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

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

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

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

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

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

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

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

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

Hugging Face 鏈接：

huggingface.co/datasets/MiniMaxAI/OctoCodingBench

??關(guān)注 Founder Park，最及時最干貨的創(chuàng)業(yè)分享

超 19000 人的「AI 產(chǎn)品市集」社群！不錯過每一款有價值的 AI 應(yīng)用。

邀請從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

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

• 最精準的AI產(chǎn)品曝光渠道

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

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

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

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

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

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

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

02OctoCodingBench：

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

要解決這個問題，評估范式本身需要發(fā)生根本性轉(zhuǎn)變——需要關(guān)注輸出過程本身。

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

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

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

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

• UserQuery的多輪指令更新

• System Reminder提供的腳手架指令

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

• Skills 文檔的正確調(diào)用流程

• Memory/Preferences中記錄的用戶偏好和項目狀態(tài)

基于該評測集，MiniMax 針對現(xiàn)有的開源閉源模型進行了廣泛的評估，發(fā)現(xiàn)了一些很有啟發(fā)性的實驗結(jié)果：

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

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

不同交互輪次下 ISR 的變化

• 現(xiàn)階段模型表現(xiàn)普遍未能達到生產(chǎn)級要求，過程合規(guī)仍是盲區(qū)：

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

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

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

03未來的研究方向

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

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

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

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

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

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

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

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker