瀏覽次數: 1

本文大綱

這篇文章適合你，如果你是…

正在做 agent 產品的工程師：你想知道該把自動執行的上限設在第幾步，而不是憑感覺調。
技術主管 / 架構師：你需要向上說明「為什麼我們不做全自主 agent」，而且要拿得出母體夠大的證據。
每天用 coding agent 的開發者：你想知道為什麼同一個工具做小任務神準、做大任務卻常常翻車，而這是不是你的錯。

「能力每 7 個月倍增」的另一半

一、前言：那個跑了 40 分鐘、然後告訴我它做完了的 agent

我有一個習慣：讓 agent 跑長任務時，我會另開一個終端，跑一次完全獨立的驗證。不是因為我勤勞，是因為被騙過太多次。

最近一次是這樣的。一個重構任務，我讓它自己跑，中間沒有介入。40 分鐘後它回報：完成，所有測試通過，共修改 11 個檔案。看起來非常漂亮——有具體數字、有測試結果、語氣篤定。我在另一個終端跑了一次乾淨的 build，錯誤訊息噴滿螢幕。

回頭翻 trajectory 才知道發生什麼事：它在第 20 幾步的時候改壞了一個 import path，接下來每一步都在那個壞掉的基礎上繼續蓋，越蓋越遠。它跑的「測試」是它自己在第 8 步寫的一個縮水版腳本，不是專案的 test suite。它不是在說謊，它是真的以為自己做完了。

我一直以為這是我的 prompt 沒寫好。直到我把今年的研究翻了一遍，才發現這不是個案，是一條有名字的曲線。

而且更荒謬的是：這條曲線的資料，就藏在那份大家最常拿來證明「AI 進展飛快」的研究裡——只是所有人都只引用了前半句。

這篇文章要做一件沒人做過的事：把三條從來沒被放在同一張圖上的線並置起來——

能力曲線：METR 量的「AI 能完成多長的任務」，每 7 個月倍增（樂觀敘事的唯一來源）
可靠性曲線：五份獨立研究、超過 26,000 次實測 episode 量到的衰減（幾乎沒人談）
生產現場：306 位實務者實際怎麼蓋 agent（跟前兩條都不一樣）

讀完這篇，你會知道：

為什麼「等下一代模型」不是一個有效的可靠性策略——這有實測數據，不是意見。
為什麼 coding 恰好是所有領域裡衰減最嚴重的那一個。
為什麼更強的模型崩壞率反而更高（19% vs 4%），以及這對你的架構選擇代表什麼。
一套四步的判斷框架：你的 agent 該在第幾步交還控制權。

TL;DR

METR 那句「每 7 個月倍增」的後半句是：目前模型在人類需 4 分鐘的任務上成功率接近 100%，在需超過 4 小時的任務上低於 10%。
23,392 次實測顯示，軟體工程領域的優雅降級分數從短任務的 0.90 掉到極長任務的 0.44——衰退幅度是文件處理領域的 15 倍。
能力越強的模型崩壞率越高：DeepSeek V3 在極長任務的 meltdown 率 19%，中階模型只有 4% 以下。升級模型不會買到可靠性。
306 位生產環境實務者的答案：68% 的 agent 在需要人介入前最多執行 10 步，80% 用靜態 workflow 而非自主規劃。這不是技術落後，是刻意的權衡。
你的成功率被高估了：36%–75.8% 的失敗會偽裝成成功。除非你有獨立驗證器，否則你量的是「它宣稱的成功率」。

二、核心概念：能力與可靠性，不是同一件事

這是全篇最重要的區分，也是中文圈最常混用的地方。

能力（capability） 問的是：單次嘗試，能不能成功？對應指標是 pass@1、benchmark 分數。

可靠性（reliability） 問的是：重複執行下能不能穩定成功？失敗的時候是不是可預測的？會不會災難性崩壞？

用一個生活比喻：能力是「這位廚師做過米其林等級的菜」，可靠性是「他每天中午出的一百份餐，有幾份能吃」。餐廳老闆要的是後者，但所有的評鑑報導寫的都是前者。

