长任务 Agent 如何保存净进展

原文：Harness-of-Harness: A General Framework for Iterative Agentic Software Development（2026-09-01）。

一、它解决的不是“Agent 能否继续跑”，而是“继续跑是否仍在积累价值”

长时间运行常被简化为更大的上下文窗口、更多 Token 或自动 continuation。但这些手段只延长了执行时间，没有回答四个工程问题：

上一轮究竟交付了什么稳定结果？
哪些能力已经通过独立验证，哪些仍只是开发者自述？
失败后从哪里恢复，如何避免重复探索？
下一轮为什么应该做这件事，而不是继续扩张任务范围？

HoH 的回答是把“继续对话”改造成“推进一个版本化开发过程”。系统每轮处理的核心对象不是对话历史，而是制品状态与证据状态：

(At−1,Et−1) →S,loop t (At,Et)

其中，A 是代码、资源、配置与可运行构建等制品；E 是测试结果、验收报告、失败轨迹与未解决风险。规格 S 在整个运行期间保持稳定，避免目标在迭代中悄然漂移。

flowchart LR S[稳定规格 S] --> P[Planner\n读取制品与证据] A0[(Artifact Aₜ₋₁)] --> P E0[(Evidence Eₜ₋₁)] --> P P --> I[有界增量 Iₜ] I --> D[Developer\n唯一写入者] D --> A1[(候选制品 Aₜ)] A1 --> Q[Independent QA\n冻结版本、只读验收] Q --> E1[(新证据 Eₜ)] E1 -->|未通过或发现新缺口| P E1 -->|满足完成条件| R[发布或收束]

二、三种分离构成 HoH 的机制核心

1. 制品与证据分离

“代码已经写完”不等于“能力已经成立”。制品说明系统现在是什么，证据说明哪些主张已被外部检查支持。两者分开后，下一轮规划不必相信上一轮的自然语言总结，而可以直接消费可执行制品和机器可读证据。

2. 生产者与验证者分离

Developer 是制品的单一写入者；QA 面对冻结候选版本，以只读方式检查。这样既减少并发写入冲突，也降低同一个 Agent 同时“写答案、解释答案、给自己打分”产生的确认偏差。独立验收的价值不在角色名称，而在权限边界和输入快照。

3. 长期目标与当轮增量分离

Planner 不把整个规格再次交给 Developer，而是选择一个局部完备、可独立验证的增量。每轮必须留下稳定检查点，使失败成本被限制在一轮内。长任务因此不再依赖一条脆弱的超长轨迹，而是由一串可审计的小事务构成。

stateDiagram-v2 [*] --> Planned Planned --> Developing: 锁定有界增量 Developing --> Candidate: 提交唯一写入 Candidate --> Verifying: 冻结候选版本 Verifying --> Accepted: 验收证据充分 Verifying --> Rework: 失败证据/风险缺口 Rework --> Planned: 证据进入下一轮规划 Accepted --> Planned: 仍有规格未满足 Accepted --> Completed: 规格与退出条件满足

三、实验真正支持了什么

论文在 GameCraft-Bench、FrontierSWE 与 ProgramBench 上组合三组 Harness 与模型。摘要报告三轮迭代平均相对提升 52.25%，最高 82.86%；另展示了一个持续 70 多轮、跨多日开发的 FPS 项目。

GameCraft 配置	得分	Token	可读出的结论
Vanilla 1	49.58	2.59M	单轮基线
Vanilla continuation 3	58.24	6.33M	延长执行有效，但提升有限
HoH 1	59.71	2.88M	一轮结构化控制已超过三轮普通续跑
HoH 2	64.84	5.67M	Token 少于 Vanilla 3，得分更高
HoH 3	71.52	8.41M	迭代继续积累可测收益

消融实验更能定位因果来源：删除计划更新后得分降至 63.39，删除证据反馈后降至 65.23，取消 warm start 后降至 63.67 且 Token 增至 11.12M。也就是说，收益不是简单来自“多调用几次模型”，而来自进展状态、反馈闭环与恢复机制的组合。

证据边界同样重要：基准中的循环条件受控；70 多轮案例只是一个开放式项目，并额外使用工具、Skill 和版本管理。论文证明了这种控制结构具有潜力，但没有证明它已经普遍解决真实组织中的自主软件交付、需求变更或生产事故责任。

四、落到 Agent Runtime，应建设哪些一等对象

HoH 不应被实现成三个角色名称和一段轮询提示词。可迁移的设计是把版本、证据和退出条件放进 Runtime：

type RunId = string;
        type ArtifactVersion = string;
        
        interface Evidence {
          artifactVersion: ArtifactVersion;
          checkId: string;
          verdict: "pass" | "fail" | "inconclusive";
          producedAt: string;
          reportUri: string;
        }
        
        interface IterationState {
          runId: RunId;
          specificationHash: string;
          artifactVersion: ArtifactVersion;
          acceptedEvidence: Evidence[];
          openRisks: string[];
          nextIncrement?: {
            objective: string;
            acceptanceChecks: string[];
            writeScope: string[];
          };
        }
        
        async function advance(state: IterationState): Promise<IterationState> {
          const plan = await planner.plan(state);
          const candidate = await developer.apply(plan, {
            baseVersion: state.artifactVersion,
            exclusiveWriteScope: plan.writeScope,
          });
          const evidence = await qa.verifyReadOnly(candidate.version, plan.acceptanceChecks);
          return checkpoint(reconcile(state, candidate, evidence));
        }

这段参考实现刻意表达五个约束：规格以哈希固定；写入范围显式化；QA 绑定确定的制品版本；失败也写入证据；每轮结束生成可恢复检查点。角色可以替换，约束不能被提示词默契代替。

五、工程与用户体验上的直接启发

进度应该由证据定义。面向用户显示“3/5 个验收条件已通过”，比“Agent 已思考 47 分钟”更可信。
允许从稳定版本继续。恢复点必须同时指向制品和证据，避免恢复后重新证明已经完成的工作。
把不确定性保留下来。inconclusive 不是失败的别名，它提醒下一轮补充观测，而不是编造确定性。
退出条件属于产品。预算耗尽、风险上升、验收完成与需要人工决策都应成为可配置终止语义。

从经验主义角度看，HoH 的价值是把 Agent 的“理解”降格为假设，把可复现证据提升为状态。系统不因模型宣称完成而前进，只因新版本经受了明确检查而前进。长周期智能由此不再表现为持续意识，而表现为能够保留、质疑并累积外部化成果。

结语

Harness-of-Harness 最值得吸收的不是 Planner、Developer、QA 三个标签，而是一个长任务不变量：每轮必须把制品推进到新版本，并把与该版本绑定的证据写入可恢复状态。Agent Runtime 的前沿因此不是无限延长 Session，而是建设能够保存净进展的控制面。