AI Agent 失败模式分类：生产环境中如何崩溃

Q3-5 研究报告 —— 对 Agent 失败模式、恢复机制和跨平台弹性的系统性分析

研究日期：2026 年 7 月 | 方法：跨平台源码分析、社区报告、GitHub issues 和实际测试

AllClaws 背景： 跟踪 34 个平台（11 个 claw + 17 个外部 + 5 个 CLI + 1 个数字孪生）

执行摘要

每个 AI Agent 平台发布时都附带一个完美运行的 Demo。Agent 读取一个 GitHub issue，写出修复方案，提交 PR。Slack bot 总结一个频道，起草回复，等待审批。这些 Demo 是真实的，但它们也是谎言。

这些 Demo 省略了使用 AI Agent 的主导现实：它们不断崩溃。不是以灾难性的、头条新闻式的方式崩溃——虽然那种也会发生——而是以细小的、累积的、令人抓狂的方式崩溃。一个虚构的函数调用，框架重试六次后放弃。一个上下文窗口在任务执行中途溢出，悄悄丢弃你三轮前给出的指令。一个返回空响应的工具调用，触发无限重试循环，在你注意到之前烧掉了 $85 的 API 额度。

这些失败不是 bug。它们是将大语言模型——优化合理性而非正确性的随机系统——放入假设确定性行为的 Agent 循环中产生的涌现特性。当一个框架将 LLM 包裹在 while not done: 循环中并赋予它工具时，它创造了一个动力系统，其失败模式与任一组件单独存在时都有质的区别。

本报告建立了一个分类法，涵盖 AllClaws 跟踪的 34 个平台中观察到的 13 种失败模式。每种模式都描述了其机制、触发条件、平台特定的表现形式和恢复模式。目标不是给平台排名——没有一个平台能免疫——而是为开发者和研究人员提供讨论 Agent 可靠性的共同词汇。

核心发现：大多数 Agent 失败是递归的。一个初始的、轻微的错误——格式错误的工具输出、含糊的指令——在 Agent 循环中级联，被重试逻辑、上下文累积和 LLM 在不确定性下产生幻觉的倾向所放大。处理失败最好的平台不是功能最多的平台，而是在失败检测和恢复之间拥有最短、最可审计的反馈回路的平台。

分类法概览

13 种失败模式按 Agent 执行生命周期 组织——从 Agent 的内部推理，到工具交互、控制流、记忆退化、系统级联、输出验证和安全。这个排序追踪了单个任务如何在 Agent 系统中流转，展示每一层在哪里可能崩溃。

Group A: 推理与规划

Agent 的大脑失灵——错误推理、虚构 API、不断升级的错误链。

1. Hallucination Loop（幻觉循环）

发生什么： Agent 生成一个看起来合理但错误的操作，观察到失败或意外结果，然后生成另一个看起来合理但错误的操作来"修复"它，创建了一个不断升级的错误链。

机制： LLM 产生连贯的续写，而非正确的续写。当一个工具调用失败（错误的 API 端点、无效参数、不存在的文件），模型最可能的响应不是"我不知道"，而是一个同样错误的、自信的替代方案。Agent 循环将此作为上下文反馈，强化了幻觉。

触发条件：

• • 不熟悉的 API 或代码库（模型回退到与实际不符的训练数据模式）
• • 不指向根本原因的含糊错误消息
• • 命名冲突（两个函数名相似，Agent 选了错误的那个）

平台特定表现形式：

在 aider 中，这表现为"自信补丁"模式：Agent 生成一个语法正确的 diff，应用它，测试失败，然后 Agent 生成一个处理症状而非原因的新 diff。我们观察到 4-6 个补丁的链，每个在修复前一个错误的同时引入了新错误——代码库在两个损坏状态之间振荡。

在 MetaGPT 中，幻觉循环采取了不同的形式。"Architect" agent 根据需求设计系统架构。"Engineer" agent 实现它。"QA" agent 测试它。当测试失败时，QA agent 向 Engineer 报告，Engineer 打补丁——但 Architect 的原始设计可能本来就有缺陷。Engineer 和 QA 之间的循环可以无限持续，因为两个 agent 都没有权限质疑架构。幻觉在角色层级中传播。

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

恢复模式：

