这篇论文来自 UC Berkeley 的研究团队，成员包括 Mert Cemri、Melissa Z. Pan、Shuyi Yang 等，通讯作者为 Ion Stoica 和 Joseph E. Gonzalez。核心问题是：为什么多智能体 LLM 系统（Multi-Agent LLM Systems, MAS）的表现往往还不如单智能体？

研究团队提出了 MAST（Multi-Agent System Failure Taxonomy）——首个基于实证数据的多智能体系统失败模式分类体系。他们分析了 7 个主流 MAS 框架的 200+ 条执行轨迹，识别出 14 种失败模式，归类为 3 大类别：规格说明问题、智能体间对齐失败、任务验证缺失。

论文链接：https://arxiv.org/abs/2504.12767

一个让人尴尬的现实：多智能体不一定比单智能体强

多智能体 LLM 系统这两年火得不行。从软件工程到药物发现，从科学仿真到通用任务处理，似乎只要把多个 LLM 智能体拼在一起，就能解决一切复杂问题。

但实际表现呢？相当拉胯。

研究团队统计了 6 个主流 MAS 在不同 benchmark 上的失败率，结果不太好看。以 ChatDev 为例，在 ProgramDev benchmark 上使用 GPT-4o 的正确率只有 33.33%——也就是说，三分之二的软件生成任务直接失败。MetaGPT 的表现稍好一些，但失败率仍然居高不下。

更有意思的是，Kapoor 等人（2024）的研究表明，简单的 best-of-N 采样（多试几次取最好的）在很多任务上就能匹敌甚至超越精心设计的 MAS。那多智能体的「集体智慧」到底体现在哪里？

这个落差促使研究团队提出了一个根本性的问题：MAS 到底为什么会失败？不是泛泛地问，而是要把失败的模式一个一个揪出来，分好类，弄清楚。

研究方法：扎根理论 + 迭代式标注

要搞清楚 MAS 的失败模式，直接拍脑袋想是不行的。研究团队采用了社会科学中经典的扎根理论（Grounded Theory）方法——从数据中归纳理论，而不是先假设再验证。

具体来说，他们做了这么几件事。

首先，收集数据。团队选取了 7 个有代表性的开源 MAS 框架：MetaGPT、ChatDev、HyperAgent、AppWorld、AG2、Magentic-One 和 OpenManus。这些系统覆盖了不同的架构模式——流水线式、层次式、星形拓扑等，任务类型也各不相同，包括软件开发、工具调用、数学推理等。每个系统的执行轨迹平均超过 15000 行文本，总共产出了 200 多条轨迹。

然后，六位有 Agent 系统经验的标注者对这些轨迹进行开放式编码（Open Coding）。标注者逐条分析智能体之间的对话和交互，识别其中的失败点，并不断比较、归类。这个纯标注过程每人花了超过 20 小时。

但光有初始分类还不够。一个好的分类体系必须满足一个条件：不同的人用它来标注同样的轨迹，结论应该基本一致。

为此，团队进行了三轮标注者间一致性（Inter-Annotator Agreement, IAA）实验。第一轮，三位标注者独立标注 5 条轨迹，Cohen’s Kappa 只有 0.24——几乎没共识。这说明初始分类太模糊了。于是大家坐下来反复讨论，调整失败模式的定义、拆分或合并类别，然后再用新的 5 条轨迹测试。第二轮达到了 0.92，第三轮 0.84。Cohen’s Kappa 超过 0.8 被认为是强一致性，超过 0.9 则是近乎完美。

为了验证 MAST 的泛化能力，团队还把最终的分类体系应用到了两个全新的 MAS（Magentic-One 和 OpenManus）以及全新的 benchmark（GAIA 和 MMLU）上，这些数据和系统都没参与过分类体系的开发。结果 Cohen’s Kappa 达到了 0.79，说明 MAST 的失败模式定义是靠谱的。

此外，团队还开发了一个基于 LLM 的自动标注管线（LLM-as-a-Judge），使用 OpenAI 的 o1 模型配合 few-shot 示例，在准确率上达到了 94%，与人类标注者的 Cohen’s Kappa 为 0.77。这使得大规模自动化分析 MAS 失败模式成为可能。

MAST：14 种失败模式，3 大类别

