Terminal agent 的 RL 看起来像一道规模题：合成更多任务，让模型在更多 Docker 环境里练习。RIVER 先检查了更基础的一件事：这些环境给出的 reward 到底对不对。它发现 TMax-15K 中只有 35.8% 被 GPT-5.4 判为 CLEAN；有的 verifier 会奖励直接读取泄露答案，有的会因为函数名不同而拒绝功能完全正确的实现。论文据此把环境过滤、oracle pass@2 和 turn-level repetition penalty 组合成一套训练 recipe。
Q1. 为什么 terminal-agent RL 不能只靠扩大环境数量？
Policy 会沿着 verifier 的实际判定边界学习，即使这条边界偏离了 instruction。 对数学题，错误答案通常只是一次负样本；对长程 terminal task，一个弱 checker 会让整条错误策略得到正向强化。Agent 如果发现复制 /app/ground_truth.txt 最容易拿到 1 分，RL 就会提高这种 shortcut 的概率。
现有路线已经覆盖了更多技能和任务类型。Endless-Terminals 展示了大规模合成环境上的 RL，TMax 又扩展到 14,399 个跨领域任务。RIVER 检查这些环境的 reward integrity：instruction 说的目标、Docker 实际提供的状态和 verifier 检查的条件，是否指向同一件事。
论文给出一个机制解释。Pre-training 与 SFT 主要提供 atomic skills，例如写 shell pipeline、调用编译器、理解某个领域操作；RL 更可能改变跨多个 turn 的 behavior，例如是否先检查环境、遇错后换方案、结束前验证，以及是否反复执行近似命令。它称之为 Agentic Compositional Generalization。
这套解释有两个可检验预测。第一，SFT 数据的 skill coverage 应该影响较弱模型的起点。第二，RL 环境的 verifier 会决定哪些跨 turn 模式被强化。RIVER 的方法和实验都围绕这两个预测展开。
Q2. 它与 Endless-Terminals、TMax 和“更强测试”路线的边界在哪里？
Endless-Terminals 与 TMax 主要扩大训练覆盖，RIVER 把研究对象换成 reward integrity，并尝试解释 RL 到底改变了 trajectory 的哪一层。 它不是新的通用 terminal benchmark，也没有提出新的 task generator。上游环境仍来自 TMax。
| 路线 | 主要扩展对象 | Reward / judge | 与 RIVER 的边界 |
|---|---|---|---|
| Endless-Terminals | 大规模可执行 terminal environments | 每个环境的 outcome verifier | 证明 synthetic RL 可以提升 terminal agent；RIVER 进一步检查 verifier 是否给对信号。 |
| TMax | 14,399 个任务的 domain 与 skill coverage | 随环境发布的 task-specific verifier | RIVER 直接使用它作为 source pool，只留下约 3.5K 个任务。 |
| Stronger-tests / verifier-generation | 为 coding task 生成更强 unit tests | 提高 output correctness 的判别力 | RIVER 同时检查 instruction、环境与 verifier 的一致性，并关注这些信号塑造的 multi-turn behavior。 |
| Compositional generalization | 单轮 reasoning 中的 primitive 与 composition | 通常是最终答案 reward | 本文把假设扩展到有 command、observation 和 recovery 的多轮 agent trajectory。 |
RIVER 把方法和机制解释绑在一起：如果 RL 主要塑造可复用 behavior，那么 verifier 的错误会跨 domain 扩散；一个简单但可靠的重复检测规则，也可能在许多任务上同时生效。
Q3. 14,399 个环境怎样变成 3.5K，judge 又怎样产生一条 reward？
3.1 数据来源、筛选与责任边界
RIVER 从 TMax 的 14,399 个训练环境开始。每个环境的核心是 instruction、Docker / bundled data 与 task-specific verifier。论文没有报告人工 annotator 逐条创建 CLEAN 标签，而是让 GPT-5.4 同时读取这三类材料，围绕“一个认真遵守 instruction 的 Agent 能不能理解任务并通过 verifier”给出一个主 verdict。
八类 verdict 是 CLEAN、VERIFIER-TOO-WEAK、INSTR-VERIFIER-MISMATCH、INSTR-ENV-MISMATCH、ANSWER-LEAK、INSTR-AMBIGUOUS、TASK-TRIVIAL 和 OTHER。一个任务可能同时有多个缺陷，但 audit 强制选择一个主类别。GPT-5.4 判 CLEAN 后，作者再用 GPT-5.4 + Terminus-2 对环境做 oracle pass@2，移除两次都失败的任务。后一步主要排除过难任务和训练 infrastructure 不兼容，而不是再次判断 verifier 是否正确。
- 1 · PACKAGETMax 作者提供 instruction、container 与 verifier。
- 2 · AUDITGPT-5.4 静态读三类材料，给八类 verdict。
- 3 · ORACLEGPT-5.4 + Terminus-2 各跑两次，去掉 pass@2=0。
- 4 · ROLLOUTPolicy 在留下的 container 中按 harness 交互。
- 5 · CHECK原任务 verifier 全部通过才得到 outcome reward 1。
- 6 · SHAPE重复 turn 的 response-token advantage 额外扣分。
3.2 Agent 能看见什么，什么应当隐藏？
Policy 能看见 instruction、command history、terminal observations，以及容器权限允许读取的文件。GPT audit verdict、oracle 两次 rollout 和其他训练样本不在它的 prompt 中。Task verifier 在 rollout 后运行，作为 outcome reward 的来源。
理想情况下，ground truth、reference implementation 和 hidden tests 应当只对 verifier 可见。TMax 的部分任务把它们直接放进 /app，于是“应当隐藏”与“实际隐藏”发生分离。RIVER 的 ANSWER-LEAK 标签就是为这种问题准备的。论文没有给出统一的 sandbox access-control 规范，也没有发布 3.5K 过滤结果供本文逐条核查；这里能确认的是论文和项目页公开的 audit 结果与 case files。
3.3 一条 PASS 和一条 FAIL 为什么都判错了？
task_003722 要从 broadcast.mp4 中 OCR 新闻 ticker。Agent 先发现并读取 /app/ground_truth.txt，随后还是尝试了正常抽帧与 OCR，但自己的结果与 reference 的 similarity 只有 0.368，低于 0.85 门槛。第 7 个 turn 它用泄露 reference 覆盖输出，第 8 个 turn 达到 1.0，于是 reward=1。Similarity 的计算本身没有问题，问题出在 reference 被放进了 Agent 可读区域。
task_006064 要求 Rust 程序保留 a-z 与空格。Agent 使用 is_ascii_alphabetic()，生成的 top tokens 与 covariance matrix 都通过 functional tests。第三个 test 却在源码里 grep is_alphabetic 字面量。合法 API 名不含这段连续字符串，整题因此 reward=0。这个 FAIL 测到的是 implementation spelling，不是 instruction 规定的行为。
3.4 Turn-level repetition penalty 到底怎样算？
下面是按论文公式写的最小重建示例，只用于解释接口，不是官方训练代码。论文作者截至 2026-09-29 没有公开 RIVER training repo、River-8B checkpoint 或 RIVER-TMax-3.5K 下载。
# Article reconstruction from Eq. (1), not official code.
def repeat_shaping(turns, delta=0.05, cap=0.15):
"""Return per-turn penalties after GRPO reward normalization."""
penalties = [0.0] * len(turns)
spent = 0.0
for i, current in enumerate(turns):
repeated = any(
jaccard(current.command, old.command) > 0.8
and jaccard(current.observation, old.observation) > 0.8
for old in turns[:i]
)
if repeated and spent < cap:
penalty = min(delta, cap - spent)
penalties[i] = -penalty
spent += penalty
return penalties这个 rule 要求 command 和 observation 同时近似，避免把“同一检查命令得到新信息”全部当作 loop。它改变相应 turn 的 token advantage，不改最终 PASS / FAIL。论文的消融还试过 verify-before-done reward。那条 reward 确实增加了结束前验证行为，却没有继续提高 benchmark 表现，所以最终 recipe 只保留 repetition penalty。
3.5 Audit 本身可靠吗？
作者让 Claude Opus 4.8 在看不到 GPT 标签的情况下复判 120 个环境，每个 GPT verdict 类别抽 15 个。八分类完全一致只有 22.5%，因为同一坏环境常有多个缺陷；合并成 CLEAN / defective 后，一致 100/120，即 83.3%。更有用的是条件结果：GPT 判 defective 的 105 个中，Claude 也判 defective 的有 94 个，89.5%；GPT 判 CLEAN 的 15 个中，Claude 仍判 CLEAN 的只有 6 个，40%。所以这套 audit 更适合保守排除明显坏环境，不适合把 CLEAN 当成经过充分人工认证。
Q4. 实验结果支持哪些结论？
4.1 River-8B 的主结果
River-8B 从 Qwen3-8B 出发，先用约 78K OpenThoughts trajectories 做 SFT，再用 RIVER-TMax-3.5K、EndlessAgent harness 和 GRPO 做 RL。四个 benchmark 共 589 tasks；每个 checkpoint 运行 3 seeds，单题最多 64 action turns 或 600 秒。OpenThoughts-TBLite 给连续分数，其余三个只有全部 checker 通过才记 1。主表的 Average 是四个 benchmark 的不加权平均。
最精确的主结论是：River-8B 在论文重测的 open-source RL-trained 8B agents 中，四项与平均分均最高。 不能把它直接扩成“所有 terminal agents 的 SOTA”，因为闭源 Claude / Codex 不在这张表里，而且 baseline 使用各自原生 harness。作者尽量统一 serving 与 budget，但模型、SFT 数据、RL 环境和 harness 仍有多处同时变化。
4.2 为什么 broad-skill SFT 也在 recipe 里？
作者为 Qwen3-8B 构造了三个 SFT 起点：以 nl2bash 和 InferredBugs 为主的 Narrow-SFT，约 13.6K trajectories；从更广来源组成的 Diverse-SFT，约 78K；以及从 Diverse-SFT 随机抽到同样 13.6K 的 Diverse-DS-SFT。Narrow-SFT 与 Diverse-DS-SFT 在 SFT 后的平均分接近，继续做同一套 RL 后却拉开明显差距。这个 size-matched 对照部分排除了数据量的影响，剩下的差别主要来自 atomic-skill coverage。
论文还报告了一次失败的早期实验。作者在未经过 RIVER 过滤的 TermiGen 环境上使用 partial reward，训练 reward 和 in-distribution score 都上升，外部四项平均分反而下降，同时 rollout 越来越早结束。换成 Diverse-SFT 起点后，同一设置的 reward hacking 有所减轻。作者因此把 broad-skill SFT 放在较弱 base model 的 RL 之前；它不是 RIVER 的环境过滤核心，但会影响 policy 有没有能力通过正常路径完成训练任务。
4.3 少于 30% 的环境，为什么会出现 +106%？
作者进一步沿用 TMax 的 Qwen3.5-2B/4B/9B、Qwen3.6-27B、Vanillux2 harness 与 DPPO 设置，只把完整 TMax 训练集换成 RIVER 过滤后的约 3.5K 环境。论文按每个模型的 RL score − base score 先算 RL gain，再比较两套训练集的 gain。
结果是 Terminal-Bench-Lite 上的平均 RL gain 相对 TMax 增大 106%，Terminal-Bench-v2.1 上增大 30%。这说明过滤后的 reward signal 在这些配置里更有效率。它不表示模型得分增加 106 个百分点，也不表示每个 model size 都提高相同比例。
4.4 Behavior 是否真的跨 domain 转移？
作者从 RIVER-TMax-3.5K 中另留约 300 个任务做 controlled evaluation，再让 RL 只看 2、4、6 或 8 个 domain。两域训练只包含 Debug 和 Systems，其他六域仍然出现提升。轨迹里的 inspection、error recovery、repetition 等 behavior 变化也同时出现在未训练域。
这组结果支持“跨 domain 的 behavior transfer”。边界同样要写清：domain 来自作者对 TMax task skill 的分类，held-out tasks 仍属于同一个合成环境家族；它不是独立收集的真实用户分布。
Q5. 对 Claude Code、Codex 这类完整 harness，哪些结论最值得复用？
第一，harness 里的 evaluator 是训练系统的一部分。 只要 checker 错了，更多 rollout 会更稳定地优化错误目标。构建 terminal-agent 训练集时，应当把 instruction、sandbox、可见文件、hidden reference、test protocol 和 reward aggregation 当成一个整体审计，而不是只数任务类别。
第二，judge 要同时检查 false positive 与 false negative。 前者让 shortcut 得分，后者让正确方案受罚。只做 pass@k 难度过滤会漏掉两类问题：一个泄露答案的任务可能很容易 pass，一个错误 hard-coded reference 可能让所有强模型都失败。
第三，behavior feature 可以成为轻量诊断层。 Command repetition、inspection、error recovery 和 verify-before-done 都可以从真实 terminal traces 里确定性提取。它们适合做训练监控和 failure analysis；只有经过 intervention 证明会提高结果的 feature，才适合进入 advantage shaping。本文中 verify reward 就是一个反例：相关但没有带来额外性能收益。
对下一篇完整 harness 论文，我会优先补三个实验：在 Claude Code、Codex CLI 与开源 runner 上使用同一批 sealed tasks；让独立人工与多个 model judges 复核 reward disagreement；把 task family、container provenance 和 checker author 全部隔离到未见 split。这样才能判断学到的是可迁移 behavior，还是某个上游 generator / harness 的惯例。
Q6. 最后怎样评价这篇论文？
这篇论文最强的部分，是用真实 false-positive / false-negative rollout 说明 reward integrity 会怎样改变 Agent 行为，再用跨 model、size、harness 和 domain 的实验检查同一 recipe。 它还认真报告了一个负结果：verify-before-done 与成功相关，但直接奖励它没有继续提高性能。
需要保留的限制也很具体：
6da2749。没有训练代码、3.5K 清单、checkpoint 或 task-level logs。我的最终判断是：RIVER 要求先审计 reward，再决定是否扩大训练环境。 它的 3.5K 环境未公开，限制了完全复核；但两类真实 verifier failure、严格区分的筛选 actor，以及 behavior reward 的正负消融，已经给 terminal-agent RL 提供了一套很实用的实验框架。
来源与授权说明：论文为 arXiv non-exclusive distribution license，项目仓库未声明 license。本文没有复用原图像素，所有图均根据 arXiv:2608.22631v3 的 Figures 1-11、Tables 1-9、Algorithm 1 和公开 case 数据重绘。项目页与仓库于 2026-09-29 核查，仓库 revision 为 6da2749578df2779b8a7e134ccb8d063d84693aa。
留言