• • 熔断器（Circuit breakers） —— 连续失败的硬限制（aider 默认 5 次，Claude Code 默认 3 次）
• • 上下文重置 —— 清除对话历史，仅用任务描述和错误日志重新开始
• • 人工上报 —— 连续 N 次失败后提示用户，而不是继续

弹性排名： Claude Code 和 OpenCode 处理得最好，具有显式的熔断器和自动上下文压缩。没有内置限制的框架（原始 LangGraph、AutoGen）最脆弱。

2. Hallucinated Dependency（虚构依赖）

发生什么： Agent 虚构了一个不存在的库、包或 API，并编写了依赖它的代码。代码看起来正确，但在运行时失败，因为依赖是想象出来的。

机制： LLM 通过预测最可能的下一个 token 来生成代码。当它们遇到通常需要使用库的任务时，会为它生成 import 语句。如果库存在，这就能工作。如果不存在——因为模型混淆了两个相似的库、基于命名模式虚构了一个、或引用了训练数据中已重命名或弃用的库——代码就会失败。

触发条件：

• • 不熟悉的生态系统（模型很了解 Python，但虚构 Rust crate 名称）
• • 内部或专有包（模型无法知道公司内部库）
• • 版本漂移（模型引用了库 2.x 版本的 API，但 3.x 版本已更改）

平台特定表现形式：

在 aider 和 Copilot CLI 中，这表现为 import nonexistent_library 或 from some_package import fictional_module。生成的代码语法正确甚至结构良好，但它 import 的包在 PyPI 上不存在。

在 MetaGPT 中，Engineer agent 生成带 import 的代码。QA agent 运行代码，发现 import 错误，报告回去。但 Engineer 的"修复"通常是为虚构的库创建一个 stub 实现——将缺失依赖变成一个静默损坏的依赖。

在 GoClaw（基于 Go）中，虚构依赖表现为不存在的标准库包或错误的第三方模块路径。Go 严格的模块系统在编译时捕获这些，但 Agent 可能浪费几个回合试图"修复"import 路径，然后才意识到包不存在。

恢复模式：

• • 依赖验证 —— 在编写代码前检查 import 是否可解析
• • 语言服务器集成 —— 使用 LSP 在编写代码时验证
• • 包管理器检查 —— 在 import 前验证包是否存在于 PyPI/crates.io/npm

Group B: 工具交互

Agent 在与外部世界的接口上失手——错误的工具、错误的参数、错误的权限。

3. Tool Misuse（工具误用）

发生什么： Agent 用错误的参数调用正确的工具，或者完全调用了错误的工具，产生看起来有效但语义不正确的输出。

机制： 工具 schema 是复杂 API 的有损描述。LLM 阅读工具定义 delete_file(path: str) 时理解了语法，但不理解语义——path 应该被验证、删除是不可逆的、工具可能对相对路径和绝对路径的处理不同。

触发条件：

• • 相似的工具名称（write_file vs append_file）
• • 复杂的参数类型（嵌套对象、有交互效应的可选字段）
• • schema 中未捕获的隐式约定（例如"始终使用绝对路径"）

平台特定表现形式：

Hermes-Agent 向模型暴露了 40 多个工具。工具选择错误是最常见的失败模式——模型在本应调用 patch 时调用了 write_file，或在本应使用 search_files 时调用了 terminal。工具描述很详细，但选项的绝对数量造成了一个随工具集大小增长的选择问题。

在 AgentScope 中，分布式多 Agent 架构引入了一种新的误用模式：一个节点上的 agent 调用一个期望来自另一个节点状态的工具。工具在本地成功执行，但产生全局不一致的结果。这是经典"陈旧读取"问题的分布式系统版本，应用于 Agent 状态。

在 Dify 中，工具误用的表现不同。可视化工作流构建器意味着非开发者配置工具集成。用户将 Slack 输出连接到一个期望 JSON 但接收纯文本的工具。工作流在设计器中"正常工作"，但在运行时失败——而错误消息对配置它的非技术用户来说通常是不透明的。

恢复模式：

• • Schema 验证 —— 在执行前拒绝带有无效参数的工具调用
• • Dry-run 模式 —— 展示工具将做什么而不实际执行
• • 框架级类型检查 —— LangGraph 的类型化状态和 Hermes-Agent 的参数验证都能减少这种情况

