过去几年，大模型在编程领域的能力进步肉眼可见，但大多数场景仍然有一个共同点：始终需要人类协作。开发者负责拆解任务、拍板中间步骤、审查每一处改动，出了问题还要亲自下场干预。

上海人工智能实验室的研究团队在《Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement》的论文里，挑战了一个宏大的目标：只给 AI 一份高层次需求描述，让它从一张白纸出发，独立完成规划、编码、测试、调试的全过程，最终交付一个完整、功能齐全、可部署的软件系统，全程不需要人类的进一步指导。

为什么AI 自主开发很难？

很多人以为，让 AI 写软件，就是把任务描述拉长一点、让它多跑一会儿。论文明确反对这种看法：自主开发不是跑得更久，而是如何长期保持有效进展。

和短任务不同，从零造一个软件系统，牵涉一串相互依赖的决策：需要把高层需求翻译成可执行的计划、协调不同模块、设计并集成组件、不断测试和排错。随着决策和改动不断累积，开发轨迹会变得非常长。而轨迹一长，三个问题就会冒出来：

• 遗忘：早先的需求、设计决策、已经踩过的坑，很容易在漫长的过程中被丢到脑后；一个局部看起来很合理的修改，可能悄悄破坏了别处的既有功能。
• 停滞：失败的尝试和次优决策不断累积，而新的测试证据又可能推翻旧的假设。结果就是反复"检查—修复—再检查"，或者对已经验证过的组件做无意义的重复验证。
• 自欺欺人：功能缺陷和缺失并不总能在测试中暴露出来，于是 AI 可能在一个残缺的系统上过早宣布完工。

全自主软件开发真正的难点，是让一个没有人类监督的系统，在漫长的时间里始终保持连贯、有效的进步。

Harness-of-Harness：可持续改进的循环

现代编程智能体并不是裸奔的模型。它周围围绕着一整套基础设施，统称为 harness：它决定了模型能看到什么信息、能调用哪些工具、执行结果如何反馈给下一步决策。你可以把它理解成给 AI 配的工作台 + 工具箱 + 工作章程——Codex CLI、OpenCode、SWE-agent 这类产品，本质上就是一个个 harness。

有趣的是，近年出现了一个趋势：把 harness 本身当成可以被优化的对象。AutoHarness 从环境反馈里自动合成 harness，Meta-Harness 用搜索来调 harness，Self-Harness 让 harness 迭代地诊断和修改自己。而Harness-of-Harness（HoH）正是顺着这条思路再往上一层：

HoH 不去改任何现有 harness 的内部实现，而是在它们之上再架一层编排与质量保障框架，就像操作系统之上再装一套项目管理与测试体系。

HoH 的做法，本质上是一套老派但极其有效的软件工程原则的AI 化：迭代式增量开发（iterative and incremental development）。

它把一次孤立的开发过程，重新组织成一个反复运行的规划 → 开发 → 测试闭环。每一轮循环只做一件小而可验证的事，并把成果连同证据一起带到下一轮。

具体到机制设计，论文提炼出几条硬原则：

• 在修复和增长之间找平衡。不能只顾着补 Bug，也不能只顾着加功能，要每轮都有真实的进步。
• 把开发切成小的、可验证的增量。每次改动范围有限，出了问题容易定位，进展也更容易被证实。
• 把开发过程中的测试和独立的验收分开。自己说自己写对了不算数，得由另一个角色独立验证。
• 约束可验证的产出，而不是约束工作流程。框架规定每个角色必须交什么、不许越权做什么，但具体怎么推理、怎么用工具，交给模型自己发挥。
• 鼓励复用而不是重造。能用现成工具、技能、资产，就别让模型从零手搓。

在上下文管理上，HoH 没有引入花哨的记忆模块，而是采用渐进式披露：各种计划、报告、历史都持久化到文件系统里，先给模型一个精简的分类索引，只有当相关内容确实相关时，才把详细内容取出来。这样既保持了长期连续性，又不撑爆上下文窗口。

三个角色：规划者、开发者、测试者

HoH 的每一轮循环，由同一个固定的 harness+模型组合，分别扮演三个角色、各跑一次：

角色一：项目策划（Project Planner）， 团队的产品经理

• 任务：在每次开发循环开始时，策划者会阅读原始需求文档、检查当前项目的状态，并查看上一轮测试报告。
• 产出：一份开发文档。这份文档不是写代码，而是决定本轮要做什么，它会明确指出要保留哪些已验证的功能（不能弄坏已有的东西），以及如何验证新功能是否成功。（只读项目现状，不能改代码。）