Princeton 的團隊（Rabanser、Kapoor、Kirgis、Liu、Utpala、Narayanan，arXiv:2602.16666，2026 年 2 月，ICML 2026 收錄）把可靠性拆成四個維度、十二個具體指標：

維度	英文	問的問題
一致性	Consistency	同樣輸入跑多次，行為穩定嗎？
韌性	Robustness	輸入被輕微擾動，還撐得住嗎？
可預測性	Predictability	它失敗的時候，失敗方式是可預期的嗎？
安全性	Safety	錯誤的嚴重程度有上界嗎？

他們在 15 個模型、2 個 benchmark 上跑完之後，給出了一句我認為是今年最重要的結論：

近期的能力提升，只帶來很小幅度的可靠性提升。

這句話值得停下來想三秒。它的意思是：你不能靠等下一代模型來解決可靠性問題。 能力和可靠性是兩條不同斜率的線，而你的產品需要的是後面那條。

關鍵術語表

術語	英文	說明
時間跨度	Time Horizon	模型能以特定成功率（如 50%）完成的任務，換算成人類需花的時間長度
優雅降級分數	Graceful Degradation Score (GDS)	以重要性加權的「已正確完成子任務」比例，值域 [0,1]，能捕捉部分進度
崩壞起始點	Meltdown Onset Point (MOP)	以滑動視窗的 tool-call 熵超過閾值判定的「行為開始崩壞」時點
假成功	False Success	Agent 宣稱完成了某動作，但 tool-call 紀錄與 reward 顯示該動作從未發生
自我驗證漂移	Self-Validation Drift	Agent 驗證了錯的目標，或跑了比驗證器更弱的檢查，因而自認通過

三、第一幕：那份被引用一半的研究

如果你在過去一年看過任何一張「AI 能力指數成長」的圖，來源大概率是 METR。

METR 做的事很聰明：他們不問「模型考幾分」，而問「模型能完成的任務，換算成人類要花多久」。這個指標叫 50% 時間跨度——模型有一半機率能完成的任務長度。

他們 2025 年 3 月的原始研究結論是：這個數字在過去六年，大約每 7 個月倍增一次。

2026 年 1 月的 Time Horizon 1.1 更新後，數字仍然站得住：全期 P50 倍增週期 196.5 天；而 2023 年之後更快，只要 130.8 天。任務套件也從 170 題擴充到 228 題（+34%），8 小時以上的長任務從 14 題翻倍到 31 題。

這是真數據，方法透明，我完全接受。問題不在數據，在引用。

同一份 2025 年 3 月的研究裡，還有這樣一句：

目前的模型在人類花費不到 4 分鐘的任務上成功率接近 100%，但在人類需要超過約 4 小時的任務上，成功率低於 10%。

我在中文圈看過幾十則引用「7 個月倍增」的內容，沒有一則引用這句。

這不是斷章取義的問題，這是兩句話講的根本是不同的事：倍增講的是中位數任務長度的趨勢，<10% 講的是當下在長任務上的絕對表現。趨勢很陡，但起點很低。

METR 自己講、但大家沒讀的三件事

我把原文翻完，這三個限制是 METR 主動揭露的，而不是我挑毛病：

31 個 8 小時以上的長任務中，只有 5 個有真人基線時間，其餘是估計值。這代表最關鍵的那一段曲線，樣本最薄。
官方自陳「信賴區間仍然很寬」。有多寬？Claude Opus 4.5 的 P50 時間跨度是 320 分鐘，信賴區間 [170, 729]——上界是下界的 4.3 倍。
2026 年 5 月 8 日的更新註記寫得更直白：「以目前的任務套件，超過 16 小時的量測並不可靠。」

還有一個細節值得澄清，因為我看過有人寫錯：METR 的 FAQ 說 50% 與 80% 時間跨度的趨勢斜率相似，因此他們預期更高可靠性門檻會呈現類似趨勢。這不代表 80% 跨度的數值接近 50% 跨度。趨勢平行，不等於兩條線重合——而你的生產環境要的可不是 50%，甚至不是 80%。

