4.1.2 · 长轨迹信用分配

1. 从调用记录恢复条件概率

策略梯度依赖的是生成动作时的条件概率。若第 $t$ 次调用真正看到的输入为 $x_t$ ，采样 token 序列为 $u_t=(w_{t,1},\ldots,w_{t,L_t})$ ，行为策略给出的对数概率应为

\log \mu(u_t\mid x_t)=\sum_{j=1}^{L_t}\log \mu(w_{t,j}\mid x_t,w_{t,<j}).

轨迹重建不能拿 episode 结束后的完整历史重新拼一个 $\tilde x_t$ 再算概率。只要 $\tilde x_t\neq x_t$ ，训练器算出的便是另一个条件分布。压缩、动态 system prompt、时间戳、工具列表变化都会制造这种差异。最稳妥的做法是保存发给推理服务的规范化请求正文，并对其计算内容哈希；重放时先检查哈希和 tokenizer 版本，再重算 token 序列。请求中若含不可训练的模板 token，要同时保存损失掩码生成规则，而非依靠后来版本的 chat template 猜测。

工具调用还会带来边界问题。某些服务把工具调用编码成特殊 token，某些服务返回 JSON 文本，另一些服务把函数名与参数放进独立字段。若日志只保存可读文本，反序列化后可能丢掉模型实际采样的控制 token。训练器应以推理端返回的 token ids 或可无歧义复原它们的结构为准。特别是 JSON 被 Harness 自动修复时，应分别保存模型原始输出与执行版本；前者参与 policy loss，后者决定环境转移。把修复后的 JSON 当作模型动作训练，相当于让策略为一个从未生成的序列获得奖励。

一个具体例子能看出偏差。模型输出 {"path":"a.txt" "content":"x"}，缺少逗号；Harness 自动修复后成功写入文件，最终任务通过。环境层面的动作是成功写文件，策略层面的样本却包含格式错误。若直接给整段输出正优势，格式错误也被提高概率。可选处理有三种：保留奖励并期待其他失败样本抵消；把自动修复记作成本，在 reward 中扣除；或把该调用标成 Harness 介入样本，只训练修复前仍可明确归因的 token。三种方案优化目标不同，实验报告需要说明采用哪一种。

多进程 Harness 更复杂。设父调用 $c_0$ 创建两个并行分支 $c_1,c_2$ ，它们看到的历史并不相同，完成顺序也未必等于创建顺序。若按日志时间简单串接，会让 $c_2$ 看见实际只属于 $c_1$ 的观察，从而制造不存在的条件依赖。正确结构是一棵调用 DAG：节点保存输入、输出和本地顺序，边表示父子关系、消息继承或环境同步。只有共享状态经过明确同步之后，另一个分支才可把它纳入观察。对并行工具执行，也要区分「同时发出后统一汇总」和「先返回者立刻进入下一次推理」；两者诱导的策略完全不同。

可以给重建器设置四条不变量。第一，逐调用重放所得 token ids 与原记录一致。第二，每个被训练 token 都能追溯到唯一 policy 版本和一次真实采样。第三，所有环境观察均出现在产生它的动作之后，且没有跨分支偷看。第四，episode 的终止、reward 与最终状态哈希能够对齐。只要任一条失败，这条数据仍可用于系统排错，却不应悄悄进入在线策略更新。

解耦 rollout 与训练能提高吞吐，也会让长轨迹放大 policy lag。设轨迹由行为策略 $\mu=\pi_{\theta_{k-d}}$ 生成，训练时参数已经更新到 $\pi_{\theta_k}$ 。单个 token 的重要性比率为

r_{t,j}=\frac{\pi_{\theta_k}(w_{t,j}\mid x_t,w_{t,<j})} {\mu(w_{t,j}\mid x_t,w_{t,<j})}.

若把整次调用看成一个动作，序列比率是所有 token 比率的乘积。即使每个 token 只偏离一点，长输出的乘积也可能迅速趋近零或变得极大。假设每个 token 在新策略下相对旧策略平均只有 $1.002$ 倍，一段 2000 token 输出的序列比率约为 $1.002^{2000}\approx54.5$ ；平均是 $0.998$ 时则约为 $0.018$ 。长程 Agent 比短回答更怕策略滞后：episode 更慢、策略版本落后更多，同时每条序列又更长。

PPO 类算法通常裁剪 token 或序列比率，但裁剪只能限制一次更新的幅度，不能把严重离策略的数据重新变成 on-policy 样本。大量 token 落到裁剪区间外时，有效梯度来自少数位置；若进一步按 episode 聚合，长轨迹还会因乘积退化失去作用。系统需要同时观测策略年龄、KL、比率裁剪比例和有效样本量。对带权样本，可用

N_{\mathrm{eff}}=\frac{(\sum_i w_i)^2}{\sum_i w_i^2}

衡量权重集中程度。收集了一万条 episode 并不意味着拥有一万条有效样本；若少数新轨迹占据绝大部分权重， $N_{\mathrm{eff}}$ 会远低于原始计数。

一个调度例子：集群每分钟启动 120 条 episode，平均完成时间 12 分钟，P95 为 35 分钟；训练器每 4 分钟推进一次 policy。平均样本完成时已落后约三个版本，尾部样本可能落后九个版本。若按完成顺序立即入队，短任务总是更接近当前策略，长任务总是更陈旧。最终训练器不只偏爱简单任务，还系统性低估长轨迹。把最大允许版本差设为两步会丢掉大量昂贵样本；放宽到十步又加剧离策略偏差。更合理的办法是按任务长度分桶设置窗口，减少更新频率或在一批 rollout 完成前冻结采样策略，并把被丢弃样本的计算成本纳入吞吐报告。

