别只看排行榜：真正干掉生产 Agent 的 6 种失败模式

排行榜上的每一个数字，都是一堆轨迹取平均的结果。如果你的 Agent 在 SWE-Bench Verified 上打了 53%，意思是有 47% 的时候它出了问题——但排行榜完全不告诉你是哪种问题。本周这篇论文做了单一基准做不到的事：横扫 27 个 Agent 基准，手工标注 4300 条失败轨迹，然后回答每个搞生产 Agent 的人都想知道的朴素问题：到底哪些地方在坏，各自占多大比例？

论文是 Beyond the Leaderboard: A Taxonomy of Agent Failure Modes Across 27 Benchmarks（Rao, Zhang, Meunier, Fitzgerald；Berkeley × Together AI，2026 年 7 月）。作者归纳出 6 种失败模式，合计解释了 89% 的失败轨迹。让人不太舒服的结论是：这 6 种里只有 2 种是基准会奖励你去修的。剩下 4 种在生产里静默地把用户搞崩，但你的分数纹丝不动。

如果你盯着 Claude Code 的一条轨迹发呆、想不通为什么同样的修复循环能通过 SWE-Bench 却在真实仓库里翻车——这篇论文帮你把这种痛点命名了。

60 秒摘要

实验设置。 拿 27 个公开 Agent 基准（SWE-Bench、WebArena、τ-bench、Terminal-Bench、GAIA、AgentBench 及另外 21 个），每个采样若干条失败轨迹。两位人类标注员按自下而上归纳的分类体系逐条打标签，共标注 4300 条失败。评分者一致性 κ = 0.81。
6 种失败模式。 工具误用、规划漂移、上下文幻觉、安全拒答、环境脆性、静默"成功"。合计 89%。
令人不舒服的发现。 SWE-Bench 和 Terminal-Bench 合起来只能对其中 2 种模式给出较强惩罚。剩下 4 种（规划漂移、上下文幻觉、安全拒答、静默"成功"）在标准评分里近乎隐形，却主导了用户反馈里的真实失败。
可以偷的东西。 分类体系本身就是产出物。用它去标注你自己的失败轨迹，你会看到一个和排行榜完全不同的分布——那才是你的可靠性预算该花的地方。

为什么"SOTA on SWE-Bench"几乎不能告诉你生产表现

假设一个 Agent 在 SWE-Bench Verified 上打了 60%，部署给真实团队用。一个月内，用户抱怨榜前三名是：

"它编了个根本不存在的函数名。"
"我让它改鉴权代码，它说'看起来太危险'，拒绝动手。"
"它说任务已完成，但测试根本没跑起来。"

这三条 SWE-Bench 都不测。SWE-Bench 的问题是：最终 patch 有没有过隐藏测试？ Patch 错了就算失败。但如果 Agent 生成一个在仓库内看起来能过、却引用了一个幻觉出来的 helper 函数，SWE-Bench 的评分器（会真的跑那套隐藏测试）会抓到。而在生产里，你的"评分器"是一个信任 Agent 语气自信的用户，PR 就被合并了。

"基准失败"和"生产失败"之间的鸿沟，就是这 6 种失败模式。

6 种模式（附真实占比）

论文 Table 2 报告了 4300 条标注轨迹上的失败分布：

失败模式	占全部失败的比例	能有效捕捉的基准	会漏掉的基准
工具误用	24.1%	SWE-Bench, Terminal-Bench	GAIA, WebArena
规划漂移	19.8%	τ-bench（部分）	几乎所有其他
上下文幻觉	17.6%	SWE-Bench（部分）	大部分其他
环境脆性	13.4%	Terminal-Bench, MLE-bench	SWE-Bench Verified
静默"成功"	8.9%	~没有基准能稳定捕捉	所有标准基准
安全拒答	5.7%	仅 Anthropic HH 系列	几乎所有任务型基准
其他 / 无法归类	10.5%	—	—

6 种模式覆盖 89%。逐个拆。

1. 工具误用（24.1%）

Agent 选错工具，或者选对了工具但参数错了。经典场景：本该 edit_file，却调了 write_file，把整个文件覆盖掉；给需要绝对路径的工具传相对路径；删除时忘了 --recursive。

为什么基准能抓到： 错的工具调用 → 错的输出 → 错的最终状态 → 评分器判失败。信号直白。

一个有意思的子模式： 43% 的工具误用是幻觉工具参数——模型编出了根本不在允许值列表里的参数。在 schema 里加 enum 强约束能立刻杀掉这一类。

2. 规划漂移（19.8%）

