HarnessDev 把评测对象从任务答案换成可运行的 harness：六个模型从弱 seed 创建完整执行系统，再用下游反馈继续演化。本文拆解任务边界、隐藏评测、执行器迁移、真实失败与 2,207 个实例上的结果。
Q1. HarnessDev 为什么把“可运行基础设施”当成新的评测对象？
它要测的是模型能否把一个只规定输入、输出和审计接口的弱 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，而不是一段系统提示词。
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。
Q3. Creation 与 Evolution 到底怎样运行，什么信息被隐藏？
Creation 给 creator 一个弱 seed 与开发环境，完成后冻结 harness；Evolution 再把下游执行反馈交回 creator，让它提交新版本。Creation 覆盖 Code、Data、Writing、Search 四个域和 SWE-bench Pro、Terminal-Bench 2.1、MLE-bench、EQ-Bench3、BrowseComp 五个下游 benchmark。隐藏评测任务不会在开发期出现。
- CREATEcreator 只能改 harness 目录，自己运行 smoke tests。
- FREEZErunner 固定产物，用 creator 自身或统一 Gemini executor 执行。
- OBSERVEEvolution 只看到 feedback pair 的结果和轨迹。
- HOLD OUT630 个 SWE-Pro 实例在结束后一次性评测，不回传。
主分数是各原生 benchmark 指标的非加权平均；Creation 每个 creator 独立构建三次并报告 avg@3。MLE-bench 的 33 个物理 cell 展开为 2,475 次结果，不能把表中每格误读为一条 run。
Q4. 2,207 个实例和真实执行记录说明了什么？
最强 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。
Q5. 如果真要让 Agent 写 harness，最值得补哪几块？
下一步应把 runtime observability、真正的 state persistence 和跨 executor 回归测试变成硬要求。只检查类是否存在，会把 dead code 当能力；更好的 checker 应要求状态写入、恢复和超时路径在正式轨迹中留下证据。每次修改还应同时跑原 executor、替代 executor 与完全未见任务，避免把 feedback gain 当成通用改进。
论文项目页在 2026-10-08 可访问，但没有给出 HarnessDev 的公开代码、任务包或 checker 仓库链接。因此本文能核对论文协议和数字，无法独立重跑隐藏评测或检查每个 task-specific assertion。这一缺口本身应计入 benchmark 的可复现性评价。
Q6. 最后怎样评价 HarnessDev？
这是目前最适合建立“harness coding 全景图”的一篇。它同时给出从零创建、反馈驱动演化、统一 executor、隐藏任务与运行时机制审计；结论也足够克制：模型已经能造出可运行系统，但成熟度、可迁移性和真实状态管理仍不稳定。
主要来源：论文全文与附录、arXiv v1 元数据；代码或项目页于 2026-10-08 核验。固定来源状态：availability checked 2026-10-08; project page exposes the paper but no public HarnessDev code or checker repository。
留言