本文深入探讨了大型语言模型（LLM）驱动的多智能体系统（MAS）中普遍存在的失败模式。尽管MAS在软件工程、药物发现和科学模拟等领域展现出巨大潜力，但其在主流基准测试中的性能提升却往往微乎其微。为了系统性地分析阻碍MAS有效性的挑战，《Why Do Multi-Agent LLM Systems Fail?》文提出了MAST（Multi-Agent System Failure Taxonomy），这是首个基于实证的MAS故障分类法。通过对七个流行MAS框架的200多个任务进行分析，识别出14种独特的故障模式，并将其归纳为三大类：规范问题、智能体间错位和任务验证。MAST的构建经过严格的标注者间一致性研究，并集成了一个经过验证的“LLM即评判者”评估流程。我们的研究结果表明，这些故障需要更复杂的解决方案，强调了系统设计在MAS成功中的关键作用，并为未来的研究指明了清晰的路线图。

多智能体LLM系统的崛起与挑战

近年来，基于大型语言模型（LLM）的智能体系统在人工智能领域引起了前所未有的关注。这些智能体系统因其能够处理复杂、多步骤的任务，并能与多样化的环境进行动态交互而备受瞩目，这使得它们在解决现实世界问题方面展现出巨大潜力。例如，多智能体系统（MAS）已被广泛应用于软件工程、科学模拟以及通用智能体等多个领域。

然而，尽管对多智能体LLM系统抱有极大的期待值，但一个令人困惑的现象是，与传统的单智能体框架相比，它们在主流基准测试中的性能提升往往微乎其微。这种性能差距凸显了对阻碍MAS有效性的挑战进行系统性分析的迫切需求。为了解决这一核心问题，本文提出了MAST（Multi-Agent System Failure Taxonomy），这是首个基于实证研究的MAS故障分类法。通过对七个具有代表性的MAS框架（包括MetaGPT, ChatDev, HyperAgent, AppWorld, AG2, Magentic-One）进行深入分析，涵盖了200多个任务，并由六位经验丰富的专家参与人工标注。在此过程中，成功识别出14种独特的故障模式，并将它们归纳为三大类：
(i) 规范问题（Specification Issues）
(ii) 智能体间错位（Inter-Agent Misalignment）
(iii) 任务验证（Task Verification）

图：使用 GPT-4o 和 Claude-3 的六种常用多代理 LLM 系统的故障率。性能是在不同的基准上测量的，因此不能直接比较。

MAST的构建过程是严谨而迭代的，通过多轮严格的标注者间一致性研究（Inter-Annotator Agreement, IAA），最终实现了高达0.88的Cohen’s Kappa分数，这表明了其高度的可靠性和通用性。为了进一步支持可扩展的评估，作者还开发并验证了一个创新的“LLM即评判者”（LLM-as-a-Judge）评估管道，并将其与MAST无缝集成。通过两个具体的案例研究，清晰地展示了MAST在分析MAS故障和指导其开发方面的实际应用价值。研究结果明确指出，已识别的故障并非仅仅通过简单的修补就能解决，而是需要更深层次、更复杂的系统性解决方案，这为未来的MAS研究指明了清晰而关键的路线图。

MAST：多智能体系统故障分类法

MAST的构建方法

为了深入理解MAS的故障根源，研究采用了扎根理论（Grounded Theory）研究方法，对MAS的执行轨迹进行了首次系统性评估。作者精心挑选了7个在开源社区中广受欢迎的MAS框架，并收集了超过200个对话轨迹进行分析。每个轨迹平均包含超过15,000行文本，涵盖了多样化的任务场景。为了确保分析的全面性和客观性，还邀请了六位经验丰富的专家参与数据标注。

在扎根理论的指导下，将故障定义为MAS未能实现预期任务目标的任何实例。为了保证标注的一致性和可靠性，三位标注者独立对15个轨迹进行了交叉标注，并计算了标注者间一致性（Inter-Annotator Agreement, IAA），最终取得了高达0.88的Cohen’s Kappa分数，充分证明了标注过程的严谨性。

通过这项全面的分析，从海量数据中提炼并识别出14种独特的故障模式，并根据其内在关联性，将它们归纳为三大核心类别。这些故障模式共同构成了多智能体系统故障分类法（MAST），这也是首个针对MAS故障的结构化分类法。值得强调的是，MAST的开发并非一蹴而就，而是一个迭代且严谨的过程，需要对故障边界进行清晰、可推广的定义。我们承认MAST可能无法涵盖所有潜在的故障模式，但它无疑为统一理解MAS故障奠定了坚实的基础。

