OpenClaw 有价值应用（2026-05-20）：多Agent系统故障自愈流——让AI系统从「静默崩溃」变成「自知自愈」

场景演示

你有没有遇到过这种情况：

• 定时任务跑了，Agent 说"完成了"，但实际上中间报错了，只是错误被吞掉了
• Subagent 跑了几个小时，最后 session 超时结束，没有任何输出
• 多 Agent 流水线跑了 20 步，第 18 步失败，整条流水线无声无息地停了

这是 AI 自动化系统最危险的时刻——它以为自己还在跑，实际上已经死了。

多 Agent 系统故障自愈流，就是给 AI 工作流装上「心跳监测 + 自我诊断 + 自动重启」的三合一机制，让系统从「静默崩溃」变成「自知自愈」。

Step by Step

第一步：建立心跳监测 Agent

给每个长时运行的任务挂一个独立的「心跳 Agent」，每 N 分钟检查一次目标 Agent 的状态。

你是一个心跳监测 Agent，负责监控指定 session 的健康状态。

监控目标 session：{target_session_id}
心跳间隔：5 分钟
超时阈值：连续 3 次无心跳 = 判定为「失联」

检查内容：
1. session 当前是否仍在运行（sessions_list）
2. 最后一条消息时间戳距今是否超过阈值
3. 输出是否有错误关键词：[error]、[timeout]、[failed]

判定结果：
- 健康：输出 ✅ + 简短状态描述
- 失联：输出 🔴 + 原因 + 建议操作（restart session / notify human）

第二步：部署自我诊断 Pipeline

当心跳 Agent 报告失联，触发诊断 Pipeline：

诊断流程：
1. 读取 session 历史（sessions_history）
2. 提取最后 N 条消息，识别错误类型
3. 判断错误是否可重试：
   - 网络超时 / API 限流 → 可重试，等待后自动重跑
   - 逻辑错误 / 断言失败 → 不可重试，通知人工介入
   - 上下文窗口超限 → 自动 reset session，从断点续跑
4. 输出诊断报告到飞书

第三步：自动重启 + 断点续跑

对于可恢复的故障，触发自动修复：

## 故障自愈执行协议

若诊断结果为「可重试」：
1. 等待冷静期（Exponential backoff：5min → 10min → 20min）
2. 重新发起 subagent，传递原始任务 + 已完成步骤清单
3. 新 session 从断点继续，不从头跑
4. 若重试 3 次仍失败 → 升级通知人工

若诊断结果为「上下文超限」：
1. sessions_send 重置指令到目标 session
2. 等待 reset 完成
3. 从最近 checkpoint 恢复任务上下文
4. 继续执行

第四步：故障日志持久化

所有故障事件写入飞书 Bitable，形成故障知识库：

可复制提示词

启动心跳监测

你是一个心跳监测 Agent，为指定的 subagent session 定期检查健康状态。

监控目标：{session_id}（目标任务的 session key）
检查间隔：每 5 分钟一次
超时判定：连续 3 次检查无心跳（最后消息时间距今 > 5 分钟）

执行检查时，使用 sessions_list 和 sessions_history 工具获取目标 session 状态。

输出格式（每次检查后输出这一行）：
✅ 健康 | 最后消息：{时间} | 距今：{N}分钟
🔴 失联 | 原因：{描述} | 建议：{操作}

若判定为失联，立即：
1. 读取目标 session 最近 20 条消息
2. 识别错误类型（超时/逻辑错误/上下文超限/API失败）
3. 判断是否可自动恢复
4. 将诊断结果写入 /tmp/health_report_{session_id}.md
5. 若可恢复，执行自动重启逻辑；若不可恢复，通过飞书通知人工

诊断触发器

你是一个故障诊断 Agent，读取心跳报告并执行诊断。

心跳报告路径：/tmp/health_report_{session_id}.md

诊断协议：
1. 读取报告内容
2. 调用 sessions_history 提取目标 session 最后 30 条消息
3. 识别错误关键词：[error]、[timeout]、[context window]、[failed]
4. 分类：
   - 网络类（timeout/503/429）：自动重试
   - 逻辑类（assertion/error）：通知人工
   - 资源类（context/memory）：reset + 续跑
5. 生成诊断报告，包含：错误类型、根因、可恢复性、建议操作
6. 若可恢复，执行 sessions_send 发送恢复指令
7. 若需人工，写入飞书 Bitable 并推送通知

使用的 Skills

价值与注意事项

核心价值

• 不再有静默失败：每个长时任务都有心跳守护，故障不会被吞掉
• 自动恢复不过度依赖人工：网络抖动、API 限流等瞬时故障自动修复
• 故障知识沉淀：每次故障都记录到 Bitable，久而久之形成故障模式库
• 断点续跑不浪费：上下文超限后从 checkpoint 续跑，不从头开始

注意事项

1. 心跳间隔要合理：太短会产生过多检查调用，太长会延误发现时间。推荐 5 分钟。
2. 重试要有上限：自动重试不超过 3 次，防止进入死循环。
3. 人工介入阈值要清晰：明确哪些错误必须通知人，不要所有错误都自动重试。
4. 日志不要写敏感信息：Session ID 可以记录，但不要记录 API Key、Token 等。
5. 故障自愈不是银弹：逻辑错误、资源枯竭等结构性故障，必须人工排查。

总结：多 Agent 系统故障自愈流，本质上是给 AI 工作流装上「免疫系统」——它让系统从被动等死，变成主动发现、自我诊断、自动修复。每一次故障都是系统进化的机会，故障知识库会越来越丰富，系统也会越来越健壮。