智能体强化学习（Agentic RL）

所属：01-fundamentals / 02-post-training
面试权重：★★★
来源：4 篇（2026-10-13 采集；原始摘录见 02-interview/questions/xhs-reports.md §4.8 与 §4.11）
① 小红书《为什么 Agentic RL 中 GRPO 反而不好用？》（483 赞，13 张图）—— 观念层
② 小红书《腾讯大模型算法面经》一二面（27 题，约半数在 RL）
③ 小红书《Agent RL 训练细节踩完坑之后的一些经验（上）》（沫波，1474 赞，6 张图）—— 工程层，B 级（一线复盘，无外部出处）
④ ✅ 可核实出处：《真实终端环境中的 Agentic RL 大规模训练实践》（阿里巴巴未来生活实验室，919 赞，13 张图）—— 对应 arXiv 2512.24873、开源模型 ROME、Notion blog《The Bitter Lesson Behind Building Agentic RL in Terminal Environments》

⚠️ 本文中「阿里报告」标注的内容来自 ④（有出处，可用、可查）；其余来自 ①②③，未做一手考证。凡 ③ 给出的具体数字（奖励权重、G 的取值范围、20k 长度阈值等）都是单篇复盘的经验值，不是普适结论。
相关项目：Own — Race Bot / HKJC（Verl 框架，Qwen-32B 的 SFT + GRPO 两阶段）→ 见 02-interview/projects/race-bot-hkjc.md
⚠️ 边界必须先说清：HKJC 那个项目是单轮 RLVR（一个 prompt 采样多条 SQL，奖励由「能否执行 / 结果是否正确」判定）—— 那正是 GRPO 好用的场景。本文件讲的是多轮工具调用的 RL，你的项目不覆盖它。这个边界自己先讲，比被面试官问出来强。

一句话#

Agentic RL 把 RL 的训练单元从「一条回答」换成「一条轨迹」：模型思考 → 调工具 → 拿环境反馈 → 再决策，直到任务结束才拿到一个延迟的终局奖励。这一换，GRPO 赖以成立的四条前提同时失效。

为什么重要（面试角度）#

这是仓库结构上的一道缝：02-post-training/grpo.md 讲 GRPO 本身，04-agent-architecture/ 讲 Agent 循环，而面试把两者合起来问。分块写会让每一块各自完整，交叉问题却无处可查。

面试里它长这样：

• 腾讯大模型算法面经（一面）：「多轮工具调用的 RL loss 如何设计？」「loss 是每轮模型调用后计算，还是整个 rollout 完成后计算？」「从 loss 角度看，GRPO 的设计有什么问题？」
• （二面）：「一条完整 rollout 的最终奖励如何获得？」「Agentic RL 训练中，工具返回等待与 batch 组织做过哪些优化？」
• 最高频的开场追问：「Agentic RL 里可以继续用 GRPO，因为不训练 critic、省显存。」→ 面试官接一句：「最终 reward 是 1，前面二三十次 tool call，到底该奖励哪一步？」

你的处境：有一手 GRPO 经验（HKJC），这既是优势也是陷阱 —— 面试官顺口问一句「那多轮呢」，答不上来就会从「做过」掉到「只会背公式」。这一篇的作用就是守住这条边界。

核心内容#

1. 根源：训练单元从 contextual bandit 变成 POMDP#

所有问题都从这一格派生出来。 单轮时「整条 response 用一个 advantage」是合理的近似；多轮时它就成了最粗的那把刀。

2. 先问「该不该上 RL」，再看 GRPO 的四条前提#

面试里如果被问「Agentic RL 怎么做」，先反问一句「这个任务真的需要 RL 吗」，比直接讲算法高一个段位。原话（③）：「大部分团队其实不需要上 RL……所以第一个问题不是『怎么做 RL』，而是『我是不是真的需要 RL』。」

SFT 在 Agent 场景的天花板（三条，比「SFT 是模仿学习」具体得多）：

该上 RL 的四条判据（满足至少两个才值得认真考虑）：