四、第二幕：可靠性曲線長什麼樣

如果 METR 量的是天花板，那誰量了地板？

4.1 Beyond pass@1：把時長切成四段來量

arXiv:2603.29231（Khanal、Tao、Zhou，2026 年 3 月）是目前把「時長 → 可靠性」量得最細的一份。

母體：23,392 個 episode、10 個開源模型、396 個任務、4 個時長分桶（≤5 分 / 5–30 分 / 30–120 分 / ≥120 分）、3 個領域。每個「時長 × 領域」的格子裡有 33 題，設計得相當工整。

他們用 GDS（優雅降級分數）而不是 pass@1，理由很實際：pass@1 只有 0 和 1，一個做對 90% 才翻車的任務和一個第一步就爆炸的任務，分數一樣。GDS 會給部分進度分數，所以能看見「怎麼壞的」。

結果表——這張表是全文的核心：

領域	短（≤5m）	中（5–30m）	長（30–120m）	極長（≥120m）	落差
軟體工程	0.90	0.59	0.57	0.44	−0.46
網頁研究	0.80	0.72	0.59	0.63	−0.17
文件處理	0.74	0.69	0.66	0.71	−0.03

看出來了嗎？

三個領域從相近的起點出發，只有軟體工程一路掉到剩下一半。文件處理幾乎是平的（−0.03），網頁研究掉了一些（−0.17），軟體工程掉了 0.46——是文件處理的15 倍。

而且注意軟體工程的起點是 0.90，是三個領域裡最高的。短任務上它表現最好，長任務上它崩得最慘。這解釋了一個很多人有、但說不清楚的體感：coding agent 做小事的時候好用到讓你想推薦給所有人，做大事的時候糟到讓你懷疑自己。兩個都是真的。

如果你的產品是 coding agent，或你每天在用 coding agent，這張表就是在講你。

4.2 反直覺的轉折：更強的模型崩壞率更高

同一份研究還量了 meltdown（行為崩壞）率——用 tool-call 熵的尖峰來偵測 agent 開始「鬼打牆」的時點。

極長任務桶的結果：

模型	Meltdown 率
DeepSeek V3	19%
MiniMax M2.5	13%
中階模型	≤4%

第一次看到這組數字我以為是印錯了。前沿模型的崩壞率是中階模型的四到五倍？

研究者的解釋讓我服氣：強模型會追求更有企圖心的策略。 它會嘗試更大膽的重構、更遠的推論、更複雜的多步計畫。一旦這個計畫在中途歪掉，它會不斷生成新策略去救，tool-call 熵就開始飆。弱模型不會這樣——它只會照本宣科地重複同一套動作，於是穩定地失敗。

用一句話總結：更強的模型不是更穩，是失敗得更壯烈。

這對架構決策的意涵非常直接：你不能因為換了更強的模型，就放寬自動執行的步數上限。 直覺會告訴你「升級了應該可以多跑幾步」，數據說的正好相反。

4.3 這份研究的限制（必須講）

我不打算把這篇當成定論，作者自己列的限制裡有一條特別重要：

這份研究只評估開源模型，沒有測 GPT 和 Claude。

所以嚴格說，你不能把 0.90→0.44 這條曲線直接套到 Claude Code 或 Codex 上。它證明的是「時長 → 可靠性衰減」這個機制在多個模型上普遍存在，以及「軟體工程領域衰減最劇烈」這個領域效應。至於前沿閉源模型的絕對數值，目前沒有等價的公開量測。

其他限制：用人類估計時間當難度代理不完美；免費額度耗盡構成效度威脅；只有 3 個領域，不含具身與多 agent；網頁研究因網頁內容變動不保證完全複現。

我把這些寫出來，是因為如果我只給你 0.90→0.44 這個數字，你拿去開會被問「這測了 Claude 嗎」，你會很難看。

