AI Agent为什么会"僵死"？Mission Control三信号检测与检查点崩溃恢复完整解析
【免费下载链接】mission-controlThe world's first Autonomous Product Engine (APE): AI agents research your market, generate features, and ship code as PRs. Convoy mode, crash recovery, cost tracking, 80+ API endpoints. Self-hosted via OpenClaw Gateway.项目地址: https://gitcode.com/gh_mirrors/mission/mission-control
Mission Control 是全球首个自主产品引擎（APE），内置一套「三信号完成检测 + 检查点崩溃恢复」机制：通过运行时会话心跳、任务活动流、检查点/交付物三类持久化信号判断 AI Agent 是"在安静干活"还是真的"僵死"，并借助 checkpoint 自动续跑，避免任务卡死后人工救火。
一、"僵尸"Agent 是怎么产生的？
先说结论："僵尸"不是 Agent 卡住了，而是 Agent 已经不存在了，但任务还以为它活着。🧟
典型场景有三个：
- 进程崩溃/被杀：Agent 的运行时会话（OpenClaw 或 Codex）因 OOM、断网、网关重启而退出，但数据库里任务状态还是
in_progress； - 派发失败：规划完成后派发请求超时，任务停留在
assigned，没有任何会话被真正创建； - 静默失联：会话进程还在，但 Agent 再也不产出任何活动记录。
如果不检测，任务会永远停在"进行中"，队列看起来一切正常——这正是"僵尸"最危险的地方：它不报错，只消失。
二、核心思路：不看"进程活着没"，只看"持久化信号"
Mission Control 的 src/lib/agent-health.ts 采用的判断逻辑很务实：不依赖易失的进程状态，而是查询数据库里的持久化证据。核心信号有三个：
| 信号 | 来源 | 含义 |
|---|---|---|
| ① 运行时会话（心跳） | openclaw_sessions/codex_sessions表中状态为active/running的记录 | Agent 进程是否还连着 |
| ② 任务活动流 | task_activities、task_deliverables的最新时间戳 | Agent 最近有没有产出动作或交付物 |
| ③ 工作检查点 | work_checkpoints的last_checkpoint_at | Agent 最近一次"存档"是什么时候 |
检测的第一步是心跳门禁（agent-health.ts#L340-L353）：只要任务处于活跃状态（assigned/in_progress/testing/verification），却查不到任何活跃会话，直接判定为zombie（无心跳），置信度 0.9：
"任务还在进行，但 Mission Control 找不到这个 Agent 的活跃运行时会话。"
心跳正常时，再看三类信号的"最新有意义信号"距今多久，套用四档阈值（agent-health.ts#L9-L12）：
| 静默时长 | 判定 | 状态含义 |
|---|---|---|
| ≤ 5 分钟 | working（Active recently） | 有活动/交付物/检查点，一切正常 ✅ |
| 5 ~ 45 分钟 | working（Working silently） | 长构建期正常静默，不报警 |
| 45 ~ 90 分钟 | stalled（Needs attention） | 有会话但久无信号，标记警告 ⚠️ |
| > 90 分钟 | stuck（Genuinely stuck） | 真的卡住了，进入自动救援 🔴 |
这套设计的精妙之处：长任务安静构建 20 分钟是常态，不是故障。早期版本 5 分钟没动静就报"stalled"，误报率高得令人发疯；现在"working silently"被明确视为健康状态，只有 90 分钟以上才升级为真卡死。
另外还有一个聊天维度的补充检测：如果操作者 30 分钟前在任务聊天里问了问题，Agent 至今既没回复、也没有完成信号，会被单独标记为Chat reply overdue（agent-health.ts#L384-L398）——专治"人在群里@了半天没人理"的尴尬场景。
健康检查何时运行？
runHealthCheckCycle()不是死循环轮询，而是挂靠在 SSE 事件流上（src/app/api/events/stream/route.ts）：只要有客户端通过实时事件流连接着控制台，健康检查就会周期性自动执行；也可以手动调用 src/app/api/agents/health/route.ts 触发一轮全量体检。状态每次变化都会通过事件广播（agent_health_changed）推给前端看板。
三、从"发现僵尸"到"自动复活"：Nudge 恢复管道
检测到问题后，Mission Control 的升级路径（specs/agent-health-overhaul-spec.md）是一条清晰的流水线：
working ──(5 min 静默)──> working_silently ──(45 min)──> stalled ──(90 min)──> stuck │ 连续 3 次体检判定 stuck ▼ 自动 Nudge（踢一下） ▼ 结束旧会话 → 注入检查点上下文 → 重新派发（最多 2 次尝试）关键规则：连续 3 次健康检查都判定"真卡死"才会自动 Nudge（AUTO_NUDGE_AFTER_STALLS = 3，agent-health.ts#L594-L604），避免一次网络抖动就误杀 Agent。
nudgeAgent()的恢复四步曲（agent-health.ts#L688-L741）：
- 清理现场：把该任务名下所有
active状态的 OpenClaw 会话置为ended，取消 Codex 运行，防止新旧会话打架； - 注入"存档"：调用
buildCheckpointContext()取任务最近的检查点，拼成一段"崩溃恢复"上下文追加到任务描述里（见下节）； - 回退状态：任务从
in_progress回退到assigned，清除旧派发错误； - 重新派发：调用
/api/tasks/[id]/dispatch，最多重试 2 次；成功后重置连续卡顿计数、任务恢复working，活动流里留下一条"Agent nudged — re-dispatching with checkpoint context"记录。
如果自动 Nudge 两次都失败，错误信息会写回任务的planning_dispatch_error字段并在界面醒目展示——绝不静默吞掉失败。此外，健康周期里还有一个"孤儿任务清扫器"：规划已完成、却卡在assigned状态超过 2 分钟的任务会被自动补派发（agent-health.ts#L608-L653）。
四、检查点（Checkpoint）：Agent 的"存档读档"系统
自动恢复之所以敢"杀进程重来"，底气来自 src/lib/checkpoint.ts：Agent 干活途中会周期性"存档"。
存什么（saveCheckpoint，checkpoint.ts#L18-L41）：
state_summary：当前进度的人话总结files_snapshot：已创建/修改过的文件清单（路径 + 哈希 + 大小）context_data：当前步骤、已完成步骤、剩余步骤、备注等结构化上下文
存档时同步更新agent_health.last_checkpoint_at，并广播checkpoint_saved事件——所以检查点既是恢复凭证，也是健康检测的第三类信号。
怎么读档：buildCheckpointContext()（checkpoint.ts#L79-L103）把最新存档渲染成一段直接喂给新 Agent 的提示，大意是：
🔄CRASH RECOVERY — 从检查点恢复（附时间戳） 已完成工作：xxx；已创建文件：a.ts、b.ts…… 当前步骤 / 已完成步骤 / 剩余步骤……请从上一个 Agent 中断处继续，不要重做已完成的工作。
这段"续跑说明书"会被拼进新派发任务的消息里，新 Agent 接手后能准确知道哪些活干完了、活到哪一步，而不是推倒重来烧一遍 Token。除了自动 Nudge 场景，用户也能手动触发读档：前端"从检查点恢复"按钮走的是 src/app/api/tasks/[id]/checkpoint/restore/route.ts，逻辑与自动 Nudge 同源：追加检查点上下文 → 结束旧会话 → 重新派发。
五、这套机制为什么值得参考？
- 证据驱动，不猜进程：所有判定都基于数据库里的持久化记录（会话、活动、检查点、聊天），控制台自己重启也不影响结论；
- 分级容忍，少报不误报：5 / 45 / 90 分钟三档阈值区分"安静构建"与"真卡死"，连续 3 次确认才动手，保护长任务；
- 检测-恢复闭环：发现问题 → 自动清理 → 带上下文重派 → 失败留痕，全程无人值守，符合 APE"自主引擎"的定位；
- 状态可解释：每次判定都带
reason、confidence和完整信号快照写入agent_health.metadata，界面展示的每个红黄灯背后都能追到具体证据（见 src/lib/agent-health.test.ts 中的用例覆盖）。
想深入实现细节，可以从这三个文件入手：src/lib/agent-health.ts（三信号判定与 Nudge）、src/lib/checkpoint.ts（存档/读档）、specs/agent-health-overhaul-spec.md（状态机与升级策略设计文档）。
一句话总结：让 AI Agent 长时间自主干活，"死掉"是迟早的事；真正拉开差距的不是让 Agent 不崩，而是像游戏存档一样——崩了能发现、发现能续命、续命不重做。这正是 Mission Control 三信号检测与检查点恢复想解决的核心问题。
【免费下载链接】mission-controlThe world's first Autonomous Product Engine (APE): AI agents research your market, generate features, and ship code as PRs. Convoy mode, crash recovery, cost tracking, 80+ API endpoints. Self-hosted via OpenClaw Gateway.项目地址: https://gitcode.com/gh_mirrors/mission/mission-control
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
