怎样让 Codex 连续开发几天？

代码会留下，关于代码的可靠认识却会不断过期

几小时后，Agent 会同时面对持续增长的历史，以及互相脱节的 artifact、需求、回归风险和测试结论。

论文 Figure 2：右侧要求系统自己完成 observe → plan → develop → test 的闭环。

01

决定被遗忘早期 requirement、设计取舍和已知限制埋进长轨迹，后续修改不再知道什么不能破坏。

02

下一步没有唯一答案同一 PRD 可以对应多条开发路线；Agent 容易停在局部修补或重复尝试。

03

“能运行”不等于“做完”完整软件的正确性分散在编译、交互、状态迁移、视觉、音频与稳定性里。

HoH 不改 Codex，也不训练模型；它改的是外层开发协议

HoH 把验证证据绑定到候选版本，跨轮状态不再只是对话摘要

一轮包含一次受控的状态提交

代码和证据必须分开保存，又必须绑定到同一个候选

三个角色的分工由权限边界保证

Planner 选边界，Developer 写候选，QA 只对冻结版本出证据

Planner 和 Tester 的只读边界会在初始化时被验证

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):
        if self.role is not RoleName.DEVELOPER:
            if self.workspace_access is not READ_ONLY:
                raise ValueError(...)

每条 claim 都带 candidate、scope、observation 和 limitation

{
  "candidate_id": "loop-70-...",
  "final_status": "FAIL",
  "verified_records": [
    {
      "claim": "clean boot works",
      "method": "runtime replay",
      "evidence": ["log", "screenshot"]
    }
  ],
  "gap_records": [
    {
      "claim": "encounter reaches combat",
      "observed": "idle / walk only",
      "impact": "golden path blocked"
    }
  ]
}

内部 QA 能帮助下一轮；外部 hidden verifier 只能在结束后结算

先看提交经过什么 judge，再看表格里的数字

三种 harness/model 的总体指标都提高，但不能当成生成方差估计

提升不只来自“项目终于能启动”，内容深度和呈现也一起变化

论文 Figure 4：error bars 为跨 45 个 task 的 20,000 次 bootstrap percentile interval。

Core Mechanics基础玩法与核心循环。三种 harness/model 都提高。

Content Depth更完整的状态、反馈与 progression；权重与 Art and Presentation 同为 0.35。

Binary gate 仍先执行如果项目无法编译或运行，四个维度不会把 Overall 从 0 救回来。

三轮 HoH 更常把核心交互、UI 和场景细节同时补齐

论文 Figure 6：Momentum Lab、Kitchen Rush、Ant Empire。

Momentum LabOverall 34.05 → 70.61；从基础平台场景走向更完整的动量玩法。

Kitchen RushOverall 42.62 → 73.38；订单、厨房状态与管理反馈更完整。

Ant EmpireOverall 65.52 → 87.88；殖民地状态、资源与进展展示更成熟。

证据边界这些是按结果展示的作者选择案例，不能替代逐题生成方差或随机 case study。

Repeated Vanilla 也会进步，但 HoH 每轮更有效地使用新增 token

论文 Figure 9：累计 score 与 token trajectory。

Protocol	Pass 1	Pass 2	Pass 3	Tokens@3
Vanilla / Continue	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 的 58.24 / 6.33M。

仍不是严格等 computeMatched pass 不等于 matched wall-clock、invocation 数或 token；论文另用 budget efficiency 辅助解释。

三条跨轮通道都重要；丢掉 artifact 最贵

论文 Figure 10：最终 GameCraft score 与累计 token。

Full HoH@3 · 71.52 / 8.41M规划、QA evidence 与 artifact warm-start 全部保留。

No Plan Update · 63.39Planner 不再根据上轮 evidence 重新选择本轮增量。

No Evidence Feedback · 65.23下一轮拿不到独立 QA 的 verified/gap records。

No Warm-Start · 63.67 / 11.12M每轮从空 workspace 重建；分数下降，同时 token 反而最多。

Dominance 上升与长期零分可以同时存在

Figure 5：Codex 从 Vanilla 27.33% 到 HoH@10 72.67%，HoH@9 为 76.00%。

Figure 8：4 Implementation、9 Performance、2 Research tasks。

总体平均上涨，不代表每个任务、每个阶段都变好

论文 Figure 11：每次 coding-harness invocation 的 token 分布。

单题回退Pi 的 Spire Descent 26.61 → 10.96，Pipe Crisis 53.26 → 37.65；整体单调不等于 task-level 单调。

生成方差未知每个 task-condition 一次有效 run，没有共同生成 seed，也没有同题重复采样。

不同 provider 不同记账cache 与 input/output token 的统计口径不同，Figure 11 适合看同一 harness/model 内部，不适合横向算单价。

Developer 完成了代码任务，不代表用户路径已经被验证

QA 运行的是完整路径：局部修复通过，golden path 仍被阻断

Figure 1：论文截点为 Loop 70；81 issues 中关闭 65、未解决 16，17 个曾关闭 issue 因回归重开。

Setup / actionQA 在冻结候选上 clean boot，进入 encounter，并 replay 返回主菜单再尝试重新开局。

Observation 1敌人只出现 idle / walk；没有 aim、fire、reload、hit、death，combat golden path 未成立。

Observation 2Replay 后 DeployButton 无法再次启动流程；llvmpipe sample 只有 8 FPS。

Verdict · FAIL / BLOCKEDDeveloper receipt 的 PASS 只说明实现任务结束；独立 QA 的失败证据才决定下一轮状态。

最值得复用的是 candidate-bound evidence；最需要补的是重复实验与 QA 校准

PROVEN完整 HoH 协议有效三种 harness/model、三套 benchmark 的总体指标均高于 Vanilla；matched passes 与三项消融支持跨轮状态有用。

NOT PROVEN没有同题生成方差一次有效 run 无法回答稳定性；bootstrap 只重采任务。

OPEN PROBLEMQA 还未校准需要测 false positive / negative、停止条件、rollback 和 fixed-budget 分配。

AUTHOR INTEREST9.5 / 10对 Claude Code、Codex 式完整 harness 的多日自治开发非常直接。