引言: AI 开发中的侦探工作

想象一下，你管理着一个由软件开发人员、研究人员和数据分析师组成的团队。你给他们分配了一个复杂的项目——比如分析某个城市的房地产市场——然后等待结果。但当报告交上来时，它是错的。数据是凭空捏造的 (幻觉) ，或者代码根本无法执行。现在，你必须弄清楚团队中谁掉链子了，以及事情具体是什么时候开始出错的。是分析师提取了错误的文件吗？是程序员写了有 bug 的脚本吗？还是经理给出的指令不明确？

现在，将这些人类员工换成大语言模型 (LLM) 智能体。这就是 LLM 多智能体系统的现实。这些系统非常强大，能够通过协作来解决编码、科学和数学方面的复杂任务。然而，就像人类团队一样，它们也会失败。而当它们失败时，调试 (debug) 简直是一场噩梦。

传统上，寻找失败的根本原因——这一过程被称为故障归因 (failure attribution) ——需要人类专家阅读数百行交互日志。这既缓慢、昂贵，又无法扩展。

但是，如果是让 AI 来调试 AI 呢？

在最近一篇题为 “Which Agent Causes Task Failures and When?” 的论文中，研究人员提出了一种新的自动化故障归因框架。他们引入了一个庞大的数据集 Who&When , 并评估了不同的算法，看看 LLM 是否能识别出它们自己的错误。

此图比较了基于故障日志的 LLM 多智能体系统中的手动与自动化故障归因方法。

如图 1 所示，目标是从成本高昂的手动归因转变为一种高效、自动化的流程，该流程可以精确定位“决定性错误步骤”。

多智能体生态系统

要了解我们如何查找错误，首先需要了解系统架构。研究人员将多智能体系统建模为一个回合制环境。

\[ { \mathcal { M } } = \Big \langle \mathcal { N } , S , A , P , \phi \Big \rangle . \]

这里，\(\mathcal{N}\) 代表智能体集合 (团队) 。在任何给定的时间步，恰好有一个智能体根据当前状态采取行动。系统产生一条“轨迹 (trajectory) ”——即状态和动作的历史记录——最终导向一个结果。

核心问题不仅仅是结果错误；而是要确定轨迹注定失败的那个具体时间点。

定义“决定性错误”

研究人员为故障的真正原因引入了一个正式定义。他们称之为决定性错误 (Decisive Error) 。

在一个失败的轨迹中 (最终结果 \(Z(\tau) = 1\)，代表失败) ，可能存在许多小错误。然而，一个决定性错误是指那个特定的动作，如果对其进行修正，结果就会从失败转为成功。

在数学上，他们定义了对轨迹的干预:

\[ \tau ^ { ( i , t ) } = \mathcal { T } _ { ( i , t ) } ( \tau ) , \]

如果在第 \(t\) 步对智能体 \(i\) 进行干预 (用好的动作替换坏的动作) ，并且系统随后成功了，那么这个特定的“智能体-步骤”对就是罪魁祸首。

\[ \Delta _ { i , t } ( \tau ) ~ = ~ \left\{ \begin{array} { l l } { { 1 , } } & { { \mathrm { i f } } ~ Z ( \tau ) = 1 \mathrm { ~ a n d } ~ Z \big ( \tau ^ { ( i , t ) } \big ) = 0 , } } \\ { { } } & { { } } \\ { { 0 , } } & { { \mathrm { o t h e r w i s e . } } } \end{array} \right. \]

自动化故障归因的目标是找到代表该决定性错误最早发生时刻的配对 \((i^*, t^*)\)。

\[ \begin{array} { r } { \mathcal { C } ( { \tau } ) = \ \{ ( i , t ) \ | \ \Delta _ { i , t } ( { \tau } ) \ = \ 1 \} , } \\ { ( i ^ { * } , t ^ { * } ) = \arg \operatorname* { m i n } _ { ( i , t ) \in \mathcal { C } ( { \tau } ) } \ t . } \end{array} \]

Who&When 基准测试

没有犯罪现场就无法训练侦探。为了使自动化故障归因成为可能，研究人员构建了 Who&When 数据集。

