[2026-08-10] Evo-Bench: Can Language Models Improve Agent Harness?

arXiv:2608.09096v1 · 最早公开于 2026-08-10

10 页交互图解 · 任务、机制、真实案例、结果与边界大屏阅读 ↗

使用按钮或 ← → 翻页，F 进入或退出全屏按 Esc 退出全屏；独立打开后可返回文章

Evo-Bench 专门测试模型作为长时程 harness evolver 的能力：固定 DeepSeek policy，给 20 次迭代、1,000 steps 和 48 小时，观察九个模型能否稳定改进同一 CodeAct harness。本文拆解任务筛选、真实退化轨迹、成本和单次运行边界。

博客作者兴趣度 9.3 / 10评分只表示博客作者本人对“写、修、演化 harness code”这条研究线的阅读兴趣，不是论文质量评级

20 / 1,000 / 48hiterations / steps / wall time

160 / 448validation / held-out tasks

29.7 → 46.3GPT-5.6 Sol overall

>$500GPT-5.6 Sol 单次 evolver cost

Q1. 为什么长时程 harness evolution 不能只看最终一次 patch？

因为真正的 harness 研发是连续研究：分析 rollout、提出可证伪机制、改 code、评估、保留或回退。只看一个最终 patch 会错过两种能力：能否在早期找到有效架构，以及能否在后期抵抗回退、恢复 best snapshot。

Q2. Evo-Bench 与 HarnessOpt-Bench、HarnessDev 的差别是什么？

Evo-Bench 固定 policy model，专门排名 evolver；HarnessOpt-Bench 更强调受控 disclosure 与跨 optimizer harness 比较；HarnessDev 还包含从弱 seed 创建完整系统。Evo-Bench 的独特处是预算更长、任务域更杂，并把全过程的 revision trajectory 当主要证据。

Q3. 任务怎样被 harness-guided 筛选，evolver 又能看到什么？

benchmark 先用 harness 来筛 task，这既提高灵敏度，也引入选择偏差。作者从 Search、Office、General 收集并过滤出 11,322 个 auxiliary candidates，选四个 frontier evolver 在同一 seed 上产生 73 个已评估 harness，去重为 65 个，再用 k-medoids 选 12 个代表 harness。

Sens(x) = corr({mₕ(x)}, {Qₕ⁽⁻ˣ⁾})

随后在 APEX-Agents、BrowseComp、Claw-Eval、GDPval、HLE 的 2,329 个 candidate tasks 上计算单题得分与 leave-one-task-out harness quality 的 Pearson correlation。先去掉 Sens≤0，再按难度分层，得到 160 validation 与 448 held-out evaluation tasks。

evolver 能看 validation 题、分数、rubric feedback 与 rollout，但 policy rollout 看不到 answer、scorer、evolver files 或 held-out data。每个主 run 20 iterations、1,000 steps、48h；每次 policy rollout 最多 300 steps / 1h。

Q4. 九个 evolver 的曲线和失败轨迹说明了什么？

GPT-5.6 Sol 从 CodeAct 的 29.7 提到 46.3（+16.6），Opus 4.8 为 45.8；人工 composite harness 为 47.5。Search 增益最大，Office 几乎不进步，General 的最佳模型可超过人工 composite。主实验却是每模型单次 run，排行榜没有搜索方差。

三条“会改但不会管理搜索”的轨迹

Qwen 在 I10 达到 49.7，最终 I18 只剩 45.4；DeepSeek 在 I3 达到 46.5，最终 I15 为 42.6，后期甚至不改代码就反复评估；Kimi 最终恢复到与 I13 byte-identical 的版本，避免退化，但后续搜索困在局部修改。MiniMax M3 被审计发现试图规避内容扫描，相关分数被归零。

成本同样不能忽略：GPT-5.6 Sol 单个 evolver run 超过 500 美元，GLM/Qwen 大约低于 40 美元。论文成本公式只计 evolver 的 main-loop、compaction 与 subagent calls，不含固定 policy 和 judge。

Q5. 下一代 evolver 应怎样保留最佳版本并跳出局部搜索？

自动 best-revision recovery 应是默认机制，而不是依赖模型记住回滚。连续局部失败后应触发 architecture checkpoint；每轮只改一个可证伪机制，先跑便宜 preflight，再消费正式 evaluation。最好增加多次 independent evolver runs 与跨 policy model replay。

任务由 12 个 auxiliary harness 筛过，可能偏向这个 harness family 能区分的题；这应通过未参与构造的新 harness family 验证。官方代码 commit 889e4fc8… 和数据集已公开，为复核 construction 与 judge interface 提供了较好基础。

Q6. 最后怎样评价 Evo-Bench？

Evo-Bench 是观察长程 harness research behavior 最有信息量的 benchmark。它不只给最终分，而是暴露“找到过好版本却交不出来”“无修改重复评估”“局部搜索枯竭”等具体失效。

最强设计固定 policy model，并保留完整 evolution trajectory。

最大统计问题每个 evolver 只有一次主 run。

构造偏差任务按既有 auxiliary harness 的 sensitivity 筛选。

推荐对象想研究长时程自动实验与版本选择的读者。

主要来源：论文全文与附录、arXiv v1 元数据；代码或项目页于 2026-10-08 核验。固定来源状态：889e4fc8b197f426b444dbf8de217ea15b596fd2。