不换模型，编码智能体提升 52%：上海 AI 实验室的 HoH 迭代循环

当一个编码智能体写了一个功能，修它的时候弄坏了另一个，然后又因为检查自己工作的也是它而没有察觉 —— 这不是模型问题。这是流程问题。上海人工智能实验室的一个新框架认为，合适的解法不是更大的语言模型，而是围绕团队已经在用的那个模型搭一套不同的组织结构。

这个框架叫 Harness-of-Harness，简称 HoH。它在一份2026 年 9 月 1 日提交的 arXiv 预印本中有所描述：把现有的编码智能体 harness 包进一个外层的规划-编码-测试循环，在迭代之间加入持久状态，并把规划代码、编写代码和验证代码的角色分离成不同的智能体 —— 每个都对项目只有刻意受限的视野。在三个基准和三种 harness-模型配置上，HoH 相对于不带外层的同一批智能体平均取得 52.25% 的相对提升，最高 82.86%。在一个为期五天的案例研究中，该系统在 70 多次迭代中无人干预地做出了一款可玩的第一人称射击游戏。

为什么编码智能体在长项目上会停滞

提交的论文指出了编码智能体长期做一个项目时特有的四种结构性失效模式。需求失忆，指随着长会话中上下文被压缩，早期的架构决定和此前的修复丢失。功能回退，指一个局部看起来有效的改动悄悄破坏了代码库中别处的行为。开发停滞，描述的是反复验证已经确认的组件、而不是推进实现的模式。而过早完成 —— 可以说是四者中最危险的 —— 发生在智能体宣告成功却没有暴露缺失的功能，交付一个结构上不完整的系统时。

这些失效模式有一个共同的根源：在单会话的智能体运行中，写代码的智能体同时评估自己的工作，会话的上下文是有限的，而没有任何东西把经过验证的行为证据带到下一轮。增加推理算力解决不了底层架构的问题。

这个框定很重要，因为它重新定向了工程问题。2025 年和 2026 年初的主流直觉是，更长的上下文窗口或更强的模型终将解决多文件、多日的工程任务。HoH 反驳这一直觉的核心证据是一次直接的 token 预算对比：一次两轮的 HoH 运行用了 567 万 token，在 GameCraft-Bench 上得 64.84 分；而同一个原版 harness 连续跑三遍、用了 633 万 token，只得 58.24 分。结构性的框架胜过了更多的算力。

三角色循环：HoH 如何工作

HoH 的每次迭代依次运行三个不同的智能体，各自使用一次独立的 harness-模型调用，权限严格分区。

第一个是项目规划者接收最初的软件规格、当前的工件状态，以及此前所有 QA 评估累积的证据。它为下一个增量产出一份有边界的开发文档 —— 选定一个局部可完成的目标，在修复遗留问题和交付一项新能力之间取得平衡。关键在于，规划者不能写工件；它是只读的。这防止了规划者在读取当前状态时锚定在自己的实现假设上。

第二个是开发者接收开发文档和当前工件，但不直接接收此前的证据流 —— 这个设计选择减少了对以往测试运行中陈旧假设的锚定。开发者是唯一对项目有写权限的角色，并采用左移测试：一个伴生的测试工具在写代码的同时并发运行，实时暴露回退，而不是把它们攒到之后的评估阶段。

第三个是QA 测试者评估工件的一个冻结的只读快照。它不能修改它所测试的东西。它同时使用黑盒评估（检查运行时行为和渲染输出）和白盒检视（阅读源码和运行日志），产出一份结构化的证据包 —— 记录什么能用、什么坏了、什么缺失。没有测试结果支撑的说法被记为缺口，而不是当作成功。QA 测试者产出的证据状态，是带到下一次迭代的两个量之一。

带到下一轮的另一个量是工件状态本身 —— 当前迭代结束时的代码、配置文件和资源。因为开发者从上一个工件热启动，每一轮都直接建立在已确认的先前工作之上，而不是从对话历史重建上下文。论文显示，去掉热启动会让 GameCraft-Bench 分数下降 7.85 分，token 消耗增加约 32%（Codex 加 GPT-5.5 三次迭代从 841 万 token 增至 1112 万），因为从上下文重建工件比从存储的文件恢复要花多得多的推理。

