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

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

歸一化增益（最佳 per model）。解析度帶：OfficeQA ±0.045、BrowseComp-Plus ±0.066、Terminal-Bench ±0.054、GAIA ±0.035。

1. 模型可分級，但非精細排名：claude-opus-5 三任務全面領先；gpt-5.6-terra 接近零增益。中間模型的差距常小於 round-to-round 變異 → 梯隊而非排名
2. 版本軌跡可追蹤：GPT 五版本在 OfficeQA 從 +0.03 單調升至 +0.49；Claude Opus 從 +0.37 到 +0.59
3. 廣度探索與增益正相關：八類 harness 槓桿中，觸及愈多種類與增益愈相關（ρ=0.34~0.88）
4. 軌跡閱讀無助於增益：Optimizer 依賴逐案例分數摘要而非完整軌跡；閱讀軌跡與增益負相關（-0.31~-0.64）
5. Val 過度樂觀：大多數 test 分數低於搜尋中最佳 val 分數 → held-out test 不可省略

共享 opencode 勝 11 次、原生勝 9 次——無系統性優勢。但 GPT 系在 codex 下顯著更強：sol 從 0.31→0.49（+0.18）、terra 從 0.17→0.30（+0.13）。Claude 和 Kimi 的 native/shared 差異不顯著。只讀 shared 會低估 GPT 的能力，只讀 native 會把 harness 貢獻歸因給模型。雙 harness 設計是這個基準最關鍵的方法論貢獻。

• Harness 優化是 Hermes 的核心能力：Hermes 本身就是一個 harness。目前最強模型能捕捉 63% OfficeQA headroom，但 Terminal-Bench 僅 29%——複雜系統的 harness 優化遠未飽和
• 雙 Harness 設計的方法論：比較 Hermes 在固定 harness vs 自身 tooling 下的改進，分離「模型進步」和「工具適配」
• 廣度 > 細節：快速嘗試多種 harness 改動類型，由評估反推有效方向，而非花時間細讀完整軌跡
• Held-out test 必要性：Val 分數系統性高估真實增益——自我評估必須保留未見過的測試案例
• 預算單位：以「完整任務執行次數」而非「推論 token 數」作為 self-improvement 預算——case passes 才是真正的稀缺資源

• 僅限 Python、單一 target model——跨語言/跨 runtime/跨 agent 架構泛化未測試
• 固定 tasks/splits，反覆回饋可能獎勵針對性策略——未來需引入 per-run jitter
• GAIA seed 是 stub vs 其他三任務是 competent-but-naive——seed 品質影響未系統性變化
• Optimizer 推論 token 不設限 → 結果代表「推理不受限」的上限
• 未測試 optimizer=target 的自我優化場景（最貼近 Hermes 實際情境）