该数据集包含来自 127 个不同多智能体系统的故障日志，其中包括算法生成的团队和手工构建的系统 (如微软的 Magentic-One) 。这些不是玩具问题；它们是源自 GAIA 和 AssistantBench 等真实基准测试的故障。

Ground Truth 的成本

创建这个数据集是一项巨大的工程。人类专家必须手动分析日志，理解多个智能体的逻辑，并精确指出出错的具体行数。

标注过程的统计分析显示了高昂的劳动力成本和分歧率。

正如上面的图 2 所示，这是一项艰苦的工作。每个标注者花费了超过 30 小时来标记这些日志，且最初的分歧率很高。这种困难恰恰强调了我们为什么需要自动化——如果这对人类来说都很难，那么对开发者来说就无法扩展。

下面是这些日志的一个示例。你可以看到自动化系统 (或人类) 必须如何解析对话，以发现“助手 (Assistant) ”在第 82 步因错误地引导智能体而犯了错。

来自 Who&When 的任务示例，其中标注了故障责任智能体及其相应的错误步骤。

该数据集涵盖了各种复杂性。如下面的图 8 所示，日志范围从单个智能体的简短交互到涉及多达 5 个智能体和超过 100 个步骤的大规模日志。

Who&When 数据集中涉及的智能体数量和每个故障日志实例的总长度。

核心方法: 自动化调试的三种方式

有了数据集，研究人员测试了三种不同的策略，利用 LLM 来识别故障。每种方法代表了在上下文、精度和成本之间的不同权衡。

1. 一次性处理 (All-at-Once)

在这种方法中，LLM 就像阅读小说一样。你将整个故障日志一次性输入给模型，并问: “谁搞砸了，在什么时候？”

  • 优点: 模型可以看到完整的上下文。它知道故事的结局，这有助于理解哪个智能体使船偏离了航线。
  • 缺点: “大海捞针 (Needle in a haystack) ”问题。LLM 经常难以指向大量文本块中的具体行号。
  • 成本: 这是最便宜的方法，只需要一次 API 调用。 \[ C o s t _ { a l l - a t - o n c e } = C + n \cdot T _ { l } \]

2. 逐步处理 (Step-by-Step)

在这里，LLM 就像一个代码解释器。它逐行 (或逐步) 阅读日志。在每一步，它都会问: “这个动作正确吗？它会导致失败吗？”

  • 优点: 高精度。通过一次关注一步，模型不太可能产生关于步骤编号的幻觉。
  • 缺点: 视野狭窄 (Tunnel vision) 。它缺乏“未来”的上下文。它可能会标记一个看起来很奇怪但实际上在十步之后证明是绝妙的动作。
  • 成本: 非常昂贵。成本呈二次方扩展，因为上下文随着每一步都在增加。 \[ C o s t _ { s t e p - b y - s t e p } = \sum _ { i = 1 } ^ { i ^ { * } } ( C + i \cdot T _ { l } ) = i ^ { * } \cdot C + T _ { l } \cdot \frac { i ^ { * } \cdot ( i ^ { * } + 1 ) } { 2 } \]

这种方法将经典的计算机科学算法应用于调试。LLM 查看整个日志并决定: “错误是在前半部分还是后半部分？”然后它分割日志并重复此过程，直到隔离出错误。

  • 优点: 平衡了上下文和效率。
  • 缺点: 如果模型走错了一步 (例如，错误在后半部分却说在“前半部分”) ，就会造成级联故障并完全错过错误。
  • 成本: 中等。它呈对数扩展。 \[ C o s t _ { B i n a r y S e a r c h } = \sum _ { i = 1 } ^ { \lceil \log _ { 2 } ( n ) \rceil } ( C + \frac { n \cdot T _ { l } } { 2 ^ { i - 1 } } ) = \lceil \log _ { 2 } ( n ) \rceil \cdot C + \sum _ { i = 1 } ^ { \lceil \log _ { 2 } ( n ) \rceil } ( \frac { n \cdot T _ { l } } { 2 ^ { i - 1 } } ) \]

实验与结果: 最终裁决

那么，LLM 能调试它们自己吗？结果令人着迷，并揭示了一个“没有免费午餐”的场景。

谁 (Who) vs. 何时 (When)

