代理工程與評測
HarnessOpt-Bench 將代理外殼最佳化變成評測，模型選擇影響約為 coding harness 的 1.8 倍
HarnessOpt-Bench 要求模型在固定評估預算內修改提示、工具、記憶與控制流程，再以不可見測試集計算實際增益。111 組實驗顯示，模型本身造成的差異大於外層 coding harness，但原生工具並未穩定勝出。
代理能力不只取決於權重，也受提示、工具定義、重試策略、記憶及控制流程組成的 harness 影響。8 月 6 日公開的 [HarnessOpt-Bench](https://arxiv.org/abs/2608.06301) 把「讓模型改進另一個代理」定義成受限程式最佳化：最佳化器可修改整個可執行 harness，但不能更換目標模型、環境或驗證器；開發集會提供逐題結果與軌跡，驗證集只公開總分，測試集則由隔離伺服器保管，直到模型提交最終版本才執行。
評測涵蓋 OfficeQA、BrowseComp-Plus、Terminal-Bench 與 GAIA，並限制每個開發、驗證分割最多四次完整 case pass及目標模型 token。研究比較 Claude Opus 5、Claude Sonnet 5、GPT-5.6 Sol、GPT-5.6 Terra、Kimi K3，讓各模型分別透過 OpenCode 與原生 coding harness 工作。111 個計分單元中，固定任務及 harness 後更換模型，normalized gain 平均變動 0.142；固定模型後更換 harness 則變動 0.079，前者約為後者的 1.8 倍。20 組原生與共用 harness 對照中，共用工具勝 11 組、原生工具勝 9 組，沒有普遍的「原廠搭配」優勢。
結果也暴露最佳化器的搜尋瓶頸：觸及提示、上下文、工具 schema、檢索及逾時等更多設計槓桿，與較高增益呈正相關；大量閱讀完整軌跡卻未呈現同樣關係。多數提交版本在隱藏測試集低於搜尋期間看到的最佳驗證分數，說明只回報 validation 峰值會高估自我改進。這呼應 [Lilian Weng 對 harness engineering 的整理](https://lilianweng.github.io/posts/2026-07-04-harness/)：harness 已是可執行的系統設計空間，而非單純提示模板。
工程團隊接下來應關注評測能否加入動態題目、工具行為擾動及成熟生產級 seed。現有 seed 刻意保留大量改進空間，GAIA 起點甚至不可運作；最佳化器自身推論成本也未設上限，因此成績不能直接換算成生產環境的成本效益。