EdgeBench / LHTB：一轮历史试跑的工程复盘

1. 这一轮在回答什么问题

作者在这组特定任务与配置中想检查：提交顺序、复盘和闭合证据是否有助于持续产生有效工作。这个研究问题不能由少量历史轨迹直接回答；本文先保留可定位的问题与待检验的解释，不作 LoopX 通用长程能力的判断。

EdgeBench 使用 gpt-6.1-sol / xhigh，两臂同一模型、同一镜像、同一评分器；LHTB 使用 gpt-5.6-sol / max。“原生反馈”指 Agent 可以主动提交并拿到公开评分，冷却时间内不能再提交。原 Borden 与 Grid 第二轮的 LoopX 臂启用了检查点捕获；Borden 第二对和本地历史组合版本关闭了检查点，但显式开启了 TurnEnvelope。这些处理不能混为一个默认配置，第 7 节会具体区分。

这些运行有不少没有跑完。实验控制脚本曾被另一组的评分容器触发计数守卫，也曾在读取退出中的容器时崩溃；部分运行则在写作时主动暂停。中断前的轨迹可以支持特定故障的定位，但缺少后续窗口和正常收尾，不能补成完整 24 小时结果。

2. 分数曲线说明了什么

下列现象来自所列历史运行，出现范围并不相同。它们可用于提出后续检查项，不能外推为所有 LoopX 运行的共同模式。

首次提交的时序与质量需要分开看。Borden 上原生 Codex 首次提交约在第 13.6 分钟，LoopX 约在第 48.2 分钟；Grid 上则是原生约第 21 分钟、LoopX 约第 12 分钟，后者为 3593 的占位解。提交时刻不等于反馈返回时刻，更早提交本身也不证明候选质量更好。

曲线在一个局部解上变平。Grid 上 LoopX 第 85 分钟就到了 2075——当时比原生的 2182 更好——此后 9.5 小时、9 次提交，分数从 2075 走到 2039，下降不足 2%。原生同期从 2182 到 1791，中间换了三次方法：嵌入 C++ 加速器、加入动态规划修补步骤、对代价参数做扫描。Borden 上 LoopX 从第 3 次提交起几乎只改一个振幅常数，每小时提高约 2 分。

提交有时倒退。Borden 第一对里 LoopX 11 次有效提交出现 3 次倒退；第二对里从 68.1 掉到 41.7，拆开评分器报告看，公开部分的误差在改善，隐藏井位的误差从 0.09 升到 0.74——它在拟合公开数据。原生也倒退过（54.7 到 50.3），所以这不是 LoopX 独有的问题，但每次倒退都浪费一个冷却周期。

原生在 Borden 上的 109 需要单独说明。评分器报告会返回隐藏集合的聚合指标，原生臂和本地短测里的历史组合版本 LoopX 都通过拟合这些指标到达了 109。这是协议层面的泄漏，不是建模能力；我们把它记为任务问题，不计入任何一方的能力证据。

本地历史补充：提交时序与分数未呈现一致优势

本地报告覆盖四个任务、13 条有评分运行和 71 次原生提交。它们共用一台四核、16 GiB 主机，资源上限不是独占预留。下图按每臂原生会话首记录归零，取 submitted_at 定位每次提交，再绘制截至该次提交的历史最佳分；线只连接观测点，止于末次提交，没有拟合函数、置信带或补造的零分。

* Rust 与 Jagua 的 native-goal 保留有效评分，但运行器截止回合超时，没有正常 final_result。编解码 native-goal 约38分钟自判完成；另两次编解码启动失败没有评分，未计为0分。‡ Borden 109的协议限制见上文。

以这里明确的原生首记录时钟计算，组合 LoopX 首次提交约1.7–3.0分钟，official约2.8–9.7分钟。更早提交并没有保证更高的最终最佳分：编解码和两轮Jagua均落后，Rust接近。组合版对official的非缓存输入token比值约为Borden 1.06、编解码1.31、Rust 1.01、Jagua 1.67 / 1.57；这些运行也没有显示出更少的非缓存输入，不能直接换算为总费用节省。

Borden第二对：保留早期领先，也保留中断

这对运行的控制器在容器资源采样时崩溃，随后求解进程被停止，缺少正常终态结果。陈旧状态文件仍写着 running，不能据此视为持续执行；保留的最佳分也不能作为24小时完成成绩，或作为检查点恢复已经修好的证据。

3. 历史规划：提交被排在局部准备之后

