论文链接：Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement 项目主页：HarnessOfHarness 官网 发表时间：2026年9月1日（arXiv:2609.01481v1） 机构：上海人工智能实验室（Shanghai AI Laboratory，单一机构，国家级实验室） 领域标签：cs.AI / 自主软件开发 / Agent Harness
一、论文背景
1.1 从"代码补全"到"自主软件开发"
要理解这篇论文，先要理解它所处的位置。LLM 编码能力的应用光谱大致经历了三个阶段：
- 局部辅助：函数补全、单文件生成（如早期的 Copilot 式补全）——人类写主体，AI 补片段；
- 仓库级任务执行：在既有代码库里修 bug、关 issue（如 SWE-bench 系列评测的任务形态）——人类定义任务和验收，AI 在一个"有界回合"内完成；
- 自主软件开发（autonomous software development）：只给一份高层需求（“做一个第一人称射击游戏，要有剧情、战斗、菜单”），AI 从空仓库开始，独立产出完整、可运行、可交付的软件系统——全程无人类干预。
这篇论文瞄准的是第三阶段。这个跃迁的本质困难不是"代码写得更长"，而是时间跨度：构建一个完整系统需要几十次甚至上百次连续决策，开发轨迹自然拉长到数天。而 LLM agent 在长轨迹上有一组已知的失败模式：
- 遗忘：早期需求和设计决策被后续上下文挤掉，agent 修着修着就把三天前的约束改没了；
- 局部修复循环：陷入"检查-修复-又坏-再修"的重复打转，多轮迭代不产生净进展；
- 虚假完成：过早宣布完工，实际有功能缺失或错误——因为"缺什么"本身不可见；
- 回归：新改动破坏了此前已验证的行为，而 agent 不知道哪些行为"已验证"。
1.2 什么是 Agent Harness
Harness（运行架） 是环绕 LLM 的那层执行基础设施——它管理 agent 循环、工具调用、上下文、失败恢复与结果验证。一个流行的公式是"Agent = 模型 + Harness"：同样的模型权重，放进不同的 harness，任务表现可以差出十几个百分点（论文引用的例子：GPT-5 在 Terminal-Bench 2.1 上，Terminus 2 harness 里解 35.2%，Codex CLI harness 里解 49.6%）。当前主流编码 harness 包括 Codex CLI、Claude Code、OpenCode、Pi 等。
已有的 harness 优化工作（论文中提到的 AutoHarness、Meta-Harness、Self-Harness）思路是修改 harness 本身来改变 agent 行为。而这篇论文走了一条不同的路：不动 harness，在 harness 之上再套一层协议——这正是标题"Harness-of-Harness"的含义。
1.3 为什么现在研究这个问题
两个条件在 2026 年同时成熟了：其一，前沿模型的单回合编码能力已经足够强（能关真实 PR、能写多文件系统），瓶颈转移到了"长时程组织"上；其二，从零构建完整系统的评测基准刚补齐（GameCraft-Bench、FrontierSWE、ProgramBench 等 2026 年新基准），使"自主开发"第一次可以被严肃度量。供给（更强的模型）与度量（新基准）同时到位，这个问题就从演示级走向了研究级。
二、论文定位和关联工作
2.1 研究谱系图谱
HoH 处在三条研究线的交汇点：
谱系一：Agent Harness 优化。把 harness 当优化对象：AutoHarness 从环境反馈合成 harness 代码；Meta-Harness 在 harness 代码空间里搜索；Self-Harness 让 agent 诊断并修改自己的 harness。这条线的目标是"造更好的执行底座"。关键区别：HoH 不修改 harness，而是编排 harness 的多次调用——底座保持原样，上面加一层开发协议。这带来一个直接好处：方法可以即插即用地套在任意 harness 上（论文实测三套配置全部有效）。
谱系二：多智能体软件开发系统。MetaGPT、ChatDev 用预定义角色流水线做软件生成；AgileCoder、EvoDev 以冲刺或依赖特性为单位组织增量开发；EvoMAC 用测试反馈调整多 agent 工作流。这条线的局限（论文指出）：它们都工作在单个有界回合内，对"跨修订保留项目决策、已验证功能、评估证据"支持有限——即缺少跨天、跨版本的状态连续性。
谱系三：长程开发评测基准。SWE-EVO、SlopCodeBench 研究长程演化与退化；Commit0、ProjDevBench、ProgramBench、GameCraft-Bench 评测从零构建；FrontierSWE 覆盖从零实现加开放性能目标。HoH 直接选用这三个基准做试金石。
2.2 定位对比表
| 维度 | 之前路线（MetaGPT/ChatDev/EvoMAC 等） | 本论文（HoH） |
|---|---|---|
| 优化对象 | 多 agent 工作流本身 | harness 之上的调用协议（harness 不动） |
| 时间跨度 | 单回合/单项目生成 | 多迭代、多天持续改进 |
| 跨轮状态 | 主要传代码 | 双状态：制品态 A（代码）+ 证据态 ℰ（验证知识） |
| 增量单位 | 任务/角色分工 | 有界且局部完整的软件增量（可观察行为定义） |
| 验收机制 | 内部测试或最终评测 | 独立 QA 对冻结候选做白盒+黑盒验收 |
| 工作方式约束 | 常规定流程 | 只约束交付物 schema，不规定工作流 |
定位结论：HoH 是"软件工程经典方法论（迭代增量开发 + 左移测试 + 独立验收）向 agent 协议层的系统化移植"，其新颖性不在单个组件，而在组件间的状态传递结构（下文详述）。
三、问题定义
3.1 从具体到抽象
具体场景：给定高层软件需求 𝒮，让固定配置的编码 agent（模型 M + harness H）产出完整软件制品 A，且要求在数十次迭代中持续变好而不是退化或打转。
核心洞察：这个问题的深层结构是——下一个有用改动无法从需求单方面推出。它必须由三方共同决定：需求 𝒮（该做什么）、当前制品 A（现在是什么样、依赖结构如何）、执行证据 ℰ（哪些行为已验证、哪些失败未解决）。传统单回合开发只传 A，丢掉了 ℰ，于是每轮都要"从代码反推项目状态"，这正是遗忘与重复劳动的根源。
形式化：HoH 把开发建模为双状态马尔可夫过程：
$$(A_{t-1}, \mathcal{E}_{t-1}) \xrightarrow{\text{loop } t \text{ under } \mathcal{S}} (A_t, \mathcal{E}_t)$$- A（artifact state，制品态）：当前代码、配置、资源、项目元数据——“软件现在是什么”；
- ℰ（evidence state，证据态）：对 A 按 𝒮 与当轮目标评估所得的已验证行为、未证实声明、待修失败——“我们知道了什么”。
两者不可互相替代：A 是开发的操作对象，ℰ 是指导开发的验证知识。这个抽象的精妙之处在于：它把"持续改进"从模糊的工程愿望变成了可定义的转移函数——好的循环 = (A, ℰ) 联合单调不劣（消融实验将证明 ℰ 的传递贡献了 6.28 分）。
3.2 三大挑战与问题对应
论文识别的三个挑战与抽象结构的对应：① 长轨迹遗忘 → 需要显式跨轮状态（A+ℰ）；② 下一步欠定 → 需要项目级视角做有界目标选择；③ 隐藏的缺失行为 → 需要独立于实现者的验收方。
四、问题解法
4.1 总体架构：三角色 × 一次循环
HoH 的每轮循环依次调用同一个 harness-模型配置三次，分别扮演三个角色：
轮 t:
Project Planner(S, ℰ_{t-1}; 只读 A_{t-1}) → 开发文档 D_t
Developer(A_{t-1}; S, D_t) → 新制品 A_t
QA Tester(只读 A_t; S, D_t, Runtime.check) → 证据态 ℰ_t
一个确定性的 Runtime 契约控制每个角色能读什么、能写什么、必须交付什么 schema 的产物（违规触发重试）。注意：HoH 约束交付物而不规定工作流——agent 在边界内自由选择推理路径、工具与实现策略。这类似于管理上"定验收标准，不定操作手册"。
4.2 Project Planner：把竞争需求变成有界目标
Planner 综合全局需求 𝒮 与上轮证据 ℰ，产出开发文档 D_t，定义本轮增量的范围与验收条件。两个关键设计：
- 有界（bounded）：一轮只改一组相关的事情，限制无关行为的变更面——失败时容易定位；
- 局部完整（locally complete）：所选能力必须连带使其可运行、可测试的全部相关改动（可以跨多文件）——避免"半成品增量"。
增量的边界由"一个连贯的可观察行为"定义，而非文件数。不相关重构与顺手加功能被明确排除在外。Planner 只能读 A 不能改——目标必须落地成 D，而不是亲手写码。
4.3 Developer：单写者 + 左移测试
只有 Developer 能改制品（单写者边界），从 A_{t-1} 热启动。实现前先为目标行为建基线，每做一次有意义的改动就重跑对应路径、检查受影响的实现与回归面——这是软件工程里经典的 shift-left testing（左移测试）：让测试尽可能靠近引入变更的位置，缩短"犯错-发现"的距离。需要强调：Developer 的自测只回答"这个候选能不能拿出来"，不构成验收。
4.4 QA Tester：对冻结候选的独立验收
QA 阶段回答"需求是否真的被满足"：
- 冻结与只读：A_t 被冻结为只读候选——评估期间实现不能变，每条观察绑定唯一候选身份（防"拼凑不同版本的行为"），QA 也不许悄悄修它评的东西；
- 场景化验收标准：从 𝒮 与 D_t 推导当轮场景特定的可检验标准，而非千篇一律的通用测试；
- 黑盒 + 白盒互补：黑盒从普通输入与渲染输出检验用户可观察行为；白盒查源码、配置、资源绑定、运行日志，用于诊断与佐证黑盒无法判定的内部条件；
- 缺口而非推断：观察到的失败、未满足需求、回归、证据不足一律记为 gap，绝不推断为成功。
产出的结构化测试报告就是 ℰ_t，交还下一轮 Planner——闭环完成。
4.5 跨轮信息管理的其余机制
- 渐进披露（progressive disclosure）：计划、报告、历史等工件持久化在文件系统，先以简明分类索引暴露，需要时才取细节——替代独立记忆模块，不撑爆上下文窗口；
- 按角色组织工具：MCP 服务器、专家模型、领域算法按角色挂载，轻量 Markdown skill 提供随用随取的操作指引；鼓励复用既有资源而非重复造轮子；
- 版本化历史：角色级与迭代级双粒度版本记录，大回归后可回退到已验证状态，同类失败复发时可援引早先证据辅助诊断。
五、评估指标与实验证据
5.1 实验设计的证明逻辑
论文要证明的主张是：HoH 协议（而非某个特定模型或 harness）能让固定配置持续改进软件。证明力来自三层设计：① 跨三个 harness-模型对（最强的 Codex+GPT-5.5(high)、中间的 OpenCode+DeepSeek-V4-Pro、较弱的 Pi+MiniMax-M3）复现——排除"只在某模型上灵"的质疑；② 跨三个互补基准（游戏生成/仓库级工程/程序重建）——排除"只适配某类任务"；③ 严格对照——Vanilla（同配置单次开发）与 HoH@T 使用相同初始状态、相同 harness-模型，唯一差异是是否套 HoH 协议；评测器输出不回流开发循环（防评测泄漏）。
5.2 基准与指标
| 基准 | 任务形态 | 规模（本文取样） | 指标 |
|---|---|---|---|
| GameCraft-Bench | 从自然语言规格构建完整可玩 Godot 游戏 | 140 任务分层抽样 45（15 游戏族×3） | Overall（0-100，编译失败=0；核心机制/内容深度/功能视觉/美术呈现加权） |
| FrontierSWE | 从零实现+性能工程+研究目标 | 17 任务取 15（4 Impl/9 Perf/2 Research） | 官方 verifier 奖励均值 + Dominance（对 12 个配置随机对手的胜率） |
| ProgramBench | 净室程序重建（只给可执行文件与文档） | 全量 | Avg. Test Pass Rate（隐藏行为测试通过率） |
5.3 主结果（HoH@3 vs Vanilla）
| 配置 | GameCraft Overall | FrontierSWE 奖励 | FrontierSWE Dominance | ProgramBench 通过率 |
|---|---|---|---|---|
| Codex+GPT-5.5(h) | 49.58 → 71.52 (+21.93) | 0.31 → 0.54 | 44% → 71% (+27pp) | 60.41 → 66.50 (+6.09) |
| OpenCode+DS-V4-Pro | 26.90 → 48.98 (+22.08) | 0.23 → 0.31 | 25% → 44% (+19pp) | 45.27 → 57.56 (+12.29) |
| Pi+MiniMax-M3 | 42.16 → 58.78 (+16.62) | 0.26 → 0.55 | 35% → 64% (+29pp) | 35.83 → 52.68 (+16.85) |
三次迭代平均相对增益 52.25%，最大 82.86%。三个关键附加观察：
- 单调性：GameCraft 上三个配置的分数从 HoH@1→@3 全部单调上升（OpenCode 的增益 1.71→13.42→22.08 逐轮放大）；
- 十轮持续改进：FrontierSWE 上 Codex 配置的 Dominance 十轮从 44%（Vanilla）→ 58% → 60% → 71% 持续爬升，奖励从 22% 到 72.67%——证明这不是三轮红利而是可持续的组织方式；
- 弱者受益更大：Vanilla 越弱的配置（OpenCode/Pi）在 ProgramBench 上增益越大（+12.29/+16.85 vs Codex 的 +6.09）——协议补足的是组织能力，对模型能力不足的配置边际价值更高。
预算控制对照：给 Vanilla 三次连续开发通过（而非一次），HoH@3 仍全面占优——排除"多跑几遍自然更好"的解释。
5.4 消融实验（GameCraft，Codex 配置）
| 变体 | 得分 | 相对 Full | Token/任务 |
|---|---|---|---|
| w/o Plan Update（冻结首轮开发文档） | 63.39 | −8.13 | 7.56M |
| w/o Evidence Feedback（重规划不看执行证据） | 65.23 | −6.28 | 7.46M |
| w/o Warm-Start（每轮从空仓库重建） | 63.67 | −7.85 | 11.12M |
| Full HoH@3 | 71.52 | — | 8.41M |
三个机制各贡献 6–8 分；去掉热启动还让 token 消耗暴涨 32%（11.12M vs 8.41M）——重建既有实现的浪费被量化。w/o Warm-Start 变体恰好就是"传统单回合系统串起来"的形态，它比 Full 低 7.85 分，直接证明双状态传递（而非简单的多次调用）才是增益来源。
5.5 多日自主开发案例
基准之外，论文用 70+ 迭代、多天的自主运行，从一份高层产品需求出发产出完整 FPS 游戏：连贯剧情、完整战斗/武器/敌人交互、玩家引导、HUD 与菜单、过场动画、美术与音频集成——人类可玩。此案例中 HoH 额外挂载了角色专用工具与 skill（引擎交互、素材获取生成、参考检索、测试、项目状态管理），每阶段产物与开发轨迹公开于 GitHub，全轨迹可追溯。该案例回答了基准回答不了的问题：这套协议在"无官方评测器"的开放环境下能否维持连贯进展——答案是能，且退化时可回退。
六、效果优势的根源解释
对比对象：Vanilla（同 harness-模型的单次开发）——它曾是有效范式，因为在单回合内，harness 自带的 agent 循环（探索-编辑-测试）足以完成有界任务。
Vanilla 的根本局限：不是"能力不够"，而是信息结构缺陷。单回合开发中，“下一改什么"的判断只由需求与当前代码决定，三轮信息被丢掉：(1) 哪些行为已被验证（应保护）；(2) 哪些失败尚未解决（应优先）；(3) 此前决策为什么这样定（应遵守）。于是长轨迹上的每个新决策都是在"信息真空"里做的局部合理选择——遗忘、打转、回归不是模型笨，而是决策输入缺失的结构性后果。
HoH 的机制因果链：
- 有界增量 + Planner/Developer 分离 → 每轮变更面小且目标显式（D_t 有验收条件）→ 失败可归因到单轮目标 → 修复不再发散（对应 GameCraft 各质量维度全面提升 11–35 分，无短板效应）；
- 独立 QA + 冻结候选 → 验收不依赖实现者的自我声明，且每条证据绑定唯一候选 → “虚假完成"被结构性堵死（对应 FrontierSWE 的持续十轮改进——每个 ℰ 都是可信的，Planner 才能在正确信息上排优先级）；
- 双状态传递（A + ℰ） → 后轮热启动于已验证制品 + 结构化验证知识 → 消除重复劳动与回归失忆（消融：去掉 ℰ −6.28 分；去掉热启动 −7.85 分且 token +32%——两条信息流各自独立贡献，缺一即退化到"多次单回合"水平）；
- 约束交付物而非工作流 → agent 保留推理与工具自主性 → 协议的收益不依赖模型服从死板流程（三个能力档位模型全部受益，弱模型受益更大——组织能力对能力短板的替代弹性）。
反事实自检：如果去掉独立 QA（让 Developer 自测自验收），会怎样？论文的预算控制对照给出了部分答案的影子——多次盲目开发的 Vanilla Continuation 显著劣于 HoH；结合 trajectory-judge 类工作（outcome-only 验收对静默错误漏检 55%）可推断：无独立验收时 ℰ 会被实现者偏见污染，优先级排序失真，多轮迭代将放大而非修正错误。
七、必要知识反推
假设让一个完全没有背景的人复现这项工作，最少需要掌握：
领域知识层
- Agent harness 的构成与作用边界：知道"模型外的一切执行基础设施"叫 harness、知道 Codex/OpenCode/Pi 等可编程调用的接口——否则无法把协议"套"在 harness 上（这是方法可移植性的前提）；
- LLM 长轨迹失败模式的实证文献：遗忘、打转、虚假完成、回归——不掌握这组现象，就无法论证"为什么需要一层协议而不是更强的模型”。
方法论知识层
- 迭代增量开发（IID）：有界增量、局部完整、每增量可验证——HoH 的增量单位定义直接取自这套经典方法论；
- 左移测试：基线-变更-复测循环——Developer 内嵌测试的设计来源；
- 验收与实现分离的测试理论：黑盒/白盒互补、缺陷记为 gap 而非推断通过——QA 角色的验收标准设计来源；
- 多 agent 角色分工的先例（MetaGPT/ChatDev 等）：知道前人怎么分角色、局限在哪（无跨轮状态），才能定位"缺的是状态传递而非更多角色”。
工程知识层
- 确定性 Runtime 契约：用 schema 校验 + 权限控制实现"约束交付物"——需要工程化的输入冻结/只读/重试机制；
- 渐进披露的上下文管理：索引 + 按需取用，替代记忆模块——需要文件系统级的工件组织；
- 评测协议设计：同配置对照、评测输出不回流、bootstrap 置信区间、Dominance 胜率——保证"是协议的功劳"可被归因。
知识融合的关键节点：这项工作真正的创造性融合点，是把软件工程的三件古典工具（IID、左移测试、独立验收）翻译成 agent 可执行的状态转移协议——识别出 (A, ℰ) 双状态这个抽象，让古典方法论从"人类团队的纪律"变成"机器循环的算法"。没有领域知识会错判问题，没有方法论知识会重复造轮子，没有工程知识则落不了地。
八、论文中可以提取的通用性灵感
灵感一：约束交付物，不约束工作流
- 核心思想：对自主系统规定"必须交出什么"（schema 化的产物 + 违规重试），比规定"怎么干"更能保住质量下限，同时不扼杀上限。
- 论文证据：HoH 对三个角色只施加产出契约，推理路径全自由——三档模型全部受益且弱模型受益最大。
- 推广场景：人机协作的内容生产（验收标准替代流程管控）；分布式团队/外包管理（接口契约化）；RL 的动作空间设计（约束输出分布而非轨迹）；API 经济中的服务等级协议设计。
灵感二：双状态传递——对象状态与认知状态要分开传
- 核心思想：跨时段复杂工作中，“工作成果”（制品）与"关于工作的验证知识"（证据）是两类独立资产，只传前者必然导致下一周期的决策在信息真空里做。
- 论文证据：w/o Evidence Feedback −6.28 分、w/o Warm-Start −7.85 分 + token +32%——两条信息流各自独立贡献。
- 推广场景：交接班制度（工作台账与实物分开交接）；多阶段科研项目（数据资产 + 实验结论台账）；企业知识管理（文档库 ≠ 验证过的决策依据库）；编译器/构建系统的产物缓存 + 依赖元数据。
灵感三：验收者必须冻结被验对象且不得修复它
- 核心思想：评估与修复混在同一主体上会产生系统性偏差（实现者倾向自我通过、验收者倾向顺手修复）。冻结候选 + 只读评估 + 缺口记录，是获得可信评估的最小制度设计。
- 论文证据：QA 只读冻结候选，观察绑定唯一候选身份，“证据不足"一律记 gap；这是 FrontierSWE 十轮持续改进（22%→72.67%）的信息基础。
- 推广场景：代码评审（评审者不直接改码）；审计与合规（审计独立性原则）；AI 评测系统（judge 不得接触被评系统的修改权）；科学同行评审（投稿冻结制度）。
灵感四：弱底座 + 强组织的替代弹性
- 核心思想：当个体能力不足时，组织层协议（分工、验收、状态管理）的边际价值更大——“流程红利"与"能力红利"存在替代关系。
- 论文证据：Vanilla 越弱的配置在 ProgramBench 上增益越大（Pi +16.85 vs Codex +6.09）。
- 推广场景：初创团队 vs 大厂的组织设计；教育中的脚手架教学；低算力场景下的 multi-agent 编排（弱模型 + 强协议可能是性价比路线）；自动化运维的 runbook 工程。
灵感五：让失败可归因的"变更面控制”
- 核心思想：把每轮变更限制在"一个连贯可观察行为"内，是把系统调试从"全局搜索"降为"局部定位"的关键——增量边界应由行为定义，而非文件数或工作量。
- 论文证据：有界且局部完整的增量设计 + 单写者边界，使 GameCraft 四个质量维度均衡提升（无互斥 sacrificed 维度）。
- 推广场景：微服务的发布粒度设计；实验科学的多变量控制（单变量原则）；feature flag 的灰度切分；立法/政策改革的渐进推进。
本文基于 arXiv:2609.01481v1 全文（含方法、全部实验、附录协议与消融）撰写。基准数据：GameCraft-Bench (arXiv:2606.17861)、FrontierSWE、ProgramBench。