角色二：开发者（Developer）， 团队的程序员

• 任务：开发者是唯一能修改代码的角色。拿到开发文档后，开始动手写代码、调整资源。
• 特色实践：开发者会遵循Shift-Left Testing原则，即边写边测。每做一个改动，就立刻运行一下相关功能，确保改动有效且没有破坏其他东西。这就像厨师炒菜时不停尝味道，而不是等整桌菜上齐了再试吃。（唯一的写者，只有它能改代码。）

角色三：质量保证测试员（QA Tester）， 团队的质检员

• 任务：测试员是独立的、严格的第三方。它拿到开发者交付的候选版本后，会从黑盒（比如玩游戏、看界面）和白盒（检查代码、日志）两个角度进行全面测试。
• 产出：一份结构化的测试报告。报告会明确区分哪些功能是已验证（Verified，工作良好）的，哪些是有缺陷（Gap，存在问题或证据不足）的。这份报告是下一轮规划的重要依据。（只读，不能偷偷修候选版本）

为什么要分成三个角色而不是让一个模型边写边自评？论文点出了关键：这三种决策需要的信息、权限和立场完全不同。

• 选目标（这轮做什么）需要项目全局视野；
• 实现（怎么做）需要写权限和局部技术自主权；
• 验收（做得对不对）必须由没参与实现的第三方来下判断，否则就会出现“开发者说写完了、代码也确实存在，但功能根本没跑起来”的自欺欺人。

所以论文特别强调一个细节：QA 评估的是一个被冻结的只读快照。这样所有观察都绑定同一个候选版本，避免评估过程中偷偷把 Bug 修了再自我表扬。

于是每一轮循环的输出，可以简洁地写成：

• A（工件状态）：当前软件的样子——源码、配置、资源、项目元数据。它保证开发是增量延续的，而不是每轮从零重来。
• E（证据状态）：通过评估获得的已验证知识——哪些行为被证实了、哪些还缺证据、哪些失败还没解决。它保证规划是有据可依的。

两个状态一起跨过轮次边界，缺一不可。只有 A 没有 E，下一轮就得靠猜来重建开发历史；只有 E 没有 A，就没有可以继续改的东西。这，就是Harness-of-Harness能长期进步的关键。

长周期开发还有一个痛点：代码只是现状，它不会告诉你“为什么当初这么改”“还有哪些问题没解决”“哪些行为已经验证过了”。

HoH 的解法是把状态和演进过程都留下来。它维护了角色级和迭代级的版本化项目历史：保存软件当前状态的同时，附上简要的变更说明。这样一来：

• 如果某次大改动把系统搞崩了，可以回滚到之前已验证的状态；
• 如果某个相似的失败再次出现，可以直接翻出前一次诊断的证据来辅助定位，而不是从头猜。

实战测评

为了严谨验证，研究者在三类基准上做了对照实验，使用了三组不同的harness + 模型组合：

三个基准各测什么：

• GameCraft-Bench：让 AI 按自然语言规格，用 Godot 引擎从零做一个完整可玩的游戏。论文抽取 45 个任务，覆盖 15 个游戏家族，分为动作、时机、策略、模拟、冒险五类。
• FrontierSWE：仓库级软件工程任务，从零实现或深度优化真实开源项目，论文评估其中 15 个任务。
• ProgramBench：只给一个编译好的可执行程序和文档，让 AI 重建出行为一致的同款代码库。

三轮迭代之后，HoH 在每一组配置、每一个基准上都超过了不套框架的 Vanilla（原始用法）。 平均相对提升 52.25%，最高提升 82.86%。具体数字如下：

值得注意的点：

