裸 Codex
使用 codex app-server，不启用 Goal 或 LoopX，按单次执行方式工作。
DeepSWE · GPT-5.6 Sol · v1 研究解读
从继续执行，
走到有效交付。
113 个软件工程任务，把长程 Agent 的三个问题放到一起：工作怎样继续，补丁是否交付，结果是否正确。
研究归档贡献 @gwh6669999 ↗
2026 年 9 月 16 日合入 · 实验修订 2cef51d
113 TASKS / HISTORICAL BEST-VALID
三种配置，三组完成结果
01 / RESULTS
先把数字放回它的统计口径。
Heartbeat 相比原生 Goal 多完成 10 个任务，完成比例相差约 8.8 个百分点。这是值得继续研究的观察；汇总表本身还不能说明，差异来自额外计算量、恢复策略，还是交付修复。
| 配置 | 完成任务 | 完成比例 | Partial | F2P | P2P |
|---|---|---|---|---|---|
裸 Codex plain | 54 / 113 | 47.8% | 0.9206 | 0.745 | 0.997 |
原生 Goal goal | 60 / 113 | 53.1% | 0.9620 | 0.868 | 0.997 |
LoopX + Heartbeat heartbeat | 70 / 113 | 61.9% | 0.9739 | 0.886 | 0.993 |
Partial、F2P 与 P2P 沿用原表字段；F2P 关注失败测试转为通过，P2P 关注原有通过测试是否保持通过。公开归档未提供逐题归约数据与完整计分脚本，本页不重新定义权重，也不将这些比例当作独立任务数。
已能看到什么
原生 Goal 相比单次执行已经出现差异；Heartbeat 的历史完成数进一步上升。三组 P2P 均接近 1，但 Heartbeat 略低，不能只用完成数概括全部质量变化。
还不能推导什么
没有逐任务的成败配对，无法知道哪些任务转正或转负；没有完整尝试次数和成本，无法估计成功率稳定性、单位成本收益或单项机制的因果效应。
02 / EXECUTION CONFIGURATIONS
比较的核心：谁负责让工作继续？
这五种配置同时改变了运行接口、状态组织和继续方式。它们提供不同的实验切口，不能看成只开关一个功能的消融实验。
Codex 原生 Goal
仍使用 app-server；原生 Goal 保持活跃时，由 app-server 继续推进。
LoopX + 外部监督
首次调用 codex exec，取得会话标识后使用 resume；外部 supervisor 读取 LoopX 状态，分段推进并检查交付。
LoopX 控制面驱动 CLI
由外部调用 loopx turn run-once --host codex-cli，组织多段执行。
LoopX + 原生 Goal
使用 app-server，在同一会话与 Goal 中处理 blocked 状态并重新启动 turn。
配置描述来自归档 README 与运行器源码，只说明历史实验怎样组织执行；不证明当前 LoopX 全部能力已经得到验证。
03 / CONTINUATION
Heartbeat 每轮都要重新检查交付。
归档里的 supervisor 并非只重复一句“继续”。它取回任务提示，恢复已有会话，检查代码交付和工作项状态，再决定结束或进入下一轮。
- 01
取回工作
heartbeat-prompt --thin
取出当前任务，附加补丁交付要求。 - 02
执行或恢复
exec → exec resume
从事件中保留会话标识，限制单段运行。 - 03
核对结果
normalize_delivery
整理补丁，再读取 P0 工作项状态。 - 04
收口或续跑
交付与状态同时满足才收口；缺失交付时补修复工作项。
有效补丁 + 收口条件满足
supervisor 返回执行完成；功能正确性仍交给独立验证器。
状态已收口，但补丁无效
新增交付修复 Todo，在剩余预算内继续。
预算或唤醒次数耗尽
返回失败，不把已运行很久当作完成依据。
源码细节：这里的“收口条件”具体检查什么？
历史函数 _goal_terminal 实际检查 Todo 列表：至少存在一个 P0 项，且所有 P0 项处于 done 或 deferred。它没有直接证明整个业务目标完成，也不验证补丁功能。
默认最多唤醒 8 次，轮间间隔 5 秒，单段超时 7,200 秒、总窗口 14,400 秒；命令行可覆盖这些值。单段子进程超时后 supervisor 仍可继续判断。这些是源码中的默认配置，不是历史每个任务的实际唤醒数或耗时。
继续执行需要判断依据，停止执行也需要。
04 / DELIVERY & VERIFICATION
代码写好了，验证器却可能拿到空补丁。
归档记录了一个具体的交付边界：Agent 可以在关联 worktree 中开发，但 DeepSWE 从主工作目录收集 git diff <base> HEAD。代码存在、提交存在，仍可能没有进入最终收集的产物。
工作发生处Agent worktree
修改与提交
交付整理唯一补丁与哈希核对
可应用 · 非空 · 内容一致
验收入口主目录的已提交补丁
交给独立验证器
workspace_delivery.py；不代表每次历史运行都发生了 worktree 恢复。交付整理器检查什么
枚举工作树，收集相对任务基线的补丁，并按补丁哈希去重。没有改动时返回 empty；存在多个不同补丁时返回 ambiguous。只有唯一补丁才继续检查可应用性、恢复到主目录，并核对恢复前后的哈希。
独立验证器检查什么
交付整理器确认“补丁被交到了正确位置”。研究口径还要求无运行异常、任务校验和匹配、独立验证结果存在且一致。功能是否正确由验证器判断，不能用流程终态或非空补丁代替。
为什么这属于 Harness，而不能都算成模型能力？
历史整理器会提交未提交的改动，并在隔离实验工作区恢复补丁。这是运行器介入交付的行为。成功提交不一定完全由 Agent 自主完成；缺失交付也不一定意味着模型不会解题。比较时应把生成代码、运行器恢复和最终验证分开记录。
这份实现会对实验主目录执行重置与补丁恢复，依赖专用、隔离的任务环境。本文解释它的交付机制，不把原脚本当作日常仓库操作指南。
流程完成、产物交付、功能正确，是三个要分别验证的事实。
05 / SCOPE & NEXT EXPERIMENT
把观察变成结论，还缺哪些证据？
这份贡献提供了可读的运行器和历史汇总。要进一步判断哪种机制有效，需要把计算预算、重复尝试和交付处理重新放到可对照的实验里。
| 维度 | 已公开的依据 | 对结论的影响 |
|---|---|---|
| 模型与推理强度 | 两个启动脚本默认 openai/gpt-5.6-sol / xhigh。 | 逐次运行配置未公开，默认值不等于每次调用的证明。 |
| 时间与资源 | remaining59 脚本给 LoopX 的 Goal 超时为 14,400 秒，plain / goal 为 3,600 秒；LoopX 另设 3.0 的 agent timeout multiplier。 | 不是等预算对比；超时上限也不是实际耗时。不能推导成本效率。 |
| 聚合与尝试 | 113 任务，逐任务选最佳有效结果；没有完整逐题尝试清单。 | 不是 pass@1，无法重建成败配对、方差或置信区间。 |
| 版本与复现 | 实验基于 2cef51d。原始 14 个文件归档；依赖外部任务定义、支持模块与运行环境。 | 不是独立可运行的发布包。文件身份、语法与导入检查不等于实验复现。 |
| 已知执行缺陷 | 归档说明保留了 59 任务启动器与 54 任务准入不匹配、profile 初始化竞争、启动和重试处理等问题。 | 不能把准入回执视为每次运行均有效的保证；需要在修复后的独立实验中验证。 |
06 / SOURCES
从研究汇总读到执行代码。
本文只使用公开归档与源码，引用固定到读取修订。没有运行新实验，没有新增或恢复已撤回的成绩。