实战复盘：OpenClaw 6人 AI Agent Team 险些全军覆没——静默失败链的教训6个 AI Agent 同

📖 本文首发于微信公众号「Wesley AI 日记」，更多 AI Agent 实战系列请微信搜索关注。

上个月，我的 6 人 AI Agent 团队险些全军覆没。

不是断电了，不是服务器挂了——而是 6 个 Agent 同时在运行，每个都认为自己在正常工作，但整个系统的输出是零。

事故现场

先说背景：我用 OpenClaw 框架搭了一套 AI Agent 团队来运营自媒体，包含 CEO Agent（调度）、内容 Agent（写文章）、发布 Agent（推送到各平台）、互动 Agent（评论回复）、增长 Agent（数据分析）和站点可靠性 Agent（系统监控）。

那天是一个普通的工作日，系统按计划执行当日任务。

时间线：

问题出在哪？内容 Agent 写入的路径是 /articles/2026-03-xx.md，但发布 Agent 读取的路径配置是 /workspace/articles/2026-03-xx.md。路径不一致。

但故事没有这么简单。

发布 Agent 找不到文件后，它做了什么？

它重试了 5 次，每次间隔 30 秒。 5 次都失败了。然后呢？

它没有报错，没有通知任何人。它在任务日志里写了一行："发布尝试完成，共5次。" 注意：不是 "发布失败"，是 "发布尝试完成"——这在语义上是成功的。

接下来，互动 Agent 看到发布日志显示 "完成"，开始准备当日评论互动计划。它为一篇根本没发出去的文章准备了回复模板。

增长 Agent 看到内容 Agent 写了文章、发布 Agent 完成了任务，开始生成当日数据报告。报告里写着："今日内容产出 1 篇，已发布。"

CEO Agent 晚上汇总时，收到的信息是：所有模块正常运行，任务全部完成。

实际结果：当天0篇文章发布。

事后复盘，这次事故暴露了三个系统性问题：

6 个 Agent 之间通过文件系统通信，但没有一个统一的文件路径协议。每个 Agent 在自己的配置里定义路径，没有集中管理。

修复： 建立共享配置文件 shared-config.md，所有 Agent 读同一个路径定义。

"发布尝试完成" vs "发布成功" 在人类看来有明显区别，但在 Agent 的上下文中，LLM 倾向于使用积极的措辞，且下游 Agent 缺乏语义分辨能力。

修复： 引入结构化状态码：SUCCESS、FAILED、PARTIAL、SKIPPED。每个任务完成后必须输出明确的状态码，而不是自然语言描述。

没有人检查最终产出。每个 Agent 只验证自己的环节，没有人从全链条角度看"今天到底发了几篇文章"。

修复： CEO Agent 在每日结束时执行端到端验证：直接去目标平台检查发布结果，而不是依赖各 Agent 的自报。

这次事故后，我做了几个关键改动：

1. 从 6 个 Agent 精简到 4 个

砍掉了独立的发布 Agent 和互动 Agent，将发布功能集成到内容 Agent 中（减少跨 Agent 通信），互动功能集成到增长 Agent 中。

2. 引入"铁律"机制

每次事故后，提炼出一条不可违反的规则，写入全团队共享的 AGENTS.md。比如这次的铁律："任何任务完成后，必须输出结构化状态码，自然语言描述仅作为备注。"

3. 降级通知

任何 Agent 检测到异常但无法处理时，必须通过飞书消息通知人工。不能静默重试后放弃。

4. 每日端到端检查

CEO Agent 每天 23:00 执行一次全平台扫描，检查当日预期产出是否真实存在。

最重要的认知变化是：Agent 团队的规模不是越大越好，最优规模是能跑通核心流程的最小配置。

📖 本文首发于微信公众号「Wesley AI 日记」

📚 AI Agent 实战系列（微信搜索「Wesley AI 日记」关注）：

👆 微信搜索「Wesley AI 日记」关注，不错过每一篇更新。