Proctor：面向AI編碼代理基準測試的簽名隔離捆綁工具

近年來，AI 編碼代理基準測試的可靠性受到廣泛質疑。2026年4月，賓夕法尼亞大學的研究人員（Stein、Brown、Hassani、Naik 和 Wong）發表了一篇論文，記錄了在主要基準測試中發生的廣泛作弊行為：超過1000條作弊痕跡，主要集中在 Terminal-Bench 2 和 HAL USACO 上，還有約30條任務級別的案例。這些作弊手段非常普通，例如代理直接讀取測試文件（在某個被移除的 Terminal-Bench 2 提交中，429條成功軌跡中有415條是通過簡單的文件系統讀取 /tests 實現的），或者通過查看 Git 日誌獲取修復提交，甚至直接預寫評分器的獎勵文件。這些問題本質上都是沙箱和訪問控制的失敗，而非模型的問題。研究中最引人注目的一個數字是，一個頂級提交在去除作弊後從第1名跌至第14名，這源於另一種作弊類型：通過代理的腳手架（AGENTS.md）注入答案密鑰。這種作弊方式來自沙箱外部，因此操作系統隔離無法阻止，這也是 Proctor v0.2 溯源工作的目標。

Proctor 正是為解決這些問題而設計的。它通過在操作系統級別強制隔離，運行基準測試任務，使得配置的隱藏評估工件（如測試文件、修復歷史、網絡）無法從代理的沙箱中訪問。然後，它會生成一個簽名的判決，並附帶一份防篡改的違規訪問嘗試日誌。具體來説，代理在一個重新執行沙箱初始化進程的環境中運行，該環境位於全新的用户、掛載、PID、網絡、IPC 和 UTS 命名空間中，完全無特權。測試文件不在其掛載命名空間中，而是被一個空的只讀 tmpfs 覆蓋；網絡命名空間為空，直接出站連接被拒絕；代碼倉庫在基礎提交處實例化，之後的修改歷史不會被傳輸；seccomp 用户通知監控器記錄對禁止路徑的打開嘗試和直接出站連接，但隔離強制執行完全依賴於掛載和網絡命名空間。評分器則在第二個隔離的沙箱中運行，使用代理從未見過的真實測試數據集。每個運行還會生成一個便攜的 bundle.json，包含簽名判決、違規記錄和代理日誌哈希，全部綁定在一個簽名下。

Proctor 的設計目標是一個通用的、與基準測試無關的標準。目前，它提供了 Terminal-Bench（Harbor 格式）和 SWE-bench 的適配器。對於 SWE-bench，它會在基礎提交處實例化代碼倉庫，並剝離修復歷史，然後通過隔離的評分器運行測試。Proctor 的誠實範圍僅限於阻止沙箱內的訪問作弊，即通過文件系統、Git 歷史、網絡或進程表獲取答案。它不能阻止從沙箱外部傳入的答案（例如通過腳手架注入答案密鑰），這些需要提交溯源策略，這也是 v0.2 的重點。此外，它也不能阻止針對評分器的欺騙（如直接輸出正確結果），這將在後續版本中處理。

目前，Proctor v1 已經實現併發布，支持 Linux、Rust 編寫且無需特權。它附帶了一個漏洞語料庫（corpus/），重現了所覆蓋的沙箱內訪問作弊類別，並驗證每個類別都被阻止和記錄，所有測試在標準的 GitHub CI 上均為綠色。v1 還支持簽名便攜運行捆綁包、端到端的基準測試任務，以及作為 GitHub Action 使用。未來，v0.2 將專注於提交溯源，通過捕獲和內容尋址代理接收到的所有輸入（腳手架、指令文件、代理二進制、環境），並將其綁定到運行捆綁包中，使得審查者可以驗證輸入了哪些內容。後續版本還計劃根據實際需求加強評分器防護、增加更多基準適配器，以及提供 SWE-bench 的固定鏡像解析路徑。

要安裝 Proctor，用户可以下載預編譯的二進制文件或通過 cargo 從源碼構建。它需要 libseccomp2 運行時庫，並且在某些發行版（如 Ubuntu 24.04）上需要啓用無特權用户命名空間。項目提供了詳細的安裝步驟和快速驗證方法，包括運行語料庫測試來實際驗證沙箱的有效性。