• 提升与原始水平无关。最强的 Vanilla（Codex+GPT-5.5）拿到了 GameCraft-Bench 的最高分；而原本垫底的 OpenCode 组合提升同样巨大，甚至在动作类、模拟类游戏和 FrontierSWE 的性能类任务上反超了"Codex Vanilla"。也就是说，这个方法对弱基座同样有效，甚至可能更有效。
• 越跑越好，不是越跑越崩。在 GameCraft-Bench 上，三组配置的分数从 HoH@1 到 HoH@3 一路单调上升；把 Codex 组合在 FrontierSWE 上跑到 10 轮，支配率（Dominance，与同池其他 11 个配置逐任务对战胜率）从第 3 轮的 39.33% 一路涨到第 10 轮的 72.67%（第 9 轮曾到 76.00%），而 Vanilla 只有 27.33%。这直接回应了"长周期任务会退化"的担忧。
• 不是多跑几遍的功劳。一个合理的怀疑是，HoH 效果好，会不会只是因为轮数多、花的时间多？论文专门做了预算控制实验，让 Vanilla 也连续开发 3 遍（Vanilla Continuation）。结果，HoH 只用了 2 遍的预算（5.67M tokens）就拿到 64.84 分，超过 Vanilla 连跑 3 遍（6.33M tokens）的 58.24 分。印证了提升来自规划—测试这套结构本身，而不是单纯堆预算。
• 三个机制各有贡献。论文还做了消融实验，分别拆掉一个关键机制：
  • 不更新开发计划（每轮用第一版）：掉 8.13 分；
  • 不给规划者反馈测试证据：掉 6.28 分；
  • 不保留上一轮工件（每轮从零重写）：掉 7.85 分，且 token 消耗从 8.41M 涨到 11.12M。

这说明“计划随证据更新”“证据驱动重规划”“保留既有实现”三者缺一不可。

AI 连续几天，自己做出一款可玩的 FPS 游戏

基准测试考察的是少量轮次内的成品质量，论文还做了一场更具戏剧性的实战：Fusepoint。这是一款单机剧情向第一人称射击游戏，需求合同写得非常具体：

• 一段约 5 分钟的单人拆弹任务；
• 需要按顺序占领两个控制点；
• 最终目标处进行三阶段拆弹；
• 固定 18 名敌人，按 3/5/10 分布在前中后三个遭遇区；
• 要有成功拆弹与引爆两条不同的结局分支。

开发环境：用 Godot 4.7 做引擎，配了 Godot MCP（让 AI 能操作引擎、执行、调试）、素材生成工具、UI/UX 技能、测试技能，以及 CC0/CC BY 授权的可复用素材库。系统用的是 Codex CLI + GPT-5.6-Sol（高推理档）。

整个过程中，人类只做了一件事：偶尔恢复网络或 API 连接。 规划、编码、调试、测试、验收，全部由 AI 自己完成。

70 轮迭代下来，开发轨迹呈现出清晰的三个阶段：

• 初始搭建（第 1–27 轮）：先把项目跑起来，建立核心交互路径。这个阶段新增功能也暴露了大量缺陷，artifact 越可测，暴露的 issue 越多，积压不降反升，很正常。
• 能力扩张（第 28–49 轮）：一边加新功能，一边继续诊断和修复。此时系统越来越集成，一个局部改动可能牵动任务状态、战斗、界面反馈、运行时行为。
• 趋于稳定（约第 49 轮之后）：计划的功能接近完成，修复逐渐成为主线，活跃的 issue 积压开始下降。

到第 70 轮时，共记录了 81 个 issue，关闭 65 个，还剩 16 个未解决；其中有 17 个 issue 曾被重新打开，因为后来的改动让之前已验证的行为又失效了。这种回归被完整记录在案，下一轮规划能直接把它当成明确的修复任务，而不是要 AI 重新考古。

最终交付的游戏是什么水平？论文列出的清单相当可观：连贯的剧情、完整的战斗与武器系统、敌人 AI、玩家引导（小地图）、HUD、菜单与设置、过场动画、打磨过的视觉特效与光照、脚步声与枪声等音效，并且真人可玩。开发过程、轨迹和试玩视频都公开在 GitHub 上。

小结

这篇论文最核心的地方，是把视角又抬高了一层。它没有发明新的模型，也没有强迫重写工具链，而是找到了一种通用的编排方式，让任何一组（harness+模型）组合，都能通过小步增量 + 独立验收 + 证据留痕持续改进。当然，也要冷静看待局限：目前实验集中在游戏与特定工程任务，70 轮只跑了一个案例；token 成本并不低（HoH@3 单任务动辄数百万到上千万 token）；人类只负责修网络也只适用于网络环境相对可控的场景。

让AI开发复杂软件的关键，不仅仅是模型本身有多强大，更在于如何管理和组织它们的开发过程。通过“计划-执行-验证”的迭代循环，并让项目历史和测试证据在不同环节间流动，AI也能展现出持续、稳定、有效的长期工作能力。