Agentic RL 基础设施实战：从训练采样到推理加速的完整指南

这半年，身边几乎每个做 AI Infra 的团队都在聊 Agentic RL，我自己也连续跟进了几个从传统 RL 迁移到智能体强化学习的项目。坦白说，Agentic RL 的基础设施和之前做游戏 AI、机器人控制完全不是一回事，它既要管大模型的推理生成，又要管环境交互和长轨迹存储，还得承受强化学习本身带来的稳定性问题。这篇文章就把我对 Agentic RL Infra 主流技术路线的理解整理一遍，从训练采样拓扑、经验存储到推理加速，再到框架选型和实战排障，尽量说清楚每条路线解决什么问题、适合什么场景，给正在搭建这套系统的团队提供一份可以直接对照的参考。

1. 先捋清楚：Agentic RL 的基础设施到底在解决什么问题

1.1 Agentic RL 与传统强化学习的本质差异

Agentic RL 的核心是训练一个能自主决策的智能体：给它一个目标，让它在环境里通过试错获取奖励信号，不断优化自己的策略。这里的环境可以是代码运行沙箱、网页浏览器、游戏模拟器，也可以是物理世界的机器人；策略则是一个大语言模型、多模态模型，或者是基于这些模型的混合决策系统。

这跟传统 RL 的差别不只是模型变大了，而是整个数据流都变了。传统 RL 里，一条经验通常是一个 (状态, 动作, 奖励, 下一个状态) 四元组，状态是低维向量，动作是几个数值或离散索引。Agentic RL 里，动作是模型生成的 token 序列，状态是上下文窗口里成千上万个 token，奖励可能要等很多步之后才出现。一条完整轨迹的长度往往是几千甚至几万 token，这种量级的样本生产和存储完全不是原来的 replay buffer 能扛住的。

1.2 为什么普通 RL 框架迁不过来

有人会问：RLlib、Sample Factory 这些成熟框架不是现成的吗？答案是可以跑通 demo，但撑不起真正的 Agentic 任务。

第一个问题是大模型推理的引入。传统 RL 的 actor 网络是一个小模型，前向计算廉价，可以在 CPU 上跑几千个并行环境。Agentic RL 里，策略本身是几十上百亿参数的大模型，你必须用专门的推理引擎做批量生成，KV Cache 要管理，连续批处理要调度，这已经不是传统 RL 框架关注的事。

第二个问题是轨迹组成的异构性。Agentic 任务的观测往往包含文本指令、工具返回结果、历史对话、中间代码执行输出，这些数据要组装成模型能消费的格式，再和训练侧的 tokenizer、模板拼起来，工程复杂度比传统 feature 工程高一个数量级。

第三个问题是时序一致性。一个 rollout 可能持续几十步，每步生成都需要模型推理。如果同时有几百个 actor 在做异步采样，不同 actor 手里的模型参数版本、prompt 模板版本、环境版本都可能不一致，任何一环错位都会污染训练数据。这个问题普通 RL 框架基本不做。

1.3 基础设施的四大件：样本生产、训练、存储、评估

不管用哪条技术路线，Agentic RL Infra 最终要撑起四件事：

• 样本生产（Rollout）：环境交互 + 模型推理生成轨迹。这条链路决定数据吞吐量和多样性。
• 训练（Learn）：拿轨迹做策略梯度更新，核心是 PPO 全流程（旧策略概率计算、GAE、裁剪、KL 约束）。
• 经验存储（Memory）：轨迹在哪里放、怎么存、怎么采样，决定数据管线的稳定性和可追溯性。
• 评估分析（Eval）：训练过程中持续跟踪策略表现，及时发现 reward hacking、分布漂移、任务退化。

简单类比：整个系统像一个火锅店流水线。环境是备菜间，不停准备各种食材；rollout 是传菜口，把做好的菜送出来；训练是后厨炒菜，根据菜品反馈调整配方；经验存储是冷库，食材要保鲜、要分门别类，出问题还得能查到是哪批采购的。冷库设计得不好，后厨再厉害也做不出稳定的菜。

2. 训练与采样拓扑：同步、异步与半解耦

2.1 同步 PPO：简单可靠的起点

