Agentic RL

条目状态与系统位置

本图位于 Training / Agent Runtime 的交界：运行时负责环境、工具和轨迹，训练侧负责 reward、advantage 和 policy update。链接是独立文章；未链接的术语表示当前只在闭环中解释，尚无独立正文。

学习主线

Agentic RL 位于“运行时 Agent 工程”和“策略训练”交界：先理解 Agent Loop、Agent Evaluation，再读 Reasoning RL、PPO、GRPO。

与其他阶段的边界

  • Supervised Fine-Tuning：模仿示范。
  • Reasoning RL：常聚焦单题或可验证推理。
  • Agentic RL：模型与工具/环境多步交互，轨迹产生数据和奖励，再更新策略。

训练闭环

1
2
3
4
5
6
7
policy model
→ rollout workers / inference engine
→ tools, web, code or simulator environment
→ trajectory and reward/verifier
→ learner updates policy
→ weights synchronized to rollout
→ new trajectories

奖励与优化

  • Reward Model、process/outcome reward、verifier（后两者未单列）
  • sparse reward、reward shaping、credit assignment（待建）
  • PPO、GRPO 与 KL regularization
  • tool cost、failure recovery 与 safety constraints（未单列：作为 rollout 验收条件）

系统架构

  • Learner：PyTorch + DeepSpeed/Megatron/FSDP
  • Rollout：vLLM/SGLang
  • Control plane：Ray 组织 learner、rollout、reward 和 environment workers
  • Cluster plane：Kubernetes 管理容器、节点和资源隔离

Ray 围绕 PyTorch learner 与 vLLM rollout 进行组织，而不是简单位于二者“下面”。

工程问题

  • asynchronous rollout 与 policy staleness（待建）
  • weight synchronization（未单列：见本页训练闭环）
  • rollout throughput 与 GPU 分配（未单列：见 vLLM 和 Ray）
  • environment sandbox、fault recovery（待建）
  • Agent Evaluation 与安全

关键因果链

1
2
3
4
5
6
环境/工具设计
→ rollout 质量与成本
→ reward/verifier 的可辨识性
→ advantage 与 policy update
→ weight staleness / 同步延迟
→ 下一轮轨迹分布

任何环节失真都会被后续优化放大：工具超时会变成错误奖励，奖励漏洞会变成策略投机，rollout 与 learner 不同步会让训练目标过时。验收必须同时看任务成功率、轨迹长度、工具成本、策略新鲜度、失败恢复和安全约束。

从单题推理到环境轨迹

Agentic RL 的难点不只是把 prompt 换成更长的 trajectory，而是动作会改变后续状态，奖励可能延迟到任务结束。若一个 agent 先写错文件、再用后续工具把错误掩盖，最终文字答案正常，单一 outcome reward 仍可能无法指出哪一步需要改。应保留每个 observation、工具副作用和中间 verifier；在可行时加入 process signal，但要防止模型学会迎合 verifier 的表面格式。

1
2
3
4
5
6
state_t
→ policy chooses tool/action
→ environment changes to state_(t+1)
→ verifier observes outcome / cost / safety
→ credit assigned to earlier actions
→ policy update changes future rollout distribution

系统约束决定算法选择

PPO 需要 rollout、价值估计和较近的 policy/reference；GRPO 通过同一问题的 group reward 估计相对优势，减少独立 critic，但对 group 方差和任务可验证性更敏感。两者都不能修复不可辨识的 reward。若 rollout 使用旧权重、工具延迟很长或环境有随机副作用，应先解决版本标记、轨迹去重和恢复，再讨论换算法。

最小闭环应同时对比：成功率/验证通过率、平均轨迹长度、工具费用、无效循环、reward 与真实业务指标的相关性、rollout policy staleness 和安全违规。若 reward 上升而真实成功率下降，优先怀疑 reward hacking 或环境分布漂移，而不是继续增加训练步数。