Agent 失败不能只看最终答案,要定位哪一步坏了
Microsoft Research 的 AgentRx 用带证据的轨迹诊断定位 Agent 关键失败步骤,适合把验收从最终准确率推进到过程质量。

目录
AgentRx:从执行轨迹诊断 AI Agent 失败
摘要
AI Agent 的失败往往难以定位,因为其执行过程是概率性的(probabilistic)、长程的(long-horizon)、多智能体的(multi-agent),并且经由充满噪声的工具输出来中介。我们通过人工标注失败的 Agent 运行轨迹来弥补这一空白,并发布一个全新的 benchmark:包含横跨 11 种多样化任务场景的 170 条轨迹,涵盖结构化 API 工作流、生产事故管理(incident management)以及开放式的网页/文件任务。每条轨迹都标注了一个「关键失败步骤」(critical failure step)以及一个来自扎根理论(grounded theory)推导出的跨领域失败分类法的类别。
为降低失败归因的人工成本,我们提出 AgentRx——一个自动化、领域无关的诊断框架,用于精确定位失败 Agent 轨迹中的关键失败步骤。它合成约束(constraints)、逐步评估这些约束,并产出一份可审计的约束违规校验日志及其关联证据;随后由基于 LLM 的评审(judge)依据这份日志来定位关键步骤并给出类别。AgentRx 相比既有工作在步骤定位上平均提升 75%,同时还能提供失败类别归因。
1 引言
基于大语言模型(LLM)的 Agent 正日益在没有人工介入(human in the loop)的情况下自主行动。现代 Agent 系统能够规划、协调、调用工具并执行复杂的真实世界任务。这些 Agent 已不再局限于沙箱,而是被部署到招聘(LinkedIn, 2024)、网页浏览(Fourney et al., 2024,即 Magentic-One)、生产环境云服务运维(Zhang et al., 2024,即 Flash)等高风险场景中。这种以极少指导即可运作的能力极大地放大了人类生产力(Brynjolfsson et al., 2023)。然而,正是这种带来速度的自主性,也让 Agent 系统难以调试:轨迹是长程的、工具输出充满噪声,且失败在被观察到之前可能已经通过副作用(side effects)传播开来。因此,确保 AI Agent 的鲁棒性不是一个可选项,而是其在现实世界安全落地的前提条件。
(图 1 说明:给定一条失败轨迹、领域策略(domain policy)与工具 schema,AgentRx 输出关键失败步骤、根因类别,以及一条可审计的约束违规记录。)
本文聚焦的问题是:对阻止 Agent 成功完成任务的关键失败进行根因分析与定位。我们把「关键失败」(critical failure)定义为:执行轨迹中任一 Agent 发生的第一个不可恢复(unrecoverable)的失败。为了理解并刻画此类失败,我们人工分析了失败的 Agent 执行过程,并推出一个覆盖 11 种任务场景、共 170 条轨迹的 benchmark。每条轨迹包含完整执行痕迹(消息、工具调用、工具输出、可观察的环境状态),并标注了「关键步骤」与「失败类别」——后者刻画该次运行为何最终失败。我们基于扎根理论的标注流程还产出了一套用于根因归因的跨领域失败分类法(taxonomy)。
挑战。人工失败归因对长程轨迹而言成本高昂,且难以扩展到服务数百万日活用户的 Agent 系统。它不仅需要检视很长的轨迹,还需要领域专业知识来理解系统提示词、可用工具、领域策略、用户护栏(guardrails)以及预期的状态转移。这就产生了对 Agent 执行进行自动化校验的需求。在软件工程中,「契约」(contracts)使接口误用与约束违反变得显式;Agent 系统也需要一种类似的正确性概念,只不过它要表述在「执行」之上:模糊的意图、消息、工具调用与状态更新。
AgentRx。为把这一观点落地,我们设计了 AgentRx——一个面向 AI Agent 的领域无关自动化框架,它:
- 将异构的多智能体日志归一化为统一的轨迹表示(intermediate representation,IR);
- 从工具 schema、领域策略与观察到的轨迹中合成约束;
- 产出按步骤索引的「义务违反」校验日志及支持证据,供下游评审(judge)定位关键失败步骤并赋予类别。
如图 1 所示的例子:当助理 Agent 调用 get_product_details 后报告「有 11 个可选 T 恤」时,AgentRx 合成了一条关系型约束 tshirt_count_matches,从工具响应中重新计算数量,并核对其与助理 Agent 的解读是否一致。产出的违规记录包含了与助理声称相矛盾的确切轨迹窗口,帮助评审定位决定性的失败。
评估。我们在本文提出的 benchmark 以及既有失败分析数据集(Zhang et al., 2025a 即 Who&When;Cemri et al., 2026 即 MAST)上评估 AgentRx。AgentRx 在「定位第一个未解决的关键失败步骤」与「根因类别归类」两方面均超过最先进方法与我们的基线。结果清楚表明:轨迹级约束是检测失败的有用信号。
贡献:
- (i) 一个跨多样任务、人工标注的开源失败轨迹数据集(170 条),包含步骤定位与失败归因标注(标注者间一致性 κ=0.89);
- (ii) 一个新颖的领域无关失败诊断框架,将约束合成与基于 LLM 的裁决结合来定位 Agent 失败;
- (iii) 通过扎根理论编码得出的跨领域失败分类法,包含 9 个根因类别(另有第 10 类 Inconclusive「无法定论」备用),可泛化到多个领域;
- (iv) 大量实验表明:失败定位相比既有工作平均提升 75%,根因归类相比我们自己的评审基线提升 30%。
(图 2 说明:各领域每条轨迹的失败时间线。每条横线是一条轨迹,彩色刻度标记检测到的失败发生步骤(并标注类别),星号标记根因步骤。Magentic-One 共 295 个失败,68% 的轨迹至少含两个失败;Flash 共 55 个失败;τ-bench 共 52 个失败。)
2 AgentRx Benchmark
我们是第一个为「AI Agent 中第一个不可恢复关键失败的归因」引入 benchmark 的工作。该 benchmark 包含 170 条失败轨迹,横跨 11 种多样化任务场景,覆盖结构化 API 工作流、生产事故管理、软件开发 Agent、数学推理以及开放式网页/文件任务。这些场景沿三个轴变化:单智能体 vs 多智能体执行、结构化 API vs 开放式环境、可恢复 vs 不可恢复的失败链。对每个场景,我们采样失败轨迹并用它们构建失败归因 benchmark。
2.0 任务场景与数据来源
τ-bench(Yao et al., 2024):面向零售任务的工具调用 benchmark,含一个 LLM 模拟的用户与一个配备领域专用 API 和策略指南的单智能体。典型任务中,Agent 可以取消或修改待处理订单、对已送达订单退货/换货、更新用户地址、回答商品咨询。我们用 gpt-4o 对 115 个 τ-bench 零售任务各跑一次试验,分析其中 39 条失败轨迹。
Flash(Zhang et al., 2024):用于诊断生产云服务中复发事故的工作流自动化 Agent,是一个多智能体系统——专门的 Agent 按事故排障指南(troubleshooting guide)执行,指南步骤包括查询某区域内可能受影响的集群、以及依据事故是否为误报采取缓解措施等。我们分析了 42 条至少包含一次 Agent 失败的 Flash 轨迹。
Magentic-One(Fourney et al., 2024):面向开放式网页与文件任务的通用多智能体系统,由 Orchestrator(编排者)协调网页浏览(WebSurfer)、文件导航(FileSurfer)与代码执行等专门 Agent。我们从 Who&When 数据集(Zhang et al., 2025a)中随机采样 44 条失败的多智能体轨迹。
RelWork:我们从 MAST(Cemri et al., 2026)与 Who&When(Zhang et al., 2025a)的 9 个任务领域中各选 5 条轨迹采样。其中 7 个领域来自 MAST,覆盖软件开发 Agent、API/工具工作流、数学推理与开放式网页/文件任务;其余 2 个来自 Who&When:算法生成的与手工构建的 Agent 系统,处理 GAIA/AssistantBench 风格的查询。这带来 45 条额外失败轨迹,使 AgentRx benchmark 总量达到 170 条。RelWork 拓宽了 benchmark,并让我们能够评估分类法与归因任务能否泛化到包含长程轨迹的其他 Agent 失败数据集。
数据集划分说明:benchmark 按上述四个来源划分(对应 HuggingFace 数据集 microsoft/AgentRx 中 tau_bench/retail、Flash、Magentic-One、RelWork 等 split;论文正文以 τ-bench、Flash、Magentic、RelWork 四个域名指代)。
2.1 失败的扎根理论标注
为系统分析关键 Agent 失败,我们采用扎根理论的开放式编码(open coding,Glaser and Strauss, 2017)人工标注轨迹,让失败类别从痕迹中自然涌现,而不是强加一套预定义标签。三名标注者独立对三个领域的轨迹编码。标注者逐步阅读每条轨迹,每当观察到失败时撰写结构化的编码备忘录(coding memo)。我们把「失败」定义为:Agent 未能朝正确结果推进的任何节点,例如违反策略指南或执行无效工具调用。编码分两阶段:
阶段 1:穷尽式失败标记。标注者先标记所有失败步骤,即便后续步骤才主导最终结果。对每个失败事件记录:(i) 步骤索引;(ii) 一个开放码(open code):紧扣轨迹痕迹的简短具体描述;(iii) 失败原因。这一阶段捕捉早期偏差与级联失败,包括 Agent 后来恢复的那些。
阶段 2:关键失败识别。随后识别关键失败步骤:因果链上最早的、Agent 未能从中恢复的失败。该步骤决定整条轨迹的根因类别。
整个编码过程中,标注者不断将新码与既有码比较,尽量复用、必要时新建定义;周期性地把相关开放码合并为更高层类别并打磨定义;迭代至理论饱和(theoretical saturation)——新轨迹不再带来新的失败现象。分类法源自三个结构迥异的领域(覆盖单智能体与多智能体设置),每个领域由多名标注者独立标注。之后我们冻结类别定义,用封闭式编码(closed coding)标注剩余轨迹并重新编码早期轨迹;特别是 RelWork 轨迹完全在冻结的分类法下标注,因此它充当了一个「留出检验」(held-out check),验证类别能否迁移到塑造它们的三个领域之外。
每条 benchmark 记录存储:轨迹标识符、有序的失败事件列表(步骤索引、自然语言描述、分类法标签、理由),以及关键失败;事件列表给出从第一个不可恢复失败到终止失败的因果链。
2.2 跨领域失败分类法
既有工作(MAST,Cemri et al., 2026)从系统层面组织多智能体失败模式(按设计、协调、验证阶段)。我们的分类法则用于标注关键失败,共 9 个根因类别(外加 1 个「无法定论」备用类,见附录 A):
- 指令/计划遵循失败(Instruction/Plan Adherence Failure):Agent 未遵循必需指示或既定计划,无视指令。涵盖「执行不足」(漏掉必要步骤)与「过度执行」(计划外动作)两类对计划、领域策略或编排者约束的违反。
- 凭空创造新信息(Invention of New Information):Agent 引入、删除或篡改了不存在于任何可用输入、上下文或工具输出中的信息。包括编造无依据的事实、幻觉细节,或无正当理由遗漏相关信息。
- 无效调用(Invalid Invocation):Agent 发出无效的工具调用,例如格式错误的输入、缺失参数、无法通过 schema 校验的值。
- 工具输出误读(Misinterpretation of Tool Output):Agent 对自己或其他 Agent 的工具输出推理错误,导致错误假设或错误行动(也包括只考虑了部分工具输出的情形,即交接失败 handoff failure)。
- 意图–计划错位(Intent–Plan Misalignment):Agent 误解用户目标或约束,产出错误的计划—— pursuing 错误目标或因误解而违反关键约束。
- 用户意图欠明确(Under-specified User Intent):由于轨迹执行到该点时信息不完整,Agent 无法完成任务(缺日期、地址、账户 ID、商品变体等)。
- 意图不受支持(Intent Not Supported):用户请求的动作没有对应工具可执行(如要求听音频、访问私有系统、执行只有人能做的动作)。
- 护栏触发(Guardrails Triggered):Agent 的执行被安全策略(RAI)或外部站点访问限制阻断——例如策略拒绝、CAPTCHA、登录/付费墙/403/robots.txt 拒绝——尽管计划本身有效。
- 系统失败(System Failure):Agent 调用工具时遇到系统连通性问题,如 API 端点不可达、超时、连接被拒、DNS 失败。
(第 10 类 Inconclusive(无法定论):1–9 均不清晰适用时使用,须慎用,且评审必须给出自定义类别标签。)
分类法设计原则:
- (i) 关键步骤处互斥:一条轨迹上可能出现多个失败模式,但关键失败步骤只获得恰好一个类别标签,该标签捕捉该步骤导致不可恢复失败的首要原因;
- (ii) 消歧准则:如「指令/计划遵循失败」(计划正确但 Agent 偏离)与「意图–计划错位」(Agent 从正确意图形成了错误计划)以「计划本身是否正确」区分,并通过分类法检查清单(checklist 𝖪)中的是/否问题操作化(附录 A);
- (iii) 可扩展性:分类法作为固定集合嵌入提示词;扩展只需 (a) 在检查清单 𝖪 中定义新类别问题,(b) 将其加入评审提示词。
标注者间一致性:在来自 τ-bench、Flash、Magentic-One 的 30 条轨迹上评估,每条由三名标注者用相同分类法与指南独立标注。由于 Cohen's κ 只定义于两名标注者之间,我们对标注者两两配对计算并取均值:三对 κ 分别为 0.93、0.87、0.90,均值 κ=0.89,属于「近乎完美一致」(0.8–1.0),说明分类法定义清晰且使用一致。分歧经人工复核以打磨定义;关键步骤处标签互斥,模糊情形用分类法检查清单裁决。
标注成本:人工标注工作量可观,尤其是长程轨迹。轨迹长度中位数:τ-bench 36 步(范围 20–62);Flash 3 步(范围 2–6,且平均每步含 8 个子步骤,Flash 的步骤按排障指南定义);Magentic-One 33 步(范围 5–130);RelWork 10 步(范围 4–37)。标注者平均每条轨迹耗时:τ-bench 20 分钟,Flash 与 RelWork 各 22 分钟,Magentic 24 分钟。170 条轨迹合计 62.5 个人工时,难以规模化——这正是 AgentRx 自动化失败归因的动机。
表 1:各领域关键失败标签分布(按领域归一化为失败轨迹百分比)
| 根因类别 | τ-bench | Flash | Magentic | RelWork |
|---|---|---|---|---|
| 指令/计划遵循失败 | 20.5 | 23.8 | 18.2 | 33.3 |
| 凭空创造新信息 | 2.6 | 9.5 | 9.1 | 17.8 |
| 无效调用 | 0 | 0 | 0 | 2.2 |
| 工具输出误读 | 20.5 | 33.3 | 34.1 | 33.3 |
| 意图–计划错位 | 15.4 | 0 | 9.1 | 6.7 |
| 用户意图欠明确 | 33.3 | 19.0 | 0 | 0 |
| 意图不受支持 | 5.1 | 0 | 6.8 | 2.2 |
| 护栏触发 | 0 | 0 | 20.5 | 2.2 |
| 系统失败 | 2.6 | 14.3 | 2.3 | 0 |
| 失败轨迹数 | 39 | 42 | 44 | 45 |
要点:「工具输出误读」是四个域中最普遍的根因之一(约 1/5 到 1/3);τ-bench 中「用户意图欠明确」占比最高(33.3%);Magentic 的「护栏触发」显著(20.5%);RelWork 中「指令/计划遵循失败」最多(33.3%)。
3 AgentRx 框架形式化
设置。AgentRx 的输入为:(i) 带输入–输出 schema 的工具集 𝒯;(ii) 可选的领域策略 Π;(iii) 一条失败轨迹 T=⟨s₁,…,sₙ⟩。每个步骤 sₖ 含多条日志事件,字段包括 Agent 名称、工具名称、步骤索引、工具输出或自然语言对话内容。由于各领域日志格式不同,先将每条轨迹归一化为统一的中间表示(IR)。记 T≤ₖ 为截至第 k 步(含)的轨迹前缀。AgentRx 从工具 schema、领域策略与轨迹前缀生成可执行约束,逐步评估它们,产出可审计的校验日志 𝖵。基于 LLM 的评审使用 𝖵 与分类法检查清单 𝖪,预测根因步骤 ŝ 与类别 ŷ。
分类法检查清单(Taxonomy checklist):我们将失败分类法手工编纂为语义检查清单 𝖪——对分类法中每个类别 y,𝖪(y) 给出一小组针对性的是/否问题(及简短判定准则),把类别定义操作化。
3.1 全局约束与动态约束合成
AgentRx 分两阶段合成约束:
- 全局约束 𝒞ᴳ:一次性从工具 schema 及(若可用)领域策略合成,存入全局存储 𝖦——直觉上编码领域规则;
- 动态约束 𝒞ᴰₖ:在每一步从任务指令 I 与已观察前缀 T≤ₖ 合成(以 𝖦 为上下文),存入局部存储 𝖫ₖ——编码轨迹特定规则与先前观察(例如给定早前工具输出后必须成立的约束)。
第 k 步可用约束定义为并集 𝒞ₖ := 𝒞ᴳ ∪ 𝒞ᴰₖ。实践中,约束合成以轻量 schema 输出约束,以标准化跨领域检查(见附录 F.1)。
3.2 带守卫的约束与评估
AgentRx 生成的每条约束 C 包含:
- (i) 守卫(guard) G_C(T≤ₖ, sₖ) ∈ {0,1}:决定约束何时适用——捕捉结构性条件,如第 k 步是否调用了某特定工具或触发了某特定 Agent;
- (ii) 断言(assertion) Φ_C(T≤ₖ, sₖ) ∈ {sat, viol}:求值时返回二元判定 v。
记 g_{C,k}=G_C(T≤ₖ,sₖ)、φ_{C,k}=Φ_C(T≤ₖ,sₖ)。第 k 步的评估定义为:
Eval_C(k) = (skip, ∅) 若 g_{C,k} = 0(守卫不满足,跳过)
= (φ_{C,k}, e) 否则(返回判定与证据)中文解释:守卫不成立时该约束在本步直接跳过、不产生记录;守卫成立时执行断言,返回「满足/违反」判定及配套证据 e。
约束检查有两种方式:程序化检查——对结构化字段执行(如 schema 有效性、等值、成员关系),生成可执行 Python 检查;或语义检查——以自然语言谓词形式交由基于 LLM 的检查器评估。两者都返回「判定–证据」对 (v, e)。示例见附录 F。
3.3 校验日志(Validation Log)
在第 k 步,AgentRx 评估每条守卫成立(G_C(T≤ₖ,sₖ)=1)的约束 C∈𝒞ₖ,并将每条被违反的约束及其支持证据记入按步骤索引的校验日志:
𝖵 := { (k, C, e) | C ∈ 𝒞ₖ, G_C(T≤ₖ, sₖ) = 1, (viol, e) = Eval_C(k) }中文解释:日志 𝖵 是一组三元组(步骤号、被违反的约束、证据),按步骤索引、可审计,并将每条违规直接链接到支持证据。
3.4 根因归因评审
给定任务指令 I、轨迹 T、检查清单 𝖪 与校验日志 𝖵,基于 LLM 的评审输出关键失败步骤 ŝ 与类别 ŷ。评审选择第一个其违规证据足以解释该次运行为何相对 I 失败的步骤。违规作为诊断证据而非硬性要求:当轨迹上下文另有指示时,评审可以推翻违规信号。评审依据违规关联的分类法标签设定 ŷ,并输出一段简短理由,引用选择该失败类别的具体原因。
4 实验评估
我们在 AgentRx benchmark 上把 AgentRx 作为 Agent 轨迹的根因诊断系统来评估,衡量它能否定位第一个不可恢复的关键步骤并赋予正确的根因类别。实验检验:准确性、跨领域与跨模型泛化、校验信号的贡献、以及放宽指标下的鲁棒性。
4.1 实验设置
指标。步骤定位采用:精确关键步骤准确率(预测步骤与标注步骤完全一致的轨迹比例)、Acc@±r(r∈{1,3,5},允许预测偏离 r 步以内)、平均步骤距离(预测与标注步骤相距多远)。类别预测采用四种口径:critical(关键失败类别准确率)、any-failure(匹配轨迹中任一标注失败类别)、earliest(匹配第一个观察到的失败)、terminal(匹配终止失败)。当无法识别有依据的关键失败时,评审还可输出「inconclusive(无法定论)」。
实验设置。每个配置运行 n=3 次,报告均值±标准差,以纳入采样噪声与评审波动(见表 4)。除特别说明外,AgentRx 同时使用程序化约束与语义约束。领域策略是可选输入:τ-bench 提供策略文档,Flash 与 Magentic-One 没有,其约束仅从工具 schema 与观察到的轨迹导出。默认模型为 gpt-5(o3 与 DeepSeek-V3.2 的结果见附录表 8、表 9)。表 4 中,Baseline 表示不带 AgentRx 附加证据的评审;Baseline+Vio. 等设置逐步叠加校验信号。
4.2 与既有 benchmark 的对比
表 2:与相关工作能力对比。MAST 侧重多智能体失败的宏观刻画,Who&When(W&W)侧重「责任 Agent+失败步骤」归因,AgentRx 则把分类法级分析与「证据落地的失败运行诊断」结合起来:
| 能力维度 | MAST | W&W | AgentRx |
|---|---|---|---|
| 失败轨迹 benchmark | ✓ | ✓ | ✓ |
| 广覆盖多智能体 | ✓ | ✓ | ✓ |
| 失败分类法 | ✓ | – | ✓ |
| 跨运行失败分析 | ✓ | ∼ | ✓ |
| 责任 Agent 归因 | – | ✓ | ✓ |
| 失败步骤定位 | ∼ | ✓ | ✓ |
| 第一个不可恢复失败 | – | ∼ | ✓ |
| 证据落地的校验 | – | – | ✓ |
与 Who&When 对比。尽管 W&W 也标注了责任 Agent 与失败步骤,但其目标步骤并不总是符合我们定义下的「关键失败」。在一条轨迹中(附录 C),Orchestrator 从 W&W 标记的失败中恢复了——把任务从 WebSurfer 切换到 FileSurfer——直到后来一次幻觉出的文件/路径错误才变得不可恢复(我们的标注捕捉到了这一点)。这说明我们的定位是更严格的调试目标。
由于 W&W 为其自有轨迹格式设计,我们用 AgentRx 领域适配器把轨迹转换为 W&W 所需格式,并修改 W&W 提示词以要求「第一个不可恢复」失败步骤,与我们的任务定义对齐。
表 3:跨数据集失败归因准确率(W&W* 为改造后的 W&W;均值±标准差,3 次运行):
| 数据集 | 方法 | Agent 准确率 | 步骤准确率 | 类别准确率 |
|---|---|---|---|---|
| τ-bench | W&W* | 65 ± 1.5 | 18.8 ± 5.3 | – |
| τ-bench | AgentRx | 66.7 | 42.7 ± 1.5 | 47 ± 1.5 |
| Magentic | W&W* | 61.4 ± 6.8 | 22.7 ± 3.9 | – |
| Magentic | AgentRx | 71.2 ± 1.1 | 36.4 | 46.2 ± 1.3 |
| Flash | W&W* | 16.1 ± 1.2 | 64.3 ± 3.9 | – |
| Flash | AgentRx | 82.5 ± 1.4 | 82.5 ± 1.4 | 65.9 ± 5 |
| RelWork | W&W* | 57 ± 6.8 | 32.6 ± 1.3 | – |
| RelWork | AgentRx | 65.9 ± 5 | 61.5 ± 4.2 | 59.3 ± 2.1 |
「75% 提升」的口径:指表 3 中步骤定位准确率相对 W&W* 的相对提升的跨域平均——τ-bench 18.8→42.7(约 +127%)、Magentic 22.7→36.4(约 +60%)、Flash 64.3→82.5(约 +28%)、RelWork 32.6→61.5(约 +89%),四域平均约 +75%(论文摘要称「improves step localization by 75% on average over prior work」)。同时,根因类别归类相对我们自己的 judge-only 基线平均提升约 30%(如 τ-bench 30.8→47.0、Magentic 35.6→46.2、RelWork 46.7→59.3)。AgentRx 还在多数设置下改进了「失败 Agent 识别」,且与 W&W 不同,它能预测根因类别。归一化 IR 与证据落地的校验共同改善了异构 Agent 轨迹上的归因。
与 MAST 对比。MAST 研究聚合层面的多智能体失败模式,而 AgentRx 诊断单条失败轨迹。两者分类法并非一一对应:部分 AgentRx 标签在 MAST 中只有部分类似物,而「无效调用」「意图不受支持」「护栏触发」「系统失败」在 MAST 标签中不存在。由于 MAST 未为我们的关键步骤/根因任务提供金标签,我们把它用作泛化压力测试而非准确率 benchmark:不改代码直接在全部 1,022 条 MAST 轨迹上运行 AgentRx,为每条轨迹产出关键步骤、根因类别与支持性违规证据;移植到新 Agent 系统只需一个日志格式→IR 的适配器。结果画像因框架而异:「计划遵循失败」总体占主导,而「无效调用」「工具输出误读」「系统失败」在特定框架中突出(图 3);7.6% 的轨迹获得的 AgentRx 标签在 MAST 中没有对应项。步骤定位位置也因框架而异:AppWorld 失败得早,Magentic-One 失败得晚——与 MAST 关于「验证与终止类失败常见」的观察一致(图 4)。
4.3 违规证据与检查清单的作用(消融)
表 4 将 AgentRx 与 judge-only 基线(只看轨迹与分类法提示词、无 AgentRx 校验证据)对比,分离三种附加信号:仅违规证据(Baseline+Vio.)、仅检查清单(Taxonomy Checklist)、检查清单+违规(Checklist+Vio.);并区分两种评审协议(All-at-Once 一次输出 vs Step-then-Category 先定步骤再归类)与两种约束生成策略(one-shot vs step-by-step)。
表 4 关键数字摘译(步骤定位准确率 %,gpt-5 评审,n=3;「Checklist+Vio.」列为组合信号):
| 域 | Baseline | Baseline+Vio.(逐步约束) | Checklist+Vio.(逐步约束) |
|---|---|---|---|
| τ-bench | 29.9 ± 1.2 | 42.7 ± 1.5 | 39.3 ± 1.2 |
| Flash | 80.2 ± 1.4 | 81.7 ± 1.4 | 80.2 ± 3.6 |
| Magentic | 32.6 ± 1.3 | 34.1 ± 1.9 | 35.6 ± 1.3 |
| RelWork | 51.9 ± 4.6 | 61.5 ± 4.2 | 61.5 ± 2.1 |
类别准确率方面:τ-bench 由 30.8 升至 47.0(Checklist+Vio.,逐步);Flash 由 58.7 升至 65.9;Magentic 由 35.6 升至 46.2;RelWork 由 46.7 升至 59.3。Magentic 的平均步骤距离由基线的 22.5 大幅降至 12.4。
结论:违规证据在 τ-bench 与 RelWork 上带来最明显增益;检查清单在 Flash 上最有用——说明当违规证据稀疏或含噪时,语义结构可以更有分量;在 Magentic 上,检查清单+违规组合的步骤准确率最佳。总体上两种信号互补:违规帮助定位「有据可查」的错误,两者结合才能在跨域上给出可靠归因。
表 5:τ-bench 分类别准确率(Checklist vs Checklist+Vio.,逐步约束,n=3 合并):
| 类别 | 仅检查清单 | +违规 | Δ |
|---|---|---|---|
| 系统失败 | 0.0 | 66.7 | +66.7 |
| 意图–计划错位 | 5.6 | 61.1 | +55.5 |
| 工具输出误读 | 66.7 | 100.0 | +33.3 |
| 指令/计划遵循失败 | 75.0 | 66.7 | −8.3 |
| 凭空创造新信息 | 0.0 | 0.0 | 0 |
| 意图不受支持 | 0.0 | 0.0 | 0 |
| 用户意图欠明确 | 0.0 | 0.0 | 0 |
中文说明:违规证据显著拉升三类——「系统失败」与「意图–计划错位」(仅清单的评审几乎从不预测这两类)以及「工具输出误读」。「指令/计划遵循失败」略降,是因为仅清单评审把它当万金油标签;有了违规证据后,这些失败被归到真实原因上。
4.4 约束生成策略的影响
两种策略:one-shot——从完整轨迹一次性生成约束,更省钱;step-by-step——对每个前缀 T≤ₖ 生成约束,更贴合在线诊断(只依赖截至第 k 步可获得的信息)。如表 4 所示,逐步生成在各域一致优于一次性生成,且在长轨迹上优势最明显:Magentic 上逐步的 Checklist+Vio. 把平均步骤距离从 22.5 降到 12.4;Flash 轨迹短,两种策略表现接近。这与表 6 的轨迹长度统计一致:更长的痕迹在一次性生成下更易受上下文稀释(context dilution)影响,使局部化的逐步约束生成更可靠。
表 6:每条轨迹的平均 token 与字符数:
| 指标 | τ-bench | Flash | Magentic | RelWork |
|---|---|---|---|---|
| 平均每步 token | 133 | 169 | 330 | 393 |
| 平均每步字符 | 480 | 930 | 1280 | 1711 |
| 平均每条轨迹 token | 4889 | 6415 | 16484 | 5837 |
成本权衡:在实验所用 GPT-5 定价假设下,judge-only 基线每条约 0.05 美元,one-shot AgentRx 配置每条约 0.18 美元(约 3.6 倍)。开销主要来自约束生成(约占总成本 81%);最终评审阶段与基线相当。因此当全轨迹上下文足够时,one-shot 是性价比选项:大规模监控可用更便宜的模式,深度调试才值得逐步分析。
4.5 LLM-as-a-Judge 协议评估
比较两种评审协议:All-at-Once(一次调用同时预测关键步骤与类别,AgentRx 默认)与 Step-then-Category(先预测步骤、再对该步骤归类)。表 4 显示 Step-then-Category 常能提升类别准确率(τ-bench、Flash、Magentic 上皆是),但可能损害步骤定位——因为类别决策以一个可能含噪的第一阶段步骤为条件。
4.6 放宽指标下的鲁棒性
放宽步骤容差后准确率上升(Acc@±1 ≪ Acc@±3 ≪ Acc@±5)。类别预测报告四种口径:critical(根因归因)、any-failure(匹配任一失败类别——较弱但实用的「能标出失败」能力)、earliest、terminal。
表 7 关键数字摘译(AgentRx vs Baseline,n=3):
| 域(方法) | StepAcc. | Acc@±1 | Acc@±3 | Acc@±5 | 平均距离 | CriticalCat. | AnyCat. |
|---|---|---|---|---|---|---|---|
| τ-bench(Baseline) | 29.9 | 41.0 | 53.8 | 68.4 | 5.4 | 30.8 | 42.1 |
| τ-bench(AgentRx) | 42.7 | 48.7 | 61.5 | 68.4 | 3.8 | 47.0 | 50.9 |
| Flash(Baseline) | 80.2 | 94.4 | 100 | 100 | 0.2 | 58.7 | 62.7 |
| Flash(AgentRx) | 82.5 | 93.7 | 97.6 | 100 | 0.2 | 65.9 | 65.9 |
| Magentic(Baseline) | 32.6 | 43.2 | 43.9 | 52.3 | 22.5 | 35.6 | 50.8 |
| Magentic(AgentRx) | 36.4 | 47 | 54.6 | 59.8 | 12.4 | 46.2 | 59.1 |
| RelWork(Baseline) | 51.9 | 68.1 | 84.4 | 88.9 | 2.0 | 46.7 | 46.7 |
| RelWork(AgentRx) | 61.5 | 76.3 | 92.6 | 92.6 | 1.2 | 59.3 | 59.3 |
结论:无论严格口径还是放宽口径,AgentRx 都保持有用。
4.7 定性失败分析
我们人工检视了 AgentRx 给出错误或误导诊断的案例:
(1)呈现的违规可能误导评审。给评审看的违规证据有时指向错误的失败类型。一个 Flash 例子中,正确标签是系统失败——底层问题是基础设施性的:Kusto 查询因端点问题失败。但违规日志被「预定义查询与正确集群选择」等调用导向的检查主导。为缓解此问题,我们加入一个可选的反思与剪枝阶段:在评审前让 LLM 移除可能误报的生成约束。
(2)呈现的违规可能捕捉的是下游症状。违规可能真实存在,但位于根因下游,把诊断推向次生失败。在 Magentic-One 任务 1f975693-…中,正确标签是凭空创造新信息:Orchestrator 幻觉出「PDF 已成功下载」并基于该错误假设规划。但 AgentRx 的检查清单聚焦于轨迹后段第 51 步的护栏拦截(ResponsibleAIPolicyViolation)与 Orchestrator 发出的无依据 FINAL ANSWER,使诊断偏移到护栏触发——因为违规指向的是下游症状。
5 相关工作
Agent 评估 benchmark:近期工作覆盖工具执行、网页交互与助理行为(Barres et al., 2025;Yao et al., 2022 即 WebShop;Drouin et al., 2024 即 WorkArena)。AgentBench(Liu et al., 2024)在八个交互环境(代码、游戏、网页,含操作系统与数据库)中评估 LLM Agent;WebArena(Zhou et al., 2024)在真实网站上评估长程网页 Agent 能否把语言指令转化为可执行浏览器交互;GAIA(Mialon et al., 2023)针对「人类容易但常需多步工具使用」的通用助理问题。但这些 benchmark 主要报告终局成功率,不含失败归因的金标签。本文数据集标注第一个不可恢复关键步骤并赋予跨领域分类法类别。Who&When 是最接近的对比对象。
Agent 可靠性:AgentGuard(Koohestani, 2025)通过对照学习到的行为模型监控执行,提供运行时保障;也有工作把计划翻译成形式化表示并用模型检查(model checking)验证 Agent 行为与计划的对齐(Ramani et al., 2025;Zhang et al., 2025b)。这些方法主要面向运行时强制或计划符合性检查;本文的焦点是诊断轨迹——从工具、策略与已观察前缀中抽取约束,并把产生的违规作为失败归因的证据。另一条线通过反馈与自我修正提升 Agent 表现:Self-Refine(Madaan et al., 2023)形式化了「LLM 自我批评并修订」的迭代循环;CRITIC(Gou et al., 2024)用搜索、代码执行等外部工具作为反馈来验证输出。
Agent 轨迹的 LLM 评估:Gu et al.(2025)系统化了评审设计与不一致/偏差的缓解策略;Agent-as-a-Judge(Zhuge et al., 2025)用「会使用工具的 Agent」评估其他 Agent,主张其优于单次评审。AgentRx 与这些范式兼容,但通过提供证据,把评审从「打分」转向「诊断」。
6 结论
评估 Agent 不应只看它是否失败,更要看恢复在何处变得不可能。我们提出一个领域无关框架,通过生成约束并赋予根因类别来诊断失败轨迹。AgentRx 把 Agent 评估推向证据落地的调试:不仅解释 Agent 失败了,还解释它何时、为何失败。
7 局限性与威胁效度
- 分类法覆盖度:我们的失败分类法覆盖多样领域、由三名独立标注者标注,但可能未涵盖其他 Agent 领域的全部失败模式,或需扩展。
- 评审可能被误导:当校验信号弱或含误报时,AgentRx 可能被带偏——含噪或下游的违规信号会误导评审(见 4.7 的两个定性案例)。这引出未来工作:识别「区分真失败与噪声标记所需的最小高质量信号集」。
- 成本:AgentRx 依赖 LLM 调用,但相比人工失败归因显著降低人力、更易扩展;同时提供成本更低的 one-shot 约束生成作为替代(每条约 0.18 美元 vs 基线 0.05 美元,约束生成占约 81% 成本)。
- (威胁效度补充,散见于实验设置:所有配置跑 n=3 取均值±标准差以控制采样噪声与评审波动;W&W 对比经过格式适配与提示词修改以对齐「第一个不可恢复失败」的任务定义;MAST 仅作泛化压力测试而非准确率比较,因其无本任务金标签;RelWork 在冻结分类法下标注,作为分类法迁移性的留出检验。)
作者将框架与数据集视为「迈向 AI Agent 系统化、基于证据的失败归因」的一步。
伦理考量
本文目标是让 AI Agent 更易调试:帮助开发者用执行痕迹中已有的证据,定位运行首次变得不可恢复的位置与原因。收益:更快调试、更清晰的责任归属、更安全的迭代;benchmark 与分类法也促使更好的埋点(instrumentation)与「该记录什么、该检查什么」的思考。风险:更好的诊断不等于 Agent 可以安全部署,解释可能被过度信任为「保证」;轨迹数据可能含敏感信息,使用者须谨慎处理日志并遵循隐私实践;从既有 benchmark 学出的分类法会继承其盲区,应视为起点而非真实世界失败的完整地图。总之,本工作最好用作 Agent 调试框架:更早发现问题、主动修复,但不能替代认真测试。
附录要点
- 附录 A:分类法检查清单 𝖪(详见原论文)。为 9 个根因类别各给出一组是/否判定问题(每类 3–4 问),外加第 10 类 Inconclusive(须慎用并提供自定义类别)。示例:「无效调用」要求确认——失败步是否有具体调用载荷?运行时是否明确报出解析/schema/语法错误?且错误不是网络/超时类基础设施问题、不是 CAPTCHA/登录/付费墙拦截?这些排除式问题正是类别互斥性的操作化。附录还含 o3 评审消融(表 8:违规证据在覆盖密集的 τ-bench、Flash 上帮助 o3;在上下文厚重的 Magentic、RelWork 上 o3 无证据也有竞争力)与 DeepSeek-V3.2 消融(表 9:用开源模型跑完整流水线,在 Flash 与 τ-bench 上类别准确率提升 +5.6~+8.7 个百分点,Magentic 与 RelWork 上大致中性——证明 AgentRx 并非 GPT-5 专属)。
- 附录 B:层级评审协议(表 10)。比较 Step-then-Category、Category-then-Step 与 All-at-Once。两种两阶段协议都受误差传播之苦:过早锁定类别(或步骤)会丢弃单次联合判断可用的依据。Category-then-Step 在 τ-bench、Flash 上更好,但在长而嵌套的 RelWork、Magentic 上更差。唯一分解优于联合的场景是 Flash 的步骤定位(88.3% vs 82.5%,轨迹最短的域)。其余场合 All-at-Once 持平或更优,故保留为默认。
- 附录 C:根因归因 vs 第一个失败。用一条 Magentic 轨迹论证:W&W 把第 3 步(WebSurfer 无法访问文档)标为失败,但 Orchestrator 随后成功切换到 FileSurfer(系统展示了可用的回退机制);真正不可恢复的是第 33 步 FileSurfer 的幻觉——它把文件下载到某路径、之后却去读一个不存在的文件路径。前两个失败可恢复,第三个才是根因。
- 附录 D:Magentic-One 标注示例。一条轨迹共标注 22 个失败事件(步骤 5–120),呈级联结构:WebSurfer 反复未取到指定日期的到达时间信息(指令/计划遵循失败 ×10),随后 Orchestrator 反复尝试用邮件/电话联系(意图–计划错位 ×12);根因判定为第 1 个失败(WebSurfer 未取到关键信息),因其引发后续连锁误判。
- 附录 E:各失败类别的代表性轨迹示例(9 小节)。包括:系统失败(Flash:Kusto 集群连接失败+查询语法错误);工具输出误读(τ-bench:未正确数出可用 T 恤数量);指令遵循失败(Flash:结论未给出删除 VM 的关键缓解步骤与链接);凭空创造信息(Flash:幻觉出 Python 脚本与 Azure 链接);意图不受支持(Magentic:反复要求 WebSurfer 对 YouTube 视频截图,能力之外);用户意图欠明确(τ-bench:任务未指明黑色台灯型号,无法匹配真值动作);护栏触发(Magentic:DataVault 定价页被 Cloudflare 反爬 403+CAPTCHA 拦截,第三方来源也均被访问控制挡住);意图–计划错位(τ-bench:误以为可取消订单子集,结果整单被取消);无效调用(τ-bench:用 modify_order 取消子项却未提供必需的替换项,非法调用,且后续试图绕过)。
- 附录 F:约束生成。F.1 给出约束 schema 输出格式:断言名(snake_case)、taxonomy_targets(映射到 9 类)、constraint_type(SCHEMA / PROTOCOL / RELATIONAL_POST / PROVENANCE / TEMPORAL / CAPABILITY / ANY)、event_trigger(步骤/子步索引、角色名、内容正则、工具名,即「守卫」)、check_hint、pass/fail 示例、check_type(python_check 程序化 或 nl_check 语义)。F.2 展示一条完整的语义约束示例:「写操作(取消/换货/退货/改单/改地址)前必须有用户显式确认」——含评审系统提示词(严格合规评审:证据不足标 UNCLEAR 并丢弃,只有确凿证据才判 fail)、用户提示词模板、评审范围说明、聚焦步骤指令、三条 rubric 准则、rubric 评估算法与 JSON 输出格式。
- 附录 G:违规示例。展示 T 恤计数约束
tshirt_available_options_match_variants_count的完整 Python 检查代码:从当前步助理内容用正则提取声称的「available」数量,回溯找到最近一次get_product_details工具响应,解析 variants 中available == true的条目数并比对,不一致即违规。 - 附录 H:评审提示词(3 套全文)。H.1 基线评审提示词(分类法 10 类定义+三步决策程序:从头扫描找第一个失败→检查其是否被解决→未解决即为根因,已解决则继续扫描;输出 JSON:失败原因、类别编号 1–10、步骤索引及理由)。H.2 检查清单版基线(每类附 checklist 问题,输出多一个 checklist 推理字段)。H.3 AgentRx 评审提示词(在基线之上附加违规清单:每条违规含步骤索引、断言名、约束类型、检查类型、严重度、check hint、证据窗口、taxonomy targets;并提示「部分违规可能是误报、并非都与根因相关」)。
- 附录 I:开源许可。τ-bench、Magentic-One、Who&When 为 MIT License;MAST 为 CC-BY 4.0;AgentRx benchmark 以 MIT License 发布(论文本身为 CC BY 4.0)。
原文链接:https://arxiv.org/abs/2602.02475 PRIMARY_SOURCE: https://arxiv.org/abs/2602.02475
- #Agent评估
- #故障诊断
- #可审计
- #安全治理


