Harness-of-Harness: 具有持续改进能力的多日自主软件开发

TL;DR Harness-of-Harness 将编码代理组织为规划-编码-测试循环，持续改进软件产物，在三个基准上平均提升 52.25%，并能多天迭代出可玩 FPS 游戏。

问题

问题背景

当前 AI 行业正聚焦于自主软件开发：LLM-based coding agents 在无人干预下将高层需求转化为完整可用的软件系统。已有编码代理 harness（如 Codex、OpenCode、Pi）能完成单次任务，但难以支撑多日连续开发与持续改进。

现有方法局限

现有 standalone harness 通常将 agent 执行视为一次性过程，运行一轮“规划-编码-测试”后输出结果，存在明显局限：

• 缺乏跨循环状态管理：代理无法记住历史决策与产出，导致重复劳动或功能回归。
• 无法分离实现时测试与独立评估：代理可能过拟合特定测试来“刷分”，真实软件质量无提升。
• 难以平衡缺陷修复与能力增长：修复缺陷容易，但在修复同时扩展功能、保持架构一致性仍是挑战。
• 产出难以约束为可验证增量：代理常生成大量不可验证或半成品代码，无法累积稳定进展。

为什么这个问题难/重要

自主软件开发要求代理在数天乃至上百次循环中保持稳定、可追踪的改进，这涉及多个技术挑战：

1. 项目规划与增量拆分：需将大目标切成小且可验证的任务块，避免一次性失败。
2. 独立质量保证：评估必须与实现解耦，防止代理用实现时测试作为性能指标。
3. 状态管理与工具暴露：需要逐步交付产物、角色工具与技能，并维护版本化项目历史。

业界对长期自主 agent 的关注日益增长（如 SWE-bench 等基准），但现有 benchmark 多评估单次能力，难以刻画多日持续开发的真实挑战。因此，HoH 所解决的持续改进问题对推动 agent 从“单任务编码”走向“长期自主开发”至关重要。

行业类比

这类似于强化学习中的 self-play 或持续训练范式：让 agent 在环境反馈下反复试错并累积策略改进，而非仅凭一次前向推理完成任务。

核心洞察

• HoH 的核心是一个叠加在现有编码代理 harness 之上的元层控制循环，它通过外部状态管理、版本化项目历史和逐步暴露能力来组织多轮 `planning-coding-testing` 迭代，而不修改底层模型或提示。与直接改进代理反思或工具调用的工作不同，HoH 证明了在编排层面施加结构（如可验证增量、独立 QA）即可带来跨 harness 和模型的稳定提升，表现出较强的通用性和可插拔性。
• HoH 的持续改进关键在于分离修复与能力增长、开发时测试与独立评估，并要求每个循环交付可验证的小型工件。这不同于简单依赖代理自我批评或重复修复的基线：HoH 用外部评估信号约束迭代方向，避免了自我强化偏差，并允许代理在长周期中积累技能和重用组件，从而在三轮内实现平均 52.25% 的相对增益，且在 70 次迭代后能产出完整可玩的 FPS 游戏。

方法

输入与总体架构

HoH 接收高层需求描述，构建在现有 coding-agent harness 之上（如 Codex / OpenCode / Pi），将其单次开发过程组织为多轮 planning-coding-testing 循环。每个循环包含三个核心模块，并通过 跨循环状态管理 传递版本化项目历史、交付物和证据，实现持续改进。

关键模块

1. 项目规划：将原始需求拆分为小而可验证的增量，平衡缺陷修复与能力增长，避免代理陷入局部修补或重复造轮子。
2. 工件开发：向代理渐进暴露角色特定工具与技能，鼓励复用已有代码与组件，而不是从零重写；同时以约束可验证输出（如测试通过、报告格式）代替硬性规定代理工作流，保留灵活性。
3. 独立质量保证：将实现阶段的即时测试与最终独立评估分离，避免代理自己出题自己考导致过拟合；每个循环产出可度量的质量证据，作为下一轮规划的输入。

输出

经过多次循环迭代（如在三个基准上平均相对增益 52.25%），HoH 输出完整、可运行、可持续演进的软件系统，并保留完整版本历史与审计轨迹。

与同类方法的差异点

与 vanilla harness 一次性生成不同，HoH 是元级别的编排层：它不替换底层代理，而是通过循环结构、状态管理和独立评估机制，将任意现有 harness 升级为具备持续改进能力的自主开发系统。

