走完之后：下一道门在哪
你已经能在单卡上完整跑一轮 RL。接下来是 agentic RL、多轮工具调用、更大的模型——以及它们各自要求什么。
学完这节你能做到
- 知道 agentic RL 与单轮 RLVR 在工程上的差别
- 列出继续深入需要补的三块知识
- 给自己排一个下一步的具体项目
你现在会什么
走完这条路径，你手上有这些东西：
□ 一套已知能跑的 5090 环境，和它的实测吞吐数字
□ 一份约两百行、每行都看得懂的 GRPO 训练脚本
□ 一个自己训练过的模型：GSM8K 从 20.9% 到 63.2%
□ 八条曲线的判读能力，以及五种失效的诊断与处置
□ 一套评测流水线，知道自己的实验分辨率是 4 个百分点
□ 读得懂 slime / Miles 那种四十个参数的启动脚本
第四和第五项最值钱。跑通一次 RL 不难，难的是训练不对时知道该看哪、该改什么。 那是只能靠亲手跑坏几次才能长出来的东西。
接下来说清三个方向，以及它们各自要求什么。
方向一：agentic RL
单轮问答之后，最自然的下一步是多轮 + 工具调用。
变化在哪：
| 单轮 RLVR（你做的） | agentic RL | |
|---|---|---|
| 一条轨迹 | 一次生成 | 多轮交互，中间穿插工具调用 |
| reward | 结尾一次 | 结尾一次，中间更稀疏 |
| 环境 | 无 | 需要沙箱 / 检索 / 浏览器 |
| 长度 | 几百 token | 几千到几万 token |
| 失败模式 | 五种 | 多了「工具调用格式错」「陷入循环」「超时」 |
单轮 RL 的循环是同步的、确定的：采样 → 打分 → 更新。
agentic 的一条轨迹可能是：生成 → 调工具 → 等返回（几秒到几十秒）→ 继续生成 → 再调 → …
于是你要处理：异步、超时、重试、并发限制、沙箱隔离、工具返回值的截断。这些和 RL 算法一点关系都没有，但它们会占掉你 80% 的时间。
这正是框架真正开始有价值的地方。 slime 把这一整块收敛成「往 Data Buffer 里塞数据」；Miles 直接对接了 Harbor、HUD、NeMo Gym、OpenEnv、Verifiers 这些环境层，沙箱支持 AgentENV、Daytona、E2B、Modal。
自己造这一层不值得。agentic 是「该上框架」的明确信号。
单卡上能做的最小 agentic 实验：给模型一个计算器工具，让它学会在需要时调用。
任务：稍复杂的算术题（模型自己算容易出错）
工具：一个 calculate(expr) 函数
reward：答案正确 + 正确使用了工具的格式
轨迹：生成 → 遇到 <tool>...</tool> 就暂停 → 执行 → 把结果拼回上下文 → 继续
这个实验不需要沙箱（工具是本地纯函数），单卡跑得动，但已经包含了多轮的核心结构：轨迹中断、外部结果注入、继续生成。做完它，你对 agentic RL 的理解会比读十篇博客都深。
方向二：on-policy distillation
一条比 RL 便宜得多的路线，值得知道它存在。
思路：不用 reward，用一个更强的教师模型的输出分布当学习目标。
RL: 学生生成 → 打分 → 按分数调整概率
on-policy 蒸馏: 学生生成 → 教师对同一序列给出概率分布 → 让学生逼近它
关键区别在「on-policy」：序列仍然是学生自己采样的（所以覆盖的是学生真实会犯的错），但学习信号是教师的完整分布，而不是一个标量 reward。
| RL (GRPO) | on-policy 蒸馏 | |
|---|---|---|
| 需要 reward 吗 | ✅ 必须 | ❌ 不需要 |
| 信号密度 | 一个标量 / 序列 | 完整分布 / 每个 token |
| 收敛速度 | 慢 | 快 |
| 需要什么 | 可验证的任务 | 一个更强的教师模型 |
| 能超过教师吗 | ✅ 理论上可以 | ❌ 上限是教师 |
判断很简单：有没有一个明显比你的模型强、而且你能跑得起的教师？
- 有 → 先蒸馏。信号密度高，收敛快得多，而且不用设计 reward
- 没有（或者你就是想突破现有模型的水平）→ RL
实践中常见的组合是先蒸馏后 RL：蒸馏快速把学生拉到教师水平，再用 RL 突破教师的上限。
slime 和 Miles 都有 on-policy distillation 的专门页面，说明这在工业界是标准手段之一，不是替补方案。
方向三：更大的模型
32GB 的天花板，按 L0 显存账本的结论：
| 模型 | 方式 | 单卡 32GB |
|---|---|---|
| 0.6B | 全参 | ✅ 舒服 |
| 1.7B | LoRA r16 | ✅ |
| 4B | LoRA r16 | ⚠️ 要精打细算 |
| 8B | QLoRA 4bit | ⚠️ 能跑不好跑（G 压到 4，单步 3 分钟） |
| 14B+ | — | ❌ 租卡 |
| 任何 MoE | — | ❌ 租卡 |
换更大的模型是最容易想到、也最容易白花钱的一步。
在 0.6B 上，你一周能做二十次实验；在 8B QLoRA 上，一次十小时，一周能做十次都算勤奋。而你要学的东西（reward 设计、曲线判读、失效诊断）在 0.6B 上全都能学到。
值得换大模型的理由只有一个：你的任务本身在小模型上做不了（比如需要更强的基础能力才能产生正样本，采样出来 reward 全是 0）。
判断方法就是 L0 那个：测 pass@8。 如果 0.6B 的 pass@8 也接近 0，说明它根本不会做，RL 无从下手——这时才该换模型（或者先 SFT）。
要租卡，按 L3「从 1 卡到 8 卡」那条流程：20 步冒烟（几块钱）→ 单卡 200 步 → 才开多卡。
值得读的
读的顺序按「对你现在最有用」排，不是按发表时间。
三篇论文
| 论文 | 读它解决什么问题 |
|---|---|
| DeepSeekMath | GRPO 的原始出处。你已经实现过了，回头读会发现每个符号都认识 |
| DeepSeek-R1 | 纯 RL 能激发推理能力的证据。重点看它没做什么（没用过程奖励、没用 MCTS） |
| PPO | clip 机制的来源。只需要读到信任区间那一节 |
补充一个非论文的：OpenAI Spinning Up 的策略梯度那几页，是对 L1 数学推导最好的交叉验证。
两个仓库
| 仓库 | 怎么读 |
|---|---|
| slime | 先读 docs/ 里的设计文档，再看 Data Buffer 和权重同步那两块实现。不要试图从头读到尾 |
| Miles | 看 fully-async 调度和 P2P weight transfer。它有 llms.txt 索引，适合按主题跳读 |
不要通读。带着一个具体问题去查：
「它的优势是在哪算的？」 → 搜 advantage
「权重同步具体做了什么？」 → 搜 update_weights / sync
「退化组是怎么过滤的？」 → 搜 filter / over_sampling
「clip 的实现和我的一样吗？」 → 搜 clip / ratio
每次带一个问题去读，读完对上自己的实现。这样读一个下午的收获，比通读一周多。
你的两百行脚本是最好的索引 —— 你知道每个功能应该长什么样，所以能一眼认出框架里对应的那段。
给自己排下一个项目
最后一件事，也是最重要的一件：从一个你真正在意的任务开始。
跟着教程做完 GSM8K，你会的是「跟着教程做 GSM8K」。要把它变成能力，得在一个没人给你标准答案的任务上再走一遍。
选题的三条标准：
□ 1. 有可自动验证的成功标准
—— 否则你要先解决 reward 问题，难度翻倍
□ 2. 0.6B 或 1.7B 上 pass@8 不为 0
—— 模型至少偶尔能做对，RL 才有东西可强化
□ 3. 你自己在意结果
—— 这决定你会不会在第三次 OOM 之后放弃
几个符合这三条的方向：
| 任务 | 怎么验证 | 数据从哪来 |
|---|---|---|
| 把自然语言转成你项目的配置格式 | schema 校验 + 关键字段比对 | 自己的项目里现成的配置文件 |
| 从日志里提取结构化字段 | 与正则基线比对 | 自己的服务日志 |
| 生成能通过测试的小函数 | 跑单元测试 | 从自己的代码库里挖 |
| 写符合规范的 commit message | 格式校验 + 关键信息覆盖 | 自己仓库的 git 历史 |
| 简单 SQL 生成 | 执行后比对结果集 | 自己的数据库 |
RL 项目会在很多地方卡住：环境装不上、reward 被钻空子、训练不收敛、显存不够。
如果你对结果无所谓，会在第二个坑那里停下来。如果你真的想要那个东西，你会把坑一个个填掉——而填坑的过程就是学习的过程。
选一个你会因为「做出来了」而高兴的任务。这比选一个「看起来更前沿」的任务重要得多。
最后
这条路径的核心主张其实只有一句：
RL 的门槛比大多数人以为的低，但它的调试成本比大多数人以为的高。
前半句是好消息：一张消费级显卡、一百块钱卡时、两周业余时间，你就能完整走一遍 LLM 强化学习，不需要集群也不需要论文。
后半句是这条路径真正想教的东西：reward 会被钻空子、熵会崩塌、权重会忘了同步、曲线会骗你。这些不是「学完基础之后的进阶话题」，它们是第一次跑训练就会撞上的东西。
所以这里花了大量篇幅讲怎么读曲线、怎么排除、怎么保持实验可归因——因为那才是把「跑通一次」变成「会用 RL」的分界线。
什么情况下该选 on-policy distillation 而不是 RL？
为什么说 agentic RL 是「该上框架」的明确信号？
想判断「该不该换更大的模型」，最直接的检查是什么？
给自己选下一个 RL 项目时，三条标准里最容易被忽略的是哪条，为什么它重要？
这节课的落点
- 最值钱的产出不是那个模型，是失效诊断能力和实验纪律
- agentic RL：算法不变，但异步/超时/沙箱这层工程量占 80% 时间——该上框架了
- 单卡能做的最小 agentic 实验：给模型一个本地计算器工具，练「轨迹中断 + 结果注入」
- on-policy 蒸馏：不用 reward、信号密度高、收敛快，上限是教师；常见组合是先蒸馏后 RL
- 换大模型的唯一正当理由：当前模型 pass@8 接近 0（根本不会做）
- 读框架源码带着具体问题跳读，你的两百行脚本就是最好的索引
- 选下一个项目的三条：可自动验证、pass@8 不为 0、你自己在意结果
- 核心主张：RL 的门槛比想的低，调试成本比想的高——后者才是这条路径真正教的东西