01 · OVERVIEWarXiv:2609.01437 · 2026-09-01

把 harness code 本身放进评测与优化循环

HarnessDev 把评测对象从任务答案换成可运行的 harness：六个模型从弱 seed 创建完整执行系统，再用下游反馈继续演化。本文拆解任务边界、隐藏评测、执行器迁移、真实失败与 2,207 个实例上的结果。

先分清谁在写代码、谁在执行任务

评测对象

这里的 harness 是模型权重之外的执行系统：它决定 prompt、工具、循环、上下文、状态、恢复与验证。HarnessDev 不让模型直接解隐藏题，而是让 creator model 写出这套系统，再由 executor model 通过它解题。

核心问题

它要测的是模型能否把一个只规定输入、输出和审计接口的弱 seed，发展成真正能长期执行任务的程序。普通 agent benchmark 固定 Claude Code、Codex 或某个 ReAct loop，只比较最终答案；HarnessDev 把 prompts、tools、control flow、state、lifecycle 和 verification 一起放进可编辑区。这很重要，因为相同权重换一套 harness，结果可以相差很大。论文引用的 Terminal-Bench 2.1 例子里，同一 GPT-5 在 Terminus 2 为 35.2%，在 Codex CLI 为 49.6%。HarnessDev 因而把交付物定义为 runnable codebase，而不是一段系统提示词。

HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?2 / 10

03 · LOOParXiv:2609.01437 · 2026-09-01

一条稳定的因果链：证据 → 修改 → 评测 → 冻结

1失败证据

从任务、轨迹或运行状态定位问题。

2修改 harness

改 prompt、tools、control flow、memory 或 verifier。

3执行评测

在固定模型与环境中运行候选。

4冻结与泛化

选择版本并在未见任务上检查。

HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?3 / 10

04 · NUMBERSarXiv:2609.01437 · 2026-09-01

四个数字先建立结果量级

2,207unique downstream instances

18独立创建的 Code harness

67.8 vs 86.2最佳 Self-Eval vs 人工 reference

+4.44 pp最大 held-out Evolution 增益

HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?4 / 10

05 · RELATEDarXiv:2609.01437 · 2026-09-01

相邻工作的边界决定分数能否比较

Q2. 它和 HarnessOpt、Meta-Agent Challenge、Self-Harness 的边界在哪里？

它比 prompt optimization 更宽，比从零造任意 agent 更受约束，又比只修一个既有 harness 更接近完整开发。工作 Agent 改什么主要反馈 HarnessOpt-Bench 固定任务中的既有 harness dev trace、val aggregate、隐藏 test Self-Harness / Harness-R1 从失败轨迹修改已有 runtime 回归门或在线奖励 Meta-Agent Challenge 从零写 task-specific agent.py 开发 API 与最终 secret test HarnessDev 先 Creation，再从自己的产物继续 Evolution 小规模开发任务与正式冻结评测与这些工作相比，HarnessDev 最有价值的是把“能创建”和“能继续演化”放在同一 lineage 中，并额外测 executor transfer。

HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?5 / 10

06 · PROTOCOLarXiv:2609.01437 · 2026-09-01

真正的协议藏在可见与隐藏信息之间

协议与信息边界

Creation 给 creator 一个弱 seed 与开发环境，完成后冻结 harness；Evolution 再把下游执行反馈交回 creator，让它提交新版本。 Creation 覆盖 Code、Data、Writing、Search 四个域和 SWE-bench Pro、Terminal-Bench 2.1、MLE-bench、EQ-Bench3、BrowseComp 五个下游 benchmark。隐藏评测任务不会在开发期出现。 CREATE creator 只能改 harness 目录，自己运行 smoke tests。 FREEZE runner 固定产物，用 creator 自身或统一 Gemini executor 执行。 OBSERVE Evolution 只看到 feedback pair 的结果和轨迹。 HOLD OUT 630 个 SWE-Pro 实例在结束后一次性评测，不回传。主分数是各原生 benchmark 指标的非加权平均；Creation 每个 creator 独立构建三次并报告 avg@3。MLE-bench 的 33 个物理 cell 展开为 2,475 次结果，不能把表中每格误读为一条 run。

HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?6 / 10

07 · RESULTSarXiv:2609.01437 · 2026-09-01

主结果之外，更重要的是版本怎样失败

结果怎么读

