为啥「3个agent」没水吃？科学家发现了14个失败原因

2025 年是 agent 爆发之年。

基于处理复杂、多步骤任务以及与不同环境实时互动的能力，由大语言模型（LLM）驱动的 agent 系统，尤其是多 agent 系统（MAS），被认为非常适合用来解决现实世界中的问题，也因此被越来越多地应用在各个领域中，如软件工程、药物发现、科学模拟，以及通用 agent 系统。

然而，相比于单个 agent 系统甚至更简单的 baseline，多 agent 系统却在处理实际问题时更易出错。如下图所示，AppWorld 的故障率可高达 86.7%。

图｜使用 GPT-4o 和 Claude-3 的 5 种常用多 agent LLM 系统的故障率

这是为什么呢？来自加州大学伯克利分校和意大利联合圣保罗银行的研究团队给出了答案——

他们首次对多 agent 系统面临的挑战进行了全面研究，并确定了 14 种独特的故障模式，并划分为 3 大类：（1）规范和系统设计故障；（2）agent 间错位；（3）任务验证和终止。

相关研究论文以“Why Do Multi-Agent LLM Systems Fail?”为题，已发表在预印本网站 arXiv 上。

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

具体而言，他们提出了首个基于经验的多 agent 系统故障分类法——MASFT，理解和缓解多 agent 系统故障提供了一个结构化框架。

同时，他们也开发了一个可扩展的“LLM-as-a-judge”评估管道，用于分析新的多 agent 系统性能和诊断故障模式。

另外，针对 agent 规范、对话管理和验证策略，他们还进行了干预研究，尽管将任务完成率提高了 14%，但仍未能完全解决多 agent 系统故障问题，这凸显了结构性多 agent 系统重新设计的必要性。

此外，他们也将研究成果进行开源，包括：

150 多个标注的多 agent 系统会话轨迹；

可扩展的 LLM-as-a-judge 评估管道和 150 多个轨迹的 LLM 标注；

15 个选定轨迹的详细专家标注。

多达 14 种故障模式

在这项工作中，研究团队使用了扎根理论（Grounded Theory）这一定性研究方法，直接从经验数据中构建理论，而不是检验预定义的假设，使故障模式的识别有机地产生。

他们通过理论抽样、开放式编码、持续比较分析、备忘录和理论化等方法反复收集和分析多 agent 系统的执行轨迹，获得多 agent 系统跟踪记录并讨论初步发现后，通过收集观察到的故障模式得出了 MASFT。

图｜系统研究多 agent 系统的方法流程

为了实现自动故障识别，他们开发了基于 LLM 的标注器，并验证了它的可靠性。

然后，他们进行了标注器之间的协议研究，通过添加、删除、合并、拆分或修改定义反复调整故障模式和故障类别，直到达成共识。这一过程反映了一种学习方法，即不断完善分类法，直至达到稳定性，并通过 Kappa 系数来衡量标注器之间的一致性。

图｜多 agent 系统故障模式分类法

最终，MASFT 包含了 3 个总体故障类别：规范和系统设计故障；agent 间错位；任务验证和终止，确定了多 agent 系统在执行过程中可能遇到的 14 种细粒度故障模式。

MASFT 还将多 agent 系统的执行划分为 3 个阶段：执行前、执行中和执行后，确定了每个细粒度故障模式可能发生的多 agent 系统执行阶段。

图｜多 agent 系统故障类别相关矩阵

另外，他们发现，多 agent 系统面临着与复杂的人类组织类似的问题，其故障模式与在人类组织中观察到的常见故障模式一致。“不要求澄清”破坏了“尊重专业知识”，“agent 错位”体现了加强等级区分和协调角色分配的必要性。

多 agent 协作的有效性，仍有待提高

针对以上所有的故障类别，研究团队提出了战术策略和结构策略。

战术策略涉及针对特定故障模式的直接修改，如改进提示、agent 网络的拓扑结构和对话管理。然而，两个案例研究证明，这些方法的有效性并不一致。

结构策略，即对整个系统有影响的更全面的方法：强验证、增强型通信协议、不确定性量化以及内存和状态管理。这些策略需要更深入的研究和细致的实施，仍是有待未来探索的研究课题。

图｜多 agent 系统的解决策略和故障分类

研究团队在两个案例研究中应用了这些策略方法。

在第一个案例中，他们使用 AG2 中的 MathChat 场景实现作为基线，在该场景中，学生 agent 与能够执行 Python 代码的助理 agent 合作解决问题。

为了进行基准测试，他们从 GSM-Plus 数据集中随机选取了 200 个练习。第一种策略是改进原始提示，使其具有清晰的结构和专门用于验证的新部分。第二种策略是将 agent 配置细化为一个更专业的系统，其中包含三个不同的角色：问题解决者（Problem Solver），不使用工具，使用思维链方法解决问题；编码者（Coder），编写并执行 Python 代码，得出最终答案；验证者（Verifier），审查讨论并批判性地评估解决方案，要么确认答案，要么引发进一步讨论。

在这种情况下，一旦找到解决方案，只有验证人可以终止对话。

在第二个案例中，ChatDev 模拟了一个多 agent 软件公司，不同的 agent 有不同的角色定位，如首席执行官、首席技术官、软件工程师和审核员，他们试图合作解决一个软件生成任务。

他们实施了两种不同的干预措施。第一个是改进特定角色的提示，以强化层次结构和角色一致性；第二个是尝试涉及对框架拓扑结构的根本性改变，将框架的停止结构从有向无环图（DAG）修改为循环图。

现在，只有当 CTO agent 确认所有审查都得到适当满足时，该过程才会终止，并设定了最大迭代截止时间，以防止出现无限循环。这种方法可以实现迭代改进和更全面的质量保证。

图｜各种方案的性能准确度

研究团队表示，许多“显而易见”的解决方案实际上存在严重的局限性，需要概述的结构性策略来实现更加一致的改进。

考虑到目前多 agent 协调中的信息冗余与冲突，协作中放大的模型偏差，未来的多 agent 系统需要做到快速响应、实时验证和动态协调，以提高团队协作的有效性。

“基于 LLM 的多 agent，在分布式科研协作、应急响应系统等领域仍具有一定的潜力。”

作者：与可