每一个 AI agent 平台都附带一个完美运行的 demo。agent 读取一个 GitHub issue，写出修复，提交 PR。Slack 机器人总结一个频道，起草回复，然后等待批准。这些 demo 是真的，但它们也是谎言。

demo 省略了与 AI agent 共事的主要现实：它们总是在出问题。不是那种灾难性的、上头条的方式——虽然那种也有——而是微小的、累积的、令人抓狂的方式。一个幻觉出来的函数调用，框架重试六次后才放弃。一个在任务中途溢出的上下文窗口，静默丢弃了你三轮之前给出的指令。一次返回空响应的工具调用，触发无限重试循环，在你察觉之前烧掉 85 美元的 API 额度。

这些失败不是 bug。它们是把大语言模型——为合理性而非正确性优化的随机系统——放进假设确定性行为的 agent 循环后涌现出来的属性。当一个框架把 LLM 包进 while not done: 循环并交给它工具时，它创造了一个动力系统，其失败模式与两个组件各自单独的失败模式在性质上都不同。

AllClaws 分析了 34 个跟踪平台的失败模式——从 aider 和 Claude Code 这样的编程 agent，到 MetaGPT 和 ChatDev 这样的多代理框架，再到 Dify 这样的可视化平台。我们识别出 13 种不同的失败模式。以下是其中最要命的几种。

静默成功：最危险的失败

agent 报告任务已成功完成，但输出是错的、不完整的，或者根本没有实际执行。用户信任了这个报告继续前进，很久之后才发现失败。

这是我们跟踪的所有平台中最危险的单一失败模式。在 aider 中，agent 报告”所有测试通过”，但它只运行了测试的一个子集。在 OpenClaw 中，agent 报告”部署成功”，而部署命令返回了被捕获却未被检查的非零退出码。在 MetaGPT 中，QA agent 报告”所有测试通过”，依据的测试套件本身却是由 Engineer agent 编写的——可能并不覆盖会暴露 bug 的边界情况。

在 Copilot CLI 中，静默成功表现为”命令成功了”，而命令本身就不是对的那个——项目用的是 yarn，它却跑了 npm install，命令成功执行了（npm 安装了已存在的包），但依赖冲突要在几天后才会浮出水面。

在 Dify 中，可视化工作流可能在每个节点都静默成功，而整条流水线产出错误输出。每个节点都返回 200 OK，但节点之间的数据转换丢失了信息——一个 JSON 字段被丢掉，一个日期被重新格式化。工作流报告成功，因为没有节点抛出错误。

机制并非恶意。LLM 被训练得乐于助人。当被问到”你做了 X 吗？”时，模型的先验是说”是”——不是因为它在撒谎，而是因为”是”是对确认性提问最可能的回答。如果 agent 没有真正验证结果，它报告的是基于计划而非执行的成功。

幻觉循环

agent 生成一个貌似合理但错误的动作，观察到失败，然后生成另一个貌似合理但错误的动作来”修复”它，制造出一条不断升级的错误链。

在 aider 中，这表现为”自信补丁”模式。agent 生成一个语法上看起来正确的 diff，应用它，测试失败，然后 agent 生成一个只处理症状而非根源的新 diff。我们观察到 4-6 个补丁的链条，每一个在修复上一个错误的同时引入新错误——代码库在两个坏状态之间振荡。

在 MetaGPT 中，幻觉循环换了种形式。Architect agent 根据需求设计系统架构，Engineer agent 实现它，QA agent 测试它。当测试失败时，QA 反馈给 Engineer，Engineer 打补丁——但没有人有权限质疑架构本身。幻觉在角色层级中传播，Engineer 和 QA 之间的循环可以无限持续。

在 OpenClaw 中，当 agent 遇到不熟悉的 CLI 工具时会出现幻觉循环。它根据自己知道的相似工具猜测标志和参数。每次失败的调用都教给它错误的教训——”也许我需要 sudo？”——导致越来越有创意却越来越错的命令。

根源在于 LLM 产出的是连贯的延续，而不是正确的延续。当工具调用失败时，模型最可能的回应不是”我不知道”，而是一个同样错误的自信替代方案。

上下文衰减：慢性杀手

在长对话中，agent 逐渐丢失对原始目标的追踪，忘记早期建立的约束，开始产出对最新消息技术上响应、但与整体任务不一致的结果。

