当AI团队"各自为政"时，伊利诺伊大学用"梯度指纹"找出问题根源

来源：市场资讯

（来源：科技行者）

这项由伊利诺伊大学厄巴纳-香槟分校研究团队完成的工作，以预印本形式发布于2026年6月，论文编号为arXiv:2606.28187，有兴趣深入了解的读者可通过该编号查询完整论文。

假设你经营一家大型餐厅，厨房里分工明确：一个人负责切菜，一个人负责炒菜，一个人负责摆盘，最后一个人负责端给客人。当客人抱怨菜品难吃时，你怎么知道问题出在哪个环节？是菜切得不好，还是火候不对，还是摆盘时撒了奇怪的调料？如果只是笼统地告诉所有人"菜不好吃，大家都要改进"，效果恐怕非常有限。

这正是当今人工智能领域一个真实存在的困境。大语言模型（也就是像ChatGPT这类能对话的AI）正在被组成"团队"来协作完成复杂任务，比如同时处理订酒店、预约餐厅、查询火车的综合旅行规划需求。这种由多个AI分工协作的系统叫做"多智能体系统"。但问题在于，当整个系统给出一个糟糕的答案时，没有人知道该怪哪个AI——现有技术只能告诉你"整体结果不好"，无法精确定位是哪个环节出了问题。

伊利诺伊大学厄巴纳-香槟分校的研究团队为此提出了一套名为GBC（梯度基连接，Gradient-Based Connections）的方法，并配套开发了一个叫做AgentChord的实用框架。核心思路是：像追踪餐厅菜品问题的溯源流程一样，用数学方法精确计算出多智能体系统中每个AI的每一句输出，对最终结果到底有多大影响。找到症结所在后，系统就能有针对性地改进出问题的那个AI的"工作指令"，而不是让所有AI一起盲目调整。

一、多个AI协作为何容易"翻车"

回到餐厅的比喻。单个厨师独自完成一道菜，哪里做错了一目了然。但当五六个人分工合作时，每个人的失误都会叠加传递到下一个人，最终呈现在餐桌上的问题往往是多个环节共同造成的。更麻烦的是，中间某个人的一个小错误，可能被后面的人以完全不同的方式放大或者掩盖，追责起来极为复杂。

多智能体AI系统面临完全相同的困境。每个AI接收上一个AI的输出作为自己的输入，然后产生新的输出传递给下一个AI。这种链式结构意味着，哪怕第二个AI说了一句模糊的话，传递到第五个AI时可能已经演变成一个完全错误的结论。研究人员发现，现实中的多智能体系统经常遭遇"误协调"问题，各个AI之间信息传递效率低下，出错时又难以确认责任归属。

更根本的问题在于，目前主流的优化方法都依赖"粗粒度反馈"——也就是只告诉系统整体表现好不好，而不说明哪里具体出了问题。这就好比餐厅老板每次只对厨房喊一声"今天菜做得不行"，既不指出是哪道菜，也不说明是什么问题，厨师们只能凭感觉猜测和调整，效率极低。

正是为了解决这个问题，研究团队开始思考：能不能建立一种机制，像给每句话标注"影响力分数"一样，精确追踪多智能体系统中每个输出对最终结果的贡献？

二、梯度：这把追责的"解剖刀"是怎么工作的

要理解GBC的核心机制，先要理解"梯度"这个概念。在数学上，梯度描述的是"当你改变一个因素时，结果会怎样变化以及变化多大"。想象你在爬山，梯度就是地面的坡度——坡越陡，朝那个方向迈一小步，高度变化就越大。

在AI的世界里，梯度被用来衡量某个输入对输出的"敏感程度"。如果把上一个AI的某句话删掉或者改写，下一个AI的输出会发生多大变化？变化越大，说明那句话的影响力越强。GBC就是利用这种敏感度分析，为多智能体系统中每一对相邻AI之间的信息传递建立一个"影响力分数"。

具体来说，研究团队将整个多智能体系统建模成一张"计算图"——可以把它理解成一张流程图，每个节点代表一个AI，节点之间的箭头代表信息流向。每个AI接收来自前一个AI的输出，加上自己的任务说明，生成新的输出。GBC要做的，就是在每条箭头上标注一个数值，表示这条信息传递有多重要、影响力有多大。

为了计算这个影响力分数，研究团队设计了四种不同的计算方式。第一种叫"L1范数均值"，它计算上一个AI的输出中每个词对下一个AI产生输出的平均影响力，然后把这些影响力加总平均。第二种叫"L1范数最大值"，类似第一种，但只取所有词中影响力最大的那个作为代表，这样能减少无关词汇的干扰。第三种和第四种则引入了一个更精细的分析维度：不仅看梯度本身，还把梯度和词语本身的"权重"（即词向量）相乘，这种方法借鉴自生物信息学领域的归因分析技术，能捕捉到更细腻的"第一阶贡献"。四种方式分别对应均值和最大值两种汇总策略。

