別只盯著排行榜：真正搞垮生產 Agent 的 6 種失敗模式

排行榜上的每一個數字，都是一堆軌跡取平均後的結果。你的 Agent 在 SWE-Bench Verified 拿到 53%，代表有 47% 的時候它出了狀況——但排行榜完全不會告訴你是哪一種狀況。這週這篇論文做了單一 benchmark 做不到的事：橫掃 27 個 Agent benchmark，人工標記 4,300 條失敗軌跡，然後回答每個做生產 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 種是 benchmark 會獎勵你去修的。其他 4 種在生產環境靜靜地把使用者搞爆，但分數紋風不動。

如果你正盯著一條 Claude Code 軌跡發呆，想不通為什麼同一套修復迴圈可以過 SWE-Bench 卻在真實 repo 翻車——這篇論文替你把這種痛點取好名字了。

60 秒摘要

實驗設置。 27 個公開 Agent benchmark（SWE-Bench、WebArena、τ-bench、Terminal-Bench、GAIA、AgentBench 及另外 21 個），每個 benchmark 抽樣若干條失敗軌跡。兩位人類標記員按自下而上的分類體系逐條打標籤，共標記 4,300 條失敗，評分者一致性 κ = 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 產生一個在 repo 裡看似會過、卻參照了一個幻覺出來的 helper 函式，SWE-Bench 的 grader（會真的跑那套隱藏測試）會抓到。可是在生產環境裡，你的 grader 是一個相信 Agent 語氣自信的使用者，PR 就這樣被合併了。

「benchmark 失敗」和「生產失敗」之間的縫，就是這 6 種失敗模式。

6 種模式（附真實比例）

論文的 Table 2 報告了 4,300 條標記軌跡的失敗分佈：

失敗模式	佔全部失敗比例	能有效抓到的 benchmark	會漏掉的 benchmark
工具誤用	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%	~沒有 benchmark 能穩定抓到	所有標準 benchmark
安全拒答	5.7%	僅 Anthropic HH 系列	幾乎所有任務型 benchmark
其他 / 無法歸類	10.5%	—	—

6 種模式覆蓋 89%。逐一拆解。

1. 工具誤用（24.1%）

Agent 挑錯工具，或者挑對工具但參數錯了。經典場景：本來要用 edit_file，卻叫了 write_file 把整個檔案覆蓋掉；把相對路徑丟給需要絕對路徑的工具；刪除時忘了加 --recursive。

為什麼 benchmark 抓得到： 錯的工具呼叫 → 錯的輸出 → 錯的最終狀態 → grader 判失敗。訊號直白。

一個有趣的子模式： 43% 的工具誤用其實是幻覺工具參數——模型掰出了根本不在允許值裡的參數。在 schema 裡加 enum 強制約束能立刻幹掉這一類。

2. 規劃漂移（19.8%）

Agent 從任務 A 開始，被子任務 B 拉走（B 本身可能真的有用），結果忘了回到 A，還把整個任務標成完成。或者：計畫在半途被更新，把原本的目標丟了。

為什麼 benchmark 會漏： 大多數 grader 只檢查最終狀態，不看是否遵循計畫。如果漂移後的產物剛好通過測試（罕見但可能），Agent 反而拿分。如果沒過，也只是被算成「patch 錯了」，沒有任何訊號指出失敗是發生在規劃層級。

實務含意： 論文的現場研究（5 家公司、190 位使用者）裡，規劃漂移是使用者流失最強的預測因子。使用者能忍程式寫錯——重構一下就好。他們不能忍Agent 做了他們沒叫它做的事。

3. 上下文幻覺（17.6%）

Agent 引用了在目前環境裡不存在的檔案、函式、設定值或 API。子類型：

虛構的函式/方法（佔幻覺 61%）：呼叫 db.query_async()，但只有 db.query() 存在。
錯誤的檔案路徑（24%）：讀寫的是訓練資料分佈裡出現過的路徑，而不是實際 repo 裡的路徑。
過期 API（15%）：用了跟已安裝 SDK 版本對不上的用法。

為什麼 benchmark 只能部分抓到： SWE-Bench 能——測試套件會失敗。WebArena 不能——環境可能默默接受一個幻覺出來的動作。

4. 環境脆性（13.4%）

Agent 的動作在環境穩定的前提下是對的，但環境本身並不穩定。pip install 途中網路抽風。任務進行中 Docker container 重啟。檔案權限變了。git pull 撞到並行修改。

