用途：当开发机感觉迟缓——负载持续高于核心数、swap 抖动、代理进程泛滥或编译风暴时，按从最安全到最具侵入性的顺序清理进程，恢复系统响应。
主要能力：分三步循环。一、只读诊断：用 uptime、nproc、/proc/pressure/cpu|io|memory、僵尸计数、按 CPU 排序的进程列表建立基线。二、按 kill hierarchy 清理：先回收僵尸与已退出的会话（无风险），再对卡住的子进程发 SIGTERM，等待 3 秒后升级为 SIGKILL；然后杀掉“困惑的父代理”，使其停止反复重启子进程；最后对幸存进程 renice/ionice，保留交互空间。任一循环恢复响应即停止，不执行后续步骤。三、清理代理集群：针对重复构建目录、孤立 MCP 子进程、被遗弃的 tmux/zellij 会话等二次问题。四、验证：重跑基线命令并写一行 delta。
使用方式：附带快速检查清单。示例命令包括：ps -eo stat | grep -c '^Z' 统计僵尸；zellij list-sessions 2>&1 | grep -c EXITED 与 zellij delete-all-sessions --yes 清理死会话；用 ps -eo pid,etimes,args 按运行时长筛出长时间挂起的子进程（如 12 小时以上）和父代理（16 小时以上）；对存活编译进程执行 renice 19 -p "$pid" 与 ionice -c 3 -p "$pid"；最后 sleep 10 && uptime 验证。运行报告写入 .agents/system-tuning/YYYY-MM-DD-triage.md。
限制：不得对 systemd、sshd、dbus、cron、postgres、mysql、redis、nginx、caddy、docker、containerd、k3d、kubelet 以及会话所在的复用器发信号，除非获得明确授权；不确定就保留并记录。生产事故应交由他人处理，不要盲目 kill。若单一进程为热点，应先用 /perf。资料未提供安装方式与价格信息。