主题归档 2026-06-21 ★★★★★ PPOAgentic RLLLM AgentRLHFRLVRGRPOCredit AssignmentPost-training

#PPO 在 Agentic RL 中的应用与进展：从 RLHF 到长轨迹 Agent 训练

一句话结论：PPO 并没有在 Agentic RL 时代过时，它只是从“对单轮回答做 token-level 对齐”的算法，逐渐被迫改造成面向多轮交互、工具调用、长轨迹信用分配的训练框架。 现在真正的分歧不是“PPO vs 非 PPO”，而是：Agent 的决策单元到底应该是 token、turn、step、trajectory，还是更抽象的 latent state？

这篇文章梳理 PPO 在 Agentic RL 中的应用和进展。核心脉络大概是：

经典 PPO
  → RLHF / InstructGPT：对单轮语言输出做偏好对齐
  → RLVR / Reasoning RL：用可验证奖励训练推理与代码
  → Agentic RL：搜索、网页、GUI、代码仓库、多工具交互
  → Turn/Sequence/Trajectory-level PPO：重新定义 PPO 的决策粒度
  → 与 GRPO/GIGPO/HGPO 分化：critic-based 样本效率 vs critic-free 组内相对估计

如果只记住一个问题，那就是：PPO 原本擅长优化连续动作序列，但 LLM Agent 的“动作序列”已经不再只是 token，而是带有环境状态、工具反馈、历史记忆和长期目标的交互轨迹。

#1. PPO 原本解决什么问题？

PPO，全称 Proximal Policy Optimization，由 Schulman 等人在 2017 年提出。它本来是一个通用强化学习算法，核心目标是：在更新策略时既要让策略朝着高奖励方向走，又不要一步迈太大导致训练崩掉。

人话理解：

  • 普通 policy gradient 像是“看到奖励高的动作就猛推一把”。
  • TRPO 想保证更新别太大，但实现复杂。
  • PPO 用一个 clipped surrogate objective 做近似约束：如果新策略相对旧策略变化太大，就截断收益，防止过度更新。

PPO 在传统 RL 里受欢迎，是因为它在几个维度上比较均衡：

维度PPO 的特点
稳定性比裸 policy gradient 稳定，避免策略突变
实现复杂度比 TRPO 简单很多
样本利用一批 rollout 可以做多轮 minibatch 更新
工程成熟度大量 RLHF / RL 框架都支持

但 PPO 也有一个重要前提：它通常需要估计 advantage。也就是说，它要知道“这个动作比当前状态下的平均水平好多少”。在经典 RL 里，这通常依赖 value function / critic。

这点后来成为 PPO 在 LLM Agent 里的核心矛盾：critic 有助于样本效率，但在长文本、长轨迹、多工具 Agent 中，value 估计很难、很贵、很容易错。

#2. 第一阶段：PPO 成为 RLHF 的默认算法

PPO 真正进入大模型训练主线，是通过 RLHF。

InstructGPT / ChatGPT 这一类路线大致是：

  1. 收集人类示范，做 SFT。
  2. 收集人类偏好比较，训练 reward model。
  3. 用 PPO 优化语言模型，让模型生成更符合 reward model 偏好的回答。

这里 PPO 的“环境”其实很简单：

prompt → 模型生成回答 → reward model 给分 → PPO 更新

它不像传统 RL 那样有复杂环境状态转移。一次生成可以被看作一个 episode，生成过程中的 token 是动作，最终 reward 往往在整段回答结束后给出。

这带来两个特点。

第一，PPO 在 RLHF 中主要承担“别让模型偏离太远”的稳定优化器角色。通常还会加 KL penalty，把策略限制在 reference model 附近，避免 reward hacking 或语言质量崩坏。

第二，这个阶段的 PPO 主要服务于对齐，而不是训练复杂的环境交互能力。它让模型更有帮助、更安全、更符合人类偏好，但还没有真正让模型学会长程规划和工具操作。

这也是为什么早期 RLHF 中的 PPO，和今天讨论的 Agentic RL PPO，虽然算法名相同，但问题形态已经很不一样。

#3. 第二阶段：RLVR 让 PPO 从“偏好对齐”走向“能力强化”

随着 DeepSeek-R1、o1/o3 这类 reasoning model 的出现，RL 的角色发生了变化：它不只是让模型更听话，也开始被用于提升数学、代码、推理能力。