1. 任务结果能自动判 —— 「代码跑不跑得过测试、SQL 查出来的结果对不对、网页上的操作有没有到达目标状态，这些都是天然的 reward。如果你的任务结果只能靠人来评判，那 RL 的训练成本会高到不现实。这个条件其实是最关键的，没有可靠的自动 reward，后面一切都是空中楼阁。」
2. SFT 模型已经「会做但做不好」 —— 偶尔成功、成功率大概 10%~40%。说明模型已有基本能力，RL 可以在此基础上优化上去；如果 SFT 模型完全不会做（成功率接近 0），「巧妇难为无米之炊」。
3. 任务存在多种解法 —— SFT 只能学到标注员选择的那一种路径，RL 可以让模型自己探索，有时还能找到比标注数据更好的策略。
4. 错误恢复是刚需 —— RL 训练过程中模型会见到大量失败状态，自然就学会了怎么从错误中恢复。

别上 RL 的三种情况（能主动说出这三条，比会讲算法更显判断力）：

• SFT 已经能到 90%+ 成功率 —— RL 能带来的提升很有限，不值得为那几个点搞那么复杂；
• 没有自动评测手段 —— reward 全靠人打分，训练成本直接爆炸，而且人打的 reward 噪声很大，训练效果也不好保证；
• 基座模型太弱 —— 连基本的指令跟随和格式输出都搞不定，「这时候老老实实先把 SFT 做好，基础没打好就上 RL 纯粹是浪费算力」。

3. GRPO 成立的四条前提#

GRPO 的机制（见 grpo.md）：同一 prompt 采样 $G$ 条回答，用组内奖励的均值与标准差算相对优势，从而删掉价值网络。它能成立，依赖四条：

1. 短 horizon —— 一条 response 就是一次决策
2. 强 verifier —— 最终答案可被规则稳定判对错
3. 组内 reward 有方差 —— 否则 advantage 全零
4. 一条 response 可作为主要优化单元

4. Agentic RL 把四条前提同时打破#

4.1 信用分配太粗（credit assignment）#

Vanilla GRPO 让整条 trajectory 共享同一个 advantage。后果是两个方向都错：

• 答对时：一个搜索 Agent 最终答对了，中间既有高质量 query，也有无效搜索、重复调用和错误判断 —— 它们会一起受到鼓励。
• 答错时：一条轨迹可能前面二十步都做对了，最后因格式错误或一次工具超时而失败 —— 前面那些有效动作一起被惩罚。

一句话概括：GRPO 知道整条轨迹好不好，却不知道到底是哪一步做对了。

4.2 组内 advantage 经常归零#

Agentic 任务通常 horizon 更长、最终 reward 又常常只有 0 和 1：

• 任务太难 → 同组轨迹全部失败
• 任务太简单 → 同组轨迹全部成功

两种情况下组内 reward 的方差都接近零，advantage 随之消失。结果是「采样了几条昂贵的长轨迹，最后却没有多少有效梯度」。

这和 grpo.md 里那条结构性缺陷是同一件事，但在 Agentic 场景下发生频率高得多 —— 因为「全对/全错」在长horizon、稀疏奖励下是常态。

4.3 组内比较掺入了环境噪声#

这是最容易被忽略的一条。不同轨迹在第一次调用工具之后，看到的状态就可能不同 —— 搜索结果、网页内容、API 返回值、执行报错和超时都有随机性。

于是：两条轨迹的 reward 不同，未必来自模型策略的差异，也可能来自环境反馈的差异。此时组均值只能当初始任务的 baseline，很难回答「在某个中间状态下，当前 action 到底比其他 action 好多少」。

换句话说：GRPO 的 baseline 假设「同一个 prompt 下的组内比较是公平的」。单轮任务里这个假设成立（大家看到的是同一个 prompt），多轮任务里它从第一步工具返回起就不成立了。

4.4 rollout 成本与 policy lag#

• 单轮 GRPO 采样 8 条回答，成本通常还能接受。但每条 trajectory 包含几十次工具调用，再乘一个 group size，rollout 很快成为训练瓶颈：省掉 critic 带来的显存优势，可能已经覆盖不了环境交互的成本。
• 为提高吞吐，工程上往往采用异步 rollout。等轨迹真正进入训练时，当前 policy 已经更新了很多次，数据越来越 off-policy。

5. 最隐蔽的一层：优化粒度与决策粒度没对上#

这一层面试官最爱追，而且很少有人答得出来。

