我們對 Coding Agent 的評測，可能搞錯了方向

我們對 Coding Agent 的評測，可能搞錯了方向。

一個反復出現，但常常被忽略的現象是：用戶對 Agent 的不滿，往往不是因為它「做不到」，而是因為它「做得不好」。

「做得不好」集中表現在：Agent 不遵循明確給出的指令和潛在的工程規范。比如，系統提示里明確要求「不要使用 emoji」，Agent 卻在代碼注釋里加上笑臉；用戶要求「先備份再修改」，Agent 上手就是一鍵 [rm -rf] 刪除文件。

這些問題的共同特征是：任務最終可能完成了，但過程違反了規范。用戶要的不只是「能跑的代碼」，還有「符合團隊協作規范的代碼」。

這也暴露了當前主流評測體系的盲區。學術榜單，不管是SWE-bench verified，還是各種基于terminal環境的測試，核心理念幾乎都是結果導向指標。只問兩個問題：測試通過了嗎？Bug 修復了嗎？

這種評估方式，不看模型在沙盒里的輸出過程，也不看真實場景的交互體驗。最后的結果是：評估和真實使用場景，完全錯位。

為此，MiniMax 開源了一個新評測集：OctoCodingBench。用來評測 Coding Agent 在完成任務的過程中，有沒有遵守規矩。

測評結果很有意思：即便是最強的模型，在 2/3 的任務中，代碼可能是對的，但過程是錯的。

Hugging Face 鏈接：

huggingface.co/datasets/MiniMaxAI/OctoCodingBench

??關注 Founder Park，最及時最干貨的創業分享

超 19000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的AI產品曝光渠道

01為什么 Coding Agent 需要新的 Bench？

如果遵循過程規范的 Coding Agent，才能被放心地引入真實的軟件工程流程中。那目前主流 Code Agent 的評估體系就出現了明顯的盲區。隨著 Claude Code、Codex、Cursor、Windsurf 等 Agent 產品的普及，社區正在形成一套面向 Agent 的倉庫協議體系。項目不再只是一堆代碼，同時也包含了多層次協作模式的說明：

• [CLAUDE.md]/[AGENTS.md]：告訴 Agent「這個項目怎么玩」——命名約定、測試流程、禁用的危險操作等

• Skills：封裝可復用的工作流 (如「生成 API 文檔」)，Agent 需要正確識別觸發時機并按規范調用

• Memory：跨會話保存用戶偏好和任務進度，Agent 需要基于歷史狀態繼續工作，而非從頭開始

這些機制的出現，本質上是在構建一個多層級的指令系統。舉個例子，當用戶說「幫我重構這個模塊」時，Agent 需要同時滿足多個層級的約束：系統層面的安全規則（不能直接刪代碼）、當前用戶的即時指令（重構到什么程度）、倉庫中明確寫下的工程規范，以及歷史記憶中已經做出的決策（延續還是推翻）。更復雜的情況是，這些指令源之間可能沖突。用戶臨時說「這次就先不寫測試了」，但 [AGENTS.md] 里明確要求「每次提交必須有測試覆蓋」——Agent 該聽誰的?

然而一個尷尬的問題是，當前的學術榜單，無論是 SWE-bench verified，還是各類基于 terminal 環境的測試，其核心理念幾乎都是Outcome-based Metrics(結果導向指標)：測試是否通過? Bug 是否修復？這種結果導向的評估方式，根本無法刻畫模型在沙盒環境下的輸出過程，更不用說復雜現實場景的真實交互體驗，最終導致了評估和真實使用場景的錯位。

02OctoCodingBench：

面向工程可靠性的過程評估

要解決這個問題，評估范式本身需要發生根本性轉變——需要關注輸出過程本身。

基于這一動機，MiniMax 引入了 OctoCodingBench，從Check-level 準確率 (CSR)、 Instance-level 成功率 (ISR)兩個維度來進行評估，旨在充分觀測模型的完成任務時出現的過程指令不遵循問題，以盡可能接近真實用戶體驗。

其中，CSR 用來衡量 Coding Agent 遵循了多大比例的規則，ISR 則用來衡量 Coding Agent 是否遵循了每條規則。

一個合格的 Coding Agent，需要在完成任務的同時遵循：

• System Prompt中的全局約束 (語言、格式、安全規則)

• UserQuery的多輪指令更新

• System Reminder提供的腳手架指令

• Repository 規范文件(如 [CLAUDE.md]/[AGENTS.md]) 中的代碼風格、提交規范

• Skills 文檔的正確調用流程

• Memory/Preferences中記錄的用戶偏好和項目狀態

基于該評測集，MiniMax 針對現有的開源閉源模型進行了廣泛的評估，發現了一些很有啟發性的實驗結果：

• 所有模型的 Check-level準確率 (CSR) 可以達到 80%+，但 Instance-level 成功率 (ISR) 只有 10%-30%。換句話說，模型在單項約束上表現不錯，但一旦要求「全部規則同時滿足」，成功率就斷崖式下跌。

• 絕大模型模型的指令遵循能力會隨著輪次的變多逐漸下降。這印證了「過程合規」在長流程任務中的脆弱性。

不同交互輪次下 ISR 的變化

• 現階段模型表現普遍未能達到生產級要求，過程合規仍是盲區：

  從榜單數據來看，即便是表現最強勁的 Claude 4.5 Opus，其 Instance-level 成功率（ISR）也僅為 36.2%。這意味著，在近三分之二的任務中，模型雖然可能寫出了能跑的代碼，但在過程規范上依然存在違規。這一低分現狀明確揭示了一個事實：Coding Agent 的「過程規范遵循」尚未被業界充分關注和優化，目前的模型嚴重偏科于「結果正確」，而忽視了「過程正確」。

• 開源模型正在快速追趕閉源模型：

  觀察榜單可以發現，MiniMax M2.1 和 DeepSeek V3.2 的 ISR 分別達到了 26.1% 和 26%，已經超過了公認強大的閉源模型 Claude 4.5 Sonnet (22.8%) 和 Gemini 3 Pro (22.9%)，開源模型已經展現出了極強的競爭力。

03未來的研究方向

MiniMax 認為，下一代 Coding Agent 的訓練，需要引入Process Supervision(過程監督)：

• 細粒度的過程監督：不只監督模型的「測試通過」，還要監督模型「遵循命名規范」、「正確使用 Skills」、「沒有泄露 System 信息」等；

• 層級化的指令遵循：在訓練數據中標注指令沖突場景，讓模型學會在沖突情況下如何遵從指令層次的優先級行動；

• 可驗證的 Checklist：把「指令遵循」從模糊的整體印象，拆解成可自動化檢查的原子約束，既能用于評估，也能用于 RL 信號構建。

Coding Agent 的能力邊界，正在從「能否寫出能跑的代碼」，轉向「能否在復雜約束下協作式地完成任務」。這也映射出產品哲學的深層轉變：Agent 不是要替代人類開發者，而是要成為懂規矩、守紀律的團隊成員。

因此，過程規范（Process Specification）才是 Coding Agent 進化的核心命題。

當我們開始關注過程而非僅僅結果，當我們讓評估體系能夠捕捉「違規但成功」的危險模式，Coding Agent 才能真正從 Demo 走向生產環境。

轉載原創文章請添加微信：founderparker