Benchmark 幻覺:榜單高分的 AI Agent,到你的真實業務裡為何只剩 3–4 成成功率
公開榜單上,頂級 AI Agent 的分數一個比一個亮眼;可一旦接入你自己的私有系統,成功率往往驟降到三四成。本文用三組本週一手基準資料——真實私有企業程式碼庫的 38.8% pass@1、77.4% 到 53.0% 的一致性缺口、長任務 73.4% 的失敗率——拆解"演示很驚豔、上線就翻車"的三層差距,並說明為什麼補上私有語境(而非追逐更高榜單分)才是企業落地的真正槓桿。
TL;DR: 最強的前沿 AI Agent,在真實私有企業程式碼庫上的單次通過率(pass@1)也只有約 38.8%——換句話說,同一個在公開榜單上名列前茅的 Agent,一旦接入你自己的系統、資料與業務規則,十件事裡往往做砸六件。差距主要來自三層:缺私有語境(它不懂你的內部系統與業務約定)、一致性不足(同一任務重複跑不一定次次成功)、以及長任務失控(步驟一多、鏈條一長就崩)。公開榜單分數衡量的是通用能力,不等於你的業務分數;真正決定落地效果的,是有沒有把私有語境補進去。本文用三組本週一手基準資料把這三層差距量化,並給出企業該怎麼補的答案。
這是《為什麼企業 AI Agent 會在生產環境翻車》的資料版姊妹篇:那篇講"為什麼會翻車",本文用基準數字回答"翻車到什麼程度、差距具體在哪、怎麼補"。
一、公開榜單分數,能代表你的業務成功率嗎?
不能——而且差距比多數人想像的大。
問題的關鍵在於基準題目取自哪裡。多數廣為人知的高分,來自公開的開源倉庫任務;而 Real-SWE Benchmark(Specific Labs) 換了個更接近現實的口徑:題目全部來自向真實公司授權的私有生產程式碼庫,涉及計費、報稅、客戶遷移這類"改錯一步就有業務後果"的改動。在這個更真實的口徑下,榜首的 Claude Code 也只拿到 38.8% 的 pass@1(每個任務獨立跑 8 次取平均),其後依次是 GPT-6 Astra 33.8%、Gemini CLI 31.2%、GLM 5.3 + Claude Code 28.8%、Kimi K3 18.8%。
也就是說,即便是當下最強的前沿 Agent,面對真實私有企業程式碼,也只能解決不到四成的任務。榜單敘事裡的"接近可用"和你實際部署後看到的成功率,根本不是同一個數字。
| 維度 | 公開榜單給你的印象 | 你的真實私有企業場景 |
|---|---|---|
| 任務來源 | 公開開源 issue(語境自洽、邊界清晰) | 授權私有生產程式碼庫(計費/報稅/客戶遷移,有業務後果) |
| 最強 Agent 成功率 | "已接近可用"的高分敘事 | pass@1 約 38.8%(Real-SWE 榜首) |
| 失敗集中區 | 短平快的 demo 型任務 | 長任務(跨系統、多步、長鏈條) |
| 評估口徑 | 單次 / 首過即算成功 | 每任務 8 次取平均,還要看一致性 |
這張表是本文的主線:接下來三個問題,分別對應表裡"評估口徑"和"失敗集中區"兩欄背後的真實機制。
二、為什麼演示時很驚豔,真跑起來只有一半靠譜?
因為"能做成一次"和"每次都能做成"是兩回事——中間隔著一道一致性缺口。
IBM Research 在 Hugging Face 上的一篇文章 《Your Agent Aced the Task. Will It Do It Again?》 把這個問題量化得很清楚:一個基於 GPT-4.1 的 ReAct agent 在 AppWorld 基準上平均成功率 77.4%,聽起來相當能打;但如果要求"同一任務連續跑 5 次全部成功",達標率驟降到 53.0%——兩者之間是 24.4 個百分點的一致性缺口(consistency gap),在難任務上這道缺口甚至擴大到 30 個百分點。而"多數基準只報第一個數字",於是演示時你看到的是 77.4% 的那一面,上線後遇到的是 53.0% 的那一面。
這解釋了"演示驚豔、真用就不行"的體感:演示是精心挑過的一次成功,生產是同一動作反覆執行。IBM 的文章直言不諱——"對一筆金融交易做對賬、或檢查一份合同裡的義務條款……(偶爾錯一次)就可能是壓垮生產的那根稻草。"在有業務後果的場景裡,五次裡錯一次,就是一次真實的生產事故。
三、長任務是主要失敗區嗎?
是。任務越長,Agent 越容易在中途失控。
同一份 Real-SWE 資料從時長維度給出了很直接的訊號:10 分鐘以內就能完成的短 rollout,失敗率明顯偏低;而更長的 rollout,失敗率高達 73.4%。長任務,是失敗最集中的區域。
這一點對企業尤其關鍵,因為真實業務裡"有價值的活"幾乎都是長任務:一次客戶資料遷移、一條跨多個內部系統的對賬鏈路、一個牽涉若干審批環節的合規改動——都是多步、跨系統、長鏈條。演示裡那種"一句話、一步到位"的任務,恰恰是 Agent 表現最好、也最不像真實工作的那一類。你越是把它放到真實業務的長鏈條上,它離榜單分數就越遠。
四、上線之後,怎麼不燒錢地持續確認 Agent 沒退化?
不必每次改版都重跑全量測試——用自適應的抽樣評估,能以極小成本守住效果。
Agent 上線不是終點:模型在換、提示詞在改、依賴在升級,每一次變動都可能讓效果悄悄退化。但"每次都重跑全量基準"成本高到沒人願意做。arXiv 上的一項研究 《Efficient Benchmarking in Production: A Study of an Evolving LLM Agent》(2609.21267) 給出了更省的做法:研究物件是一個月活數萬的生產級分析型 agent,用它 574 次歷史執行按時間切分來做實驗。結論是,採用多維 2PL 自適應測試(IRT,一種按題目難度動態選題的評估方法)保真度最好——只跑 200 道題(全量的 38.5%),就能把評估誤差控制在 1.03 個百分點(MAE)。實際部署時他們進一步選了工程更簡單的"難度分層固定子集",不僅能零重標定遷移到另外 5 個 agent 家族,連校準視窗短到 1 天都依然穩定。
評估之外,如何定位問題也有更省的路徑。前面提到的 IBM Research 那套方法配了一個 Consistency Analyzer:只需一條已記錄的執行軌跡(trace)、無需人工標註答案,就能找出"離另一種行為只差一次取樣"的易翻車決策點,據此生成改進指引,把一致性缺口從 24.4pp 砍到 12.0pp(同任務 Pass⁵ 提升 16.0pp),而且平均準確率不下降。
把這兩件事合起來看:**持續複評不必昂貴,但必須持續。**低成本的抽樣評估負責"守住不退化",軌跡分析負責"定位在哪退化"——這套閉環,才是讓 Agent 在生產里長期可信的基礎設施。
五、那企業到底該怎麼補上這 60% 的差距?
答案不在"換一個榜單分更高的模型",而在"把它缺的私有語境補進去"。
回看前面三組資料:Real-SWE 之所以把成功率打到 38.8%,是因為題目來自 Agent 從未見過的私有生產程式碼庫;IBM 之所以強調金融對賬、合同審查錯一次即事故,是因為這些場景高度依賴你獨有的業務規則。這兩點指向同一個結論——榜單分數衡量的是通用能力,業務分數取決於私有語境:你的內部系統怎麼調、資料契約長什麼樣、業務規則的邊界在哪、哪些是不能碰的邊界案例。這些,恰恰是任何公開基準都不包含、也無法替你補上的東西。
而補上私有語境,正是 Forward Deployed Engineer(FDE,前置部署工程師) 的核心價值。FDE 不是把一個通用 Agent 交付給你就結束,而是駐進你的真實場景,把私有語境一層層注入模型能力:
- 需求語境化——把模糊的業務目標翻譯成 Agent 能執行的、帶邊界條件的任務;
- 建私有 eval 集——用你自己的真實任務(而非公開題目)建立評估基線,讓"業務分數"可被度量;
- 持續複評閉環——用上一節那套低成本抽樣評估 + 軌跡分析,守住效果不隨迭代退化。
這也是為什麼在 6AM TECH,我們把"落地效果"而不是"榜單排名"當作交付標準:公開分數是起點,私有語境才是護城河。如果你想知道自己的場景離"可用"還差多少,可以先做一次免費的 AI 落地診斷,我們會幫你評估現有差距在私有語境、一致性還是長任務上。想更系統地理解 Agent 為何在生產翻車,也可以讀姊妹篇《為什麼企業 AI Agent 會在生產環境翻車》。
資料來源:Real-SWE Benchmark / Specific Labs、IBM Research @ Hugging Face、arXiv 2609.21267。