这类工作常被概括为 RLVR：Reinforcement Learning with Verifiable Rewards。它的核心是：如果任务答案可以自动验证，就不一定需要人类偏好 reward model。

例如：

  • 数学题：最终答案是否正确。
  • 代码题：测试是否通过。
  • 搜索问答：答案是否匹配标准答案或引用是否支持。
  • 工具任务：最终环境状态是否达到目标。

这时 PPO 面临的新问题是：奖励仍然可能只在最后给出，但生成过程变长了，Chain-of-Thought、代码草稿、搜索步骤、工具调用都可能影响最终结果。

标准 token-level PPO 会把整个生成序列看成一串 token action，然后根据最终 reward 回传 advantage。问题是：

最终答对了，是因为哪一段推理对？
最终答错了，是因为哪一步出错？
长 CoT 中哪些 token 真正有因果作用，哪些只是废话？

这已经开始接近 Agentic RL 的 credit assignment 问题。

所以从 RLHF 到 RLVR，PPO 的定位发生了第一次迁移：

阶段PPO 优化对象奖励来源核心问题
RLHF单轮回答质量人类偏好 / reward model对齐、稳定性、KL 控制
RLVR推理/代码过程自动验证器长输出信用分配、探索、reward hacking

#4. 第三阶段：Agentic RL 让 PPO 面对真正的环境交互

Agentic RL 指的是用 RL 训练 LLM Agent 在环境中行动，而不只是生成一段静态文本。

典型任务包括：

  • Web / Search Agent：多轮搜索、打开网页、整合证据。
  • WebShop / WebArena：浏览网页、选择商品、完成任务。
  • GUI Agent：观察屏幕、点击、输入、滑动、打开 App。
  • Code Agent / SWE Agent：读仓库、定位 bug、修改文件、运行测试。
  • Tool-use Agent：调用 API、数据库、计算器、代码解释器等工具。

这时 PPO 面临的问题比 RLHF 复杂得多：

状态：用户目标 + 历史消息 + 环境观察 + 工具返回 + 记忆
动作：自然语言 token + 工具调用 + GUI 点击 + 文件编辑
奖励：可能只有最终成功/失败，也可能有过程 reward
轨迹：几十步、上百步、甚至跨多个工具和环境

这不是简单的“prompt → answer”。它是一个长程控制问题。

#4.1 WebGPT：早期 browser-assisted QA 的信号

WebGPT 是一个很早的重要节点。它把 GPT-3 放进文本浏览器环境中，让模型搜索和浏览网页来回答长问题。训练上主要使用 imitation learning、reward model 和 rejection sampling，而不是今天意义上的大规模 PPO Agent RL。

但它的意义在于：它已经把语言模型从“回答器”推向“会浏览环境的 Agent”。

它暴露的新问题是：如果模型在浏览过程中做了很多中间操作，最后回答质量好坏如何反向归因到搜索 query、点击、引用选择这些步骤？

这就是后续 Agentic RL 必须解决的问题。

#4.2 WebShop：把语言 Agent 放进可评估环境

WebShop 提供了一个模拟电商网站环境：Agent 需要根据自然语言需求浏览商品、筛选属性、最终购买合适商品。

它的重要性在于，它让语言 Agent 的行为可以被环境奖励评估。WebShop 这类环境后来成为许多 Agentic RL 方法测试长程交互能力的基准。

对 PPO 来说，WebShop 让问题变成：

一个购买任务可能包含多次搜索、点击、筛选、比较、选择。
最后 reward 是买对还是买错。
PPO 应该如何给每个 turn / action 分配 advantage？

这就是 turn-level PPO、trajectory-level PPO、stepwise group-based RL 后来要处理的核心。

#5. 为什么直接把 RLHF-PPO 搬到 Agent 上不够？

最直接的做法是：把整条 Agent 轨迹拼成一个长序列，用 PPO 优化所有 token。

这在工程上最简单，但问题很多。

#5.1 决策粒度错位：token 不是 Agent 的自然动作

LLM Agent 的一个 action 可能是：

{"tool": "search", "query": "PPO agentic RL long horizon"}

或者：

点击屏幕上第 3 个按钮

它不是单个 token。token-level PPO 会在语言 token 层面更新，但真正影响环境的是完整的工具调用、点击动作、代码 patch、搜索 query。

所以 token-level credit 可能很噪：它优化的是字符串概率，而不是清晰的环境动作。

#5.2 长轨迹稀疏奖励：最终成败太粗