每次迭代的所有工件改动都提交到 Git，形成带版本的检查点历史。当一次 QA 评估判定当前迭代退步到上一个已验证状态之下时，框架回滚到那个检查点，并把这次回退作为一个有记录的问题纳入下一个规划周期。在 Fusepoint 案例研究中，81 个被跟踪的问题里有 17 个因后续改动引入的回退而被重新打开 —— 每一个都是由独立的 QA 测试者揭示的，而不是由开发者审查自己的输出发现的。

论文从这套架构中提炼出五条设计原则。计划必须在修复遗留问题和增加一项新能力之间平衡 —— 纯修复循环和纯功能添加各自会产生特征性的失败模式。改动必须小到足以确认它不会破坏既有的已验证行为。实现时的测试（开发者的伴生工具）必须与评估（QA 测试者的证据包）分开。框架约束的是可验证的输出格式，而不是规定智能体的内部推理。版本历史使得候选迭代降低整体系统质量时可以回滚。

基准：三个任务，三种配置

HoH 的评估测试了三组 harness-模型搭配 —— Codex 加 GPT-5.5（high）、OpenCode 加 DeepSeek-V4-Pro、Pi 加 MiniMax-M3 —— 覆盖三个为考察端到端自主软件开发的不同维度而设计的基准。

GameCraft-Bench测试编码智能体能否根据自然语言规格在 Godot 引擎内做出一款完整、可玩的游戏。该基准包含 15 个游戏族的 140 个任务，用回放演示和评分标准引导的多模态评判来评估。它衡量的不只是智能体能否生成语法有效的代码，而是产出的工件能否作为一款可交互的游戏运行。该基准于 2026 年 6 月发布；发表时，最强的单轮智能体在总体指标上得分约 41%，意味着多数智能体难以交付机制连贯、有视觉反馈、呈现一致的游戏。

在 GameCraft-Bench 上，最强的 HoH 配置 —— Codex 加 GPT-5.5（high）—— 从 49.58（原版基线）升到 HoH@3 的 71.52，提高 21.93 分。OpenCode 加 DeepSeek-V4-Pro 从 26.90 升到 48.98（+22.08 分），Pi 加 MiniMax-M3 从 42.16 升到 58.78（+16.62 分）。值得注意的是，较弱的基线按比例获益更多，表明 HoH 的结构部分弥补了 harness 的不足。

FrontierSWE在超长周期的软件工程任务上评估智能体 —— 开放式的实现、性能和研究问题，每个任务最多给 20 小时。它使用一种支配率指标：给定配置在多次试验的两两对比中获胜的比例。在 FrontierSWE 上，三组 harness-模型搭配的提升都很可观：Codex 从 44% 支配率升到 HoH@3 的 71%；OpenCode 从 25% 到 44%；Pi 从 35% 到 64%。性能在三次迭代时并未见顶 —— 在 FrontierSWE 上把 Codex 跑到 HoH@10，支配率推到 72.67%，而原版连续运行为 27.33%。这是论文最重要的发现之一：迭代循环在十个周期里持续累积增益，没有饱和。

ProgramBench提出一个洁净室重建任务：智能体只拿到一个编译好的可执行文件和使用文档，必须从零搭建一个代码库来复现该二进制的行为。它用智能体驱动的模糊测试生成的隐藏行为测试，评估平均测试通过率。ProgramBench 上所有配置都有正向提升：Codex +6.09 个百分点，OpenCode +12.29，Pi +16.85。

消融研究分离出了每个组件的贡献。在 GameCraft-Bench 上用 Codex 加 GPT-5.5，去掉计划更新（初始创建后固定计划）损失 8.13 分。去掉热启动（强制每次迭代从上下文重建工件）损失 7.85 分并增加 token 消耗。去掉证据反馈（不让规划者读取先前的 QA 结果）损失 6.28 分。没有哪一个机制单独产生全部增益；框架需要三者协同工作。