冻结策略也有代价。若等待所有长尾 episode 完成，GPU 可能空转，快速任务产生的新数据也无法及时利用。可以让多个固定版本的 rollout cohort 并行，每个 cohort 在自己的版本内完成组内比较，训练器消费完一组再释放对应推理副本。这牺牲部分显存与调度复杂度，换来清晰的行为策略归属。另一种做法是只让过旧轨迹进入 SFT、失败分析或 replay buffer，不用于要求近似 on-policy 的优势更新。数据并未浪费，只是换了与其统计性质相符的用途。

组相对算法还有额外约束。同一任务的 $G$ 条响应若来自不同 policy 版本，组均值不再只是同一条件下的相对难度基线，也混入版本能力差异。设旧策略成功率为 $0.2$ ，新策略为 $0.6$ ，组内各采两条；即使任务与采样参数相同，旧样本更容易得到负优势。更新会把「来自旧版本」误当成「动作较差」。因此，一个 reward group 应尽量共享任务版本、Harness 版本、初始状态、采样策略和采样参数。做不到时，至少要分层中心化或将跨版本样本剔出组比较。

这组条件解释了组内相对优势方法在部分长程任务上的困难。每个 prompt 需要生成一组昂贵轨迹；若奖励只在终点出现，整组又经常全成或全败，组内标准差接近零，中心化以后几乎没有可用信号。异步完成和长度差异还会引入策略陈旧与选择偏差。不过，这并不能推出「长轨迹必然不能用 GRPO」。只要过程奖励足够可靠、分组保持同一策略版本、任务处在具有组内方差的难度区间，组内基线仍然可以工作。

PPO 的区别在于额外学习价值函数 $V_\phi(s_t)$ 。给定时序差分残差

\delta_t=r_t+\gamma V_\phi(s_{t+1})-V_\phi(s_t),

GAE 用

\hat A_t^{\mathrm{GAE}(\gamma,\lambda)}= \sum_{l=0}^{T-t-1}(\gamma\lambda)^l\delta_{t+l}

把未来回报按时间位置传回当前动作。它提供了组内终局比较没有直接给出的时间分辨率，也会引入 critic 偏差、额外显存和训练不稳定性。因而选择取决于哪种误差更难承受：组内奖励塌缩与昂贵重复采样，还是价值估计误差与 critic 成本。公开材料若只说明某个 GLM 长程训练配方采用 PPO，只能确认算法选择；除非作者给出对照、消融或明确说明，不能把上述机制分析写成该团队已经证明的唯一动机。

判定器噪声会通过观测奖励移动最优策略。任务原本有一个不可直接观测的真实成功变量 $y\in{0,1}$ ，verifier 给出的标签为 $\hat y$ 。记假阳性率为 $\alpha=P(\hat y=1\mid y=0)$ ，假阴性率为 $\beta=P(\hat y=0\mid y=1)$ 。对真实成功概率为 $p_\pi$ 的策略，观测成功率为

\hat p_\pi=(1-\beta)p_\pi+\alpha(1-p_\pi) =\alpha+(1-\alpha-\beta)p_\pi.

如果 $\alpha,\beta$ 是固定常数且 $\alpha+\beta<1$ ，观测成功率仍与真实成功率单调对应，只是差距被压缩。然而 RL 会主动寻找 verifier 的薄弱点，错误率通常依赖策略产生的行为。策略学会创建一个空文件后，针对「文件存在」检查的假阳性率会上升；策略学会把目标文字放进隐藏节点后，基于页面文本的检查也可能失真。此时 $\alpha=\alpha(\pi)$ ，最大化 $\hat p_\pi$ 未必最大化 $p_\pi$ 。

考虑两个策略。策略 A 真正完成任务的概率为 $0.7$ ，几乎不会投机，假阳性率为 $0.02$ 、假阴性率为 $0.05$ ，观测成功率为 $0.02+0.93\times0.7=0.671$ 。策略 B 真正成功率只有 $0.4$ ，却能利用检查漏洞，使假阳性率达到 $0.5$ 、假阴性率为 $0.05$ ，观测成功率为 $0.5+0.45\times0.4=0.68$ 。训练会偏向 B，尽管它解决真实任务的能力更差。差距很小时，这种翻转不会在平均曲线上显得离谱，只有审查高奖励失败样本才能发现。

改进 verifier 不能只追求更多规则。多个检查若共享同一个错误假设，简单投票并不会消除偏差。比如文件存在、文件非空、文件含目标关键词三个检查都无法证明程序行为正确，它们只是对表面产物做了三次相关测量。更强的验证应尽量读取因果后果：执行隐藏测试、查询服务端状态、重新加载页面、从干净客户端验证权限，或在扰动输入上检查性质。对代码任务，示例测试确认基本接口，隐藏测试覆盖未见输入，变形测试检查输入变化后的关系；三者提供的是互补证据。

判定器还要抵抗状态污染。一次成功 rollout 留下数据库记录，下一次失败 rollout 可能借用旧记录通过验证；测试顺序固定时，早期步骤也可能替后续任务准备资源。验证协议应从已知初态启动，验证结束后销毁或恢复快照，并用状态哈希确认隔离。若恢复开销太高，至少随机打乱任务顺序，插入空白对照，观察无动作 Agent 是否也会获得奖励。无动作基线的通过率大于零，通常意味着初态、判定器或任务定义存在漏洞。