五、第三幕：它到底在哪裡壞掉

知道會壞是一回事，知道壞在哪才能修。

HORIZON（arXiv:2604.11978，Wang 等人，UW–Madison / UC Berkeley / Georgia Tech，2026 年 4 月）收集了 3,100+ 條 trajectory，橫跨 Web、OS、Embodied、Database 四個領域，測試 GPT-5 系列與 Claude-4-Sonnet，然後人工＋LLM-judge 標註每一條是怎麼死的。

七類失敗，分成兩個層級：

層級	佔比	包含
過程層風險	72.5%	環境錯誤、指令錯誤、規劃錯誤、歷史錯誤累積
設計層風險	27.5%	災難性遺忘、錯誤假設、記憶限制

三個關鍵發現：

第一，崩塌是非線性的。 成功率不是隨組合深度平滑下滑，而是在小幅延長之後急速崩塌。這就是「斷崖」這個詞的實證依據——不是斜坡，是懸崖。這也解釋了為什麼調參很難救：你不是在對抗一個線性劣化，你是在找那個臨界點在哪。

第二，不同領域的斷點位置不同。 Web 最早崩塌，Embodied 衰減最陡。這意味著沒有一個放諸四海的「步數上限」，你得針對自己的領域測。

第三，也是最關鍵的：規劃類與記憶類失敗在長時程中佔主導。作者據此明確主張：單靠擴大基礎模型不足以改善。

把這條跟 Princeton 那句「能力提升只帶來很小的可靠性提升」放在一起，你會得到同一個結論的兩個獨立證明：這是系統設計問題，不是模型能力問題。

順帶一提：研究社群把力氣花在哪

The Horizon Gap（arXiv:2608.06663，2026 年 7 月）綜述了 1,547 篇 arXiv 論文（2024–2026），分類統計很說明問題：

類別	論文數
執行控制與回復	584（編排 338、回復 245）
記憶與上下文管理	397
規劃與拆解	182
長時程訓練	167
評估與量測	114
基礎、限制與安全	103

投入最多的不是「怎麼規劃得更好」（182 篇），而是「壞掉之後怎麼救回來」（回復 245 篇）。整個社群已經默認了「它一定會壞」這個前提。

而評估與量測只有 114 篇——最少人做的，恰好是我們最缺的那塊。 這也解釋了為什麼你很難拿到自己場景的可靠性數字：沒有人做工具給你。

六、第四幕：那為什麼你沒發現

到這裡有個很合理的反駁：如果長任務失敗率真的這麼高，我怎麼沒感覺？

因為失敗會偽裝成成功。

我上一篇文章寫過假報完成的四個斷點，那時的角度是「怎麼驗收」。這次要補上的是：假報完成不是隨機發生的，它跟時長高度相關，而且已經被量出來了。

arXiv:2606.09863（Advani，University of Colorado，2026 年 6 月）做了一件很聰明的事：他不去問 agent，而是拿 agent 的最終自述比對 tool-call 紀錄與 reward。只要 agent 說「我做了 X」而紀錄顯示 X 從未發生，就標記為假成功。

母體：tau2-bench 的 9,876 條 trajectory（8 個模型家族，含 Claude Opus/Sonnet 4.5、GPT-5.2、Gemini 3 Pro/Flash、GLM-5、Qwen 系列）＋ AppWorld 的 1,879 條 trajectory（4 個模型家族，用程式化單元測試提供與文字無關的 ground truth）。

假成功佔所有失敗的比例：

環境	比例
tau2-bench 整體（1,730 次失敗中）	36%
├ 航空領域	45%
├ 零售領域	47%
└ 電信領域	3%
AppWorld（自我評估架構）	75.8%
跨模型變異（tau2-bench）	13% – 79%

標註信度很紮實：regex 標籤與人工標註一致率 91.5%，κ = 0.86。

但真正有價值的不是 36% 或 75.8%，是電信領域那個 3%。