同步 PPO 是最容易理解的架构。有一组 actor 并行收集经验，收集完一个 batch 后，把经验统一交给 learner 做多轮梯度更新。更新完的新参数再广播给所有 actor，开始下一轮收集。

优点是实现简单、调试直观。经验全都是新策略采的，on-policy 性质好，梯度噪声小，训练曲线干净。对于 rollout 速度很快的任务（比如游戏模拟器、简单控制问题），同步架构完全够用，甚至是最优解。

但 Agentic RL 里，一次完整 rollout 可能要模型推理几十次，而且环境本身慢（比如要等代码执行结果、要等网页加载）。同步等待的代价非常高：要么 actor 数量巨大才能填满 learner 的胃口，要么 learner 大量时间在空转等数据。我在一个代码生成任务里做过对比，同步架构下 GPU 利用率只有 40% 上下，大部分时间都耗在等待长轨迹回传。

2.2 异步解耦：IMPALA 路线的现代变体

异步架构的核心是让 actor 和 learner 各跑各的。actor 拿到的是历史版本的策略参数，采集完一条轨迹就直接推进 learner 的训练队列，不等更新。Learner 持续从队列里面取数据，每取一批就更新一次 weights，再把新 weights 定期广播回去。

这个思路在 IMPALA 上已经被验证过了。它最大的优势是数据吞吐拉满，actor 永远不用等 learner，learner 也不缺数据。代价是 actor 手上的策略经常是过期的，训练数据有一部分是 off-policy 的，所以要做重要性校正（V-trace 或类似机制），否则梯度偏得厉害。

现代 Agentic RL 的异步方案大部分是 IMPALA 的变形，但做了不少调整。比如不再追求逐条样本接入，而是把同一个 batch 的轨迹攒齐再交；或者干脆采用“批次化异步”——actor 组之间并行采集，一组采完就交给 learner，但 learner 保证只用一个 batch 的数据做固定轮数的更新。这种方式在吞吐和 on-policy 性质之间拿了一个平衡，也是我见过比较多团队最终采用的形态。

2.3 大规模异步 PPO 的参数设计

如果你的任务是多智能体协同、长周期任务、或者策略本身特别大，同步和纯异步都可能不够，这时候需要把训练拆成更细的阶段。

我自己实践下来比较稳的组合是：Learner 单卡或少量卡做梯度更新，Rollout 由多个 actor 组并行承担，每个 actor 组内部再分环境并行和推理并行两层。关键参数上，值得注意几个：

• Batch size：一个训练 batch 里包含的样本数或者 token 数。语境化任务按 token 数算比按样本数算更直观，因为每条轨迹长度差异太大。
• 更新轮数（epochs）：一个 batch 被 learner 重复使用的次数。控制在 2~4 轮比较常见，太多容易 overfit 到老样本。
• 参数广播周期：新 weights 多久推给 actor 一次。推得太勤，集群通信开销大；推得太少，off-policy 偏置变大。实践中可以设定为 learner 更新 N 次之后广播一次，或者每隔固定时间广播。
• 经验队列深度：队列里最大积压多少条轨迹。积压太多意味着 learner 在消费很旧的数据，累积校正误差变大；积压太少又可能在训练高峰打满 learner 时让 actor 阻塞。通常设上限并配合丢弃策略。

一个真实的参考：某模拟任务里，我用 16 个 actor 组、每个组 32 个环境并发，Learner 上 4 卡训练，队列深度设成 200 条轨迹，参数广播每 10 个更新周期一次。整体吞吐比同步方案翻了差不多三倍，训练曲线没有明显变差。

3. 样本生产：环境交互与 Rollout 工程化

3.1 环境并行的两种层次

Agentic RL 的环境层次差异很大，但工程上基本可以分成两类。

一类是轻量文本/逻辑环境，比如代码执行沙箱、API 调用模拟、网页任务仿真。这类环境不需要 GPU，瓶颈在 CPU 和 IO，所以可以开几千个并发进程或者线程跑。另一个是重量级物理仿真环境，比如机器人操作仿真、自动驾驶仿真环境，通常一个环境就要占一个 GPU 甚至多卡，并行规模就小得多，需要把环境切分到不同 Node 上调度，并且在 rollout 之前先做资源预留。

