Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享

AITNT-国内领先的一站式人工智能新闻资讯网站
# 热门搜索 #
AITNT-国内领先的一站式人工智能新闻资讯网站 搜索
Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享
7713点击    2025-03-28 09:33

这两年,AI 领域最激动人心的进展莫过于大型语言模型(LLM)的崛起,LLM 展现了惊人的理解和生成能力。


在此基础上,一个更宏伟的构想应运而生:构建多智能体系统(Multi-Agent System, MAS)


想象一下,不再是单个 AI 孤军奋战,而是一个由多个专门的 AI 智能体组成的“梦之队”,它们各自拥有特定技能(如编码、设计、测试、沟通),通过协作来完成复杂的、多步骤的任务,比如开发一款软件、进行科学研究,甚至模拟人类社会行为。


这种“群体智能”的潜力令人遐想:任务分解、并行处理、专才专用、集思广益……


理论上,MAS 应该能解决单个 LLM 难以应对的宏大挑战,实现“1+1 > 2”的效果。然而,现实却有些骨感。


Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享


尽管业界对 MAS 热情高涨,但在许多基准测试中,这些“AI 梦之队”的表现相比单个智能体框架,提升效果甚微,有时甚至更差。这不禁让人发问:


为什么这些看似强大的 AI 团队,在实际运作中却常常掉链子?


这篇论文来自加州大学伯克利分校 (UC Berkeley),首次对这个问题进行了系统性的、深入的研究。


研究者们并没有简单地将失败归咎于 LLM 本身的能力局限(比如“幻觉”或“对齐”问题),而是将目光投向了 MAS 系统设计和智能体之间交互的复杂性


他们通过对五个流行的 MAS 框架、超过 150 个任务执行过程的详细分析,提出了一个名为 MASFT (Multi-Agent System Failure Taxonomy)多智能体系统失败分类法,系统地揭示了这些系统失败的根源。


Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享


  • 论文链接:https://arxiv.org/pdf/2503.13657
  • 论文标题:Why Do Multi-Agent LLM Systems Fail?
  • 研究团队:加州大学伯克利分校 (UC Berkeley)
  • Github 链接:https://github.com/multi-agent-systems-failure-taxonomy/MASFT


背景知识:什么是 LLM 智能体和多智能体系统 (MAS)?


在我们深入探讨失败原因之前,先快速了解一下关键概念:


1.大型语言模型 (LLM):


可以将其理解为一个极其强大的“大脑”,通过在海量文本数据上训练,学会了理解和生成人类语言,甚至具备一定的推理、规划能力。


2.LLM 智能体 (LLM-based Agent):


这不仅仅是 LLM 本身。一个 LLM 智能体通常是“LLM 大脑 + 特定指令/角色设定 + 记忆(对话历史)+ 行动能力(如使用工具、调用 API)”。


你可以把它想象成一个被赋予了特定身份和工具的智能助手,比如一个“AI 程序员”、“AI 研究员”或“AI 客服”。它能根据任务需求,动态地与环境(如互联网、软件工具)交互,并根据反馈调整行为。


3. 多智能体系统 (MAS):


这是由多个 LLM 智能体组成的集合。这些智能体被设计成可以相互沟通、协调,共同完成一个更大的目标。设计 MAS 的初衷是为了利用“分工协作”的力量,例如:


  • 任务分解: 将复杂任务拆分成小块,交给专门的智能体处理。
  • 并行处理: 多个智能体同时工作,提高效率。
  • 上下文隔离/专业化: 每个智能体专注于自己的领域,避免信息过载,提升专业度。
  • 多样化推理/讨论: 不同智能体可能提出不同见解,通过讨论或辩论产生更好的解决方案。


论文中研究的 MAS 系统(如 MetaGPT, ChatDev, HyperAgent, AppWorld, AG2)就模拟了软件公司、研究团队等协作模式。例如,ChatDev 模拟一个软件开发公司,包含 CEO、CTO、程序员、测试员等不同角色的 AI 智能体,它们通过对话来完成软件开发任务。


MAS 严重未达预期


先看一组数据:


Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享


在一些流行的 MAS 框架和任务上,成功率低得惊人:


  • MetaGPT (软件开发任务): 成功率仅 66.0%
  • ChatDev (软件开发任务): 成功率仅 25.0%
  • HyperAgent (软件工程基准测试): 成功率仅 25.3%
  • AppWorld (跨应用任务): 成功率仅 13.3%
  • AG2 (数学题解答): 成功率 84.8% (相对较高,但仍有 15.2% 失败率)


这意味着,即使使用了强大的底层 LLM(如 GPT-4o, Claude-3),这些精心设计的 AI 团队在很多情况下也无法成功完成任务。这种表现与人们对其“群体智能”的期待形成了巨大反差。


失败归因为 14 种具体的失败模式


为了系统地找出失败原因,研究者们采用了扎根理论 (Grounded Theory) 的方法。


