IBM 与伯克利诊断企业智能体失败原因

企业级 AI 智能体在复杂的 IT 自动化任务中表现如何？为什么它们会失败？IBM Research 与加州大学伯克利分校的研究人员联手，通过 ITBench 基准测试和 MAST 诊断框架，深入剖析了这个问题。

智能体基准测试的“黑盒”问题

像 ITBench 这样的基准测试，正成为衡量智能体在高风险 IT 自动化任务中性能的标准。在 ITBench 中，智能体扮演站点可靠性工程师（SRE）或安全分析师的角色，负责诊断 Kubernetes 故障、修补漏洞或管理生产环境的云成本。

这类基准测试通常使用成功率作为主要评估指标。然而，这个指标对于构建健壮的系统来说远远不够。知道一个智能体系统在 ITBench 上取得了 14% 的成功率，只能告诉我们它失败了，但无法解释原因：它失败是因为忘记了上下文？因为幻觉（Hallucination）出了一个错误命令？还是因为它根本没有终止？

如果没有一套全面的方法来诊断这些失败，开发者只能靠猜测，常常诉诸于盲目的提示词调整，结果往往是解决了一个问题，却又引发了另一个。

为了分析复杂智能体系统的失败模式，我们开发了 MAST（多智能体系统失败分类法）。MAST 为这些不透明的基准测试评估带来了更多洞见。它基于对七个不同框架的 1600 多条执行轨迹的严格分析，为智能体失败提供了一个标准化的分类体系。

MAST 将非结构化的执行日志，转化为基于 14 种不同模式的、结构化的“失败向量”。这些模式分为三个关键类别：

• FC1：系统设计问题（“骨架”）
  • 这类失败源于智能体的架构和角色定义。
  • 示例： FM-1.3 步骤重复（循环），FM-1.4 对话历史丢失（内存泄漏），FM-1.5 未意识到终止条件（未能停止）。
• FC2：智能体间错位（“沟通”）
  • 这类失败源于运行时智能体之间或智能体与环境之间的交互方式。
  • 示例： FM-2.2 未能请求澄清（假设而非询问），FM-2.3 任务脱轨（偏离主题）。
• FC3：任务验证（“质量控制”）
  • 这类失败涉及智能体输出的质量保证。
  • 示例： FM-3.1 过早终止（过早放弃），FM-3.3 错误验证（幻觉成功）。

实验：诊断 ITBench 智能体

我们将 MAST 应用于 ITBench，以验证其能否让智能体评估更具可操作性，并深入了解失败模式。ITBench 是一个流行的评估套件，涵盖 SRE、安全/合规和 FinOps 领域的 IT 自动化任务。

我们标注了 310 条由 Codex 构建的 SRE 智能体在真实环境中产生的 ITBench SRE 执行轨迹。这些轨迹捕捉了智能体与其工具之间的自然语言交互，涉及三个代表不同能力层级的模型：Gemini-3-Flash、Kimi-K2 和 GPT-OSS-120B。这让我们能够超越简单的成功率指标，探究驱动这些结果的不同失败特征。为此，我们使用了召回率（Recall）分数，因为模型设计上最多只输出 3-5 个结果，且 SRE 更偏好召回率而非 F-1 分数。

• Gemini-3-Flash: 100 条轨迹（平均召回率 75.5%）
• Kimi-K2: 105 条轨迹（平均召回率 28.6%）
• GPT-OSS-120B: 105 条轨迹（平均召回率 12.4%）

发现一：前沿模型失败更“干净”，开源大模型易连锁崩溃

当我们检查失败的轨迹时，三个模型在失败复杂性上呈现出清晰的层级差异。这通过每次失败运行中观察到的不同失败模式数量来衡量。

• Gemini-3-Flash: 每次失败轨迹平均 2.6 个失败模式
• Kimi-K2: 每次失败轨迹平均 4.7 个失败模式
• GPT-OSS-120B: 每次失败轨迹平均 5.3 个失败模式