实验

实验设计

HoH 在三个 benchmark 上评估：GameCraft-Bench（游戏开发）、FrontierSWE（仓库级软件工程）、ProgramBench（程序重建）。覆盖三组 harness-model 配对：Codex + GPT-5.5、OpenCode + DeepSeek-V4-Pro、Pi + MiniMax-M3。基线为对应 standalone harness（Vanilla）。HoH 引入 planning-coding-testing 迭代循环，最多 3 次迭代进行质量提升；另有 >70 次迭代的多日 FPS 游戏开发案例。

关键发现

• 三个 benchmark 上 HoH 全部优于 standalone harness，平均相对提升 +52.25%，最大 +82.86%（3 次迭代后）。
• 随迭代轮次增加，软件质量持续上升，FrontierSWE 上持续到第 10 轮仍保持增益。
• 多日部署中，HoH 自主完成一款 FPS 游戏，包含连贯剧情、核心机制、可玩体验、打磨视觉与集成音频。

与基线对比解读

HoH 的收益并非来自更多 raw compute，而是通过 repair 与 capability growth 平衡、小型可验证增量、独立 evaluation 隔离，将 agent 从一次性生成转变为可持续改进的工程流程。相比 Vanilla 的单轮 harness，HoH 用同样的开发轮次得到更高 artifact quality，说明结构化的循环状态管理与约束产出比单纯增加模型调用更有效。对工程实践的直接启示：在 agentic coding 场景下，应当把开发过程切分为可验证的中间产物，并建立版本化历史与证据收集，而非只依赖更强的基座模型。

行业影响

落地场景

HoH 可作为 元 harness 叠加在现有 coding agent 之上，将一次性代码生成转化为多轮自主开发循环。典型场景：

• 电商平台自动开发并持续优化 促销活动微服务：从需求生成可运行代码，通过独立 QA 与用户反馈循环迭代。
• 内容平台自动构建 推荐系统原型：编码代理分小步验证递增功能，不断改进排序模型服务与 A/B 测试工具。

商业价值

直接降低长周期软件项目的 人力成本：HoH 在 GameCraft-Bench、FrontierSWE、ProgramBench 上平均相对提升 52.25%，最高 82.86%，且 70+ 迭代开发出可玩 FPS 游戏，说明可减少人工编码与 QA 投入。同时加速迭代，让软件在开发中持续改善，缩短 Time-to-Market。

现有工作流接口

HoH 不与具体 harness 绑定，而是作为外部编排层集成。可接入：

• 现有 CI/CD pipeline：将 HoH 的 planning-coding-testing loops 作为 pre-merge 质量关卡，产出可验证产物与版本化历史。
• Agent 管理平台：通过统一接口调用 Codex/OpenCode/Pi 等底层 harness，无需改动其内部实现。
• 输出独立评估结果与 project history，便于接入代码仓库/issue tracker，实现可追溯的自主开发。

局限

• **计算与资源开销显著**：HoH 在现有 harness 之上叠加多轮 planning-coding-testing 循环、独立 QA、版本化历史与证据收集，实际 token 消耗与调用次数远高于单次 baseline。论文虽在附录报告资源使用，但未与预算受控的 Vanilla Continuation 做严格成本-收益分析；对于成本敏感或快速迭代的生产环境，额外开销可能限制直接部署。
• **性能受底层模型与 harness 制约**：HoH 是元层框架，不改变 coding-agent 的推理、工具调用或代码生成能力；平衡修复与能力增长的策略高度依赖基座模型能否遵循规划、复用既有模块。实验仅覆盖三组 harness-model 对（Codex+GPT-5.5、OpenCode+DeepSeek-V4-Pro、Pi+MiniMax-M3），在更弱模型或不同工具生态下相对增益可能缩水。
• **评估与真实自主开发仍有差距**：GameCraft-Bench、FrontierSWE 和 ProgramBench 主要依赖自动化可验证指标，强调功能正确性与代码可编译性；对于主观体验（如 UI 美学、叙事连贯性）仅通过单一 FPS 游戏案例做定性分析，缺乏对照。此外，自主开发的‘无人工干预’边界由作者定义，多天任务中的失败恢复、需求漂移和长期可维护性尚未被系统评估。