4. Permission Confusion（权限混淆）

发生什么： Agent 尝试一个它没有权限的操作，收到一个不透明的错误，然后要么无限重试，要么执行一个错误的变通方案。

机制： 权限系统（文件权限、API scopes、OAuth scopes）复杂且通常文档不完善。Agent 收到如"403 Forbidden"或"permission denied"等错误，这些错误不解释需要什么权限或如何获取。Agent 的响应是尝试替代方法——这些方法通常因同样的权限原因而失败。

触发条件：

• • 文件系统权限错误（尝试在没有 sudo 的情况下写入 /etc/）
• • API scope 错误（尝试用只读 OAuth token 发送邮件）
• • 容器隔离（尝试从容器内访问宿主资源）

平台特定表现形式：

在 OpenClaw 和 Hermes-Agent 中，两者都有终端访问权限，权限错误很常见。Agent 尝试安装包（pip install x），收到权限错误，尝试用 sudo（sudo pip install x），要么成功（造成系统级混乱），要么失败（sudo 需要密码，Agent 没有）。

在 Coze Studio 中，OAuth 连接的工具（Slack、Gmail、Jira）有细粒度的 scopes。Agent 可能尝试一个操作（例如"发送消息到 #general"），但 OAuth token 不允许。来自 Slack 的错误消息通常是"missing_scope"，不解释需要哪个 scope。

恢复模式：

• • 清晰错误映射 —— 将权限错误翻译为可操作的消息
• • 能力声明 —— Agent 应在尝试操作前知道自己的权限
• • 最小权限默认 —— 仅授予当前任务所需的权限

Group C: 控制流与资源限制

循环断裂、预算耗尽——Agent 的执行机制脱轨。

5. Infinite Retry Loop（无限重试循环）

发生什么： Agent 遇到失败（速率限制、超时、权限错误），重试相同操作，再次失败，并无限继续重试——燃烧 API 额度和时间而不取得进展。

机制： 大多数 Agent 框架实现了带指数退避的重试逻辑。但退避处理的是瞬时失败（网络超时），而非持久性失败（错误的 API key、不足的权限）。当持久性失败触发重试逻辑时，Agent 进入一个只能被外部干预打破的循环。

触发条件：

• • API 提供商的速率限制（尤其是免费层或共享 key）
• • Agent 无法修复的权限错误（需要 sudo、需要 OAuth 刷新）
• • 工具调用中的循环依赖（工具 A 需要工具 B 的输出，工具 B 又需要工具 A 的输出）

平台特定表现形式：

在 AutoGen 中，Agent 之间的对话可能进入"礼貌同意循环"，其中 Agent A 要求 Agent B 做某事，Agent B 说做不到，Agent A 换一种方式再问，对话持续几十个回合没有进展。严格来说这不是重试循环——是协商循环——但效果相同：浪费 token，没有进展。

在 OpenWorker 中，审批门控设计缓解了这个问题：在任何有后果的操作之前，Agent 必须获得人工审批。如果人类拒绝，Agent 会获得明确的反馈。这以需要持续的人工关注为代价打破了无限循环。

在没有显式递归限制的原始 LangGraph 工作流中，一个路由回自身的节点（有意或通过逻辑错误）将永远循环。LangGraph 添加了默认递归限制（25 步），但许多用户会覆盖它。

恢复模式：

• • 硬步骤限制 —— 每个任务的最大迭代次数，由框架强制执行
• • 带抖动的指数退避 —— 防止对速率受限 API 的惊群效应
• • 失败分类 —— 区分瞬时失败和持久性失败，停止重试持久性失败

6. Rate Limit Spiral（速率限制螺旋）

发生什么： Agent 遇到速率限制，等待，重试，又遇到速率限制——但每次重试都消耗配额，使下一次速率限制来得更快。螺旋收紧，直到 Agent 把所有时间花在等待上，没有任何进展。

机制： 速率限制通常表示为"每分钟 N 个请求"或"每天 M 个 token"。当 Agent 在速率限制错误后重试时，重试本身消耗配额。如果 Agent 重试 N 次，它已经消耗了 N 个单位的配额而没有任何有用的工作。在最坏的情况下，重试触发额外的速率限制（由于请求突发），创建一个正反馈循环。