这种失败模式密度的差异，揭示了这些系统崩溃方式的根本不同。Gemini-3-Flash 展现出一种“外科手术式”的失败特征。即使在失败的运行中，它也能保持较高的内部一致性，通常只因为一个孤立的失败（比如错误的验证步骤）而失败。这些失败是精确的，也更容易诊断。

在光谱的另一端，GPT-OSS-120B 则遭受连锁崩溃。在这些轨迹中，我们观察到错误会随着时间推移而叠加。流程早期一个小的推理错配，常常导致偏离任务规范，进而引发智能体的完全脱轨。Kimi-K2 处于中间地带，其失败比前沿模型更频繁、更复杂，但尚未达到 120B 开源权重模型中看到的系统性不稳定程度。

这一发现的意义在于，更高的成功率往往伴随着更孤立的失败。那些以较少并发问题失败的系统，其行为更具可预测性，也更容易通过有针对性的工程干预来改进。

发现二：“非致命”与“致命”失败

MAST 带来的最关键洞见之一，或许是区分系统能够容忍的失败与对下游任务成功构成致命打击的失败。通过比较失败模式在成功轨迹与失败轨迹中的分布，我们可以将它们分为三类。

非致命（良性）缺陷

在三个模型的运行中，某些失败模式即使在最终成功的任务里也频繁出现。这些通常是结构性摩擦，而非致命错误。

• FM-1.3 步骤重复： 超过 90% 的成功 Kimi-K2 运行中都存在此模式。在 SRE 领域，迭代通常是必要的。智能体可能会多次查询同一指标，以验证服务是否稳定或修复是否生效。有趣的是，Gemini-3-Flash 在其失败的轨迹中反而表现出更少的重复，这可能意味着它有时失败是因为迭代不足。
• FM-1.1 不遵守任务规范： 智能体经常偏离严格的工具格式或顺序指令，但仍能设法找到正确的根本原因。

这种区分正是 MAST 的价值所在。它让我们可以忽略像故障排除中常见的重复这类良性失败，转而专注于那些导致运行失败的致命缺陷。

致命缺陷

某些行为是成功与失败的明确分界线。当这些模式出现时，成功完成任务的概率会急剧下降。最突出的例子是 FM-3.3（验证错误）。与成功轨迹相比，Gemini-3-Flash 的失败轨迹中此模式的出现率增加了 52%。其他显著的失败模式包括 FM-1.5（未意识到终止条件）和 FM-2.6（推理与行动不匹配）。

一旦发生这些致命缺陷，任务运行很可能就失败了。这提示从业者需要为系统中的智能体开发更健壮的上下文管理策略，以应对多轮交互。

案例研究：Gemini-3-Flash（果断但过于自信）

Gemini-3-Flash 效率很高，但其主要瓶颈在于倾向于在没有严格证据的情况下就假设成功。其失败特征主要体现在验证错误上的巨大差异。它经常能识别出正确的信号，但在与事实依据交叉验证之前就提前终止了。

要解决这个问题，开发者应该实现一个外部验证关卡。要求智能体在退出前必须提供基于工具的证据（例如警报已清除或指标达到健康阈值），这样可以缓解该模型固有的过度自信问题。

• 改进方法： 在 ITBench 上，仅靠提示工程对提升 Gemini-3-Flash 性能帮助不大。我们在 NeurIPS 2025 论文 中展示的实验表明，通过手动干预（如针对内存相关失败的提示工程），性能提升最多只有约 15.6%。而此前在 关于 MAST 的博客文章 中我们展示过，通过引入新的智能体（例如 Summarizer Agent 来提醒其他智能体当前状态，持续增强其状态以修复 FM-1.4），或引入上下文管理机制（例如更严格的 状态机 来强制执行终止条件以修复 FM-1.5），可以获得高达 53% 的性能提升，因为这些方法解决了系统更根本的问题。

案例研究：Kimi-K2（终止危机）

虽然终止条件混淆（FM-3.1 和 FM-1.5）是 Kimi-K2 的主要失败模式，但其失败的轨迹定义于普遍存在的 行动与推理不匹配（FM-2.6），该模式出现在惊人的 92% 的失败案例中。

• 执行差距： 虽然其内部推理的部分内容通常是准确的，但它存在高达 92% 失败率的 FM-2.6（行动与推理不匹配） 问题。它经常能识别出正确的下一步，但随后却执行了一个冗余或不相关的命令。
• 元循环陷阱： 大约 25% 的失败轨迹涉及 FM-2.3（任务偏离）。当工具调用返回一个微小错误时，智能体往往会放弃主要事件，转而进入调试自身调查脚本的循环。

Kimi-K2 是一个典型的“想太多”模型，其推理链往往过长，但可能在执行环节失败。

案例研究：GPT-OSS-120B

GPT-OSS-120B 在本组模型中表现出最不稳定的失败特征。该模型平均每个失败轨迹会出现 5.3 种不同的失败模式，这表明其存在无法维持内部状态的根本性问题。

• 对话历史丢失（FM-1.4）： 这是 120B 模型独有的致命缺陷。它在 24% 的轨迹中丢失对话历史，而 Gemini-3-Flash 表现出零记忆丢失，Kimi-K2 只有 7%。随着 SRE 任务轨迹变长，GPT-OSS-120B 实际上“忘记”了最初要处理的警报，导致任务完全偏离。
• 推理脱节（FM-2.6）： 高达 94% 的轨迹显示出推理与行动的脱节。它描述一个正确计划但随后执行完全无关或冗余工具调用的可能性，几乎是 Gemini（31%）的 3 倍。

解读图表的新视角：区分“致命”与“非致命”

总结来说，MAST 让你可以将失败模式分成两类：

可恢复的 / 结构性的（在成功轨迹中也出现）

这些失败并非致命，系统可以从中恢复并成功完成任务。

• FM-1.3 步骤重复
• FM-3.3 验证错误（重要细微差别：系统确实进行了验证，只是验证效果不佳）
• FM-2.6 推理与行动不匹配（经常出现，但不总是决定性的）

致命的 / 决定性的（与失败轨迹强相关）

这些失败通常导致系统无法恢复。

• FM-1.5 未意识到终止条件
• FM-3.1 提前终止
• FM-1.4 对话历史丢失
• FM-2.3 任务偏离（罕见，但一旦出现极具诊断价值）
• FM-2.2 未能请求澄清（尤其对于 Granite/Llama 体系）

这就是“更深入理解”的部分：两个模型在某个小切片上可能拥有相同的成功率，却因完全不同的原因失败——这需要不同的修复方案。

结论

MAST 是一个通过检查智能体系统轨迹来识别细粒度失败类型的工具，有助于系统开发和调试。在这篇博客中，我们展示了通过将 MAST 应用于 ITBench，我们可以从泛泛的观察（“开源模型表现不佳”）转向具体的工程路线图，帮助提升依赖这些模型的智能体系统性能，例如：

1. 对于 Gemini-3-Flash： 验证失败（FM-3.3）是这类“外科手术式”模型最常见的致命失败。绝不允许智能体自行终止；必须在运行被视为成功之前，要求其提供基于工具的硬性证据（例如 AlertManager 警报清除或 K8s 状态变更）。
2. 对于 Kimi-K2： 使用确定性的状态机来修复该模型在识别任务完成时经常遇到的困难。该模型的推理链可能过长且难以终止，因此对何时结束进行更严格的控制可能大有裨益。
3. 对于 GPT-OSS-120B： 当微小的推理不匹配（FM-2.6）污染任务历史时，会发生系统性崩溃。实施积极的上下文清理和早期错误检测，以确保小的偏差不会累积成完全的任务偏离。

• IT-Bench 论文： https://arxiv.org/pdf/2502.05352
• IT-Bench 代码： https://github.com/itbench-hub/ITBench
• MAST 论文： https://arxiv.org/abs/2503.13657
• MAST 代码： https://github.com/multi-agent-systems-failure-taxonomy/MAST
• MAST-Data： 🤗 MAST-Data (1600+ 轨迹)