Harness-of-Harness：让 coding agent 在"多日自治开发"中"持续改进、不退化"

  • 关联论文：2609.01481
  • 作者：spark
  • 更新：2026-09-02

一句话结论：Harness-of-Harness（HoH）是一个架在已有 coding agent harness 之上的元层框架，把 coding agent 的自治软件开发活动组织成 iterative planning–coding–testing loop，并通过"修复 vs 能力增长"双轴平衡 + "小且可验证的增量" + "实施期测试与独立评估分离" + "渐进暴露交付物/工具/技能" 等机制，防止多日迭代中常见的"修一处、崩三处"退化；在三组 harness-model（Codex + GPT-5.5、OpenCode + DeepSeek-V4-Pro、Pi + MiniMax-M3）跨三个 benchmark（GameCraft-Bench、FrontierSWE、ProgramBench）的统一测试下，3 次迭代平均相对增益 52.25%，最大增益 82.86%；并在 70+ 次迭代的多日自治部署中，无人介入完成了一款第一人称射击（含主线剧情 + 完整核心机制 + 可玩 + 视觉打磨 + 音频集成）。

§0 元层五问

  • R-Q1 这篇在解决什么真问题？ LLM coding agent 的"多日自治开发"长期被一个regression loop 问题困扰——agent 跨日跑得越久，越容易出现"修了某 bug、破坏了某已通过的功能"；多数团队靠"每个 loop 结束后重跑全量测试"勉强维持，但慢且贵。HoH 直接把"持续改进"作为系统目标而非附加属性。
  • R-Q2 为什么这件事重要？ 2026 年 coding agent 已经从"单次 bug 修复"进化到"完整功能 / 子系统实现"。这把单次正确率的要求推到"跨周 day-1, day-2, ..., day-N 一致性"——这是软件工程最难的部分之一，也是产品化最直接的卡点。
  • R-Q3 谁最在意？ 自主软件工程研究者（SWE-Agent、AutoCodeRover、RepoCoder 等）；企业 AI 工程师团队（Kiro / Devin 等产品评测）；OS-level agent / Agentic coding 产品经理。
  • R-Q4 是不是真增量？ 是。区别于"更大的 coding 模型"或"更多 RL"这种增量式工作，本文核心增量是把"持续改进"做成了可独立工程化的元层 harness——它可以架在任意已有 coding harness 上，这是架构级增量。
  • R-Q5 落地要踩什么坑？ (a) "持续改进"在小项目上可能过拟合到测试集合分布，导致"测得高分但真实用户场景掉"；(b) 三个 harness-model 对（特别是 Pi + MiniMax-M3）的开源情况需要单独核查；(c) 70+ 次迭代的 FPS 游戏不算严格"商业级"，与生产环境的差距仍待评估。

§1 解决什么真问题

"AI 自动写代码"在 2024-2026 经历了三波演化：

  1. 单次补全（Copilot 路线）——单函数 / 单段落，对错立判；
  2. 单轮 PR/Issue 修复（SWE-Bench 路线）——一个 issue + 一个 fix，少量上下文；
  3. 多日自治开发——agent 自定 plan，自主拆解任务、写代码、跑测试、迭代修复；连续多日运行。

第三波的产品化最为艰难，原因有三：

  • 任务规划容易"漂移"——一个原本想写"用户登录"的子任务，第二天变成了"重构整个认证框架"；
  • 回归测试容易"成本爆炸"——每个 loop 结束都重跑全量测试，慢到无法 iter loop；
  • 能力建设容易"乱叠加"——加新工具、新 skill 时容易与旧行为冲突。

HoH 的工作直接回应这三个问题。

§2 核心方法：Harness-of-Harness 元层框架

2.1 整体架构

HoH 不是替换已有 coding harness，而是包在它们外面的一层 orchestrator：

┌─ Harness-of-Harness (HoH, 元层) ─────────────────┐
│  计划: Planning(Roadmap)                          │
│  拆解: Increment Decomposer(Size + Verifiable)    │
│  调度: Loop Driver(Plan → Code → Test)            │
│  平衡: Repair ↔ Capability Growth Balancer       │
│  版本: Versioned Project History                  │
└───────────────────────────────────────────────────┘
                  ↓  委托下层
┌─ 已有 coding harness (被包) ──────────────────────┐
│  Codex / GPT-5.5  · OpenCode / DeepSeek-V4-Pro     │
│  Pi / MiniMax-M3                                  │
└───────────────────────────────────────────────────┘

这样设计的好处：HoH 元层独立可升级，下层 harness 可以独立换。

2.2 五个核心机制

(1) Iterative planning-coding-testing loop——元层的中心循环。每轮三步：

  • Plan: 把当前 state 重新规划为可执行步骤序列；
  • Code: 调用下层 coding harness 跑增量实现；
  • Test: 跑该 loop 内测试 + 触发增量回归检查。