假阴性同样会扭曲学习。一个任务允许多种等价实现，而 verifier 只接受参考解的文件布局，正确的新方案会被惩罚。长期训练后，策略倾向模仿判定器偏好的表面形式，探索空间变窄。可以从失败样本中抽取环境终态，由独立测试或人工复核估计假阴性；也可以对输出做语义保持变换，例如重命名局部变量、调整无关布局、改变等价操作顺序，检查 reward 是否稳定。这里的目标在于让奖励对任务允许的等价类保持一致，同时继续拒绝缺少核心结果的方案。

训练期间需要版本化 verifier，因为修复漏洞会改变 reward 尺度。若 v1 误把空文件判成功，v2 加入内容检查，同一策略的成功率可能突然下降。把 v1 与 v2 数据直接放进一个组里做相对优势，等于把规则升级误认为策略退化。历史轨迹若保留完整终态，可以用 v2 重新评分；无法重放时就应分版本统计。模型 checkpoint、任务与 verifier 三者共同定义了一条可解释的学习曲线。

1.1. 长程 credit assignment 的可用分解

终局奖励把整个 episode 压成一个比特，优点是目标干净，缺点是无法指出哪一步促成成功。直接给全部生成 token 同一个优势，相当于假设所有动作贡献相同。对一条包含探索、误操作、恢复和最终修复的轨迹，这个假设显然很粗。更细的分解需要借助环境状态，却不能把容易投机的过程指标冒充最终目标。

一种做法是定义势函数 $\Phi(s)$ ，用势差构造 shaping：

r'_t=r_t+\gamma\Phi(s_{t+1})-\Phi(s_t).

在理想 MDP 和正确势函数下，这类 shaping 不改变最优策略，只改变学习信号的密度。真实 Agent 环境中， $s_t$ 部分不可观测， $\Phi$ 往往由测试通过数、资源存在性或页面状态近似，理论保证随之减弱。若测试之间有前置关系，单纯用通过比例作为势函数还可能不单调：修复核心接口时暂时破坏一个表面测试，长期更接近目标，短期势值却下降。

另一种做法是事后找关键转折。将轨迹在第 $t$ 步的环境快照复制出来，从该点采样多个续写，估计

Q(s_t,a_t)\approx\frac{1}{K}\sum_{k=1}^K R(\tau_{t:}^{(k)}).

再与替代动作或状态基线比较，可判断某一步是否显著改变成功概率。它比语言模型对步骤打分更接近任务事实，代价是需要可快照环境和大量分支 rollout。对昂贵 GUI 或真实网站，完整反事实采样可能不可承受，可以只在失败聚集的少数节点执行。OpenForge 的远程沙箱与版本化环境为这种研究提供了基础，但仓库公开能力并不等于论文已经完成了全部反事实归因实验。

还可以按可逆性划分动作。读取、搜索和列目录通常不改变外部状态；写文件、提交表单、删除资源会改变状态；发布、付款或外部消息可能不可逆。对于只读探索，失败后的代价主要是 token 与时间；对于不可逆动作，错误会直接封死后续路径。课程设计可以先训练模型在高不确定性时使用只读观测，证据充分后再执行写操作。这种设计把动作风险写进成本，目标与奖励「思考得多」不同：

R'(\tau)=R(\tau)-\lambda_c C_{compute}(\tau)-\lambda_r C_{risk}(\tau).

两个系数必须与应用目标对应。若 $\lambda_c$ 太大，策略会跳过必要检查；若 $\lambda_r$ 太大，策略会拒绝任何可能失败的操作。报告 pass rate 时同时给工具步数、耗时、不可逆动作数和人为接管率，才能看出性能提升是否靠更高代价换来。

错误恢复可以拆成「发现—诊断—回滚—改道」四个能力。模型先要发现结果与预期不符，再根据观察区分参数错误、权限错误、环境故障和方案错误；随后恢复到可继续的状态，收尾阶段选择新动作。只在顺利成功轨迹上训练，四步都很少出现。构造 recovery task 时，应从真实失败快照开始，保留足以诊断的日志，并让 verifier 检查最终任务和状态完整性。若只奖励输出一段错误分析，模型学到的是解释失败；若重置成全新任务，模型学到的是重新开始。真正的恢复要求它处理已经被部分修改的世界。

远程沙箱训练的有效学习量同时受容量和吞吐限制，瓶颈常在 CPU、启动和外部工具等待，而非生成 token。设集群最多运行 $N$ 个 Pod，单条 episode 平均占用时间为 $T_e$ ，可用率为 $u$ ，粗略完成率为

q=\frac{Nu}{T_e}.

若 $N=600$ 、 $u=0.8$ 、 $T_e=15$ 分钟，每小时约完成 $600\times0.8\times60/15=1920$ 条。假设环境故障率 8%、轨迹重建失败率 4%、策略版本过旧丢弃率 10%，三类近似独立，则可用于目标更新的比例约为

(1-0.08)(1-0.04)(1-0.10)=0.795,

每小时有效轨迹约 1526 条。若每个任务组成 8 条响应的一组，最多形成约 190 个完整组。只报告 1920 条 rollout，会高估真正进入优势计算的数据量约四分之一。