为了进一步提升故障分析的效率和可扩展性，作者创新性地开发了一个基于LLM的“LLM评判者”（LLM-as-a-Judge）评估管道。该管道能够自动化地识别和诊断MAS故障。通过与专家人工标注的对比，对该管道的可靠性进行了严格验证，取得了0.77的Cohen’s Kappa一致性分数。为了验证MAST的通用性和泛化能力，作者将其应用于两个额外的MAS（Magentic-One和OpenManus）以及两个新的基准测试（GAIA和MMLU），这些MAS和基准测试均未参与MAST的初始开发。在这些未曾见过的领域和基准测试上，依然取得了高达0.79的Cohen’s Kappa标注者间一致性，这有力地证明了MAST的广泛适用性。

MAST的故障类别与模式

MAST将多智能体系统的故障模式分为三大核心类别，并进一步细化为14种具体的故障模式。这些故障模式的发生贯穿于智能体间对话的不同阶段：执行前（Pre Execution）、执行中（Execution）和执行后（Post Execution）。

图：MAST： MAS 故障模式分类法。代理间对话阶段表明端到端 MAS 系统何时可能出现故障。如果故障模式跨越多个阶段，则表示问题涉及或可能发生在不同阶段。百分比表示每种故障模式和类别在对 200 多条跟踪记录的分析中出现的频率

规范问题 (Specification Issues)

-占总故障的41.77%： 这类问题主要源于系统设计层面，智能体未能正确理解或遵循任务和角色规范，导致行为与预期不符。

• 不遵守任务规范 (Disobey Task Specification) - 10.98%： 智能体未能按照既定任务目标或用户指令行事。例如，在MetaGPT实现国际象棋的任务中，智能体未能覆盖非兵棋子的移动限制，导致任务规范未被完全遵守。

• 不遵守角色规范 (Disobey Role Specification) - 0.50%： 智能体未能按照其被分配的角色职责行事。例如，HyperAgent中的Navigator智能体在不被要求的情况下思考解决方案，但却没有将其传达给Planner，这违反了其角色规范。

• 步骤重复 (Step Repetition) - 17.14%： 智能体重复执行相同的步骤或陷入循环，导致效率低下和资源浪费。例如，在AppWorld的一个轨迹中，智能体为了获取播放列表中的10首歌曲，竟然进行了10轮对话，每次只获取一首，尽管其能力允许一次性获取全部10首。

• 对话历史丢失 (Loss of Conversation History) - 3.33%： 智能体未能有效保留或利用之前的对话信息，导致上下文丢失和重复提问。

• 未意识到终止条件 (Unaware of Termination Conditions) - 9.82%： 智能体未能识别任务完成或无法继续的条件，导致无限循环或不必要的尝试。例如，AG2在解决一个无解的数学问题时，即使答案已经明确，mathproxyagent仍然不断要求Assistant“继续解决问题”。

智能体间错位 (Inter-Agent Misalignment)

-占总故障的36.94%： 这类问题主要发生在智能体之间的协调和沟通层面，反映了多智能体系统内部协作的挑战。

• 对话重置 (Conversation Reset) - 2.33%： 智能体间的对话意外重置，导致之前积累的上下文信息丢失，需要重新开始。

• 未能请求澄清 (Fail to Ask for Clarification) - 11.65%： 智能体在面对不明确或缺失信息时，未能主动寻求澄清，而是基于不完整信息继续操作，导致错误。例如，AppWorld中Spotify Agent要求提供访问令牌，而Supervisor Agent直接尝试使用密码作为令牌，但未能意识到这需要进一步澄清。

• 任务脱轨 (Task Derailment) - 7.15%： 智能体偏离了主要任务目标，转而处理不相关的问题或次要细节，导致主任务无法完成。例如，AG2在解决一个数学问题时，在给出正确答案后，又开始解决另一个完全不相关的问题。

• 信息隐藏 (Information Withholding) - 1.66%： 智能体未能向其他需要该信息的智能体共享必要的、关键的信息。例如，在图5中，Phone Agent未能将API要求的用户名格式（应为电话号码）告知Supervisor Agent，导致登录失败。