Agent 任务常常只有最后成功/失败奖励。整条轨迹可能几十步，如果最终失败，直接把负信号压给所有 token，会误伤很多正确步骤。

这和我上一篇讲 GIGPO/HGPO 时的核心问题一致：长轨迹 RL 的关键不是“有没有 reward”，而是“reward 怎么分配给真正造成结果的决策”。

#5.3 Critic 很难学：value function 的状态空间太复杂

PPO 通常需要 value model 估计每个状态的价值。但 LLM Agent 的状态包括长上下文、网页、屏幕、工具返回、代码仓库状态。训练一个可靠 critic 很难：

  • 输入太长，显存贵。
  • 状态分布变化快，critic 容易过拟合。
  • 最终 reward 稀疏，value bootstrap 噪声大。
  • 如果 critic 错了，PPO 的 advantage 也会错。

这就是 GRPO、RLOO 等 critic-free 方法流行的原因：它们牺牲一部分样本效率，换取更低内存、更简单、更少 value-model 误差。

#5.4 环境成本高：PPO 的 on-policy 采样很贵

PPO 是 on-policy 或 near-on-policy。每次策略更新都需要新 rollout。对数学题来说 rollout 只是生成文本；对 Agent 来说 rollout 可能意味着：搜索网页、访问 GUI、运行代码测试、调用 API、执行浏览器任务。

这会让训练成本急剧上升。于是 Agentic RL 里经常要混合：

  • imitation learning / behavior cloning；
  • offline trajectory reuse；
  • rejection sampling；
  • process reward / verifier；
  • group-based advantage；
  • replay buffer 或离线 critic；
  • 分层 RL / turn-level update。

PPO 仍然重要，但通常不再是“单独解决一切”的算法。

#6. 当前进展一：Turn-level PPO，把一步从 token 改成 turn

一个很直接的改造是：不要把 token 当作 MDP step，而是把 Agent 的一个 turn 当作 step。

Turn-PPO: Turn-Level Advantage Estimation with PPO for Improved Multi-Turn RL in Agentic LLMs 就是这个方向的代表。它指出，在多轮任务中，直接用 GRPO 可能不够稳定，而 PPO 的 critic-based advantage 在某些设置下更鲁棒。于是它把多轮 Agent 任务建模成 turn-level MDP，而不是 token-level MDP。

人话说：

  • token-level PPO：每个 token 都是一个动作。
  • turn-level PPO：一次完整回复/工具调用/环境交互回合是一个动作。

这样做的好处是，advantage 更贴近环境决策。Agent 真正改变环境的不是某个 token，而是一个完整 turn 的行为。

Turn-PPO 在 WebShop 和 Sokoban 等任务上验证了这种思路，尤其关注 long-horizon、多轮交互场景。

它推动的下一阶段问题是：turn 比 token 更合理，但一个 turn 内可能包含推理、工具选择、参数生成、动作执行等多个子决策。是否还需要更细粒度的 step / sub-step credit？

#7. 当前进展二：Sequence-level PPO，把长推理当作整体决策

另一个方向是 Sequence-Level PPO / SPPO。

SPPO 关注长程 reasoning task。它认为标准 token-level PPO 在长 CoT 上会遇到两个问题：

  1. temporal credit assignment 不稳定；
  2. value model 显存成本高。

于是它把推理过程重新建模为 sequence-level contextual bandit：一整段推理序列作为一个决策单元，用更轻量的 scalar value function 估计低方差 advantage。

这和 Turn-PPO 的直觉相通：不要执着于 token-level MDP。

差别在于：

  • Turn-PPO 更面向多轮 Agent 环境。
  • SPPO 更面向长 CoT / long-horizon reasoning。
  • 二者共同说明：PPO 在 LLM 场景下要重新选择“动作粒度”。

这对 Agentic RL 很重要，因为很多 Agent 轨迹里既有长 CoT，又有工具 turn。未来可能需要同时处理：

token-level language modeling
sequence-level reasoning
turn-level tool interaction
trajectory-level task success

#8. 当前进展三：RAGEN / Search-R1 等把 RL 推向多轮工具和搜索

RAGEN: Understanding Self-Evolution in LLM Agents via Multi-Turn Reinforcement Learning 是多轮 Agent RL 的代表节点之一。它关注 LLM Agent 在多轮环境中通过 RL 自我演化，强调 multi-turn rollout、环境反馈和长期能力提升。

Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning 则把搜索引擎纳入 reasoning 过程，训练模型在需要时搜索、整合证据、回答问题。后续还有 MMSearch-R1 等多模态搜索 Agent。