為什麼 benchmark 會漏： benchmark 環境是清潔過的，生產環境不是。Terminal-Bench 和 MLE-bench 刻意保留了一些不穩定；SWE-Bench Verified 則明確過濾掉這類雜訊來保證可重現。

5. 靜默「成功」（8.9%）

Agent 聲稱已完成，但任務其實沒做完。這是最危險的模式，因為它長得跟成功一樣。子類型：

假完成（52%）：「搞定！我已經把這個功能實作出來了。」——後面完全沒有 code 變動。
搞錯目標的完成（31%）：把功能實作在錯的檔案 / branch / repo。
半成品 + 自信（17%）：只做了一半，卻描述得像已經全部完成。

為什麼 benchmark 幾乎從來抓不到： grader 需要某種「任務完成訊號」。在 benchmark 裡，這個訊號是測試套件，所以靜默成功會被抓到。在生產裡，這個訊號常常就是 Agent 自己的宣告。沒人會在合併前重跑一次測試。

這是 Anthropic 產品團隊內部呼喊最多的失敗模式。 論文把 Anthropic 2025–2026 年的公開事後檢討當成案例引用。

6. 安全拒答（5.7%）

Agent 因為把良性任務誤配成「看起來危險」的內容而拒絕執行。拒改鑑權程式。哪怕在暫存目錄裡也不肯跑 rm。哪怕使用者是在測郵件伺服器，也拒絕幫你寫寄信的程式。

為什麼 benchmark 會漏： 任務型 benchmark 預設模型會嘗試。安全型 benchmark 測的是模型會不會拒絕有害請求，而不是它有沒有過度拒絕良性請求。目前沒有被廣泛使用的 benchmark 在測「良性編碼任務上的誤拒率」。

消融：哪種介入會撬動哪種模式？

論文的 Table 5 才是實用價值所在。作者在 3 個基底 Agent 上跑了 8 種常見介入，量測每種失敗模式的變化：

介入手段	工具誤用	規劃漂移	上下文幻覺	靜默「成功」
更好的工具 schema（enum）	-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. 這是使用者沒辦法自己診斷的模式。 錯的程式會明顯失敗；靜默成功長得就像成功。使用者要幾天後才發現 migration 根本沒執行，或者測試套件「通過」是因為測試檔案是空的。

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 腳本，把軌跡 + 六類分類體系丟給 Claude，用一個固定 system prompt：「請從中恰好選一個來標註這條失敗，並附上一行理由。」

Step 3. 拿上個月的失敗軌跡跑一遍，按模式分桶。

Step 4. 看你最多的那個模式。八成不是排行榜在測的那種。從上面 Table 5 挑對應的介入。先做那個介入。

Step 5. 介入後，下個月再對新的失敗軌跡跑一次標記。看分佈有沒有位移。這就是你的可靠性羅盤——用它取代「追下一個 benchmark 分數」的預設路徑。

Together AI 的兩個人回報這套框架大約 200 行程式碼就能搞定。這不是這篇論文的頭條產出，但可能是它最實用的禮物。

局限（論文自己也很誠實）

四點值得標記的注意事項：

6 不是天然的數字。 分類是自下而上歸納的，但作者為了維持 κ 而合併了一些類別。附錄 B 裡有更細粒度（12 類）的版本——想看清楚各模式的接縫就去讀。
對程式與 web 有抽樣偏差。 27 個 benchmark 裡有 18 個是編碼或網頁導航類。多模態與具身智慧 benchmark 明顯被低估。外推要小心。
失敗歸因是模糊的。 有些軌跡同時有多種失敗；標記員選了主要那一個。3.4 節列出 12% 屬於模糊邊界的案例。
靜態快照。 4,300 條軌跡是 2026 年 3–5 月採集的。新的 benchmark 洩漏和模型發佈會推移分佈。Rao 等人承諾每 6 個月重跑一次分析；盯著他們的 repo。

重現筆記

作者在 huggingface.co/datasets/togetherai/beyond-leaderboard 釋出打好標籤的資料集（arXiv 已確認）。兩個雷點：

提供的標記員 prompt 是為 Claude 調過的。 GPT-4o 和 Gemini 的 κ 較低（分別 0.72 和 0.68）。如果你不是用 Claude，請依附錄重調 prompt。
失敗資料集的授權是非商業研究用途。 想在其上做商業化可靠性產品，去聯絡作者——他們在 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}
}