Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement
一句话概括
Harness-of-Harness（HoH）让现有 LLM 编码智能体在数天、数十轮迭代中自主开发完整软件。它在 3 个基准上均优于对应独立 harness，三轮迭代后平均相对提升 52.25%。
速览
- 任务：让 LLM 编码智能体（coding agent）把高层需求变成完整、可用、无需人类干预的软件系统。
- 方法：HoH 叠加在现有 harness 上，把执行组织为迭代的「规划—编码—测试」循环。
- 关键数字：3 组 harness-模型组合、3 个基准，三轮迭代后平均相对提升 52.25%，最大提升 82.86%。
- 数据与开源：摘要给出 GitHub 与项目主页链接。基准与部署细节摘要未给出。
问题背景
LLM 编码智能体已能完成单轮或少量轮次的编程任务。例如修一个 issue、实现一个函数。
但自主软件开发要求更多。它要从高层需求出发，完成架构设计、模块拆分、编码、测试与缺陷修复。它甚至要整合视觉与音频资源，最终交付人类可直接使用的软件。
现有 harness 多面向「单次任务」或「有限轮次修复」。它们缺少让智能体长期持续改进产出的机制。
常见问题有 4 类。修一个 bug 引入新问题；反复重写而非复用；测试与评估混为一谈；缺少版本管理，无法回退或追踪进展。
一句话：现有 harness 擅长完成一个点，不擅长持续推进一个面。
方法要点
HoH 不重造编码智能体。它作为元框架叠加在现有 harness 之上，把执行组织为迭代循环。
其设计原则有 4 条：
- 平衡修复与能力增长：每轮既修上一轮的问题，也引入新功能或技能，避免只修不建。
- 切分小而可验证的增量：每次迭代只处理一个可独立测试的模块，降低出错半径。
- 分离实现期测试与独立评估：单元测试指导编码，独立评估判断本轮是否真正达标，防止刷测试。
- 约束可验证输出而非规定流程：要求交付物满足可检查条件，保留智能体灵活性。
此外，HoH 实现 3 个渐进式暴露机制。随迭代推进，逐步开放交付物细节、角色专属工具与可复用技能库。角色专属工具如调试器、资源打包器。HoH 还鼓励复用已有代码。
所有版本的项目历史都被记录，支持回溯与对比。
关键结论
HoH 在 3 个基准上做了测试。基准为 GameCraft-Bench、FrontierSWE、ProgramBench。
它测试了 3 组 harness-模型组合。分别是 Codex+GPT-5.5、OpenCode+DeepSeek-V4-Pro、Pi+MiniMax-M3。
- HoH 在 3 组组合上均一致优于对应的独立 harness。
- 三轮迭代后，平均相对性能提升 52.25%，最大提升 82.86%。
- 一次多日部署超过 70 轮迭代。HoH 自主开发出一款第一人称射击游戏。
这款游戏包含连贯故事情节、完整核心机制、可玩体验、精致视觉与集成音频。
需说明：摘要未给出基准的具体评估指标定义。摘要也未说明 70 轮迭代中人类是否干预或中途检查。「自主开发」是否允许过程中反馈，摘要未明确。
读后思考
HoH 的定位清晰。它不是更聪明的编码模型，而是让现有模型更持久工作的组织框架。
这类似软件工程中的持续集成/持续交付（CI/CD）。人类靠小步提交、自动化测试与版本控制保证长期质量。HoH 把这套纪律移植给 AI 智能体。
最直接的适用场景是长期、开放式的软件项目。例如从零开发游戏、内部工具或原型系统。这类项目的需求可能随进展演化。
渐进暴露技能机制尤其适合需要学习新工具或新库的场景。
另一个场景是多智能体协作的底层调度。摘要测试的是单智能体 harness。但角色专属工具与版本化历史设计天然适合扩展为多智能体分工。不同智能体负责不同模块，共享项目历史以避免冲突。
局限与开放问题
- 评估成本与时间：70 轮多日部署意味着大量 API 调用与算力消耗。工业级应用是否经济可行，摘要未给出成本分析。
- 长期收益曲线：摘要仅展示三轮迭代数据。改进是否随轮数持续增长，还是边际递减甚至过拟合测试集，未知。
- 自主的边界：摘要称无需人类干预。但多日部署中是否有人类检查点、安全护栏或需求澄清机制，未说明。若完全无人监督，智能体可能高效开发出用户不想要的东西。需求理解如何不漂移值得深究。
- 创新性风险：技能库与复用机制是否会让智能体固守早期成功模式，缺乏突破性设计，是潜在风险。