触发条件：

• • 跨多个 Agent 或用户共享的 API key
• • 有激进速率限制的免费层 API
• • 突发模式（短时间内大量工具调用）

平台特定表现形式：

在中国模型提供商（GLM、DeepSeek、Qwen）中，速率限制通常比 OpenAI/Anthropic 更紧，尤其是免费层或开发者账户。运行在这些模型上的 Agent 更快更频繁地遇到速率限制。

在服务多个用户的 Dify 部署中，速率限制螺旋可能影响整个平台。如果底层模型 API 限制了 Dify 服务器，所有活跃的工作流会同时停滞。

恢复模式：

• • 请求排队 —— 序列化 API 调用以保持在限制内
• • 多 key 轮换 —— 将负载分散到多个 API key
• • 抖动退避 —— 向重试延迟添加随机性以避免同步重试

7. Token Exhaustion（Token 耗尽）

发生什么： Agent 在完成任务之前耗尽 API 预算或遇到 token 速率限制。与上下文溢出不同，这是财务/运营限制，而非技术限制。

机制： Agent 任务长度不可预测。一个"修复这个 bug"的任务可能需要 5 个回合或 500 个回合，取决于复杂度。API 成本随 token 线性增长。没有预算控制，单个任务可能消耗一整天的 API 分配。

触发条件：

• • 需要大量工具调用的复杂任务
• • 幻觉循环（失败模式 #1）在错误方法上浪费 token
• • 啰嗦的模型在 200 token 就够时产生 2000 token 的响应

平台特定表现形式：

在 MetaGPT 中，多 Agent 角色扮演结构意味着每个"回合"涉及多个 Agent 通信。单个功能请求触发 PM → Architect → Engineer → QA → PM，每个都消耗 token。Token 成本是单 Agent 方法完成相同任务所用量的 3-5 倍。

在运行 GLM 模型的 OpenClaw 中，成本更低（中国模型 API 比 OpenAI/Anthropic 便宜得多），但速率限制更紧。Token 耗尽表现为速率限制错误而非预算耗尽。

恢复模式：

• • 预算上限 —— 每个任务的 token 硬限制，带优雅降级
• • 模型分层 —— 简单操作（工具选择、输出解析）使用更便宜的模型，复杂推理使用昂贵的模型
• • 缓存 —— 缓存工具输出和 embedding 以避免冗余计算

Group D: 记忆与状态

信息随时间退化——上下文窗口填满、注意力漂移、Agent 对现实的模型偏离实际。

8. Context Window Overflow（上下文窗口溢出）

发生什么： Agent 积累了太多上下文（工具输出、对话历史、文件内容），超过了模型的上下文窗口。框架要么静默截断，要么报错退出，要么开始摘要——每种方式都有不同的失败模式。

机制： 上下文窗口是有限的（Claude 128K，GPT-4o 128K-200K，Gemini 200K）。Agent 任务是无界的。读取大文件、运行啰嗦的测试套件或探索深层目录树可能在几个回合内填满上下文窗口。

触发条件：

• • 大文件读取（尤其是压缩 JS、生成代码或日志文件）
• • 啰嗦的工具输出（测试套件、构建日志、目录列表）
• • 没有上下文管理的长对话

平台特定表现形式：

在 Claude Code 中，上下文溢出触发自动压缩——最旧的消息被摘要。这保留了继续工作的能力，但丢失了细节。我们观察到 Agent 在压缩后重新读取已经读过的文件（因为它们忘了已经读过），浪费 token。

在 IronClaw（基于 Rust）中，编译器二进制的输出可能非常庞大——数千行编译器警告。如果 Agent 读取完整的构建日志，它会用警告消耗整个上下文窗口，没有空间留给实际的错误消息（这通常在顶部，警告之前）。

恢复模式：

• • 流式 + 过滤 —— 不要读取整个输出；过滤错误和相关行
• • 上下文预算 —— 将上下文窗口的不同部分分配给不同信息类型
• • 外部记忆 —— 将中间结果写入文件，仅读取摘要

9. Context Decay（上下文衰减）

发生什么： 在长对话（50+ 回合）中，Agent 逐渐失去对原始目标的追踪，忘记对话早期建立的约束，开始产生技术上响应了最新消息但与整体任务不一致的输出。

