在Why Do Multi-Agent LLM Systems Fail?论文地址:https://arxiv.org/pdf/2503.13657
邀请了多位人类专家，仔细审查了来自 5 个不同 MAS 系统的 150 多个任务执行记录（每个记录平均包含超过 15000 行文本，主要是智能体之间的对话和行动日志）。反复阅读、标记、讨论这些记录中的失败点，不断提炼和归纳，最终形成了一套包含 14 种具体失败模式的分类法，并将其归纳为三大类。

image.png

类别一：规范与系统设计失败 (Specification and System Design Failures, 占总失败的 37.17%)

这类失败源于系统设计本身的缺陷、任务指令的不明确、或者智能体未能遵循其角色和职责。就像一个项目团队，如果项目目标模糊、成员职责不清、工作流程混乱，那么失败几乎是注定的。

FM-1.1: 不遵从任务规范 (Disobey task specification, 15.2%):

智能体未能遵守任务的具体要求或约束。

举个栗子：要求ChatDev开发一个使用标准国际象棋记谱法（如'Ke8', 'Qd4'）作为输入的两人象棋游戏，但它最终生成的游戏却要求输入棋子移动前后的坐标 (x1, y1), (x2, y2)，完全不符合要求。

FM-1.2: 不遵从角色规范 (Disobey role specification, 1.57%):

智能体越俎代庖，做了超出其角色定义的事情。

举个栗子：在ChatDev的需求分析阶段，扮演“产品官”(CPO)角色的智能体有时会跳过与“CEO”的讨论，单方面定义产品愿景并做出最终决定，这显然超出了CPO的职责。

FM-1.3: 步骤重复 (Step repetition, 11.5%):

不必要地重复已经完成的步骤，导致延迟或错误。

举个栗子：HyperAgent中的“导航员”智能体反复提出相同的查找代码的步骤，即使之前已经尝试过或问题已转移。

FM-1.4: 对话历史丢失 (Loss of conversation history, 2.36%):

系统意外地截断了上下文，导致智能体忘记了最近的交互内容，行为回退到之前的状态。

举个栗子：HyperAgent在解决一个编程bug时，一开始决定用scikit-learn模型替换所需的lightgbm库（因为未安装），但在后续交互中，它似乎忘记了这个决定，又回过头来尝试安装lightgbm。

FM-1.5: 不清楚终止条件 (Unaware of termination conditions, 6.54%):

智能体不知道或不理解何时应该结束交互，导致不必要的对话持续进行。

举个栗子：在AG2解决一个数学问题时，即使已经给出了正确（或无法解决）的答案，代理仍然反复要求继续进行，不明白任务已经结束。

类别二：智能体间协作失调 (Inter-Agent Misalignment, 占总失败的 31.41%)

这类失败发生在智能体之间的沟通和协作环节。即使每个智能体单独看都很“聪明”，但如果它们之间沟通不畅、目标冲突、互相误解，团队整体表现也会大打折扣。这就像一个团队，成员间缺乏有效的沟通机制，导致信息壁垒、重复劳动、甚至内耗。

FM-2.1: 对话重置 (Conversation reset, 5.50%):

对话意外或无理由地重新开始，丢失了之前的上下文和进展。

FM-2.2: 未能请求澄清 (Fail to ask for clarification, 2.09%):

面对模糊或不完整的信息时，智能体没能主动要求更多信息，而是基于猜测行动，导致错误。

举个栗子： AppWorld 中的“主管”智能体指示“电话”智能体使用邮箱地址作为用户名登录，但 API 文档明确需要电话号码。“电话”智能体发现了这一点，却没有向主管澄清，而是直接用错误的邮箱地址尝试登录，导致失败。同时，“主管”智能体在提供指令时也未能检查或询问细节。

FM-2.3: 任务偏离 (Task derailment, 5.50%):

对话或行动逐渐偏离了最初设定的任务目标，变得无关紧要或效率低下。

举个栗子： AG2在解决一个数学问题时，可能中途被某个计算细节带偏，开始解决一个完全不同的问题，或者在找到正确答案后又继续进行不相关的计算。

FM-2.4: 信息隐瞒 (Information withholding, 6.02%):

某个智能体掌握了对任务至关重要的信息，但未能与其他智能体分享。

举个栗子：HyperAgent 的“导航员”有时找到了潜在解决方案，但没有将其完整传达给“规划师”，导致后者无法做出正确决策。