对于轻量环境，工程上的关键是把环境并发和模型推理解耦。环境进程持续批量推进状态，把观测打包推到推理服务；推理服务返回动作，再填回环境。你可以用消息队列做缓冲，也可以直接用 Ray 这种带对象存储的任务提交框架。如果是 C++/Unity 写的高性能模拟环境，还得注意 Python 侧 GIL 锁，尽量把批量环境步进封装成向量化调用。

3.2 策略推理大规模生成：吞吐优先于延迟

Agentic RL 的 rollout 有一个特点：同一时刻需要生成大量不同上下文的 token，但是单条请求的响应时间并不需要特别快。这和在线聊天服务完全相反，所以推理引擎的调度策略要调整。

目前主流做法是把 vLLM 这类连续批处理引擎接到 rollout 链路里。状态 context 积累到一定数量后，一次性送给推理引擎，引擎内部做 continuous batching，在吞吐和显存之间动态平衡。为了让吞吐最大化，可以适当调大 batch size、开长 prompt 的 prefix cache，但必须留出 KV Cache 的余量，不然长轨迹生成到一半直接 OOM，很影响体验。

还需要控制推理引擎的采样参数稳定。同一批 rollout 里，temperature、top_p、repetition penalty 这些参数必须全程一致，任何一个环境步进的代码对参数做了不一样的覆盖，产生的数据分布就变了。我见过一次排查了很久的诡异问题，结果是一个环境副本里的采样 temperature 被默认成了 0，导致它产出的轨迹全是贪心解码，训练曲线立刻变得异常平滑。

3.3 长轨迹组装与工具调用状态管理

Agentic 任务的轨迹不是简单的一串 token，它中间会有很多结构化环节：用户指令、模型思考、工具调用参数、工具返回结果、模型再决定下一步。这些环节在存进经验池之前，要统一组装成标准格式，并且打上明确的阶段标记。

一个比较常用的做法是：每条 rollout 记录按 turn 和 step 划分，每个 step 保存完整的 prompt 版本、模型输出版本、工具输出、奖励信号，以及这一 step 的时间戳和采样随机种子。后面做训练数据切分、奖励重算、消融分析时，这些信息全都用得上。

另外，长轨迹往往超出模型上下文窗口，需要做裁剪和摘要。裁剪策略要考虑的是：直接截断早期上下文可能让模型忽略任务关键信息，而摘要又可能引入分布外内容。稳妥一点的做法是把轨迹切分成多个重叠窗口，分别计算各自的优势估计，再聚合成最终监督信号。这样不仅解决了上下文长度限制，还天然增加了有效样本数量。

4. 经验管线与存储架构

4.1 内存优先的 Replay Buffer 设计

传统 RL 的 replay buffer 是一个容量限制下的经验集合，一次训练批量从里面均匀采样。Agentic RL 阶段，我们通常不需要太复杂的优先级采样，因为 rollout 本身已经是策略交互的结果，轨迹质量相对均匀。但是在稀疏奖励任务里，能拿到非零奖励的轨迹占比极低，这时候就有必要给少数正样本更高的采样权重。

实现上，可以用双缓冲结构：一个“热”缓冲保存最近几轮 rollout 的高质量经验，另一个“冷”缓冲保存历史轨迹，训练时按比例混合采样。热缓冲比例高一些，可以稳定策略梯度；冷缓冲保留一部分，防止策略遗忘早先学会的能力。这个思路尤其适合奖励函数不稳定或者多任务切换频繁的场景。

4.2 分布式对象存储与列式格式

当轨迹规模大起来之后，单机内存就装不下了。主流路线是把经验写入分布式对象存储，格式上优先用列式存储比如 Arrow 或 Parquet。

为什么用列式而不直接存 JSON？因为轨迹里大量字段是序列化的 token id、logprob、reward、mask，这些数据按列存储压缩率高、读取时可以按需加载某一列，做观测分析时不用把整条轨迹都拉出来。训练流水线里常见的操作是扫描所有轨迹的 reward 列，算均值和方差，再抽取 logprob 列算 ratio，这恰恰是列式存储最擅长的事。

Ray Object Store 是目前和训练框架粘合最平滑的选择，它能在分布式内存里直接共享 Arrow 表格，部分读取时不需要序列化拷贝。如果团队的数据栈已经用了 Spark 或 Dask，也可以直接落成 Parquet 文件用数据湖管起来。