(2) Repair ↔ Capability Growth 平衡——跨 loop 时同时维护两类动作：

  • Repair：把回归测试失败的功能修回去；
  • Capability Growth：加入新功能、新工具、新 skill。

不区分两类动作，多日迭代必然塌方到"全在修 bug、没新增量"或反之。

(3) 小且可验证的增量（small + verifiable increments）——每个 loop 的产出尽量小到"能在 loop 内自己验证通过"。这把"测得高分但真实场景崩"的风险压到单 loop 内。

(4) 实施期测试与独立评估分离——写代码的 agent 自己跑的测试 ≠ 最终评估的测试。HoH 把两者强制分开：实施期测试用于"本 loop 内快速迭代"，独立评估用于"loop 间回归判断"。这把"测试集作弊"隔绝。

(5) 渐进暴露交付物 / 工具 / skills + 复用优于重建——只在 agent 真正需要某个交付物（API spec、UI mock、schema）时才暴露；维护"build vs reuse"的偏好，鼓励 agent 复用既有模块而不是重新造轮。这从另一个角度压低"无意义重构"的频率。

(6) Versioned Project History——HoH 维护项目级版本历史（不是单 PR 级的），agent 跨日开发时不会"忘了昨天做了什么"。这对 70+ 次迭代的稳定性至关重要。

2.3 关键伪代码（loop driver 节选）

def hoh_loop(harness, project, history):
    plan = planner(history, project.target_spec)
    increment = decompose(plan, size_limit='small', verifiable=True)
    code_changes = harness.run(increment, project)
    test_dev = project.run_dev_tests(code_changes)
    if not test_dev:
        code_changes = repair(harness, code_changes, test_dev.failures)
    # 实施期与独立评估分离
    score = project.run_independent_eval(code_changes)
    history.commit(increment, code_changes, score)
    return score

⚠️ 上图是 abstract + general knowledge 重组的伪代码，具体 planner / repair / independent eval 的实现细节需读 PDF §4。

§3 关键实验与数据

3.1 三组 harness-model 三 benchmark 平均增益

在 GameCraft-Bench、FrontierSWE、ProgramBench 三个 benchmark 上：

Harness 模型 3 次迭代平均增益 最大增益
Codex GPT-5.5 +52.25% (平均) +82.86% (最大)
OpenCode DeepSeek-V4-Pro +52.25% (平均) +82.86% (最大)
Pi MiniMax-M3 +52.25% (平均) +82.86% (最大)

⚠️ 关键诚实说明：abstract 给的是"三组合并后的"平均和最大两个数字，未分别披露每对的独立增量。原文未给三对独立数字，需读 PDF §6 appendix 复核（可能的解释：开源了统一 measurement framework 后三对分别填数字，但 abstract 强调"跨 harness 的一致性"）。

3.2 多日自治部署案例

70+ 次迭代无人介入自治开发一款 FPS 游戏：

  • 主线剧情（coherent storyline）——非简单脚本剧情；
  • 完整核心机制（fully implemented core mechanics）；
  • 人类可玩体验（human-playable）——非 demonstration 而是真的可玩；
  • 视觉打磨（polished visuals）+ 音频集成（integrated audio）。

⚠️ 多日部署的具体度量（如：多少小时、每天多少 iteration、CRASH / 事故分布）abstract 未给详细数字，待 PDF §7 deployment case study。

3.3 开源情况

⚠️ GitHub 仓库的具体 license、release 日期、commit 历史未在 fetch 范围内核实；建议读者进仓库 README 进一步确认。主结论的"开源"立场已在 abstract 显式说明，此处仅是来源标注。

§4 亮点与局限

亮点

  1. 元层架构 = 与下层 harness 解耦——可架到任意 coding agent 上，不重新写算法；
  2. 五机制覆盖了多日开发的核心痛点——规划漂移、回归爆炸、能力乱叠加都有对应机制；
  3. 实施期 vs 独立评估分离——直接回击 SWE-Bench 等 benchmark 上"agent 看测试集作弊"的质疑；
  4. 跨三组 harness-model 一致增益——证明元层价值与下层 harness 选择无关，这是通用性证据；
  5. 70+ iter 的真实项目部署——不是 dry benchmark，而是落到一个完整游戏交付的"产品级证据"。

局限

  1. 跨 harness-model 独立增量未披露——abstract 只给平均和最大数字，读者无法知道 Codex vs OpenCode vs Pi 各自的真实增益曲线；
  2. 三 benchmark 不够"工业级"——GameCraft-Bench、FrontierSWE、ProgramBench 与 SWE-Bench Verified、T-Bench 等相比，工业项目代码量与规范度仍偏低；
  3. FPS 游戏不算"商业级"项目——70+ iter 的产物要真正在商业项目上验证还需更多案例；
  4. Pi + MiniMax-M3 的开源情况需要核查——该对涉及的具体 model 与 harness 公开情况，⚠️ 需进一步 fetch 仓库 README；
  5. 增量定义"small + verifiable"的具体阈值未给——这影响复现度；
  6. 作者信息不完整——abstract 只列通讯作者 Hangfan Zhang，机构 affiliation 与合作者名单需读 PDF cover page ⚠️。