计算出所有影响力分数之后，GBC会从中挑选出每个AI的最重要前驱（默认保留影响力最高的一个），由此构建出一张"归因图"——只保留那些真正关键的信息传递路径，把那些影响微弱的路径过滤掉。这张归因图，就是后续追责和优化的"地图"。

三、沿着"错误地图"向前追溯

有了归因图之后，GBC的下一步是把"错误信号"从终点沿着这张地图向起点传播。

回到餐厅的比喻：客人抱怨后，服务员把反馈传递给摆盘的人，摆盘的人说"我的食材是从炒菜的人那里拿的"，于是反馈继续传递给炒菜的人，炒菜的人又说"菜是切菜的人切的"……这样一路追溯下去，就能找到问题的源头。

GBC做的正是这件事，只不过是用数学方法自动完成的。在系统的最终输出处，研究团队首先定义一个"语言损失"——用自然语言描述这次输出到底哪里出错了，比如"酒店的停车场信息预测错误"或者"遗漏了用户要求的餐厅价格区间"。这个损失信号附着在归因图的终点，然后按照图中的路径一级一级向前传播，途经每个节点时记录下"这个AI的哪次输出最应该为这个错误负责"。

整个回溯过程会生成若干条"归因轨迹"，每条轨迹就像一条从错误终点到某个可疑源头的面包屑路径。收集了足够多的轨迹之后，优化器就能知道：在这批训练样本中，哪些AI出错最频繁，哪些错误类型最常见，应该优先修改哪个AI的工作说明。

论文中用一个算法（Algorithm 1）详细描述了这个反向传播的过程，本质上是一次图的深度遍历：从损失节点出发，沿着归因图中的路径递归地向前追溯，把每条完整的路径记录下来存入对应AI的"轨迹库"，直到追溯到系统的初始输入为止。

四、AgentChord：让这一切真正可用的工程框架

理论上再好的方法，如果在实际运行时需要消耗天文数字的计算资源，也很难真正落地。梯度计算本身是非常消耗内存的操作，尤其是对于拥有数百亿参数的大型语言模型来说，为每一个词都计算梯度，内存开销会急剧膨胀。

研究团队为此专门设计了一种叫做"前缀梯度计算"的技巧。回想一下多智能体系统中每个AI的工作方式：它接收两类输入，一是固定的"工作说明"（也就是任务提示词），二是来自上游AI的动态输出。GBC只需要计算动态输出部分的梯度，工作说明是固定不变的，不需要对它做梯度追踪。

于是，系统先用不需要记录梯度的模式处理固定的工作说明，把计算结果缓存起来；然后再用需要记录梯度的模式处理动态输入部分。这样一来，存储梯度所需的内存量从正比于"总输入长度"缩减到正比于"动态输入长度"。如果一段工作说明占了总输入的一半，内存消耗就直接减少了一半，这在实际工程中是一个非常可观的优化。

AgentChord整合了GBC的归因机制和一个以大型语言模型充当优化器的提示词改写系统。每轮优化的流程是：让多智能体系统跑一批训练样本，收集归因轨迹和错误信息，然后把这些信息连同当前所有AI的工作说明、可用工具列表和历史优化记录一起交给优化器，让它分析问题并给出改进后的工作说明。优化器被要求不改变AI之间的调用顺序，只能修改工作说明的内容，并且被要求以特定格式输出改进建议和理由，以便系统自动解析和应用。

五、在真实任务上的表现：两个不同维度的考验

研究团队选择了两个公认具有挑战性的基准测试来验证GBC的效果，这两个测试考验的是完全不同维度的AI能力。

第一个测试叫MultiWOZ 2.4，这是一个任务导向对话基准，模拟的是用户同时在多个领域（酒店、餐厅、景点、火车、出租车）提出需求时，AI系统需要同时处理这些不同领域的预订和查询任务。研究团队为这个测试设计了一套管理员-工作员架构：一个"管理者AI"负责根据对话内容分配任务，五个"领域专家AI"分别负责酒店、餐厅、景点、火车、出租车的API调用，最后一个"回复者AI"负责将所有信息整合后生成用户看到的最终回答。

评估指标包含六个维度：Inform分数（系统是否查询到了正确的信息）、Success分数（整个对话是否成功完成了用户的目标）、JGA（联合目标准确率，衡量每个对话轮次中系统对用户意图的理解是否完全正确）、槽位召回率、槽位精确率和槽位F1分数（后三者衡量系统对用户需求中各个具体字段的识别准确程度）。