4.3 血缘追踪：模型、环境、奖励版本一个都不能少

Agentic RL 的经验数据异常混乱，问题定位靠猜是很痛苦的事。所以经验管线里从第一天起就要记录血缘信息，我的标准是每条经验至少要挂这几个版本号：

• 策略模型版本：是哪个 checkpoint 采出来的。
• 环境版本：环境逻辑是否有改动。
• Prompt 模板版本：指令和格式化方式是否一致。
• 奖励函数版本：如果中间调过奖励权重，要能定位到具体版本。
• 数据 schema 版本：字段含义和类型变化时要有自描述能力。

有了这些信息，当训练曲线出现突变时，才能在几分钟内锁定到是“哪个环境组件更新了”还是“哪次 prompt 改动导致了分布偏移”。没有血缘追踪，整条流水线就是一个黑盒，排查效率极其低下。

4.4 轨迹切分、Padding 与 Mask 实践

训练时不能直接把一条几千步的长轨迹塞进一个 batch。常规做法是切成固定长度的 segment，比如 1024 或 2048 个 token 一段。每条 segment 要计算对应的 advantage 和 return，并在切分点截断 GAE 传播，避免跨段的信息泄漏。

Padding 的地方特别容易出低级错误。我见过不少团队在 padding token 上算了 loss，导致训练曲线一开始还行，后面越训越差。正确做法是所有 padding 位置在 loss 计算时都用 mask 屏蔽掉，同时 attention mask 也要跟着处理。如果模型用的是 chat template，还要注意特殊 token 的位置，很多框架对 chat template 的处理方式不同，切分时格外小心。

5. 推理服务与长上下文管理

5.1 推理引擎选型：vLLM 之外的几种选择

Agentic RL 的推理引擎选型，本质上是在吞吐、延迟、功能丰富度之间做取舍。目前主流的三种：

• 以 vLLM 为代表的通用型引擎：兼容性好，原生支持 PagedAttention 和连续批处理，社区活跃，适合大多数 Agentic 任务。缺点是某些版本的稳定性还有提升空间，遇到极端长序列时容易出幺蛾子。
• TensorRT-LLM 这类编译优化引擎：吞吐极致，适合把模型固定成特定 shape 和精度，但改动模型结构或者采样逻辑成本高，灵活性差一些，适合已经稳定的生产链路。
• 自研推理服务：当任务场景特别极端（比如要求超长上下文、强定制化采样）时，团队会基于某个开源引擎做二次开发，把 rollout 逻辑直接嵌入推理循环。成本高，但能获得最佳控制力。

我给大多数团队的默认建议是先用 vLLM 类方案跑通，把数据管线和训练流程验证好，再根据瓶颈决定要不要上编译优化引擎。

5.2 Prefix Cache 与共享提示词

Agentic 任务里经常有很长的公共前缀，通常是系统提示词和任务说明。如果每个环境 step 都把这些前缀和完整历史拼接起来重新计算一遍 prefill，推理消耗会大得惊人。

Prefix Cache 的核心思路是：相同前缀的 KV Cache 可以直接复用，只计算增量部分。对于共享系统提示词或者固定任务描述的场景，这个优化能把 tokens-per-second 提升好几倍。

不过这里要提醒一句：Prefix Cache 的正确性依赖前缀严格一致。一旦你在某个 step 往前缀里插入了一段环境返回结果，而另一个 step 没有插入，缓存就失效了，甚至可能因为匹配错位产生隐性错误。实现时要对缓存 key 做严格的前缀 hash 校验，不能只比较开头几个 token 就复用。

5.3 长上下文轨迹的增量 Prefill 与分段处理

长轨迹还有一个麻烦：环境返回内容多、模型还要输出思考过程，上下文窗口很容易被打满。常见方案有两个。

一个是增量 Prefill：每次只处理新增加的那部分 token，不需要重新计算整个序列的注意力。这和 Prefix Cache 配合很好，适合对话式多轮环境。但要注意数值精度问题，增量计算和全量重算的浮点误差会导致输出不完全一致，这个在强化学习的经验一致性检查上可能变成问题。