研究人员在两个指标上评估了这些方法: 智能体级准确率 (Agent-Level Accuracy) (识别谁搞砸了) 和步骤级准确率 (Step-Level Accuracy) (识别何时) 。

展示三种故障归因方法性能的表格。一次性处理在智能体级表现最佳，逐步处理在步骤级表现最佳。

如表 1 所示，结果出现了分化:

  • 一次性处理 (All-at-Once) 是识别智能体 (Who) 的冠军。因为它看得到全貌，所以它理解哪个智能体应对导致失败的策略负责。
  • 逐步处理 (Step-by-Step) 是识别步骤 (When) 的冠军。其细粒度的关注点使其比其他方法能更好地精确定位失败的时刻。
  • 二分查找 (Binary Search) 充当中间地带，但很少获胜。

即使在测试不同的基础模型 (如 Llama-3 或 Qwen) 时，这一趋势也保持不变，如下面的雷达图所示。

比较不同模型性能的雷达图。趋势保持一致。

上下文长度限制

一个主要发现是，当对话变长时，当前的 LLM 会感到吃力。

展示随着日志长度增加性能下降的图表。

图 4 描绘了一幅严峻的画面。随着日志长度的增加 (从 Level 1 到 Level 5) ，所有方法的准确率都在直线下降。特别是步骤级准确率，在非常长的交互中几乎降至零。这证实了“大海捞针”问题是自动化调试的一个重大障碍。

“差不多”就够了吗？

研究人员也意识到，找到精确的步骤非常困难。但对于人类调试者来说，知道错误“在第 50 步左右”几乎和知道它“在第 50 步”一样好。

当他们放宽标准，允许 ±5 步的容差时，准确率显着提高。

表格显示步骤级准确率随着容差的增加而提高。

有趣的是, 一次性处理从这种容差中获益最大。虽然它难以命中确切的步骤，但它经常落在正确的邻域内。

统计可靠性

即使模型在处理单个实例时很吃力，它们能得出正确的总体统计数据吗？是的。

实际与预测的故障责任智能体直方图。分布非常吻合。

图 6 显示，“有罪”智能体的预测分布与 Ground Truth 非常吻合。这意味着即使系统不能完美地调试每一次运行，它也可以告诉开发者: “嘿，你的协调者 (Orchestrator) 智能体导致了 60% 的故障。” 这对于系统优化来说是一个有价值的见解。

混合方法与未来方向

既然一次性处理擅长寻找智能体，而逐步处理擅长寻找步骤，我们可以将它们结合起来吗？

研究人员测试了一种混合方法 (Hybrid Method) :

  1. 使用一次性处理来识别责任智能体。
  2. 仅对该智能体采取的行动使用逐步处理。

三种方法与混合方法的比较。混合方法在指标上胜出，但 token 成本最高。

混合方法实现了最佳的整体性能，显著提高了步骤级准确率。然而，有一个陷阱: 就 token 成本而言，这是最昂贵的方法。

推理模型能有所帮助吗？

最后，团队测试了最新的“推理”模型 (如 OpenAI o1 和 DeepSeek R1) ，看看它们先进的思维链能力是否能解决这个问题。

展示强推理模型性能的表格。它们改善了结果，但并未完全解决问题。

虽然推理模型确实提供了一些改进，但它们并不是灵丹妙药。准确率仍然很低，仍需要人工监督。

结论

论文 “Which Agent Causes Task Failures and When?” 为 AI 智能体领域开启了一扇新的大门。它让我们从单纯地构建智能体，过渡到理解如何维护和调试它们。

关键要点如下:

  1. 调试很难: 即使对于 SOTA 模型，精确定位多智能体对话中的故障原因也是一项困难的推理任务。
  2. 上下文 vs. 精度: 存在权衡。查看整个历史记录有助于识别不良行为者，但需要逐步检查才能找到确切的错误。
  3. Who&When 基准测试: 这个新数据集很可能成为测试未来模型诊断能力的标准。

随着多智能体系统越来越多地融入我们的软件基础设施，自动化故障归因将从“锦上添花”变为必不可少。这项研究为自愈 AI 系统奠定了基础，使其不仅能解决问题，还能理解它们为什么有时会失败。