伯克利论文：Multi-Agent多智能体系统为什么会失败？

多智能体大语言模型（Multi-Agent LLM）系统会失败？最近，伯克利大学发表了一篇重磅论文《Why Do Multi-Agent LLM Systems Fail?》，深入剖析了MAS系统的失败原因，整理出14种具体失败模式，并提出了相应改进建议。 以下是该论文译文，Enjoy。 简介

尽管人们对多智能体系统 (MAS) 的热情日益高涨，其中多个 LLM 智能体协作完成任务，但与单智能体框架相比，它们在流行基准上的性能提升仍然微乎其微。这一差距凸显了分析阻碍 MAS 有效性的挑战的必要性。

在本文中，我们首次全面研究了 MAS 挑战。我们分析了五种流行的 MAS 框架，涉及 150 多个任务，涉及六位专家人工Annotator。我们确定了 14 种独特的故障模式，并提出了适用于各种 MAS 框架的综合分类法。该分类法从每项研究中三位专家Annotator之间的一致意见中迭代出现，Cohen's Kappa 得分为 0.88。这些细粒度的故障模式分为 3 类：(i) 规范和系统设计故障，(ii) 代理间错位，以及 (iii) 任务验证和终止。为了支持可扩展评估，我们将 MASFT 与 LLM-as-a-Judge 集成在一起。我们还探讨了是否可以通过提出两种干预措施轻松预防已识别的故障：改进代理角色的规范和增强编排策略。我们的研究结果表明，已识别的故障需要更复杂的解决方案，这为未来的研究指明了明确的路线图。我们开源了我们的数据集和 LLM解释器。

“成功的系统都是一样的，失败的系统都有自己的问题。”（伯克利，2025）

最近，基于大型语言模型 (LLM) 的代理系统在人工智能社区中引起了广泛关注。这种日益增长的兴趣源于代理系统能够处理复杂的多步骤任务，同时与不同的环境进行动态交互，这使得基于 LLM 的代理系统非常适合解决现实世界的问题，基于这一特点，多智能体系统在软件工程等各个领域得到了越来越多的探索，比如药物发现、科学模拟，以及最近的通用剂。

图 1：五种流行的多智能体 LLM 系统与 GPT-4o 和 Claude-3 的失败率。

在本研究中，我们将基于 LLM 的代理定义为具有提示规范（初始状态）、对话跟踪（状态）和与环境（例如工具使用情况（操作））交互的能力的人工实体。然后将多代理系统( MAS ) 定义为旨在通过编排进行交互的代理集合，从而实现集体智慧。MAS 的结构旨在协调努力，实现任务分解、性能并行化、上下文隔离、专门的模型集成和多样化的推理讨论。

图 2：MAS 故障模式分类。

尽管 MAS 的采用率不断提高，但与单智能体框架或简单基线（例如流行基准测试中的最佳 N 采样）相比，其准确性或性能的提升仍然微乎其微。我们的实证分析表明，最先进的 (SOTA) 开源 MAS ChatDev的正确性可能低至 25%，如图 1 所示。此外，对于如何构建稳健可靠的 MAS，目前还没有明确的共识。这引出了一个我们首先需要回答的基本问题：MAS 为什么会失败？

为了了解 MAS 故障模式，我们使用GT理论 (Glaser & Strauss, 1967) 对 MAS 执行轨迹进行了首次系统评估。我们分析了五种流行的开源 MAS，雇用了六位专家Annotator来识别 150 条对话轨迹中的细粒度问题，每条轨迹平均超过 15,000 行文本。我们将故障定义为 MAS 未实现预期任务目标的情况。为了确保故障模式和定义的一致性，三位专家Annotator独立标记了 15 条轨迹，实现了Annotator间一致性，Cohen’s Kappa 分数为 0.88。通过这项综合分析，我们确定了 14 种不同的故障模式，并将它们聚类为 3 个主要故障类别。我们引入了多智能体系统故障分类法 (MASFT)，这是 MAS 的第一个结构化故障分类法，如图 2 所示。我们并不声称 MASFT 涵盖了所有潜在的故障模式；相反，它是分类和理解 MAS 失败的第一步。

为了实现可扩展的自动评估，我们引入了使用 OpenAI 的 o1 的 LLM-as-a-judge 流程。为了验证此流程，我们在 10 条轨迹上将其Annotator与三位人类专家Annotator进行交叉验证，最终获得 0.77 的 Cohen's Kappa 一致性率。