他们邀请了六位人类专家,仔细审查了来自 5 个不同 MAS 系统的 150 多个任务执行记录(每个记录平均包含超过 15000 行文本,主要是智能体之间的对话和行动日志)。


扎根理论的核心是让理论从数据中自然浮现,而不是预设假说。专家们反复阅读、标记、讨论这些记录中的失败点,不断提炼和归纳,最终形成了一套包含 14 种具体失败模式的分类法,并将其归纳为三大类。这套分类法被称为 MASFT


Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享


为了确保分类法的可靠性,研究者们进行了注释者间一致性 (Inter-annotator agreement) 测试。


三位专家独立使用 MASFT 对同一批任务记录进行标注,计算他们之间的一致性程度(Cohen's Kappa 系数)。经过多轮迭代优化,最终的 MASFT 达到了 0.88 的 Kappa 分数,这表明该分类法具有很高的可靠性和一致性。


下面,我们详细解读 MASFT 的三大失败类别及其包含的具体模式:


类别一:规范与系统设计失败 (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 文档明确需要电话号码。“电话”智能体发现了这一点,却没有向主管澄清,而是直接用错误的邮箱地址尝试登录,导致失败。同时,“主管”智能体在提供指令时也未能检查或询问细节。


Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享


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 中,智能体在评审同伴的解答时,可能自己也犯了同样的错误,或者未能识别出明显的逻辑漏洞,给出了错误的“验证通过”结论。


这些失败意味着什么?不仅仅是技术问题


MASFT 揭示的失败模式多种多样,并且在不同的 MAS 系统中分布也不同,这说明 MAS 的失败不是由单一原因主导的,而是系统性、多样性的问题。


Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享


更有趣的是,论文作者将这些 AI 系统的失败模式与高可靠性组织 (High-Reliability Organizations, HROs) 的研究联系起来


HROs 是指那些在极其复杂和高风险环境下(如核电站、航母)却能保持极低事故率的组织。


研究发现,HROs 通常具备一些关键特征,如极端的层级分化、尊重专业知识、对失败保持警惕等。而 MASFT 中的许多失败模式,恰恰违反了这些 HRO 的成功原则:


  • "不遵从角色规范" (FM-1.2) 违反了 "极端层级分化"。
  • "未能请求澄清" (FM-2.2) 违反了 "尊重专业知识" (Deference to Expertise)。


这表明,构建一个成功的 MAS,不仅仅是提升底层 LLM 的智能那么简单,它更像是在构建一个组织。如果组织结构、沟通协议、权责分配、质量控制流程设计不当,即使每个成员(智能体)都很“聪明”,整个系统也可能像一个管理混乱的公司一样,效率低下、错误频出,甚至彻底崩溃。


论文开头的两句引言恰如其分:


Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享


“幸福的家庭都是相似的;不幸的家庭各有各的不幸。” (托尔斯泰, 1878)


所以,成功的系统都是相似的;失败的系统各有各的问题。


能修复这些问题吗?


既然发现了问题所在,自然要寻找解决方案。论文探讨了两类策略:


1.战术性方法 :


这些是相对直接、针对特定失败模式的“小修小补”。例如:


  • 改进提示 (Prompt Engineering): 给出更清晰的任务指令和角色定义
  • 优化智能体拓扑/沟通模式: 改变智能体之间的连接方式和对话规则 (如从线性流程变为循环反馈,或加入专门的协调者)。
  • 加入自我验证/重试机制: 让智能体在完成任务后自查,或在遇到不一致时尝试重新沟通 (Appendix E.5)。
  • 多数投票/重采样: 多次运行或让多个智能体给出答案,选择最一致的结果。


研究者们在两个案例(AG2-MathChat 和 ChatDev, Sec 6)中尝试了这些战术方法。结果显示:


这些方法确实能带来一些改进(例如,改进后的 ChatDev 在 ProgramDev 任务上的准确率从 25% 提升到 40.6%),但效果有限且不稳定


对于 AG2,改进提示在 GPT-4 上效果显著,但在 GPT-4o 上,新拓扑结构反而效果不佳。这说明这些“头痛医头,脚痛医脚”的方法,并不能根治所有问题。


2.结构性方法:


这些是更根本、更系统性的变革,旨在从基础架构层面提升 MAS 的鲁棒性和可靠性。这通常需要更深入的研究和更复杂的实现。


  • 强大的验证机制: 设计通用的、跨领域的验证框架(不仅仅是代码测试,可能涉及逻辑验证、事实核查、QA 标准等)。论文特别强调了验证的重要性,认为它是抵御失败的“最后一道防线”,但构建通用验证机制极具挑战。
  • 标准化沟通协议: 定义清晰的、结构化的智能体间通信语言和格式,减少歧义,实现类似计算机网络协议那样的可靠交互。
  • 不确定性量化: 让智能体能够评估并表达自己对信息或结论的“置信度”,在低置信度时主动寻求更多信息或采取更保守的行动。
  • 增强的记忆和状态管理: 改进智能体记录、检索和利用长期/短期记忆的方式,确保上下文连贯性。
  • 基于强化学习的协作训练: 通过奖励期望的行为(如有效沟通、遵守角色、成功协作)和惩罚不良行为,来“训练”智能体学会更好地团队合作。


这些结构性方法被认为是未来解决 MAS 失败问题的关键,但它们也带来了新的研究挑战。


Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享


借助 AI 翻译成了中文表格:


Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享


道阻且长,行则将至


这项研究,为我们理解为什么基于 LLM 的多智能体系统频频失败提供了第一个系统性的框架——MASFT。


这篇论文清晰地揭示了,这些失败不仅仅是底层 AI 模型的问题,更多是源于系统设计、智能体间交互以及验证机制的深层缺陷,这些缺陷与复杂人类组织的运作困境惊人地相似。


其次,研究结果也提醒我们,期望通过简单的提示工程或微调就能让“AI 梦之队”发挥全部潜力是不现实的。


未来需要更深入、更根本的结构性变革,包括设计更鲁棒的验证系统、更可靠的通信协议、以及更有效的协作机制。才能有望逐步构建出真正可靠、高效、能够应对复杂现实世界挑战的多智能体系统。


前路充满挑战,但这篇论文无疑为推动“群体智能”提供了一张失败地图。


文章来自于“夕小瑶智能体”,作者“吉卜力”。


Multi-Agents 系统太难搞了,不要轻易尝试 | UC Berkeley 论文分享

AITNT-国内领先的一站式人工智能新闻资讯网站
AITNT资源拓展
根据文章内容,系统为您匹配了更有价值的资源信息。内容由AI生成,仅供参考
1
AI代理

【开源免费】Browser-use 是一个用户AI代理直接可以控制浏览器的工具。它能够让AI 自动执行浏览器中的各种任务,如比较价格、添加购物车、回复各种社交媒体等。

项目地址:https://github.com/browser-use/browser-use


2
AI工作流

【开源免费】n8n是一个可以自定义工作流的AI项目,它提供了200个工作节点来帮助用户实现工作流的编排。

项目地址:https://github.com/n8n-io/n8n

在线使用:https://n8n.io/(付费)


【开源免费】DB-GPT是一个AI原生数据应用开发框架,它提供开发多模型管理(SMMF)、Text2SQL效果优化、RAG框架以及优化、Multi-Agents框架协作、AWEL(智能体工作流编排)等多种技术能力,让围绕数据库构建大模型应用更简单、更方便。

项目地址:https://github.com/eosphoros-ai/DB-GPT?tab=readme-ov-file



【开源免费】VectorVein是一个不需要任何编程基础,任何人都能用的AI工作流编辑工具。你可以将复杂的工作分解成多个步骤,并通过VectorVein固定并让AI依次完成。VectorVein是字节coze的平替产品。

项目地址:https://github.com/AndersonBY/vector-vein?tab=readme-ov-file

在线使用:https://vectorvein.ai/(付费)

3
智能体

【开源免费】AutoGPT是一个允许用户创建和运行智能体的(AI Agents)项目。用户创建的智能体能够自动执行各种任务,从而让AI有步骤的去解决实际问题。

项目地址:https://github.com/Significant-Gravitas/AutoGPT


【开源免费】MetaGPT是一个“软件开发公司”的智能体项目,只需要输入一句话的老板需求,MetaGPT即可输出用户故事 / 竞品分析 / 需求 / 数据结构 / APIs / 文件等软件开发的相关内容。MetaGPT内置了各种AI角色,包括产品经理 / 架构师 / 项目经理 / 工程师,MetaGPT提供了一个精心调配的软件公司研发全过程的SOP。

项目地址:https://github.com/geekan/MetaGPT/blob/main/docs/README_CN.md

4
免费使用GPT-4o

【免费】ffa.chat是一个完全免费的GPT-4o镜像站点,无需魔法付费,即可无限制使用GPT-4o等多个海外模型产品。

在线使用:https://ffa.chat/

5
微调

【开源免费】XTuner 是一个高效、灵活、全能的轻量化大模型微调工具库。它帮助开发者提供一个简单易用的平台,可以对大语言模型(LLM)和多模态图文模型(VLM)进行预训练和轻量级微调。XTuner 支持多种微调算法,如 QLoRA、LoRA 和全量参数微调。

项目地址:https://github.com/InternLM/xtuner

6
prompt

【开源免费】LangGPT 是一个通过结构化和模板化的方法,编写高质量的AI提示词的开源项目。它可以让任何非专业的用户轻松创建高水平的提示词,进而高质量的帮助用户通过AI解决问题。

项目地址:https://github.com/langgptai/LangGPT/blob/main/README_zh.md

在线使用:https://kimi.moonshot.cn/kimiplus/conpg00t7lagbbsfqkq0