这些工作不一定都以“标准 PPO”为唯一核心，但它们共同推动了一个趋势：RL 的训练对象从静态答案变成交互策略。

对 PPO 来说，这些系统提出了几个新要求：

  1. 多轮状态建模：状态不只是 prompt，而是历史搜索和观察。
  2. 工具动作建模：动作不只是文本，还包括 search query、点击、调用。
  3. 过程反馈利用：搜索结果、工具返回、环境变化都可以作为中间信号。
  4. 长期 credit assignment：最终答对可能依赖很早的一次搜索。

这也是为什么 Agentic RL 的 PPO 往往需要配合 process reward、step reward、turn-level advantage 或分层 credit assignment。

#9. 当前进展四：Agent Lightning，把任意 Agent 执行解耦成 RL 训练轨迹

Agent Lightning: Train ANY AI Agents with Reinforcement Learning 提出了一个很工程化、也很关键的问题：现实中的 Agent 往往已经由 LangChain、OpenAI Agents SDK、AutoGen 或自定义框架搭好了，RL 训练不应该要求重写整个 Agent。

它的思路是把 Agent 执行和 RL 训练解耦：

  • Agent 按原有框架执行任务。
  • 系统把执行过程抽象成 MDP 轨迹。
  • 再用统一数据接口和 credit assignment 模块，把轨迹拆成训练 transition。

这类框架对 PPO 的意义在于：PPO 不再只是一个模型内部 loss，而是整个 Agent runtime 的训练后端之一。

也就是说，未来的 PPO Agent 训练可能更像：

Agent runtime 负责执行
trajectory recorder 负责记录状态/动作/奖励
credit assignment module 负责拆分回报
PPO/GRPO/其他 RL optimizer 负责更新模型

这比早期 RLHF 的“生成文本 → reward model 打分 → PPO 更新”复杂得多，也更接近真实 Agent 系统。

#10. 当前进展五：GUI / Code / SWE Agent 里的 PPO 与 RL

GUI Agent 和 Code Agent 是 Agentic RL 最自然、也最困难的应用场景。

#10.1 GUI Agent

GUI Agent 要观察屏幕并执行点击、输入、滑动等动作。2025–2026 年出现了许多 GUI-R1、UI-R1、MagicGUI、GUI Agents with RL 这类工作和综述。

PPO 在这里的挑战是：

  • action space 混合了语言、坐标、UI 元素和高层意图；
  • 错误动作可能有不可逆后果；
  • 环境状态视觉化、长程、部分可观测；
  • 成功 reward 稀疏，但每一步都可能影响后续。

因此 GUI Agent RL 往往会采用混合策略：SFT 先学基本操作，RL 再优化任务完成率；离线数据和在线探索结合；奖励包含最终成功、过程约束、安全规则等。

#10.2 Code / SWE Agent

代码 Agent 的奖励看似更清楚：测试通过就是 reward。但困难在于：

  • 一个任务可能需要读很多文件；
  • 修改可能跨多个模块；
  • 测试反馈慢且稀疏；
  • 中间错误很多，但并不都应该被惩罚；
  • 代码仓库状态巨大，critic/value 估计更难。

DeepSWE、SWE-RL、SWE-TRACE、Agentic Rubrics 等工作都说明，代码 Agent RL 的关键不只是 PPO loss，而是如何设计环境、rubric、过程 reward、测试反馈、轨迹筛选与 credit assignment。

我的判断是：在 Code Agent 里，PPO 会更像一个优化器组件，而不是完整方法本身。真正决定效果的是：

任务环境 + 轨迹采样 + 测试/验证器 + 过程 reward + credit assignment + 上下文管理

#11. PPO 与 GRPO 系列的分叉：为什么大家转向 critic-free？

近两年大模型 RL 中，GRPO、DAPO、GSPO、GIGPO、HGPO 等方法非常火。它们和 PPO 的关系不是简单替代，而是围绕一个核心取舍分化：

要不要训练 critic/value model？

PPO 的优点是：如果 value 学得好，advantage 估计样本效率高，不一定需要同一个 prompt 下采很多条样本来做 baseline。

GRPO 的优点是：不用 critic，直接在同组 rollout 内做相对优势估计，显存更低、工程更简单，也减少 value 估计错误。

