AI编程 这几年进步很快，已经能自己改仓库、调工具，也会排查局部的报错。
可任务一拉长，毛病就攒起来了。
需求漏了。
工作重复了。
改一处又坏一处，验收也跟着出错。
现在的 AI工具 不少。
AI对话 也早就让人和机器能聊上几句。
难的是让它们连着干几天活，还不跑偏。
上海人工智能实验室有一篇新论文，把这个过程拆开看了。
做法叫 Harness-of-Harness，简称 HoH。
思路不复杂。
把现成的编程智能体，组织成一个反复跑的流程。
先规划，再开发，最后独立验收。
轮次之间，代码状态和测试证据都留着。
作者在三个软件开发基准上，试了三种模型搭配。
三轮迭代下来，平均相对提升 52.25%。
另外还拿一个跑了 70 轮的第一人称射击游戏，做了长周期考察。
论文的价值，主要在智能体的执行协议、状态管理和验收机制。
它没有重训底层模型。
也没有证明任意复杂的软件都能无人值守做完。
长周期开发为什么容易失控
短任务里，改了什么我们当场看，下一步做什么也当场定。
可交互一延长到几十轮，项目状态就不再等于最新那份代码。
哪些需求还没做，某次修复为什么失败，哪些功能已经验过。
这些信息散在早期对话和临时日志里。
新一轮智能体只读当前仓库，就得自己重新推断。
还有一个常见毛病。
局部错误，比整体需求更容易被看见。
智能体可能连着好几轮，围着同一处异常修。
或者功能还没齐，就把代码能跑当成需求做完。
功能加得快，改动范围跟着涨。
已有行为就开始回归。
HoH 的回应是几条规矩。
每轮只挑一个能检查的开发增量。
开发者自己实现，自己初测。
再由独立的一方，去检查冻结版本的软件。
最后把结果交给下一轮规划。
这套安排借的是增量开发、持续测试，还有职责分离这些老办法。
论文的贡献，是把它们落成一套能重复执行的协议。
再去比它到底影响多大。
三种职责，两类状态
一次 HoH 迭代里，规划者拿着产品需求、当前代码和上一轮证据。
它挑出一组相关任务，写成开发文档。
任务要够小，方便定位故障。
又要功能完整，能靠可观察的行为验收。
文档里还会写清，哪些是此前验过、这次改了也不能碰坏的行为。
开发者从现有项目接着做，有权改软件产物。
实现方案和调试工具都自己挑。
改前改后，各测一遍。
验收者随后上场，检查被冻结的候选版。
它一边做黑盒交互测试，一边翻白盒的源码、配置和日志。
每一条要求，都要记下证据、缺口和回归。
验收者不能直接改正在验收的产物。
这样报告对应的，才是一个确定的版本。
这三个角色，在论文实验里是同一套配置的三次独立调用。
靠不同的提示词、不同的输入上下文和不同的运行权限，来分职责。
所谓独立验收，指验收和实现隔开。
它并不代表换了另一个模型，也不代表请了外部的人来审。
运行环境还管着角色的输入、读写权限和结构化输出校验。
规划改了什么，验收谁负责，边界能一路追下去。
HoH 在轮次之间保留两类状态。
一类是产物状态，装着当前的源码、资源，还有配置和项目元数据。
它说明软件已经实现了什么。
另一类是证据状态。
它记着测试观察、已验证行为，还有未满足的要求和待处理故障。
说明哪些结论有依据。
给定一个需求，一次迭代能写成一条式子。
这段公式截图没抓到，大意是代码被继承，证据参与下一轮决策。
单靠代码历史，系统未必知道验收的约束在哪。
单靠测试报告，开发者又缺一个能继续改的项目。
为了不把全部历史塞回上下文，HoH 把计划、报告和开发记录存进文件系统。
先露一个分类索引，要用哪条再读哪条。
角色相关的工具和技能，也是按需给。
长周期那个案例里，版本记录用来追溯改动和故障。
这里要分清一点。
论文的主要基准实验，并没有额外引入案例专用的工具、技能和版本控制。
所以基准上的提升，主要反映的还是这套协议本身。
实验是怎么做的
论文用了三套任务。
第一套叫游戏生成基准，要求照着自然语言做出能玩的游戏。
它抽了 45 个任务，综合打分 0 到 100。
第二套覆盖软件实现、性能优化和研究任务，用了 15 个。
第三套要求照着编译好的程序和文档，把软件重建出来。
再拿隐藏的行为测试来评。
主实验拿一次常规开发做对照，跟三轮迭代比。
九组模型搭配乘基准的比较里，三轮那套的汇总指标，全都高过对应的单次开发。
提升多少，按任务和配置不一样。
游戏生成那边，进步还体现在机制、内容，还有画面呈现这些分项上。
所以能支撑一个范围明确的判断。
在论文覆盖的项目构建和程序重建任务里，固定底层模型，只改运行协议，也能把最终软件的质量往上抬。
不过三轮要比单轮花更多推理预算。
为了排除多跑几次自然更好的解释，作者另设了一组对照。
沿用一个智能体会话，继续跑第二、第三轮。
但不给它角色分工和证据反馈。
用某款前沿模型在游戏基准上试，结果是下面这样。
同为三轮开发，三轮那套拿到 71.52 分。
续跑对照只有 58.24 分。
三轮那套两轮用掉约 567 万词元，得 64.84 分。
续跑对照三轮用掉约 633 万词元，得 58.24 分。
这组对照说明，质量差距没法完全用开发轮次或者词元总量来解释。
但也要说清楚，这里三轮那套其实用了更多词元。
论文也没证明，它在所有任务和预算下都是最省的路子。
消融实验又拆了一层，看跨轮次机制的作用。
还是那款模型，还是游戏基准的三轮开发。
移除任一机制，平均质量分都会降。
最狠的是取消代码继承，分数掉了，词元消耗还涨到 1112 万。
至少在这组任务里，攒下已有的实现，照着测试证据改计划，确实比反复从头建更管用。
这三项机制是互相配合的。
不过消融实验没有把它们的交互作用拆干净，我觉得这一点还能再细看。
70 轮的游戏，和还在的回归
作者还让 HoH 从一份产品需求文档和空项目出发，做一款单人的第一人称射击游戏。
需求里有几分钟的拆弹任务，要依次占下两个控制点。
拆弹分三段。
三个交战区里放 18 名敌人，结局有成功和爆炸两种。
系统用的是某款编程智能体，加一个开源游戏引擎。
另外配了引擎操作、素材处理，还有界面和测试这些专用工具。
论文说人工介入只涉及恢复网络或接口可用性，没参与具体的规划、编码，还有调试和验收。
70 轮的记录，变化挺清楚。
前 27 轮主要在搭可执行的项目和核心交互，同时把缺失的需求和缺陷抖出来。
中间 28 到 49 轮一直在加功能，修复的活也慢慢变多。
后期功能趋于完整，更多迭代花在稳定性和回归上。
到第 70 轮，项目一共记下 81 个问题。
65 个关掉了，16 个还开着。
另有 17 个问题，是关掉之后又被打开。
这些回归说明，长周期自主开发还是会弄坏已经验过的功能。
HoH 能派上用场的地方，是把回归和先前通过的验证记录挂上钩。
下一轮规划能直接处理已知的失败，不用只凭最新代码去猜问题是怎么来的。
这个案例说明，HoH 能扛住几十轮的软件状态和迭代，也做出了能玩的游戏。
它还是一个特定引擎、特定需求下的案例。
项目到观察截止时，还有没解决的问题。
论文也没有把它推广成通用的商业软件交付能力。
我觉得它的研究问题选得准。
编程智能体在长任务里，会遇到规划漂移、信息遗失和回归。
这些问题，不会因为单次代码生成变强就自己消失。
HoH 把它们转成了能检查的工程约束。
一轮只做能验收的增量。
只有开发者能改产物。
验收针对冻结版收证据。
下一轮，拿现有代码和证据当起点。
设计没复杂到讲不清。
要复现，也能较清楚地定位每个部件的作用。
但算法层面的原创性相对有限。
分工开发、增量迭代都有研究和工程的底子。
持续测试、文件化记忆也一样。
论文比较强的部分，是把它们组合成固定协议。
再用跨模型、跨任务，还有预算对照和消融实验去检验效果。
按这个标准，它更偏系统工程的方向。
这个方向我觉得还是值得读。
从产品实现角度看，HoH 能对上现有的工程设施。
规划负责划增量和验收条件。
开发者改代码工作区。
测试结合持续集成、运行时检查和交互测试出证据。
问题和版本历史，留着待办、回归和已验证功能。
不过这是我的总结，不是论文在企业研发环境里做过的实证。
真到跨团队协作、数据库迁移，或者安全治理和线上发布，还得单独设计和验证。
想复现，可以从论文的核心章节和附录入手。
先把跨轮次状态、冻结版的验收，还有同预算下的基线比较跑通。
再考虑加行业专用工具。
对做智能体运行环境的人来说，这几个机制，比照搬三段角色提示词更值得投实验资源。
论文地址：https://arxiv.org/html/2609.01481
