给 Coding Agent 再套一层"驾驶舱"：HoH 让 AI 连续 6 天、70 个循环写出一款能玩的 FPS 游戏

你有没有试过让 Codex、Claude Code 这类编码 Agent 一口气干一个大活？前一两个小时它还挺像回事，再往后就开始犯浑：忘了自己两小时前定的设计，修一个 bug 弄坏三个功能，在"检查—修复—再检查"里原地打转，最后项目还缺着一半功能，它却告诉你"已经全部完成了"。

这不是模型变笨了，是长时程自主开发这件事本身和"单次会话写代码"是两个完全不同的问题。这篇来自上海人工智能实验室的论文 Harness-of-Harness（HoH，arXiv: 2609.01481）给出的答案很直接：模型不用换，harness 也不用改，在外面再套一层 harness，把 Agent 的执行组织成一轮又一轮"规划—编码—测试"循环就行了。说实话我的第一反应是"这不就是套娃吗"，但看完实验数据我承认这个套娃套得相当有章法——三个基准、三组 harness–model 组合，三轮迭代后平均相对提升 52.25 个百分点，最大 82.86 个百分点；更狠的是，他们用这套东西让 Agent 连续自主开发了 6 天、跑了 70 个循环，从零搓出了一款人类真能上手玩的第一人称射击游戏。

核心摘要：HoH 解决的痛点是编码 Agent 在多日无人干预的自主开发中会遗忘状态、累积错误、陷入无效循环。方案是在现有 coding-agent harness 之上叠加一个编排层，把执行拆成 Project Planner、Developer、QA Tester 三个角色的迭代循环，用"工件状态 + 证据状态"双状态机制维持跨循环的连续性。在 GameCraft-Bench、FrontierSWE、ProgramBench 上，HoH 相对独立 harness 三轮后平均提升 52.25%，且等 token 预算下依然领先。我的判断：这不是底层算法突破，而是一套非常扎实的工程协议，但它恰好踩中了 2026 年 Agent 工程从"单次会话"走向"多日自主"的关键节点，值得每个做 Agent Infra 的人细读。

📖 论文信息

• 标题：Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement
• 作者：Haoyang Yan、Min-Le Su、Hangfan Zhang、Zhanhao Li、Chen Zhang、Shao Zhang、Yang Chen、Lei Bai、Shuyue Hu（前四位为共同一作）
• 机构：Shanghai Artificial Intelligence Laboratory（上海人工智能实验室）
• 发表：2026 年 9 月 1 日提交，arXiv: 2609.01481
• 代码：https://github.com/Flesymeb/HarnessOfHarness
• 项目页：https://flesymeb.github.io/HarnessOfHarness/

🎯 问题动机：自主开发的敌人不是能力，是时间

先厘清一个概念。论文里说的 autonomous software development，指的是人只给一份高层需求（比如一份 PRD），Agent 从零开始把完整、能跑、能用的软件系统做出来，全程不需要人类指导。这跟我们现在主流的 human-in-the-loop 模式完全不同——后者里开发者得拆任务、盯中间决策、审查变更、失败了随时接管。

图1：左边是现在我们熟悉的样子——人拿着扳手站在 Coding Agent 旁边，observe、reinvoke、收拾 errors & bugs；右边是 HoH 的图景——人躺着，规划—开发—测试的循环自己转，从 Concept 一路滚到 Product。

为什么这件事难？论文把它拆成了三个结构性挑战，我觉得拆得很准：

状态遗忘。开发轨迹拉长后，早期的需求、设计决策、已经踩过的坑、已经验证过的行为，都会被遗忘或者跟后续变更脱节。Agent 可能引入一个局部合理但违反全局约束的修复。

下一步动作的不确定性。高层规格没法唯一确定"下一个有用的变更"是什么。反复的检查—修复会烧掉大量迭代却不推进系统。

质量要求的异构性。功能和质量是通过五花八门的、场景特定的行为体现的——一个游戏"手感对不对"、一个系统"边界条件处理了没有"，缺失的行为可能根本不会被检测到，于是一个半成品被当成完成品接受了。

我之前在让 Agent 跑过夜任务的时候就碰到过一模一样的症状：早上起来一看，测试全绿，但核心功能被"顺手"重构没了。论文有一句话总结得到位——自主软件开发不只是延长执行时间的问题，真正的挑战是随时间维持连贯且有效的进展。

