7.0
热点
AI SCORE
技术实践2026-02-19 00:15
企业 AI Agent 失败诊断：新基准测试工具发布
Hugging Face Blog#Agent#企业#基准
Editor brief · 编辑速览
IBM 与 UC Berkeley 联合发布 IT-Bench 和 MAST 工具，帮助识别企业级 agent 系统的关键问题。
ITBench HF Space ITBench HF Dataset MAST HF Dataset ITBench Github MAST Github
IBM Research 与 UC Berkeley 合作研究了 Agentic LLM 系统在真实世界 IT 自动化任务中为何会出错。这些任务涉及事件分诊、日志与指标查询，以及在长链路工具调用循环中执行 Kubernetes 操作。
Benchmark 通常会把性能简化成一个数字，只告诉你 Agent 是否失败，却从不解释失败的原因。为了解决这一黑盒问题，我们应用了 MAST（Multi-Agent System Failure Taxonomy，多 Agent 系统故障分类法）这一新兴的 Agentic 可靠性诊断方法。我们使用 MAST 分析面向 SRE、Security 和 FinOps 自动化的行业 Benchmark——ITBench，将原始执行轨迹转换为结构化的故障特征，从而准确揭示哪里出了问题，以及该如何修复。我们标注了 310 条 ITBench SRE 轨迹，覆盖三类不同的模型：Gemini-3-Flash、Kimi-K2 和 GPT-OSS-120B。
Gemini-3-Flash 这样的 Frontier Model 通常会以相对干净的方式失败，每条轨迹平均出现 2.6 种故障模式，往往只会遇到验证环节等孤立瓶颈。GPT-OSS-120B 这样的大型开放模型则会遭遇级联故障，每条轨迹平均出现 5.3 种故障模式。运行早期的一次推理偏差就可能污染整个上下文，继而引发不断叠加的幻觉。
在所有模型中，最能预测失败的因素是 FM-3.3（错误验证）。Agent 经常在没有核对 ground truth 的情况下就“宣布胜利”。
Kimi-K2 很难判断任务何时已经完成。它在提前终止上的增幅高达 46%，在未意识到终止条件上的增幅则达到 43%，经常在即将解决问题之前退出，或者陷入无休止的循环。
构建 Agent 时，我们的分析带来了以下启示：
对于 Gemini 这样的 Frontier Model：将验证外置。绝不要让 LLM 批改自己的作业。退出之前，必须取得确凿的工具执行证据。
把终止判断与循环控制放到模型之外：终止问题是常见的致命因素（FM-1.5）。应当添加明确的停止条件，以及针对重复工具调用或操作的循环检测器，或者实现 Finite State Machine。
当输入存在歧义时，强制 Agent 先澄清，或仅执行只读操作：澄清失败（FM-2.2）是驱动较小模型失败的重要因素。应当在 Agent graph 中将歧义处理设计成一等分支。
如果你正在为企业 IT 工作流构建 Agent，那么真正需要的正是这种评估：不只是问“它通过了吗？”，还要问“哪里出了问题、问题发生在什么位置，以及哪种干预措施的杠杆效应最大？”
ITBench 之类的 Benchmark 正逐渐成为衡量 Agentic 系统在高风险 IT 自动化任务中表现的标准。在 ITBench 中，Agent 会扮演 Site Reliability Engineer（SRE）或 Security Analyst，负责诊断 Kubernetes 故障、修补漏洞，或管理生产环境中的云成本。
这些 Benchmark 主要使用成功率评估 Agent。然而，这一指标不足以支持稳健系统的工程建设。知道某个 Agentic 系统在 ITBench 上取得了 14% 的成功率，只能说明它失败了，却无法解释原因：是因为忘记了上下文？因为幻觉出了一条命令？还是仅仅因为它没有终止？
如果没有一套全面诊断这些故障的方法，开发者就只能靠猜，往往不得不盲目调整 prompt，结果常常是解决了一个问题，却又制造出另一个问题。
为了建立分析复杂 Agentic 系统故障模式的新标准，我们开发了 MAST（Multi-Agent System Failure Taxonomy）。MAST 能够提供更多洞察，让这些 Benchmark 原本不透明的评估过程变得更加开放。MAST 源自对七种不同框架、超过 1,600 条轨迹的严格分析，为 Agent 故障提供了一套标准化分类法。
MAST 根据三大关键类别中的 14 种不同模式，将非结构化执行日志转换成结构化的“故障向量”：
这里的故障源自 Agent 的架构与角色定义。例如：FM-1.3 步骤重复（陷入循环）、FM-1.4 对话历史丢失（内存泄漏）、FM-1.5 未意识到终止条件（无法停止）。
这里的故障源自 Agent 的架构与角色定义。
例如：FM-1.3 步骤重复（陷入循环）、FM-1.4 对话历史丢失（内存泄漏）、FM-1.5 未意识到终止条件（无法停止）。
这类故障发生在运行时，源自 Agent 彼此之间或 Agent 与环境之间的交互方式。例如：FM-2.2 未能请求澄清（不问而直接假设）、FM-2.3 任务偏离（跑题）。
这类故障发生在运行时，源自 Agent 彼此之间或 Agent 与环境之间的交互方式。
例如：FM-2.2 未能请求澄清（不问而直接假设）、FM-2.3 任务偏离（跑题）。
这类故障发生在 Agent 输出的质量保障环节。例如：FM-3.1 提前终止（过早放弃）、FM-3.3 错误验证（幻觉出成功结果）。
这类故障发生在 Agent 输出的质量保障环节。
例如：FM-3.1 提前终止（过早放弃）、FM-3.3 错误验证（幻觉出成功结果）。
为了验证使用 MAST 是否能让 Agent 评估真正具备可操作性，并深入了解其故障模式，我们将其应用于 ITBench。ITBench 是一套广受欢迎的 IT 自动化任务评估套件，覆盖 SRE、Security/Compliance 和 FinOps。
我们标注了 310 条 ITBench SRE 执行轨迹。这些轨迹由一个使用 Codex 构建的 SRE Agent 在真实环境中生成，记录了 Agent 与其工具之间的自然语言交互，覆盖代表不同能力层级的三种模型：Gemini-3-Flash、Kimi-K2 和 GPT-OSS-120B。借助这些轨迹，我们可以越过简单的成功率指标，调查究竟是哪些不同的故障特征导致了这些结果。我们在这里使用 recall 分数，因为按照设计，这些模型最多只会输出 3～5 个结果，而 SRE 相比 F-1 分数更偏好 recall 分数。
Gemini-3-Flash：100 条轨迹（平均 Recall 为 75.5%）
Kimi-K2：105 条轨迹（平均 Recall 为 28.6%）
GPT-OSS-120B：105 条轨迹（平均 Recall 为 12.4%）
下面将详细介绍这次诊断分析的发现。
查看失败轨迹时，我们可以清楚地看到，三种模型的故障复杂度存在明显的层级差异。这里的复杂度通过每次失败运行中观察到的不同故障模式数量来衡量。
Gemini-3-Flash：每条失败轨迹 2.6 种故障模式
Kimi-K2：每条失败轨迹 4.7 种故障模式
GPT-OSS-120B：每条失败轨迹 5.3 种故障模式
故障模式密度上的差异揭示了这些系统发生故障时的根本区别。Gemini-3-Flash 呈现出外科手术式的故障特征。即便运行失败，它仍能保持较高的内部一致性，通常只会因为某个孤立问题而失败，例如验证步骤出错。这些故障定位精确，因此更容易诊断。
在光谱的另一端，GPT-OSS-120B 会遭遇级联式崩溃。在这些轨迹中，我们观察到错误往往会随着时间推移不断叠加。流程早期的一次轻微推理偏差，常常会导致其偏离任务规范，进而引发 Agent 的全面失控。Kimi-K2 则处于两者之间：它的故障比 Frontier Model 更频繁、更复杂，但尚未达到 120B 开放权重模型那种系统性不稳定的程度。
这一发现的重要意义在于，更高的成功率往往也伴随着更加孤立的故障。一个系统在失败时同时出现的问题越少，它的行为就越可预测，也越容易通过有针对性的工程干预进行改进。
MAST 最关键的洞察或许在于，它能区分系统可以容忍的故障与会导致下游任务失败的致命故障。通过比较成功轨迹与失败轨迹中的故障模式分布，我们可以将它们分成三类。
在三种模型中，有些故障模式即便在最终成功的运行中也会频繁出现。它们往往只是结构性摩擦，而不是终止任务的 bug。
FM-1.3 步骤重复：超过 90% 的 Kimi-K2 成功运行都存在这种模式。在 SRE 领域，迭代通常是必要的。Agent 可能会多次查询同一指标，以确认服务是否正在趋于稳定，或者修复是否已经生效。Gemini-3-Flash 在失败轨迹中的重复反而更少，这表明它有时恰恰是因为迭代次数不够而失败。
FM-1.1 不遵守任务规范：Agent 经常会偏离严格的工具格式或顺序指令，但仍能成功找到正确的根因。
这种区分正是 MAST 价值所在。它让我们可以忽略故障排查中经常出现的重复等良性故障，转而聚焦真正导致运行失败的致命故障。
有些行为能够清楚地区分成功与失败。一旦出现这些模式，成功的概率就会急剧下降。最突出的例子是 FM-3.3（错误验证）。与成功轨迹相比，Gemini-3-Flash 失败轨迹中出现这种模式的比例增加了 52%。其他突出的故障模式包括 FM-1.5（未意识到终止条件）和 FM-2.6（推理与行动不匹配）。
如果这些问题发生，运行很可能已经无可挽回。这也提示实践者，应当在系统中的多个 Agent 以及多轮交互之间建立稳健的上下文管理策略。
Gemini-3-Flash 的效率很高，但它的主要瓶颈在于，常常会在缺少严格证据的情况下认定任务已经成功。其故障特征主要由验证错误的大幅增加所主导。它经常能够找到正确的信号，却在将这些信号与 ground truth 交叉核对之前就终止运行。为了解决这一问题，开发者应当实现外部验证门禁。只有取得基于工具的证据，例如告警已经解除，或指标已经达到健康阈值，才允许 Agent 退出。通过这种方式，我们可以缓解该模型固有的过度自信。
修复方案：要提升 Gemini-3-Flash 在 ITBench 上的表现，prompt engineering 的帮助不会太大。尤其是，我们在 NeurIPS 2025 论文中展示的实验表明，针对内存相关故障，即便进行 prompt engineering 等人工干预，性能最多也只能提升约 15.6%。而在此前一篇介绍 MAST 的博客文章中，我们展示了另一种方案：引入 Summarizer Agent 等新 Agent，持续提醒其他 Agent 当前发生了什么，并不断扩充它们的状态，从而修复 FM-1.4；或者引入上下文管理机制，例如使用更严格的 State Machine 强制终止，从而修复 FM-1.5。由于这些方法解决的是系统更根本的问题，因此最多可以带来 53% 的性能提升。
虽然终止判断混乱（FM-3.1 和 FM-1.5）是 Kimi-K2 的主要故障模式，但其失败轨迹最显著的特征是普遍存在行动与推理不匹配（FM-2.6），这一问题出现在惊人的 92% 的失败轨迹中。
执行鸿沟：尽管它的一部分内部推理往往是正确的，但 FM-2.6（行动与推理不匹配）在其失败中的出现率高达 92%。它经常能够找出正确的下一步，却又执行了一条重复或无关的命令。
元循环陷阱：大约 25% 的失败轨迹涉及 FM-2.3（任务偏离）。当一次工具调用返回轻微错误时，Agent 经常会放弃主要事件，转而陷入调试自身调查脚本的循环。
Kimi-K2 是典型的过度思考型模型：它的推理链往往过长，却可能在执行环节失败。
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 是一种检查 Agentic 系统轨迹的工具，它能够识别细粒度的故障类型，为系统开发与调试提供支持。在本文中，我们展示了如何通过把 MAST 应用于 ITBench，将“开放模型表现不佳”这种笼统观察，转化成一份具体的工程路线图，帮助提升依赖这些模型的 Agentic 系统性能。例如：
对于 Gemini-3-Flash：验证失败（FM-3.3）是外科手术式模型最常见的致命故障。绝不要允许 Agent 自行决定终止；必须取得确凿的、由工具提供的证据，例如 AlertManager 中的告警已经解除，或 K8s 状态已经发生预期变化，才能将一次运行视为成功。
对于 Kimi-K2：使用确定性的 State Machine，解决该模型频繁出现的任务完成识别问题。该模型的推理链可能过长，而且难以终止，因此如果能对终止时机实施更严格的控制，它的表现可能会得到显著改善。
对于 GPT-OSS-120B：当轻微的推理与行动不匹配（FM-2.6）污染任务历史时，就会发生系统性崩溃。应当实施激进的上下文清理与早期错误检测，确保轻微的不一致不会不断叠加，最终导致任务全面失控。
IT-Bench 论文：arXiv 2502.05352
IT-Bench 代码：GitHub itbench-hub/ITBench
MAST 论文：arXiv 2503.13657
MAST 代码：GitHub multi-agent-systems-failure-taxonomy/MAST
MAST-Data：🤗 MAST-Data（1,600 多条轨迹）
本文提及的数据集：2 个
本文提及的 Space：1 个
Model Routing 很简单，直到它不再简单。
ScarfBench：用于企业 Java Framework 迁移的 AI Agent Benchmark
· 注册或登录后发表评论
本文提及的数据集：2 个
本文提及的 Space：1 个