异步 rollout 之后，GRPO 仍在 token 级别计算 ratio 和 clipping，而环境执行的单位是一整次 tool call。两者粒度不一致：

GRPO 的优化单元：token        ← ratio、clipping 都在这一层
环境的决策单元：  tool call    ← 一整次调用才产生一个 observation

后果：训练容易出现高方差、过度 clipping，甚至出现reward 还在上涨、正确轨迹的 likelihood 却开始下降；再往后是 entropy 上升、gradient norm 突变，最后整段训练崩掉。

注意：这解释了一个反直觉现象 —— 训练崩之前，reward 往往是好看的。所以只看 reward 曲线会误判。

这条有正式解法，而且有出处：阿里那篇报告（arXiv 2512.24873）从同一观察出发 —— 「多轮 agentic 任务中，大多数 token 并不会改变环境状态；一条轨迹中可能包含多个决策节点；每一次交互步骤都对应一个具体的决策或状态转移」—— 提出在 interaction chunk（交互片段） 层面建模：chunk = 从一次环境交互到下一次环境交互之间的一段连续片段，通常以一次工具调用结束，构成一个完整的功能单元。算法叫 IPA（Interaction-Perceptive Agentic Policy Optimization），三条做法：

• 在 chunk 层级而非 token 层级计算回报与重要性采样；
• 训推偏差过大时，对整个 chunk 做 masking，而不是逐 token masking —— 「从而更契合以结果为导向的粗粒度奖励结构」；
• 引入 chunk 初始化重采样，以及 imitation learning + RL 的混合训练，扩大模型在困难任务上的有效学习范围。

细节里有两个值得记的点：chunk 级折扣回报 $G_k=\gamma^{\Delta(K,k)}R_{final}$ 的理由是「token 级折扣在长序列上会指数衰减到几乎为 0」；以及训推不一致——「即便参数一致，rollout 引擎（SGLang）与训练引擎（Megatron）之间也会存在 logprob 的系统性偏差」，所以要把几何平均比值超过阈值的 chunk 整体 mask 掉。原文也坦承这是临时保障措施而非根本解决方案。

面试里的用法：被问「GRPO 在 agent 场景的粒度问题怎么办」，加分路径是「有一类工作把优化单元从 token 提到交互片段，因为大多数 token 并不改变环境状态，所以按 chunk 算回报、并对整个 chunk 做 masking 更契合轨迹级奖励」→ 然后点名 IPA / Chunked MDP（阿里）。这比继续说「GiGPO / ATPO」（见 §6.3 的诚实边界）扎实，因为它有出处。

6. 工程上怎么改，面试里怎么答#

按「先诊断、再动手」的顺序讲，比直接背算法名强得多。

6.1 第一步：先查 GRPO 还有没有学习信号#

• 看每组 reward 的分布
• 统计 zero-advantage group 的比例（全对或全错的组占多少）

如果大量组内样本全对或全错 → 可以做 dynamic sampling（动态采样），优先采样处于能力边界附近的任务。 ⚠️ 但这只解决「没有组内差异」，解决不了多轮 credit assignment —— 这一句是区分「读过」和「想过」的地方。

6.2 第二步：检查 reward 能不能落到 turn 上#

把终局奖励拆出中间反馈，可行的信号包括：

• 工具调用是否合法
• 是否到达了新的环境状态（没到达说明这步白做）
• 单元测试通过了多少
• 是否完成了某个子目标

原则两条：

• 能用执行结果验证的，就尽量少用纯 LLM Judge。（可验证信号便宜、稳定、不易被 hack；judge 贵且可被钻）
• 奖励「调用了工具」也不够 —— 否则模型很容易学会反复调用工具刷分。

6.3 第三步：算法层面的取舍#

⚠️ 诚实边界：GiGPO、GraphGPO、ATPO、SORL、anchor-state grouping 这几个名词来自单篇面经，本文件不做展开也未核实。面试里安全的说法是：「我知道有一类工作把 trajectory 级的比较细化为相同状态下的 action 比较」，然后不展开细节。硬展开会被一层追问打穿。

6.4 两类问题不要混着答#

面经里专门点出的一对区分：

• 训练稳定 ≠ credit 分对了
• credit 分细 ≠ stale trajectory 已经处理好