但 GRPO 到 Agent 场景会遇到新问题：整条轨迹组内比较太粗。于是出现：

  • GIGPO：在轨迹组里再构造同状态动作组，做 step-level micro advantage。
  • HGPO：发现同当前状态还不够，历史上下文不一致会导致 advantage 偏差，于是构造 hierarchy-of-groups。

所以 PPO 与 GRPO 系列可以这样理解：

方法族核心优势核心代价Agentic RL 中的关键问题
PPO有 critic，样本效率潜力更高；经典稳定value model 贵且难学critic 如何处理长上下文、多轮状态
GRPO/RLOOcritic-free，工程简单，显存低需要组内多样本，baseline 粗长轨迹 credit 太粗
GIGPO/HGPOstepwise / hierarchical group credit依赖可比较状态/上下文结构如何定义“可比状态”
Turn-PPO/SPPO保留 PPO，但改动作粒度仍要处理 value/advantage 估计turn/sequence/trajectory 粒度如何选择

这说明一个重要趋势：Agentic RL 的算法创新，正在从“换 loss”转向“重新定义状态、动作、优势估计和可比较样本组”。

#12. PPO 在 Agentic RL 中的当前定位

综合来看，PPO 当前在 Agentic RL 中有四种角色。

#12.1 作为稳定的 on-policy 优化器

PPO 仍然是最成熟的 on-policy policy optimization 算法之一。很多系统即使最终做了复杂改造，也会保留 PPO 的 clipped objective、KL 控制、advantage normalization 等工程经验。

#12.2 作为 critic-based 路线的代表

在 GRPO 等 critic-free 方法流行后，PPO 反而成为一个重要对照：当组内相对估计不稳定或样本开销太大时，critic-based PPO 可能重新有优势。Turn-PPO 的结论就指向这一点：在某些多轮任务里，PPO 比直接 GRPO 更鲁棒。

#12.3 作为“粒度重构”的框架

PPO 可以运行在 token、sequence、turn、trajectory 等不同粒度上。现在的问题不是 PPO 能不能用，而是：

什么是一个 state？
什么是一个 action？
reward 应该落在哪一层？
advantage 应该对哪个决策单元估计？

#12.4 作为 Agent runtime 的后训练后端

在 Agent Lightning 这类框架中，PPO/其他 RL 算法可以作为通用后端，训练任意 Agent 框架产生的轨迹。这意味着 PPO 未来可能更多隐藏在基础设施里，而不是作为论文标题中唯一的算法亮点出现。

#13. 关键开放问题

#13.1 Value model 应该看什么上下文？

如果 PPO 要在 Agent 中继续发挥作用，就必须回答：critic 的输入是什么？

  • 只看当前 observation？
  • 看完整历史？
  • 看压缩后的 memory？
  • 看工具状态和环境状态？
  • 看 latent task state？

完整历史太贵，当前观察不够，手工摘要可能丢关键信息。这里和“通用上下文压缩器”“latent state reasoning”直接相关。

#13.2 PPO 的 action 粒度应该是什么？

不同任务可能需要不同粒度：

  • 数学推理：sequence-level 可能足够。
  • 搜索 Agent：turn-level 或 tool-call-level 更自然。
  • GUI Agent：UI action-level 更自然。
  • Code Agent：patch-level、test-run-level、file-edit-level 可能更关键。

未来可能需要 adaptive granularity：模型或训练系统自动决定在哪些层级上估计 advantage。

#13.3 如何把过程 reward 和 PPO advantage 结合？

如果有 process reward model、rubric、测试反馈、工具中间信号，PPO 不应该只用最终 reward。但过程 reward 很容易引入错误激励：模型可能学会迎合 rubric，而不是完成任务。

所以关键不是“加更多 reward”，而是 reward calibration：哪些过程信号真的和最终成功有因果关系？

#13.4 PPO 与 model-based RL 如何结合？

你最近关心的 model-based RL / Dreamer for LLM Agent 在这里非常相关。

PPO/GIGPO/HGPO 大多依赖真实 rollout。问题是 Agent rollout 太贵，而且很多反事实动作没有被采样到。如果有 learned world model 或 latent transition model，就可以：

  • 预测某个工具动作的后果；
  • 在 latent space 中做 imagined rollout；
  • 给 PPO critic 提供更丰富的 bootstrapping 信号；
  • 构造更多可比较的 counterfactual group。