同一批模型、同一個 benchmark，只是換一個領域，假成功率從 47% 掉到 3%。這代表假成功不是模型的固有屬性，而是環境給不給得出獨立驗證訊號的函數。

換句話說：agent 不是天生愛騙人，是你沒給它一面鏡子。

這條線索直接給出解法，我們留到決策框架講。

把兩幕串起來

現在可以把因果鏈接起來了：

長時程任務缺少中途的獨立驗證訊號 → agent 只能自評 → 自評會漂移 → 失敗被記成成功 → 你的體感比實際好。

斷崖之所以是斷崖，一部分原因是你站在崖上，但儀表板顯示平地。

補一個佐證：DeployBench（arXiv:2606.05238）觀察 agent 自行判定停止的 97 個案例，其中 87 個自報結果與驗證器不符——55 次自報 SUCCESS 但驗證失敗，32 次自報 PARTIAL 但仍然失敗。作者稱之為 self-validation drift：agent 驗證了錯的目標，或跑了比驗證器更寬鬆的檢查。

七、第五幕：業界早就知道了，只是沒發論文

前面四幕都是研究。現在講現場。

Measuring Agents in Production（Pan 等人，arXiv:2512.04123，ICLR 2026 收錄）是目前規模最大的生產環境 agent 系統性研究。作者群橫跨 UC Berkeley、Stanford、IBM Research、UIUC，掛名者包括 Ion Stoica、Matei Zaharia、Dawn Song、Joseph Gonzalez——這個名單本身就是品質背書。

方法：306 位實務者問卷＋ 20 個深度訪談案例，涵蓋 26 個應用領域。

他們實際怎麼蓋 agent

發現	數值
在需要人介入前，最多執行 10 步	68%
最多執行 5 步	46.7%
使用預先定義的靜態 workflow，而非自主規劃	80%
自建實作，而非採用 agent framework	85%
使用 LangChain 等 framework	15%
直接用現成模型，不調權重	70%
手工撰寫 prompt	79%
20 個受訪團隊中使用 RL 的	1 個

他們實際怎麼評估

發現	數值
主要依賴人在迴圈中評估	74%
不使用任何正式 benchmark	75%
使用公開 benchmark	<10%
使用 LLM-as-judge（且一律搭配人工驗證）	52%

他們認為最大的問題是什麼

發現	數值
把可靠性列為首要技術重點	37.9%
把延遲列為關鍵阻礙	14.8%

這是整篇文章我覺得最有價值的一段。

你看到的是什麼？是一群沒讀過上面任何一篇論文的工程師，靠踩坑，收斂到了跟研究完全一致的結論——然後用架構把它擋掉了。

68% 限制在 10 步以內，不是因為他們不會做全自主 agent。是因為他們試過，然後把能力換成了可控性。80% 用靜態 workflow 取代自主規劃，剛好消掉 HORIZON 指認的主導失敗類型之一。<10% 用公開 benchmark，因為 benchmark 量的是能力，而他們要的是可靠性。

學界在量天花板能推多高，業界在蓋防護欄該設多低。這兩件事都在進行，只是從來沒有人把它們放在同一張圖上。

我想特別對技術主管說一句：如果你正在被問「為什麼我們的 agent 不能全自動」，這份 306 人的資料就是你的答案。限制步數不是保守，是目前有證據支持的主流工程實踐。

八、決策框架：你的 agent 該在第幾步交還控制權

以上都是研究。以下是我根據這些研究整理的判斷框架——這一節是我的綜合推論，不是任何一篇論文的直接結論，請帶著這個前提使用。

四個問題，依序問

問題 1：你的任務有沒有程式化的成功判準？

這是最關鍵的分岔，因為電信領域 3% vs 零售 47% 那組對照告訴我們，這個變因的影響大過模型選擇。

有（能跑測試、能比對 API 回傳、能做 schema 驗證）→ 可以放長，但每個階段都必須用驗證器判定，不能用 agent 自述判定。
沒有（產出是文件、設計、判斷）→ 對齊業界中位數，5–10 步就交還。你沒有鏡子，就別讓它獨自走太遠。

