任務成功率從 6.7% 升至 68.3%：讓性能相差 10 倍的是 harness，不是模型

Grok Code Fast 的編碼基準測試成功率為 6.7%。在不更換模型的情況下，僅替換一個編輯格式，成功率便升至 68.3%。模型參數一個比特都沒有動過。

假期期間親自跑 agent 時，我有過類似的體驗。模型發佈速度快得令人喘不過氣，但在實際工作中對性能產生極端差異的，並非模型本身，而是包裹模型的 harness，也就是系統提示詞、工具配置與中間件的組合。

相同模型，不同排名

LangChain 團隊用自家編碼 agent 跑了 Terminal Bench 2.0。GPT-5.2-Codex 保持不變，只調整了系統提示詞、工具配置與中間件。分數從 52.8 升至 66.5，排名從榜外第 30 名以後躋身前 5 名。模型訓練費用為零。

關鍵在於推理預算的分配。將 xhigh 統一套用於所有任務時，成功率停在 53.9%；但按任務難度拆分為 xhigh-high-xhigh 後，便升至 66.5%。原本因超時而失敗的問題，透過這種分配策略得以解決。相同模型、相同 token 預算，差別只在分配方式。

被編輯格式掩蓋的真實實力

一位開源 agent 開發者創造了名為 hashline 的編輯方式。讀取文件時，在每一行附上 2 至 3 個字符的哈希標籤；模型修改時，只需引用這些標籤。

舊有方式要求模型一字不差地複現原始文字，連一個空格也不能錯，否則就會失敗。用過編碼 agent 的人都深知反覆出現 “String not found” 錯誤的痛苦。hashline 從結構上繞開了這個問題。

結果相當顯著。Grok Code Fast 從 6.7% 躍升至 68.3%，Grok 4 Fast 的輸出 token 減少了 61%。GPT-4 Turbo 僅憑格式替換便從 26% 升至 59%，Gemini 3 Flash 則超越了舊有最高紀錄 5 個百分點。沒有任何模型訓練成本，只是更換了一個編輯介面。

沒有驗證循環，agent 便止步於第一個答案

最常見的失敗模式如下：agent 寫好代碼，回頭讀一遍自己寫的代碼，判斷沒問題，從未跑過任何測試便就此結束。

LangChain 團隊在 agent 終止前加入了一個中間件，強制對照任務規格進行驗證。對同一文件反覆編輯的「死循環」，也由另一個中間件負責偵測，引導 agent 重新考量解題思路。若缺少這兩個機制，分數提升幅度將會小得多。提前向 agent 注入目錄結構與可用工具，並透過時間預算警告引導 agent 進入驗證階段，同樣收效明顯。

越便宜的模型，對 harness 越敏感

MiniMax M2.5 和 Kimi K2.5 速度快，擅長使用 agent 工具，價格也遠低於大型模型。但相較於美國大型模型，其基礎知識較為薄弱。MiniMax 給人的感覺是從一開始便針對 agent 場景專項訓練。資源有限，因而選擇專項而非通用路線，加上低廉的價格，令其在 Openclaw 等平台上的使用量急速攀升。

從 hashline 基準測試結果來看，模型越弱，格式替換帶來的性能波動幅度越大。MiniMax 在套用 hashline 後，成功率翻了一倍以上。整個基準測試的費用約為 $300。

基準測試並不等同於實際生產

有一點需要注意。無論是 Terminal Bench 還是 hashline 基準測試，測量的都是受控環境下的數值。在實際生產中，代碼庫規模、依賴衝突、需求模糊等變數要多得多。在基準測試中達到 66.5% 的 agent，能否在十萬行的遺留項目中保持同等水準，目前尚未經過驗證。harness 優化的效果是明確的，但直接將基準測試排名換算為實際生產性能，則存在相當風險。

儘管如此，方向是清晰的。在 ROI 層面，harness 設計超越模型選擇的區間確實存在。當前我們所見的基準測試排名，有相當大一部分反映的不是模型實力，而是 harness 的品質。