IBM 与加州大学伯克利分校使用 IT-Bench 与 MAST 诊断企业代理故障

IBM Research 和 UC Berkeley 开发了一种方法，超越了在代理式 LLM 评估中仅使用成功率的做法，方法是将 IT-Bench（面向 SRE、安全和 FinOps 自动化的基准）与 MAST（多代理系统故障分类法） 相结合。该方法帮助开发者识别具体的故障特征，区分良性的结构性摩擦和导致任务崩溃的致命错误。

代理基准的“黑箱”问题

传统基准通常只报告单一的成功率，却无法解释 为什么 代理会失败。为了解决这个问题，研究人员引入了 MAST，这是一套标准化的分类法，可将非结构化的执行日志转换为跨 14 种不同模式的结构化“故障向量”。这些模式被归为三大类：

  • FC1：系统设计问题（骨架）: 架构类故障，例如 FM-1.3 Step Repetition（循环）、FM-1.4 Loss of Conversation History（内存泄漏）以及 FM-1.5 Unaware of Termination。
  • FC2：代理间不对齐（通信）: 运行时通信故障，包括 FM-2.2 Fail to Ask for Clarification 和 FM-2.3 Task Derailment。
  • FC3：任务验证（质量控制）: 输出质量故障，例如 FM-3.1 Premature Termination 和 FM-3.3 Incorrect Verification（幻觉式成功）。

诊断实验：IT-Bench SRE 跟踪

研究人员对 310 条 SRE 执行跟踪（覆盖三类模型）进行标注，以分析它们各自的故障特征。模型在平均召回率（Mean Recall）上的表现差异显著：

  • Gemini-3-Flash: 75.5% 平均召回率
  • Kimi-K2: 28.6% 平均召回率
  • GPT-OSS-120B: 12.4% 平均召回率

故障密度与复杂度

研究发现模型强度与其故障的“外科手术式”程度呈直接相关。更强的模型每条失败跟踪中出现的故障模式更少、更孤立，因而更易调试：

  • Gemini-3-Flash: 每条失败跟踪 2.6 种故障模式（外科手术式故障）。
  • Kimi-K2: 每条失败跟踪 4.7 种故障模式。
  • GPT-OSS-120B: 每条失败跟踪 5.3 种故障模式（级联崩溃）。

Gemini-3-Flash 通常因单一孤立的瓶颈而失败，而 GPT-OSS-120B 则因早期推理不匹配导致上下文被污染，进而出现整体失控。

区分致命与非致命故障

MAST 能够根据系统是否能够从故障中恢复，将故障划分为两类：

可恢复 / 结构性故障

这些缺陷即使在成功运行中也经常出现，且往往是任务所必需的。例如，FM-1.3 Step Repetition 在超过 90% 的成功 Kimi‑K2 运行中出现，因为 SRE 任务常常需要多次查询同一指标以验证其稳定性。

致命 / 决定性故障

这些错误与失败高度相关，通常不可恢复：

  • FM-3.3 Incorrect Verification: 所有模型中失败的最强预测因子。Gemini-3-Flash 在失败跟踪中该模式的出现率比成功跟踪高出 52%。
  • FM-1.5 Unaware of Termination Conditions 与 FM-2.6 Reasoning Action Mismatch 也是主要的失败驱动因素。

针对模型的案例研究与干预措施

Gemini-3-Flash：过度自信

Gemini-3-Flash 效率高，但倾向于在缺乏严格证据的情况下假设成功。其故障特征主要是验证错误。

推荐修复： 实施外部验证闸门。要求在代理退出前提供硬工具证据（例如健康指标阈值），而不是让 LLM 自评作业。

Kimi-K2：终止危机

Kimi‑K2 在识别任务何时完成方面表现不佳。它出现 Premature Termination（提前终止）增长 +46%，以及 Unaware of Termination Conditions（不知终止条件）增长 +43%。此外，FM-2.6 (Action‑Reasoning Mismatch) 在 92% 的失败中出现——模型找到了正确的步骤，却执行了无关的指令。

推荐修复： 使用确定性的状态机在模型外部强制终止与循环控制。

GPT-OSS-120B：系统性不稳定

该模型根本无法保持内部状态。它在 24% 的跟踪中丢失对话历史（FM-1.4），而 Gemini‑3‑Flash 为 0%，导致它“忘记”最初正在处理的警报。

推荐修复： 实施激进的上下文清理和早期错误检测，防止小的推理不匹配累积成整体失控。

企业代理的工程路线图

基于 MAST 分析，研究人员提出了三项主要的架构干预，以提升代理的可靠性：

  1. 外部化验证： 在退出前要求硬证据，以缓解前沿模型的过度自信。
  2. 外部化循环控制： 使用有限状态机在模型外部实现终止与循环检测，防止无限循环或提前退出。
  3. 强制澄清： 将歧义处理设为代理图中的一等分支，防止小模型在输入模糊时走错路径。

Sources