经过扎根理论分析和迭代式精炼，MAST 最终识别出 14 种细粒度失败模式，归入 3 个高层类别。

FC1：规格说明问题（41.77%）

这是最大的一类失败，根源在系统设计和 prompt 规格上。具体包括：

• 未遵循任务要求（FM-1.1, 10.98%）：智能体没有按照用户的指令执行任务。比如让 ChatDev 做一个「标准的每日 Wordle 游戏」，生成的程序却用了固定的词库，完全忽略了「每日更换」的隐含需求。即使研究者把 prompt 写得更明确——「不要使用固定词库，每天随机选择一个新词」——ChatDev 仍然生成了固定词表，还引入了新的 bug。

• 步骤重复（FM-1.3, 17.14%）：智能体反复执行相同的操作。这在 HyperAgent 中尤为严重，占了其失败模式的相当大比例。很多时候是因为系统设计中轮次配置过于死板。

• 未识别任务完成（FM-1.5, 9.82%）：任务明明已经做完了，智能体还在继续操作。

• 上下文丢失（FM-1.4, 3.33%）和未遵循角色定义（FM-1.2, 0.5%）。

有意思的是，研究团队发现，规格说明失败不能简单归咎于「模型不听话」。它的深层原因至少有四个：MAS 架构设计缺陷、用户 prompt 不够清晰、底层 LLM 理解能力有限、以及 LLM 理解了指令但执行时跑偏。一个设计良好的 MAS 应该能从高层规格中推断出合理的细节，而不是要求用户把每一步都写得清清楚楚。

FC2：智能体间对齐失败（36.94%）

这类失败发生在执行过程中，涉及智能体之间的协调和通信问题。

• 推理与行动不匹配（FM-2.6, 13.98%）：智能体的推理过程和实际采取的行动对不上。它想的是一回事，做的是另一回事。

• 基于错误假设继续推进（FM-2.2, 11.65%）：智能体遇到不确定的信息时，不去求证，而是直接假设一个答案然后往下走。

• 任务跑偏（FM-2.3, 7.15%）：对话过程中话题逐渐偏离了原始目标。

• 信息隐瞒（FM-2.4, 1.66%）：智能体掌握了关键信息却不告诉其他智能体。论文中给了一个很生动的例子：在一个 AppWorld 任务中，Phone Agent 知道用户名格式要求，但没有把这个信息传递给 Supervisor Agent。Supervisor 按照自己的猜测反复尝试登录，失败一次又一次，最终整个任务以失败告终。

FC2 的诊断特别复杂。表面看起来一样的症状，背后可能是完全不同的根因。比如「信息缺失」可能是因为智能体故意隐瞒（FM-2.4），也可能是忽略了他人的输入（FM-2.5），还可能是上下文太长导致的信息丢失（FM-1.4）。MAST 的细粒度分类正是为了区分这些不同的根因。

FC3：任务验证缺失（21.30%）

最后一类失败涉及验证环节：系统没能检测到错误，或者过早地宣告任务完成。

• 过早终止（FM-3.1, 7.82%）：任务还没做完就停了。

• 验证不完整或缺失（FM-3.2, 6.82%）：验证器只做了表面检查——比如检查代码是否能编译、注释是否完整——但不去验证程序是否真的能正确运行。ChatDev 生成的象棋程序就是个典型：通过了所有验证轮次，但实际上会接受非法的走棋。

• 错误验证（FM-3.3, 6.66%）：验证器给出了错误的判断，把有问题的输出标记为通过。

验证失败占所有失败的 13.48%（FM-3.2 + FM-3.3）。有验证器的系统（如 MetaGPT、ChatDev）确实比没有验证器的系统总失败率更低，但验证器绝不是万能药。ChatDev 有完整的验证流程，在 ProgramDev 上依然只有 33.33% 的正确率。

系统设计 > 模型能力：干预实验的证据

MAST 不仅仅是一个分类体系，它还能指导实际的 MAS 开发。

研究团队做了两组干预实验来验证这一点。

第一组针对角色规格说明。团队根据 MAST 识别出的 FM-1.2（未遵循角色定义）模式，改进了 ChatDev 中各智能体的角色描述。结果在同样的 LLM（GPT-4o）和同样的用户 prompt 下，成功率提升了 9.4%。

