二十多个 Claude 智能体协作的失效教训

二十多个 Claude 智能体协作，最危险的故障可能是一张自信、全绿的状态页。dev.to 一篇经验文章回顾了作者用 Claude Code 智能体运营小型公司四个月的过程，列出 12 类失效及修复。现有节选揭示的核心问题是：智能体可能把前序会话留下的记录当成证据，而检查通过，也可能只是文档彼此一致。

目前能确认什么

作者的工作流由一名人类负责人决定优先级，多个智能体会话执行任务，通过共享记忆仓库、留言板和定时流程协作。共享文件夹收到任务记录，也会触发新的工作会话。

一次应用商店审核批准了四个应用，但他们团队的所有看板连续六天没有捕捉到变化，检查始终全绿。原因之一是检查拿文件核对文件，没有查询真实业务系统。

他们给出的修复包括：先查 API、HTTP 或 git，再读取文档；查询出错时标为 UNDETERMINED；声称部署、发送或合并完成时，当轮检查最终状态。

节选还强调给查询配一个必定命中的对照。例如，搜索结果为空，既可能确实没有目标，也可能是查询失效。对照查询能帮助区分这两种情况。第 12 类问题在节选中未完整展开，不能据此还原全部方案。

我的判断

共享记忆里的重复陈述，不能算作多份独立证据。

程序员搭建多智能体流程时，应让「完成」对应可观察的结果：部署后查询线上版本，合并后核对目标分支的提交，业务状态则读取对应系统。否则，增加审阅智能体可能只会增加认可同一份错误记录的会话。

独立审阅也不能只靠一句提示词。作者采用全新进程，只提供路径和检查要求，以减少构建过程中的结论对审阅者的影响。但新进程仍可能读取同一份错误材料，隔离上下文并不自动保证结论正确。

这些修复在其他项目中能覆盖多少故障、如何维护检查本身，现有节选没有给出充分证据。可以确认的是，验收标准需要落在业务结果上。