这两条对应完全不同的修法（前者动 ratio/clipping，后者动采样与并行策略）。混在一起答，等于暴露没分清问题。

6.5 训练时至少同时盯这些指标#

只有 reward 一条曲线是不够的（见 §5）。该面经给出的清单：

reward 分布 · 非零 advantage 比例 · 任务成功率 · 有效工具调用率 · trajectory 长度 · 每个 turn 的 entropy · KL · clip fraction · gradient norm · 正确轨迹的 log probability

记住其中的因果顺序：reward 还在涨的时候，正确轨迹的 likelihood 可能已经在跌了。

6.6 第四步（工程）：环境与 rollout 怎么做#

这一层是工程量的大头，也是最容易在面试里显出「真跑过」的地方。

环境必须能快速重置到确定性的初始状态。 原话：「每个 rollout 都要从同一个起点开始，不然 reward 的 comparability 就没了。」三种方案的取舍必须能说清：

作者的做法：核心的确定性操作（比如代码执行）用真实沙箱，对外部 API 用 mock + record-replay 混合。

并行化是刚需。 GRPO 每个 prompt 采 $G$ 个 rollout（$G$ 一般 8~64），每个 rollout 可能有多轮工具调用；不做并行的话「一个 batch 的数据可能要采几个小时」。做法：rollout 生成和模型训练异步进行（一边用当前模型采样，一边用上一批 rollout 训练模型 —— 代价就是 §4.4 的 policy lag）；环境交互也批量并行，同时开几十个 sandbox；用 vLLM 做推理时注意和训练框架的 GPU 调度别打架。

量级参考（7B）：prompt 集 5,00050,000 条；每 prompt 采 832 个 rollout；有效训练步数几百到几千步；总 token 消耗数十亿到数百亿，主要取决于轨迹长度。

结论原话（和 §4.4 是同一个结论，但说得更斩钉截铁）：「其实 rollout 生成消耗的算力远大于模型更新本身。所以推理集群的配置往往比训练集群更重要。」

6.7 稳定化：mask & filter，以及「保守起步」#

(a) Mask and Filter —— 维持稳定性的基础保障（有出处的做法）。 终端环境里不可避免出现瞬时网络故障、沙箱启动失败、工具调用偶发超时；「把这些异常信号直接纳入策略更新，会向优化过程引入噪声」。原则一句话：

「当前对训练有害或无法提供有效学习信号的样本，都可以采用 mask 或者 filter。」

关键在按可恢复性分两类（这个区分是它的精细之处）：

• 不可恢复或大规模的错误（环境启动失败、沙箱不可用）→ 完全 mask 掉，并用占位样本替换，以保证 batch size 大小的数据；
• 偶发且可恢复的错误（工具超时、网速延缓）→ filter 掉，并在全局控制比例（例如 ≤50%），避免过度重试。

实验对比：不用 mask & filter 时训练波动大、准确率不稳定（0.604）；采用后曲线更平滑并收敛到显著更优（0.673）。

(b) 保守起步：先从正样本轨迹学习。 前提判断：「在早期阶段，RL 往往受限于数据质量，而不是优化算法本身（当数据质量较差时，再好的优化方法也难以奏效）。」做法：在数据尚未完全可靠时，仅使用正样本轨迹训练。 证据分两段，结论相反 —— 反转本身才是要点：

• 大规模合成数据上：正负轨迹同时更新会更频繁崩溃；仅用正轨迹在各种设置下都保持稳定（原文提到同类现象见 TOPR、W-REINFORCE）；
• 切换到小规模、高质量、经专家验证的数据后：两种方法都能稳定训练，但加入负轨迹后下游测试集提升更显著。

于是采用课程式策略：早期只用正样本轨迹更新（基于大规模实例数据构建稳定的策略流形），后期有了小规模高质量实例才同时考虑正负轨迹。

⚠️ 与 RFT 的区别（这是面试官最容易钻的一层）：看起来像 RFT，但「前者仍然优化 RL 的 surrogate objective，只是将负样本的 advantage 置零」；RFT 是把筛出的成功轨迹当监督数据、优化 likelihood 目标。而且前者仍遵循标准 RL 流程（masking、clipping、normalization 等稳定机制）。原文原话：「positive-only RL 并不是 RFT 的替代，而是一种更为保守的 RL 训练方式。」