Fusepoint 案例研究：五天、70 次迭代、零人工提交

为了在受控的基准条件之外检验 HoH，作者用 Codex CLI 加 GPT-5.6-Sol（high）在 Godot 4.7 中跑了一次为期五天的自主部署。规格是一份描述玩家可感知内容的产品需求文档：一个五分钟的拆弹任务、两个顺序的控制点目标、十八个带 AI 行为的敌方单位，以及两个叙事结局分支（成功拆除与爆炸）。所有工程决定 —— 任务排序、架构选择和验收标准 —— 都由框架决定。

开发轨迹分为三个阶段。第 1 到 27 次迭代建立了可执行的骨架；核心系统搭建期间问题集中在这一阶段。第 28 到 49 次迭代并行进行功能开发和回退修复，问题积压有波动但没有增长。第 50 到 70 次迭代进入稳定阶段，随着 QA 测试者的证据包发现的新缺口越来越少、已有缺口不断关闭，活跃问题数逐步下降。

在 70 多次迭代中，HoH 跟踪了 81 个独立问题，关闭 65 个，留下 16 个未解决，并标记了 17 次回退 —— 即某次迭代中通过 QA 的改动在之后的迭代里破坏了先前已验证的行为。每次回退都被记为一个有记录的问题，而不是在无人察觉中悄悄退化。最终的游戏 Fusepoint 包括渲染的 3D 环境、完整的武器系统、空间音频、体积云与光照效果，以及最初 PRD 中规定的叙事分支结构。项目完整的提交历史、每次迭代的开发文档、问题列表和 QA 证据包都在仓库中公开可查。团队还用同一框架做了一款像素风 roguelite 游戏 Mournlight 和一款生产力应用 Focusboard。

HoH 不替代什么

HoH 不修改底层的编码智能体 harness。MetaGPT 和 ChatDev 这类系统在内部规定角色工作流，需要采用整条流水线。同一时期的相关论文 Self-Harness 演化的是 harness 本身 —— 优化脚手架结构，而不是围绕既有的脚手架组织开发。HoH 的架构选择是有意保守的：它把 harness 当作固定的基底，这意味着使用 Codex CLI、OpenCode 或 Pi 的团队可以在不重写智能体配置的情况下采用这个外层循环。

这些增益也不依赖于前沿模型的访问权。Pi 加 MiniMax-M3 —— 三组测试组合中最弱的 —— 在 FrontierSWE 上显示出最大的比例提升（支配率 +29 个百分点）。这表明框架的价值不取决于是否使用最强的可用模型；它解决的是影响任何迭代式编码智能体的流程失效模式。

HoH 尚未回答的是，证据状态的累积在十次迭代之外如何扩展。论文只在 FrontierSWE 上测试了 T=10；GameCraft-Bench 和 ProgramBench 上最多评估到 T=3。当证据包在几十次迭代中不断增长 —— 正如 Fusepoint 部署中那样 —— 管理它的结构、相关性权重和检索效率就成了当前论文留下的设计问题。论文摘要与正文之间模型名称的不一致（alphaxiv 指出正文写 GPT-4o、摘要写 GPT-5.5）值得对照最终发表版本核实。

接下来会怎样

上海 AI 实验室已表示计划发布 HoH-lite，一个旨在降低采用门槛的核心工作流轻量实现。项目页面列出了更多即将推出的展示案例。框架的增益对特定领域或安全攸关的软件是否成立 —— 那里 QA 测试者的黑盒和白盒评估必须换成领域专属的测试套件 —— 是一个对企业部署有直接影响的开放研究问题。

这篇论文最深的含义或许在组织层面而非技术层面。多年来，编码智能体的基准提升由模型改进驱动：更好的推理、更长的上下文、更多的训练数据。HoH 的消融证据表明，角色分离、证据持久化和带版本的回滚各自独立地为多日自主开发的表现做出贡献。至少对这类长周期任务而言，瓶颈似乎是智能体会话之间缺少一种持久的机构记忆 —— 而不是模型在任何单次会话内的能力。