机制： Transformer 注意力偏向最近的 token。第 3 回合给出的指令到第 50 回合实际上已不可见，尤其是在对话积累了大量填满上下文窗口的工具输出的情况下。Agent 不会以人类的方式"忘记"——信息技术上在上下文中——但注意力权重使其在实践中不可访问。

触发条件：

• • 有大量工具调用的长对话（每个输出都填充上下文）
• • 多阶段任务，早期约束适用于后期工作
• • 上下文窗口大到足以容纳所有内容，但不够大到能关注所有内容

平台特定表现形式：

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

在 ChatDev 中，上下文衰减在角色边界间表现明显。产品经理 agent 编写规格说明。当 Engineer agent 看到它时，上下文已包含规格、架构文档和多轮实现。Engineer 的输出偏离原始规格，因为规格的细节已被上下文压力压缩。

在 aider 工作会话中，上下文衰减导致"目标漂移"——Agent 开始重构不属于原始请求的代码，因为最近的消息讨论了该代码的结构，而原始任务描述已被挤出有效注意力范围。

恢复模式：

• • 系统提示强化 —— 在系统提示中重复关键约束（不仅是第一条用户消息）
• • 定期上下文重置 —— 为每个子任务开始全新对话
• • 外部状态 —— 将任务状态写入文件并重新读取，而非依赖对话历史

10. State Desynchronization（状态去同步）

发生什么： Agent 对系统状态的心理模型偏离了实际系统状态。Agent 认为文件已被修改、进程正在运行、配置已应用——但现实不同。

机制： Agent 基于其观察维护一个隐式的系统状态模型。当系统在 Agent 观察之外发生变化（另一个进程修改了文件、部署被回滚、文件被清理删除），Agent 的模型就变得陈旧。Agent 基于其陈旧模型做决策，产生不正确的结果。

触发条件：

• • 对 Agent 正在使用的文件的外部修改
• • 并发进程（CI/CD 管道、其他 Agent、人类开发者）
• • 非确定性工具行为（一个命令有时成功有时失败）

平台特定表现形式：

在多 Agent 系统（MetaGPT、ChatDev、AgentScope）中，状态去同步是地方性的。Agent A 修改文件。Agent B 从其缓存中读取旧版本。Agent C 基于 Agent B 的陈旧信息行动。结果是经典的缓存一致性问题，但在语义层面而非硬件层面。

在活跃代码库上工作的 aider 中，当开发者在 Agent 工作时进行手动编辑，就会发生状态去同步。Agent 的下一个操作基于它上次读取的文件版本，而非当前版本。这导致补丁无法应用，或者更糟，应用错误。

在 OpenWorker 中，桌面集成意味着系统状态不断变化——用户打开应用、移动文件、接收消息。Agent 对"屏幕上是什么"或"存在哪些文件"的视图可能在几秒内就变得陈旧。

恢复模式：

• • 新鲜读取 —— 在修改文件前始终重新读取
• • 状态校验和 —— 追踪文件修改时间，当它们变化时使假设失效
• • 文件锁定 —— 协调对共享资源的访问

Group E: 系统架构

失败通过共享依赖和分布式组件级联传播。

11. Dependency Cascade（依赖级联）

发生什么： 一个工具或服务失败，失败通过 Agent 的依赖图级联，导致恰好共享依赖的不相关任务失败。

机制： Agent 任务不是隔离的——它们共享状态、上下文和外部服务。当 Agent 的文件系统访问失败（例如磁盘满），每个后续文件操作都会失败。当网络断开，每个 API 调用都会失败。Agent 可能将每个失败归因于不同的原因，导致诊断上的徒劳追逐。

触发条件：

• • 基础设施故障（磁盘、网络、DNS）
• • 共享外部服务（GitHub API、模型提供商）
• • 状态损坏（Agent 的记忆文件被损坏，影响所有后续读取）

平台特定表现形式：

在 AgentScope 中，分布式架构意味着一个节点上的故障可以级联到所有与之通信的 Agent。消息中心充当单点故障——如果它宕机，所有 Agent 都失去协调能力。

在任何使用 MCP 服务器的平台中，MCP 服务器崩溃会带走该服务器提供的所有工具。Agent 看到通用的"tool unavailable"错误，可能将其错误归因于自己的操作。