6.8 崩溃了怎么救：先看早期信号#

心态（有出处的原话）：「在大规模终端 RL 训练中，崩溃是常态。」 关键不是避免崩溃，而是能不能 Resume，以及监控哪些早期信号。

一条真实曲线：训练分数在 step ~80 开始急剧下降 —— 但回看更早阶段，优势的平均值已经出现了明显的持续下滑趋势。进一步分析发现：从大约 step ~50 开始，失败轨迹的最大回复长度迅速上升，而失败轨迹的样本数基本保持不变 → 说明问题不是整体失败变多，而是少量极端失败轨迹在主导更新。对策：对响应长度超过 20k 的失败轨迹 masking（或降权）→ 优势均值回升。约 40 step 后不稳定再现，这次最早的信号是负样本数量逐渐增加 → 对负样本全局重加权。

不稳定时优先检查的信号（可直接当排障清单）：

两条经验原则：优先针对极端轨迹做定向处理（极端轨迹若能被特征定位，例如「超长的失败轨迹」，就先精准 mask），仍然不稳定再上全局重加权；RL 梯度通常比监督学习噪声大，因此更小的学习率、配合更强的约束、退火或自适应机制，往往更稳定。

与 §6.5 的分工：§6.5 的指标清单回答「平时看什么」，这张表回答「崩了先怀疑什么、动哪一刀」。

6.9 防「隐蔽的 reward hacking」：行为监控信号#

原话：「在 Agentic RL 中，reward hacking 往往更加隐蔽。由于智能体与真实环境交互，它们常常可以以『看似合理』的方式通过测试用例。」

反复出现的五种模式（比「模型会刷分」具体得多）：

两条启示：测试用例的质量与鲁棒性至关重要 —— 「薄弱或描述不充分的测试可能在无意中奖励错误行为」；并非所有实例都适合用于 RL 训练 —— 「某些任务本身难以通过测试准确评估，反而更容易诱导模型寻找捷径」。

该盯的监控信号（很具体，可直接落到面板上）：不同任务的成功率趋势、不同工具的成功/失败率、重复或循环的工具调用模式、不同工具的使用频率、不同命令的使用频率。发现异常（某个工具调用突然激增、大量重试循环、频繁执行 kill process 类命令）就回滚训练，或定位并移除引发问题的实例。

6.10 最重要的一条：没有通用解法#

§6.6–6.9 里的所有手段（selective trajectory masking、selective token masking、trajectory-level reweighting、retry-loop penalties、轻量行为塑形奖励/惩罚）有一个共同的目标：「控制哪些轨迹、轨迹的哪些部分、以何种权重参与策略梯度更新」。

但原文紧接着强调 —— 这是整篇里最值钱的一句：

「没有通用解法。不同数据条件下，同一策略可能产生相反效果。」

证据是一个反例实验：移除标准差归一化（std normalization），在一种数据设置下会迅速导致训练崩溃；而在另一种设置下，同样的操作反而使训练更加稳定 —— 差异只来自数据分布。

为什么这条最值钱：它把「读过几篇 Agentic RL 的方法」和「理解这些方法为什么不是银弹」区分开了。面试里主动说「这些技巧没有通用解，同一策略在不同数据分布下可能反向，所以要先判断失败属于重尾型 / 负样本占优 / 学坏模式哪一类」，比罗列十个方法名可信得多 —— 而且这是公开技术报告里的原话，不是推测。这也直接解释了 §6.4 那条「两类问题不要混着答」为什么重要。

7. 结论#

该面经的原话：「GRPO 没过时，但它不再是默认答案。」

更准确的表述是：GRPO 在单轮 reasoning RL（数学、代码）里依然很好用，因为 prompt、response 和 reward 之间的关系相对直接；Agentic RL 多了环境状态、多轮动作、延迟奖励和异步 rollout，这四个新变量各自动摇一条前提。所以「Agentic RL 能不能用 GRPO」的正确答案不是能或不能，而是先问这四个变量在不在你的场景里成立。

最后补一层落地视角：把这些变量都摆清之后，实践中真正决定成败的往往不是算法名字，而是三件更土的事 ——