实验用了两种不同的底层模型：Llama-3.3-70B-It和Qwen-3-32B。结果显示，优化之前，多智能体系统并不比单个AI表现更好——以Qwen-3-32B为例，多智能体系统的Inform分数（95）和Success分数（80）确实高于单智能体（88和40），但JGA（28.9 vs 44.4）和槽位F1（79.3 vs 88.5）却明显更差，说明多智能体系统虽然"大方向对了"，但对细节的把握反而更混乱。

经过GBC优化之后，情况发生了显著变化。以Qwen-3-32B加上"L1范数均值"连接权重的组合为例，JGA从28.9跃升至54.4，槽位F1从79.3上升至91.4，同时Inform达到99.0、Success达到94.0。这个优化后的多智能体系统在所有六个指标上都超越了单智能体基线，说明GBC成功地把一个"乱糟糟"的多AI团队改造成了一个真正有效的协作体系。

整个优化过程使用了30个训练样本，每处理3个样本更新一次提示词，共进行10个优化步骤。从优化轨迹来看，Inform分数和槽位召回率在整个过程中始终保持较高水平，而JGA、槽位精确率和槽位F1则呈现出清晰的上升趋势。Success分数的波动最大，说明完成用户的完整目标这件事涉及更长链路的协调，仅靠提示词优化改善起来相对困难。

第二个测试叫τ-bench，考验的是一种完全不同的能力：AI系统需要通过多轮对话、调用各种工具（如查询订单、修改商品、处理退换货等）来完成零售场景下的复杂客服任务。与MultiWOZ的静态评估不同，τ-bench要求系统动态地与模拟用户交互，每一步工具调用都会影响后续对话走向，更接近真实的业务场景。

研究团队同样设计了管理者-工作员架构，其中专家AI分别负责用户信息查询、商品检索、订单修改、售后处理和用户档案管理五个子任务。评估指标分为三类：动作奖励（工具调用序列是否与标准答案一致）、输出奖励（最终回答是否包含所有必要信息）和综合奖励（两者的乘积，要求两方面都做对才能得分）。

优化之前，Qwen-3-32B多智能体系统的综合奖励只有13.0，低于单智能体的22.6。经过GBC优化，以"L1范数最大值"连接权重为例，综合奖励提升至24.3，超过了单智能体基线。"输入乘积均值"策略同样达到了24.3的综合奖励，主要得益于动作奖励从13.9大幅提升至27.0。对于Llama-3.3-70B-It，所有优化变体都超过了未优化基线，其中"输入乘积最大值"策略表现最佳，综合奖励从6.1提升至9.6。

六、归因质量与优化效果之间的隐藏联系

研究团队还做了一项颇有意思的分析：不同的连接权重计算方式，归因的准确性有多大差异？这种差异又是否能解释优化效果的差异？

他们用一种直观的方式衡量归因准确性：检查每条归因轨迹是否正确地包含了"应该负责"的专家AI。在MultiWOZ中，如果当前对话涉及酒店预订，那么正确的归因轨迹应该包含酒店专家AI；如果涉及火车查询，就应该包含火车专家AI。

分析结果揭示了一个清晰的规律：无论使用哪种底层语言模型（Llama还是Qwen），L1范数均值和L1范数最大值这两种方式的归因准确率始终高于基于输入乘积的两种方式。而在最终的任务表现上，L1范数类方法的优化效果也确实更好。这表明，归因越准确，优化器收到的"错误定位信息"就越精确，最终改进提示词的效果也就越显著。用研究团队的话说："更高的归因质量与更强的优化效果相关联。"

此外，研究团队还分析了不同AI在优化过程中被更新的频率。他们计算了一个叫"归一化更新频率"的指标，衡量每个AI在"相关轮次"中被优化器修改的比例。结果发现，领域专家AI（如酒店、餐厅、火车等）的更新频率明显高于管理者AI和回复者AI。这与错误分析的结果高度吻合：主要的错误类型是跨域错误（管理者把任务分配给了错误的专家AI）、信息遗漏（专家AI没有提取到对话中的关键信息）和过度预测（专家AI猜测了用户没有明确说出的需求），这些错误的根源主要在于各个专家AI自身的工作方式，而不是管理者或回复者的问题。

在τ-bench的错误分析中，最常见的错误类型是"检索和识别失败"，即AI无法在复杂的多轮对话中正确定位到当前正在讨论的订单、用户或商品。这种基础信息定位失败后，后续所有的工具调用和回复内容都会出错，属于"牵一发而动全身"的关键失误。其次是工具误用、管理者指令不清、过早放弃任务和错误的成功判断。这些错误模式揭示了τ-bench的核心难点：它要求系统在多个回合中维护准确的任务状态，这对AI之间的信息传递精度要求极高。