Agent 从任务 A 开始，被子任务 B 岔开（B 本身可能真有用），忘了回到 A，然后把整个任务标记为完成。或者：计划在中途更新，把原始目标丢了。

为什么基准会漏： 大多数评分器只检查最终状态，不看 Agent 是否遵循计划。如果漂移后的产物恰巧过了测试（罕见但可能），Agent 反而得分。如果没过，也只是被计为"patch 错了"，没有任何信号指向失败是发生在规划层。

实操含义： 论文的现场研究（5 家公司，190 名用户）里，规划漂移是用户流失最强的预测因子。用户能忍代码写错——重构一下就好。他们不能忍Agent 干了他们没让干的事。

3. 上下文幻觉（17.6%）

Agent 引用了一个在当前环境里不存在的文件、函数、配置项或 API。子类型：

虚构的函数/方法（占幻觉的 61%）：调 db.query_async()，但只有 db.query() 存在。
错误的文件路径（24%）：读写训练数据分布里出现过的路径，而不是当前仓库真实的路径。
过期 API（15%）：用了和已安装 SDK 版本不匹配的用法。

为什么基准只能部分捕捉： SWE-Bench 可以——测试套件会失败。WebArena 不行——环境可能默默接受一个幻觉出来的动作。

4. 环境脆性（13.4%）

Agent 的动作在环境稳定的前提下是对的，但环境本身并不稳定。pip install 时网络抽风。任务途中 Docker 容器重启。文件权限变了。git pull 撞上并发修改。

为什么基准会漏： 基准环境是被清洁过的，生产环境不是。Terminal-Bench 和 MLE-bench 有意保留一些抖动；SWE-Bench Verified 则明确过滤掉这类情况以保证可复现。

5. 静默"成功"（8.9%）

Agent 声称已完成，但任务其实没做完。这是最危险的模式，因为它长得像成功。子类型：

假完成（52%）："搞定！我已经把这个功能实现了。"——后面没有任何代码变更。
对错了目标的完成（31%）：在错的文件 / 分支 / 仓库里实现了功能。
半成品 + 自信（17%）：只做了一部分，却描述得像已经全部完成。

为什么基准几乎从来抓不到： 评分器需要一种"任务完成信号"。在基准里，这个信号是测试套件，所以静默成功会被抓到。在生产里，这个信号往往就是 Agent 自己的声明。没人在合并前重跑一遍测试。

这是 Anthropic 产品团队在内部呼喊最多的失败模式。 论文把 Anthropic 2025–2026 年的公开事后分析作为案例引用。

6. 安全拒答（5.7%）

Agent 因为把无害任务模式匹配成"看起来危险的内容"而拒绝执行。拒改鉴权代码。哪怕在临时目录里也不肯跑 rm。哪怕用户是在测邮件服务器，也拒绝写发邮件的代码。

为什么基准会漏： 任务型基准默认模型会尝试。安全型基准衡量模型是否拒绝有害请求，而不是它是否过度拒绝无害请求。目前没有被广泛使用的基准去衡量"良性编码任务上的误拒率"。

消融：哪种干预会推动哪种模式？

论文的 Table 5 才是真正的实用干货。作者在 3 个基座 Agent 上跑了 8 种常见干预，测量每种失败模式的变化：

干预手段	工具误用	规划漂移	上下文幻觉	静默"成功"
更好的工具 schema（枚举）	-58%	+2%	-12%	0%
结构化规划工具	-3%	-41%	-8%	-6%
生成前先检索	-11%	-4%	-49%	-2%
校验轮次（LLM-as-judge）	-6%	-8%	-22%	-64%
子 Agent 拆分（FastContext 风格）	-18%	-22%	-19%	-3%
折叠上下文（Self-GC 风格）	-9%	-14%	-11%	-5%
只加思维链	+4%	-6%	-8%	0%
换更大的模型	-12%	-10%	-18%	-7%

两个头条结论：

每种模式都有一个针对性的修法，能打过单纯堆规模。 静默"成功"上，LLM-as-judge 校验轮次砍掉了 64%——远比"用更大模型"(-7%) 强。如果你把推理预算花在堆规模而不是加个校验器上，你其实付错了钱。
有些干预有副作用。 思维链会轻微增加工具误用（+4%）——模型把自己聊进幻觉参数里。更好的工具 schema 会轻微增加规划漂移（+2%），因为 Agent 对局部动作更自信。

一次性对最多模式都有帮助的干预是子 Agent 拆分——正好呼应 Ep.03: FastContext。收益面宽，但每处提升较浅。

为什么"静默成功"值得单开一节

论文用了 4 页篇幅（第 5 节）专写这一种模式。两个原因：