另一个是分段处理：把长上下文拆成若干窗口，模型只在当前窗口内做决策，窗口之间的信息通过摘要传递。这个方法能绕过长度上限，但如果摘要写得不好，模型会丢失关键信息，训练出来的策略时好时坏。我倾向于先用增量 Prefill，必要时再做分段裁剪，不要一上来就设计太复杂的摘要机制。

5.4 推理引擎的随机种子与数值一致性

这是 Agentic RL Infra 里最容易被忽视、也最容易踩坑的点。推理引擎为了产量，经常会在内部做算子融合、张量并行、分块计算，相同输入可能得到不同输出。如果采样种子管理不当，试验无法复现；如果不同 actor 用的推理精度不一样（比如一个用 FP16、一个用 BF16），它们产出的轨迹分布就有细微差别，混合在一起训练时梯度会变得很怪。

我自己会在 rollout 服务的配置里固定随机种子，并且要求推理引擎报告实际使用的精度和采样参数。训练回放和分析时，能用保存下来的 logprob 和 token 直接重放，就不要依赖重新推理。

6. 框架选型与工具链对照

6.1 面向 LLM 的 RL 框架：OpenRLHF 与 veRL 类

如果你要做的是 LLM 智能体微调，也就是把一个大模型训得更符合某个任务目标，那直接基于 OpenRLHF、veRL 这类框架起步是最快的。它们会把 rollout、经验缓存、PPO 更新、模型调度都做成开箱即用，而且默认支持大规模分布式训练。

这类框架的优势是省事，缺点是定制空间相对有限。一旦你的环境交互特别复杂，比如每步都要做代码编译结果校验、或者要和外部工具做双向通信，就可能要自己改造 rollout 循环。另外，它们对超长轨迹优化程度差异较大，选型之前最好先用自己的任务跑一个完整小规模验证。

6.2 通用分布式 RL：Ray 生态与 RLlib

如果你的任务是机器人控制、通信博弈、或者多个智能体协同，传统 RL 的问题定义更贴切，RLlib 这类通用框架还是值得考虑的。Ray 提供了从任务调度、对象存储到超参调优的整套工具，RLlib 则封装了多种算法和多级并行模板。

说实话，RLlib 有学习曲线，而且文档里那些例子看起来简单，一上生产环境就各种调度问题。但它有两个不可替代的优点：一是环境抽象丰富，二是分布式资源管理做得细，特别适合同时跑大量小型环境并行的情况。如果你的 rollout 服务、训练服务都要在同一个集群里共存，Ray 的亲和性调度比裸 Kubernetes 好使。

6.3 轻量与教学：CleanRL 与 Tianshou

有时候你只是想验证一个新想法，不想维护一套重型基础设施。CleanRL 和 Tianshou 这类轻量框架就很合适。CleanRL 的优势是代码极简、单一文件，适合读源码理解 PPO 细节；Tianshou 则提供了一个更完整的实现库，兼顾易用性和扩展性。

轻量框架上生产环境的路径一般是：先用它们跑通算法和任务验证，等确定要长期投入了，再往重型框架迁移。迁移时正好把经验管线、血缘追踪这些基础设施一起补上。

6.4 怎么选：一张对照表

我整理了一个主观但实用的选型对照表，供参考：

6.5 集群资源调度的三个注意点

最后聊一下集群调度。Agentic RL 的负载混合度很高：learner 要 GPU，rollout 里的环境并行要 CPU/内存，推理服务要 GPU。如果调度器只按“一个任务给多少卡”来分配，很容易出现某个节点 CPU 打满而 GPU 空闲，或者反过来。

比较好的做法是把资源请求细化到资源维度：环境并行组申请 CPU 和内存，推理服务申请 GPU 和显存，learner 申请高带宽 GPU 组。Karay 或 Kubernetes 的自定义资源模型都支持这种细粒度调度。别忘了给推理服务留足 KV Cache 相关显存，否则高并发下容易 OOM。

7. 常见问题与排查记录

7.1 训练曲线很漂亮，评估却不理想

这是 Agentic RL 最常见也最隐蔽的问题。训练时 reward 一路走高，一放到新的测试集上就拉胯。我排查过这种案例，最后发现是训练环境的随机性不够，agent 被“背答案”背出来了。

