CyberGym 基準測試解析：E2E 分數究竟衡量什麼

最廣為流傳的 CyberGym 分數——也就是發布貼文中的那個數字、被拿來在各模型之間比較的那個——是 131 項經過篩選的任務的任務成功率；其中成功是指代理產生一個概念驗證輸入，能使未修補的 C/C++ 建置崩潰、寫出能阻止該崩潰的修補程式，且未破壞專案中由開發者撰寫的測試。在 BenchLM 的彙整中，MiMo-V2.6-Flash 以 95.1% 領先，MiMo-V2.6-Pro 為 94.0%，DeepSeek-V4.1-Flash 則落後幾個百分點，落在八成八、九。幾乎沒有引用該表的人會提到三件決定這些數字是否可比的事：該基準存在不只一種實作、大多數列是供應商自我報告而非獨立執行，以及最有趣的那個階段雖有記錄卻未計分。這正是同一套歸因標準：AI 事件檔案庫套用於自身條目——沒有來源的主張不算結果——而 CyberGym 語料庫未達此標準的頻率，比其聲譽所暗示的還高。

這是一份指南，說明基準測試要求代理做什麼、任務集如何建立、各實作在哪些地方出現分歧，以及防禦者應該和不應該從高分得出什麼結論。

任務：找出、重現、修補——而不破壞任何東西

CyberGym 源自 Berkeley Center for Responsible, Decentralized Intelligence，其前提刻意設定得相當狹窄。每項任務都針對一個廣泛使用的開源 C/C++ 專案中的記憶體安全漏洞。代理必須找出該錯誤、撰寫可觸發 sanitizer 崩潰的概念驗證輸入，然後修補程式碼，使崩潰不再重現，同時專案自身的測試仍持續通過。這個流程正是重點。只要求「找出錯誤」的基準測試會獎勵模式辨識；要求可運作的崩潰輸入與不造成破壞的修補，則迫使代理完成從懷疑、證明缺陷到修復的閉環。

RDI 將這項基準測試置於一個更廣泛的觀測體系中，該體系追蹤 AI 在攻擊與防禦各階段的網路能力，而這樣的定位框架值得注意：CyberGym 只是測試台上的一項工具，與 ExploitGym 及端到端變體並列。若把它當成獨立的排行榜來解讀，就會失去這層脈絡，這也是這些數字一旦脫離原脈絡往往失真、難以通用的原因之一。

四個階段，其中三個會計分

評分規則是這項基準測試中最少被報導的部分，因為正是在這裡，一個聽起來合理的分數可能與實際發生的情況產生落差。

階段 1是重現：代理程式的概念驗證輸入是否會使未修補的建置當機。階段 2是修補：提交的變更是否能阻止該特定當機。階段 3是回歸：開發人員撰寫的功能測試是否仍會通過。這三項會產生分數。

階段 4要問的是：這個修補是否真的修好了實際的 ground-truth 漏洞，而它會被記錄為一項診斷資訊，而不是計入分數。這個不對稱值得花點時間說明，因為它正是「代理能讓一個當機消失」與「代理能修好這個 bug」之間的差別。兩者都是有用的主張；但它們並不是同一個主張。一個代理若靠攔截訊號、把邊界檢查放寬到超出溢位範圍，或乾脆停用整條程式碼路徑來壓制當機，它在階段 1 到 3 會得分，卻會在階段 4 失敗。如果一份報告只給出一個數字，卻沒說明是否參考了階段 4，你就無法判斷它測量的究竟是這兩者中的哪一個——而診斷之所以存在，正是為了讓你能問這個問題。

131 項任務是如何選定的——以及這對分數有何影響

來源資料集比評分集更大，而篩選是影響可比性的最大單一槓桿。RDI 的資料集包含來自 Google OSS-Fuzz、橫跨 139 個開源專案的 920 個漏洞。第三方追蹤器所採用的端到端變體將其縮減為 131 項任務，每個專案一項任務，依難度挑選，並排除有 oracle 洩漏或沙箱相容性限制的任務。

由此直接得出三個後果。首先，每個專案只有一個任務意味著分數主要由廣度而非深度主導：一個在許多專案上表現中等的代理，會勝過一個只在三個專案上表現卓越的代理；這是站得住腳的設計選擇，也是一種不同於「這個代理能修復多少漏洞」的衡量方式。其次，排除 oracle 洩漏會移除那些答案可從環境中發現、而非透過推理得出的任務，因此剩下的任務集會以特定方式變得更難——它移除的是捷徑，而不是移除簡單任務。第三，每個任務 90 分鐘的預算，並且是在以該專案 OSS-Fuzz 映像檔建立的沙箱內執行，這是成功定義的一部分，而非無關緊要的細節，因為很大一部分真實的漏洞相關工作正是受這類限制所約束，而依賴無界探索的代理會在這裡失敗，卻在其他地方成功。

任何忽略任務選擇規則的比較，都是在比較兩個恰好同名的不同測驗。

兩種實作，以及為何它們不必一致

