上海Al Lab提出Harness-of-Harness:5天无人干预，AI从零做出FPS游戏

©PaperWeekly 原创· 作者 | 闫浩扬

单位 | 上海人工智能实验室博士生

研究方向 | AI Agent

Harness-of-Harness（HoH）是上海人工智能实验室提出的一种自主软件开发框架：不更改 harness 底座，而是把整个开发过程组织成反复执行的「规划-编码-测试」循环。

在三个基准上，HoH 相对各自的裸 harness 平均提升 52.25%；在案例研究中，系统历时 5 天、70 余轮迭代，自主完成一款可游玩的 FPS 游戏。

论文标题：

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

论文链接：

https://arxiv.org/abs/2609.01481

项目主页：

https://flesymeb.github.io/HarnessOfHarness

代码地址：

https://github.com/Flesymeb/HarnessOfHarness

动机：现在的 AI 编程，方向盘还在人手里

论文开篇即讨论了一个基础问题：现有的 coding agent，是否已经具备「自主开发软件」的能力。就当前主流实践而言，答案是否定的。

随着大模型能力提升，coding agent 已能完成相当规模的编程任务，但其「自主」多数仍属 human-in-the-loop：任务由人类拆解，中间决策由人类监督，代码变更由人类审查，出现回归后亦依赖人类介入修复——agent 承担执行环节，开发过程的控制权仍掌握在人类手中。

〓 图1：两种软件开发范式对比

当目标从「解决局部问题」扩展为「从零构建完整可运行的软件系统」时，挑战的性质随之改变：关键不再是让 agent 运行更久，而是如何在长程开发中维持稳定、连贯的进展。论文将长程自主开发面临的主要困难归纳为四类：

①  需求遗忘：早期需求、设计决策和踩过的坑，在漫长的开发轨迹中被遗忘；

②  功能回归：局部看似合理的修改，悄悄破坏别处的既有功能；

③  开发停滞：反复「检查-修复-再检查」，对已验证的组件做重复验证；

④  提前宣告完成：功能缺失没有暴露，残缺的系统被过早宣布完成。

其中第四类现象在长程 agent 任务的实践中并不罕见，也是现有系统可靠性受到质疑的主要原因之一。因此，自主软件开发的核心问题并非延长 agent 的运行时间，而是如何使长程开发中的进展可持续。

针对这些问题，HoH 把开发过程的控制权交给一套角色分权的循环结构。

项目目前已经公开了两款 AI 自主开发、可下载游玩的游戏：第一人称射击游戏 Fusepoint 与像素风 Roguelite 游戏 Mournlight。

以 Fusepoint 为例，其具备完整的武器系统、3D 场景、连贯的剧情、空间音效以及云层、光照等渲染细节，完成度显著高于常见的基于 three.js 的演示原型。

第二款游戏——肉鸽类的 Mournlight 也开放体验，效果同样优秀。

〓 图2、3：Fusepoint 与 Mournlight 实机画面

方法：把开发组织成「规划-编码-测试」进化循环

这篇工作提出的方法叫 Harness-of-Harness，简称 HoH。不同于同团队的另一篇工作 Self-Harness（它进化的是 harness 本身）；HoH 持续进化的对象换成了整个软件开发过程，harness 只是底座。

HoH的思路借鉴了 loop engineering：在已有 harness 之上，引入 Planner—Coder—Tester 的迭代闭环，使软件在轮次增加后持续改进，而非反复修补、陷入停滞。

HoH 不重新构造 harness，而是在其上组织开发，将开发过程结构化为反复执行的「规划-编码-测试」循环。

每轮包含三个角色：Planner 制定开发计划，Developer 执行代码修改，QA Tester 负责独立验收。

权限切分严格：只有 Developer 具有项目写权限，Planner 与 QA Tester 全程只读；QA Tester 的评估对象是一份冻结的只读快照，从机制上排除了边测试边修改的可能。

论文提炼了自主软件开发系统的五条设计原则：

①  平衡修复与能力增长：每份计划既处理遗留问题，也交付一个新的小能力——只修不加，开发退化为无尽的补丁；只加不修，技术债持续累积；

②  小而可验证的增量：改动范围越小，越容易确认其未破坏既有行为；

③  开发与验证分离：实现阶段的测试与独立评估分开进行，开发者不能既当运动员又当裁判——消融实验显示，移除该机制会导致明显掉分；

④  约束产出，而非过程：框架只规定各角色必须交回的工件格式，思考方式、工具选择与执行顺序由模型自主决定；

⑤  版本化的项目历史：若某一轮使系统退化，则回退至上一已验证状态，类似游戏中的存档点。

在开发侧，Developer 采用测试左移（shift-left testing）的组织方式：编码过程伴随一个测试工具边车（sidecar），边写边测、实时暴露问题，而非将缺陷累积到验收阶段——与人类工程师的实践一致。

