多智能体系统的失败归因不能只有一个答案

引言

论文原文Rethinking Failure Attribution in Multi-Agent Systems: A Multi-Perspective Benchmark and Evaluation。

多智能体系统的失败归因不能只有一个答案

多智能体系统的调试，正在被一个看起来合理、但其实很危险的假设误导：一次失败只有一个确定的根因，找到那个“唯一正确”的出错步骤就够了。这个假设在单代理、短链路任务里也许还能勉强成立，但一旦系统由多个 LLM 代理协作完成任务，失败往往不是单点、单因、单视角的。不同的人沿着不同的“理想执行路径”回看同一段日志，很可能会把责任落在不同步骤上，而且这些判断都说得通。

这会直接影响两件事。第一，基准怎么建。如果数据集只接受一个标准答案，大量本来合理的归因都会被判错。第二，模型怎么评。如果评测方式本身忽略了归因的多义性，就会低估 LLM 的真实能力，甚至得出“模型几乎不会做失败归因”的结论。真正更贴近现实的做法，不是逼系统猜中唯一标签，而是让它给出多个合理归因，并说清楚每种归因背后的判断逻辑。

失败为什么不是单选题

多智能体系统里的失败，常常来自一串相互依赖的决策，而不是某个孤立动作本身。一个代理的错误规划，可能把后续代理引向错误路径；一个代理已经暴露了问题，另一个代理仍然继续执行，也可能同样构成失败；甚至某一步本身没有明显“犯错”，但它把系统带进了一个不该接受的策略分支，回头看也可能是责任起点。

一个很典型的例子是：用户询问“1928 年夏季奥运会哪个国家派出的运动员最少”，系统中的协调代理先调用数据分析代理，后者假设可以访问历史数据，于是直接构造了一份示例数据并写 Python 代码处理，之后系统继续执行、统计并给出答案。看同一段日志，至少会出现三种都合理的归因方式：有人会把问题归到最早的规划步骤，因为协调代理一开始就把任务交给了不具备真实数据获取能力的代理；有人会把责任落在生成代码的那一步，因为代码中引入了虚构数据；也有人会认为真正导致失败的是继续运行这段代码的步骤，因为系统已经沿着错误前提往前推进了。

这正是多智能体系统失败归因的核心难点。失败不是总能被压缩成“第 7 步错了”这种单一结论。它更像是一组可竞争、但同时成立的因果解释。视角差异并不意味着谁更“主观”，而是意味着不同分析者对“正确执行轨迹”有不同预期。有人期待先上网查真实数据，有人接受先写代码再补数据验证；一旦预期不同，责任落点就会不同。

这也是为什么专家之间的分歧并不低。在复杂执行日志上，成对标注者之间的分歧率可以接近 60%。如果一个基准强行规定只有一个正确步骤，它测到的就不再是“谁更会调试”，而更像“谁更像数据集设计者当时的那种看法”。

从唯一标签到多视角解释

传统失败归因的形式很简单：给定一段失败轨迹 $\tau$，输出一个固定的失败步骤集合 $F^*$。也就是把问题写成

$$ f_{\mathrm{det}}(\tau)\rightarrow F^* $$

这里的关键假设是，$F^*$ 是唯一正确答案。很多已有设定甚至进一步把它简化成只选一个步骤。

更贴近真实调试场景的形式，应该把输出改成一组“步骤 + 理由”的组合：

$$ F(\tau)={(t_k,r_k)}_{k=1}^{K} $$

其中，$t_k$ 表示某个被认为诱发失败的时间步，$r_k$ 表示为什么这个步骤在第 $k$ 种视角下应当被归因为失败。$K$ 不是固定的，因为一段执行日志可能只有一种明显归因，也可能同时容纳多种合理解释。

这个改动看起来只是把单标签改成多标签，实际意义却大得多。因为调试真正需要的不是“你猜中了哪个标准答案”，而是两类信息：第一，哪些步骤值得优先排查；第二，这些步骤为什么值得排查，以及更好的动作应该是什么。只有把归因理由和理想动作一起保留下来，失败归因才真正能服务于系统改进。

真正有用的基准需要把分歧保留下来