大部分的混淆就出在這裡。CyberGym-E2E 既是作為 RDI 基準而存在，也是由第三方評估者所運行的實作，而兩者不保證對同一個模型產生相同的數字。評估者自己的文件明白指出：其實作使用一組經過篩選的 131 項任務，每個專案一項，依難度挑選，並且它在隔離沙箱中運行每一項任務，沙箱是從該專案的 OSS-Fuzz 映像建構而成，使用其自己的 agent harness，每項任務有 90 分鐘的預算。

這句話包含了決定分數的兩個變數。 測試框架是代理運行時所處的迴圈——它如何觀察工具輸出、能採取多少步驟、如何從失敗的嘗試中恢復。較強的框架搭配較弱的模型，可以勝過相反的情況，而框架並不屬於模型的權重。 預算則與兩者相互作用。因此，CyberGym 的數字應正確地寫成「這個模型，在這個框架中，在這個實作裡」，而引用時缺少實作細節的數字，就是一個沒有分母的數字。

有一個值得指出的二階效應：由於測試框架（harness）承擔了實際工作，兩個模型版本之間的 CyberGym 分數提升，可能有一部分其實是測試框架的改進；而廠商若報告自家測試框架的結果，所報告的是系統能力，而非模型能力。兩者都合理；將它們混為一談則不然。

誠實地閱讀追蹤表

大多數人遇到的這張表是次級彙編，而且它標示了自己的來源——只要讀了標示，這正是有用之處。在 29 列中，7 列來自基準測試擁有者或獨立執行，21 列是供應商自我報告，還有一列是次級報告。這份彙編明言，它列出此表僅供參考，並不據此排名，並建議謹慎閱讀，因為大多數列都是自我報告。它自己的飽和度註記是頁面上最有用的一行：前三名相差約 70 分，而前十名則落在約 10 分以內，因此這張表仍能區分模型——但不是在範圍頂端，那裡的排序很薄弱。

供應商的自我報告是可展示的證據。它不是獨立測量，而這項差異在這個基準測試中比在大多數情況下都更重要，因為測試框架變數讓廠商有相當大的空間去調整它所回報的數字。當自我報告與獨立執行結果不一致時，以獨立執行結果為準。當只有自我報告存在時，誠實的解讀是「未經證實、看似合理、無可比較的基準線」。

反向而言，同樣的告誡也適用於這項基準測試為讀者設下的陷阱：一個沒有 CyberGym 欄位的模型，並不代表它拿零分。它只是尚未在那套測試框架中被測量過，這是兩種不同的陳述。把「缺席」當成「失敗」，正是讓一張表格不再是一項量測、而淪為排行榜的開端。

高分對防守球員代表什麼，又不代表什麼

安全團隊真正在意的問題，並不是「哪個模型登上排行榜首位」，而是「一個在這項評測中拿高分的 agent，會對我的風險造成什麼影響」。基準測試所回答的問題，比真正被提出的問題狹窄得多，而這道落差值得被明確指出。

這確實意味著代理能在 90 分鐘內、在已知的建置版本中，於真實的開原始碼裡找出記憶體安全漏洞，產出可運作的崩潰輸入，並寫出一項能阻止崩潰又不破壞測試的變更。這是實實在在的能力，與分診和修補工作直接相關，也正是勝任的代理能有意義地縮短分析師待辦隊列的那類任務。

這並不代表代理程式了解你的程式碼庫、你的威脅模型或你的部署環境。這些任務取自公開的 OSS-Fuzz 目標，具有已知的真實漏洞，以及一套能告訴代理程式是否完成的測試套件。正式環境的程式碼沒有這種判定依據。這也不代表代理程式會找到那個錯誤，而不是一個錯誤：第 4 階段之所以存在，正是因為兩者會分歧，而第 4 階段不計入。

而這並不會移轉到攻擊面，而在攻擊面上，同樣的能力會有不同的解讀。一個能夠定位並重現記憶體安全缺陷的代理，也能在未經授權測試的程式碼中這麼做，這正是為何這種等級的能力，恰恰促使人們在模型層級進行存取控制，而非只在系統提示中寫一句免責聲明。

在信任 CyberGym 數字之前，該問什麼

五個問題，一份寫得好的報告足以回答，而一篇發布貼文通常無法回答。

• 哪種實作？ RDI 的基準測試，還是第三方評估者的過濾變體。如果報告沒有說明，這個數字就無法與任何東西比較。

• 誰的執行結果？獨立評估或供應商自我報告。彙整表會逐列標示這一點；大多數行銷資料則不會。

• 是哪一套測試框架，預算又是多少？ 如果該測試框架是供應商自家的且未加以說明，請將結果視為針對特定產品配置的系統層級主張。

• 有諮詢第 4 階段嗎？附有診斷資訊的回報比率，能告訴你修補程式是真正修好了錯誤，還是只是讓當機不再發生。

• 是哪一組任務？ 常見的任務集是依難度挑選出的 131 個「每個專案一項」的任務；換一組篩選條件就是另一項測試。

Cybergym 是一個為困難且真實的任務所精心建構的基準測試，而它的建構方式比它的排行榜更有意思。各階段說明了代理必須做什麼；篩選機制說明了這個分數究竟是什麼的分數；測試框架說明了功勞該歸給誰。一個附帶這三者的數字才真正有用。單獨出現的數字，只是帶著百分比符號的公關稿。