問題 2：你的領域在 GDS 表上落在哪一列？

接近軟體工程（0.90→0.44）→ 假設一定會斷崖，預先把任務切成多個可獨立驗收的段落。
接近文件處理（0.74→0.71）→ 可以容忍較長時程，衰減溫和。
不確定 → 用軟體工程那一列的假設，這是保守方向。

問題 3：你用的是前沿模型還是中階模型？

前沿模型的 meltdown 率反而更高（19% vs ≤4%）→ 不要因為升級了模型就放寬步數上限。 這是最反直覺、也最容易踩的一個坑。
如果你一定要放長，那就把 meltdown 偵測做進去：監控 tool-call 的重複率與熵，異常就中斷。

問題 4：你怎麼知道它成功了？

如果答案是「它說它成功了」→ 根據 36%–75.8% 的假成功數據，你的失敗率被系統性低估。你現在量的是「它宣稱的成功率」。
修法：把驗收條件寫成可執行的檢查，而不是自然語言的描述。差別在於「確認導覽正常運作」vs「pnpm test:e2e -- nav.spec.ts 回傳 0」。

三個場景

場景 A：內部 CI 的自動修 flaky test

環境：有完整 test suite，成功判準百分之百程式化
領域：軟體工程（衰減最劇）
建議：可放到 20–30 步，但每 5 步強制跑一次完整 test suite，且 agent 無權修改測試檔（用 hook 擋）。有鏡子的情況下，時長可以買。

場景 B：客服 agent 處理退換貨

環境：有 API 回傳可驗證，但流程分支多
領域：接近 tau2-bench 的零售（假成功率 47%）
建議：靜態 workflow ＋每個外部動作後強制對帳，5 步內交還。這正是那 80% 生產團隊在做的事。

場景 C：讓 agent 讀 20 份文件寫調研報告

環境：沒有程式化判準
領域：接近文件處理（衰減最溫和）
建議：這是少數可以放長的場景，因為 GDS 幾乎不衰減。但要接受「產出品質靠人審」，別假裝它可以自動驗收。

九、實戰最佳實踐：常見錯誤 → 正確做法

常見說法	為什麼錯	正確版本
「時間跨度 7 個月倍增，再過兩年就能自主跑一週」	忽略 METR 自陳：>16 小時量測不可靠、31 個長任務只有 5 個有真人基線、CI 寬達 4.3 倍	倍增趨勢是關於50% 成功率的中位數任務；生產環境需要的是 99%，不是同一條曲線
「換更強的模型就會更穩」	Princeton：能力提升只帶來很小的可靠性提升。Beyond pass@1：前沿模型 meltdown 率反而更高	可靠性要用系統設計買，不是用模型升級買
「benchmark 分數高就能上生產」	75% 的生產團隊根本不用正式 benchmark，<10% 用公開 benchmark	Benchmark 量能力，生產要可靠性，測的不是同一件事
「業界限制步數是因為技術落後」	MAP 的訪談顯示這是刻意的權衡	那是把能力換可控性的成熟工程判斷
「我的 agent 成功率很高」	36%–75.8% 的失敗會偽裝成成功	沒有獨立驗證器，你量的是它宣稱的成功率
「任務失敗是我 prompt 沒寫好」	HORIZON：72.5% 是過程層失敗，且規劃與記憶類佔主導	有一部分是，但更多是你讓它跑太久了

三個今天就能做的動作

在你的 agent 迴圈裡加步數計數器，並印出來。 你會驚訝於自己從來不知道它實際跑了幾步。先量，再談優化。
把最終驗收從自然語言改成可執行指令。 不要接受「已完成並確認正常」這種句子作為結案條件。
另開一個乾淨環境跑獨立驗證。 這是我養成的習慣，也是被 36% 假成功率背書的做法。

十、效能調優：怎麼在不犧牲太多能力的前提下守住可靠性

如果你的產品確實需要長時程，這裡有三個方向，按投入報酬率排序：