从会话轨迹和唤醒回执可以直接读出原因。planned 入口让 LoopX 先做一次规划，规划器的默认画像是面向开放式产品方向的：它把一个有明确评分器的有界任务拆成了三个顺序 Todo——P0 正向模型、P0 反演、P1“有了可运行的候选之后，再通过原生评测迭代”。每次执行唤醒恰好完成一个 Todo，然后花一到一分半钟做结算（完成 Todo、认领下一个、写回 vision、记录配额）。提交因此落在第三次唤醒。

这段轨迹中，规划约 1.3 分钟，结算合计几分钟；Todo 的顺序为本次首提交约 35 分钟的差距提供了可定位的解释。但首份候选质量、后续路径和完整成本没有被分别控制，不能据此认定“先取得反馈”一定更优，或把全部差距归因于规划顺序。

#6584曾实验性地要求先取得一次接受的评测，再扩展本地校准。这条约束已由合入主干的#6612撤回：当前运行器不再提供--feedback-first及其规划环境开关。下述首提交时间属于历史组合版本，不是当前启用建议，也不验证现行修复。本地四题的组合版本首提交约1.7–3.0分钟；同组official约2.8–9.7分钟，具体时钟见第2节。原Borden长测约48分钟的观察来自不同源码、冷却和运行条件，不能写成同条件的“48分钟降到2分钟”。

历史机制是实验运行器一侧的规划输入，不是产品能力的提升。它当时默认关闭，改变工作顺序，不改变预算、提交权或决策规则。轨迹定位到Todo顺序中的延迟；组合对照并不证明单因素收益。产品仍需回答共享规划怎样兼顾首次交付质量与有用反馈；第5节讨论的是路径停滞后仍持续原地工作的另一个问题。

维护者要求撤回，原因是feedback-first指引可能引导模型落入质量更低的初始点。更早取得反馈本身不证明首份交付更好，质量、延迟和完整成本需要分别比较。先交一个有竞争力的候选，和先交一个最小的候选，可能让后续工作走向不同；历史组合运行不能隔离这个效果。原版Grid的轨迹显示了围绕弱起点长期迭代的现象，但它没有启用新增的feedback-first，不能把该现象写成这个选项的已知副作用。这一点需要在同条件重跑中检验。

4. 复盘点崩溃：一个状态字没有被接受

Grid 的 4 个复盘点全部崩溃；Borden 第一对 87 次唤醒里 24 次失败，8 次是 EffectRuntimeInternalError，16 次是 ValueError。本地历史组合版本未启用检查点交接，没有观察到这条复盘捕获故障链；这不抹去本地另有的两条native-goal运行器超时和两次启动失败。失败的直接代价只有二十几分钟的原生时间，但每次失败都打断结算，并把之后的唤醒推进“先恢复、再审查”的模式——复盘变成了恢复的副产品。

根因是一个没有被接受的状态字。宿主在复盘点捕获检查点之后，Agent 在同一轮选择 Todo；这次选择会在 CLI 内部重新读取一次 guard，回执的状态渲染为 upgraded——它是同一份持久回执的合法视图，表示选择已把绑定追加上去。检查点选择器只接受 committed 和 replayed，于是抛出一个没有类型的错误，宿主把它表面化为内部错误，整次唤醒结束。

CLI 一侧把损害放大了。被拒绝的交接落进了外层 guard 的兜底分支，被报告为 quota_unexpected_collection_error——“取数失败”——并覆盖了已经保存的决策文件。下一次唤醒恢复的原生会话还记得上一轮的交接 socket，而那个 socket 随上一次唤醒一起删除了，于是先是配额校验失败，再是捕获目录的 ValueError。两道题的失败唤醒都是这一条链。

修复在 #6601，全部是产品代码：选择器接受 upgraded，拒绝时抛出带原因的类型化错误；guard 之后的捕获或交接失败成为一个新的类型化结果 quota_decision_transport_failed，连同已提交的回执和已保存决策的路径一起返回，不再覆盖；过期 socket 明确报告“属于已结束的唤醒，guard 没有运行”；失败报告保留错误类型和有限长度的信息——此前唤醒回执只记了异常类名，这也是这个问题过了两道题才被定位的原因。七个新测试在修复前全部失败、修复后全部通过；默认路径（不开捕获、不开交接）行为不变。