说到这个，其实工业界已经有一些应对思路了。Anthropic 在 2025 年底公开过他们的 two-agent pattern：一个 initializer 先建好脚手架和几百条 feature list，然后编码 Agent 一个 feature 一个 feature 地啃，靠 git commit 和 progress log 做会话间的"记忆桥"。Geoffrey Huntley 的 Ralph loop 更粗暴——就是一个 bash while 循环反复重启 Agent，反正进度存在文件和 git 历史里，不在上下文里。HoH 跟这些思路一脉相承，但把它系统化、协议化了：不只是"让 Agent 别忘事"，而是给整个开发过程装上规划、验收和版本管理。

🏗️ HoH 是什么：harness 之上的 harness

先解释下 harness 这个词。在 Agent 语境里，harness 是包在 LLM 外面的那层壳——给它提供工具、管理执行、中介它与开发环境的交互。Codex CLI、OpenCode、Pi 这些都是 harness。2026 年这词火到什么程度呢，LangChain 有组数据：同一个模型换套更精巧的 harness，Terminal Bench 2.0 通过率从 52.8% 拉到 66.5%，模型权重一个字节没动。

HoH 的核心观察是：既然 harness 能结构化"模型的操作"，那就可以在 harness 之上再加一层，结构化"harness 在长时程开发中的参与方式"。关键是 HoH 完全不修改底层 harness 的实现，它就是外面的一层编排协议。

图2：HoH 的整体架构。中间是被编排的 harness（OpenCode、Codex 等），围着它转的是三个角色：Project Planner 把 PRD 和测试证据变成开发文档 D_t；Developer 按计划用工具链和 skills 构建软件；QA Tester 从多个质量维度做证据奠基的测试。右侧展示了开发文档的内容结构（未解决缺口→优先级任务范围、已验证行为→保留约束、任务规格→验证要求）和按角色组织的工具与 skills。

三个角色，三次独立调用

每个循环按"规划—开发—测试"顺序各调一次角色，用的是同一套 harness–model 配置，只是角色契约不同：

这个设计里有几个我觉得很见功力的地方。

单一写入者边界。三个角色里只有 Developer 能动工件。Planner 只能看，Tester 只能验。听起来是常识，但你想想看，多少多 Agent 系统的混乱就是因为大家都能写——改着改着就互相覆盖了。

自测不算验收。Developer 在开发过程中嵌入聚焦测试（shift-left testing），但它的自测只决定"能不能提交候选"，不构成验收。验收由独立的 QA Tester 干，而且 Tester 会从规格和开发文档推导场景特定的检查标准——游戏就查渲染输出和交互响应，系统就查配置和运行时状态。这基本就是把软件工程里"开发和 QA 分离"的老规矩搬给了 Agent。

约束输出，不规定过程。每个角色必须返回符合 schema 的结构化产物，违反就 retry；但 Agent 内部怎么推理、怎么用工具，不管。这个度把握得挺聪明——管太死会限制模型能力发挥，管太松又没法编排。

双状态机制：工件 + 证据

跨循环的连续性靠两个互补状态维持：

• 工件状态 \(A_t\)：软件现在是什么（源码、配置、资源、元数据）
• 证据状态 \(\mathcal{E}_t\)：哪些行为已验证、哪些声明没证据、哪些失败待解决

状态转移就是：

论文里一句话我很喜欢：工件连续性让开发成为增量的，证据驱动的目标选择让开发成为迭代的。记忆这块没有用专门的记忆模块，而是 plans、reports、histories 全持久化在文件系统里，先暴露简洁的索引，需要细节再检索——渐进式披露，不撑爆上下文。核心流程用伪代码表示：

输入: 规格 𝒮, 初始工件 A₀, 迭代预算 T
固定: 模型 M, harness H, 角色契约
ℰ₀ ← ∅
for t = 1, …, T:
    D_t ← ProjectPlanner(𝒮, ℰ_{t-1}; read_only(A_{t-1}))
    A_t ← Developer(A_{t-1}; 𝒮, D_t)
    ℰ_t ← QATester(read_only(A_t); 𝒮, D_t, Runtime.check(A_t))
return A_T

🧪 实验：三个基准、三组配置，全面压制

实验设计得相当规整。三个基准：

• GameCraft-Bench：140 个任务、15 个游戏家族，从自然语言规格构建完整可玩的 Godot 项目。实际评估分层抽样 45 个任务，分 Action、Timing、Strategy、Simulation、Adventure 五大组，Overall 分数 0–100，跑不起来记 0 分。
• FrontierSWE：从零实现 + 开放式性能/研究目标，取 17 个任务中的 15 个（4 个实现、9 个性能、2 个研究），除了官方 reward 还报 Dominance——对随机竞争对手的任务级胜率。
• ProgramBench：cleanroom 程序重建，只给编译好的可执行文件和文档，重建行为匹配的代码库，看隐藏测试通过率。