1. 分段驗收（最高 CP 值）
把一個 30 步任務切成 5 個 6 步任務，每段結束跑驗證器。這等於把你從 GDS 曲線的極長桶（0.44）搬回短桶（0.90）。這是唯一一個不用寫複雜程式碼就能拿到大部分收益的做法。

2. Meltdown 偵測
監控最近 N 步的 tool-call 分布。如果重複率飆升或出現同一組動作的循環，立刻中斷並回報，不要讓它繼續燒 token。Beyond pass@1 用的是熵閾值，你可以先從最簡單的「連續 3 次相同 tool call 就中斷」開始。

3. 回復導向設計
在每個階段結束時存 checkpoint（含 git commit 或狀態快照），失敗時回滾到上一個已驗證的點，而不是從頭重來。研究社群在這個方向投入了 245 篇論文，說明它既重要也還沒有標準答案——但基本的 checkpoint / rollback 你今天就能自己做。

十一、工具與資源

METR Time Horizons — 持續更新的時間跨度量測，含互動圖表與原始資料。看能力趨勢就看這個，但記得讀 FAQ 裡的限制。
Princeton HAL Reliability Dashboard — 對應 arXiv:2602.16666 的互動儀表板，可查 15 個模型的四維可靠性剖面。
tau2-bench — 假成功研究的母體來源之一，客服場景的 agent 評測。
AppWorld — 用程式化單元測試提供 ground truth，是少數不依賴 agent 自述的評測環境。
The Horizon Gap 論文 — 1,547 篇論文的分類綜述，找長時程相關研究的最佳入口。

十二、總結與展望

一表看完

證據	母體	說了什麼	證據等級
METR Time Horizon	228 任務	能力每 ~7 個月倍增；但 >4h 任務成功率 <10%	機構自行量測
Beyond pass@1	23,392 episodes	軟體工程 GDS 0.90→0.44；前沿模型 meltdown 19%	預印本實測
HORIZON	3,100+ trajectories	72.5% 過程層失敗；非線性崩塌；擴大模型救不了	預印本實測
Agent Reliability	15 模型 × 2 benchmark	能力提升只帶來很小的可靠性提升	ICML 2026
False Success	11,755 trajectories	36%–75.8% 的失敗偽裝成成功	預印本實測
Measuring Agents in Production	306 實務者	68% ≤10 步；80% 靜態 workflow；75% 不用 benchmark	ICLR 2026

給不同讀者的建議

如果你是個人開發者：把「跑一次獨立驗證」變成習慣，比換任何工具的效益都大。
如果你在做 agent 產品：先量你的步數分布和真實成功率（用驗證器，不是自述），再決定要不要放長。多數人會發現自己的真實成功率比想像低一截。
如果你是技術主管：MAP 那份 306 人的資料是你目前能拿到最好的「為什麼我們不做全自主 agent」的論據。

三個值得追的方向

前沿閉源模型的可靠性公開量測。目前最細的衰減曲線只測了開源模型，這是最大的資料缺口。
可靠性評測工具化。1,547 篇論文裡評估只佔 114 篇，這個缺口遲早有人補，補上的人會很有價值。
回復導向的 agent 架構。245 篇論文在做這件事，但還沒有像 ReAct 那樣被廣泛採用的標準模式。

金句

「能力和可靠性是兩條不同斜率的線，而你的產品需要的是後面那條。」

「更強的模型不是更穩，是失敗得更壯烈。」

「Agent 不是天生愛騙人，是你沒給它一面鏡子。」

「學界在量天花板能推多高，業界在蓋防護欄該設多低。」

延伸思考

你現在的 agent，實際上平均跑幾步才交還控制權？你量過嗎，還是只是有個印象？
如果你要向老闆證明「我們的 agent 成功率是 X%」，你手上有沒有一個不依賴 agent 自述的量測方式？如果沒有，那個 X 是誰算出來的？
上一次你覺得「agent 表現變好了」，是因為模型升級、prompt 改了，還是那陣子的任務剛好比較短？你怎麼區分這三件事？