FM-2.5: 忽略其他智能体输入 (Ignored other agent's input, 4.71%):

智能体无视或未能充分考虑其他智能体提供的输入、建议或修正。

举个栗子： 在Multi-Agent Peer Review系统中，一个智能体收到了另一个智能体对其数学解题过程的正确反馈，指出了计算错误。该智能体口头上承认了反馈，但在最终答案中仍然坚持自己最初的错误结果，没有采纳正确的修正。

FM-2.6: 推理-行动不匹配 (Reasoning-action mismatch, 7.59%):

智能体的内在“思考”（推理过程）与其最终采取的“行动”（如调用工具、生成代码）不一致。

举个栗子： HyperAgent 的“导航员”在分析一个 pylint 的 bug 时，其内部思考过程（Thought）正确地识别了问题所在和需要修改的代码位置，但在最终给“规划师”的“回答”（Final Answer）中，却给出了不同的、甚至是无关的建议。

类别三：任务验证与终止失败 (Task Verification and Termination, 占总失败的 31.41%)

这类失败关乎任务的“收尾”阶段：如何确保最终结果的质量（正确性、完整性、可靠性），以及如何在恰当的时机结束任务。缺乏有效的质量控制和明确的结束机制，可能导致交付低劣成果或资源浪费。

FM-3.1: 过早终止 (Premature termination, 8.64%):

在所有必要信息交换完毕或目标达成之前，对话、交互或任务就被结束了。

举个栗子：HyperAgent 的“编辑器”智能体声称已经完成了对代码的修改，但实际上并没有执行修改操作，却提前结束了自己的任务环节，导致后续依赖该修改的步骤失败。

FM-3.2: 无验证或验证不完整 (No or incomplete verification, 9.16%):

系统缺少验证步骤，或者验证步骤未能覆盖所有关键方面，导致错误或不一致被遗漏。

举个栗子： ChatDev 在实现国际象棋游戏时，负责验证的智能体只检查了代码是否能编译通过，却没有实际运行游戏、检查是否符合所有象棋规则（如特殊移动、吃子规则等），也没有验证输入输出是否符合任务要求。这导致即使代码能运行，游戏本身也可能漏洞百出或无法正常玩。AG2 在数学题中可能算对了总花费，但在需要计算剩余金额时却没有进行减法验证，或者数错了题目中给出的数字个数。

FM-3.3: 验证不正确 (Incorrect verification, 13.61%):

存在验证步骤，但验证本身是错误的或无效的，未能发现实际存在的问题。

举个栗子： MetaGPT 在实现棋类游戏时，单元测试可能只覆盖了最基本的情况（如兵的移动），没有覆盖非兵棋子的复杂移动规则，却错误地认为验证通过。Multi-Agent Peer Review 中，智能体在评审同伴的解答时，可能自己也犯了同样的错误，或者未能识别出明显的逻辑漏洞，给出了错误的“验证通过”结论。

解决思路

FM-1：系统规约失败

阶段一：预分析

• 任务接收Agent（Leader）在接收到自然语言任务后，不立即执行；
• 它会先分析任务目标、判断已知信息与需补全的信息；
• 例如在“升级某项目到JDK 11”的任务中，预分析会识别：
  • 当前JDK版本；
  • 项目使用的构建工具（如Maven）；
  • 项目中使用了哪些可能不兼容的类。

阶段二：隐性数据收集

• 系统自动爬取任务相关的“隐性上下文”，如：
  • pom.xml 文件内容；
  • 实际部署环境信息；
  • 日志和依赖版本；
  • 与JDK升级相关的内部知识库链接。

阶段三:模型驱动任务拆解

有了完整上下文后，LLM才参与生成任务步骤；
避免“上下文盲区导致错误规划”。

FM-2：协作失调

事件驱动通信机制：

• 所有Agent的动作、状态变化、思考结果都会发布为事件；
• 其他Agent可订阅感兴趣的事件类型；
• 事件记录在统一的日志中心，可用于追踪、回放和调试；
• 所有事件都具备类型、发起者、时间戳、载荷数据，利于重建上下文。

共享记忆管理：统一Agent认知，消除信息不对称

冲突检测与澄清机制：引导Agent主动提问，避免错误假设

• 在预分析阶段，Leader Agent会提取任务中可能引发歧义的部分，例如：
  • 用户只说“升级”，未指定JDK版本；
  • 项目中多个模块版本不一致，目标不明确；
  • Leader可在任务早期通过User Agent发起澄清对话，避免错误启动任务；
• 在任务执行阶段，每一步操作都由“观察-反思-评分”机制包裹；
• 如果某Agent的行为偏离计划，系统会触发异常标记，并反馈给Router重新评估是否需要：
  • 回退操作；
  • 更换执行者；
  • 人工介入。

FM-3：验证缺失

整体目标不是“100%不出错”，而是“错误能识别、能回退、能吸取教训”，实现MAS的自我演进能力。构建了一套覆盖执行前、执行中、执行后的验证机制。

工具服务内置预检：每一步操作都有“入口检查”

工具服务（Tool Service）在每次Agent调用工具时，都会先进行参数验证与环境可用性检测：

• 如果调用Web搜索：检查URL、关键词有效性；
• 如果调用Rewrite Plugin：验证环境变量（如Java版本）是否设置；
• 如果调用Maven命令：先执行mvn -v检查版本与配置。

反思评分机制：让Agent自己判断“做得对不对”

Agent每个执行步骤之后都会执行一轮标准化的反思评分流程（类似AutoGPT中的Reflect + Evaluate）：

• Agent会被要求：
  • 描述执行动作；
  • 观察结果；
  • 评估是否达到预期目标；
• 系统会对比预期与实际，给出评分（如0~1）；
• 若评分低于设定阈值，会触发两种后续动作：
  • 任务重试：最多重试1~2次；
  • 路径回退：回到上一个安全步骤，由Router重新选择Agent或请求用户反馈。

可插拔验证Agent机制：为不同任务定制验证标准

很多任务的验证无法靠简单“成功/失败”来评判，比如：

• 文档生成是否准确；
• 代码修改是否正确；
• 环境是否符合安全规范。
  为此，允许系统中引入专用的验证Agent

系统层级的容错机制：验证不仅是功能，更是策略

• 执行指标监控：包括步骤执行时长、系统CPU占用、任务收敛进度等；
• 异常检测模块：持续监听是否出现死循环、长时间无进展、内存爆炸等风险；
• 终止策略：超过容忍阈值后自动中止任务，并输出当前状态供分析；
• 用户确认机制：任务执行中可多次请求用户确认结果，避免盲目推进。