Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement

一句话概括

本文提出 Harness-of-Harness（HoH）框架，通过在多轮“规划—编码—测试”循环中持续暴露交付物、工具与技能，让现有 LLM 编码智能体在无需人类干预的情况下，于数天乃至数十轮迭代中自主开发出完整、可玩且持续改进的软件系统。

问题背景

当前基于大语言模型的编码智能体（如 Codex、OpenCode 等）已经能完成单轮或少量轮次的编程任务，例如修复一个 issue、实现一个函数。但真正的“自主软件开发”远不止于此：它要求智能体从一份高层需求出发，独立完成架构设计、模块拆分、代码编写、测试验证、缺陷修复，甚至视觉与音频资源的整合，最终交付一个人类可以直接使用的软件。

现有编码智能体框架（论文中称为 harness）大多面向“单次任务”或“有限轮次修复”设计，缺乏一种机制让智能体在长时间、多轮迭代中持续改进自身产出。常见问题包括：智能体在修复一个 bug 时可能引入新问题；反复重写已有模块而非复用；测试与评估混为一谈导致“自欺欺人”；缺乏对项目历史版本的管理，导致无法回退或追踪进展。简而言之，现有 harness 擅长“完成一个点”，但不擅长“持续推进一个面”。

方法要点

HoH 的核心思想并非重新发明一个编码智能体，而是作为一个“元框架”叠加在现有 harness 之上，将其执行过程组织为迭代的“规划—编码—测试”循环。其关键设计原则可归纳为四点：

第一，平衡修复与能力增长。每一轮循环不仅修复上一轮发现的问题，还要引入新的功能或技能，避免智能体陷入“只修不建”的局部最优。

第二，将开发范围切分为小而可验证的增量。每次迭代只处理一个可独立测试的模块或功能，而不是试图一次性生成整个系统，从而降低出错半径并便于定位问题。

第三，将实现期测试与独立评估分离。开发过程中使用的测试（如单元测试）用于指导编码，而独立的评估标准（如端到端功能检查）用于判断本轮是否真正完成目标，防止智能体“刷测试”而忽略真实可用性。

第四，约束可验证的输出而非规定工作流程。HoH 不强制智能体按某种固定步骤行事，而是通过要求交付物必须满足某些可检查的条件（如代码可运行、接口存在、资源文件齐全）来引导行为，保留智能体的灵活性。

此外，HoH 还实现了三个渐进式暴露机制：随着迭代推进，逐步向智能体开放更多交付物细节、角色专属工具（如调试器、资源打包器）以及可复用的技能库，并鼓励复用已有代码而非从零重写。所有版本的项目历史都被记录，支持回溯与对比。

关键结论

基于摘要，HoH 在三个基准（GameCraft-Bench、FrontierSWE、ProgramBench）上，对三组“harness-模型”组合（Codex+GPT-5.5、OpenCode+DeepSeek-V4-Pro、Pi+MiniMax-M3）进行了测试。结果显示：

• HoH 在三组组合上均一致优于对应的独立 harness；
• 经过三轮迭代后，平均相对性能提升为 52.25%，最大提升达 82.86%；
• 在一次超过 70 轮迭代的多日部署中，HoH 自主开发出一款第一人称射击游戏，包含连贯故事情节、完整核心机制、可玩体验、精致视觉与集成音频。

需要说明的是，摘要未给出这些基准的具体评估指标定义（如通过率、任务完成度还是人类评测分数），也未说明 70 轮迭代中人类是否进行了任何形式的干预或中途检查。摘要提到的“自主开发”具体指人类仅在开始时给出高层需求，还是允许在过程中提供反馈，这一点摘要未明确。

读后思考 / 适用场景

HoH 的定位非常清晰：它不是又一个“更聪明的编码模型”，而是让现有模型“更持久地工作”的组织框架。这让人联想到软件工程中的“持续集成/持续交付”理念——人类开发者通过小步提交、自动化测试和版本控制来保证长期项目质量，HoH 相当于把这一套工程纪律移植给了 AI 智能体。

最直接的适用场景是长期、开放式的软件项目，例如从零开发一个游戏、一个内部工具或一个原型系统，且需求本身可能随开发进展而演化。HoH 的“渐进暴露技能”机制尤其适合需要学习新工具或新库的场景——智能体在早期迭代中可能不知道某个调试工具，但随着项目推进，框架可以逐步“教会”它使用这些工具。

另一个值得关注的场景是多智能体协作的底层调度。虽然摘要中测试的是单智能体 harness，但 HoH 的“角色专属工具”与“版本化历史”设计天然适合扩展为多智能体分工——不同智能体负责不同模块，共享项目历史以避免冲突。

局限与开放问题

最明显的局限是评估成本与时间。70 轮迭代的多日部署意味着大量 API 调用和计算资源消耗，这在工业级应用中是否经济可行，摘要未给出成本分析。其次，HoH 的改进效果是否随迭代轮数持续增长，还是存在边际递减甚至过拟合于测试集的风险，摘要仅展示了三轮迭代的数据，长期行为未知。

另一个开放问题是**“自主”的边界**。摘要声称“无需人类干预”，但多日部署中是否有人类检查点、安全护栏或需求澄清机制，并未说明。如果完全无人监督，智能体可能沿着错误方向“高效地”开发出用户不想要的东西——HoH 如何确保需求理解不漂移，是一个值得深究的问题。

最后，HoH 的“技能库”与“复用机制”是否会导致智能体固守早期成功模式而缺乏创新性，也是潜在风险。毕竟，软件开发的最高价值往往不在于“稳定复用”，而在于“突破性设计”——这或许是所有自动化开发框架都尚未跨越的鸿沟。