三组 harness–model 配置：Codex CLI v0.142.5 + GPT-5.5（high reasoning）、OpenCode v1.14.30 + DeepSeek-V4-Pro、Pi v0.80.10 + MiniMax-M3。对照组 Vanilla 就是同样配置跑一次标准开发，HoH@T 是跑 T 轮循环，主实验 T=3。初始状态、底层配置完全一致，唯一差别就是套不套 HoH。

主结果：三轮之后

几个值得停一秒的点。

OpenCode 的 GameCraft 从 26.90 到 48.98，按未取整数值算相对提升约 82.86%——这就是摘要里那个最大增益的出处。起点越弱的配置，吃到的红利越大。更有意思的是，弱起点套上 HoH 能反超强起点的裸奔：OpenCode + HoH@3 在 GameCraft 的 Action、Simulation 和 FrontierSWE 的 Performance 类别上超过了 Codex Vanilla。你想想看，harness 编排带来的增益在某些维度上已经能盖过模型能力差距了。

也不是处处单调。Pi 的 ProgramBench 在 HoH@2 达到 53.57 的峰值后，HoH@3 回落到 52.68；Pi 的 Dominance 也从 HoH@2 的 66% 微降到 64%。论文没回避这些波动，这点挺诚实。

拉长到 10 轮会怎样

在 FrontierSWE 上用 Codex 跑了 10 轮迭代：Dominance 从 HoH@3 的 39.33% 一路爬到 HoH@10 的 72.67%，最佳检查点 HoH@9 到 76.00%，而 Vanilla 只有 27.33%。曲线没有饱和迹象——这是"continual improvement"这个标题承诺最直接的证据。

等预算对照：不是堆 token 堆出来的

这是我最关心的实验。HoH 跑三轮自然比跑一次花更多 token（Codex 上 8.41M 对 2.59M），那如果只是让 Vanilla 也连续跑三轮呢？

看中间两行：HoH@2 用 5.67M token 拿到 64.84 分，Vanilla 连续跑三轮用 6.33M token 只有 58.24 分。花得少，还高了 6.6 分。这个对照基本堵住了"增益全是靠多烧 token"的质疑——结构化的规划—测试循环本身在创造价值。

消融：三个机制缺一不可

在 GameCraft 全 45 任务、Codex 配置上消融（满分参照系是完整 HoH@3 的 71.52）：

三个变体在每一个任务上都输给完整版。去掉 warm-start 那条尤其说明问题：分数掉了不说，token 还从 8.41M 涨到 11.12M——反复重建就是纯浪费。证据反馈和计划更新各自贡献 6–8 分，双状态机制不是摆设。

质量维度和定性对比

GameCraft 的四个评分维度（Core Mechanics、Content Depth、Functional Visuals、Art and Presentation）上 HoH@3 全部提升。Codex 的 Functional Visuals 从 48.67 拉到 74.23，Art and Presentation 从 45.28 到 65.28——打磨视觉和交互这类"软质量"，恰恰是最需要多轮迭代才能做好的。

图3：Momentum Lab、Kitchen Rush、Ant Empire 三个任务的对比。上面一行是 Vanilla：Momentum Lab 是扁平的几何平台加互相重叠的修饰区域；下面 HoH@3 有了主题地形、明确的目标指引和蹬墙路线。Kitchen Rush 从单一的摆盘区变成取货、备菜、摆盘、处理的完整工作流。分数上分别是 34.05→70.61、42.63→73.38、65.52→87.88。

🚀 压轴戏：6 天 70 循环，一款能玩的 FPS

基准实验之外，论文还有个让我坐直了的案例：Fusepoint，一款单人叙事向第一人称射击游戏，从一份用户提供的 PRD 和一个空目录开始，用 Codex CLI + GPT-5.6-Sol 自主开发，截至分析时跑完 70 个开发循环，跨了 6 天。

产品契约相当具体：5 分钟拆弹任务、按序占领 2 个控制点、最终目标处 3 阶段拆弹、固定 18 个敌人按 3、5、10 分布在三个交战区、成功与引爆两种结局分支。人类的介入仅限于"网断了帮忙恢复一下"——规划、实现、调试、测试、验收全程零参与。