启动时间也会改变最优调度。假设容器冷启动 90 秒，实际交互 6 分钟，销毁与验证 30 秒，单条总时长 8 分钟，启动与收尾占四分之一。复用 Pod 能提高吞吐，却带来状态泄漏；每条都冷启隔离最强，成本更高。折中方案是在同一不可变镜像上复用节点缓存，不复用任务文件系统和服务状态；或者一个 Pod 顺序运行多个任务，但每次恢复经过校验的快照。无论采用哪种方式，都要用无动作验证与状态哈希证明隔离，而不是把「容器还在」等同于「状态干净」。

批量调度还存在 head-of-line blocking。若一个 batch 必须等最慢 episode 才能更新，少数卡死任务会拖住全部样本；若先到先训练，短任务又得到更多更新机会。可以为 episode 设置软截止时间和硬截止时间：软截止后允许已完成样本组成同质小组，硬截止后终止并按原因分类。任务采样器按单位墙钟时间的有效信息量分配预算，同时给困难任务保留最低配额，避免系统只追求吞吐而把长程能力训练掉。

有效学习量还取决于组内差异。若同一任务的八条 rollout 全部成功或全部失败，简单中心化优势接近零，这组样本几乎不提供相对排序信号。成功率接近中间区域的任务更有信息，但只采这类任务会改变目标分布。可以把训练采样分布 $q(x)$ 与目标任务分布 $p(x)$ 分开：训练时增加临界任务比例，评测仍按 $p(x)$ ；需要估计总体目标时再用分层统计或重要性加权。任务难度随策略更新而变化，课程调度器应根据滑动窗口更新，且保留固定锚点任务监控遗忘。

OpenForgeRL 将真实部署 Harness 接入记录代理、远程沙箱和 RL 训练器，并在 Claw、GUI 等任务上报告了训练后的可测提升。论文还比较了 Harness 对可学习性的影响，观察到自检、工具覆盖和多步完成改善，而错误恢复仍弱。这些结果支持把 Harness 纳入训练分布，并把环境、Harness 与 policy 分别版本化。

它并不能单独证明任何真实 Harness 上训练都会提升，也不能证明跨 Harness 迁移必然发生。任务合成、底座模型、判定器质量和采样预算都会改变结论。某个 Harness 训练后得分较高，可能因为它提供更清楚的工具反馈，也可能因为任务生成过程更贴近它的动作空间。要区分两者，需要交换 Harness、固定任务与预算，并对未见接口做测试。

公开仓库还明确提示项目正在重组和调试，部分路径、checkpoint 与任务尚未公开。因而当前读者可以核查核心架构、环境接入和示例训练流程，却未必能从头重现论文全部数字。严谨的复现记录应把「代码能够运行」「公开任务上得到趋势」「复算论文主表」分成三个层级。第一层验证接口，第二层验证机制，第三层才验证完整经验结论；前两层成功不能自动宣称第三层完成。

此外，论文报告的 pass@3、pass^3 与单次通过率含义不同。若三次采样独立且单次成功率为 $p$ ，至少一次成功的理想值为 $1-(1-p)^3$ ，三次全成功为 $p^3$ 。真实 Agent 的多次采样共享任务、环境和系统故障，独立假设往往不成立。一个不稳定 verifier 可能让三次结果同时错误，一个任务镜像损坏会让三次全部失败。报告这些指标时应给出实际逐任务聚合定义，保留同一任务的联合结果，不能只用独立公式从平均单次成功率反推。

2. 任务合成是一道分布设计题

OpenForgeRL 的任务流水线可以概括成 propose、prune、build、test、refine。五个动词看起来像数据生产步骤，真正决定训练行为的是它们共同定义了什么样的任务能够留下。提议器从种子、领域描述或现有环境中生成目标；裁剪器删除重复、不可验证或过于简单的题；构建器准备镜像、初态、mock service 与验证代码；测试阶段让参考方案和故意破坏的方案通过同一判定器；修订阶段处理无法启动、答案泄漏和判定歧义。最终进入训练池的是经过这条流水线筛中的条件分布。

设自然任务分布为 $p_{real}(x)$ ，提议器产生 $q_0(x)$ ，第 $j$ 个筛选步骤以概率 $a_j(x)$ 接受任务，最终训练分布满足

q_{train}(x)\propto q_0(x)\prod_j a_j(x).

某类任务若很难自动验证，它的 $a_{test}(x)$ 就低；若需要昂贵外部服务，它的 $a_{build}(x)$ 也低。即便提议器覆盖了它，最终训练池仍会系统性缺失。于是可验证性从质量门槛变成了隐含课程：文件修改、结构化 API 和确定性网页状态容易留下，开放式研究、长期沟通与依赖现实反馈的任务容易消失。模型在合成池中进步，第一步说明它适应了这个可构建、可重置、可验证的子空间。

裁剪重复项也不能只靠文本相似度。两条指令分别写「修好分页」和「列表第二页不显示，请处理」，底层仓库、失败测试和修复路径可能完全相同；两条文字完全相同的指令若初始数据库、权限或依赖版本不同，又可能要求不同策略。任务身份应至少由目标语义、初始状态摘要、环境资产、隐藏验证结构和允许动作共同决定。训练集与评测集去重时，也要沿这些维度检查。只对 prompt 做 embedding 去重，会把改写泄漏留在数据中。

