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

2025-03-26 12:30:32 科技

图片

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)任务验证和终止。

相关研究论文以(yǐ)“Why Do Multi-Agent LLM Systems Fail?”为(wèi)题(tí),已(yǐ)发(fā)表(biǎo)在(zài)预(yù)印(yìn)本(běn)网(wǎng)站(zhàn) arXiv 上(shàng)。

图(tú)片(piàn)

论(lùn)文链(liàn)接(jiē):https://arxiv.org/abs/2503.13657

具(jù)体(tǐ)而(ér)言(yán),他(tā)们提出了首个基于经验的多 agent 系统故障分类法——MASFT,理解和缓解多 agent 系统故障提供了一个结构化框架。

同时,他们也开发了一个可扩展的“LLM-as-a-judge”评估管道(dào),用(yòng)于(yú)分(fēn)析新的多 agent 系统性能和诊断故障模式。

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

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

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

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

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

多达(dá) 14 种(zhǒng)故(gù)障(zhàng)模(mó)式(shì)

在(zài)这(zhè)项(xiàng)工(gōng)作(zuò)中(zhōng),研(yán)究(jiū)团(tuán)队(duì)使(shǐ)用(yòng)了(le)扎(zhā)根(gēn)理(lǐ)论(lùn)(Grounded Theory)这(zhè)一(yī)定(dìng)性(xìng)研(yán)究(jiū)方(fāng)法(fǎ),直(zhí)接(jiē)从(cóng)经(jīng)验(yàn)数(shù)据(jù)中(zhōng)构(gòu)建(jiàn)理(lǐ)论(lùn),而(ér)不(bù)是(shì)检(jiǎn)验(yàn)预(yù)定(dìng)义(yì)的(de)假(jiǎ)设(shè),使故障模式的识别有机地产生。

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

图片

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

为了实现自动故障识别,他(tā)们(men)开(kāi)发(fā)了(le)基(jī)于(yú) LLM 的(de)标(biāo)注(zhù)器(qì),并(bìng)验(yàn)证(zhèng)了(le)它(tā)的(de)可(kě)靠(kào)性(xìng)。

然(rán)后(hòu),他(tā)们(men)进(jìn)行(xíng)了(le)标(biāo)注(zhù)器(qì)之(zhī)间(jiān)的(de)协(xié)议(yì)研(yán)究(jiū),通(tōng)过(guò)添(tiān)加(jiā)、删(shān)除(chú)、合(hé)并(bìng)、拆(chāi)分(fēn)或(huò)修(xiū)改(gǎi)定(dìng)义(yì)反(fǎn)复(fù)调(diào)整(zhěng)故(gù)障(zhàng)模(mó)式(shì)和(hé)故(gù)障(zhàng)类(lèi)别(bié),直(zhí)到(dào)达(dá)成(chéng)共(gòng)识(shi)。这(zhè)一(yī)过(guò)程(chéng)反(fǎn)映(yìng)了(le)一种学习方法,即不断完善分类法,直至达到稳定性,并通过 Kappa 系数来衡量标注器之间的一致性。

图片

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

最终,MASFT 包含了 3 个总体故障类别:规范和系统设计故障;agent 间错位;任务验证和终止,确定了多 agent 系统在执行过程中可能遇到的 14 种(zhǒng)细(xì)粒(lì)度(dù)故(gù)障(zhàng)模(mó)式(shì)。

MASFT 还(hái)将(jiāng)多(duō) agent 系(xì)统(tǒng)的(de)执(zhí)行(xíng)划(huà)分(fēn)为(wèi) 3 个(gè)阶(jiē)段(duàn):执(zhí)行(xíng)前(qián)、执(zhí)行(xíng)中(zhōng)和(hé)执(zhí)行(xíng)后(hòu),确(què)定(dìng)了(le)每(měi)个(gè)细(xì)粒(lì)度(dù)故(gù)障(zhàng)模(mó)式(shì)可(kě)能(néng)发(fā)生(shēng)的(de)多(duō) agent 系(xì)统(tǒng)执(zhí)行(xíng)阶(jiē)段(duàn)。

图(tú)片(piàn)

图(tú)|多(duō) agent 系(xì)统(tǒng)故(gù)障(zhàng)类(lèi)别(bié)相(xiāng)关矩(ju)阵(zhèn)

另(lìng)外(wài),他(tā)们(men)发(fā)现(xiàn),多(duō) agent 系(xì)统(tǒng)面(miàn)临(lín)着(zhe)与(yǔ)复(fù)杂(zá)的(de)人(rén)类(lèi)组(zǔ)织(zhī)类(lèi)似(shì)的(de)问(wèn)题(tí),其(qí)故(gù)障(zhàng)模(mó)式(shì)与(yǔ)在(zài)人(rén)类(lèi)组(zǔ)织(zhī)中(zhōng)观(guān)察(chá)到(dào)的(de)常(cháng)见(jiàn)故(gù)障(zhàng)模(mó)式(shì)一(yī)致(zhì)。“不(bù)要(yào)求(qiú)澄(chéng)清(qīng)”破(pò)坏(huài)了(le)“尊(zūn)重(zhòng)专(zhuān)业(yè)知(zhī)识(shi)”,“agent 错(cuò)位(wèi)”体(tǐ)现(xiàn)了(le)加(jiā)强(qiáng)等(děng)级(jí)区(qū)分(fēn)和(hé)协(xié)调(diào)角(jiǎo)色(sè)分(fēn)配(pèi)的(de)必(bì)要(yào)性(xìng)。

多(duō) agent 协(xié)作(zuò)的(de)有(yǒu)效(xiào)性(xìng),仍(réng)有(yǒu)待(dài)提(tí)高(gāo)

针(zhēn)对(duì)以(yǐ)上(shàng)所(suǒ)有(yǒu)的(de)故(gù)障(zhàng)类(lèi)别(bié),研(yán)究(jiū)团(tuán)队(duì)提(tí)出(chū)了(le)战(zhàn)术(shù)策(cè)略(è)和(hé)结(jié)构(gòu)策(cè)略(è)。

战(zhàn)术(shù)策(cè)略(è)涉(shè)及(jí)针(zhēn)对(duì)特(tè)定(dìng)故(gù)障(zhàng)模(mó)式(shì)的(de)直(zhí)接(jiē)修(xiū)改(gǎi),如(rú)改(gǎi)进(jìn)提(tí)示(shì)、agent 网(wǎng)络(luò)的(de)拓(tà)扑(pū)结(jié)构(gòu)和(hé)对(duì)话(huà)管(guǎn)理(lǐ)。然(rán)而(ér),两个案例研究证明,这些方法的有效性并不一致。

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

图片

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

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

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

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

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

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

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

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

图片

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

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

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

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

作者:与可