图4：上面是活跃 issue 数的趋势线，下面是每个循环新增与关闭的 issue 计数，中间标注了各阶段的里程碑——从 Day 1 的初始灰盒、导入地图、武器手感，到 Day 3 的 HUD 与 UI、动画绑定、CG 过场，再到 Day 5 之后的敌人战斗 AI、VFX 打磨、叙事打磨，最后到 Day 6 的可玩构建。

这张图的信息量很大。活跃 issue 曲线先升后降，论文把它分成三个阶段：

到 Loop 70：共记录 81 个 issue，65 个关闭，16 个未解决，还有 17 个是关闭后被后续变更搞回归了重新打开的。重开的 issue 会同时标记失败行为和早期验证历史，让回归修复成为后续规划里的显式工作项——这正是证据状态机制在真实长程开发里发挥作用的样子。

最终产物：连贯的故事线、完整实现的战斗/武器/敌人交互、玩家引导、HUD 与菜单、过场动画、打磨过的视觉和集成音频——人类可玩。游戏本体、全部开发轨迹、游玩视频都在 GitHub 公开了。

坦率的讲，6 天无人值守做出一款能玩的 FPS，放在一年前我是不信的。当然也得泼点冷水：它依然需要人来恢复网络和 API，16 个未解决 issue 说明质量远没到"发布级"，而且单个案例没有对照组——我们不知道同一个模型用 Anthropic 式 two-agent pattern 或者别的编排方案做同样的 PRD 会是什么效果。这个案例的证明力在于"可行性"，不在于"最优性"。

🔬 批判性审视：这套东西的真实位置

吹完了，说几个问题。

创新定位要清醒。HoH 说到底是一套工程协议，不是算法突破。规划—执行—验证的外层循环、文件系统做持久记忆、角色分离，这些思想在 Anthropic 的 two-agent pattern、Ralph loop、甚至八月那篇让 harness 自我进化的 Ouroboros（arXiv: 2608.08311）里都能看到影子。HoH 的贡献在于把这些实践协议化、可复现化，并用受控实验证明了每个组件的增量价值——等预算对照和三组件消融做得很扎实，这是大多数工程博客给不了的。

评估有水分嫌疑的地方。GameCraft-Bench 只抽了 45/140 任务，FrontierSWE 只跑了 15/17，都说是计算限制，可以理解但终归是采样。另外 Dominance 是对"随机抽取的竞争对手"的胜率，对手池的构成会影响这个指标的绝对值。还有个小疑点：摘要里的 82.86% 最大相对增益在正文里没有显式归属，我是自己拿 26.90→48.98 反推出来的，论文把账算得再明白点会更好。

成本问题不能回避。HoH@3 的 token 消耗是 Vanilla 的 3.2 倍。等预算对照证明了"花得值"，但没证明"花得起"——对很多团队来说，三轮完整循环的账单本身就是门槛。而且跨 provider 的 token 统计口径不一致，论文自己也承认只能配置内比较。

非单调性是个开放问题。70 个循环里 17 个 issue 被重开，说明"改进"本身会制造回归。HoH 靠版本化历史和证据状态来兜底，但回归率随循环数增长会不会失控，论文没有给出答案。10 轮 FrontierSWE 实验里曲线还在涨，可 70 轮的真实项目里稳定化阶段是靠"功能添加放缓"换来的——这到底是框架的智慧还是框架的极限，说实话我也没想明白。

💡 我的判断

这篇论文最值钱的地方，不是某个具体数字，而是它把"多日自主开发"从玄学变成了协议。三个角色、双状态、单一写入者、独立验收、版本化历史——每一条单看都不新鲜，组合在一起并用受控实验验证增量，就成了 2026 年 Agent 工程范式的一份可参考的施工图。

对工程实践的启发很直接：

• 如果你在跑长任务 Agent，先把"开发自测"和"独立验收"分开，这是消融里价值 6 分以上的改动，成本最低；
• 进度存文件、证据入历史，别指望上下文窗口记住一切；
• warm-start 不是可选项——从空工作区重建既掉分又烧钱（11.12M vs 8.41M token）；
• 等预算下结构化循环优于无脑连续跑，编排本身就是杠杆。

往大了看，harness 工程在 2026 年已经从"给模型套壳"进化到"给壳套壳"，业内在讨论 dark factory——完全无人值守的软件工厂。HoH 的 70 循环 FPS 是这个方向目前最完整的公开演示之一。下一步真正难的问题恐怕是：当循环数从 70 涨到 700，回归率、成本和验收标准的漂移，谁来兜底？

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我