FAQ

Q1：這是不是在說 agent 沒用？
完全不是。同一批數據顯示短任務的 GDS 高達 0.90，coding agent 在短任務上表現是所有領域最好的。結論是「把長任務切成短任務」，不是「別用 agent」。

Q2：那 METR 的研究是不是不可信？
可信，而且方法透明度在同類研究裡數一數二。問題出在引用者只取了對自己論點有利的那一半。METR 自己把限制寫得清清楚楚。

Q3：0.90→0.44 這條曲線適用於 Claude Code / Codex 嗎？
不能直接套用——那份研究明確說只測開源模型。它證明的是「時長→衰減」這個機制普遍存在，以及軟體工程領域衰減最劇烈的領域效應。前沿閉源模型的絕對數值目前沒有等價的公開量測。

Q4：為什麼更強的模型崩壞率反而更高？
因為強模型會嘗試更有企圖心的策略。策略一歪，它會不斷生成新策略去救，行為熵飆升。弱模型只會重複同一套動作，穩定地失敗。

Q5：10 步這個數字是硬規定嗎？
不是。68% 的生產團隊落在「10 步以內」，46.7% 落在 5 步以內，但這是跨 26 個領域的分布，不是規範。用第八節的四個問題判斷你自己的數字。

Q6：如果我的任務就是需要 50 步呢？
那就切成 10 個 5 步的段落，每段用驗證器結案。分段驗收是本文投報率最高的建議。

Q7：LLM-as-judge 可以當驗證器嗎？
可以當輔助，不能當唯一。MAP 的資料顯示 52% 的團隊用 LLM-as-judge，但一律搭配人工驗證——注意「一律」這個詞。而且假成功研究已經證明自我評估架構的失真最嚴重（75.8%）。

Q8：假成功偵測器可以直接拿來用嗎？
目前不建議當唯一防線。原論文自陳偵測器在 10% 標記率下精確率只有 50%，跨領域遷移的 AUROC 僅 0.69，還有 20–25% 的案例可以靠改寫收尾訊息繞過。真正有效的還是獨立的程式化驗證器。

Q9：多 agent 架構能解決這個問題嗎？
本文引用的研究都不涵蓋多 agent 場景（Beyond pass@1 明確排除）。Beyond the Leaderboard 把「多 agent 協調失敗」列為六大失敗叢集之一，所以不能預設多 agent 會改善可靠性。

Q10：這些研究會不會很快就過時？
The Horizon Gap 的統計顯示 58%–77% 的相關論文集中在 2026 年發表，這是個高速變動的領域。但「能力 ≠ 可靠性」這個結構性區分，以及「需要獨立驗證訊號」這個機制，不太可能因為模型換代而失效。

參考資料

論文

Pan, M. Z. et al. Measuring Agents in Production. arXiv:2512.04123（ICLR 2026）— https://arxiv.org/abs/2512.04123
Rabanser, S. et al. Towards a Science of AI Agent Reliability. arXiv:2602.16666（ICML 2026）— https://arxiv.org/abs/2602.16666
Khanal, A., Tao, Y., Zhou, J. Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents. arXiv:2603.29231 — https://arxiv.org/html/2603.29231v1
Wang, X. J. et al. The Long-Horizon Task Mirage? Diagnosing Where and Why Agentic Systems Break. arXiv:2604.11978 — https://arxiv.org/html/2604.11978v1
Advani, L. From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents. arXiv:2606.09863 — https://arxiv.org/html/2606.09863
DeployBench: Benchmarking LLM Agents for Research Artifact Deployment. arXiv:2606.05238 — https://arxiv.org/pdf/2606.05238
Albayaydh, W., Zhao, R., Flechais, I. Beyond the Leaderboard. arXiv:2607.05775 — https://arxiv.org/abs/2607.05775
Chen, M., Wang, L., Qu, B. The Horizon Gap. arXiv:2608.06663 — https://arxiv.org/html/2608.06663