Harness-of-Harness（HoH）在 Codex、OpenCode、Pi 这类现成 coding harness 外再加一层长期开发协议。它让 Planner → Developer → QA Tester 反复处理同一个项目，并跨轮保留两份状态：可继续修改的软件 artifact，以及经过 QA 绑定到具体候选版本的 evidence。
Q1. 为什么现有 coding harness 很难连续开发几天？
当开发持续几天，项目状态、验证结论和下一步决策会逐渐脱节。 普通 coding harness 往往在一个 bounded episode 里完成 issue 或局部功能。多日 greenfield development 会同时积累代码、资源、设计选择、已知缺陷和曾经通过的行为；后续局部修复还可能破坏早期功能。
论文把风险归为三类。第一，早期 requirement 和设计决定会被遗忘。第二，高层 PRD 通常无法唯一确定“下一步最值得做什么”，Agent 容易在局部修补中循环。第三，完整软件的正确性分散在编译、交互、状态迁移、视觉、音频和运行稳定性里，单个通用 test 很难覆盖。
HoH 据此用“PRD + 当前 artifact + 已验证 evidence”共同决定下一步。每轮只选择一个 bounded but locally complete increment，也就是范围有限、但在用户可观察行为上自洽的增量。这样既避免一次改动扩散到整个项目，也避免只修一个文件却留下一条无法运行的半成品路径。
Q2. HoH 和多 Agent、长上下文、harness 自优化有什么区别？
HoH 优化正在开发的项目，模型和底层 harness 保持不变。 它和角色式多 Agent 的表面结构相似，差别落在权限、跨轮状态和验收证据上。
| 路线 | 变化对象 | 状态怎样跨轮 | 与 HoH 的区别 |
|---|---|---|---|
| 长 context / memory | 模型可见历史 | 对话、摘要或外部 memory | 能记住过去，不等于把每个事实绑定到一个已测试候选 |
| MetaGPT / ChatDev | 固定的角色和消息流程 | 角色间文档与对话 | HoH 额外固定读写权限、冻结候选和 evidence schema |
| AgileCoder / EvoDev / EvoMAC | sprint、feature dependency 或测试反馈 | 迭代计划和实现状态 | HoH 把 artifact 与 QA evidence 明确拆成两条持久通道 |
| AutoHarness / Meta-Harness / Self-Harness | prompt、tool、harness code 或 orchestration | 跨任务优化结果 | 它们改变 operational layer；HoH 固定 operational layer，持续改变项目 |
| LongHorizon-Harness | 单任务的 task state 与 bounded contract | Manager state + read-only audit | 更通用地包裹 GUI/CLI 任务；HoH 针对软件开发保留版本化 artifact 与角色化 QA |
| Harness-of-Harness | 当前软件 artifact 和 development evidence | (A_(t-1), E_(t-1)) → (A_t, E_t) | Planner、Developer、QA 每轮各调用一次同一 harness/model |
论文还引用 Proof-or-Stop、Self-Refine 和 Reflexion。它们都强调反馈或证据；HoH 进一步把“谁能写项目、谁能验收、证据属于哪个候选版本”落实成 Runtime contract。方法落在候选冻结、权限隔离和证据归属上。
Q3. 一轮 HoH 到底怎样运行？
3.1 三个角色看到什么、能改什么？
D_t。A_(t-1) warm-start，读取 PRD 和 D_t，是唯一允许写 artifact 的角色。它负责 baseline、修改和自测。A_t，不能修代码。它把 verified records 与 gap records 写入 E_t。论文的 Algorithm 1 可以压缩成六步：
- 1 · PLAN用 PRD 和旧 evidence 选择一个可验证增量。
- 2 · PRESERVE列出不能回归的已验证行为。
- 3 · DEVELOPDeveloper 在现有 artifact 上实现。
- 4 · SELF-TEST先建立 baseline，再对每次重要修改重测。
- 5 · FREEZE把候选复制到 QA 隔离区，绑定 candidate identity。
- 6 · ASSESSQA 用黑盒和白盒证据生成下一轮
E_t。
3.2 权限不只写在 prompt 里
公开的 hoh-lite（revision ae7cc6f，Python 3.12+，Apache-2.0）用枚举和不可变 RoleBinding 强制权限。下面是官方源码摘录；Planner 或 Tester 如果拿到读写 workspace，初始化就会报错。
class WorkspaceAccess(str, Enum):
READ_ONLY = "read-only"
READ_WRITE = "read-write"
@dataclass(frozen=True)
class RoleBinding:
role: RoleName
workspace_access: WorkspaceAccess
godot_mcp: GodotMCPAccess
def __post_init__(self) -> None:
if self.role is not RoleName.DEVELOPER:
if self.workspace_access is WorkspaceAccess.READ_WRITE:
raise ValueError(
f"{self.role.value} cannot receive a read-write candidate workspace"
)
if self.godot_mcp is GodotMCPAccess.READ_WRITE:
raise ValueError(
f"{self.role.value} cannot receive read-write Godot MCP"
)Runtime 还检查调用顺序。正常路径必须从 Planner 开始，Planner 后只能到 Developer；Developer 后才能到 Tester。每次调用的 role、状态、开始时间、耗时和摘要会写入 runtime_receipt.json。这让“Agent 说自己按顺序做了”变成 host 可以复核的事件记录。
3.3 Evidence 不是一句“测试通过”
论文把每个可检查 claim 写成三元组 (claim, execution records, status)。例如“左右键会移动角色”需要引用 replay 和 runtime trace；“完成目标后出现结果页”如果截图只显示任务结束却没有结果页，就进入 gap records。下一轮 Planner 会把前者写成 preservation constraint，把后者写成 update target 和 validation requirement。
{
"verified_records": [{
"claim_id": "player_control",
"execution_records": [
{"type": "replay", "observation": "Left and right inputs move the avatar."},
{"type": "runtime_trace", "observation": "Position changes after each input event."}
],
"status": "verified"
}],
"gap_records": [{
"claim_id": "result_state",
"execution_records": [
{"type": "screenshot", "observation": "The objective ends without a result screen."}
],
"status": "gap"
}]
}这段是论文 Listing 1 的缩减摘录。QA 可以引用截图、视频、replay、runtime state、日志和公开 test；source-code presence 本身不能证明行为已经发生。
Q4. 实验怎么评，结果和真实 case 说明什么？
4.1 内部 QA 和最终 benchmark judge 是两套系统
HoH 的 QA 只看公开任务、当前 artifact 和公开执行记录。 Benchmark 在完整 run 结束后才运行 hidden tests 或 private rubric；结果不会进入 Planner、Developer 或 QA。
B=0，Overall 直接为 0；可运行时按四个 rubric dimension 加权。frogsgame-rl（需要当时不可用的 Tinker API 登录）和 modular-stack-wan21（要求 NVIDIA driver ≥580，实验 H200 worker 为 570.133.20）。每题由官方 verifier 给 reward。其中 M/D/V/A 分别是 Core Mechanics、Content Depth、Functional Visuals、Art and Presentation 的 rubric-item 均值。FrontierSWE headline mean 是 15 个 task reward 的无权均值；Dominance 先在同一 task 上与其余 11 个配置逐一比较，胜/平/负记 1/0.5/0，再在 domain 内平均，最后对三个 domain 做 macro average。ProgramBench 的 Pass Rate† 不是 solved-task rate，而是 per-task hidden-test fraction 的平均。
运行次数：每个 task-condition 只有 1 次有效 run。Infrastructure 或 provider transport error 会被替换，不算额外 replicate。客户端没有共同的可复现生成 seed，论文也没有统一覆盖 temperature 或 top-p。
4.2 主结果：三种 harness 都有提升
| Harness + model | GameCraft Overall | FrontierSWE mean reward | ProgramBench Avg. Test Pass Rate |
|---|---|---|---|
| Codex + GPT-5.5 high | 49.58 → 71.52 | 0.31 → 0.54 | 60.41 → 66.50 |
| OpenCode + DeepSeek-V4-Pro | 26.90 → 48.98 | 0.23 → 0.31 | 45.27 → 57.56 |
| Pi + MiniMax-M3 | 42.16 → 58.78 | 0.26 → 0.55 | 35.83 → 52.68 |
4.3 不是“多跑几遍就会涨”
三次 Vanilla Continuation 会在同一 session 里收到固定提示 Continue developing and testing the current game.，但没有新的 development document，也没有独立 QA evidence。按相同 development pass 比较：
| 方法 | 1 pass | 2 passes | 3 passes | 三轮 token / task |
|---|---|---|---|---|
| Vanilla / Continuation | 49.58 | 54.99 | 58.24 | 6.33M |
| HoH | 59.71 | 64.84 | 71.52 | 8.41M |
HoH@2 用 5.67M tokens 得到 64.84，已经超过三轮 Vanilla Continuation 的 58.24 和 6.33M。按论文公式，相对 Vanilla 每增加 1M tokens，三轮 Continuation 增加 2.32 分，HoH 增加 3.77 分。
消融的 Full HoH@3 是 71.52。去掉 Plan Update 后是 63.39，去掉 Evidence Feedback 后是 65.23，去掉 Warm-Start 后是 63.67。后者还把 token 从 8.41M 推到 11.12M，因为每轮都从空 workspace 重建。
4.4 FrontierSWE 能继续迭代，但仍有长期零分任务
聚合分数会遮住停滞项。Codex 在 Cranelift、Dependent Type Checker、FFmpeg 和 Inference System 四个 Performance task 上从 Vanilla 到 HoH@3 都是 0。Pi 的 Revideo 也一直是 0。持续迭代能提高部分任务，不保证跨过每个 verifier 的硬门槛。
4.5 真实 Loop 70：Developer PASS，为什么 QA 仍判 FAIL？
Fusepoint · combat_readability · candidate loop-70-c3d32741612b
- 来源与状态：这是作者公开 Fusepoint 仓库 revision
55b442fc的真实 Planner/Developer/Tester receipt。Planner 从已有 issue ledger 选择四个 active issue，要求同时保留 clean boot、A/B/C 敌人数量、mouse-look、武器组件和终局逻辑。 - 本轮实现目标：修复 rifle enemy 把 pistol animation 绑定到活体敌人的问题；让 Alpha/Bravo/Charlie 的 3/5/10 敌人能分离 prepare 与 advance；把小号、定时消失的 story cue 改成玩家确认后才推进，并补齐 combat feedback cleanup。
- Developer 输出：公开 README 记录 Developer Status = PASS、Completed tasks = 3、Changed paths = 6。这个 PASS 只表示开发阶段结束，不能关闭 QA criterion。
- QA setup 与 action：Tester 先验证 clean boot，再用普通路线进入 gameplay；随后调用各 encounter 的 prepare/advance 路径，采集 runtime actor state、截图、日志和 frame。候选在测试期间冻结，QA 不能改代码。
- 观察：3/5/10 个 rifle actor 能准备出来，source 也不再把 rifle state 映射到
Pistol_*。但 advance 只产生 idle/walk sample，没有 target visibility、fire authorization、shot、reload、hit reaction 或 death；Replay 返回 predeployment 后，DeployButton 也无法用已测输入重新开局。 - 判定：
clean_boot = PASS，rifle-pistol binding issue 被 verified；enemy combat AI、animation motion quality、combat feedback、audio/VFX、performance stability 均 FAIL。最终phase_status = blocked、Tester review = FAIL。
这个 case 展示了 HoH 最重要的语义：“实现了修复”与“在冻结候选上观察到验收行为”是两个状态。 QA 还区分代码修复、运行路径可达、证据完整和产品完成度，避免一个局部 source assertion 把整条交互链直接判成通过。
4.6 全部原论文结果图放在一起看
Q5. 对 Claude Code、Codex harness 研究有什么启发？
对后续研究更有用的是四条可测试的系统约束。
第一，单写者边界。Planner 可以读结构，QA 可以运行候选，只有 Developer 能改 artifact。这样一次状态变化有明确责任人，QA 证据也不会混入边测边修的中间版本。
第二，evidence 必须绑定 candidate identity。截图、日志和 replay 需要指向同一个 frozen artifact。否则一份报告可能把旧截图、新代码和测试中临时修过的状态拼在一起。
第三，内部 feedback 与隐藏 benchmark 隔离。Harness 可以利用公开运行证据修项目，但不能看最终 judge 的 hidden tests、分数或 rationale。这条边界决定实验是在改进开发协议，还是在对 evaluator 过拟合。
第四，把 preservation constraint 当成一等输入。下一轮除了“要修什么”，还需要“哪些已验证行为不能退步”。Fusepoint 的 17 次 reopen 说明，长任务的主要风险会从缺功能逐渐转向 regression management。
如果要在这个方向继续发论文，我会优先做以下实验：
- 在固定 token、wall time 和 harness invocation 数下比较普通 continuation、HoH 和 LongHorizon-Harness，避免“更多调用”解释全部增益。
- 对 evidence 做校准：测 QA 的 false positive、false negative、跨模型一致性，以及黑盒和白盒证据分别贡献多少。
- 把 candidate-bound receipt 做成 harness-neutral protocol，让 Claude Code、Codex、OpenCode 能复用同一种 evidence object，而不是每个 benchmark 写一套胶水。
- 加入 rollback 或 branch selection。当前 HoH 总是沿最新 artifact 继续；遇到严重回归时，系统虽保留 version history，却没有在主实验中系统比较回滚策略。
- 对 task-level regression 建模。聚合均值提高时，仍需要检测 Spire Descent、Pipe Crisis 一类持续退步的 task，并决定何时停止继续迭代。
Q6. 这篇论文目前能证明什么，不能证明什么？
论文有一套完整、可执行、公开到角色权限和真实 receipt 的 harness 设计；实验支持整套 HoH 有效，但还不足以精确分解收益或证明多日项目已经达到独立产品验收标准。
hoh-lite 足以检查 orchestration contract，不足以复算全部表格。我的结论是：HoH 把“继续让 Agent 写”改造成“每轮产生一个版本化候选，再用独立证据决定下一步”。 对 Claude Code、Codex 这类完整 harness，这比再加一段更长 prompt 更接近真实的软件工程控制面。它还留下三个明确研究口：如何校准 QA、如何在固定预算下分配 Planner/Developer/Tester，以及如何让长期迭代在单题上也具备可检测的停止与回滚条件。
留言