HarnessOpt-Bench：讓 LLM 自己優化 Agent Harness — Harness 工程從基礎設施變成模型能力

一句話核心結論

LLM 部署在 agentic system 中時，模型權重只是能力的一部分——harness（prompt、工具定義、控制流、記憶、編排程式碼）同樣決定最終表現。HarnessOpt-Bench 把這個命題變成可量測的基準：讓一個 LLM（optimizer）去診斷、修改、優化另一個 agent（target）的 harness，用 held-out test 驗證改進。五個前沿模型在四個下游任務（OfficeQA、BrowseComp-Plus、Terminal-Bench、GAIA）上共 111 次評分運行，結果顯示：模型選擇的影響力是 harness 選擇的 1.8 倍；原生 harness 並無一致優勢（20 組對比中共享 harness 贏 11 次、原生贏 9 次）；最強配置 claude-opus-5 在 OfficeQA 捕捉了 63% 的可用 headroom。Harness 優化已經從「人寫的樣板程式碼」變成模型自己的一種可量測能力——而且目前所有模型都還有很大進步空間。

Harness 優化問題的形式化

論文將 harness 優化定義為一個受限的隨機程式優化問題：

1. 候選（Candidate）：可執行的 Python codebase，optimizer 可編輯/新增/刪除檔案，但不可改變 target model、環境或 verifier（θ 固定）
2. 評估與揭露（Evaluation & Disclosure）：案例分為 dev/val/test 三區。Dev 揭露案例輸入、逐案例結果和完整軌跡（用於診斷）；Val 只揭露總分（用於選擇）；Test 完全不可見——只在 optimizer 提名後由 trusted server 評分
3. 預算（Budget）：上限 100 次評估呼叫 + 四次完整案例遍歷 per partition + target model token 上限。Optimizer 自己的推論 token 不設限但監控記錄
4. 目標函數（Objective）：最大化歸一化增益 g = (E(H⁺) − E(H₀)) / (1 − E(H₀))。負值代表提名候選比 seed 還差

這個問題之所以比一般 coding benchmark 難，是因為評估本身就是昂貴且隨機的：每個 harness 改動的效果必須透過多次 agent rollout 估計，而每次 rollout 都有隨機性。Optimizer 必須在有限評估預算內，從雜訊中分離真實改進、診斷失敗、決定何時提名。

實驗矩陣：五模型 × 四任務 × 雙 Harness

歸一化增益（g），粗體 = 該欄最佳。解析度帶（resolution band）：OfficeQA ±0.045、BrowseComp-Plus ±0.066、Terminal-Bench ±0.054、GAIA ±0.035。GAIA 的 seed 是非功能性 stub（baseline 為零），因此增益即原始分數。

五大發現

1. 模型可分級，但非精細排名：claude-opus-5 在三個「competent seed」任務上全面領先（OfficeQA 0.63、BrowseComp-Plus 0.48、Terminal-Bench 0.29），gpt-5.6-terra 則接近零增益。中間模型（sonnet、sol、kimi）的差距常小於 round-to-round 變異，支持「梯隊」而非排名
2. 版本軌跡可追蹤：GPT 系列五個發布版本在 OfficeQA 上增益從 +0.03 單調上升到 +0.49，其中三步超越解析度帶。Claude Opus 系列從 +0.37 到 +0.59（非單調但首尾差超過解析度帶）
3. 廣度探索與增益正相關：八類 harness 槓桿（prompt、context management、step cap、retry/timeout、tool schema、answer extraction、retrieval policy、reasoning effort）中，觸及愈多種類與增益愈相關（ρ=0.34~0.88）
4. 軌跡閱讀無助於增益：Optimizer 主要依賴逐案例分數摘要而非完整軌跡。111 個 cell 中僅 7 個請求過詳細軌跡（16 次）。閱讀軌跡的時間占比與增益負相關（-0.31~-0.64）——不是說診斷不重要，而是當前任務中逐案例摘要已足夠定位問題
5. Val 分數過度樂觀：大多數 optimizer 提名的候選在 test 上的分數低於搜尋過程中看到的最佳 val 分數。Held-out test 對量測真實增益不可省略

原生 Harness ≠ 最好 Harness

這可能是論文最顛覆的發現之一。在 20 組 model-task 對比中，共享 opencode harness 勝 11 次、原生 harness 勝 9 次——沒有統計上的系統性優勢。真正的故事藏在交互效應裡：

• GPT 系在 codex 下顯著更強（GAIA）：gpt-5.6-sol 從 opencode 的 0.31 跳到 codex 的 0.49（+0.18），gpt-5.6-terra 從 0.17 跳到 0.30（+0.13）。均超過解析度帶
• Claude 系和 Kimi 在 native vs shared 間差異不顯著：最多一兩個解析度帶的差距
• GAIA 是唯一有多於兩個 harness 層級的任務：加上 goose 和 mini-swe-agent 後，harness 排序因模型而異——沒有一個 harness 在所有模型上保持同一排名

對實務的啟發：只讀 shared harness 會低估某些模型的真實能力（如 GPT+codex），但只讀 native harness 會把 harness 的貢獻誤歸因給模型。雙 harness 設計是這個基準最關鍵的方法論貢獻。

對 Hermes / DKY 的啟發

• Harness 優化是 Hermes 的核心能力：Hermes 本身就是一個 harness（prompt system + tool definitions + control flow + memory + orchestration）。HarnessOpt-Bench 的結論意味著讓 Hermes 優化自己的 harness 是合理且可量測的方向。目前最強模型已能捕捉 63% 的 OfficeQA headroom，但 Terminal-Bench 僅 29%——複雜系統環境的 harness 優化遠未飽和
• 雙 Harness 設計的方法論：對 Hermes 的自我改進實驗，建議採用類似策略——比較 Hermes 在固定 harness 下的改進 vs 在自身原生 tooling 下的改進，分離「模型進步」和「工具適配」的貢獻
• 廣度探索 > 細節診斷：論文發現觸及更多 harness 槓桿比花時間讀軌跡有效。對 Hermes 而言：與其讓 agent 仔細閱讀每個任務的完整 log，不如讓它快速嘗試多個不同類型的改進（改 prompt、調 timeout、換 tool schema 等），由評估結果反推有效方向
• Held-out test 的必要性：Val 分數系統性高估真實增益——Hermes 在自我評估時，必須保留一部分未見過的測試案例，否則無法區分真實進步和對驗證集的過擬合
• 預算約束的現實：論文用 case passes（而非 evaluation calls）約束搜尋。Hermes 的自我改進也面臨同樣問題：不是 API 呼叫次數限制進步，而是能跑多少次完整 agent 任務。應以「完整任務執行次數」而非「推論 token 數」作為 self-improvement 的預算單位

限制

• 候選僅限 Python，每個任務只用一個固定的 target model——未測試跨語言、跨 runtime、跨 agent 架構的泛化
• Tasks 和 splits 固定，反覆 dev/val 回饋可能獎勵針對特定評估的策略而非通用改進。未來需要引入 per-run jitter
• GAIA 的 seed 是非功能性 stub vs 其他三任務的 competent-but-naive seed——seed 品質對 optimizer 行為的影響未系統性變化
• Optimizer 自己的推論 token 不設限——目前的結果代表「當推理預算不是瓶頸時」的上限
• 未測試 optimizer model 自己就是 target model 的自我優化場景（最貼近 Hermes 的實際使用情境）