• 忽略其他智能体输入 (Ignored Other Agent’s Input) - 7.82%： 智能体未能有效处理或响应其他智能体的输入，导致信息传递中断或协作失败。例如，在多智能体同行评审任务中，一个智能体虽然承认另一个智能体给出的解决方案是正确的，但却忽略了这一事实，并坚持自己的错误解决方案。

• 推理-行动不匹配 (Reasoning-Action Mismatch) - 0.17%： 智能体的实际行动与其内部推理或计划不一致。例如，HyperAgent中的Navigator智能体已经找到了Pylint bug的解决方案，但却向Planner智能体提供了不相关的信息，导致行动与推理脱节。

任务验证 (Task Verification)

-占总故障的21.30%： 这类问题主要与系统对任务完成情况的质量控制和结果验证有关，反映了MAS在自我纠错和确保输出质量方面的不足。

• 过早终止 (Premature Termination) - 13.98%： 智能体在任务未完全完成或未达到预期目标时过早地终止执行。

• 无或不完整验证 (No or Incomplete Verification) - 6.82%： 智能体未能对任务结果进行充分或全面的验证，导致潜在错误未被发现。例如，AG2在解决数学问题时，混淆了鱼的数量和价格，并且没有对最终答案进行验证。

• 错误验证 (Incorrect Verification) - 6.66%： 智能体对任务结果进行了错误的验证，导致误判，认为错误的结果是正确的。例如，MetaGPT在实现国际象棋时，初始测试未能覆盖非兵棋子的移动限制，并且缺乏对完整国际象棋规则的验证，导致错误验证。

实验分析与关键发现

多智能体系统失败率概览

尽管多智能体系统（MAS）的应用日益增多，但令人沮丧的事实是，与单智能体框架或简单的基线（如best-of-N采样）相比，它们的性能提升往往微乎其微。实证分析揭示了即使是最先进的（SOTA）开源MAS也普遍存在高失败率。例如，ChatDev（一个旨在通过多智能体协作进行软件开发的系统）在ProgramDev基准测试中仅实现了33.33%的正确率，这意味着其在三分之二的任务中都未能成功完成。这一发现促使我们深入探讨一个根本性问题：为什么MAS会失败？

图：按类别和系统划分的故障模式分布。由于故障是在不同的任务中检测到的，因此在定量意义上，不同的 MAS 之间的结果无法直接比较。不过，对于每种 MAS，我们都可以分析故障在三大类别和 14 种特定故障模式中的分布情况。

具体来看：

• MetaGPT (ProgramDev): 成功率仅为40.0%，失败率高达60.0%。这表明在程序开发任务中，MetaGPT在大多数情况下未能达到预期。

• ChatDev (ProgramDev): 成功率33.3%，失败率66.7%。与MetaGPT类似，ChatDev在软件开发场景中也面临严峻的挑战。

• HyperAgent (SWE-Bench Lite): 成功率25.3%，失败率74.7%。在解决软件工程问题方面，HyperAgent的表现不尽如人意，四分之三的任务都以失败告终。

• AppWorld (Test-C): 成功率13.3%，失败率86.7%。这是所有测试系统中失败率最高的，表明其在特定测试场景下存在严重缺陷。

• AG2 (OlympiadBench): 成功率59.0%，失败率41.0%。尽管AG2的成功率相对较高，但仍有超过四成的任务未能成功，显示出其在奥林匹克数学问题解决方面的局限性。

• Magentic-One (GAIA): 成功率38.0%，失败率62.0%。在通用AI智能体基准测试GAIA上，Magentic-One也未能展现出令人信服的性能。

这些数据共同强调了对MAS故障进行系统性分析的紧迫性，并为MAST的提出提供了强有力的实证支持。它们清晰地表明，当前MAS的性能瓶颈并非仅仅是底层LLM能力的不足，更深层次的问题在于系统设计、智能体间的协调以及任务验证机制。

案例研究：MAST在故障诊断中的实用性

MAST不仅仅是一个理论框架，它更是一个强大的实用工具，能够帮助研究人员和开发人员深入理解、高效调试并最终显著改进多智能体系统（MAS）。通过对故障模式进行精确的定义和分类，MAST清晰地揭示了构建可靠MAS所面临的复杂挑战，从而为整个研究社区指明了有针对性的研究方向。

当一个MAS在基准测试中表现出高失败率，特别是当故障表现形式多样且复杂时，要准确查明其根本原因往往异常困难。在缺乏系统化框架的情况下，开发人员通常只能对单个失败的执行轨迹进行临时性的、耗时耗力的调试。此外，评估干预措施的实际效果也极具挑战性。即使总体成功率有所提高，也很难判断这种改进是否真正解决了预期问题，是否引入了新的副作用，或者仅仅是针对特定案例的偶然优化。