参考方案能证明任务至少存在一条已知可行路径，不能证明判定器覆盖全部正确路径，也不能证明普通策略在预算内可达。参考方案若拥有额外权限、预知隐藏测试或绕过 Harness，任务对模型可能仍不可解。合成阶段应让参考方案使用与待训 Agent 相同的工具、权限和时间限制，并保存逐步轨迹；随后从干净快照复跑，确认成功不依赖构建过程残留。

为了测试 verifier，可以构造三类负例。第一类删除参考方案的关键动作，验证缺失核心条件时确实失败。第二类只制造表面产物，例如创建同名空文件、在页面不可见区域写目标文本，检查是否会误判。第三类保留语义结果但改变实现形式，检查判定器是否错误拒绝等价解。这三类分别探测漏检、投机和过拟合参考答案。测试通过后仍需在训练过程中抽样审计，因为策略会发现人工负例没有覆盖的新路径。

任务难度也不能用参考轨迹长度单独衡量。短轨迹可能需要一次非常精确的不可逆选择，长轨迹可能只是机械浏览。更可用的难度描述包含基础策略成功率、成功轨迹长度分布、失败模式熵、可恢复错误比例和动作分支度。若八次采样有四次成功，组相对更新容易得到正负信号；若始终为零，它可能太难、环境可能损坏，也可能 verifier 过严。这三种情况只有通过参考方案、环境健康检查和失败分类才能分开。

合成任务还容易继承生成模型的语言习惯。目标描述过度完整、验收条件全写在 prompt 中、每个歧义都被提前消除，会训练出依赖「教科书式任务」的策略。真实请求常含省略、错误术语和逐轮补充。可以在保持隐藏目标不变的前提下生成不同信息条件：完整规格、缺少次要细节、带一处可澄清歧义、含无关背景。评测时分别观察策略会不会检查环境、提出必要问题或根据证据消解歧义。扰动不能改变任务本身，否则比较的已是两道题。

Harness 让基础模型得分更高，可能因为它替模型做了更多工作；让 RL 增益更高，则可能因为它给出了更稳定的学习接口。这两个维度需要分开。它的可学习性主要来自观察质量、动作可表达性、控制流援助和错误反馈：观察质量决定关键信息能否进入上下文；动作可表达性决定模型能否用有限步骤完成目标；控制流援助包括自动规划、重试、压缩和并行；错误反馈决定失败后是否有可辨别的下一步。

假设 Harness A 为基础模型提供强自动重试，初始成功率从 30% 提到 50%，但所有失败收尾阶段都被压成同一句「执行失败」；Harness B 不自动重试，初始成功率只有 35%，却返回稳定的错误码、失败动作和状态差异。RL 后 A 可能到 55%，B 可能到 60%。A 的部署援助更强，B 的可学习性更好。只比较训练后的绝对分数会说 B 略强，只比较 RL 增量又会忽略 A 的高起点。完整结果至少要同时报告 base、post-RL、绝对增益和单位训练成本。

可以用二维交换实验寻找因果来源。固定 policy 和任务，把 A 的观察格式配给 B 的动作执行器，再把 B 的反馈格式配给 A；若改善随观察格式移动，关键因素在 $O_H$ ，若随执行器移动，关键因素在 $G_H$ 或转移规则。现实中组件未必可直接互换，但可以用适配层统一工具语义，逐项消融压缩、重试、错误回传和工具描述。每次只改变一个机制，比把两个完整产品端到端对打更能解释结果。

工具 schema 是可学习性的典型来源。一个参数同时接收字符串、列表和隐式默认值，看似灵活，实际让模型面对多种等价表示；严格 schema 会在执行前拒绝错误，减少环境污染，也可能让小格式错误阻断本来正确的意图。训练中应分别统计语义选择错误与参数编码错误。若 RL 提升主要来自 JSON 合法率，说明模型学会了接口；若工具选择和最终状态也改善，才说明规划能力同时增长。

上下文压缩决定长轨迹中的记忆通道。可把完整历史 $h_t$ 经过压缩器 $C_H$ 得到 $x_t=C_H(h_t)$ 。理想压缩保留对后续最优动作充分的统计量，但任务未知时很难做到。一个实用测试是反事实删除：从成功轨迹中删除压缩摘要里的某条事实，观察后续动作分布和成功率变化；也可以把关键事实以不同表述重复注入，检查模型是否真正使用它。若压缩器总把失败尝试删掉，模型会反复走旧路；若把每个错误都保留，目标和当前状态又会被噪声淹没。

自动重试同样有双刃剑。瞬时网络故障适合透明重试，权限不足、参数无效和资源不存在则需要模型改变方案。Harness 若对所有错误统一重试，会消耗预算并隐藏诊断信息；完全不重试又把随机基础设施噪声交给策略。可以根据错误的条件独立性决定：若再次执行在状态不变时有合理成功概率，允许有界重试；若失败由动作内容决定，立刻返回结构化原因。训练日志要保留每次自动重试，否则模型成功看起来会比它真实贡献的更大。

多 Harness 联合训练的目标也不应被理解成简单数据相加。设共享语义技能参数为 $\theta_s$ ，接口适配行为为 $\theta_h$ 。不同 Harness 的梯度可能在共享能力上同向，在格式行为上冲突。可以测量同一 batch 上的梯度余弦：正值表示局部协同，负值表示竞争。即使不直接修改优化器，这个诊断也能告诉研究者冲突来自哪些工具和任务。若冲突集中在调用格式，可以通过统一中间表示或少量 Harness 标记缓解；若冲突来自互斥的安全策略，就不该强行抹平。

