新智元報導
編輯：傾傾
【新智元導讀】如果未來的某天，AI 智能體（Agent）可以自己調整參數、修復 Bug，會發生什麼？
就在最近，史丹佛大學 IRIS Lab 的博士生 Yoonho Lee 聯合 MIT 與威斯康辛大學的研究者發表了一篇新論文，將 AI 智能體優化的邏輯完全翻轉了過來。
這篇論文的作者陣容十分豪華。指導教授是機器人學習明星學者 Chelsea Finn，合作者中還包括 DSPy 框架的作者 Omar Khattab。
過去，業界競爭的焦點在於模型本身的參數規模、訓練數據以及 RLHF（人類回饋強化學習）。但 Meta-Harness 另闢蹊徑：它認為支撐模型運行的那一層「腳手架」（Harness）同樣決定了性能的生死。
這些設定以前全靠人工調校，而現在，Meta-Harness 讓 AI 自己來完成這項工作。
結果令人驚艷：Claude Haiku 4.5 的成功率達到 37.6%，登頂所有 Haiku 智能體榜首；Claude Opus 4.6 更是達到 76.4%，僅次於榜一的 ForgeCode。
所謂的 "harness" 指的是一整套基礎設施：包括系統提示詞（System Prompt）、工具定義、重試邏輯、上下文管理、子代理協調以及生命週期鉤子（Lifecycle Hooks）。
如果說模型本身是大腦，那麼 harness 就是讓這個大腦能實際工作的身體。
這個概念在 2026 年突然爆紅，業界終於意識到，同一個模型，只要更換不同的 harness，性能差距可能會大得離譜。
今年 2 月，工程師 Can Bölük 做了一個實驗。他僅僅修改了編輯格式而未更動模型，結果 15 個大語言模型（LLM）的編碼性能提升了 5 到 14 個百分點，且輸出 token 減少了約 20%。
更誇張的是，GPT-4 Turbo 僅僅因為更換了一種編輯格式，準確率就從 26% 飆升至 59%。同樣的模型，性能差距超過一倍，唯一的變數就是 harness。
「Agent = Model + Harness」成為目前最熱門的趨勢。模型提供智能，而 harness 讓智能變得有用。
Claude Code 與 Codex 都在做同一件事：精心設計 harness 來彌補模型的短板。但問題在於，harness 工程目前高度依賴人工。
工程師必須手動撰寫提示詞、調整工具接口、設計重試策略，然後進行測試、分析日誌、猜測問題所在、修改程式碼並再次測試。這個循環既耗時又費力，而且許多失敗模式根本不是人類能輕易診斷的。
Meta-Harness 的目標，就是將這個循環自動化。
Meta-Harness 嘗試 給優化器提供更多資訊。這聽起來簡單，但恰恰是過去所有方法的瓶頸。
論文中的對比表列出了主流文本方法在每一步能看到的上下文數量：
Self-Refine 僅查看最近一次的輸出與自我批評，約 1,000 token；OPRO 查看過去幾輪的方案與分數，約 2,000 token；而 TextGrad、AlphaEvolve、GEPA 等較先進的方法，也僅在 8,000 到 26,000 token 之間。
而 Meta-Harness 呢？最高可達 1,000 萬 token，差距高達 400 倍。
為什麼需要這麼多？因為 harness 工程產生的失敗模式，往往隱藏在執行軌跡（Execution Traces）的細節中。例如，一個任務執行失敗，原因可能是十步之前某個工具調用返回了截斷的輸出，導致後續推理全部偏差。
如果優化器只能看到一個「失敗」的標量分數，或者一段壓縮後的摘要，它根本無法定位問題。Meta-Harness 的做法是給提案者（Proposer）一個完整的文件系統。
這個文件系統中儲存了所有歷史候選 harness 的源碼、每一輪的執行軌跡、命令日誌、錯誤訊息、超時行為及評分結果。提案者可以使用 grep、cat 等標準工具自行檢索，想看哪個文件或搜尋哪個關鍵字都可以。
優化器不再是在固定 prompt 上做推理，而是一個會檢索資訊、瀏覽歷史、編輯程式碼的智能代理。提案者使用的是 Claude Code，它不需要被餵食壓縮資訊，它有能力自行決定看什麼以及怎麼看。
整個搜尋循環非常直觀：
- 提案者讀取文件系統中的歷史記錄。
- 分析哪些任務失敗了以及失敗原因。
- 針對性地重寫 harness 程式碼。
- 新 harness 運行測試，結果寫回文件系統。
- 循環持續進行。
論文展示了一個包含 19 個任務子集的搜尋過程。從 Terminus-KIRA 基線的 28.5% 起步，到第 7 輪迭代就成長至 46.5%。
每一輪都基於具體的執行軌跡進行「反事實診斷」——如果當時這樣處理，結果是否會不同？例如，第 7 輪的改進是在第一次 LLM 調用前先執行一條 shell 命令，將環境依賴資訊注入到初始 prompt 中。增加一條命令，省去了無謂的試錯。這種程度的診斷精度，是靠壓縮摘要無法實現的。
Meta-Harness 分三個場景進行測試：文本分類、數學推理、程式碼代理。程式碼代理使用 TerminalBench-2 作為基準，包含 89 個 Docker 化任務，涵蓋程式碼翻譯、分佈式機器學習配置、系統編程、生物資訊學、密碼分析等領域。
每個任務均為二元評分，執行 5 次取平均值，難度相當高。因為它們需要長程自主執行、處理複雜依賴、應對截斷的終端輸出，且需要深厚的領域知識。該基準被幾乎所有前沿實驗室用來衡量程式碼代理的實際能力，是繼 SWE-bench 之後又一個被廣泛認可的「真實工作」測試集。
Meta-Harness 的做法是優化完整的編碼 harness，包括系統提示詞、工具定義、完成檢測邏輯、上下文管理，全部納入優化範圍。提案者會讀取每個任務的執行軌跡，診斷失敗模式，然後提出針對性修復。
結果，Claude Haiku 4.5 的成功率達到 37.6%，在所有 Haiku 4.5 代理中排名第一，超越了第二名的 Goose (35.5%)。Claude Opus 4.6 的成功率高達 76.4%，在所有 Opus 4.6 代理中排名第二，僅次於 ForgeCode (81.8%)。
需要強調的是，Haiku 是 Claude 系列中最輕量的版本，參數規模遠小於 Opus。傳統思路認為小模型天生不如大模型，性能天花板是硬傷。但 Meta-Harness 證明，透過優化 harness，小模型的性能天花板可以被顯著抬高。
Meta-Harness 不僅在程式碼任務上有效。在文本分類場景下，研究者使用了 LawBench (215 類)、Symptom2Disease (22 類)、USPTO-50k (180 類) 三個數據集，模型為 GPT-OSS-120B。經過 20 輪進化迭代，最佳發現的 harness 在測試集上達到 48.6% 準確率，比之前的 SOTA 方法 ACE 高出 7.7 個百分點。
甚至成本更低——Meta-Harness 僅使用了 45.5K 上下文 token，而 ACE 使用了 203K。
研究者還做了直接對比實驗，將 Meta-Harness 與兩個代表性的程式搜尋方法在相同提案者與評估預算下進行對比。結果顯示，Meta-Harness 僅用 十分之一 的評估次數就追平了對方的最終準確率，且最終準確率還高出 10 個百分點以上。
原因在於 OpenEvolve 和 PUCT 將歷史壓縮成固定 prompt 格式，丟棄了執行軌跡，而 Meta-Harness 保留了所有細節。
在數學推理場景下，Meta-Harness 搜尋的是檢索增強（RAG）的推理策略。語料庫包含超過 50 萬道題目，來自 8 個開源數據集。研究者在 250 道題的搜尋集上進化出一個檢索 harness，然後在 200 道 IMO 級別題目上測試，並額外使用了 5 個搜尋過程中未見的模型。
單一發現的檢索 harness 在 5 個新模型上平均提升了 4.7 個百分點（從 34.1% 提升至 38.8%），且是在模型本身不變的情況下。這說明 Meta-Harness 發現的策略具有可遷移性，而非僅針對特定模型的過擬合技巧。
模型能力的競爭正進入新階段。過去幾年，前沿實驗室比的是誰的模型更強、參數更多、數據更大。但現在，GPT-5、Claude 4、Gemini 3 在許多任務上已拉不開太大差距。
真正的差距在於 harness。同一個模型，配上不同的 harness，性能可能差一倍。而 harness 工程目前仍高度依賴人工經驗，缺乏系統化方法與自動化工具。
模型是智能的來源，harness 是智能的放大器。而現在，優化 harness 本身也可以交給 AI。這可能是 LLM 應用開發進入下一個階段的標誌。
參考資料：https://x.com/yoonholeee/status/2038640635482456118