直观地看，更好的规范和提示策略可能会缓解 MAS 故障。为了检验这一假设，我们使用提示工程和增强的代理拓扑编排实施了干预措施。我们对 AG2 的案例研究和 ChatDev表明，尽管这些干预措施为 ChatDev 带来了 +14% 的改进，但它们并不能解决所有故障情况。此外，改进后的性能对于实际部署来说仍然不够好。

这些发现表明，MASFT不仅仅是现有多智能体框架的产物，而是 MAS 中存在根本设计缺陷的体现。为了构建强大而可靠的 MAS，MASFT可作为指导未来研究的框架，概述 14 种故障模式中每一种的潜在解决方案。此外，我们还开源了我们的Annotator，以供 MAS 的进一步研究。

虽然人们可以简单地将这些失败归咎于当今 LLM 的局限性（例如幻觉、错位），但我们推测基础模型能力的改进不足以解决完整的 MASFT。相反，我们认为良好的 MAS 设计需要组织理解——如果组织结构存在缺陷，即使是由经验丰富的个人组成的组织也可能灾难性地失败

先前对高可靠性组织的研究表明，明确的设计原则可以防止此类故障。与这些理论一致，我们的研究结果表明，许多 MAS 故障源于代理间交互中的挑战，而不是单个代理的局限性。MASFT 能够系统地识别这些故障，并为下一代 MAS 的设计原则提供信息。

本文的贡献如下：

• 我们引入了MASFT，这是第一个基于经验的MAS 故障分类法，为理解和减轻 MAS 故障提供了一个结构化框架。

• 我们开发了一个可扩展的 LLM-as-a-judge评估流程，用于分析新的 MAS 性能和诊断故障模式。

• 我们针对代理规范、对话管理和验证策略开展了尽力干预研究。尽管任务完成率提高了 14%，但它们未能完全解决 MAS 故障，凸显了结构性 MAS 重新设计的必要性。

• 我们完全开源：（1）所有 150 多个带Annotator的 MAS 对话轨迹、（2）可扩展的 LLM-as-a-judge 评估流程和 150 多个轨迹上的 LLM Annotator，以及（3）15 个选定轨迹上的详细专家Annotator。

2.2 代理系统设计原则

一些研究强调了构建强大的代理系统的挑战，并提出了新的策略（通常用于单代理设计）来提高可靠性。例如，Anthropic 的博客文章强调了模块化组件（如快速链接和路由）的重要性，而不是采用过于复杂的框架。同样，Kapoor等人表明，复杂性可能会阻碍代理系统在现实世界中的应用。我们的工作通过系统地研究 MAS 中的故障模式、提供说明 MAS 故障原因的分类法以及为代理系统设计提出符合这些见解的解决方案来扩展这些见解。

2.3 LLM 系统中的故障分类

尽管人们对 LLM Agent的兴趣日益浓厚，但对其失效模式的专门研究却出奇地有限。与Bansal 等人的研究对代理系统中人机交互中面临的挑战进行了分类，我们的贡献代表了研究 MAS 故障模式的开创性努力。这突出了未来研究的必要性，即开发强大的评估指标、识别常见的故障模式以及设计缓解策略以提高 MAS 的可靠性。

3研究方法 图 3： 系统研究 MAS 的方法工作流程，包括识别故障模式、开发分类法、通过Annotator间一致性研究进行迭代细化，达到 Cohen's Kappa 分数 0.88。

本节介绍了我们识别 MAS 中的主要故障模式并建立故障模式结构化分类的方法。图3概述了此工作流程。

为了系统地、无偏见地发现故障模式，我们采用了GT理论方法，这是一种定性研究方法，它直接从经验数据构建理论，而不是测试预定义的假设。GT 的归纳性质使故障模式的识别有机地出现。我们通过理论抽样、开放式编码、持续比较分析、备忘和理论化迭代收集和分析 MAS 执行轨迹。

在获得 MAS 轨迹并讨论初步发现后，我们通过收集观察到的故障模式得出初步分类法。为了完善分类法，我们进行了inter-annotator一致性研究，通过添加、删除、合并、拆分或修改定义来迭代调整故障模式和故障类别，直到达成共识。此过程反映了一种学习方法，其中分类法不断完善，直到实现稳定性，通过 Cohen 的 Kappa 分数通过Annotator间一致性来衡量。此外，为了实现自动故障识别，我们开发了一个基于 LLM 的Annotator并验证其可靠性。