Claude Code 通过自动上下文压缩比大多数平台处理得更好——当上下文窗口填满时，旧消息被摘要压缩。但压缩是有损的。我们观察到 agent 忘记某个文件已经被修改过，然后用冲突的变更再次修改它的情况。

在 ChatDev 中，上下文衰减跨越角色边界发作。产品经理写规格书。到 Engineer 看到它时，上下文已经包含规格书、架构文档和多轮实现。Engineer 的产出偏离原始规格，因为规格的细节已经被上下文压力压缩掉了。

Transformer 注意力偏向近处的 token。第 3 轮给出的指令，到第 50 轮时实际上不可见了，尤其是当对话累积了大量填充上下文窗口的工具输出时。agent 没有”忘记”——信息技术上还在——但注意力权重让它实际上无法访问。

无限重试循环

agent 遇到持续性失败（错误的 API key、权限不足），无限期地重试同一个动作——烧掉额度而毫无进展。

在 AutoGen 中，agent 之间的对话可能进入”礼貌附和循环”：agent A 请 agent B 做某事，B 说做不到，A 换种方式再问一次，对话持续几十轮毫无进展。严格说这不是重试循环——是协商循环——但效果一模一样：token 浪费，零进展。

大多数框架用指数退避实现重试逻辑。但退避针对的是瞬时故障（网络超时），不是持续性故障（凭据错误）。当持续性故障触发重试逻辑时，agent 进入只能靠外部干预才能打破的循环。

好平台与坏平台的分水岭

在编目了 34 个平台的失败之后，模式很清晰：没有平台能消除失败。区分可靠系统与不可靠系统的，是恢复的速度和效果。

审批门控 agent（OpenWorker、带 human-in-the-loop 的 Hermes-Agent）处理失败最好。审批门提供了一条自动恢复路径：当 agent 走偏时，人类在损害扩散之前抓住它。这是用自主性换可靠性。

工程严谨的 agent（Claude Code、OpenCode）通过熔断器、上下文压缩、显式验证步骤和硬性步数上限来处理失败。它们以可预测、有边界的方式失败，而不是螺旋失控。

多代理角色扮演系统（MetaGPT、ChatDev）最容易出问题。角色层级制造了沟通开销、上下文碎片化和责任分散。出了问题时，每个 agent 都指责另一个角色的输出。角色扮演的隐喻在 demo 里很优雅，在生产中很脆弱。

可视化工作流平台（Dify、Coze Studio）把失败藏在友好的 UI 后面。在代码里显而易见的错误，在可视化流水线中变得不可见。平台在每个节点报告成功，而整体输出是错的。

真正有效的恢复模式

我们编目了九种恢复模式。没有平台全部实现。大多数实现两三种。

模式 作用 使用者
熔断器 连续失败次数的硬上限 Claude Code、aider
上下文压缩 摘要旧上下文以释放空间 Claude Code、Hermes-Agent
审批门 后果性动作前的人工审查 OpenWorker
显式验证 声称成功前运行真实检查 Hermes-Agent
新鲜状态读取 修改前重新读取文件 aider、OpenClaw
Schema 校验 执行前拒绝非法工具调用 LangGraph
Token 预算上限 每任务花费的硬上限 （罕见，多为自研）
密钥脱敏 扫描输出中泄漏的凭据 Hermes-Agent（tirith）
依赖熔断器 依赖宕掉时快速失败 （非常罕见）

最佳实践与普遍实践之间的差距，就是大多数生产失败栖身的地方。

这意味着什么

agent 失败不是异常——它是默认状态。我们构建的系统是包在确定性循环里的随机引擎，两种范式之间的失配产出了这里描述的失败模式。

agent 可靠性的下一个前沿不是更大的模型或更好的 prompt，而是更好的失败处理：能正确分类失败的熔断器、能保留任务相关信息的上下文管理、能在静默成功传播之前抓住它的验证系统。构建了这些生存机制的平台，才会是从 demo 毕业到生产的那些。

在那之前，你看到的每一个 agent demo 都是一个省略了不快路径的谎言。它给你看的是快乐路径。不快乐的路径——13 条，还在增加——才是真正的工程发生的地方。

本文基于完整的 Q3-5 研究报告：Failure Mode Taxonomy: How AI Agents Break in Production。34 个平台中记录的 13 种失败模式。

English version