七、这套方法的边界与尚未解决的问题

任何方法都有其局限性，研究团队在论文中坦诚地讨论了GBC目前面临的挑战。

计算成本是最直接的问题。即便有了前缀梯度计算的优化，每次运行仍然需要对大型语言模型进行多次前向和反向传播，比那些完全不需要访问模型内部的"黑盒方法"要慢得多、贵得多。从时间数据来看，使用Llama-3.3-70B-It在MultiWOZ上完成10个优化步骤需要约16至17小时，使用Qwen-3-32B也需要8至9.5小时，这对快速迭代开发来说是一个较大的障碍。

语言损失的设计质量也是关键。GBC的优化信号来自于用自然语言描述"错在哪里"，但如果这个描述本身不够准确或者覆盖了错误的方面，就会给后续的归因和优化带来误导。研究团队指出，不同任务的语言损失需要专门设计，没有一个通用模板能适应所有场景。

梯度方法本身是一种"一阶近似"，它假设各因素之间的影响是线性叠加的。现实中AI系统内部的交互往往是高度非线性的，尤其是在多轮对话场景下，某个AI早期的一句话可能通过复杂的路径对十几步之后的输出产生难以预料的影响，而梯度方法未必能完全捕捉这种长距离的复杂作用。

实验的范围也存在局限，目前只验证了管理者-工作员这一种架构模式，在MultiWOZ（任务型对话）和τ-bench（工具使用型对话）两个基准上进行了测试。GBC能否同样有效地应用于代码生成、开放式推理或者更大规模的自主智能体系统，还有待进一步验证。

还有一些错误类型在优化后仍然存在，比如跨域协调错误和信息遗漏。研究团队认为这些问题可能部分源于底层语言模型自身的能力上限，并非仅靠优化提示词就能完全解决的。

说到底，这项研究触碰到了一个长期被忽视的核心问题：多个AI协作时，如何知道谁应该对错误负责。就像管理一个大型团队，精细的绩效追踪比笼统的集体表扬或批评更能帮助每个人找到改进方向。GBC提供的"梯度指纹"机制，本质上就是给多AI团队建立了一套精确的追责和改进体系。

对于普通用户来说，这项研究意味着未来那些复杂的AI助手——比如同时帮你规划旅行、预订酒店、查询航班、推荐餐厅的全能助理——将可能变得更加可靠，犯错时也能更快地自我修正。对于AI开发者来说，这提供了一种比现有方法更精细的调试和优化工具，让构建可靠的多智能体系统从"凭经验猜测"变得更接近"有据可查的工程"。

值得继续追问的是：随着AI团队越来越大、任务越来越复杂，这种基于梯度的归因方法能否跟上扩展的需求？更高阶的非线性交互效应是否需要完全不同的追责思路？这些问题的答案，或许正藏在未来几年的研究进展里。有兴趣深入了解这项工作的读者，可以通过arXiv编号2606.28187查询完整论文及配套代码库。

Q&A

Q1：GBC方法和现有的多智能体优化方法（比如DSPy、TextGrad）有什么本质区别？

A：现有方法主要依赖整体任务表现来优化系统，只知道"整体结果好不好"，无法精确定位是哪个AI的哪次输出造成了错误。GBC的核心区别在于它能在单词（token）层面计算每个AI输出对下游AI的影响力，建立精细的归因图谱，把"整体批评"转变为"精准定位"，从而让优化器能够针对真正出问题的环节进行修改，而不是让所有AI一起盲目调整。

Q2：AgentChord框架运行一次需要多少时间和计算资源？

A：实验在配备四块NVIDIA A40 GPU、208GB内存的单台服务器上进行。完成10个优化步骤，使用较大的Llama-3.3-70B-It模型大约需要16至17小时，使用较小的Qwen-3-32B模型需要8至10小时。不同的连接权重计算方式（四种变体）之间的时间差异不大，主要耗时来自底层模型的规模和任务本身的复杂度。

Q3：GBC在MultiWOZ上的实验结果，优化后多智能体系统比单智能体强多少？

A：以Qwen-3-32B为例，优化前多智能体系统的联合目标准确率（JGA）只有28.9，远低于单智能体的44.4。经过GBC优化后，JGA提升至54.4，超过单智能体约10个百分点；槽位F1从79.3提升至91.4，高于单智能体的88.5；Inform和Success分数分别达到99.0和94.0，也均高于单智能体基线。