从 episode 汇总到更新时，需要先区分 Agent 评测中的 pass@k 与 pass^k。前者关心 $k$ 次中至少一次成功，适合用户允许重试或从多个候选选最优的场景；后者关心多次均成功，强调稳定性。设同一任务第 $i$ 次采样结果为 $Y_i$ ，逐任务统计量分别是

\mathrm{pass@}k=\mathbb{1}\left[\max_iY_i=1\right],\qquad \mathrm{pass^}k=\mathbb{1}\left[\min_iY_i=1\right].

它们应先在任务内聚合，再对任务取平均。把所有 rollout 混在一起算总体成功率，再代入独立公式，会忽略任务难度差异与同一环境故障造成的相关性。若一半任务成功率接近一、一半接近零，总体单次通过率可能是 50%，实际 pass@3 仍接近 50%，远低于独立同分布假设给出的 87.5%。

训练组内的奖励归一化也受任务难度影响。对同一任务采样 $G$ 次，二元奖励均值为 $\bar r$ ，中心化优势 $A_i=r_i-\bar r$ 。当 $\bar r=0$ 或 $1$ 时整组优势为零；当 $\bar r=0.5$ 时信号最大。若调度器优先采中等难度任务，更新效率提高，却会削弱极难任务的覆盖。可以为零成功组提供其他可验证信息，例如正确的中间状态或恢复片段，但不能随意给「看起来努力」的文本奖励。也可以用略强模型生成少量成功轨迹，把任务推入可学习区，再让当前策略继续探索。

长度归一化需要谨慎。token 级损失若对所有 token 平均，长回答每个 token 的单独权重变小；按序列求和，长回答又会产生更大梯度。Agent 的一次决策可能是一行工具调用，也可能是一段长代码，单纯按 token 对齐未必符合动作语义。可以分别报告 token-normalized 与 action-normalized 更新，或给每次模型调用相同总权重，再在调用内部平均。选择哪种方案取决于希望优化「生成每个 token 的质量」还是「每个决策点的质量」。

多任务聚合不能让大任务族淹没小任务族。若代码任务有一万条、GUI 任务一千条，按 episode 微平均会主要反映代码能力；按领域宏平均又让很小的领域获得同等权重。训练分布、评测分布和产品流量可以采用不同权重，但三者要分别公开。OpenForgeClaw、OpenForgeGUI 的分数属于不同环境与判定协议，不能直接平均成一个模糊的「Agent 能力」。

置信区间也应按任务层级计算。同一任务的多次 rollout 共享初态和 verifier，不能当作完全独立样本。可以对任务做 bootstrap，每次抽取任务并保留其全部重复采样，再计算 pass@k、pass^k 和成本指标。比较两个策略时，尽量使用相同任务与种子做配对差异，降低任务难度方差。对于环境错误率较高的系统，还要同时给原始结果与剔除基础设施故障后的条件结果；前者代表用户体验，后者更接近 policy 能力。

2.1. 从一次失败追到可检验假设

失败分析若止于「规划错误」「工具错误」，很难指导下一轮实验。更有效的做法是沿因果链定位最早偏离点。先问模型看到的观察是否充分，再问它生成的意图是否合理、序列化是否正确、Harness 是否按意图执行、环境是否返回真实结果、压缩是否保留结果、verifier 是否正确评价。最早出现异常的环节通常是修复对象，后续错误可能只是连锁反应。

例如 Agent 删除了错误文件。回放显示模型明确写出了正确路径，执行日志却解析成相对路径，问题在 $G_H$ ；若模型看到的目录清单已缺少根目录信息，问题在 $O_H$ ；若观察完整而模型仍选错，才是 policy 决策错误。把三类都标成「工具使用失败」会错误地用 RL 修复解析器 bug，或用工程补丁掩盖模型能力缺口。

每个故障假设都应带一个最小反事实实验。怀疑上下文压缩丢事实，就固定 policy，只替换为完整历史；怀疑工具描述含糊，就保持执行器不变，改写 schema；怀疑 verifier 漏洞，就让人工确认的失败终态单独过验证；怀疑 policy lag，就按版本年龄分桶比较收益和 KL。若反事实没有改变结果，假设就应降级，而非继续堆解释。

长程任务还要观察「失败发生在何时」。早期失败通常与任务理解和初始化有关，中期失败常来自状态追踪、工具选择与局部实现，末期失败更多出现在验证、清理和提交。把 episode 按语义阶段对齐，比按固定 token 区间切分更有意义。若训练后早期错误减少、末期错误增加，整体成功率可能不变，但模型已经把瓶颈推向了收尾阶段验收；下一轮数据应加强自检与交付，而非继续增加开局规划样本。

恢复失败也需要区分「没有发现」「发现但诊断错」「诊断对但没有可逆路径」「有路径却未执行」。第一类需要更可靠的结果检查，第二类需要结构化错误与对照经验，第三类涉及环境设计和 checkpoint，第四类才主要是策略选择。OpenForgeRL 报告 error recovery 仍弱，最有价值的后续工作便是把这个总指标拆开，否则新增数据只能盲目增加失败轨迹。

策略最终能做到什么，受模型、Harness 和环境三者的交集限制：模型不会使用某个工具时，增加权限没有意义；Harness 不暴露某个动作时，再强的模型也无法执行；环境不给可观察反馈时，模型只能猜测结果。可以把可达成功集合写成