在验收侧，QA Tester 采用黑盒与白盒相结合的方式：黑盒检查交互与渲染，白盒检查源码与运行时日志，结论仅在绑定到对应被测版本时有效每轮结束后，两类信息被带入下一循环：软件工件的最新状态，与已被测试证据支持的结论。

前者保证开发的延续性——不每轮从零重写；后者保证规划有据可依——不必依赖猜测。

〓 图4. HoH 框架总览：三个角色围绕版本化工作区循环迭代

实验：三基准平均提升 52.25%

HoH 在基准评估上选择了三种 benchmark，涵盖不同的端到端软件开发场景，各测一面：GameCraft-Bench 从零做完整可玩的游戏；FrontierSWE 做仓库级的真实项目工程；ProgramBench 从编译好的程序逆向重建代码库。

实验选择了三种 harness-model 组合（Codex + GPT-5.5 high、OpenCode + DeepSeek-V4-Pro、Pi + MiniMax-M3），结果显示 HoH 对各自的裸 harness（vanilla baseline）提升显著：平均相对提升 52.25%，三轮后最高提升 82.86%。

〓 图5. 三个基准 × 三组配置成绩

值得注意的是，最强的 Vanilla 配置（Codex + GPT-5.5）提升同样显著，49.58 到 71.52，提高 21.93 分——提升并不只发生在底子弱的配置上，OpenCode 组在动作、模拟类任务上甚至超越了 Codex 的裸 harness。

然而，真实软件开发却动辄几十轮，而长程恰恰是最容易遗忘、原地打转的区间——三轮涨得动，不代表长了还稳。

因此，论文还对此做了实验分析：Codex+GPT-5.5 组在 FrontierSWE 上跑到第 10 轮，支配率（Dominance）从第 3 轮的 39.33% 涨到 72.67%，而裸 harness 只有 27.33%。质量随轮次持续上升，并未在三轮处饱和。

一个自然的疑问是：提升是否只来自更多的轮次和预算？

论文的对照实验排除了这一点——HoH 只跑两轮、花 5.67M token，拿到 64.84 分；裸 harness 连跑三轮、消耗 6.33M token，也只有 58.24 分。起作用的是结构本身，不是预算堆叠。

消融实验还把关键机制逐个拆开验证：不更新计划、不反馈测试证据、不保留上一轮工件，各掉 6～8 分，这也说明计划随证据更新、证据驱动重规划、保留既有实现，三者缺一不可。

提升也覆盖了机制、内容、视觉、呈现各维度，不是牺牲一方面换另一方面。

真实案例：5 天 70 轮，从空文件夹到可玩的 FPS

Benchmark 是可控环境，该案例则展示了 HoH 在真实开发场景中的可行性。

项目起点是一个空工作区与一份产品需求文档（PRD），其中只包含玩家可感知的内容——五分钟拆弹任务、依次拿下两个控制点并拆弹、18 个智能敌人、成功和爆炸两条结局分支。

工程拆解、任务排序与验收方式均由 HoH 自行决定。

开发历时超过 5 天，70 余轮循环。引擎为 Godot 4.7，模型为 Codex CLI + GPT-5.6-Sol high。

全程 GitHub 留痕，每一轮的开发文档、issue 表和证据包都可追溯。

在 70 轮次的开发中，HoH 共记录 81 个 issue，关闭 65 个，16 个未解决；另有 17 个曾被重新打开——后续改动破坏了先前已验证的行为。回归被逐一记录，成为下一轮明确的修复任务。

开发轨迹分为三个阶段：前 27 轮搭建核心骨架，问题集中暴露；第 28–49 轮功能扩展与修复并行；49 轮后进入收尾，修复成为主线，活跃 issue 积压持续下降。

〓 图6. Fusepoint 开发轨迹

开发过程中，人只维护额度限制和网络问题。听起来难以置信，但每轮的开发记录都完整保留在仓库里——commit、issue、测试证据（完整效果可见项目页）。

未来展望

同样的模型，套上一层正确的组织结构，产出就能从「半成品」变成「能玩的完整软件」，模型没换，变的是开发过程本身。

其中最值得回味的是独立 QA：自己验证自己，检验的永远是「我实现的那部分」，而非「需求要求的那部分」——很多项目就栽在这里。

不过，真实项目的生命周期以月、年计：需求中途会变，「做完了」的标准常常写在人心而不是文档里。

七十个循环、五天工期、五分钟体量的小游戏，放在这个尺度下还是短程——对自主软件开发这件事，仍然任重道远。

好在 HoH 给出了这一程的答案：小增量、独立验收、证据留痕。论文的下一步也将朝这个方向：拓展到更多类型的游戏和软件系统，做成更通用的自主软件开发框架。

更多阅读

·