Harness-of-Harness 把 Coding Agent 的代码版本与验收证据绑在一起
先把 Harness 说清楚。语言模型只负责生成下一步文字；真正让模型查看代码仓库、编辑文件、调用终端、运行测试，再把结果送回模型的外层运行系统，通常叫 Agent Harness。Codex、OpenCode 和 SWE-agent 的差别不只在模型，也在这层系统怎样提供工具、整理上下文和反馈执行结果。
一次修复可以在一个会话里完成，长项目却会跨越多轮甚至多个会话。这里最容易出问题的是代码和证据脱节，而非“下一轮忘了聊天记录”：第一轮测试通过的是版本 A，第二轮改出版本 B 后，旧测试结果已经不能证明 B 仍然可用；如果下一轮只读到“测试通过”，就可能在未经验证的版本上继续开发。
Harness-of-Harness（HoH）是在多次 Harness 运行之外再加一层交付控制。Planner 只负责确定下一轮做什么，Developer 修改代码，系统随后冻结候选版本，只读 QA 针对这个版本运行检查并保存证据；下一轮 Planner 同时读取代码版本和对应的通过、失败记录。它关心“哪个版本经过了什么验收”，不负责协调“几个 Agent 怎么聊天”。
9 月 1 日，上海人工智能实验室团队提交 HoH 论文。研究让三套 Coding Agent 连续开发三轮：Codex + GPT-5.5、OpenCode + DeepSeek-V4-Pro、Pi + MiniMax-M3。它们在 GameCraft-Bench、FrontierSWE 和 ProgramBench 组成的九组实验条件中，最终成绩都高于各自第一轮；作者报告平均相对增幅为 52.25%，最高为 82.86%。
这些数字不能直接证明 HoH 一定更好。三项基准的计分口径不同，52.25% 是跨口径计算的相对增幅；普通 Agent 多跑两轮同样会提高成绩。真正需要比较的是：在相近预算下，把版本冻结、独立验收和证据交接加入流程，是否比同一 Agent 继续修改更可靠。
演进主线： 真实仓库评测解决“代码能不能修” → 工具接口解决“模型怎样操作仓库” → 跨会话记录解决“下一轮怎样接着做” → HoH 再解决“下一轮依据哪个版本、哪份验收证据继续”。
核心判断： HoH 的增量来自代码版本与测试证据的绑定，以及没有写权限的 QA 独立验收，不应归因于简单增加运行轮数。现有消融支持这条证据链有贡献；主实验缺少重复运行和完整开源实现，因此还不能把 52.25% 当作生产收益。
四代方法依次解决任务、接口、状态和验收
HoH 的位置要放回 Coding Agent 四年的演进中看。
每一代方法都在补前一代留下的一个可复现缺口：
| 阶段 | 代表工作 | 新解决的问题 | 仍然缺少什么 |
|---|---|---|---|
| 2023：真实任务 | SWE-bench | 用真实代码库问题代替短代码题，检查补丁能否修复仓库 | 没有统一约束 Agent 怎样看仓库、用终端和接收反馈 |
| 2024：运行接口 | SWE-agent | 证明终端接口与反馈循环会显著改变同一模型的修复成绩 | 多轮、跨会话开发时，现场与进度仍容易丢失 |
| 2025：状态交接 | Anthropic 长时 Agent 实践 | 用进度文件、Git 提交和单次小增量降低会话重建成本 | “做过什么”有记录，“哪个版本已经被谁验收”仍不清楚 |
| 2026：独立验收 | Harness-of-Harness | 冻结候选版本，由只读 QA 生成与版本绑定的证据，再交给下一轮 Planner | 独立复现、重复运行和生产缺陷数据仍不足 |
这条演进线说明，Coding Agent 的评测对象已经从“模型能否生成正确补丁”扩展到“一个持续变化的软件版本能否留下可追责的交付证据”。聊天记录只能保存模型说过什么，代码仓库保存模型改了什么；执行日志、截图、回放和测试结果才说明某个版本是否可用。代码继续变化后，旧测试结果不能继续替新版本背书。
HoH 比普通续跑多出一条版本—证据闭环
HoH 每轮由三个角色接力。
Project Planner 读取需求、当前软件和上一轮证据，只选择一个边界清楚的增量，没有代码写权限。Developer 建立修改前基线、实现功能并运行测试。系统随后冻结候选版本，QA Tester 以只读权限做黑盒与白盒检查，发现问题也不能顺手改代码。
这套分工把“开发者声明完成”和“独立证据证明通过”分成两件事。下一轮 Planner 读取的是与冻结版本绑定的成功项、失败项和执行记录，不是一句“上一轮已经完成”。测试通过后若代码又被修改，新版本必须重新验收。
项目页展示了一次超过 70 轮的第一人称射击游戏开发：系统登记 81 个问题，65 个最终关闭，16 个仍打开，其中 17 个曾在关闭后因后续修改重新打开。问题重开比累计功能数更能说明长程开发风险——新功能会破坏旧功能，而“通过”只对当时的代码版本有效。这段演示证明 HoH 能持续维护问题与回归记录，但尚无外部质量审计，不能据此判断商业软件已经达到交付标准。
同预算对照比“三轮提升 52.25%”更有解释力
GameCraft-Bench 的消融实验把 HoH 的关键环节逐一移除，结果直接回答哪些机制在起作用：
| 三轮运行方式 | 得分 | 相对完整 HoH 的缺口 |
|---|---|---|
| 完整 HoH | 71.52 | 动态规划、证据回传和工作区延续全部保留 |
| 固定第一轮计划 | 63.39 | 后续轮次不能按新证据调整任务 |
| 不向 Planner 回传执行证据 | 65.23 | 下一轮知道做过什么，却不知道哪些检查通过或失败 |
| 每轮清空工作区 | 63.67 | 模型必须重新理解代码状态；token 从 841 万升至 1112 万 |
- 普通 Harness 连续三轮使用 633 万 token，GameCraft-Bench 从 49.58 升至 58.24；
- HoH 三轮使用 841 万 token，得到 71.52。
HoH 多得 13.28 分，也多用 32.9% token，因此“最终分更高”仍混入了计算量影响。
更干净的预算对照来自 HoH 两轮：567 万 token 得到 64.84，计算量低于普通续跑三轮，成绩仍高 6.60 分。这组结果比 52.25% 的跨基准汇总更能支持“证据交接不仅是多跑几轮”。不过主实验每个任务和条件只运行一次，6.60 分是否稳定仍不知道。
与三类 Harness 研究相比，HoH 专门检查跨轮交付
同期研究分别测运行框架的不同层，分数不能直接互比，但可以对齐它们回答的问题：
| 研究 | 核心问题 | 已报告结果 | 对 HoH 的限定 |
|---|---|---|---|
| Harness-Bench | 同一批任务更换运行框架会差多少 | 六种 Harness、八种模型；NanoBot 聚合分 76.2，OpenClaw 52.4 | 模型相同仍不能忽略外层系统 |
| Same Model, Different Harness | 上下文管理会改变多少任务完成数 | Qwen3.6 在 20480 token 下由 43 个增至 72 个；窗口扩大后差距消失 | 某些框架优势只在上下文受限时成立 |
| HarnessDev | 模型能否自己设计 Harness | Opus 4.8 自评 67.8，人类工程系统参考分 86.2；换执行模型后 SWE-Pro 从 69.3 降至 33.0 | Harness 可能与开发它的模型强绑定 |
| Harness-of-Harness | 多轮开发怎样交接版本和验收证据 | 同预算的 HoH 两轮比普通续跑三轮高 6.60 分 | 尚缺重复运行、异构 QA 和生产缺陷数据 |
这组横向对齐给出了清楚边界：Harness-Bench 测整体框架差异，Same Model 检查上下文，HarnessDev 检查自动设计，HoH 检查跨轮交付链。HoH 不替代前三种测试；它补的是“当前版本由什么证据证明可继续开发”。
复现结果将决定它是生产控制还是研究原型
HoH 仍处在 arXiv v1 阶段。
三个角色由同一模型与 Harness 分别调用，可能共享相似盲点。截至 9 月 6 日，GitHub 仍注明 HoH-lite 后续开放，外部团队暂时无法按公开代码完整复制主实验。
下一轮验证应固定总 token 与墙钟预算，让普通续跑和 HoH 各自重复多次，并报告成绩分布。QA 还应分别使用同模型、异构模型、确定性测试器和人工验收，记录持续集成失败、发布后缺陷、问题重开次数和人工验收时长。
如果普通续跑在同预算下达到相近质量，HoH 的收益主要来自额外计算；如果异构 QA 没有减少回归或人工验收时间，角色独立只增加流程开销。只有外部团队稳定复现质量提升，并同时降低发布后缺陷或人工验收成本，HoH 才能从研究原型进入生产开发流程。