\mathcal S_{success}=\mathcal S_\pi\cap\mathcal S_H\cap\mathcal S_E,

其中三项分别表示策略可生成、Harness 可表达与环境允许的轨迹。训练只直接扩大 $\mathcal S_\pi$ 。更换 Harness 会改变 $\mathcal S_H$ ，开放工具或修复环境会改变 $\mathcal S_E$ 。若任务所需轨迹根本不在后两者交集中，继续 RL 只会让策略更熟练地撞墙。

这也是为什么失败样本要保留「不可解」类别。初态缺文件、凭证无权限、目标服务离线、判定条件互相矛盾，都不该作为普通负奖励反复训练。可解性检查需要在任务生成时运行，在 rollout 时仍要复核，因为外部依赖会漂移。不可解比例上升时，训练 loss 可能看似稳定，优势估计却被大量无关零奖励污染。

反过来，Harness 也不能替策略完成太多再把成绩归给模型。若自动规划器生成全部步骤，模型只负责填少量参数；若错误修复器能够重写调用；若 verifier 结果直接泄露缺失条件，成功率会提高，policy 的长程能力却未必增长。一个简单审计方法是记录由模型、Harness 和环境分别产生的状态改变，并做能力剥离：关闭自动修复、限制重试、隐藏额外提示，再观察训练后策略保留多少收益。

部署选择最终取决于端到端系统，而非追求「纯模型」成绩。只要贡献归因清楚，强 Harness 帮模型完成任务完全合理。研究训练规律时则必须知道提升来自哪里，否则换一个控制流后收益会消失。OpenForgeRL 的意义正在于把原本藏在产品外壳里的控制变量搬进实验对象，让部署能力与策略学习可以在同一条轨迹上被审计。

端到端分数只能回答整套系统有没有用，无法判断 Proxy、真实 Harness、任务合成和 RL 各自贡献多少。要拆开这些机制，最小对照可以从同一底座、同一任务池出发，构造四个训练条件：简化 ReAct 采样并在简化循环评测；简化 ReAct 采样后放进真实 Harness 评测；真实 Harness 采样但只做行为克隆；真实 Harness 采样并做 RL。第一、二项之间的下降估计 train-deploy mismatch，第二、四项之间的变化混合了真实轨迹与 RL，第三、四项则更接近奖励优化相对模仿学习的增益。

还需要一个「真实 Harness、随机或冻结 Proxy」对照，确认提升不来自记录层无意改变请求。代理可能重排 header、修改流式响应、改变超时或丢掉 provider 特有字段；这些细节足以影响工具调用。做旁路测试时，让同一组请求分别直连推理服务和经过 Proxy，比较 token、finish reason、工具字段与延迟分布。确定性解码应逐 token 一致，随机采样至少应在相同参数与种子支持下复现，做不到时就报告代理引入的差异。

任务合成消融要固定训练 token，而非只固定任务数。一千条超长 GUI 任务和一千条短 shell 任务消耗不同；若新流水线生成更短的题，相同任务数下能完成更多更新。可以分别固定 episode 数、模型生成 token 和墙钟预算，三种口径回答不同问题：数据覆盖、优化预算与现实成本。若提升只在固定 episode 数下出现，换成固定 token 后消失，收益可能主要来自每条样本更便宜。

判定器消融可准备严格版与宽松版。严格版要求全部隐藏条件，假阳性低但可能拒绝等价解；宽松版覆盖更多实现，假阴性低但留下投机空间。用两版分别训练并交叉评测，能观察策略是否贴着特定规则生长。若在自身 verifier 上提升、换 verifier 后明显下降，说明 reward-specific overfitting 较强。最终还应抽取双方分歧样本人工复核，因为两个自动判定器可能共享盲区。

Harness 泛化要同时测试「新皮肤」和「新机制」。仅重命名工具、改 JSON 字段属于接口扰动；改变上下文压缩、自动重试和多代理调度才是控制流变化。前者测格式适配，后者测策略能否在不同状态转移下工作。若论文只报告工具名变化后的迁移，不能据此推出对全新控制流也有效。反过来，在机制完全不同的 Harness 上下降，也不代表训练失败，它说明共享能力与接口特化的边界在哪里。

2.2. 安全约束也是策略条件

远程沙箱把单次事故限制在容器内，却没有自动消除网络、凭证和供应链风险。Agent 可以下载依赖、访问网页、调用外部 API；训练会把偶然成功的路径提高概率。如果某条成功轨迹碰巧使用了越权凭证或未锁定脚本，正奖励会把危险行为当成有效策略。环境权限必须在采样前按任务最小化，不能指望 reward 在事后把所有越界动作扣回去。

权限门控会进入模型的观察与动作分布。训练时允许直接执行删除，部署时要求用户确认，策略在确认前后的状态转换上没有经验；训练时完全禁止删除，部署时偶尔授权，模型又不会利用新能力。可以把审批写成显式工具结果：请求、拒绝、批准各有稳定结构，并在任务中覆盖三种分支。这样策略学到的是如何在权限约束下推进，而非把审批视为随机报错。

凭证应由环境按 episode 注入短期、限域 token，Proxy 日志默认脱敏。仅用正则替换字符串不够，密钥可能出现在 URL、命令输出、网页或模型复述里；应在字段生成处标注敏感等级，并在存储层控制访问。脱敏后的轨迹用于训练时还要保持语义，例如把真实值统一替换成可调用的占位符，否则模型看到的参数与执行参数不同，又制造一次重建失真。

