AutoClaw

多 Agent 系统的「连带故障」难题

多 Agent 协作场景里，异常往往不是单一 bug 触发的：用户会遇到「Agent 重复发同样命令」「/approve 提示刷屏到没法用」的情况，或是系统突然变慢、定时任务堆成山——这些表象背后，可能是 cron 配置的假设和 Agent 的执行逻辑冲突，也可能是审批链路被多步工作流放大成了 N×N 次拦截。普通的「重启试试」只能暂时缓解，没法触达根因。

从现象到根因的四步排查

AutoClaw Skills 不靠「拍脑袋修复」，而是按固定流程拆解问题：

• 第一阶段：Cron 审计：检查定时任务的 everyMs 间隔、timeoutSeconds 超时设置、mode 路由逻辑，排查频率过高、超时或路由断裂的问题；
• 第二阶段：审批链路分析：面对审批刷屏日志，识别「单步高危拦截 vs 多步工作流逐条 exec」的设计冲突；
• 第三阶段：Agent 行为注入：确认行为异常后，直接修改目标 Agent 的 AGENTS.md，注入合并操作规则；
• 第四阶段：Session 排查：清理残留的僵尸 session，终止无效进程。

每步排查都有明确的修复清单——比如把「每分钟执行」改成「每 10 分钟」，或是给高频审批加合并逻辑——而不是笼统的「优化配置」。

不是万能药的适用边界

这个技能只针对多 Agent 系统的系统性设计冲突：它需要你有权修改 Agent 的 AGENTS.md 文件，也依赖现有 cron 的参数暴露程度。如果是某个具体 API 的偶发超时，或是第三方依赖的突然故障，它不会比直接查日志更有效。它更像给系统做「体检+手术」的流程指引，而不是自动修复一切的 magic bullet。