Harness-of-Harness：面向多日自主软件开发的持续改进框架 Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement
在现有编码智能体外再套规划—编码—测试循环，实现多日自主开发与持续改进
前置知识
Agent Harness（智能体脚手架）
包裹大模型外层的操作层系统，决定模型每一步看到什么上下文、能调用哪些工具、执行结果如何回流进后续决策。Codex CLI、OpenCode、Pi 等编码智能体都是典型 harness，负责管理工具调用循环、文件读写与执行环境。
本文标题 HoH 即「脚手架的脚手架」：它完全不改造底层 harness，而是把整套 harness 当作固定算子反复调用。不先理解 harness 与模型的关系，就无法理解本文的定位与增益来源。
迭代增量开发
经典软件工程方法：把系统构建拆成一连串小而可验证的增量，每个增量既修复遗留问题又交付一个具体新能力，扩展时必须保留已验证行为，使系统始终处于可运行、可测试状态。
HoH 每个循环对应一个「有界且局部完备」的增量，开发文档 $D_t$ 的任务集、保留约束与验收条件设计直接源于该原则，是读懂方法部分的钥匙。
黑盒测试与白盒测试
黑盒测试只通过输入与渲染输出观察产品边界行为、状态转移和端到端流程；白盒测试则检查源码、配置、资源绑定、运行时状态与日志，用于诊断失败和佐证输出无法确定的内部条件。
HoH 的独立 QA 阶段同时使用两类测试，且所有观察必须绑定到冻结候选的证据包上，这是「验收独立于实现」这一核心机制的技术基础。
Shift-left 测试（左移测试）
把测试尽量提前、贴近修改发生的位置：先建立目标行为基线，每次改动后立即复测并检查相邻回归面，使失败在离根因最近的地方暴露，缩短诊断与修复距离。
Developer 角色在实现时内嵌「基线—修改—复测」循环，与之后的独立 QA 形成两级反馈；消融实验和 Fusepoint 案例的 issue 动态分析都依赖理解这一分层测试设计。
上下文窗口与渐进式披露
大模型单次调用可处理的信息量有限，长轨迹中历史会被截断。渐进式披露先把长期产物整理成简短的分类索引，需要时再按需检索详细内容，从而在不设专门记忆模块的情况下维持长程一致性。
HoH 不引入记忆模块，而是把计划、报告、版本化历史存进文件系统并配索引来跨循环传递信息，这是它与带外部记忆的智能体方案的本质差异。
研究动机
现有 LLM 编码智能体大多运行在 human-in-the-loop 模式：开发者要定义任务、引导中间决策、审查改动并在失败时人工干预。即便放开约束做自主开发，长轨迹会带来结构性退化：随迭代累积，模型遗忘早期需求与设计决策，局部修复违反别处的约束；失败尝试与次优决策不断堆积，测试产生的新证据还会推翻先前假设。典型症状包括反复检查—修复的死循环、对已完成组件重复验证、以及在功能缺失或错误时过早宣告完成。论文强调这并非单纯执行时间不够，而是难以在时间中维持连贯有效的进展。数据上，最强的 Codex+GPT-5.5(high) 单次通过（Vanilla）在 GameCraft-Bench 45 个任务上 Overall 仅 49.58 分，FrontierSWE 15 个任务加权奖励仅 0.31、Dominance 44%，距离完整可用软件很远。
本文的目标是本文的目标是让固定的 harness–模型配置 $(M,H)$ 在几乎零人工干预下，从空工作区和一份高层规格 $\mathcal{S}$ 出发，端到端构造出满足功能与质量要求、完整可部署的软件系统，并能在数十乃至上百次迭代中持续改进而非停滞退化。具体分解为三点：其一，把 harness 的单次执行组织成可重复的规划—编码—测试循环；其二，让工件状态与执行证据状态跨循环传递，避免每一轮都从代码反推项目史；其三，全过程不修改任何现有 harness 的内部实现。作者用三个受控基准评测，并用一个跨 70 次迭代、约 6 天、最终产出可玩叙事 FPS 游戏 Fusepoint 的开放案例验证该目标在远超基准规模的时间尺度上依然成立。
与已有工作不同的是，三条相关路线各留下一块空白：AutoHarness、Meta-Harness、Self-Harness 把 harness 代码本身当优化对象，改的是操作层而非项目；MetaGPT、ChatDev 依赖预定义角色工作流，AgileCoder、EvoDev 按冲刺或依赖特性组织增量，EvoMAC 用测试反馈调整多智能体工作流，但都作用在单次有界回合内，不为后续修订保留项目决策、已验证功能与评估证据；现有 coding harness 则完全不管跨回合连续性。HoH 的独特切入是：复用现成 harness 作为固定算子，把改进对象换成演化中的软件项目本身；只约束各角色必须交付的结构化产物（schema 违反即重试）与读写权限，不规定推理与工具序列；并用计划更新、证据反馈、warm-start 三个显式机制解决被忽视的跨循环状态管理难题。
核心方法
直觉上，HoH 是给 harness 再套的一层脚手架：让同一个很强的编码智能体按规划—编码—测试循环反复打磨同一个项目，并把每轮学到的结论带给下一轮。形式化地，给定模型 $M$ 与 harness $H$，HoH 定义端到端映射 $\mathrm{HoH}_{M,H}: \mathcal{S} \mapsto \mathcal{A}$；记 $A_t$ 为第 $t$ 轮后的工件状态（源码、配置、资源），$E_t$ 为对 $A_t$ 评估得到的证据状态（已验证行为、未支撑声明、待修失败），每轮转移为 $(A_{t-1}, E_{t-1}) \xrightarrow{\text{loop } t} (A_t, E_t)$，其中 $E_0=\varnothing$、$A_0$ 为空工作区。实现上，每个循环用同一 harness–模型配置依次扮演 Project Planner、Developer、QA Tester 三个角色；确定性 Runtime 负责冻结各角色输入、强制读写权限、校验输出 schema（违反即重试）并把证据绑定到被测候选；运行期内只有开发文档、工件与证据在演化。
核心创新是三件事的组合。第一，约束可验证产物而非工作流：每个角色必须返回结构化工件，输出不合 schema 就重试，但如何推理、用哪些工具完全由智能体自主，这与 MetaGPT 类固定流程有本质区别。第二，双状态跨循环传递：工件状态 $A_t$ 承载实现，证据状态 $E_t$ 承载已验证知识（该保留什么、什么还没修），两者不可互相替代——只传代码会让下一轮从实现反推项目史，重蹈已知失败的覆辙并回归已验证行为。第三，实现与验收分离：Planner 只读 $A_{t-1}$，把全局规格 $\mathcal{S}$ 与 $E_{t-1}$ 综合成有界且局部完备的开发文档 $D_t$（含任务集、必须保留的行为、可观测验收条件）；Developer 是唯一写者，从 $A_{t-1}$ warm-start 并内嵌基线—修改—复测；QA Tester 只见被冻结的只读候选，用黑盒加白盒测试逐条验收，证据不足一律记为 gap 而非推断为完成。验收权独立于实现声明，是防止自我宣告完成的关键。
方法步骤详情
第 $t$ 轮共三步（Algorithm 1）。第一步规划：$D_t \leftarrow \mathrm{ProjectPlanner}(\mathcal{S}, E_{t-1})$，输入全局规格、上轮证据与只读项目快照 $A_{t-1}$，输出开发文档 $D_t$，定义一组相互关联的小任务、必须保留的已验证行为与可观测验证条件。第二步开发：$A_t \leftarrow \mathrm{Developer}(A_{t-1}; \mathcal{S}, D_t)$，在单写者边界内从上一版工件 warm-start，先为目标行为建立基线，每次有意义修改后复测并检查相邻回归面；开发者自测只用于判断是否可提交候选，不作为验收依据。第三步独立 QA：$E_t \leftarrow \mathrm{QATester}(\mathrm{read\_only}(A_t))$，候选被冻结，按 $\mathcal{S}$ 与 $D_t$ 导出的场景化标准，从功能正确性、完整性、可用性、视听质量逐维度做黑盒与白盒测试，失败与证据不足记入 $E_t$ 传给下一轮；$t=T$ 时返回 $A_T$。
技术新颖性
新颖性体现在四个层面。其一，协议与操作层解耦：不改 Codex、OpenCode、Pi 任何一行实现即可叠加平均 52.25% 的相对增益，说明改进可以建立在 harness 之上而非之内，与改 harness 本身的路线正交。其二，$A_t$ 与 $E_t$ 显式分离且联合传递：消融显示去掉计划更新降 8.13 分、去掉证据反馈降 6.28 分、去掉 warm-start 降 7.85 分且 token 从 8.41M 涨到 11.12M，三个机制缺一不可，证明增益确实来自跨循环状态管理而非多跑几遍。其三，冻结候选加只读验收：每条观察绑定唯一候选身份，禁止跨版本拼凑证据，从制度上杜绝实现者自证完成。其四，用渐进式披露替代记忆模块：计划、报告、版本化历史存文件系统，先给分类索引再按需取详情；多日案例中 17 个回归 issue 携带历史验证记录被重开，使修复回归成为显式规划对象，这是 70 轮不崩坏的关键。
实验结果
HoH 在三基准、三配置上全面超越 Vanilla：GameCraft-Bench（45 任务）三配置 Overall 升至 71.52/48.98/58.78（+21.93/+22.08/+16.62），且逐轮单调上升；FrontierSWE（15 任务）加权奖励升至 0.54/0.31/0.55，Dominance 提升 27/19/29 个百分点，Codex 十轮 Dominance 达 72.67%，Vanilla 仅 27.33%；ProgramBench 通过率升至 66.50/57.56/52.68。三迭代平均相对增益 52.25%，最大 82.86%。等 pass 对照下每档领先 10.13/9.85/13.28 分，HoH@2（64.84 分，5.67M token）超过三遍 Vanilla Continuation（58.24 分，6.33M token）。消融证实计划更新、证据反馈、warm-start 各贡献 8.13/6.28/7.85 分。多日案例 Fusepoint 70 轮产出可玩 FPS，81 个 issue 关闭 65 个、17 个回归重开。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| GameCraft-Bench（45 个 Godot 游戏从零构建任务） | Overall 均分（0–100） | 71.52（Codex+GPT-5.5，HoH@3） | 49.58（同配置 Vanilla 单遍） | +21.93 |
| GameCraft-Bench | Overall 均分（0–100） | 48.98（OpenCode+DeepSeek-V4-Pro，HoH@3） | 26.90（Vanilla） | +22.08（相对提升约 82%，为全文最大相对增益来源） |
| GameCraft-Bench | Overall 均分（0–100） | 58.78（Pi+MiniMax-M3，HoH@3） | 42.16（Vanilla） | +16.62 |
| FrontierSWE（15 任务：4 实现/9 性能/2 研究） | Dominance（对随机竞争配置的平均胜率） | 71%，加权奖励 0.54（Codex+GPT-5.5，HoH@3）；HoH@10 达 72.67% | 44%，奖励 0.31（Vanilla）；10 轮对照基线 27.33% | +27 个百分点（HoH@10 时超基线 45.34 个百分点） |
| FrontierSWE | Dominance | 64%，奖励 0.55（Pi+MiniMax-M3，HoH@3） | 35%，奖励 0.26（Vanilla） | +29 个百分点 |
| FrontierSWE | Dominance | 44%，奖励 0.31（OpenCode+DeepSeek-V4-Pro，HoH@3） | 25%，奖励 0.23（Vanilla） | +19 个百分点 |
| ProgramBench（干净室程序重建） | Avg. Test Pass Rate | 66.50（Codex+GPT-5.5，HoH@3） | 60.41（Vanilla） | +6.09 |
| ProgramBench | Avg. Test Pass Rate | 57.56（OpenCode+DeepSeek-V4-Pro，HoH@3） | 45.27（Vanilla） | +12.29 |
| ProgramBench | Avg. Test Pass Rate | 52.68（Pi+MiniMax-M3，HoH@3） | 35.83（Vanilla） | +16.85（Pi 在 HoH@2 达 53.57 后 @3 微降） |
| GameCraft-Bench（等开发遍数对照，Codex+GPT-5.5） | Overall 均分 / 每任务累计 token | HoH@1/2/3 = 59.71/64.84/71.52 分，2.88/5.67/8.41M token | Vanilla 单遍 49.58 分 2.59M；Continuation 两/三遍 54.99/58.24 分，4.56/6.33M token | 等预算下领先 10.13/9.85/13.28 分 |
局限与改进
作者承认的局限包括：受算力限制基准只采样部分任务（GameCraft-Bench 140 选 45、FrontierSWE 17 选 15），任务数少导致指标方差偏大；token 统计含缓存读取且各 provider 核算不同，只能做配置内比较、无法直接跨家比成本；主实验为控制变量未启用工具、技能与版本控制，与多日案例的完整配置不一致，两条证据链之间有落差。我的补充观察：其一，Pi 在 ProgramBench 上 HoH@2（53.57）到 @3（52.68）小幅回落，说明改进并非处处单调，循环预算 $T$ 需要事先设定而论文未给出自适应停止准则；其二，QA Tester 与 Developer 共用同一模型，验收能力受模型上限约束，GameCraft 评分与 Dominance 这类依赖模型评判或胜率合成的指标本身含噪声；其三，多日案例只有一个项目、无对照基线，人类仅恢复网络与 API 的说法难以完全审计；其四，成本约为 Vanilla 的 3.2 倍（8.41M 对 2.59M token），对预算敏感场景不友好。
独立分析的弱点
独立分析几个弱点并给出改进方向。第一，三角色用同一配置串行调用，成本三倍起步，且 Planner 的长期优先级判断缺乏纠错机制，长程中可能反复误判方向——可引入异构配置：用便宜模型做规划草稿、强模型做实现与验收，或加一个轻量价值模型为候选目标打分。第二，证据状态依赖结构化报告与分类索引，issue 累积到数百条时检索会成瓶颈；Fusepoint 中 17 个回归重开已暴露改动影响分析的缺失——可引入语义检索、显式依赖图，或在 Developer 提交前自动计算改动影响面。第三，缺少对跨模块破坏的提前捕获手段——可用 property-based 测试或轻量形式化契约把已验证行为固化为可执行断言。第四，等 pass 对照只在 Codex 与 GameCraft-Bench 上做，OpenCode 与 Pi 是否同样优于 Vanilla Continuation 未验证，结论泛化性存疑。第五，验收判据大量依赖模型生成的场景化标准，其可靠性与跨运行一致性需要人类标注校准实验支撑，论文未提供。
未来方向
作者提出的方向：把 HoH 推广到更广的真实开发场景——不同类型的游戏与其他软件系统——走向通用的端到端自主软件开发框架。基于其成果可延伸的研究：一是刻画迭代预算 $T$ 与收益的缩放规律，FrontierSWE 上 Codex 十轮仍在涨（HoH@9 达 76.00%），何时饱和、何时回退、能否自适应停止值得系统研究；二是异构多角色与并行多 HoH 实例的协作式开发，把单项目循环扩展为项目群编排；三是把 issue ledger 与回归重开机制抽象成通用证据库，结合向量检索与自动影响分析，解决规模化的状态管理；四是将独立 QA 与形式化验证、property-based 测试结合，把部分验收变成确定性检查；五是做协议增益与模型能力增益的正交分解——本文显示弱模型配置相对增益反而更大（OpenCode 约 82%），可据此预测未来更强模型下编排协议的价值边界。
复现评估
开源情况较好：标题页给出 GitHub 仓库（Flesymeb/HarnessOfHarness）与项目主页，Fusepoint 游戏成品、开发轨迹与游戏视频公开，仓库保留完整 commit 与 issue 历史。复现材料明确：三套 harness 均开源且版本固定——Codex CLI 0.142.5、OpenCode 1.14.30、Pi Coding Agent 0.80.10；模型经 API 调用（GPT-5.5 high、DeepSeek-V4-Pro、MiniMax-M3，多日案例用 GPT-5.6-Sol）。主要障碍是算力与费用：仅 GameCraft-Bench 45 任务 × 每任务 8.41M token 的 HoH@3 就约 3.8 亿 token，三配置三基准全量复现成本相当高；任务采样需按论文的分层随机种子复现（15 个游戏家族各抽 3 个）。难度评估：协议本身只是提示词、Runtime 约束与文件系统约定，代码层面复现难度低；基准评测器需对接各 benchmark 官方脚本，难度中等；多日案例涉及人工搭建的领域技能与工具链，完全复现难度中等偏上。
论文图表
左右对比两种开发模式： 在 human-in-the-loop 模式中，人类观察报错与 bug 后手动重新唤起 coding agent，产品沿概念—原型—产品推进； 在自主软件开发模式中，Harness-of-Harness 内含 Project Planner、Developer、QA Tester，自动完成观察与重唤起，把高层需求独立转化为完整产品。
该图定义了论文的问题设定与雄心：把人类在开发循环中的监督职能移交给编排框架，是理解全文动机与定位的起点。