网络 allowlist 也会改变任务可解性。依赖包下载、登录跳转和第三方资源可能访问多个域名；简单封死会让本可解任务变成基础设施失败，完全开放则允许数据外传。构建阶段应记录参考轨迹实际访问的域、请求方法和内容类别，再生成最小网络策略。训练时出现新域名请求要进入审计队列，而非自动放行或一概惩罚模型。

不可逆动作要有独立预算。发送消息、发布内容、触发付费和修改共享资源，即使在测试账号中也可能产生外部影响。模拟服务能覆盖大多数训练，少量真实端到端测试则放在受控租户并设置总量上限。奖励设计中可以把成功与安全分成硬约束：违反禁止动作的 episode 直接隔离，不参与普通组内归一化，避免同组均值让严重违规只得到一个温和负优势。

论文和公开仓库能够确认系统接口：OpenAI-compatible recording proxy 位于 Harness 与推理服务之间，Orchard 管理隔离环境，轨迹重建后交给 veRL 等训练栈。公开示例可以验证真实 Harness 调用的记录、校验与转换；小规模更新可以观察 reward、KL 和行为变化；复算论文主结果还需要相同任务、checkpoint、预算和评测协议。

这四层需要不同证据。看懂代码不能替代运行记录；跑通一个样例不能证明梯度正确；小规模曲线同向不能替代主表数字。仓库仍在整理且部分训练资源未公开时，合理结论可以停在前两层或第三层，并把缺失的任务、权重、镜像与版本列清楚。这样做没有削弱项目价值，反而避免把「机制可核查」写成「所有结果已完整复现」。

源码与论文口径发生差异时，应优先记录具体 commit 和运行行为。README 可能描述最新接口，论文对应较早版本；脚本默认参数也可能在发布后改变。最可靠的实验身份包含论文版本、仓库 commit、容器 digest、依赖锁、任务 manifest 与模型 checkpoint。若无法得到论文对应 commit，就在当前版本上重新建立基线，避免把新代码跑出的数字直接与旧表横比。

外部服务会让完全复现失效，但仍可追求可审计。保存响应摘要、状态码、时间、区域和服务版本，给动态网页保留允许范围内的快照；无法发布的凭证与数据至少给出生成规则和统计。研究者应能区分模型失败、Harness 失败、服务漂移与验证失败。只要分类清楚，即使某个在线任务几年后无法重跑，原结论的证据链仍可被检查。

对这类系统论文，版本化轨迹样本与 checkpoint 同样关键。它能让读者检查模型实际看见什么、Harness 做了哪些自动动作、环境如何变化、reward 如何绑定。权重说明最终学到了什么，轨迹说明为什么可能学到；二者加上可重建环境，才构成完整证据。若只能保留一小部分轨迹，应按任务、结果、长度、Harness 和失败类别分层抽样，避免公开样本全是最短的成功案例。失败与异常样本虽然不漂亮，却最能暴露系统边界，也能让后来者核查数据清理有没有把困难样本悄悄排除。

这种证据也方便复算。下面把相关系统放到 Harness 真实性、训练栈与 OpenForge RL 的关系中比较。

系统	Harness 真实性	训练栈	与 OpenForge RL
典型 open RL（R2E-Gym 等）	简化 ReAct loop	紧耦合	高 mismatch 风险
Orchard-SWE/GUI/Claw	Orchard Env + 固定 harness	slime fork	同 Env，OpenForge 换真实 harness
LongHorizon-Harness	部署期 MEA 审计	无训练	推理期互补：LH 管状态，OpenForge 管 policy
OpenWebRL	Orchard Env + live browser	在线 RL	GUI 域姊妹工作；OpenForge-GUI 用真实 CU harness
veRL 原生 agent	通常单进程 chat	veRL	OpenForge 把 veRL 接到外部 harness

2.3. 可复用的训练接口

Proxy-as-Adapter：任何无法改源码的 closed/complex harness，都可用「LLM 调用代理 + 轨迹重建」接入 RL——前提是 intercept 面完整。
Remote Sandbox Rollout：训练吞吐 = sandbox 并发 × episode 长度；Env 层必须 hot-path 低延迟（Orchard Env ~0.28s/exec）。
Multi-Harness Training：联合训练多种 harness → 对未见 harness 泛化；部署时可换更强 harness 获得 free lunch（Orchard-Claw +9.3 pass³ on ZeroClaw）。
RL 增益分解：format / verification / tool coverage 可 RL 学；error recovery 需另建数据或架构——指导 reward 与 curriculum 设计。
Train where you deploy：long-horizon agent 训练的默认原则应是「policy 与 harness 共演化」，而非「先训裸模型再贴 harness」。
Trajectory reconstruction contract：Proxy 与 trainer 之间应版本化 (message_list, tool_call, logits_mask) schema——harness 升级时重建逻辑可回归测试，避免 silent corruption。
Rollout–train decoupling SLA：Orchestrator 队列深度、sandbox 启动 P99、Proxy 超时策略应作为训练 infra 的一等监控项；否则 GPU 空转会吞噬 RL 预算。

Orchard README News 于 2026 年 7 月宣布 OpenForge RL，独立仓库随后公开了 rollout engine、环境实现、veRL 训练示例与推理脚本；Kubernetes sandbox 编排仍由 Orchard Env 提供。

产品落地对照见 ../../../essays/oasis-improvements-2026-08-harness-wave.md。