没有修的部分：恢复的会话仍然可能记住旧 socket，只是现在会在 guard 运行前得到明确的错误；崩溃之后的下一次唤醒不会自动回到复盘模式。两者都指向同一个更大的设计问题——每次唤醒一个新 socket 的传输方式——第 7 节会回到这里。

5. 原地微调：复盘允许保持现状，而它一直在保持

Grid 上最值得解释的不是崩溃，而是崩溃之间的 9.5 小时。我们从 Todo 状态、复盘记录和工具调用里读到三件事。

四次复盘都选择了“保持路线”。周期复盘每 6 个已结算 Turn 触发一次；复盘指引写着“到期的复盘可以保持现有路线，不强制换路”；新颖性检查只要求一个新假设。于是“把运行时上限从 28 秒再压一点”算作新假设，四次复盘都通过了。同一时间原生分数从 2182 降到 1878，LoopX 的每一次复盘都看得见这个差距，但没有任何规则要求它据此做什么。

一个笼统的 Todo 占了十个小时。规划产出的第三个 Todo 是“提交……并继续有用的本地改进”。它从未关闭，租约续了 12 次，没有新增任何 Todo。Todo 列表里没有策略：没有“假设族”，没有退出条件，没有“如果三次提交不改善就换方法”。

控制面开销约占四分之一。188 次 LoopX CLI 调用加上约 345 次读取 guard 包和决策文件，大约占 11.7 小时中的 2.8 小时；输入 token 2.07 亿对原生的 1.46 亿；上下文压缩 20 次对 7 次。原生几乎没有这类开销。

为什么不能简单加一条“分数停滞就强制换路”

本文核对的核心版本以 Agent 自报的 advanced、unchanged、blocked 分类记录进展；Grid 轨迹中每轮都申报 advanced。2041、2040、2039 的小幅改善不足以单独判断是否应换路。通用核心不应猜测 provider 指标的含义：Lean 中“少一个 sorry”和 Borden 中“多两分”没有共同的换路阈值。这说明需要明确指标解释与重规划的归属，不能据此断言模型只会微调或 LoopX 没有进展能力。

设计里已经为此留了位置：外部进展审查。一个独立的观察者在每次工作转换后写入类型化的“漂移”回执；在 assist 模式下，连续若干次漂移会升级为现有的重新规划义务，而回答这个义务时不能复述旧假设或只改名字——必须带新证据。在本文核对的版本中，它默认关闭，已有观察者判断的是代码变化，不是评分器分数。而且它有一个产品缺陷：当归属信息缺失（没有 agent-id，或窗口里没有类型化进展记录）时，assist 会静默地永远不触发，status 看起来却一切正常。

作者据此提出三项尚未实现、也未验证收益的方向：由 provider 定义指标方向、阈值与停滞判断，并通过既有义务链提供漂移信号；显式显示 assist 无法触发的原因；让迭代 Todo 带可检查的退出条件。这些是待评审的设计假设，不是 LoopX 已承诺的机制或正式路线图。即使实现，也须再检验能否改善决策与结果，不能保证 Agent 会选择更好的方法。

6. 过早关闭：验收门改变了“什么算做完”

LHTB 的四道试点任务给出了同一个模式。四次运行里，LoopX 的调度器都在 90 分钟预算的第 43–60 分钟发出 stop_until_explicit_resume，理由一字不差：“已验证的闭合证据推导出无后续，并确认没有剩余前沿”。此时隐藏集 reward 分别是 0.000、0.028、0.086 和 0.093。只有外层“继续直到超时”的机制把 Agent 叫了回来，第二阶段没有再自行停止。

这些试点与此前 Portfolio 的 no_followup 案例都提示一个验收缺口：Todo 完成不等于原目标已满足。在本组运行中，闭合证据未覆盖隐藏评估所要求的完整行为。两题的交付物在隐藏包装清单上退出非零，另一题虽通过格式检查，却在权重 0.89 的端到端压力测试上得零。它们支持检查验收接口覆盖，不足以概括 LoopX 的一般闭合能力。

我们没有改调度规则，而是改了闭合证据的来源。#6585（现已关闭、未合并）的历史分支试验引入显式开启的 LOOPX_ACCEPTANCE_CONTRACT=planned：规划阶段让模型同时写一份目标验收文档——哪些 Todo 交付结果、每个 Todo 绑定哪些可执行的验收条件、条件必须通过任务说明的验证接口来检验交付物；实验宿主以受信任的本机 owner 身份，通过现有的 goal-acceptance 契约配置它。之后被选中的 Todo 在条件通过之前不能完成，目标也不能在它仍然开着时关闭。

