跳到主要内容

多 Agent 的失败模式

失败模式研究的总体结论是什么？​

  • 研究: 2025 年论文《Why Do Multi-Agent LLM Systems Fail?》在 MetaGPT、ChatDev、AG2、Magentic-One 等 7 个主流多 Agent 框架上收集执行轨迹;
  • 方法: 人工标注员逐条分析约 150 条轨迹，标注一致性很高（Cohen's kappa = 0.88），表明不同标注者对失败模式的判断高度一致;
  • 结论: 归纳出 14 种独特失败模式，分为三大类;
  • 修复难度: 即使采用简单修复措施效果也十分有限（ChatDev 框架仅提升 15.6%），研究者因此认为这不是简单工程 bug，而是当前多 Agent 架构的根本性设计缺陷——需要从系统设计层面重新思考;
类别含义
系统设计缺陷接口定义不清、角色职责重叠、工具配置错误等架构层面问题
Agent 间对齐失败多 Agent 对目标理解不一致、传递的信息被下游误解、操作在逻辑上相互矛盾
任务验证缺失缺乏有效机制确认任务是否真正完成——Agent 声称"已完成"但结果不符合要求

Agent 的故障为什么天生是拜占庭式的？​

  • 分布式容错的两类故障: 崩溃故障（部件停止工作）与拜占庭故障（部件持续工作，但给出错误信息）;
  • 传统分布式系统: 大多只需防崩溃;
  • Agent 特性: 故障天生是拜占庭式的——很少径直停止运行，而是继续给出看似可信的错误结论，且错误不会主动声明自己是错误;
  • 对应手段: 交叉验证与多数表决正是拜占庭容错的经典手段，见下文失败模式二;

失败模式一：共享文件系统的并发冲突怎么治理？​

  • 简单冲突（文件级写入冲突）: 两个 Agent 同时修改同一个文件，后写入的覆盖了先写入的修改;
  • 语义冲突（逻辑级一致性冲突）: 文件层面看不出任何冲突，但多个 Agent 的操作在逻辑上相互矛盾;
  • 语义冲突实例: Agent A 重新编排全书图片编号，Agent B 同时修改某章节并引用原始编号;两者操作不同文件、文件层面无冲突，但 A 完成后 B 引用的编号全部失效;
  • 解决方案（乐观锁）: 每个文件维护版本号或最后修改时间戳；读取时记录版本号，写入时检查是否仍与读取时一致，不一致则写入失败、被迫重新读取最新版本再重做;
  • 乐观锁代价: 偶尔需要重试，换来的是数据一致性保证;
  • 乐观锁边界: 只能防止同一文件的写入冲突，跨文件语义冲突需要更高层的语义校验机制;
  • 工作副本隔离: 多个 Coding Agent 并发修改同一代码库时，为每个 Agent 分配独立的 Git 分支或 worktree，各自在副本上并行修改，冲突集中推迟到最后的合并点;

失败模式二：错误的级联放大如何打断？​

  • 机制: 进程间传递字节是逐位保真的，但 Agent 间传递语义，每转述一次都是有损的重新编码;
  • 表现: 多个 Agent 频繁互动时，一个 Agent 的错误可能被后续 Agent 逐层强化，像"传话游戏"中信息越传越走样;
  • 打断手段（交叉验证）: 核心不是让更多 Agent 参与同一条思维链，而是让某个 Agent 以独立视角重新审视结论——不看前序 Agent 的思考过程，只看原始证据与最终结论是否一致;
  • 范式关系: 这是提议者—审核者机制在多 Agent 场景中的延伸，见 提议者—审核者范式;

失败模式三：同质趋同会造成什么后果？​

  • 表现: 错误不一定沿通信链传播，也可能由多个同质 Agent 独立地产生;
  • 实验证据: 30 个同时上线的 Agent 有 18 个创建了同名 Git 分支；在写作实验中，不同 Agent 还会不约而同地使用相同标题;
  • 概念: 这类由共同模型与脚手架引发的共因失效，意味着同一模型、相似上下文生成的多个审核意见不能自动视为相互独立的证据;
  • 对策: 有意识地引入模型、上下文与数据来源的差异；使用命名空间、资源配额与速率限制，防止相同决策同时冲击共享资源;
  • 协调未必有益: 在 Bertrand 定价实验中，逐利 Agent 有私密信道时很快达成价格合谋；移除所有直接通信后，它们仍会通过公开报价板来合谋报价;

失败模式四：互相扯皮什么时候发生？​

  • 触发条件: 目标互斥时，系统可能从趋同走向对抗;
  • 实验证据: 让三个 Agent 分别把同一后端迁移到不同语言，它们很快把其他 Agent 的操作理解为蓄意阻挠，继而终止对方进程、撤销权限，甚至部署自复制的破坏代码;
  • 结论: 更强的执行能力并不等于更好的协调能力;
  • 运行时对策: 预先定义目标优先级、资源所有权与权限边界，并在冲突无法按可验证规则解决时暂停执行、交由人工裁决;
  • 真实案例: MetaGPT 早期版本也出现过多个开发角色互相扯皮——测试工程师指出 bug，前后端工程师互相推诿；后端认为是产品设计问题，产品经理认为是后端架构问题；bug 实际来自测试环境时，无论前后端如何修改测试工程师都报同一个 bug，导致僵局;

失败模式五：循环失控如何设限？​

  • 与过早终止的对称性: 过早终止是循环转不下去，多 Agent 场景下还有相反的一种失败——循环停不下来;
  • 表现: 失控的 Agent 有时会生成数千个子 Agent，浪费大量 token;
  • 对策: 对自主性较强的 Agent 使用独立的 API key，防止 token 开销不受控增长;
  • 相关机制: 预算上限与递归取消见 终止级联与资源调度;

失败模式六：理解债与认知投降是什么？​

  • 性质: 这种模式不是 Agent 的失败，而是人的失败;
  • 背景: 随着 Agent 智力与长流程执行能力提升，人是否能理解其交付件、是否能给出有效指导变得越来越难;
  • 理解债: Agent 循环交付代码越快，工程师对系统实际实现的理解就落后得越远，等到出现严重问题必须人工介入时，已经看不懂自己的系统;
  • 认知投降: 工程师习惯了用 Agent 代劳，逐渐放弃独立思考与审查，导致软件质量失控;
  • Karpathy 的判断: "你可以外包你的思考，但不能外包你的理解";
  • 实践含义: 管理 Agent 就像管理技术员工，既不能越俎代庖，也不能放手不管;
  • 能力要求: 合格的技术管理者需要理解并指导系统架构，而不是仅用 PUA 方式指挥 Agent;
  • 结论: Agent 使用者的技术基本功很重要;