昨天我痛痛快快地用 astra 指挥 loopx 跑 EdgeBench，astra 做 supervisor，6.1-sol 做 executor。有一些心得：

1. 关于 benchmark 的研究方法：

1. 有一类 benchmark（比如 EdgeBench）和 LHTB 等不同，它们有明确的“进程内反馈信号“——agent 可以提交版本以获取分数和信息性反馈。这类 bench 容易让 agent 对评测器过拟合，所以我加了一组 blind run 消融，去掉“进程内反馈信号“来做测试。
2. benchmark 本身的质量需要审视。切换到 blind run 方式后，有些题直接得 0 分。分析后发现评测器与题目本身存在不匹配，说明 benchmark 本身就有固有问题。例如 portfolio 这道题在 blind run 下始终得 0 分，意味着得分高度依赖执行者的能力以及“过拟合评测器“的效率。

2. loopx 技术路线的长程能力与效率

确实存在技术挑战；关于效果、效率、正确性的细节需要逐个落实。根本原因在于模型还没学会如何使用 loopx，更多依赖原子工具自身的闭环反馈与引导能力。 astra 出来之后，这是我第一次自己系统地跑 bench。光是昨天晚上我就修了 20 个小问题……我还把 explore harness 中闭环支撑的启用进一步固化了下来。博客里详细记录了过程中修复的问题，包括：session 连续性、任务状态连续性、重规划的证据、claim 与 worktree 协议的可用性与可恢复性、checkpoint/vision 状态结算路径、explore 能力的 hook 闭环、状态上下文传递的 packet 优化、benchmark 断点续跑方式。

我也推荐大家用这种方式做长程研究：先做 blind 与强反馈的消融对比；然后以 blind 模式为基础，分析评测本身的正确性；再基于 loopx 的轨迹分析驱动优化。

https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/…

总结来说，现在对 LoopX 的要求更具体了：Goal 必须保留真实任务的意义；Todo 必须对应可验证的工作；负证据必须能够排除下一个无效路径；resume 必须与 session 和控制状态无缝衔接；反馈必须有可信的契约；管理这些结构的成本必须被计量。只有当这些真实问题被解决、更难的目标被达成时，这套结构的价值才真正成立。

长程 Agent 的反馈与记忆：从 EdgeBench 的 blind 零分查起