第二组针对验证流程。团队在 ChatDev 中增加了一个面向高层任务目标的验证步骤，补充现有的代码级检查。这个改动带来了 15.6% 的绝对成功率提升。

这些结果说明了一个关键问题：MAS 的失败不仅仅是底层 LLM 能力不够。同样的模型、同样的用户输入，仅仅通过改善系统设计就能获得显著提升。换句话说，即使未来的 LLM 变得更强，如果系统架构设计有问题，多智能体系统仍然会失败。

这其实和组织管理的道理是一样的。一群聪明人聚在一起，如果组织结构混乱、沟通机制有缺陷，照样会把事情搞砸。Charles Perrow 在《Normal Accidents》中早就指出过：即使个体能力很强，如果组织结构有缺陷，灾难性失败照样会发生。高可靠性组织（High-Reliability Organizations）的研究也表明，明确定义的设计原则才能防止这类失败。

当然，干预实验也揭示了一个更深层的问题。虽然改进带来了统计学上显著的提升，但并非所有失败模式都被消除了，任务完成率在原本就表现不错的任务上提升有限，在困难的任务上依然偏低。要实现高可靠性，可能需要在智能体组织、通信协议、上下文管理和验证集成等层面做更根本性的改动。

各系统失败画像：每个 MAS 都有自己的「病」

MAST 的另一个价值在于，它能画出每个 MAS 系统的「失败画像」——不同系统在不同失败模式上的分布差异很大。

AppWorld 主要受「过早终止」（FM-3.1）困扰。OpenManus 的核心问题是「步骤重复」（FM-1.3）。HyperAgent 同时受「步骤重复」（FM-1.3）和「错误验证」（FM-3.3）影响。这些差异反映了系统架构设计的不同侧重点和不同缺陷。

三个主要失败类别之间的相关性很低（0.17-0.32），说明它们捕获的是 MAS 失败的不同维度。这不是一个类别的失败换个名字又出现一次，而是真正独立的问题领域。

不过，细粒度的失败模式之间存在中等程度的相关性（最高 0.63），这意味着症状相似的失败可能来自不同的根因。这也是为什么需要 MAST 这种细粒度分类的原因。

还有一个被忽略的问题：效率

在开发 MAST 的过程中，团队主要关注了任务正确性和完成度，这是 MAS 可用的基本前提。但他们观察到一个显著但未被纳入分类的现象：效率低下。

论文中举了一个很极端的例子。在 AppWorld 的一个任务中，要求获取播放列表中的前 10 首歌。协调者和 Spotify 智能体来回对话了 10 轮，一次取一首歌。而 Spotify 智能体的 API 完全支持一次性获取所有 10 首。

这种低效不是个例。不必要的长对话、迂回的执行路径，在某些场景下会导致成本（token 用量）和延迟（运行时间）增加 10 倍甚至更多。

团队在迭代精炼 MAST 时故意排除了效率维度以保持聚焦，但他们承认，效率、成本、鲁棒性、可扩展性和安全性这些维度对 MAS 的实际部署同样关键。

总结

MAST 是第一个基于实证数据的多智能体 LLM 系统失败模式分类体系。它不是闭门造车的产物，而是来自对 200 多条真实执行轨迹的扎实分析。

14 种失败模式、3 大类别，覆盖了从系统设计到执行协调再到质量验证的完整链条。每个失败模式都有清晰的定义和边界，标注者间一致性达到 0.88，在未见过的系统和任务上也能保持 0.79 的一致性。

三个核心发现值得记住：

• MAS 的失败主要来自系统设计问题，而非单纯的模型能力不足。同样的 LLM 和同样的 prompt，改善系统设计就能带来显著提升。
• 验证器是必要的，但远远不够。当前的验证器大多只做表面检查，无法确保深层正确性。
• 不同 MAS 的失败画像差异巨大，需要针对性的诊断和修复，而不是一刀切的优化方案。

未来，如何将这些失败模式转化为具体的系统设计原则，如何在保证正确性的同时兼顾效率，如何构建更鲁棒的智能体间通信协议——这些都是值得深入探索的方向。

团队已开源全部数据集、标注和 LLM 标注管线，地址：https://github.com/mertce/why-do-mas-fail