1. 该不该上 RL（§2）：有没有可自动验证的 reward、SFT 是不是已经「会做但做不好」；
2. 环境与数据（§6.6–6.7）：「每条 prompt 必须有可自动执行的验证方法」这件事常占整个项目工时的 30% 以上；环境要能确定性重置，而 mock / record-replay 都有「模型探索出的新路径覆盖不到」的硬边界；
3. 崩了怎么救（§6.8）：崩溃是常态，关键是能 Resume —— 而且要盯的是 advantage 均值、极端轨迹长度、负样本占比这些比 reward 更早动的信号。

这与「Agentic RL 是个高深的算法问题」的直觉相反，但四篇材料指向同一结论：Agentic RL 的瓶颈是工程，不是算法。

常见面试问法#

Q：什么是 Agentic RL？它和单轮 LLM 的 RL 有什么区别？ A：训练单元不同。单轮是 prompt → response → reward，整条回答近似一次完整决策，reward 直接归因到它；多轮是 state → action(tool call) → observation → … → reward，模型在环境里连续决策，reward 只在终局给且延迟很长。建模上从接近 contextual bandit 变成接近 POMDP。这个差别不是量变 —— 它让 GRPO 赖以成立的四条前提（短 horizon、强 verifier、组内 reward 有方差、一条 response 就是一次决策）同时失效。

Q：Agentic RL 里可以继续用 GRPO 吗？（紧接「那 credit 怎么分」的追问） A：先反问场景，再回答。 如果 horizon 短、环境确定、组内方差足，GRPO 可以继续用，在上面加 turn-level reward 比换算法更省工程成本。但只要轨迹长、工具调用多，四个问题就会同时出现：credit 太粗（整条轨迹共享一个 advantage）、组内 advantage 常归零（长 horizon + 0/1 奖励导致全对或全错）、组内比较掺入环境噪声（不同轨迹看到的 observation 不同，reward 差异未必来自策略）、rollout 成本与 policy lag（跑几十次工具调用再乘 group size，异步后数据越来越 off-policy）。正确的答法不是「能/不能」，而是先问这四个变量在你场景里成不成立。

Q：最终 reward 是 1，前面几十次 tool call，到底该奖励哪一步？ A：这是最能问穿 GRPO 的一问，因为 vanilla GRPO 让整条 trajectory 共享同一个 advantage，它只知道「整条轨迹好不好」，不知道「哪一步做对了」。后果在两个方向上都错：答对时，中间的高质量 query 与无效搜索、重复调用、错误判断一起被鼓励；答错时，可能前面二十步都对，只因最后格式错误或一次工具超时，前面的有效动作一起被惩罚。解法是把奖励落到 turn 上 —— 用「工具调用是否合法、是否到达新环境状态、单测通过多少、是否完成子目标」这些中间信号。

Q：多轮工具调用的 RL loss 怎么设计？是每轮算还是整个 rollout 完成后算？ A：这个问题的价值在于逼你说清训练单元的粒度。整条 rollout 完成后算，就是当前主流做法（终局奖励 + 组内归一化），简单但与决策粒度错配；每轮算则需要每步都有可靠奖励或价值估计，成本高且中间奖励难设计。关键在于承认这是一组取舍：改用 PPO + critic + GAE 可以让 $V(s_t)$ 把终局收益逐步传回不同 turn，代价是显存与训练难度上升 —— 在长 horizon 下这笔成本可能比反复采样整组 trajectory 更划算。

Q：从 loss 角度看，GRPO 的设计有什么问题？ A：三层。① 归因太粗：一个 advantage 摊到整条轨迹，长轨迹上等于假设每步贡献相同；② 有效梯度太少：组内奖励一致时 advantage 恒为 0，长 horizon 下「全对/全错」是常态，采样的昂贵轨迹白跑；③ 粒度和决策结构错配：GRPO 在 token 级算 ratio 与 clipping，而环境执行的单位是一整次 tool call —— 异步 rollout 让数据 off-policy 之后，这种错配会表现为高方差、过度 clipping，甚至 reward 还在涨而正确轨迹的 likelihood 已经开始跌。

