基于大语言模型（LLM）的 coding Agent，已经能够完成代码生成、仓库级问题修复等任务。
然而，当目标从“解决一个局部问题”变成“从零构建一个完整、可运行、可部署的软件系统”时，真正的挑战就不再只 是让 Agent 持续 运行更长时间，而是如何在长程开发过程中，持续做出正确决策，并保持稳定、连贯且有效的进展。
(资料图片仅供参考)
这是因为，新的约束、失败记录和已验证行为会在长程开发中不断累积，Agent 可能遗忘早期需求，也可能在局部修复中引入新的回归问题；如果每轮开发只关注当前故障，还可能陷入重复检查和修补，最终在功能尚未完整时误判项目已经完成。
为此，上海人工智能实验室团队提出了Harness-of-Harness（HoH）框架，让 coding agent 能在自主开发过程中持续改进软件。
论文链接：https://arxiv.org/pdf/2609.01481
在 GameCraft-Bench、FrontierSWE 和 ProgramBench 三个基准上，针对三组 harness-model 组合，HoH 均持续优于对应的独立 harness。经过三轮迭代后，其平均相对性能提升达到 52.25%，最高可达82.86%。
更值得注意的是，在一次持续多天、超过 70 轮迭代的部署中，HoH 还自主开发了一款具备完整玩法、叙事、视觉和音频表现的第一人称射击游戏。
研究方法
HoH 在现有 coding-agent harness 之上增加了一套持续迭代机制，将软件开发组织为“规划-开发-测试”的循环。每轮只完成一个边界明确、局部完整且可验证的软件增量，并把新版本及其测试证据传递给下一轮。
图｜Harness-of-Harness 概述。
每轮由三个角色依次完成不同任务。Project Planner读取高层软件规格、当前项目和历史测试证据，确定下一步应实现的功能，同时列出需要保留的已验证行为和具体验收条件。规划范围既不能小到无法形成可运行能力，也不能大到混入无关重构或功能扩展。
Developer从上一轮的软件版本开始实现计划内容。只有 Developer 能够修改项目，其他角色只能读取或执行，从而保持清晰的版本边界和责任划分。开发过程中，Developer 会先建立目标行为的基线，在每次重要修改后重新运行相关路径，并检查可能受到影响的回归面。这个过程用于尽早发现局部实现问题，但 Developer 的自测不等于最终验收。
QA Tester接收一个被冻结的、只读的候选版本，并独立判断它是否满足当前目标和整体需求。QA 同时使用黑盒测试与白盒测试，前者通过输入、交互流程和渲染结果检查用户可观察行为，后者检查源代码、配置、资源绑定、运行时状态和日志。只有当候选版本的行为得到与该版本绑定的证据支持时，相关要求才会被标记为已验证；失败、回归和证据不足则被记录为后续待处理问题。
HoH 在轮次之间维护两种互补状态。软件产物状态记录当前代码、资源、配置和项目元数据，回答“项目现在是什么”；执行证据状态记录已验证行为、未满足需求、观察到的失败和需要保留的功能，回答“哪些结论已经被测试支持”。Planner 根据这两类信息重新确定下一轮目标，Developer 在上一版本上继续修改，QA 再为新版本生成证据。
这种设计同时解决了长程开发中的三个问题：通过小范围增量控制单轮修改面，通过证据反馈避免遗忘未解决问题，通过独立 QA 防止开发者的完成声明替代产品验收。HoH 约束的是角色权限、输入输出和可验证产物，而不规定 Agent 的具体推理过程、工具顺序或实现算法。
在多日 FPS 案例中，研究团队让 HoH 从空工作区和一份产品需求文档开始构建 Godot 游戏 Fusepoint。系统使用 Godot MCP、资产生成工具、UI/UX 技能和测试技能完成引擎操作、资源制作、界面设计与运行验证，并通过 GitHub 保存版本、提交记录、issue 历史和测试证据，使后续迭代能够继续利用此前的实现与发现。
实验结果
研究团队在 GameCraft-Bench、FrontierSWE、ProgramBench 三类软件开发相关基准上测试了 HoH 的有效性。
他们比较了三组 harness–model 配置：Codex CLI 与 GPT-5.5（high reasoning effort）、OpenCode 与 DeepSeek-V4-Pro，以及 Pi Coding Agent 与 MiniMax-M3。Vanilla 只进行一次标准开发流程；HoH@1、HoH@2 和 HoH@3 分别执行 1、2、3 轮“规划-开发-测试”循环。两种设置使用相同的初始状态和底层 harness–model 配置，差别仅在于是否采用 HoH。
如上图，在GameCraft-Bench的 Overall 指标上，三组 harness–model 配置的 Vanilla 得分分别为 49.58、26.90 和 42.16；HoH@3 分别为 71.52、48.98 和 58.78，对应增加 21.93、22.08 和 16.62 分。
在FrontierSWE上，三组配置的平均 reward 分别从 0.31、0.23 和 0.26 提升至 0.54、0.31 和 0.55，对应的 Dominance 也从 Vanilla 的 44%、25% 和 35%，提升至 HoH@3 的 71%、44% 和 64%。
在ProgramBench上，平均隐藏测试通过率分别从 60.41%、45.27% 和 35.83%，提升至 66.50%、57.56% 和 52.68%。
进一步的多轮实验显示，HoH 的提升能够继续延伸到三轮之后。Codex + GPT-5.5 在 FrontierSWE 上运行至 HoH@10 时，Dominance 从 HoH@3 的 39.33% 提升至 72.67%。
对照实验表明，这些提升并非只是增加开发轮数带来的结果。HoH@2 使用 5.67M tokens 达到 64.84 分，高于 Vanilla 连续运行三轮、使用 6.33M tokens 时的 58.24 分。
在多日 FPS 开发案例中，HoH 从一份产品需求文档和空工作区开始构建 Fusepoint，连续运行 70 轮。项目共记录 81 个 issue，其中 65 个已解决、16 个仍未解决；17 个 issue 曾因后续修改导致回归而被重新打开。开发过程经历了核心项目搭建、功能扩展和稳定化三个阶段，版本历史、issue 记录与测试证据共同支撑了后续规划。
下一步？
在这项工作中，HoH 通过对 coding agent harness 进行持久化、证据接地的编排，为实现端到端软件开发提供了一条切实可行的路径。
未来，研究团队希望将把 HoH拓展到更广泛的真实世界开发场景中，包括不同类型的游戏及其他软件系统，最终打造一个通用的自主软件开发框架。
更多技术细节，详见原论文。
作者：学术君
如需转载或投稿，请直接在本文章评论区内留言
营业执照公示信息