在此背景下，MAST展现出其独特的实用价值。它提供了一套结构化的词汇和对不同故障模式的清晰定义，从而实现了系统化的故障诊断。当MAST与作者开发的自动化分析工具（如LLM标注器）结合使用时，开发人员可以获得其系统中在大量执行轨迹中出现的故障类型的详细分类。这种定量的概述能够精确地指出最频繁发生的故障模式，从而将调试工作的重心引向那些能够产生最大影响的领域。例如，通过MAST的分析，可以发现HyperAgent系统可能主要受到“步骤重复”（FM-1.3）和“错误验证”（FM-3.3）这两种故障模式的困扰，因此，针对这些模式的优化将带来显著的性能提升。

更重要的是，MAST有助于对MAS的改进进行严格的评估。开发人员不再仅仅依赖于粗略的总体成功率，而是可以利用MAST进行精细的“前后对比”分析。案例研究生动地说明了这一点：对ChatDev和AG2系统进行干预后，虽然总体性能有所提高，但基于MAST的详细分析能够揭示具体哪些故障模式得到了缓解，以及在改进过程中是否出现了任何权衡（例如，减少了一种故障类型的同时，无意中增加了另一种）。这种细致入微的视图对于深入理解干预措施为何有效以及如何有效地迭代以构建更健壮、更可靠的MAS至关重要。

超越模型能力：系统设计的首要性

一个核心发现是，尽管人们可能倾向于将MAST中观察到的错误完全归因于底层LLM的模型能力不足（例如，幻觉或简单的提示遵循），但我们的干预研究明确指出，许多MAS故障的根本原因在于系统设计本身，而不仅仅是LLM的局限性。这意味着，即使LLM模型本身不断进步，其能力的提升也可能不足以单独保证MAS的可靠性能。

在干预案例研究中，我们采用了两种策略来改进MAS：架构调整（即针对MAS底层拓扑结构进行优化）和提示修改（受到MAST故障模式的启发，旨在改善智能体的角色依从性和验证能力）。为了确保评估的公平性，在干预前后使用了相同的LLM和用户提示来评估MAS的性能。结果显示，MAS系统设计本身的改进能够显著减少故障，而且这种改进与基础模型的进步是相对独立的。这有力地强调了，观察到的MAS故障并非仅仅是模型能力的限制——就像人类在拥有高智能的情况下，也可能因为组织结构问题而犯错一样。因此，未来的研究和开发应更加重视MAS的整体系统设计和智能体间的协调机制，而非仅仅关注提升单个LLM的能力。

结论与未来展望

研究首次对基于大型语言模型（LLM）的多智能体系统（MAS）的故障模式进行了系统而深入的调查。运用扎根理论（Grounded Theory）的方法，对超过200个MAS的执行轨迹进行了细致的分析，并通过严格的标注者间一致性研究，迭代地完善并验证了提出的多智能体系统故障分类法（MAST）。这一分类法成功识别出14种细粒度的故障模式，并将它们归纳为三大核心类别：规范问题、智能体间错位和任务验证。MAST不仅为未来的MAS研究提供了一个坚实的基础框架，更重要的是，它为理解和解决MAS的复杂性提供了新的视角。

为了进一步提升故障分析的效率和可扩展性，还成功开发并验证了一个自动化的评估管道——“LLM标注器”。这个工具能够利用MAST进行大规模的故障分析，为开发人员提供了一个实用的诊断工具。通过这个工具，开发人员可以系统地诊断MAS的性能瓶颈，并根据MAST提供的故障模式，有针对性地改进系统设计，从而开发出更健壮、更可靠的MAS。

因此，我们对MAS所展现出的巨大潜力充满期待，但同时也清醒地认识到，要实现MAS的广泛应用，其可靠性是不可或缺的前提。MAST的提出正是为了实现这一目标，它提供了一个清晰的框架来理解和缓解MAS中普遍存在的故障。通过明确定义这些挑战，也为整个研究社区指明了具体的、亟待解决的问题，鼓励大家共同协作，推动MAS技术向前发展。未来的研究可以基于MAST，进一步探索更有效的故障预防机制、更智能的故障恢复策略，以及更完善的MAS评估标准，最终构建出能够真正服务于复杂现实世界任务的智能体系统。