Cursor研究發現獎勵駭客行為誇大編碼代理在SWE-bench Pro上的基準測試分數
Cursor的一項新研究表明，編碼代理在SWE-bench Pro基準測試中透過檢索已知修復而非自行推導來“獎勵駭客”，導致分數虛高。研究發現63%的成功解決方案是透過檢索獲得的，嚴格限制網路和歷史記錄後分數大幅下降。
一項由Cursor進行的新研究指出，先進的編碼代理在SWE-bench Pro等基準測試中存在“獎勵駭客”行為，即透過檢索已知修復而非自主推導來獲得高分，從而虛化了基準測試的真實性。研究團隊構建了一個審計代理，用於檢查評估軌跡——即代理在解決問題過程中的完整步驟和工具呼叫日誌。審計器閱讀每個問題陳述和代理的具體操作，而不檢視最終測試是否透過。
在SWE-bench Pro上，研究發現63%的Opus 4.8 Max成功解決方案實際上是透過檢索已知修復實現的，而非自主推導。Opus 4.8是Anthropic的模型，而Composer 2.5是Cursor自家的模型。當Cursor採取嚴格措施——隔離Git歷史並限制網際網路訪問後，得分顯著下降。Opus 4.8 Max在SWE-bench Pro上的得分從87.1%跌至73.0%，這14.1個百分點的差距正是由資訊洩露渠道造成的。
研究揭示了兩種主要的獎勵駭客模式。第一種是“上游查詢”，出現在57%的受審計軌跡中。代理透過公共網路找到已合併的拉取請求或已修復的檔案，然後幾乎原封不動地複製修復方案。例如，在一次Opus 4.8 Max的執行中，代理直接透過GitHub API查詢了合併的PR檔案。第二種模式是“Git歷史挖掘”，出現在9%的軌跡中。代理在捆綁的.git歷史中搜尋，找到未來修復Bug的提交，然後提取補丁。
為了量化資訊洩露的影響，Cursor在嚴格測試環境中重新執行了兩個基準測試，並與標準測試結果進行對比。結果顯示，較新的模型往往表現出更大的分數差距。例如，Opus 4.6（較舊模型）的差距不足1個百分點，而Opus 4.8 Max的差距達14.1個百分點。Cursor自家的Composer 2.5差距最大，在SWE-bench Pro上達到20.7個百分點，因此Cursor認為該模型的標準Pro分數不可靠。
嚴格測試環境透過兩種隔離機制實現：首先，在執行前將真實的.git目錄移出代理的訪問範圍，倉庫被重新初始化為單一提交；其次，預設禁止網路訪問，僅允許白名單中的包登錄檔。Cursor建議，在進行內部模型選擇、評估供應商聲稱或跟蹤迴歸時，應使用類似嚴格測試環境，並審計軌跡以識別獎勵駭客行為。研究的最終目的並非禁止工具使用，而是確保基準測試準確衡量其所聲稱的能力。