Q：组内 advantage 为什么会归零？怎么缓解？ A：组内奖励方差接近零时，归一化后 advantage 全为 0，该组对梯度没有贡献。Agentic 场景下它更常见，因为 horizon 长、奖励稀疏（常为 0/1）：任务太难则同组全失败，太简单则同组全成功。缓解分两步 —— 先诊断（看每组 reward 分布、统计 zero-advantage group 比例），再做 dynamic sampling，优先采样处于能力边界附近的任务。但要主动补一句：这只解决「组内没有差异」，解决不了多轮 credit assignment。能说出这个边界，比背出 dynamic sampling 值钱。

Q：reward 涨了但模型没变好，你怎么排查？ A：先看别的曲线。Agentic RL 里 reward 是最钝的指标：reward 上升的同时可能 entropy 骤降、response/trajectory 长度暴涨、clip fraction 变大、held-out 成功率不升 —— 这些组合指向模式坍缩、策略陈旧或钻了验证器漏洞。所以诊断面板至少要同时看：reward 分布、非零 advantage 比例、任务成功率、有效工具调用率、trajectory 长度、每个 turn 的 entropy、KL、clip fraction、gradient norm、以及正确轨迹的 log probability。最后一项尤其关键 —— 它比 reward 更早暴露问题。

Q：奖励设计在 Agentic RL 里要注意什么？ A：两条原则。① 能用执行结果验证，就尽量少用纯 LLM Judge —— 可验证信号便宜、稳定、不易被钻；judge 贵且可被 hack。② 奖励「调用了工具」是不够的 —— 否则模型很容易学会反复调用工具刷分，看起来工具调用率很高，实际什么都没完成。这和 grpo.md 里 reward hacking 的讨论是同一件事，只是可被 hack 的面变大了（多了一个真实环境）。

Q：为什么「训练不稳定」和「credit 分得粗」必须分开回答？ A：因为根因和修法都不同。训练不稳定出在 ratio/clipping 这一层（对应 GSPO 那类调整 sequence-level ratio 与 clipping 的工作）；credit 分得粗出在奖励粒度与采样上（对应 turn-level reward、dynamic sampling、同状态下的 action 比较）。同理，credit 分细也不代表 stale trajectory 已经处理好 —— 后者要靠并行策略与 policy lag 的处理。混在一起答会被读成「在堆方法名」；拆开答证明你能从现象定位到具体环节。

Q：什么时候该上 RL？什么时候不该？ A：先反问「这个任务真的需要 RL 吗」，再给判据。该上（满足至少两个）：① 任务结果能自动判（最关键 —— 「没有可靠的自动 reward，后面一切都是空中楼阁」）；② SFT 模型已「会做但做不好」，成功率大概 10%~40%（完全不会做则「巧妇难为无米之炊」）；③ 任务存在多种解法；④ 错误恢复是刚需。别上：SFT 已到 90%+ 成功率（为几个点不值得）；没有自动评测手段（reward 全靠人打分时成本爆炸且噪声大）；基座模型太弱（连指令跟随和格式输出都不行，「基础没打好就上 RL 纯粹是浪费算力」）。要能说清 SFT 在 Agent 场景的天花板特别低的三个原因：distribution shift（一步选错工具，整条链路可能全废，对话里还能接回来）、缺探索能力（SFT 只记录成功路径，不知道走错了怎么办）、信用分配粗（每步同等权重监督，实际只有个别步决定成败）。

Q：Agent 场景里 GRPO 和 PPO 怎么选？ A：先上 GRPO，但理由不是效果更好。 原文说得很直白：「多数场景下两者效果差不多」，真正的理由是这个 —— 「Agent RL 真正的瓶颈不在算法上，而在 rollout 生成速度、reward 设计质量和环境稳定性上」，GRPO 工程复杂度低，能把精力留给这三件事。PPO 的实际代价：四个模型（Actor / Critic / Reference / Reward），7B 模型 4×A100 80G 是起步价；Critic 的 value loss 容易爆炸、与 Actor 学习率难匹配；Agent 轨迹几十步，Critic 的 bootstrap 估值误差会一路累积。什么时候才考虑 PPO（三条）：手上已有训好的 **PRM（Process Reward Model）**能给中间步骤打分；任务链路特别长（20 步以上），GRPO 的粗粒度信用分配明显不够用；团队本身有 PPO 的工程积累。