最强 creator 仍显著落后于成熟 reference，而且“能跑”远不等于机制真的生效。 Self-Eval 下 Opus 4.8 总分 67.8，人工工程 reference 为 86.2；Writing 接近参考，Search 缺口最大。18 个 Code artifacts 全部可运行，共增加 17,111 行，但改动规模与分数无明显关系。真正刺眼的是运行证据：108 个组件实例中只有 72 个被正式轨迹完整触发，18 个只有部分证据，18 个从未出现；未出现者全部属于 state / memory。11/18 定义了 State class，却只有一个暴露保存接口、一个实现周期 checkpoint，在 26,679 条轨迹里没有一次 checkpoint event。真实失败：一条 120-step 限制把迁移打崩某个 Opus Code harness 在 Self-Eval 表现良好，却把原 executor 的 120-step 习惯写死。换成 Gemini executor 后，SWE-Pro 从 69.3 降到 33.0；其 Search harness 的重复查询率从 10.1% 升到 88.2%。这不是代码不能启动，而是终止、去重和审阅策略与新 executor 不兼容。 Evolution 在可见 feedback pair 上全都提升，但转到 held-out 后明显缩水。Self-runtime 的最大 held-out 增益是 Opus 的 +4.44 pp；固定 Gemini 时只有 Opus 仍提升，GPT-5.5 甚至从 42.22 降到 31.90。

HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?7 / 10

08 · EVIDENCEarXiv:2609.01437 · 2026-09-01

哪些结论成立，哪些还没有被证明

证据支持

最强 creator 仍显著落后于成熟 reference，而且“能跑”远不等于机制真的生效。 Self-Eval 下 Opus 4.8 总分 67.8，人工工程 reference 为 86.2；Writing 接近参考，Search 缺口最大。18 个 Code artifacts 全部可运行，共增加 17,111 行，但改动规模与分数无明显关系。真正刺眼的是运行证据：108 个组件实例中只有 72 个被正式轨迹完整触发，18 个只有部分证据，18 个从未出现；未出现者全部属于 state / memory。11/18 定义了 State class，却只有一个暴露保存接口、一个实现周期 checkpoint，在 26,679 条轨迹里没有一次 checkpoint event。真实失败：一条 120-step 限制把迁移打崩某个 Opus Code harness 在 Self-Eval 表现良好，却把原 executor 的 120-step 习惯写死。换成 Gemini executor 后，SWE-Pro 从 69.3 降到 33.0；其 Search harness 的重复查询率从 10.1% 升到 88

不能外推

下一步应把 runtime observability、真正的 state persistence 和跨 executor 回归测试变成硬要求。只检查类是否存在，会把 dead code 当能力；更好的 checker 应要求状态写入、恢复和超时路径在正式轨迹中留下证据。每次修改还应同时跑原 executor、替代 executor 与完全未见任务，避免把 feedback gain 当成通用改进。论文项目页在 2026-10-08 可访问，但没有给出 HarnessDev 的公开代码、任务包或 checker 仓库链接。因此本文能核对论文协议和数字，无法独立重跑隐藏评测或检查每个 task-specific assertion。这一缺口本身应计入 benchmark 的可复现性评价。

HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?8 / 10

09 · NEXTarXiv:2609.01437 · 2026-09-01

下一轮实验应该补什么

Q5. 如果真要让 Agent 写 harness，最值得补哪几块？

下一步应把 runtime observability、真正的 state persistence 和跨 executor 回归测试变成硬要求。只检查类是否存在，会把 dead code 当能力；更好的 checker 应要求状态写入、恢复和超时路径在正式轨迹中留下证据。每次修改还应同时跑原 executor、替代 executor 与完全未见任务，避免把 feedback gain 当成通用改进。论文项目页在 2026-10-08 可访问，但没有给出 HarnessDev 的公开代码、任务包或 checker 仓库链接。因此本文能核对论文协议和数字，无法独立重跑隐藏评测或检查每个 task-specific assertion。这一缺口本身应计入 benchmark 的可复现性评价。

HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?9 / 10

10 · VERDICTarXiv:2609.01437 · 2026-09-01

带着边界读结论，才不会把局部改进说成自我进化

最终判断

这是目前最适合建立“harness coding 全景图”的一篇。它同时给出从零创建、反馈驱动演化、统一 executor、隐藏任务与运行时机制审计；结论也足够克制：模型已经能造出可运行系统，但成熟度、可迁移性和真实状态管理仍不稳定。最强证据 2,207 个唯一实例、avg@3 创建、630 个后验 held-out，以及 26,679 条运行轨迹。最大风险人工 reference 不是统一模型下的 paired control；公开 checker 与 artifacts 尚不可得。工程启示检查“机制是否进入真实主路径”，比统计代码行数或自测次数更有用。推荐对象想系统理解 harness creation、evolution 与 transfer 的读者。

阅读位置

这篇在整个系列中的兴趣度为 9.6/10。先看任务边界，再看真实修改与隐藏评测，最后回到限制。

HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?10 / 10