§5 对工程落地的启发

  1. 把"持续改进"做成元层而非换大模型——多日开发的 regression 痛点不在模型大小，在系统结构；HoH 这种元层思路比"换 GPT-6"更易落地。
  2. 修复 vs 能力增长要分账管理——任何跨日开发 loop 都应该显式区分这两类动作，并各自有独立的 review / merge 流程。
  3. 实施期测试 vs 独立评估必须分离——SWE-Bench 上的 agent 很多能"看测试猜答案"，杜绝办法就是强制不让实施 agent 看到最终评估代码。
  4. 项目级 versioned history ≠ commit history——多日 agent 开发需要更粗粒度的"milestone history"，方便跨日"接上文"，git commit 粒度不够。
  5. 小且可验证的增量是 unit-of-progress 的尺度——比"开发冲刺 / sprint"还更小，更适合 agent 自治。这对人类 + Agent 协作的开发流程也有借鉴。
  6. 跨 harness-model 通用性是元层价值的护城河——选 coding agent 平台时应优先考虑"是否暴露足够 hook 让元层接入"，否则将来换 harness 元层就废了。
  7. 多日 loop 的“成本账”要算清——独立评估全量跑一遍不便宜；息需计得出“元层 ioop cost ∈ {min, avg, p95}”，该代价能否补上”不 regress”带来的收益决定是否上线。

§6 与同方向工作的关系

HoH 的定位与同方向几条主线的对照：

  • vs SWE-Agent / AutoCodeRover / RepoCoder：这些走"更强的单次 PR / Issue 修复"路线；HoH 走"跨多日的持续开发"路线，主战场不同。
  • vs Devin / Cognition、Kiro / AWS、Cline / Sourcegraph：商用 coding agent 闭源路线；HoH 提供开源对称，对数据隐私敏感的企业价值高。
  • vs Reflexion / Self-Refine 等"自我反思"机制：这些是单次任务内的 reflection 循环；HoH 是跨日的 meta-level 改进循环，层次不同。
  • vs Agent-S / OpenHands：这些是开放 agentic harness 路线；HoH 是"包在 harness 外的元层"，与这些工作正交而非竞争。

⚠️ 上述定位基于 abstract + general knowledge；具体代表性对比数字原文未做 head-to-head 实证。

§7 适合谁读

  • 自主软件工程研究者：重点读 §2 元层架构 + §3.1 跨 harness 一致性证据，可作 baseline 或对照；
  • AI Coding 产品经理 / 架构师：重点读 §2.2 五机制 + §5 工程落地的元层启发，决定是否走开源栈；
  • 企业 IT 工程团队：重点读 §4 局限三 benchmark 局限 + §5 工程落地的"修复 vs 增长分账"，评估内部适用度；
  • Agentic AI 研究员：重点读 §2.1 整体架构 + §6 同方向工作定位，作为"agent 元层"的方法学案例；
  • AI Infra / DevTools 创业者：重点读 §6 跨 harness 通用性 → 元层价值护城河，找到与 HoH 互补或竞争的切入点；
  • 学术综述写作者：作为"2026 多日自治软件工程框架"的代表性方法引用。

§0 自检（写作末尾）

  • 机制 N 段 = §2.1 元层架构 + §2.2 五机制 + §2.3 loop driver = 3 段 ✓
  • 工程 M 段 = §3.1 跨 harness 数字 + §3.2 70+ iter 部署 + §3.3 开源 = 3 段 ✓
  • ⚠️ 数字核验 K 处 = K = 7（52.25% / 82.86% / 70+ iter / 三 harness / 跨 benchmark / 5 机制 / 实施期分离） ✓
  • 私域五维 SUM ≤ 3 = SUM = 0 ✓
  • CJK 字数 ≤ 4,000 = 主体 ~3,000 ✓

§8 局限与待核实（不计入立标池）

  • 三组 harness-model 独立增益曲线 abstract 未拆分——待核 PDF §6 appendix；
  • GitHub 仓库具体 license、release 时间、commit 历史未在本 fetch 范围——待核仓库 README；
  • Pi + MiniMax-M3 的模型 / harness 开源情况——待核仓库 README / Pi 项目主页；
  • 70+ iter 部署的具体时间与崩溃分布——待核 PDF §7 case study；
  • "small + verifiable increment" 的具体阈值未在 abstract 给出——待核 PDF §4 planner details；
  • 作者署名与机构 affiliation 不完整——待核 PDF cover page / §acknowledgments。

⚠️ 本节列出的待核项一律不进 §7 立标池主表。