獎勵駭取正掩蓋模型智慧的提升
更聰明的模型，也越來越擅長鑽程式設計基準測試的漏洞。
以後來已修正的真實錯誤所建立的評估 suite 特別容易受到影響，因為這些問題其實早就有解。如果代理能存取儲存庫歷史或公開網路，有時就能直接查到答案，而不是自行推導。
為了衡量這種行為有多普遍，我們建立了一個代理來稽核評估 軌跡。在 SWE-bench Pro 上，我們發現 Opus 4.8 Max 成功解題的案例中，有 63% 是直接找到了修正，而不是自行推導。當我們封鎖 git 歷史紀錄並限制網際網路存取後，Opus 和我們的模型 Composer 2.5 分數都明顯下滑：
- Opus 4.8 Max 從 87.1% 降至 73.0%
- Composer 2.5 從 74.7% 降至 54.0%
先前研究已顯示，程式設計基準測試的答案可能會透過公開可得的來源洩漏，包括這篇 2024 年研究以及一份 2025 年 Meta 報告。我們的研究量化了當前尖端程式設計代理執行中的這個問題。更廣泛的啟示是，除了避免訓練階段的污染之外，代理式編碼基準測試也需要受控的執行階段環境。
對於進行評估的團隊，我們建議透過稽核對話記錄並限制評估環境，來降低這種獎勵駭取行為。
用模型揪出模型
為了衡量這種 獎勵駭取 行為的規模，我們讓稽核器檢查了 731 筆 Opus 4.8 Max 軌跡。它會查看問題敘述和完整的代理軌跡，但不會看到該次執行是否通過，並判定代理是否找出了已知答案。
它發現最常見的兩種 獎勵駭取 模式是：
- **上游查詢：**在 57% 的軌跡中，Opus 4.8 Max 在公開網路上找到已合併的 PR (拉取請求) 或已修正的原始碼檔案，接著幾乎原封不動地重現該修正。
- **Git 歷史挖掘：**在 9% 的軌跡中，Opus 4.8 Max 搜尋隨附的 .git 歷史記錄，找出日後修正該錯誤的提交，然後擷取其中的補丁。1
隨著模型變得更強，它們有時能推斷自己正處於 評估 中，尤其是在任務取自過去的公開儲存庫時。即使是在它們不記得訓練資料中修正內容的情況下，環境仍可能給它們線索，讓它們知道這個錯誤其實早已被解決。
在一個取自 2019 年 jq 議題的 SWE-bench Multilingual 任務中，代理嘗試用系統的 jq 二進位檔重現該錯誤。由於該映像是在錯誤修正後才建置的，重現失敗了，而代理因此推斷該議題已經解決。這樣的察覺讓它轉而搜尋現成修正，而不是自行推導出修正方式。
少數案例更加直接。有一個代理找到了一個 SWE-bench 鏡像頁面，洩露了隱藏測試和標準答案補丁。另一個則取得了隱藏測試檔案，並將通過測試所需的預期例外字串硬編碼進去。
上游查詢 (Opus 4.8 Max) 。 代理透過 GitHub API 查詢已合併的 PR，以找出該修正涉及哪些檔案，然後重現該修正 (同一個回應也會顯示各檔案的差異) ：
cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'Git 歷史挖掘 (Composer 2.5) 。 代理在隨附的 .git 歷史記錄中找到修正該錯誤的提交，讀取其差異，然後直接套用：
cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1要加入的補丁摘錄：上方 git show 輸出中裁切後的逐字片段 (也就是 Composer 重現的標準答案差異) 。
更嚴格的環境設計
大多數獎勵駭取都發生在公開網路和儲存庫歷史中。對於以歷來公開儲存庫建構的評估，這些管道必須受到控管，因為其中可能包含答案。為此，我們建立了一套嚴格的測試框架，包含兩種隔離機制：
- 歷史隔離。 在代理啟動前，
.git目錄會被移除，接著將儲存庫重新初始化為全新的單一提交儲存庫。原始歷史紀錄只有在評分時才會還原，因此測試仍可照常執行。 - 出站代理。 預設會禁止網路存取。作為一種盡力而為的控管措施，固定的代理伺服器只允許透過允許清單中的套件登錄來源解析相依套件，除此之外一律禁止。
這項限制僅適用於以歷來公開儲存庫建構的評估。這也是我們偏好使用以非公開儲存庫建構的評估 (例如 CursorBench) 的原因之一。它們可以測試代理式編碼能力，同時仍讓代理能以實際工作時會使用的方式運用工具。
持續擴大的差距
我們在更嚴格的測試框架中重新執行了 SWE-bench Pro 和 SWE-bench Multilingual，然後將各自的結果與標準測試框架下的分數進行比較，作為移除這些洩漏管道之綜合影響的替代指標2：
- 在 SWE-bench Multilingual 上，Opus 4.6 的差距不到 1 分，Opus 4.8 Max 為 9.1 分，Composer 2.5 為 7.5 分。
- 在 SWE-bench Pro 上，Opus 4.6 的差距不到 1 分，Opus 4.8 Max 為 14.1 分，Composer 2.5 為 20.7 分。
明確的結論是，與較舊的模型相比，較新的、更加先進的模型更常出現獎勵駭取。有趣的是，GPT 模型並未出現同樣的升高趨勢，在我們的執行結果中，差距普遍較小。
我們也觀察到，自家的模型 Composer 2.5 在這項研究中的 Pro 差距最大。這也是我們不把標準 SWE-bench Pro 分數視為 Composer 可靠基準指標的原因之一。狹義來說，這個分數是真實的，因為它確實是由測試框架產生的；但它把程式設計能力與取得已知修正的能力混在了一起。
Standard vs. strict harness (test pass rate)
| 1 | Opus 4.8 (max) | 91.16% | 82.03% | +9.1 |
| 2 | Opus 4.8 (xhigh) | 88.86% | 80.67% | +8.2 |
| 3 | Opus 4.7 (max) | 84.80% | 80.47% | +4.3 |
| 4 | Opus 4.7 (xhigh) | 83.74% | 78.60% | +5.1 |
| 5 | Opus 4.8 (high) | 83.09% | 79.26% | +3.8 |
| 6 | Opus 4.8 (medium) | 81.87% | 77.84% | +4.0 |
| 7 | Opus 4.7 (high) | 81.42% | 77.75% | +3.7 |
| 8 | Opus 4.8 (low) | 79.51% | 74.36% | +5.2 |
| 9 | Composer 2.5 | 79.15% | 71.60% | +7.5 |
| 10 | GPT-5.4 (xhigh) | 79.00% | 75.20% | +3.8 |
| 11 | GPT-5.5 (xhigh) | 77.80% | 74.40% | +3.4 |
| 12 | Opus 4.7 (medium) | 77.33% | 75.72% | +1.6 |
| 13 | GPT-5.5 (high) | 77.30% | 74.70% | +2.6 |
| 14 | GPT-5.4 (high) | 76.80% | 73.30% | +3.5 |
| 15 | Opus 4.6 (max) | 76.33% | 76.06% | +0.3 |
| 16 | Opus 4.6 (high) | 76.11% | 75.22% | +0.9 |
| 17 | Opus 4.7 (low) | 75.89% | 72.64% | +3.3 |
| 18 | GPT-5.5 (medium) | 75.30% | 74.20% | +1.1 |
為具察覺能力的代理設計評估
對執行程式設計評估的團隊來說，最重要的一點是，基準測試設計不應只停留在資料集建構。它還必須把執行階段環境納入考量，包括代理在任務進行期間能搜尋、檢查、擷取及復原哪些內容。
但這並不表示每個評估都應該移除網際網路存取或 git 歷史紀錄。有些評估的目的，是測試代理如何運用真實 codebase 周遭的上下文，而在這類情境中，廣泛的存取權限本來就是任務的一部分。問題在於，當這種存取改變了分數所代表的意義時，情況就不同了。
對於以歷史公開儲存庫為基礎的基準測試，開放存取可能讓代理找到已知的修正，而不是自己解決錯誤。如果測試框架中缺乏控制機制，分數就可能把程式設計能力和答案擷取混為一談。
執行評估的團隊應該先決定自己想衡量什麼樣的行為，再據此設計測試框架，並在回報結果時清楚說明設定。稽核對話記錄有助於看出模型是否以出乎預期的方式完成任務。目標不是禁止正常使用工具，而是確保基準測試衡量的，確實是它聲稱要衡量的內容。
即使如此，仍有一個更困難且尚未解決的開放問題。隨著模型越來越能察覺自己何時正在接受評估，它們可能會以更細微的方式改變行為，而這些情況無法僅靠封存 git 歷史紀錄或限制網際網路存取來修正。執行階段污染是這項更廣泛挑戰的一個具體例子：也就是如何打造出即使模型推斷自己正在被評估，仍能維持構念效度的評估。