3.1 数据收集与分析

我们采用理论抽样以确保所识别的MAS 的多样性，以及要收集数据的任务集 (MAS 执行轨迹)。 这种方法根据 MAS 的目标、组织结构、实施方法和底层代理角色的变化来指导MAS 的选择。 对于每个MAS，选择的任务都代表系统的预期能力，而不是人为挑战的场景。 例如，如果系统报告了特定基准或数据集的性能，我们会直接从这些基准中选择任务。 分析的 MAS 涵盖多个领域和上下文，如表1和附录B所述。 在收集 MAS 轨迹后，我们应用开放式编码来分析我们收集的代理-代理和代理-环境交互的痕迹。开放编码将定性数据分解为标记的段，允许Annotator创建新的代码并通过备忘录记录观察结果，从而实现Annotator之间的迭代反思和协作。具体来说，Annotator识别他们遇到的故障模式，并系统地将他们创建的新代码与现有代码进行比较，这在GT中也称为持续比较分析。这种故障模式识别和开放编码的迭代过程一直持续，直到我们达到理论饱和，即从额外数据中不再出现新见解的点。通过这个过程，Annotator标记了 5 个 MAS 中的 150 多条痕迹。接下来，我们对相关的开放代码进行分组，以揭示MASFT初始版本中的细粒度故障模式。最后，我们链接故障模式，形成错误类别的分类，如图2所示。该过程在图3中用点 1 和 2 表示。在提出初始分类法后，一个重要的问题是该分类法的可靠性如何，以及我们如何找到一种自动化方法来评估 MAS 故障。为此，我们进行了Annotator间一致性研究，其中三位Annotator旨在验证、改进和最终确定最初得出的分类法。

3.2 A nnotator间一 致性研究和迭代改进

Annotator间研究主要针对验证给定的测试或评分标准，这样当多个不同的Annotator根据相同的评分标准Annotator同一组测试用例时，他们应该得出相同的结论。尽管我们最初根据上一节中解释的理论抽样和开放编码得出了一个分类法，但仍然需要验证该分类法的无歧义性。

对于Annotator之间的一致性，我们在初步得出分类法的基础上进行了三轮主要讨论。在第一轮中，我们从上一节中解释的理论抽样获得的 150 多条轨迹中抽取了 5 条不同的 MAS 轨迹，三位Annotator使用初始分类法中的故障模式和定义对这些轨迹进行Annotator。我们观察到，Annotator在第一轮中达成的一致性非常弱，Cohen's Kappa 得分为 0.24。接下来，这些Annotator对分类法进行改进。这涉及迭代地更改分类法，直到我们达成共识，即每种故障模式是否存在于某种故障模式中，以及是否存在于所有 5 条收集到的轨迹中。在迭代改进中，我们根据需要更改故障模式的定义，将它们分解为多个细粒度故障模式，将不同的故障模式合并为一种新的故障模式，添加新的故障模式或从分类法中删除故障模式。

这一过程可以比作一项学习研究，其中不同的代理（这次是人类Annotator）独立地从共享状态空间收集观察结果，并彼此分享他们的发现以达成共识。此外，为了不陷入将训练数据用作测试数据的谬误，当我们在第 1 轮结束时进行细化研究时，我们在第 2 轮中测试了新的Annotator间一致性和分类法在另一组轨迹中的性能。在下一阶段（第 2 轮），我们采样另一组 5 条轨迹，每条轨迹来自不同的 MAS。然后，Annotator在第一次尝试中就达成了很好的一致，彼此之间的平均 Cohen's Kappa 分数为 0.92。受此启发，我们进入第 3 轮，在那里我们采样了另一组 5 条轨迹并再次使用相同的最终分类法进行Annotator，其中获得了 0.84 的平均 Cohen's Kappa 分数。请注意，Cohen's Kappa 分数超过 0.8 被认为是强的，超过 0.9 被认为是几乎完美的对齐。

受分类法可靠性的启发，我们提出了以下问题：我们能否想出一种自动化的方法来Annotator轨迹，以便开发人员或用户可以将此自动化管道与我们的分类法一起使用，以了解其模型失败的原因？因此，我们使用 LLM-as-a-judge 管道开发了一个自动化MASFT Annotator，我们将在第3.3节中对其进行描述。

3.3 LLM A nnotator

在开发了我们的分类法MASFT并完成了Annotator之间的一致性研究之后，我们的目标是想出一种自动化的方法，使用我们的分类法来发现和诊断 MAS 轨迹中的故障模式。为此，我们开发了一个 LLM-as-a-judge 管道。在这个策略中，我们为 LLM 提供了一个系统提示，其中包括我们MASFT中的故障模式、它们的详细解释以及这些故障模式的一些示例。在该策略中，我们决定使用 OpenAI 的 o1 模型，并且尝试了不提供上述示例和提供示例的情况。基于第3.2节中提到的第 3 轮Annotator间一致性研究的结果，我们测试了 LLM Annotator的成功性，如表2所示。由于我们达到了 94% 的准确率和 77% 的 Cohen's Kappa 值，我们认为 LLM Annotator（提供上下文示例）是一个可靠的Annotator。受此结果的启发，我们让 LLM Annotator标记我们收集的 150+ 条痕迹语料库中的其余痕迹，其结果如图4所示，最终的分类法与故障模式分布如图2所示。

4研究结果

图4：按类别和系统分布的故障模式。

我们对一系列不同的 MAS 进行的扎根理论研究和Annotator间一致性研究促成了图2中所示的MASFT的开发。MASFT 组织了 3 个总体故障类别，确定了 MAS 在执行过程中可能遇到的 14 种细粒度故障模式。MASFT 还将MAS执行分为与代理相关的 3 个阶段：执行前、执行和执行后，确定了每种细粒度故障模式可能发生的 MAS 执行阶段。

FC1. 规范和系统设计失败。由于系统架构设计缺陷、对话管理不善、任务规范不明确或违反约束以及对代理角色和职责的定义或遵守不充分而导致的失败

在 MAS 中，任务失败通常源于不完整或模糊的指令。然而，即使给出了明确的规范，MAS 也可能与用户输入不一致。此类失败的一个例子是违反任务规范。当被要求设计一款以经典国际象棋走法符号（如“Ke8”、“Qd4”）作为输入的双人国际象棋游戏时，MAS 框架 ChatDev 会生成一款以 (x1, y1)、(x2, y2) 作为输入的游戏，这些符号表示棋盘上棋子的初始坐标和棋子的最终坐标，因此无法满足初始要求。此类失败的另一种模式是未遵守角色规范。例如，在 ChatDev 的需求分析阶段，CPO 代理偶尔会通过单方面定义产品愿景并做出最终决策来承担 CEO 的角色。

FC2. 代理间错位。由于沟通不畅、协作不力、代理间行为冲突以及逐渐偏离初始任务而导致的失败。

图5： 电话代理未能向主管传达 API 规范和登录用户名要求。在对话的另一端，主管代理也未能澄清登录详细信息。经过几次来回尝试后，主管代理将任务标记为失败。

多智能体系统经常遭受对话效率低下的问题，智能体会进行无效的交流，消耗计算资源却没有取得有意义的进展。例如，在涉及创建类似 Wordle 的游戏的 ChatDev 跟踪中，程序员智能体在七个周期内与多个角色（CTO、CCO 等）进行了交互，但未能更新初始代码。由此产生的游戏可玩但缺乏稳健性，只有五个简单的单词，破坏了可重玩性并导致额外的通信轮次浪费。此类别中的另一种故障模式是智能体隐瞒有价值的信息。例如，在图 5 中，主管智能体指示电话智能体使用电子邮件 ID 作为用户名来检索联系信息。电话智能体在阅读文档并发现正确的用户名应该是电话号码后，仍然使用错误的凭据继续操作，导致错误。

FC3. 任务验证与终止。由于执行过早终止而导致的故障，以及缺乏足够的机制来保证交互、决策和结果的准确性、完整性和可靠性。

MAS 可能在开发时没有经过专门的验证步骤，或者可能包含无法有效执行其任务的验证代理。例如，在涉及国际象棋游戏实现的 ChatDev 场景中，验证代理仅检查代码是否编译，而不运行程序或确保符合国际象棋规则。国际象棋是一种成熟的游戏，具有广泛的规范、规则和实现，可在线轻松获取。即使是简单的检索也应该直观地防止微不足道的故障，例如接受格式错误的输入。但是，如果没有适当的验证，无效输入处理或格式错误的接口等缺陷就会持续存在，导致游戏无法玩。