恢复模式：

• • 按依赖的熔断器 —— 依赖不可用时快速失败
• • 优雅降级 —— 主工具失败时切换到替代工具
• • 依赖隔离 —— 将故障隔离开以防止扩散

Group F: 验证与信任

Agent 对你撒谎——报告成功但并未实现。

12. Silent Success（静默成功）

发生什么： Agent 报告任务已成功完成，但输出是错误的、不完整的或根本没有实际执行。用户信任报告并继续，很久之后才发现失败。

机制： LLM 被训练为乐于助人和积极响应的。当被问及"你做了 X 吗？"时，模型的先验倾向是说"是"——不是因为它在撒谎，而是因为"是"是寻求确认问题的最可能响应。如果 Agent 没有实际验证结果，它会基于计划而非执行来报告成功。

触发条件：

• • Agent 工作流中缺失验证步骤
• • 不返回明确成功/失败信号的工具
• • 中间失败被吞没的长执行链

平台特定表现形式：

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

在 Copilot CLI 中，静默成功表现为"命令成功了"，而命令实际上不是正确的——它在项目使用 yarn 时运行了 npm install，命令成功了（npm 将包安装到了已有它们的项目中），但错误包管理器引入的依赖冲突将在几天后才显现。

在 Dify 中，可视化工作流可能在每个节点静默成功，而整体管道产生错误输出。每个节点返回 200 OK，但节点间的数据转换丢失信息（例如 JSON 字段被丢弃、日期被重新格式化）。工作流报告成功，因为没有节点抛出错误。

恢复模式：

• • 显式验证步骤 —— Agent 必须运行验证命令并检查其输出
• • 独立验证 —— 使用不同的模型或单独的验证步骤来检查结果
• • Hermes-Agent 的方法 —— verification-before-completion skill 模式：在声称成功之前，Agent 必须运行实际的验证命令并粘贴其输出

Group G: 安全

敏感数据通过 Agent 输出、日志和生成的文件泄漏。

13. Credential Leakage（凭据泄漏）

发生什么： Agent 在其输出、日志或生成的文件中暴露秘密——API key、密码、OAuth token。这可能通过将秘密包含在它编写的代码中、粘贴到 commit 消息中、或通过被记录的工具输出泄漏。

机制： Agent 可以访问包含秘密的环境变量、配置文件和工具输出。在编写代码或文档时，模型可能逐字将这些秘密复制到其输出中，尤其是在模型将秘密出现的上下文解释为"配置"的情况下。

触发条件：

• • 对 Agent 可见的环境变量（传递 API key 的标准模式）
• • 包含内联凭据的配置文件
• • 回显请求参数（包括 auth header）的工具输出

平台特定表现形式：

在 OpenClaw 中，Agent 有终端访问权限，可以读取 ~/.bashrc、~/.env 或 /etc/environment。如果 Agent 编写部署脚本，它可能将数据库密码作为字面字符串包含"为了方便用户"。

在 Hermes-Agent 中，terminal 工具暴露所有环境变量。Agent 可能通过 echo $API_KEY 或读取配置文件泄漏秘密。Hermes 通过 tirith 安全扫描来缓解这个问题，但扫描是事后进行的——它在泄漏发生后捕获，而非之前。

在 Dify 中，可视化工作流构建器将连接器凭据存储在其配置数据库中。如果用户导出工作流配置以与同事分享，导出可能包含以明文存储在节点配置中的 API key。

恢复模式：

• • 秘密脱敏 —— 在发送前扫描 Agent 输出中的已知秘密模式
• • 沙盒环境 —— 在容器中运行 Agent，仅包含它们需要的秘密
• • 审批门控 —— 对包含潜在秘密的输出要求人工审批（OpenWorker 的模式）

跨平台失败弹性分析

在编目了 34 个平台的失败模式后，不同架构处理失败的模式浮现出来。

最具弹性：审批门控桌面 Agent

OpenWorker 和 Hermes-Agent（带人在回路）最好地处理失败模式。审批门控为每个失败提供了自动恢复路径：当 Agent 出错时，人类在造成损害之前就能捕获它。这以自主性换取可靠性——Agent 不能无人值守运行，但它也不能螺旋坠入灾难性失败。

