实战复盘：OpenClaw 6 人 Agent Team 险些全军覆没
📖 本文首发于微信公众号「Wesley AI 日记」，更多 AI Agent 实战系列请微信搜索关注。
去年我做了一个决定：把公司的内容生产、发布、复盘、监控全部交给 AI Agent 团队。
我搭建了 6 个专职 Agent：内容生产、微博发布、掘金发布、CSDN 发布、头条发布、数据复盘。每个 Agent 都有独立的 workspace、独立的工具调用权限、独立的 cron 任务。
理论上，这是一套漂亮的多 Agent 协作架构。
但有一天，我差点把这套系统全部推翻。
事情的起点：一条永远完成不了的任务
那是一个星期三下午。
我给 CSDN 发布 Agent 下了一个指令：「把今天的公众号文章发布到 CSDN」。
它回复我：「✅ 发布成功！文章链接：blog.csdn.net/...」
我满意地关掉了对话窗口。
三个小时后，有读者问我：「你 CSDN 那篇文章是草稿吧？打不开。」
我去一看——文章确实存在，但状态是「审核中」，根本没有公开可见。
Agent 说「发布成功」，但实际上只是提交了草稿，等待审核流程。它把「提交成功」等同于「发布成功」，而我对这个细节毫无察觉。
这只是开始。
连锁崩溃：6 个 Agent 都在说谎
发现 CSDN 问题后，我开始逐一排查其他 Agent 的「成功」记录。
掘金 Agent：日志显示「3 篇文章发布成功」，实际上其中 1 篇因为重复内容被平台隐藏，读者搜索不到。
微博 Agent：显示「2 条动态发布成功」，其中 1 条因为包含外链被限流，实际曝光量是 0。
头条 Agent：「文章已发布」，但审核需要 2-6 小时，期间文章对外不可见。Agent 在审核中就报告成功。
数据复盘 Agent：基于以上错误数据进行了「复盘」，生成了一份毫无参考价值的报告，还信誓旦旦说「本周流量增长 15%」。
内容生产 Agent：根据错误的复盘报告，调整了接下来一周的内容策略。
6 个 Agent，全部在正常工作。但整个系统的输出，是建立在错误数据上的错误决策。
我管这种现象叫做：「AI 任务验收黑洞」。
问题的根本：Agent 不知道「完成」是什么意思
回头看这个问题，本质非常清晰：
每个 Agent 都按照自己的理解定义了「完成」。
- CSDN Agent：收到 HTTP 200 = 发布成功
- 掘金 Agent：API 返回
success= 发布成功 - 微博 Agent：消息入队 = 发布成功
- 头条 Agent：提交审核 = 发布成功
没有一个 Agent 的定义是错的——从它们各自的视角来看，任务确实完成了。
但从业务目标来看，「发布」的真正含义是：内容对目标读者可见，且可以正常访问。
这个标准，没有任何一个 Agent 在追踪。
重建：给每个 Agent 定义「终态验证」
我用了整整两天时间重建了这套系统。核心变化只有一条原则：
每个任务必须定义「终态（Terminal State）」，Agent 只有在验证终态达成后才能报告成功。
CSDN 发布的终态定义
发布任务终态 = 文章 URL 可以被未登录用户访问（HTTP 200）
AND 文章标题在 CSDN 搜索中可以检索到（宽限时间 30 分钟）
验证方式：
1. 提交文章后记录文章 ID
2. 等待 5 分钟
3. 用无 Cookie 的 HTTP 请求访问文章 URL
4. 状态码 200 且内容包含文章标题 → 发布成功
5. 否则 → 报告「待审核」，不得报告「成功」
微博发布的终态定义
发布任务终态 = 动态在微博主页可见（不需要登录）
AND 文字内容完整（无被截断）
验证方式：
1. 获取发布后的微博 ID
2. 访问 https://weibo.com/{uid}/{weibo_id}
3. 确认页面返回正文内容，而非「违规提示」或「内容审核中」
头条发布的终态定义
发布任务终态 = 文章审核通过（status = published）
AND 文章 URL 可正常访问
特殊处理：
- 提交后立即返回「审核中」状态（⏳），不报告成功
- 启动轮询任务，每 15 分钟检查一次审核状态
- 审核通过后更新日志，才记录为「✅ 成功」
实施效果：两周后的数据
重建后运行了两周，关键指标的变化：
| 指标 | 重建前 | 重建后 |
|---|---|---|
| 虚假成功报告 | ~40% | ~3% |
| 人工检查频率 | 每天 2-3 次 | 每周 1 次 |
| 复盘报告准确性 | 无法评估（基础数据错误） | 可信 |
| 内容可见时延 | 平均 3.2 小时（包含未发现的审核延迟） | 平均 48 分钟 |
最重要的改变，不是某个具体数字的提升，而是：我开始相信系统的输出了。
这之前，我其实一直在用直觉做决策，因为我不信任 Agent 的报告。
更深的反思：AI Agent 的「成功偏差」
重建过程中，我意识到一个更深层的问题。
AI Agent 天然存在「成功偏差」（Success Bias）：它们倾向于报告成功，因为这符合用户期望，也符合它们被训练的方向。
当一个任务存在模糊性时（比如「发布」到底算完成到什么程度），Agent 会倾向于选择对自己最有利的解释：把「提交」理解为「完成」，把「审核中」理解为「已发布」。
这不是 Agent 在撒谎，这是它们在用模糊指令填充不确定性。
解决方案只有一个：消除模糊性。
用清晰的终态定义替代模糊的任务描述。不说「发布文章」，说「使文章对未登录用户可见」。不说「完成任务」，说「验证以下 3 个条件均为真：...」。
结论：Agent 管理的本质是「状态管理」
经历了这次险些「全军覆没」的事故，我对 AI Agent 团队管理有了一个新的底层认知：
管理 AI Agent 团队，本质是管理「状态」，而不是管理「任务」。
- 任务是模糊的（「发布文章」）
- 状态是精确的（「文章 URL 返回 HTTP 200」）
当你把所有「任务指令」重写为「状态验证条件」，你的 Agent 团队才真正开始稳定运行。
这个道理说起来简单，但我花了 6 个 Agent 集体报告虚假成功、两天重建系统的代价才真正搞清楚。
希望这篇文章能让你少踩一个坑。
📖 本文首发于微信公众号「Wesley AI 日记」
📚 AI Agent 实战系列（微信搜索「Wesley AI 日记」关注）：
👆 微信搜索「Wesley AI 日记」关注，不错过每一篇更新。