如果接受“失败归因天然带有多视角”这个前提，那么基准设计也必须一起改。更合理的做法，是先把分歧保留下来，再把它整理成对调试有用的结构化信号。

一个更完整的基准构造方式大致是这样的。先收集来自不同多智能体系统和不同任务类型的失败执行日志，再让多名具备相关经验的专家独立标注每一步：这一步是不是 failure-inducing step，为什么是，以及理想情况下应该怎么做。标注时不给任何预设视角，不暗示“应该从哪里开始找错”，让不同标注者按自己的技术判断形成独立解释。

围绕这个思路构建的 MP-Bench，一共收集了 289 条执行日志，覆盖 121 种不同的多智能体配置。日志来自两类系统：一类是手工设计的多代理系统，一类是自动生成的多代理系统；任务则来自 GAIA 和 AssistantBench 这样的代理能力评测任务。数据中包含 169 条手工系统执行日志，平均每条 33 个交互步骤；还有 120 条自动系统日志，平均每条 8 个步骤。

标注质量是这个基准最重要的部分。三位标注者都经过两轮筛选：先做技术访谈，确认其理解多智能体失败归因的含义；再做测试标注，由人工审核其正确性、一致性和解释质量。最终每条日志都由三位专家独立完成逐步标注。整个过程大约消耗了 346 个专家工时，平均每位标注者投入约 115 小时。手工系统日志平均每条需要约 31 分钟，自动系统日志平均每条约 14 分钟。

这些标注不会被粗暴压成一个唯一答案，而是先计算“共识率”。如果某一步被三位标注者都认定为失败，它的共识率就是 100%，说明它更像一个跨视角都成立的失败点，调试优先级应该最高。若某一步只被一部分人标记为失败，它仍然有价值，只是更接近“依赖视角的失败模式”，优先级相对低一些。只有至少被一位标注者认为失败的步骤才会进入最终排序，其他步骤直接排除在归因结果之外。

自由文本部分也没有被丢掉。每个失败步骤对应的“失败原因”和“理想动作”会被整合成统一表述，但整合的目标不是发明新解释，而是覆盖不同标注者已经提出的理由。这样做的结果，是基准不只告诉你“可能错在第几步”，还告诉你“为什么错”和“应该怎么改”。

这套设计带来的一个直接发现是，多视角不是边角现象，而是主体现象。最终统计里，只有 16.2% 的失败步骤能获得三位标注者完全一致的判断；27.8% 的步骤只得到两位标注者认同；56.1% 的步骤只被一位标注者判定为失败。

这组数字说明，真正应该被解释的不是“为什么会有分歧”，而是“为什么过去的基准假设几乎没有分歧”。

评测也要围绕调试价值来设计

当基准不再追求唯一标签，评测方式也不能再是简单分类。更合适的做法，是把模型输出看成一种“失败步骤优先级排序”。

具体来说，可以让同一个 LLM 以一定采样温度运行 $N$ 次，每次都独立输出它认为的失败步骤、失败原因和理想动作。然后像处理人工标注一样，把这些结果按共识率整合成一个排序。这样得到的，不是某一次抽样的偶然答案，而是模型在多个可能视角上的整体分布。

排序之间的比较可以用 nDCG@K。这个指标的好处在于，它不只关心“有没有猜中”，还关心“是不是把最重要的失败点排在前面”。这比单纯看分类准确率更贴近调试场景，因为工程上总是先修最关键、最稳定、最影响全局的失败步骤。

归因理由也需要单独评。一个可用的失败归因系统，不能只会点名，还要会解释。更完整的做法，是比较模型生成的失败原因和理想动作，看看它是否与人工判断一致，是否真正锚定了执行上下文，解释是否充分，提出的替代动作是否合理。这样评出来的才是“能不能帮助人调试”，而不是“会不会复述标签”。

重新评测后，LLM 的表现和过去看到的完全不同

一旦评测从“单一正确答案”切换到“多视角排序 + 理由质量”，对 LLM 的结论会明显改变。过去一些基于确定性基准的结果会让人觉得，LLM 在步骤级失败归因上几乎接近随机；但换成多视角设定后，情况并不是这样。