基础设施层面的解决方法是：在 rollout 链路中强制注入环境扰动，比如改变初始条件、随机化工具返回结果、打乱示例顺序。同时在评估流程里维护一个 hold-out 环境集，这个环境集在训练过程中不参与任何参数更新，定期用它做策略快照评估。如果训练 reward 和 hold-out reward 出现明显 gap，立刻刹车检查。

7.2 经验池里混入了旧格式数据

异步系统里最容易发生的一个事故：环境组件灰度升级期间，新版环境产出的轨迹和旧版轨迹混在同一个缓冲队列里。前者有新的字段，后者没有，训练代码一旦没做 schema 校验，直接读字段就崩了。

有两个工程措施必须做。一是给经验定义明确的 schema 版本号，写入时自动校验，不匹配的直接丢弃或者走单独通道。二是升级环境时先切一个小比例流量，确认新格式持续稳定产出一段时间后，再切全部流量，不要一口气全量上线。

7.3 推理服务 OOM 与显存治理

长轨迹生成时，KV Cache 会随序列增长累积，加上连续批处理的动态调度，显存很容易被瞬间打满。常见的现象是训练跑了大半天都很稳，某一次批量处理里遇到一批超长轨迹，直接把推理引擎挤崩。

处理上，我建议给推理服务设置两层保护。第一层是动态调整最大 batch size，根据当前平均序列长度自动缩小；第二层是预设硬性最大上下文长度，超过长度直接截断或者转分段处理，宁可损失一部分轨迹数据也不能让服务崩掉。还有一个小技巧：把长 prompt 和短 prompt 放在不同 batch 里，避免长短差异过大导致显存利用率不均衡。

7.4 训练卡死与心跳超时

分布式训练里卡死问题太常见了，尤其是同步 PPO 的等待逻辑。某个 actor 进程因为环境问题挂了，learner 还在死等它提交数据，整个训练就卡在那里，日志也没报错。

所有负责等待的组件都应该配心跳和超时机制。Actor 上报心跳的间隔要远小于 learner 判断超时的阈值；一旦超过阈值，就把这个 actor 从队列里摘除，重新拉起新实例，并补偿一条警告指标。另外，数据队列要设置最大等待时长，超过时长后 learner 可以选择小批量更新或者跳过，不要一味阻塞。

7.5 常见问题速查表

7.6 可观测性指标的最小集

Agentic RL 的可观测性比传统训练系统要求更高，因为环境、推理、训练三个子系统互相耦合。我建议基础设施上线第一天就采集这些指标：

• Rollout 侧：轨迹产生速率（条/秒）、平均轨迹长度、每步推理耗时、环境步进耗时、采样参数分布。
• 训练侧：PPO loss 各分量、KL 散度、explained variance、梯度范数、更新吞吐。
• 系统侧：显存利用率、推理引擎队列深度、经验缓冲积压量、参数广播延迟。

这些指标覆盖了整条链路，任何一侧出问题都能快速定位。采集之后要按模型版本、环境版本做维度切分，否则多个并行实验会互相污染视图。

单说一个我踩过的坑：刚开始我只关注了训练 loss 和 reward，完全没监控经验缓冲积压量。结果某个 actor 组挂了，积压量一路降到零，learner 开始反复消费重复数据，训练曲线还在稳步上升，其实模型早就开始原地踏步了。后来把积压量加进监控大屏，这类问题一眼就能看出来。

8. 我的一点实操体会

做了这么多 Agentic RL 基础设施的改造，最深的感受是：这条技术路线没有银弹，每条路线都是在吞吐、一致性、调试复杂度之间做权衡。同步方案简单可控但吞吐受限；异步方案吞吐高但一致性难管；用成熟框架上手快但定制空间小；全自研灵活但周期长。你可以把不同路线拼起来用，比如推理引擎选 vLLM 类，经验管线自研，训练内核基于开源框架改，这样往往能拿到最大收益。

最后再分享一个建议：从第一天起就把血缘追踪和指标监控建好，哪怕前期觉得麻烦。Agentic RL 的调试难度不在于算法复杂，而在于数据链路太长，问题出现时根本不知道该怀疑模型、环境、数据还是引擎。有了完整的血缘和监控，排查问题就是在几个仪表盘里翻一翻的事；没有它们，就只能像无头苍蝇一样改参数重跑，一晚上搭进去十几个小时未必有结论。先搭基础设施，再调算法，这个顺序不要反。