也就是说，未来的 Agentic PPO 可能不是单纯 on-policy，而是和 model-based value estimation / latent planning 混合。

#13.5 如何避免长轨迹 RL 学到伪相关？

这是我认为最重要的问题。

长轨迹 Agent 成功通常依赖少数关键步骤。PPO 如果用粗 reward 更新整条轨迹，可能奖励大量无关行为。GRPO/GIGPO/HGPO 在缓解这个问题，但仍然依赖样本组结构。

未来更基础的问题是：如何识别轨迹中的因果关键决策点？

这可能需要结合：

  • causal credit assignment；
  • counterfactual evaluation；
  • process verifier；
  • learned latent state；
  • memory provenance；
  • test-time search trace；
  • model-based rollout。

#14. 我的判断：PPO 会留下，但会被“Agent 化”

我不认为 PPO 会在 Agentic RL 中消失。更可能的情况是：

PPO 作为一个底层稳定优化器会继续存在，但论文和系统创新会越来越集中在状态抽象、轨迹切分、advantage 估计、critic 设计、过程奖励和环境基础设施上。

也就是说，未来我们看到的可能不是“Plain PPO for Agents”，而是：

Turn-PPO
Sequence-level PPO
Hierarchical PPO
Memory-aware PPO
Tool-call-level PPO
Model-based PPO
Critic-augmented Agent RL
PPO + process reward + verifier + trajectory replay

PPO 的名字可能还在，但它优化的对象会越来越不像传统 token 序列，而更像一个多层级决策过程。

#15. 对研究的启发

如果从研究机会角度看，我觉得 PPO in Agentic RL 有几个值得继续深挖的问题。

#15.1 Agent value model 可能是下一个关键瓶颈

GRPO 系列火起来，一个原因是大家不想训练 critic。但如果能训练出可靠、便宜、可泛化的 Agent value model，PPO 路线可能重新变得很强。

这个 value model 不应该只是“预测最终 reward”，而应该能理解：当前任务进展、历史关键决策、工具状态、剩余可行动作、失败风险。

#15.2 Latent state compression 可以服务于 PPO critic

长上下文 critic 太贵。一个自然方向是学习 decision-sufficient latent state：把完整 Agent 历史压缩成足以预测未来回报和选择动作的状态。

这和你的 latent-space reasoning 兴趣高度相关：latent 不只是为了省 token，也可以成为 RL 状态表示。

#15.3 Model-based Agent PPO 可以减少真实 rollout 成本

如果环境交互贵，model-based RL 可以用 learned dynamics 做 imagined transitions。对 LLM Agent 来说，world model 未必是物理世界模型，也可以是：

  • 工具调用结果模型；
  • 搜索/网页状态转移模型；
  • 代码修改后测试结果预测器；
  • 用户/任务反馈模拟器。

PPO 可以在真实 rollout 和 imagined rollout 的混合数据上更新，但关键是控制模型偏差。

#15.4 PPO 与 group-based 方法可能会融合

现在常常把 PPO 和 GRPO 对立起来，但更有可能的方向是融合：

  • 用 critic 提供全局 value baseline；
  • 用 group relative advantage 修正局部比较；
  • 用 stepwise / hierarchical groups 提供细粒度 credit；
  • 用 PPO clip 保持策略更新稳定。

这会把 PPO 的样本效率和 GRPO 系列的可比较样本优势结合起来。

#16. 总结

PPO 在 Agentic RL 中的演化可以概括为三句话：

  1. 从 RLHF 到 RLVR：PPO 从偏好对齐工具，变成推理/代码能力强化工具。
  2. 从单轮回答到多轮 Agent：PPO 面临状态、动作、奖励和 credit assignment 的全面重定义。
  3. 从 token-level 到多层级决策：Turn-PPO、SPPO、Agent Lightning、GIGPO/HGPO 等工作共同说明，未来的关键不是是否使用 PPO，而是如何定义 Agent 轨迹中的可学习决策单元。

所以，如果要判断 PPO 在 Agentic RL 中的前景，我会说：

Plain PPO 不够了，但 Agentified PPO 仍然很重要。真正值得研究的是：如何让 PPO 看到合适的状态、优化合适的动作、获得合适粒度的 advantage，并与 model-based / latent-state / group-based credit assignment 融合。

#参考资料

鼠鼠研究站 · 自动整理调研 / 论文 / 历史主题