HarnessOpt-Bench 用固定 seed、target model、环境、verifier 和严格 dev/val/test 边界，把“优化 agent harness”变成可比较实验。本文拆解预算、normalized gain、111 次 scored runs、模型效应与 evaluator 过拟合风险。
推荐阅读 9.4 / 10
01 · OVERVIEWarXiv:2608.06301 · 2026-08-06
把 harness code 本身放进评测与优化循环
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization1 / 10
02 · BOUNDARYarXiv:2608.06301 · 2026-08-06
先分清谁在写代码、谁在执行任务
评测对象
优化者不是最终答题模型。optimizer model 在 coding harness 中改写 target agent；target model、environment 和 verifier 固定。最终要比较的是改后的 harness 在隐藏 test 上相对 seed 捕获了多少剩余 headroom。
核心问题
因为一套 harness 的效果只能通过昂贵、随机的 Agent rollout 间接估计，不能像普通单元测试那样即时判定。 optimizer 必须同时做失败诊断、系统修改、预算分配和候选选择；如果每篇论文使用不同 seed、模型、split 与反馈接口，结果几乎无法横向比较。 HarnessOpt-Bench 固定四件事：初始 harness、target model、执行环境、verifier。优化者只能改 harness code，不能换模型或测试规则。这样才把“更强的被测 Agent”和“更会优化 harness 的 optimizer”分开。
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization2 / 10
03 · LOOParXiv:2608.06301 · 2026-08-06
一条稳定的因果链：证据 → 修改 → 评测 → 冻结
1失败证据
从任务、轨迹或运行状态定位问题。
2修改 harness
改 prompt、tools、control flow、memory 或 verifier。
3执行评测
在固定模型与环境中运行候选。
4冻结与泛化
选择版本并在未见任务上检查。
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization3 / 10
04 · NUMBERSarXiv:2608.06301 · 2026-08-06
四个数字先建立结果量级
111scored optimization runs
0.142 vs 0.079optimizer model effect vs coding-harness effect
11 : 9shared vs native harness pair wins
82%中位 case-pass 配额消耗
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization4 / 10
05 · RELATEDarXiv:2608.06301 · 2026-08-06
相邻工作的边界决定分数能否比较
Q2. 它与 VeRO、Meta-Harness 和普通 coding benchmark 差在哪？
VeRO 提供外层实验基础设施，Meta-Harness 提出具体搜索法；HarnessOpt-Bench 把问题固定成统一赛道。 它又不同于 SWE-bench：patch 的效用不是确定性测试，而是多次随机 rollout 的均值；反馈成本本身就是问题的一部分。 四个任务是 OfficeQA、BrowseComp-Plus、Terminal-Bench 2.0 与 GAIA。前三个 seed 是能工作的朴素 agent；GAIA seed 是不可运行 stub，所以 GAIA 测的更像从零造 agent，不能和“优化一个可用 seed”无条件合并。
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization5 / 10
06 · PROTOCOLarXiv:2608.06301 · 2026-08-06
真正的协议藏在可见与隐藏信息之间
协议与信息边界
dev 暴露逐例输入、结果与 trace；validation 只暴露 aggregate score；test 在最终 nomination 前完全不可见。 每个分区最多 100 次 evaluation calls，dev/val 各最多四个 full case passes，另有 target-token cap。optimizer 推理 token 被计量但未封顶。 g = (E(H⁺) − E(H₀)) / (1 − E(H₀)) 这里的 normalized gain 表示拿回了 seed 上方多少剩余空间；负值表示最终候选比 seed 更差。seed 与最终 candidate 都对每个 test case 跑三次。每个 optimizer configuration 只重复两轮，因此表中 range 是观测范围，不是置信区间。 具体执行链是：optimizer commit 候选 → 选择 dev/val cases → trusted service 在隔离 sandbox 运行 → 按 disclosure policy 返回 trace 或 aggregate → optimizer nominate 一个 commit → server 一次性跑隐藏 test。
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization6 / 10
07 · RESULTSarXiv:2608.06301 · 2026-08-06
主结果之外，更重要的是版本怎样失败
结果怎么读
optimizer model 的影响比外层 coding harness 更大，但两者都没有稳定赢家。 平衡子集里，更换 optimizer model 的平均效应为 0.142 gain units；更换 coding harness 为 0.079，约小 1.8 倍。20 个 model-task 对中 shared OpenCode 赢 11 次，native harness 赢 9 次。 更广的 intervention breadth 与 gain 正相关，但它和修改量混杂，不能直接解释成“改得越多越好”。更反直觉的是，111 个 scored cells 中只有 7 个使用 detailed trace，共 16 次，且没有观察到收益关联。optimizer 通常不是被 100 次 API call 卡住：中位只用了 8 次调用，却吃掉 82% 的 case-pass allowance。 一个可复核的预算例子 OfficeQA split 为 49/98/99，seed 0.341；BrowseComp-Plus 为 33/66/66，seed 0.462；Terminal-Bench 为 17/36/36，seed 0.241；GAIA 为 33/66/66，seed 0。一个 full validation pass 因而一次消耗整个 val case allowance 的四分之一，解释了为什么“评多少个案例”比“调多少次接口”更先绑定。
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization7 / 10
08 · EVIDENCEarXiv:2608.06301 · 2026-08-06
哪些结论成立，哪些还没有被证明
证据支持
optimizer model 的影响比外层 coding harness 更大，但两者都没有稳定赢家。 平衡子集里，更换 optimizer model 的平均效应为 0.142 gain units；更换 coding harness 为 0.079，约小 1.8 倍。20 个 model-task 对中 shared OpenCode 赢 11 次，native harness 赢 9 次。 更广的 intervention breadth 与 gain 正相关，但它和修改量混杂，不能直接解释成“改得越多越好”。更反直觉的是，111 个 scored cells 中只有 7 个使用 detailed trace，共 16 次，且没有观察到收益关联。optimizer 通常不是被 100 次 API call 卡住：中位只用了 8 次调用，却吃掉 82% 的 case-pass allowance。 一个可复核的预算例子 OfficeQA split 为 49/98/99，seed 0.341；BrowseComp-Plus 为 33/66/66，seed 0.462；Terminal-Bench 为 17/36/36，
不能外推
最需要补的是更多 optimizer replicate、动态 target model 与对 evaluator artifact 的抗过拟合检查。 两次重复不足以估计长程搜索的方差；每任务只固定一个 target model，也无法判断修改是否迁移。可以加入交叉 evaluator、隐藏 prompt mutation 与跨模型 replay。 论文没有链接独立公开仓库；截至 2026-10-08，Scale Research 索引也未给出可下载的完整 seed、server 和 checker artifact。因此协议设计可以审阅，独立复现仍受限。尤其 GAIA stub 与三个 competent seeds 应分榜报告。
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization8 / 10
09 · NEXTarXiv:2608.06301 · 2026-08-06
下一轮实验应该补什么
Q5. 怎样把这个 benchmark 做得更可靠、更难作弊？
最需要补的是更多 optimizer replicate、动态 target model 与对 evaluator artifact 的抗过拟合检查。 两次重复不足以估计长程搜索的方差；每任务只固定一个 target model，也无法判断修改是否迁移。可以加入交叉 evaluator、隐藏 prompt mutation 与跨模型 replay。 论文没有链接独立公开仓库；截至 2026-10-08，Scale Research 索引也未给出可下载的完整 seed、server 和 checker artifact。因此协议设计可以审阅，独立复现仍受限。尤其 GAIA stub 与三个 competent seeds 应分榜报告。
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization9 / 10
10 · VERDICTarXiv:2608.06301 · 2026-08-06
带着边界读结论，才不会把局部改进说成自我进化
最终判断
这是这组论文里实验控制最值得借鉴的一篇。 它没有发明新的 optimizer，却把 fixed target、分层 disclosure、不可见 test 与向量预算讲清楚了，也用负结果纠正了“native harness 必然更好”“详细 trace 必然有用”这类直觉。 强项 变量拆得干净，预算与信息边界明确。 弱项 每配置只有两次 optimizer replicate，且代码尚未公开。 最重要发现 真正先耗尽的是 case passes，不是 evaluation call 数。 阅读建议 先看协议和 Table 3，再读 model/harness effect。
阅读位置
这篇在整个系列中的兴趣度为 9.4/10。先看任务边界，再看真实修改与隐藏评测，最后回到限制。
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization10 / 10