Source: https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/ ← LoopX 博客 (https://loopx-project.github.io/loopx/blog/zh/)·English (https://loopx-project.github.io/loopx/blog/edgebench-feedback-and-memory/)Ruiteng Huang · 研究札记 · 2026-10-05 · 基于真实轨迹、终末重放与合成反例

我希望 LoopX 能让 Agent 完成更难的目标。但这轮实验首先教会我们的，是怎样识别“运行了很久，却没有形成有效研究“，以及怎样判断一个反馈信号是否值得相信。

我们给同一个模型配了不同的持续执行机制：官方 stop hook、单次 Codex、原生/goal、LoopX heartbeat + resume，以及带 Explore Harness 的 LoopX。每种机制再拆成可获得评测反馈与无法获得评测反馈两组。在 Portfolio 题上，无反馈组一度长时间停在零分；LoopX 也没有显出预期的效率优势。

如果只看曲线，很容易得出两个判断：没有反馈，模型就不会做；增加管理结构，只会拖慢模型。但沿着轨迹、任务说明和评测器逐层检查，原因比这复杂得多。我们发现过自己的消融实现不干净，发现过题目与评分契约矛盾，也发现过 LoopX 让模型花时间完成并不必要的协议往返。与此同时，确实有策略在修正错误扣分之后仍然得零分。

观点与问题 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#thesis)实验设计 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#matrix)从零分开始 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#zero)账本反例 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#ledger)策略与扣分 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#strategy)问题分布表 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#distribution)LoopX 真实问题 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#real)负证据与目标 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#memory)怎样衡量 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#measure)PR 与版本 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#patches)重跑计划 (https://loopx-project.github.io/loopx/blog/zh/edgebench-feedback-and-memory/#rerun)## 1. 能力上限在前，效率在后，但两者需要同一套证据

我最近在 X 上写过 (https://x.com/huangruiteng/status/2106727554254311600)，LoopX 尝试给长程 Agent 提供可以跨会话保留的结构化状态：目标、递归拆解的工作、决策和证据。首要目标是通过更慢、更充分的计划、实验、取证和修订，提高整个系统能完成的任务上限；之后再研究相同可验证结果下的计算、延迟和人类注意力成本。

更长的运行时间，需要能改变下一步行动的反馈。

这句话包含两个需要分开验证的条件。首先，反馈要准确描述发生了什么；其次，系统要实际利用反馈改变决策。评分器把真实成交误判为造假，会破坏第一个条件。框架把错误恢复文案写得含混，让模型下一轮继续试同一组无效参数，会破坏第二个条件。两者都会表现成“Agent 跑了很久，结果没有改善“。

原帖引用了 Thore Graepel 关于 AlphaGo 的讨论：搜索、检验直觉与推演未来是重要组成部分。我并不据此把 LoopX 等同于棋类搜索，也不认为持久运行本身回答了 LLM 是否具备推理能力的问题。这里采取更可检验的工程目标：系统是否能完成更难的任务？结构和反馈分别贡献了什么？在可比预算下，这些贡献是否能够被观察和复现？

这次 EdgeBench 试跑提供了很直接的检验材料。一个长程框架可以拥有完整的 Todo、checkpoint、lease 和 evidence 字段，却仍在错误的目标代理、错误的评测信号或自己的控制协议上浪费时间。我们需要检查这些结构在决策链中的作用，而不能把它们的存在当作效果。

2. 用五种 worker 和两种反馈条件拆解问题

本轮主要研究 Portfolio Risk Calibration，同时用 BipedalWalker Locomotion RL 观察另一类训练任务。五种 worker 不是五个模型：基础模型统一为gpt\-6\.1\-sol / xhigh，主要变化是执行如何继续、状态如何保留，以及是否使用 LoopX 的探索能力。

图 1|设计矩阵，不是结果矩阵。当前诊断以 Portfolio 为主，BipedalWalker 尚未完成同等覆盖。 (https://loopx-project.github.io/loopx/blog/images/edgebench-feedback-and-memory/matrix.svg)图 1|设计矩阵，不是结果矩阵。当前诊断以 Portfolio 为主，BipedalWalker 尚未完成同等覆盖。Worker保留的机制需要验证的机制事实官方 baseline沿 SForge 官方 stop hook 与继续路径停止被如何处理、什么时候提交、是否真实继续工作单次 Codex一次调用，无 stop hook 和外部续跑模型何时自然结束；不能人为补一个循环再称单次原生 /goalCodex 自身的目标执行原生目标如何结束/继续，不归因于 LoopXheartbeat + resumeLoopX 准入、Todo、重规划、结算和同会话恢复恢复的是同一 session；下一轮选择和结算确实生效+ Explore Harness上述机制加证据记录与探索规划证据被读取、解释、采用；不以配置开启代替使用证明两种反馈条件共用任务、公开数据与基本迭代策略。native 组可以提交并阅读官方分数/诊断；blind 组不能主动提交或收到 judge 反馈，但仍可以使用公开训练数据、自建回测、本地测试和公开契约校验器。因此，更准确的名称是“无 judge 反馈“，而不是“完全没有反馈“。

后台对两组都每 5 分钟自动采样评测，研究者可以看过程曲线，blind solver 不知道这些结果。默认整场预算为 18 小时，不再设置独立的单轮时限。对于外部 worker，有可运行的后继工作时也不再人为插入轮间等待。预算是上限而不是保证消耗：单次调用提前结束，本身就是该配置的行为。

stop hook 是停止边界上的继续机制，不应未经核对就等同于“每轮必提交一次“。后台评测、主动提交、模型一次响应、LoopX 一个 Turn 是不同单位。页面上的采样记录数不能用来代替模型轮数或有效实验数。接入、worker 语义和终态展示分别见#5591 (https://github.com/loopx-project/loopx/pull/5591)、#5600 (https://github.com/loopx-project/loopx/pull/5600)、#5618 (https://github.com/loopx-project/loopx/pull/5618)。

3. blind 零分首先迫使我们检查自己的实验

最初多个 blind 组长期为零。一个直觉解释是：模型没有获得外部奖励，因此缺乏优化方向。但在解释模型之前，我们先检查了包装提示。

结果发现，初版 blind prompt 除了删除提交入口，也删掉了“持续迭代““保留当前最好版本”“失败尝试不扣分“等引导。这已经不是纯粹的反馈可用性消融。模型是否愿意持续尝试、何时写入可运行产物，也被一起改变了。修复时恢复了共同的优化提示，只替换不可用的 judge 提交/反馈部分，并开启新的 attempt；旧曲线保留为诊断材料。

这一步很容易被忽略。一次实验可以有相同的模型、相同的时间和相同的题目名称，却因一段外层包装而回答了不同的问题。网络隔离也不能仅靠提示“不要看分数“：blind 的提交入口被移除，worker 不获得 judge token/URL，网络只允许必要的模型 API；服务端还要拒绝主动提交和未授权的 auto-eval。公开文档区分了反馈政策与 evaluator 隔离(#5635) (https://github.com/loopx-project/loopx/pull/5635)，不能把二者混为一个开关。

包装修复之后，零分问题仍值得追查。我们在多个 solver 的输出中看到open\_date == close\_date。它们显然在按当日成交记账：买入、卖出、卖空、回补，各对应一次执行。但旧输出说明又用这些字段描述持有区间；评测把同日开平、零 return 的高比例视作异常，甚至清零核心得分。

同一天记录成交，并不意味着同一天买入又卖出。这个区别需要题目给出明确契约。把所有 solver 都要求“猜对评测器期望的解释“，在 native 模式可能会被反复试分掩盖，在 blind 模式则会集中暴露。

图 2|调查没有停在某个方便的解释上。提示混杂、任务语义、会计审计和策略表现分别接受检验。 (https://loopx-project.github.io/loopx/blog/images/edgebench-feedback-and-memory/investigation.svg)图 2|调查没有停在某个方便的解释上。提示混杂、任务语义、会计审计和策略表现分别接受检验。沿着这个线索，我们继续发现：评分奖励的高 Sharpe、低回撤与部分反欺诈阈值冲突；完整权重记录被一个未公开的最低投资比例判为不完整；scheduled 模型更新与额外风险再平衡共用一个间隔检查；仓位约束是否检查，竟然会受模型填写的事件标签影响。

这些问题被整理到 EdgeBench #14 (https://github.com/ByteDance-Seed/EdgeBench/pull/14)。最初的 diagnostic repair 保持其他评分边界，把缺乏直接会计证据的部分清零条件改成诊断；event-v1 则明确成为新任务变体，分开两个事件时钟，并对每个交易日检查仓位约束。它们都不是把已有低分重新解释成高分。

4. 比同日成交更深一层的问题：评分器是否在验证同一本账

第一轮修复后，我们继续分析已结束样本。我们没有让正在运行的 solver 看隐藏评测细节，而是冻结终末源码与提交摘要，在隔离环境重放评分。两个 blind 样本分别复现出 0 和 8.05 分。随后另写独立对账逻辑，不导入 solver 的计算函数，从真实成交、现金、持仓与成本逐日核对。

结果是：两个样本各 243 个交易日都可以对平。权益残差小于 4×10−9，NAV 残差小于 5×10−16，股数没有差异。这并不证明它们是好策略，但说明至少不能用不匹配的近似账本直接判定它们的真实账本错误。

4.1 收盘后权重不能拿来赚收盘前的收益

考虑一个不依赖策略的合成例子：初始有 100,000 现金。第一天资产价格为 100，第二天涨到 200。我们到第二天收盘时才买 100 单位，付出 20,000 本金和 10 佣金。买入之后立即按同一个收盘价估值，权益应为 99,990，NAV 为 0.9999。资产当天翻倍发生在买入之前，账户没有赚到这段收益。

旧重建函数用当日收盘后权重与当日收益相乘，得到约 1.199919992，并因此拒绝正确的 0.9999。真实样本中，同类问题把 1.06610051 重建为约 1.1331，形成 10 分扣罚。此外，基于权重变化估算佣金，会把价格漂移与真实换仓混在一起；实际滑点和跨周末借券费用也不能由这条近似式精确还原。

图 3|独立合成反例。左图证明旧重建会误拒正确账本；右图证明仅校验期末会遗漏中间错误。右图不是“整个 judge 接受造假“的结论。 (https://loopx-project.github.io/loopx/blog/images/edgebench-feedback-and-memory/nav-counterexamples.svg)图 3|独立合成反例。左图证明旧重建会误拒正确账本；右图证明仅校验期末会遗漏中间错误。右图不是“整个 judge 接受造假“的结论。### 4.2 只校验最后一个 NAV，会遗漏中间路径

反方向也有问题。一个全现金账户，真实 NAV 应该始终为 1。如果报成 [1, 1.01, 1]，旧期末重建函数仍然通过，因为最后又回到了 1。中间凭空出现的收益却足以影响波动率、回撤、Sharpe 和风险校准。因此，“期末总钱数相等“远远不够；所有依赖路径的指标，都要求整条路径先有可信的经济来源。

4.3 相同成交签名不等于重复记账

另一个终末样本有 7 组相同签名。把日期、股票、方向、价格和数量拼起来，它们确实相同。但轨迹和账本显示，这是同日不同决策带来的独立成交：一次常规/风险更新之后，又有一次对冲调整。额外股数改变了持仓，现金发生了对应变化，费用也支付了。大部分额外成交为 1 股，一次为 4 股。

在这类场景中，签名相同可以触发调查，不能单独证明重复记账。反过来，允许模型填一个不同的 reason 或 ID 就绕过审计，同样不成立。需要同时检查唯一执行身份和经济效果：同一 ID 重复报送非法；新增一笔没有对应现金、仓位、费用变化的成交也非法；两笔确实独立且完整入账的同量成交应当通过。

4.4 版本化修复必须先明确会计约定

不能把针对两个既有 solver 的诊断适配器直接升级为通用评分器。它们采用的滑点和借券支付策略不同。新的公共契约必须先消除自由解释空间，再让 work image 与 judge 使用同一规则。

本轮 ledger-v2 明确：初始 1,000 万现金、零持仓；在每个交易日收盘执行；每笔按成交额收 5 bps 佣金和 1 bp 现金滑点；借券成本按前一收盘空头市值、4% 年率与 ACT/365 自然日计提，在下一交易日从现金扣除。跨零仓位拆成两条有序执行腿。每天都报告完整现金、整数股数、费用、权益、NAV 和权重。初始本金与费率是新实验约定，不追溯强加给旧结果。

权益t = 现金t + Σ 股数t,i × 收盘价t,i NAVt = 权益t / 初始资本 权益t − 权益t−1 = Σ 股数t−1,i × 价格变化t,i − 佣金t − 滑点t − 借券成本t

校验从价格和执行重建账本，不能用报告里的 cash 或 NAV 反过来驱动计算。漏报/少报/重复费用、重复执行 ID、多报或漏报成交、修改股数、篡改中间 NAV、改权重、缺日期、重复日期、NaN 和错误库存转换都需要负例。合法同量成交、周末借券和无交易日也要有正例。

当前公共实现和配套镜像已经通过这组合成检查，包括 24 种账本/字段变异；真实 judge 入口在非法账本进入收益评分前给出零分和明确会计错误。它不宣判欺诈，也不意味着已经解决所有旧启发式评分规则。公共校验器不包含隐藏数据、评分入口或网络调用，blind 可以使用它验证公开数据上的契约。

5. 修好评测之后，低分仍可能是正确的

这是整次分析里最需要保留的反证。single blind 的账本可以对平，净收益也为正，但仅去掉错误的 NAV 扣分之后，其他表现的小计仍约为 −1.87，最终仍然被截到零。native /goal blind 去掉重复签名的 10 分误罚，会得到 18.05 的反事实值；我们没有把它回写成新成绩。

图 4|三个已结束样本的逐日 PnL 归因。每项为初始资本的未年化百分点；不能把它解读成不同 worker 的公平胜负。 (https://loopx-project.github.io/loopx/blog/images/edgebench-feedback-and-memory/return-attribution.svg)图 4|三个已结束样本的逐日 PnL 归因。每项为初始资本的未年化百分点；不能把它解读成不同 worker 的公平胜负。三个样本的净收益分别为 6.6101%、8.0799% 和 4.0096%。多头价格收益为正，空头价格收益和费用构成拖累。但题目要求对冲与风险控制，所以“删掉空头就好了“不是合理修复，更不能根据隐藏测试期表现给正在运行的 solver 定制建议。

同样，很多成交不代表成交佣金是主因。single blind 有 475 笔成交，其中 281 笔与对冲相关，这部分佣金却只有初始资本的约 0.0412%；借券成本约 0.4484%，占总费用约 0.7129% 的大部分。native /goal blind 的对应借券成本约 0.4410%，总费用约 0.6200%。把“交易次数““换手率“和“真实成本“分开，才知道下一步应该验证什么。

single blind 的年化换手约 215%，在当前评分区间之外；两项 VaR 校准也得零分。它的优化器并非完全没考虑成本，目标中包含借券和换手项，但另一个对冲调整过程按权重带和风险可行性行动，不完全共享目标改善阈值。这提供了一个可以在公开训练数据上检验的策略假设，而不是由隐藏样本直接证明的根因。

因此，本轮任务修复只调整会计与评测契约；收益、风险和换手之间如何取舍，仍然属于 solver 的研究工作。不能为了“让 blind 看起来合理“而调分，也不能为了保住某个框架的结论而删掉失败样本。

问题分布：哪些属于评测，哪些属于长程运行

下表按问题所属的责任层次归类，避免把所有低分都归到模型、LoopX 或 judge 的某一方。“已观察“描述实际证据范围，“可能覆盖“描述共享代码路径；后者不是发生频率。各组轮次、版本和终末样本数不齐，因此这里不计算故障率。

层次具体问题实际证据 / 影响范围处理与来源实验设计blind 同时丢失持续迭代提示初版 blind 包装；五种 worker 共用该构造，不表示每个模型都因此停止恢复共同提示，新 attempt；#5591 (https://github.com/loopx-project/loopx/pull/5591)实验隔离无反馈不等于没有后台评分native/blind 共用 auto-eval；agent 可见反馈必须独立限制命令、凭证、网络、服务端资格检查；#5635 (https://github.com/loopx-project/loopx/pull/5635)任务与评分同日成交误读为同日开平多个 Portfolio 输出；native/blind 共用旧契约执行与持有记录分开；EdgeBench #14 (https://github.com/ByteDance-Seed/EdgeBench/pull/14)任务与评分奖励阈值与启发式清零冲突真实 judge 的合成边界反例；不是所有样本都触发部分条件降为诊断；EdgeBench #14 (https://github.com/ByteDance-Seed/EdgeBench/pull/14)任务与评分最低投资比例、标签决定仓位审计合成相同权重、改变标签即可改变扣分移除未声明下限，仓位逐日校验；EdgeBench #14 (https://github.com/ByteDance-Seed/EdgeBench/pull/14)任务与评分scheduled / risk 事件时钟混用真实 judge 日历反例；Portfolio 公共契约event-v1 独立时钟与公开校验；EdgeBench #14 (https://github.com/ByteDance-Seed/EdgeBench/pull/14)会计校验权重时点错误、只验期末 NAV1 个 terminal blind 误扣样本 + 2 类独立合成反例ledger-v2 完整路径；EdgeBench #14 (https://github.com/ByteDance-Seed/EdgeBench/pull/14)会计校验同签名成交直接扣罚1 个 terminal /goal blind 样本中的 7 组记录执行身份 + 经济效果核对；EdgeBench #14 (https://github.com/ByteDance-Seed/EdgeBench/pull/14)会话连续性规划/heartbeat 重开 exec，换 Todo 丢失对话共享 Codex 传输路径；原生 CLI 与两 Todo 实路径验证，非得分归因Goal/Agent 级精确 session 绑定；#5527 (https://github.com/loopx-project/loopx/pull/5527)任务连续性共享 Next Action 被其他 Agent 覆盖或旧步骤复活真实 SQLite/File 路径与并发身份、旧依据反例；本轮单 worker 不能证明该并发故障发生Todo 绑定 receipt 与读取依据校验；#5531 (https://github.com/loopx-project/loopx/pull/5531)重规划证据早期有效结果被近期重复观察淹没221 条合成观察 / 身份；显示最多 24 条、可按引用恢复；模型收益未证实保留结果/路线差异，单独呈现 Goal；#5536 (https://github.com/loopx-project/loopx/pull/5536)调度与恢复可运行后继仍主动等待外部 LoopX lane；修复后 4 组 / 9 个边界读回即时重新准入；#5617 (https://github.com/loopx-project/loopx/pull/5617)协议可用性claim 试错、无条件 worktree 提示LoopX 轨迹；共享提示影响不止 benchmark#5586 (https://github.com/loopx-project/loopx/pull/5586)、#5604 (https://github.com/loopx-project/loopx/pull/5604)、#5623 (https://github.com/loopx-project/loopx/pull/5623)协议可用性已知 replan 仍要求失败重入1 条详细 resume-blind 轨迹；App / CLI 合成实路径复现#5624 (https://github.com/loopx-project/loopx/pull/5624)、#5628 (https://github.com/loopx-project/loopx/pull/5628)状态结算checkpoint/vision 恢复与结算文案不一致LoopX writeback 路径；部分问题先由本地协议复现发现#5573 (https://github.com/loopx-project/loopx/pull/5573)、#5629 (https://github.com/loopx-project/loopx/pull/5629)、#5633 (https://github.com/loopx-project/loopx/pull/5633)、#5640 (https://github.com/loopx-project/loopx/pull/5640)能力采用Explore 已开启但普通轮缺入口两个 Explore 设置；后续观察到读取、记录与路线改变共享 hook 与统一 Harness；#5610 (https://github.com/loopx-project/loopx/pull/5610)上下文传输大 packet、截断后重复取准入保存的真实 packet 与截断恢复；字节优化不等于效果提升同 Turn 完整 capture，TurnEnvelope 待 receiver 实测；#5638 (https://github.com/loopx-project/loopx/pull/5638)模型与工具同补丁 Delete/Add 同一路径2 个 blind 首轮，约 235 / 251 秒后重试恢复工具契约问题；不算调度失败，不声称有专属 LoopX 修复 PR策略研究高换手、校准不足、保守联合筛选3 个 terminal 收益归因 + 1 条 Explore 候选链任务内研究问题；不改评分来补偿，不向活跃 solver 泄露隐藏诊断待验证假设长期运行淡化真实目标注意力存在程序性 core_goal 弱点，也有模型明确重读目标的反证计划独立目标锚点消融；尚不能当作已定位根因

6. LoopX 的真实问题，怎样把额外结构变成额外负担

Benchmark 的问题不替 LoopX 开脱。轨迹中有一批很具体的控制协议问题，它们无需等待最终评分就能复现，也有明确的修复边界。

6.1 明知需要重规划，却先给模型一个必然失败的选择

一个 blind resume 的第二轮，guard 已经返回 autonomous_replan，同时要求显式选择 Todo。模型选择现成 successor 后，却收到 deferred，要求去掉 todo-id 再重入；下一次才拿到同一 wake 的 replan 结算身份。三个关键时间点相隔约 37 秒，之后模型还要读 vision detail 才继续。

这不是会话丢失，也不是死锁：系统最终自恢复了。但首次返回已经知道必须重规划，仍让模型先执行一个不能直接兑现的动作，是可以消除的协议往返。#5624 (https://github.com/loopx-project/loopx/pull/5624) 先修外部 CLI 显式 Todo 选择的生效路径；#5628 (https://github.com/loopx-project/loopx/pull/5628) 再修已知 replan 的接续。修复保留重规划义务、fresh gate、身份和幂等性，没有把 false 一律当作可自动重试，也没有降级成普通 delivery。

6.2 resume 生效，不等于这轮已经结算

这条线还有一个更早的修复：#5527 (https://github.com/loopx-project/loopx/pull/5527)。旧 runner 在规划、heartbeat 和正式执行之间重新启动 exec，且会在换 Todo 时失去对话连续性。修复让同一个 Goal/Agent 的规划和执行复用同一个原生 Codex session；Todo 可以切换，但原有研究对话不必因此重开。会话绑定与结算绑定被明确分开：前者维持上下文，后者仍由当前 Todo、Turn 和权限约束。

这里的关键不只是把一个 ID 存下来。绑定损坏、运行配置不兼容或恢复后出现意外的新 ID，都不能静默当作成功 resume；观察到 session 的超时也不自动代表取得进展。PR 的真实入口验证使用原生 Codex CLI 0.160.0 连接可控 Responses 端点，读回规划到 heartbeat 的历史，并通过公开 Turn CLI 完成两个分别结算的 Todo。它证明接续机制，不是在线模型的得分增益；benchmark 的 fresh 默认值在该 PR 中也没有被悄悄改掉。

我们按 session ID 和实际后续操作验证恢复，避免把“启动了一个新进程“当作 resume。后来的四个 LoopX 组各自保持一个 Codex session；一次明确样本中，上一轮 writeback/spend 完成约 4.894 秒后，同 session 开始下一轮。另一份快照记录了 9 个完成到下一任务开始的边界，范围 4.894–5.997 秒，中位数 5.746 秒。

这些时间戳证明观察到的边界没有原来的三分钟主动等待，不是 CPU 延迟基准，也不证明任意崩溃都能恢复。#5617 (https://github.com/loopx-project/loopx/pull/5617) 把外部 worker 的 runnable 后继改成即时重新准入，外部等待、quota 和取消仍有独立语义。

结算本身也有边界。完成 Todo 不等于完成 Turn；writeback 后缺少 vision evidence，不能直接扣 quota。原协议在 checkpoint 恢复时存在不可用选项和误导性提示，已由 #5573 (https://github.com/loopx-project/loopx/pull/5573)、#5629 (https://github.com/loopx-project/loopx/pull/5629)、#5633 (https://github.com/loopx-project/loopx/pull/5633) 逐步修复，#5636 (https://github.com/loopx-project/loopx/pull/5636) 把 canonical settlement plan 保持为共同依据。

6.3 提示不准确，会让模型把研究预算花在协议猜测上

早期可反馈组曾连续试三种todo claim参数，相关恢复指引通过 #5586 (https://github.com/loopx-project/loopx/pull/5586) 整合。另一个问题是，单 Agent 运行契约没有要求独立 worktree，heartbeat 文案却无条件要求迁移；模