最脆弱：多 Agent 角色扮演系统

MetaGPT 和 ChatDev 是最容易失败的架构。多 Agent 角色层级造成通信开销（放大 Token 耗尽）、上下文碎片化（每个 Agent 只看到对话的一部分）和责任扩散（出了问题时，每个 Agent 都责怪另一个角色的输出）。角色扮演隐喻在 Demo 中很优雅，但在生产环境中很脆弱。

最佳工程实践：Claude Code / OpenCode

这些编码 Agent 通过工程严谨性处理失败：熔断器、上下文压缩、显式验证步骤和硬步骤限制。它们以可预测的、有界的方式失败，而非螺旋坠毁。

最大隐藏风险：可视化工作流平台

Dify 和 Coze Studio 将失败隐藏在友好的 UI 之后。在代码中显而易见的错误（类型不匹配、缺失字段）在可视化管道中变得不可见。平台在每个节点报告成功，而整体输出是错误的。这是被不透明性放大的 Silent Success（#12）。

恢复模式目录

关键洞察： 没有平台实现了全部九种恢复模式。大多数实现了 2-3 种。最佳实践与常见实践之间的差距就是大多数生产环境失败栖息的地方。

局限性和注意事项

观察偏差： 本分类法基于公开报告、GitHub issues 和我们自己的测试构建。静默发生的失败（用户不报告）被低估了。Silent Success（#12）可能比本报告所暗示的更为普遍，这恰恰因为它是静默的。

平台覆盖： 我们对某些平台（OpenClaw、aider、Hermes-Agent、MetaGPT）比对其他平台（AgentScope、Eliza、PraisonAI）有更深入的经验。对较少测试平台的失败模式描述是从架构分析推断的，而非直接观察。

快速演进： Agent 平台每周都在变化。此处描述的失败模式可能已在最新版本中修复。反之，我们尚未观察到的新失败模式可能已经出现。

单 Agent 偏差： 大多数公开的失败报告来自使用单 Agent 系统的个人开发者。多 Agent 失败模式（尤其是 State Desynchronization #10 和 Dependency Cascade #9）被低估，因为在生产环境中运行多 Agent 系统的人更少。

测试背景： 我们的测试主要针对编码任务（GitHub issue 解决、重构、测试编写）。其他任务类型（数据分析、文档生成、网络交互）的失败模式可能不同。

结论

Agent 失败不是异常——它是默认状态。我们构建的系统是包裹在确定性循环中的随机引擎，这两种范式之间的不匹配产生了本报告描述的 13 种失败模式。没有平台能免疫。没有架构能消除它们。

区分可靠 Agent 系统和不可靠 Agent 系统的不是没有失败，而是恢复的速度和有效性。在生产环境中运行最好的平台是那些快速失败、可见地失败、并为 Agent（或人类）提供纠正航向所需信息的平台。OpenWorker 的审批门控、Claude Code 的熔断器和 Hermes-Agent 的验证 skill 不是功能——它们是生存机制。

Agent 可靠性的下一个前沿不是更大的模型或更好的 prompt。而是更好的失败处理：正确分类失败的熔断器、保留任务相关信息同时丢弃噪声的上下文管理，以及在 Silent Success 传播之前捕获它的验证系统。构建这些生存机制的平台将是从 Demo 毕业到生产环境的平台。

AllClaws Research 报告 | 2026 年 7 月范围：34 个跟踪平台方法：源码分析、GitHub issue 挖掘、跨平台测试、社区报告汇总

🔗 资源

• • 失败模式分类报告原文^[1] — 英文原版
• • AllClaws 仓库^[2] — 34 平台跟踪，140 metrics，全部开源
• • 架构文档目录^[3] — 8 份双语架构分析文档

🐛 本译文翻译自 AllClaws 失败模式分类报告（2026 年 7 月）。原文为英文技术报告，本中文版作为技术参考发布。术语保留英文原文以方便对照。

引用链接

[1] 失败模式分类报告原文: https://github.com/dz3ai/allclaws/blob/main/docs/reports/failure-mode-taxonomy-2026.md[2] AllClaws 仓库: https://github.com/dz3ai/allclaws[3] 架构文档目录: https://github.com/dz3ai/allclaws/tree/main/architecture