图4显示了所研究 MAS 中细粒度故障模式以及故障类别的分布。不同的颜色代表MASFT中的不同故障类别，不同的色调代表类别内不同的细粒度故障模式。我们强调，没有任何单一错误类别占主导地位，这表明故障发生具有多样性，并且用于对故障进行分类的分类法具有稳健性。此外，我们注意到，正如预期的那样，不同的 MAS 表现出不同的故障类别和模式分布。例如，与规范和验证问题相比，AG2 的代理间错位实例较少，而 ChatDev 遇到的验证问题比规范和代理间错位挑战少。这些差异源于不同的问题设置，这会影响系统拓扑设计、通信协议和交互管理。反过来，这些因素塑造了具有自身优势和劣势的系统。

图6：MAS 故障类别相关矩阵。

图6突出显示了MASFT中不同故障类别之间的相关性。观察到的相关性不是特别强，它们表明所提出的分类法是一个合理的分类框架。此外，这还表明故障不是孤立事件；相反，它们可能具有连锁效应，可以影响其他故障类别。

图 7： MAS 故障模式相关矩阵

4.3 都是验证者的错吗？

我们已经确定了 MAS 中的一系列故障模式。然而，可以说，归根结底，每个故障都可能源于缺乏适当的验证或不正确的验证流程。如果我们假设验证代理功能完美，那么所有故障都是可检测的，因此可以避免。

在我们的研究中，我们专注于系统可以有效受益于验证过程结果的情况中的验证问题。但是，我们还会检查在最终验证步骤之前发生的其他故障模式。在许多情况下，我们可以将验证视为防止故障的最后一道防线。这使我们得出结论，虽然许多问题确实可以追溯到验证不足，但并非每个问题都可以完全归因于这一因素。其他因素，例如规格不佳、设计不足、沟通效率低下，也会导致故障。因此，全面理解和解决 MAS 故障的方法必须考虑更广泛的因素，而不仅仅是验证缺陷。

4.4 MASFT 故障模式违反 HRO 定义特征

尽管我们遇到了一些常见的 LLM 故障模式，例如文本重复，但我们将它们排除在MASFT之外，因为这些问题并非专门与MAS 有关，甚至可能在单LLM 调用管道中发生。另一方面，我们发现MAS 面临与复杂人类组织类似的问题的证据，因为故障模式与人类组织中观察到的常见故障模式一致。Roberts & Rousseau (1989)确定了高可靠性组织 (HRO) 共有的八个主要特征。 通过 GT 发现的MASFT没有任何先前的偏见，包括几种与Roberts & Rousseau确定的 HRO 独特特征相关的故障模式具体来说，“ FM1.2：不遵守角色规范”

代理试图超越其角色，违反了 HRO 特征“极端层级分化”。同样，“FM2.2 ：未能要求澄清”破坏了“尊重专业知识”。MASFT中确定的故障模式直接违反了 HRO 特征，这验证了MASFT的适用性，以及需要受 HRO 启发的非平凡干预措施。例如，为了防止 MAS 中发生“FM1.2：不遵守角色规范”，编排和角色分配可以强制层级分化。

5迈向更好的多智能体 LLM 系统

在本节中，我们讨论了一些使 MAS 更能抵御故障的方法。我们将这些策略分为两大类：（i）战术方法，（ii）结构策略。战术方法涉及针对特定故障模式量身定制的直接修改，例如改进提示、代理网络拓扑和对话管理。在第6节中，我们在两个案例研究中试验了这些方法，并证明这些方法的有效性并不一致。这促使我们考虑第二类策略，它们是具有全系统影响的更全面的方法：强验证、增强通信协议、不确定性量化以及内存和状态管理。这些策略需要更深入的研究和细致的实施，并且仍然是有待未来探索的开放研究课题。表3了解我们提出的不同解决方案策略与故障类别之间的映射。

5.1 战术方法