先看失败步骤归因本身。在手工构建的多代理系统上，表现最好的模型在 nDCG@5 上可以达到大约 0.44，而随机基线只有约 0.13；在自动生成的多代理系统上，最好的结果接近 0.79，而随机基线大约是 0.31。这个差距说明，模型并不是不会做失败归因，它只是过去常常被拿去回答一个被设错了的问题。

再看解释质量。把模型生成的失败原因和理想动作与人工整合结果对比，主流模型的整体 reasoning 分数大多落在 7.5 到 8.25 之间。这意味着模型不仅能指出多个合理失败点，还能给出与人类专家相当贴近的解释。这里表现最稳定、最强的一类模型是 Claude-Sonnet-4.5；GPT-4.1、GPT-5.1 和 GPT-OSS-120B 也都表现扎实；体量更小的 Qwen3-8B 则在归因和解释上明显偏弱。

另一个重要发现是，采样本身不是噪声，而是能力的一部分。对同一个模型多次采样时，不同样本之间会出现明显分歧，而这种分歧模式和人类标注者之间的分歧很像。这不是模型“不稳定”，而是模型在探索多个合理归因视角。完全确定性的解码会压缩这种输出空间，通常不利于恢复多视角归因；但温度也不是越高越好，结果更像是只要避免完全锁死输出，适度随机性就已经足够。

样本数也很关键。把单个模型从 3 次采样增加到 5 次、10 次，排序表现普遍继续提升。这说明多次采样并不是重复劳动，而是在逐步逼近模型内部那组更稳定的“失败信号分布”。

还有一个很有实践价值的结果：多模型组合比单模型反复采样更强。把来自不同家族的模型放在一起，比如 GPT、Claude 和 OSS 模型各采样一次，再合并结果，通常会优于单个模型连跑三次。原因不难理解：同一模型的多次采样，更多是在同一种思维风格里做局部扰动；不同模型之间的差异，才更可能带来真正互补的归因视角。对自动系统日志，GPT-5.1、GPT-OSS-120B 和 Claude-Sonnet-4.5 的组合能把 nDCG@5 进一步推到 0.82 左右，超过任何单模型结果；手工系统上，多模型组合也同样优于单模型。

对实践最重要的启发

真正可用的多智能体失败归因系统，不应该追求“一次输出一个标准答案”，而应该追求“稳定收集多个合理归因，并把它们整理成可执行的调试优先级”。这意味着系统设计目标本身要改：从找唯一元凶，变成覆盖主要因果视角。

在推理配置上，完全确定性的解码并不是最稳妥的默认选项。对这种任务来说，适度非确定性更有助于暴露不同归因路径，再通过聚合把噪声压下去，把有效分歧留下来。

在模型选择上，优先考虑跨家族组合，而不是只依赖单个最强模型。不同模型学到的偏好、策略和解释习惯并不一样，这种差异正好适合做故障诊断中的“多专家会诊”。

在工程流程上，最适合落地的形式是分层排查。先看共识率最高的失败步骤，因为这些步骤最可能是跨视角都成立的核心问题；再看中低共识步骤，它们往往对应策略分歧、能力边界或者框架设计缺陷。这样做比“修唯一标签指向的那一步”更符合真实系统的迭代方式。

这件事真正改变的是调试思路

多智能体系统的失败归因，关键不是把复杂过程压成一个答案，而是承认失败本来就可能有多个合理解释，并把这些解释转化成可操作的调试信号。只要这个前提被接受，很多过去看上去矛盾的现象就会变得清楚：为什么专家之间经常分歧，为什么模型多次采样会给出不同答案，为什么不同模型组合后反而更强，为什么旧基准会低估 LLM 的能力。

当然，这样的基准也还不算终点。当前覆盖的任务仍以通用助手场景为主，规模和框架多样性也受制于高质量人工标注的成本。未来还需要把失败归因扩展到科研、软件工程、创作等更专业的代理任务，也需要探索“专家标注 + 自动扩展”的混合流程，才能在不牺牲质量的前提下继续放大覆盖面。

但有一件事已经足够明确：多智能体系统的失败归因不该再被当成一个单选题。真正有价值的系统，不是替你挑出那个唯一的罪魁祸首，而是把整片可能的因果空间照亮，让调试从猜测变成诊断。