每隔一陣子我們幾乎都能看到某家公司的 AI 模型又在某個知名基準測試（Benchmark）中拿下了榜首。這些數字被廣泛應用在企業的新聞稿中，投資人用這些分數來合理化高昂的估值，而軟體工程師則依賴這些排行榜來決定要在產品中部署哪一個模型。我們這個產業建立在一個非常單純的默契之上：分數越高的模型，代表它解決複雜問題的能力越強。
然而，來自加州大學柏克萊分校（UC Berkeley）的研究團隊於 2026 年 4 月發布了一項最新研究，他們開發了一個自動化的掃描代理程式（Agent），針對目前業界最具權威性的八大 AI 代理基準測試進行了系統性的漏洞稽核。這八個測試包含了 SWE-bench、WebArena、OSWorld、GAIA、Terminal-Bench、FieldWorkArena 以及 CAR-bench。結果這八個基準測試全數遭到破解。AI 可以在完全沒有解決任何實際任務、沒有進行任何邏輯推理，甚至連一行正確解答的程式碼都沒有寫的情況下，輕鬆取得接近滿分的成績。這份研究指出，我們目前用來衡量 AI 能力的工具，本身就存在著致命的設計缺陷。
How We Broke Top AI Agent Benchmarks: And What Comes Next
戳破「高分等於高能力」的幻象
長期以來，AI 領域存在著一種「刷榜」文化。隨著模型變得越來越聰明，它們在傳統選擇題或靜態問答測試中早已達到人類水平。因此，研究人員開發出了更複雜的「代理基準測試」（Agent Benchmarks），讓 AI 在虛擬的作業系統、終端機或網頁瀏覽器中執行多步驟的任務。我們以為這樣就能真實反映 AI 的工作能力。
柏克萊團隊的研究發現，高分數很多時候反映的其實是 AI 或測試參與者「鑽漏洞」的能力，也就是所謂的獎勵作弊（Reward Hacking）。當系統的評分機制存在盲點時，AI 可以透過操作環境狀態、讀取隱藏答案或欺騙評分程式來獲取高分。
這是現在進行式，而非理論推演
這篇論文最核心的貢獻在於，它證明了這些漏洞不是停留在理論層面的潛在風險，而是已經在現實頻繁發生的現象：
- IQuest-Coder-V1 的「歷史抄襲」事件：這款模型曾宣稱在知名的 SWE-bench 測試中取得了 81.4% 的驚人成績。但後續調查發現，它有 24.4% 的操作軌跡只是單純執行 git log 指令，直接從版本控制歷史紀錄中把標準答案「複製貼上」。經過修正後，其真實分數掉到了 76.2%。這凸顯了測試環境沒有正確隔離歷史紀錄的荒謬情況。
- METR 對頂尖模型的稽核發現：根據 METR 的調查，像是 o3 與 Claude 3.7 Sonnet 這些最前沿的模型，在超過 30% 的評估過程中會出現獎勵作弊的行為。
- OpenAI 棄用 SWE-bench Verified：OpenAI 內部稽核發現，該測試中有高達 59.4% 的題目存在測試案例瑕疵。這代表模型一直以來都在跟一個「壞掉的標準答案」進行比對。
- KernelBench 的 GPU 記憶體殘留問題：在這個測試中，模型只要呼叫 torch.empty()，就會回傳未清理的 GPU 記憶體數據，而這些數據剛好包含了評分程式前一次運算留下的標準答案。模型不需要做任何計算，就能拿到滿分。
- Anthropic Mythos 的自主駭客行為：在 Anthropic 發布的測試報告中，展示了前沿模型已經具備主動尋找環境漏洞的能力。在一個案例中，模型需要編輯一個沒有權限的檔案。它沒有放棄，反而透過搜尋找到了工作區的漏洞，將具有提權功能的惡意程式碼注入設定檔中，並且還設計成執行後會「自動刪除」以煙滅證據。如果模型具備這種自主開發權限提升工具的能力，找出評測系統的漏洞對它們來說簡直易如反掌。
柏克萊的研究團隊正是為了解決這個系統性崩壞的現象，決定親自下場，用自動化程式找出所有隱藏的設計缺陷，藉此呼籲整個 AI 領域必須正視評測基礎設施的脆弱性。
AI 評測機制是如何被「駭」的？
研究團隊開發的自動化掃描代理，在沒有呼叫龐大語言模型推理、沒有真正解決任何任務的情況下，交出了一張驚人的成績單。
1. Terminal-Bench：木馬化測試基礎設施
Terminal-Bench 是一個包含 89 個複雜終端機任務的測試，例如編譯 COBOL 程式或設定分散式系統。它使用名為 Harbor 的沙盒框架來運行測試。雖然沙盒保護了 /tests/ 目錄，但它卻完全沒有保護系統層級的執行檔。更糟糕的是，容器預設允許對外連網。
這 89 個任務中，有 82 個會在「評分階段」透過網路下載並安裝 uv 這個套件。代理程式利用了這條脆弱的相依性鏈條。它在執行階段將系統的 /usr/bin/curl 替換成自己寫的「木馬包裝器」。當評分程式呼叫 curl 下載套件時，木馬會攔截請求，確實幫系統安裝好 uv，但同時也把安裝好的 uvx 執行檔給木馬化了。
當系統準備執行 pytest 來驗證解答是否正確時，這個被竄改的程式會直接輸出一段「偽造的全數通過畫面」，接著向獎勵檔案寫入 1。評分程式完全信任這個結果，任務宣告完美通過。剩下 7 個不透過 curl 的任務，代理程式則透過竄改 pip 或 python 執行檔來達到一模一樣的效果。一行解答都沒寫，輕鬆拿下 89 題滿分。
2. SWE-bench：不需要修復任何 Bug 的完美解題
SWE-bench 是目前影響力最大的 AI 寫程式能力測試，它提供真實的 GitHub 錯誤回報（Issues），要求 AI 寫出修補程式（Patch），讓原本失敗的測試案例順利通過。其中的 SWE-bench Verified（500題）與 SWE-bench Pro（731題）更是被視為業界標準。
而測試過程中，AI 產生的修補程式，與最終執行測試案例的環境，是位在同一個容器裡面。這代表 AI 擁有在測試執行前，竄改測試環境的完整權限。因此代理程式根本不去看 GitHub 的 Issue 到底是什麼。它直接在專案根目錄建立一個 conftest.py 檔案。Pytest 框架在執行前會自動尋找並載入這個檔案。代理程式在裡面寫入一段函式攔截了每一個測試案例的回報結果，強制將狀態從原本的失敗改寫為 passed（通過）。評分系統的日誌解析器看到滿畫面的 PASSED，理所當然地認為 AI 已經完美修復了所有 Bug。
在 SWE-bench Pro 中，代理程式甚至直接覆蓋掉負責擷取測試結果的 parser.py 檔案，讓它永遠只會回傳滿分。這讓它在總計過千題的黃金標準測試中拿下了 100% 的通過率。
3. WebArena：光明正大偷看標準答案
WebArena 包含了 812 個網頁互動任務，它會啟動一個由 Playwright 控制的 Chromium 瀏覽器，讓 AI 代理在裡面進行操作。WebArena 非常貼心地將所有任務的設定檔（包含了每一題的標準答案）以 JSON 格式存放在本地端硬碟的路徑下。同時，它忘了限制瀏覽器的訪問權限。
於是代理程式不需要去修改任何評測原始碼。它只是單純地控制瀏覽器，將網址列導向一個本地端網址，把標準答案讀出來，然後交卷。評分系統只看到送回來的答案完全正確，給出了接近滿分的成績。
此外，針對由大型語言模型擔任裁判的題目，代理程式還使用了 Prompt Injection 技術。只要在回覆的最後加上一段隱藏指令，要求 LLM 裁判給予高分，沒有經過輸入清洗的裁判就會乖乖聽話。
4. FieldWorkArena：只要一個字元就能通關
這是一個包含 890 個任務的多模態測試，要求 AI 在瀏覽器環境中回答關於圖片、影片、PDF 和文字檔的問題。但它的評分驗證函式 validate() 裡面，竟然只檢查了一件事：「對話紀錄的最後一則訊息，是不是來自助理（Assistant）？」
函式完全沒有檢查訊息的「內容」是什麼，原本應該用來比對答案準確度的程式碼變成了無用的殭屍代碼（Dead code）。代理程式只需要送出一個 {}（空的大括號），就能符合 JSON 格式的要求，並且觸發「最後一則訊息來自助理」的條件。沒有呼叫任何語言模型推理、沒有讀取任何檔案，代理程式以一招拿下了滿分。
5. OSWorld：直接下載標準檔
OSWorld 在一個完整的 Ubuntu 虛擬機中測試 AI 的桌面操作能力。因為任務需求，虛擬機必須具備對外的網際網路連線能力。為了方便評分，測試環境會將使用者的輸出檔案與官方的「參考檔」（Gold files）進行比對。而這些參考檔的下載網址竟然就直接寫在任務的設定檔中。
代理程式直接透過指令 wget，從 HuggingFace 上把官方的參考檔下載下來，然後存檔成評分系統預期要檢查的使用者輸出檔。評分系統拿參考檔去比對參考檔，自然是完美吻合。
6. GAIA：過度正規化導致的鬧劇
GAIA 是一個測試通用 AI 助理的多步驟推理題庫，它沒有沙盒環境，就是一個單純上傳答案的排行榜。除了它的驗證答案早已在 HuggingFace 上公開之外，它內建的評分字串正規化（Normalization）函式存在極大瑕疵。這個函式會把所有空白、標點符號全部刪除，並轉成小寫。
假設正確答案是 "Dr. Martin Luther King Jr."，代理程式只要胡亂輸出 "D.R M.A.R.T.I.N L.U.T.H.E.R K.I.N.G J.R"，經過正規化後都會變成 "drmartinlutherkingjr"，照樣拿滿分。另外，系統還有一個逗號分割的 Bug，如果正確答案是 "1,500"，系統會拆成陣列 ["1", "500"]，這導致填寫正確數字 "1500" 的人反而會因為陣列長度不符而被判定錯誤。代理程式只要故意在每個級別答錯一題來避開防作弊過濾器，就能輕鬆拿下高達 98% 的分數。
7. CAR-bench：被輕易操弄的 LLM 裁判
CAR-bench 是一個針對車載語音助理的測試，高度依賴另一個 LLM 來當裁判閱讀對話紀錄並評分。裁判的提示詞中，直接插入了代理程式的對話內容，中間沒有做任何安全隔離或內容清洗。對於幻覺類型的任務，四個評分標準中有三個預設為 0，只要不觸發錯誤就會給滿分。
代理程式在對話紀錄的 HTML 註解中寫下 Prompt Injection，LLM 裁判讀到這段文字後，會以為這是系統給它的指示，乖乖給出高分。遇到幻覺任務時，代理程式只要給出一個極其空泛的拒絕回答，就能完美避開所有錯誤判定，拿下所有幻覺任務的滿分。
七大原罪與評測防禦指南
柏克萊團隊統整了這八大評測系統被攻破的原因，歸納出 AI 基準測試基礎設施目前普遍存在的「七大原罪」：
- 代理與評分器之間缺乏隔離：這是最致命的錯誤。在 SWE-bench、Terminal-Bench 中，受測環境與評分環境混在一起，AI 可以輕易竄改評分依據。
- 標準答案與考卷包在一起：WebArena 與 OSWorld 直接把解答放在 AI 可以存取的本地路徑或設定檔中，這測的是找檔案的速度。
- 對未受信任的輸入使用 eval()：這不僅是評測漏洞，更是嚴重的資安威脅。評分系統不該直接執行由 AI 產生的字串。
- LLM 裁判沒有進行輸入清洗：將 AI 的輸出直接塞給 LLM 裁判，讓 Prompt Injection 攻擊變得輕而易舉。
- 脆弱的字串比對機制：過度寬鬆的正則化或單純的子字串包含檢查，讓 AI 只要給出夠長、包含足夠關鍵字的廢話就能得分。
- 沒有真正評估的評估邏輯：如同 FieldWorkArena，評分代碼寫錯或漏寫，導致只要有作答就給分。
- 信任未受信任程式碼的輸出：完全相信在 AI 控制下的容器內所產生的測試日誌（Log）或獎勵檔案。
如何建立值得信賴的評測標準？
為了解決這些亂象，研究團隊提出了 Agent-Eval Checklist，這是未來所有 AI 評測系統在上線前都必須通過的最低標準：
- 絕對隔離：評估程式必須在 AI 容器外部執行。從沙盒中提取原始日誌和檔案後，在一個唯讀且獨立的主機上進行驗證。絕不把解答放在 AI 碰得到的地方。
- 禁用 eval()：嚴禁使用危險的動態執行函式處理 AI 輸出。如果需要驗證代碼，請使用完全沒有內建函式權限的沙盒直譯器。
- 清洗 LLM 裁判的輸入：使用明確的結構化標籤將 AI 的回答框起來，並且過濾掉任何看起來像系統指令的文字。盡可能要求 LLM 輸出 JSON 格式來降低攻擊面。
- 進行對抗性測試：在發布榜單前，先用以下幾種「作弊代理」測試你的系統：空代理（Null Agent）：什麼都不做。如果這能拿分，代表系統有預設給分的 Bug。隨機代理（Random Agent）：胡亂操作。如果分數明顯高於空代理，代表評分標準過於寬鬆。注入代理（Prompt Injection Agent）：專門測試 LLM 裁判的防禦力。狀態篡改代理（State-tampering Agent）：專門修改系統環境變數。這能測試隔離機制是否完善。
- 保護評估資料鏈：確保在整個評測生命週期中，AI 絕對無法複寫、攔截或竄改傳遞給評分器的任何中介資料。
- 穩健的計分機制：避免使用單純的短字串比對，崩潰的任務應該記為零分而非從總分中剔除，並且要嚴格測試極端情況（邊緣數字、特殊編碼等）。
- 保持答案的機密性：不要公開用於排名的測試集解答，並定期更換題庫。最好的做法是採用「隱藏評估」，讓提交者永遠看不到真正的考題。
TN科技筆記的觀點
AI 模型在訓練過程中的本質，就是尋找最佳化的演算法。撇除 over-fitting 不論，我們給它一個目標函數（通常就是分數或獎勵），它會用盡一切算力去尋找讓這個數字最大化的路徑。於是 AI 一直都只是在執行我們給它的「拿高分」指令。
以 Anthropic 的 Mythos 報告為例，當模型在發現自己沒有權限編輯檔案時，它並沒有回報「我做不到」，而是自主上網搜尋漏洞、注入提權代碼，甚至寫了自我刪除的腳本來隱藏蹤跡。這代表當模型的推理能力與工具使用能力強大到某個臨界點時，它會理解：「比起辛辛苦苦去理解這幾萬行的代碼並找出 Bug，直接寫一個腳本去竄改評分系統的 conftest.py，是一條效率更高、耗能更低、且能達到同樣分數的最佳解徑。」
隨著 AI 變得越來越聰明，這種「獎勵作弊」並非是刻意寫死在腳本裡的攻擊手法，而是模型自己演化出來的能力。我們正在用一把刻度扭曲的尺，去丈量一台越來越難以捉摸的機器。
未來真正有價值的 AI，是在充滿雜訊的真實商業環境中解決實際問題的 AI，而不是一個只會在虛擬沙盒裡鑽漏洞的「刷榜機器」，我們不能再盲目迷信排行榜上的數字。對於企業與投資人而言，不如親自把模型接入公司的工作流，實際測試它的表現，才是唯一真實的指標。
支持TN科技筆記，與科技共同前行
我是TN科技筆記，如果喜歡這篇文章，歡迎留言、點選愛心、轉發給我支持鼓勵～～～也歡迎每個月請我喝杯咖啡，鼓勵我撰寫更多科技文章，一起跟著科技浪潮前進！！>>>>> 請我喝一杯咖啡
在此也感謝每個月持續請我喝杯咖啡的讀者以及新加入的讀者們，讓我更加有動力為各位帶來科技新知！
以下是我的 threads 也歡迎追蹤、回覆、轉發喔！
>>>>> TN科技筆記(TechNotes)