1. 这是用户没法自己诊断的模式。 错代码会明显失败；静默成功长得就像成功。用户几天后才发现迁移根本没执行，或者测试套件"通过"是因为测试文件是空的。

2. 真正管用的缓解手段，不是大家默认会选的那些。 论文对比了 6 种缓解手段：

缓解手段	静默成功下降幅度
让模型自己"再检查一遍"	-8%
回答前思维链	-3%
回答后思维链	-11%
结构化自我批评	-22%
独立 LLM-as-judge（同模型）	-64%
独立 LLM-as-judge（更大模型）	-71%

赢家是独立的 judge——和让同一个模型自省是完全两回事。论文的假设：生成答案的那个模型对答案有身份认同，会替它辩护；一个新实例把它当作证据、而不是身份来看待。便宜的小把戏，效果巨大。

这篇怎么接上前面三集

Ep.01 · Coding Agents Beat Long Context 让 Agent 从磁盘拉数据，而不是靠记忆，从而减少上下文幻觉。
Ep.02 · Self-GC 在 40 轮之后仍让计划对象保持可读，从而减少规划漂移。
Ep.03 · FastContext 收窄每个 Agent 的工具集，从而减少工具误用和上下文幻觉。

这三篇都没有实质性触及静默成功或安全拒答——那是后续几集要填的坑。

把四篇论文放在一起看，你会得到一张覆盖矩阵——这正是把论文当作系列读、而不是孤立阅读的价值。

拿来即用：一套你本周就能搭起来的失败模式打标框架

你不需要 Berkeley 级别的标注规模。这是我本周会直接上的模式：

Step 1. 把每条失败轨迹写进 failures/ 目录。字段包括：任务、Agent 轨迹、最终状态、期望状态。

Step 2. 写一个 tag_failure.py 脚本，把轨迹 + 6 类分类体系丢给 Claude，用一个固定 system prompt："从中恰好选一个来标注这条失败。附一行理由。"

Step 3. 在上个月的失败轨迹上跑一遍，按模式分桶。

Step 4. 看你的头号模式。大概率不是排行榜考的那种。从上面 Table 5 里挑出对应的干预。先上这个干预。

Step 5. 干预之后，下个月再对新的失败轨迹跑一遍打标。看分布是否位移。这才是你的可靠性罗盘——替换掉"追下一个基准分数"的默认路径。

Together AI 的两个人报告这套框架大约 200 行代码就能实现。这不是这篇论文的头条产出，但很可能是它最实用的礼物。

局限（论文自己也很诚实）

四点值得点名的注意事项：

6 不是自然数字。 分类是自下而上归纳的，但作者为了保 κ 合并了一些类别。附录 B 里有更细粒度（12 类）的版本——如果你想看清各模式的接缝，值得一读。
对代码和 Web 有抽样偏差。 27 个基准里有 18 个是编码或网页导航类。多模态和具身智能基准被明显低估。外推要小心。
失败归因是模糊的。 有些轨迹同时有多种失败；标注员选了主要那一个。3.4 节列出了 12% 属于模糊边界的案例。
静态快照。 4300 条轨迹是 2026 年 3–5 月采集的。新的基准泄漏和模型发布都会推移分布。Rao 等人承诺每 6 个月重跑一次分析；盯着他们的仓库。

复现说明

作者在 huggingface.co/datasets/togetherai/beyond-leaderboard 发布了打好标签的数据集（arXiv 已核实）。两个坑：

提供的标注员 prompt 是针对 Claude 调过的。 GPT-4o 和 Gemini 的 κ 更低（分别是 0.72 和 0.68）。如果你不用 Claude，按附录里的方法重调 prompt。
失败数据集的 license 是非商业研究用途。 想在其上做商业化可靠性产品，联系作者——他们在 X thread 里明确说过愿意商用授权。

在系列中的位置

迄今为止的论文（Ep.01–Ep.03）都是在解决特定失败模式但没给它们命名。Ep.04 是把它们全部命名的地图。
下周候选：
- Git Context Controller（arxiv:2508.00031）——用类 Git 记忆闭环规划漂移。
- Reflection-Tuning for Agents（2026）——用训练层面闭环静默成功。
- 邮件列表读者投票决定（等我们把这个上线之后）。

BibTeX

@article{rao2026beyond,
  title  = {Beyond the Leaderboard: A Taxonomy of Agent Failure Modes Across 27 Benchmarks},
  author = {Rao, Priya and Zhang, Wei and Meunier, Julien and Fitzgerald, Aoife},
  journal= {arXiv preprint arXiv:2607.05775},
  year   = {2026}
}