從 2% 到 47%：Mellum 2.1 的修復數字，是一道被排好的驗收介面

JetBrains 在 2026 年 10 月 12 日前後公開的 Mellum 2.1 評測資料裡，最顯眼的一組數字是 SWE-bench Verified 解決率：前代 Mellum 2 為 2%，Mellum 2.1 升至 47%，而同設定下的 Qwen3.5-9B 是 50%。這三個百分比被放在同一張表上，本身就構成了一種閱讀介面，讀者第一眼讀到的是「大幅進步」與「仍差對手三個百分點」兩層訊息。數字怎麼被排、跟誰比、比什麼，決定了這個模型在大眾心中被理解的方式。

先看模型本身的規格。Mellum 2.1 是 120 億總參數的混合專家模型，每個詞元約啟用 25 億參數；官方模型卡列出 131,072 個詞元的最大上下文長度。JetBrains 表示架構維持不變，主要更新投入後訓練，特別是強化學習與代理式軟體工程任務，訓練時模型在真實程式碼庫環境使用 shell 與檔案編輯工具，以測試結果作為回饋訊號。

值得留意的是官方對這個模型的定位措辭：代理系統中的「工作模型」，負責找出失敗測試的根因、草擬並檢查修補。這個定位是有邊界的。模型本身不會在啟動後就擁有讀取程式碼或執行命令的權限，團隊必須自行接上工具、設定可讀寫的目錄、可執行的指令與批準流程。換句話說，Mellum 2.1 被交付的不是一個完整產品，而是一組等待被組裝進工作流程的推理與生成元件。

這種「提議與採用分離」的設計，與我們先前觀察過的把勾選框重新設計成驗收關卡的 Todo 軟體有相似的結構：代理產生差異檔之後，先由測試、靜態分析或人工檢視判斷，再決定是否合併；測試未通過就讓流程停下並回報失敗，而不是把模型回覆直接當成修復完成。這條界線的價值在於可追責，出錯時能區分問題出在模型理解、工具介面、測試覆蓋，還是權限與環境設定。

回到那組數字。SWE-bench Verified 以真實軟體專案的問題與測試為基礎，衡量模型能否提出通過指定測試的修改。47% 對 50% 的差距在基準測試上是可指認的事實，但來源也明確提醒，這些是廠商自行評估的結果，不能直接推算真實團隊的修復率或節省的工時。基準分數與專案實況之間，隔著代理框架的品質、工具接線的完整度、測試覆蓋的密度，以及審核流程是否真的被執行。

這正是程式代理與單次程式碼生成在介面上的根本差異。單次生成只有一個畫面：提示、輸出、人類貼上編譯。代理式修復則是一連串必須被設計的狀態：讀檔、執行測試、定位原因、提出差異、重跑檢查、回報結果。每個轉換點都是一次驗收，也都是一次可能失敗的表達。我們在AI 生成程式碼被加上四層包裝的觀察裡提過，一套被排成「周全」的程式介面可能在語義與維護成本之間失去表達失敗的能力；代理工作流程的設計課題恰好相反，它必須讓失敗被看見、被分類、被停下來。

從這個角度看，Mellum 2.1 的價值不在那 47% 本身，而在它被交付的方式：一個需要被接上工具、套上權限、放進批準流程的工作模型，加上一組透明的基準數字與明確的低於對手的比較。願意把「仍輸 Qwen3.5-9B 三個百分點」寫進同一張表裡，這個排版本身就是一種誠實的介面設計。至於它能不能修好你團隊的程式，答案不在模型卡上，而在你為它搭起的那套驗收流程裡。