此类别包括与改进提示和优化代理组织和交互相关的策略。MAS 代理的提示应提供清晰的指令描述，并应明确指定每个代理的角色。提示还可以明确角色和任务，同时鼓励主动对话。如果出现不一致，代理可以重新参与或重试，如下提示词所示。完成复杂的多步骤任务后，在提示中添加一个自我验证步骤，通过重述解决方案、检查条件和测试错误来追溯推理过程。然而，它可能会遗漏缺陷、依赖模糊的条件，或者不切实际。此外，可以通过定义对话模式和设置终止条件来强化明确的角色规范。采用简单、定义明确的代理（而不是复杂、多任务的代理）的模块化方法可以提高性能并简化调试。群体动力学还使多智能体系统的其他有趣可能性成为可能：不同的智能体可以提出各种解决方案，采用多智能体策略模拟学术同行评审过程，以捕捉更深层次的不一致之处。

Prompt：
您的角色是逐步批判性地评估其他代理提出的解决方案并提供最终解决方案。
1. **解决方案要求**：在做出任何决定之前，请确保您已收到来自代理代码执行器和代理问题解决器的解决方案。如果缺少任何建议的解决方案，请不要得出任何结论；而是建议下一位发言者，说明：建议的下一位发言者：_建议的代理名称_ 。
2. **避免假设**：注意原始问题陈述中提供的变量与代理假设的变量。**假设值对解决方案无效** ，并且可能导致不准确。切勿以假设值为基础解决问题。始终以明确给出的变量为基础解决问题，以确保正确性。如果由于缺少信息而导致问题无法解决，则返回：** SOLUTION_FOUND \\ boxed { ' None ' } ** 。
3. **评估相互冲突的解决方案**：如果讨论过程中出现不同的答案，请根据您的证据选择最合适的解决方案或开展进一步的讨论以澄清。
4. **最终解决方案声明**：当您对最终解决方案有信心时，请按如下方式返回：** SOLUTION_FOUND \\ boxed { _solution_value_here_ } ** 。确保只有数值放在\\ boxed { }内；任何附带的文本都应放在外面

另一套交叉验证的策略方法包括多次 LLM 调用，并进行多数表决或重采样，直到验证完成。然而，这些看似简单的解决方案往往被证明是不一致的，这与我们的案例研究的结果相呼应。这强调了需要更强大的结构化战略，如下节所述。

5.2 结构性策略

除了我们上面讨论的战术方法之外，还需要更多复杂的解决方案来塑造手头的 MAS 结构。我们首先观察验证过程和验证代理在多代理系统中的关键作用。我们的Annotator表明，薄弱或不充分的验证机制是导致系统故障的重要因素。虽然单元测试生成有助于软件工程中的验证, 创建一个通用的验证机制仍然具有挑战性。即使在编码中，覆盖所有边缘情况也很复杂，即使对于专家来说也是如此。验证因领域而异：编码需要全面的测试覆盖，QA 需要经过认证的数据检查，并且推理受益于符号验证。跨领域适应验证仍然是一个持续的研究挑战。

验证的补充策略是建立标准化的通信协议。基于 LLM 的代理主要通过非结构化文本进行通信，这会导致歧义。明确定义意图和参数可增强一致性，并在交互期间和之后进行正式的一致性检查。引入了多智能体图注意力机制，利用图注意力机制来模拟智能体交互并增强协调性。同样提出了注意力沟通，使代理能够有选择地关注相关信息。同样，开发一种学习选择性通信协议，以提高合作效率。

另一个重要的研究方向是使用强化学习对 MAS 代理进行微调。代理可以使用特定于角色的算法进行训练，奖励与任务一致的操作并惩罚效率低下的行为。MAPPO优化了代理对定义角色的遵守。同样，SHPPO在应用异构决策层之前使用潜在网络来学习策略。Optima通过迭代强化学习进一步提升沟通效率与任务效果。

另一方面，将概率置信度度量纳入代理交互可以显著提高决策和通信可靠性。从 Horvitz 等人提出的框架中汲取灵感。代理可以被设计为只有当其置信度超过预定义的阈值时才采取行动。相反，当置信度较低时，代理可以暂停以收集更多信息。此外，系统可以从自适应阈值中受益，其中置信度阈值是动态调整的。

尽管记忆和状态管理通常被视为单智能体属性，但对于多智能体交互来说，它们至关重要，可以增强上下文理解并减少交流中的歧义。然而，大多数研究都集中在单智能体系统上。MemGPT引入了受操作系统启发的上下文管理，用于扩展上下文窗口，而TapeAgents使用结构化、可重播的日志（“磁带”）来迭代记录和改进代理操作，促进动态任务分解和持续改进。

6案例研究

在本节中，我们将介绍应用一些战术方法的两个案例研究。

6.1案例研究 1：AG2 - MathChat

在本案例研究中，我们使用 AG2 中的 MathChat 场景实现作为我们的基线，其中学生代理与能够执行 Python 代码的助理代理协作解决问题。为了进行基准测试，我们从 GSM-Plus 数据集中随机选择了 200 个练习, GSM8K 的增强版本并添加各种对抗性扰动。第一种策略是改进原始提示，使其结构清晰，并增加一个专门用于验证的新部分。详细的提示在附录E.1和E.2中提供。第二种策略是将代理配置细化为一个更专业的系统，该系统具有三个不同的角色：问题解决者，使用思路链方法解决问题，不使用工具；编码员，编写并执行 Python 代码以得出最终答案；验证者，负责审查讨论并批判性地评估解决方案，要么确认答案，要么引发进一步的辩论。在这种情况下，只有验证者才能在找到解决方案后终止对话。为了评估这些策略的有效性，我们使用两个不同的 LLM（GPT-4 和 GPT-4o）在三种配置（基线、改进的提示和新拓扑）中进行了基准测试实验。我们还进行了六次重复实验，以评估结果的一致性。表4总结了结果。

表 4：案例研究准确度比较。在 AG2 下，使用 GPT-4 和 GPT-4o 报告 GSM-Plus 结果；在 ChatDev 下，报告 ProgramDev 和 HumanEval 的结果。

表4的第二列显示，使用 GPT-4，经过验证的改进提示明显优于基线。但是，新拓扑并没有产生相同的改进。Wilcoxon 检验的 p 值为 0.4，表明小幅提升并不具有统计学意义。对于 GPT-4o（表4的第三列），在将基线与改进的提示和新拓扑进行比较时，Wilcoxon 检验得出的 p 值为 0.03，表明统计上有显著的改进。这些结果表明，优化提示和定义明确的代理角色可以减少失败。但是，这些策略并不是通用的，并且它们的有效性会因底层 LLM 等因素而异。

6.2案例研究2：ChatDev

ChatDev模拟了一个多智能体软件公司，其中不同的智能体具有不同的角色规范，例如 CEO、CTO、软件工程师和审阅者，他们试图协作解决软件生成任务。为了解决我们在跟踪中经常观察到的挑战，我们实施了两种不同的干预措施。我们的第一个解决方案是改进特定于角色的提示以强制执行层次结构和角色遵守。例如，我们观察到CPO 过早结束与 CEO 的讨论而没有完全解决约束的情况。为了防止这种情况，我们确保只有高级代理才能完成对话。此外，我们增强了验证者角色规范，以专注于特定于任务的边缘情况。这些干预措施的详细信息位于F节中。第二个解决方案尝试涉及对框架拓扑的根本更改。我们将框架的拓扑从有向无环图 (DAG) 修改为循环图。现在，只有当CTO 代理确认所有评论都得到适当满足时，该过程才会终止，并具有最大迭代截止以防止无限循环。这种方法可以实现迭代细化和更全面的质量保证。我们在两个不同的基准测试中测试了我们的干预措施。第一个是自定义生成的 32 个不同任务集（我们称之为 ProgramDev），我们要求框架生成各种程序，从“为我编写一个可在终端上玩的双人象棋游戏”到“为我编写一个 BMI 计算器”。另一个基准是 OpenAI 的 HumanEval 任务。我们在表4中报告了我们的结果。请注意，尽管我们的干预措施成功地提高了框架在不同任务中的性能，但它们并没有带来实质性的改进，需要我们在第5.2节中列出的更全面的解决方案。

7结论

在本研究中，我们首次系统地研究了基于 LLM 的多智能体系统的故障模式，在GT理论的指导下，我们收集并分析了 150 多个轨迹，并通过Annotator间研究迭代地完善我们的分类法并进行验证。我们确定了 14 种细粒度故障模式，并将它们归入 3 种不同的故障类别，为未来 MAS 的研究提供了标准。我们还提出了一种 LLM Annotator作为分析 MAS 轨迹的自动化方法，并展示了其有效性和可靠性。我们还讨论了所有故障类别的两套解决方案，即战术和结构策略。在对一些战术策略进行案例研究后，我们的研究结果表明，许多这些“明显”的修复实际上存在严重的局限性，需要我们概述的结构策略来实现更一致的改进。

原文链接：https://arxiv.org/html/2503.13657v1