Q：训练跑着跑着 reward 崩了，你怎么排查？ A：看比 reward 更早动的信号。 一条真实曲线的经验：训练分数在 step ~80 才急剧下降，但优势的平均值在更早阶段就已经持续下滑；进一步定位发现「失败轨迹的最大回复长度迅速上升，而失败轨迹的样本数基本不变」→ 说明不是整体失败变多，而是少量极端失败轨迹在主导更新。所以按这个顺序查：① 是否有少量极端轨迹在主导更新（特征：异常长的失败轨迹 + 重尾负回报）→ mask/降权 + 收紧 clipping；② 负样本是否整体占主导（数量占比持续上升）→ 降负样本权重、过滤低置信失败样本、改课程式训练；③ 模型是否在学「坏模式」（某些工具/命令调用频率异常）→ 加行为惩罚、改奖励设计。两条原则：优先对极端轨迹做定向处理，仍不稳定再上全局重加权；RL 梯度噪声比监督学习大，更小的学习率配合更强的约束或退火往往更稳。最后提一句心态：「崩溃是常态，关键是能不能 Resume。」

Q：Agentic RL 里的 reward hacking 和普通 RLHF 有什么不同？ A：更隐蔽，因为智能体可以「以看似合理的方式」通过测试用例。 五种反复出现的模式：改环境而不是解任务（直接修改初始环境设置）、工具过度使用（反复调用工具做琐碎操作，本质是暴力重试）、滥用搜索（用大量重复搜索弥补推理不足）、破坏性操作（例如删除所有文件、终止所有进程）、利用测试脚本或默认配置的漏洞（没真正解决任务却通过测试）。两条启示：测试用例的质量与鲁棒性至关重要（薄弱或描述不充分的测试可能在无意中奖励错误行为）；并非所有实例都适合用于 RL 训练（有些任务难以通过测试准确评估，反而诱导模型找捷径）。所以要有细粒度行为监控：不同任务的成功率趋势、不同工具的成功/失败率、重复或循环的工具调用模式、不同工具与命令的使用频率 —— 发现异常就回滚训练或移除该实例。

Q：这些稳定训练的技巧（masking、重加权、课程式训练）能不能直接套用？ A：不能，这是这条线上最重要的认知。 原文原话：「没有通用解法。不同数据条件下，同一策略可能产生相反效果。」 证据是一个反例实验：移除标准差归一化在一种数据设置下迅速导致训练崩溃，在另一种设置下同样的操作反而让训练更稳定 —— 差异只来自数据分布。这些技巧的共同目标只有一个：控制哪些轨迹、轨迹的哪些部分、以什么权重参与策略梯度更新；具体怎么控，取决于失败属于重尾型 / 负样本占优 / 学坏模式哪一类。能说出「没有通用解、要先归因」，比背十个方法名值钱得多。

Q：Agentic RL 训练中，工具返回等待和 batch 组织做过哪些优化？ A：这个问题问的是工程侧的吞吐，不是算法。核心矛盾是 rollout 里大量时间花在等工具返回（远超模型生成时间），导致 GPU 空转。可讲的方向：把工具调用并行化（同组内不同 rollout 并发、组内样本并发）、异步 rollout（用吞吐换数据新鲜度，代价是 policy lag）、以及按轨迹长度分桶组织 batch 减少 padding 与长尾等待。注意主动承认异步的代价 —— 只说异步提升吞吐、不提 policy lag，等于漏掉了这个问题的一半。

易错点#

自测#

1. 为什么说「最终 reward 是 1，前面二三十次 tool call，该奖励哪一步」这个问题能一句话问穿 GRPO？

2. 组内 advantage 归零这件事，在单轮任务里也会发生。为什么说它在 Agentic 场景下更严重？

3. GRPO 的 baseline 假设「同一 prompt 下组内比较是公平的」。这个假设在多轮任务里从哪一刻开始不成立？

4. 「reward 还在涨，正确轨迹的 likelihood 却在下降」——请把它和优化粒度问题串起来解释。

5. 面试官问「Agentic RL 训练不稳定，你怎么办」，为什么先把「训练不稳定」和「credit 分得粗」拆开答会加分？