机制读回：规划配置了 3 条条件一一绑定 3 个 Todo；第一个 Todo 的 todo complete 运行了绑定的“通过提交的模型在公开验证行上调用 predict”条件并通过——这正是试点里交付物在评分器沙箱中无法预测的那个故障。第二阶段重新规划后写了新条件，两次完成尝试因交付物不满足而被拒绝，直到满足为止。

这项改动的性质同样要说清。验收门是实验运行器替模型写文档、再调用 LoopX 现有能力；LoopX 自己仍然在第 38 分钟宣布完成。它改变的是“什么算闭合证据”——必须是验证器形状的、owner 锁定的——而不是“Agent 可不可以关闭”。0.82 是一次运行；强制继续之后是否还有增益，这次实验回答不了。评审还找到了一个真实的反例：再次确认时宿主重新读取了模型可改写的草稿，于是一次 Todo 编辑加一次条件改写就能让缺失产物的 Todo 完成。现在宿主只重放自己接受过的那份文档，并在 owner 契约摘要变化时拒绝；这个反例已进入真实 CLI 测试。

7. 哪些数字不能用

写到这里，有一个发现迫使我们重新给前面的证据定性。

LoopX 有一个默认关闭的 TurnEnvelope：把几十 KB 的配额决策压缩成约 8 KB 的行内视图，其余内容写到文件按引用读取。检查点交接的实现会在传了捕获目录时自动给 guard 命令加上 --turn-envelope。原Borden与Grid第二轮因此实际启用了envelope；本地历史组合版本和远端Borden第二对虽然关闭checkpoint，却显式开启了envelope。本地回执明确为 turn_envelope=true、turn_envelope_source=explicit。它们都不是干净的envelope-off对照；没有观察到捕获故障链不能证明关闭envelope改善了稳定性。

Grid 提供了一份开启 envelope 的历史运行观察：Agent 约读取 345 次完整捕获文件，每个 37–57 KB；约四分之一的控制面开销是在此配置下记录的。但没有同条件 envelope-off 对照，不能据此把开销或分数停滞归因于 envelope。另一个未合入组合版本放宽重入规则后记录到 CLI 调用 65 与 25、配额检查 40 与 8 的差别；这提示应单独检验重入节奏，不证明它是唯一或主要原因。

由此形成两个待验证的设计问题：交接与 envelope 是否应解耦，以及在不开检查点、同题同条件下，envelope 开/关怎样影响未缓存 token、包读取次数、CLI 调用、时间占比和分数。保留行内决策文本、按需读回细节并明确重入节奏，是作者提出的候选方向；这些观察没有证明其最优性，也不构成已经验证的产品结论。

还有三类数字要单列。实验控制脚本的事故——容器计数守卫被评分容器触发、控制进程读取退出中的容器时崩溃——缩短了运行，但不是 LoopX 的故障。Borden 的 109 来自评分协议泄漏，第 2 节已经说明。所有“修复后”的本地数字都带着多项变化同时发生：feedback-first、放宽的重入规则、显式 envelope；没有一个可以单独归因。

8. 怎样评价这批修复

下表区分历史运行观察、局部契约验证与尚待验证的假设。产品代码、实验运行器输入及配置同时变化时，分数差异不能单独归因；补丁合入、局部测试通过或运行器曲线变化，都不等于当前 LoopX 的通用能力或效率已经得到验证。

这些记录的工程价值是保留可核对的故障链、退出条件与验收反例。局部修复可以通过对应入口复现和回归测试核验；是否改善长程任务表现，还需要声明版本与配置、保留失败的对照重跑。本文不能从这些片段推出“问题主要在产品而不在模型”，也不能据此评价 LoopX 整体优于或弱于原生执行器。

9. 作者建议的后续验证

历史运行截点时，远端运行已暂停，证据保留。此后#6584与#6601已进入主干，#6612撤回feedback-first。下列顺序是研究提案，不授予执行权限：新运行须另有授权，#6585现已关闭且未合并；保留的分支证据不表示主干支持这项策略。

本文留下的是历史配置下的工程排查线索，而不是 LoopX 的正式能力结论。作者希望后续在明确的源码、模型、任务、反馈、预算与资源条件下，分别检查局部修复是否生效，以及任务质量和效率是否受益。更早反馈不等于更好交付，局部修复通过不等于长程收益成立；已撤回的策略不能作为当前启用建议。