Harness-of-Harness:让编程智能体在多轮迭代中持续改进软件
导语
让大语言模型写出一个能运行的程序,已经不再是最难的问题;真正困难的是,让它在数天乃至数十轮无人干预的情况下,持续修复问题、扩展能力,并最终交付一个可使用的软件。论文提出的 Harness-of-Harness(HoH),正是针对这一问题设计的框架。它不替换底层模型,也不要求开发者采用某一种固定工作流,而是建立在已有 coding-agent harness 之上,负责组织和约束长期开发过程。
核心做法
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 的价值不只在于单次基准分数,更在于它把“长期软件开发”抽象成了一个可管理的控制问题。对 coding agent 而言,持续交付、状态管理、回归检查和独立验收可能比单轮生成代码更关键。该框架也表明,提升智能体能力未必只能依靠更大的模型,外部 harness 对任务分解、反馈节奏和历史复用的设计同样重要。
不过,现有材料主要提供摘要层面的实验结果,尚不足以判断不同任务规模、评估标准或资源成本下的稳定性。多日自主开发案例也不能直接等同于所有软件项目都能无人值守完成。未来仍需要更细致地分析失败恢复、长期代码质量、测试覆盖率,以及迭代次数与计算成本之间的关系。
评论
正在确认登录状态……
正在加载评论……