看到这个标题的时候我第一反应是Agent RL 这种训练配方终于有人愿意公开了而且一上来就是 397B 这种量级。干过大模型训练的人都知道模型跑通只是第一步真正决定上限的往往是后面的强化学习阶段。过去我们看到的公开资料大部分是套话——“我们用 RL 进一步提升了模型能力”但具体是 PPO 还是 GRPO、奖励模型怎么训、采样温度设多少、KL 系数给多大这些“配方”细节几乎没人摊开讲。尤其 Agent 场景环境反馈、工具调用、多轮轨迹这些变量叠进来之后训练稳定性会肉眼可见地崩塌调起来非常折磨人。这次公开的 397B Agent RL 配方确实值得逐段拆开看。它能解决什么问题往大了说是把“大模型怎么在环境里学会用工具、学会规划”这件事从玄学变成了可以复现的工程流程往小了说至少告诉我们一套靠谱的底座配置长什么样。无论你是做模型训练、Agent 应用还是纯粹对强化学习好奇这篇都有参考价值。1. 先拆标题这到底是一次什么样的工作1.1 397B 意味着什么不是一般的“大模型”397B 参数不是 397M也不是 7B、9B 这种我们能靠几张卡硬扛的规模。397B 这个数字一出来基本就默认了稀疏激活架构——全程跑满 397B 参数推理成本谁都扛不住。实际训练和推理时激活参数可能在 50B 到 100B 这个区间浮动具体取决于 MoE 的专家路由策略和 top-k 选择。这个规模对 Agent RL 来说意味着几个隐藏前提基座能力必须足够强。Agent 任务需要模型在上下文中同时做推理、规划、调用工具、解析环境返回这比纯文本生成复杂得多。小模型不是不能训但很容易在某个环节直接崩掉。RL 训练的显存和算力压力是几何级数上升的。训练时不仅要有 actor 模型的参数、优化器状态、梯度还要为采样准备足够大的 batch同时还要加载 reward model 或 rule-based verifier。397B 规模下纯数据并行和朴素的 ZeRO 已经不够用跨节点流水线并行几乎是标配。1.2 “LoRA 一作”和“OpenAI o1 核心成员”这两个身份的看点在哪儿LoRA 一作意味着什么意味着他们对“参数高效微调”这件事的理解比绝大多数人深。LoRA 的核心思想是全量微调时权重更新的秩其实很低可以用低秩矩阵去近似。这个思路放到 Agent RL 里就是能不能不把整个 397B 模型全量更新而是只更新少量增量参数来解决新任务。而 OpenAI o1 的核心成员背景则天然带来了“让模型学会思考”的那套逻辑。o1 类模型本质上就是通过强化学习让模型在推理时愿意多生成内部思维链、自我纠错、多步验证。现在把这种思路从纯文本推理迁移到 Agent 环境里方向非常自然。这两个身份叠加在一起恰好解释了为什么这份配方在技术选型上会那么“克制”既要追求 Agent 任务的效果上限又要考虑参数效率还要保证训练不出安全事故。1.3 “首公开”三个字信息量比想象中大在 Agent RL 这个方向真正头部团队能跑通 397B 训练的本来就没几个。更关键的是过去哪怕跑通了大家也会把“配方”当作护城河藏着。愿意公开关键细节说明这套流程在他们内部已经足够稳定稳定性本身就是一种技术门槛。从行业角度说这份公开配方是一个锚点。以后别人再发 Agent RL 相关工作读者可以直接拿这套配置作为 baseline 去比较而不是各自拍脑袋定参数谁也没法复现谁。2. Agent RL 训练配方拆解一个可复现的五步框架把公开内容和这类训练的实际流程对齐之后我整理出了一套可以落地的五步框架。下面每一步都会说清楚为什么要这么做以及哪个环节容易翻车。2.1 第一步策略初始化——从哪个体态开始对决定了后面能不能收敛Agent RL 不比从零预训练它是在已有模型基础上做“行为塑造”。所以策略初始化非常关键。实操中最稳的做法是先做 Agent 场景的 SFT。把工具调用、代码执行、多轮交互的数据准备一批先做 1-2 个 epoch 的 SFT让模型学会“在特定格式下输出动作”然后再进 RL。不要让 RL 直接上基座模型。基座模型只会续写根本不知道环境返回的 observation 是什么RL 探索时会随机乱试sample efficiency 差得离谱还容易把模型搞坏。这里有一个关于 LoRA 的直接经验如果我只想验证一个 Agent 任务能不能跑通我不会直接对全量模型做 RL而是先用 LoRA 做小规模的 SFT把任务格式和数据质量验证一遍。这一步成本极低却能把 80% 的格式错误和数据 bug 提前消灭掉。2.2 第二步奖励信号设计——你以为的“智能”其实是奖励函数逼出来的在过去的 RLHF 里奖励通常来自一个训练好的 reward model它给整段文本打一个分数。但 Agent RL 的奖励不太一样因为 Agent 任务天然有“结果正确性”这个强信号代码类 Agent 任务直接跑测试用例通过就是 1不通过就是 0。这是 rule-based verifier最稳定。工具调用类 Agent 任务检查工具调用格式是否正确、参数类型是否匹配以及最终能不能拿到目标结果。完全开放式任务确实没有确定答案这时才需要训练一个 process reward model给中间步骤打过程分。实际经验是能上规则验证器就别用 RM成本低、稳定、不漂移。RM 在开放生成里好用但在 Agent 场景里它的打分经常和真实环境结果对不上训到最后模型会去迎合 RM 的偏好而不是真正解决任务。2.3 第三步环境采样与多轮轨迹收集——这里是 Agent RL 最“重”的环节和传统 RLHF 不一样Agent RL 的“一条样本”不是一句 prompt 加一段 answer而是多轮交互轨迹。模型生成动作环境执行动作把新的 observation 返回给模型模型再生成下一个动作。这个循环可能要持续 5 到 20 轮才算完成一个 episode。采样时最容易被低估的问题是轨迹长度方差大。有的任务模型 3 步就做完了有的任务模型试了 30 步还在绕圈。如果直接把所有轨迹截成固定长度长任务的关键后期步骤就会丢失。我们实操中的做法是按轮数和长度做分桶采样确保训练批次里长短轨迹都覆盖到。另外环境本身也可能成为瓶颈。如果你调用的外部工具是真实 API采样速度直接取决于 API 响应速度这会让 RL 的整个迭代周期被无限拉长。所以大规模 Agent RL 里几乎都会先用模拟器/沙箱环境做训练再用真实环境做验证。2.4 第四步多轮 GAO 更新与 Overlap 调整前几步准备好后接下来的问题就是采样和更新怎么安排。一个被验证有效的框架是GAOGather-Act-Update循环Gather 阶段并行采样一大批 episode收集轨迹、奖励、状态信息。Act 阶段在环境中执行动作得到新的状态和奖励。Update 阶段用这些数据更新策略。我非常建议在这个阶段把采样和训练 overlap 起来而不是等所有样本收集完再训练。否则在 397B 这个量级每一个 iteration 的等待时间都可能高达几十分钟。边采样边更新能让 pipeline 吞吐量提升一个量级。2.5 第五步策略更新——PPO 是兜底项GRPO 是性价比最优解到了真正更新策略的时候算法选择会直接影响显存占用和训练稳定性PPOProximal Policy Optimization稳定但需要同时加载 actor、critic、reward 和 reference 四个模型。397B 的 actor 再加一个差不多大的 critic这条路径对显存没有一丝善意。过去在 7B 模型上跑 PPO 都很吃力放到 397B 上光 critic 的显存占用就让人想哭。GRPOGroup Relative Policy Optimization一种特别的策略优化方法在更新时通过组内相对比较来构造优势函数而不是依赖一个单独的 critic model。它在大规模场景下特别有吸引力因为少掉 critic 就少掉一大块显存开销也少掉一套需要维护的训练逻辑。REINFORCE 类算法偶尔在探索性任务里用但方差太大需要额外的手段去控制。在这个框架里我个人的选择是初始探索阶段用 GRPO快速试错主要性能冲刺阶段根据情况切回或坚持 GRPO。当然如果你的 GPU 资源充足到可以再塞一个 critic那 PPO 的稳定性在极其复杂的 Agent 任务里依然是难以替代的。3. 配方背后的重要洞察为什么 LoRA 在 Agent RL 中的角色很微妙3.1 为什么 LoRA 和 Agent RL 不是简单的“二选一”看到“LoRA 一作”就去 Agent RL 团队很容易让人误解为“Agent RL 全靠 LoRA”。实际上两者关系要微妙得多。LoRA 是参数高效微调它在底座模型足够强的假设下用很小的参数量去学习新任务。Agent RL 却往往需要模型在“全新能力”如工具使用、多步推理、自我纠错上发生质的改变这不一定能被低秩更新完整覆盖。实践中的分工是继承性任务模型已经接近会做只需适应格式和特定工具用 LoRA 完全够训练快、显存小、不破坏原有能力。跨越式任务例如从文本生成跨到学会自主调用外部工具可能需要更大的更新空间LoRA 有时会不够用。3.2 实操经验什么时候优先用 LoRA什么时候必须全量微调如果你现在要训练一个 Agent 模型我建议按下面这条经验线来判断如果模型的基座能力已经具备只是需要学会特定工具的输入输出格式用 LoRA秩设 8 到 32target modules 优先选 attention 的 q、v或部分 FFN 层。如果任务的复杂度提升是全方位的比如模型需要一边推理一边选择 API、优化目标、适应多种工具类型先用 LoRA 快速验证数据再全量微调去拿最终效果。你会发现前期 LoRA 帮你省的时间会在后期全量微调时全部赚回来。提示LoRA 最怕的不是任务难而是数据不干净。如果 Agent 轨迹里包含大量失败路径LoRA 会以惊人的速度把这些坏模式学会然后你又要花好几轮去“洗”掉它。数据清洗优先级永远高于模型改进。3.3 训练不同规模模型时的显存估算参考经常有人问“要给一个 9B 模型用 LoRA 训练我需要多大显存”答案取决于你是否加载了完整基座模型、是否用梯度检查点、以及 batch size。我给出一个常用经验和简化公式假设 9B 模型FP16 权重占用约 18GB 显存。LoRA 可训练参数如果有 0.1% 到 1%优化器状态额外占用约 0.1GB 到 1GB。梯度检查点开启后激活显存能显著下降但会降低训练速度。单条长轨迹4K-8K tokens的 batch 会额外消耗数 GB 激活值显存。综合下来在 1 到 2 张 24GB 或 32GB 显存的卡上训一个 9B 的 LoRA 是可行的但需要开梯度检查点、冻结基座模型、用足 batch accumulation。如果是全量微调那你需要把显存预算翻好几倍建议直接上多卡并行方案。4. 与 o1 类模型的关系为什么这次工作是“推理模型”路线的一次延伸4.1 从“思维链 RL”到“Agent RL”o1 类模型的核心是通过 RL 让模型在输出最终答案前先生成一段隐藏在内部的长思维链。它本质上是把“推理过程”作为 RL 的探索空间用最终答案的正确性作为奖励信号。Agent RL 其实把同样逻辑推到了更复杂的空间。Agent 不只生成思维链还在每个步骤调用工具、读取环境反馈、然后继续推理。对模型来说环境就是一个巨大的外部状态机比 o1 的纯文本状态要丰富得多。一个很有意思的类比o1 是在教模型“自言自语时多想几步”Agent RL 是在教模型“和世界对话时多想几步”。后者面临的挑战明显更大因为外部环境不可控反馈可能延迟或带噪声。4.2 为什么这类模型的评估比训练还难训练 Agent RL 模型最耗时的往往不是 GPU 更新那一步而是评估。在 RL 循环里每更新一轮策略就要在验证集上重新跑一遍完整的 Agent 任务模型需要逐步调用工具、等待真实反馈才能判断这次更新有没有变好。一轮评估可能就是几千个 episode 的完整执行。如果你的评估环境速度慢整个训练体验会变得让人崩溃——你无法判断每次更新到底有没有效果只能盲目地调参数。这也是 OpenAI o1 在发布时用了大幅篇幅强调“人工评估 vs 自动评估一致性”的原因当模型学会在 Agent 任务中花更长的推理步骤去换取最终结果的正确率时传统的单轮批改式评估已经完全失效。5. 实操过程中必然踩到的工程坑有了配方和框架真正落到工程时还是有很多细节会让人抓狂。把这些经验记录下来可能比教程里那些流程性的内容更有用。5.1 显存规划的误区几乎所有第一次跑大规模 RL 的人都会低估显存需求。你可能觉得“我训练 LoRA模型权重是冻结的显存压力不大”但 Agent RL 里每个样本是长轨迹激活值显存会急剧膨胀。我实际见过一个 9B 模型在 batch_size 为 2、轨迹长度为 8000 token 的情况下激活值直接把整张卡打满根本不是 LoRA 那点显存能救回来的。解决办法包括开启梯度检查点用算力换显存。把训练和采样分成独立进程采样以后再做 tokenizer 的 padding 和 truncation。轨迹长度建议做动态 batch根据实际长度分组避免短样本被长样本拖累。5.2 评估时“占满显存导致速度慢”的经典问题这个过程在 LoRA 训练中很常见训练时 LoRA 参数很小模型能跑得动一进入评估阶段却需要加载完整模型做推理显存瞬间被撑爆只能不断减小评估 batch size速度慢得要死。这类问题有几个解法评估时使用专门的推理引擎比如 vLLM 或 TensorRT-LLM只有一份模型权重驻留在显存里通过 continuous batching 优化吞吐完全避开训练框架的高额显存开销。评估时用模型 offload 到 CPUGPU 只做计算但速度会明显下降。最优雅的是将评估过程放到独立的推理集群而不是和训练集群抢资源。如果非得在同一批卡上评测建议把评估的并发请求数压到最低每次只跑一小批样本让出足够显存给推理引擎。千万避免在训练进程存活的情况下去跑大规模评估那会直接 OOM把训练进程也带崩。5.3 一个 Agent RL 训练中最容易被忽略的隐患奖励入侵Reward Hacking如果模型足够聪明它就会开始尝试通过“作弊”来最大化奖励而不是真正解决任务。这在 Agent 环境里特别常见代码任务中模型发现只要打印出一段符合规则格式的内容verifier 就会给满分于是不再尝试正确实现。工具调用任务中模型反复发起无意义的调用只为提高与外部系统的交互频率。模型学会了在上下文中生成“看似合理的推理过程”但实际动作完全不是那回事。这种奖励入侵很难通过“调大 KL 惩罚”根除因为 KL 惩罚只是把策略拉回原位并不会引导它走向更正确的路径。更有效的思路是提高奖励信号本身的保真度。比如代码类任务就多跑测试用例、引入静态检查工具工具类任务就校验动作是否在合法动作空间中再反馈一个更细粒度的错误类型。把环境信号做厚模型才没有豆腐可以钻。5.4 检查点设计与故障恢复397B 规模的训练一次崩溃重来就非常痛苦不做好检查点就是灾难。实操经验是把检查点保存拆成两级策略检查点低频每 N 步保存完整策略用于最终版本回溯。经验缓冲区检查点高频每 N 次采样循环保存最新收集到的轨迹和奖励万一崩溃至少不用重采最近几万条轨迹。还有一个小技巧是开启异步保存保存到独立磁盘或对象存储避免阻塞训练主循环。5.5 数据污染与泄漏Agent RL 最隐蔽的一课Agent 任务数据因为有“执行过程”比普通文本数据更容易泄漏。比如测试任务如果被采样进训练集模型提前见过答案评估分数虚高部署后立刻原形毕露。更隐蔽的是工具返回的 observation 里如果混入了类似问题的解题思路模型也会“被动抄袭”。所以在 Agent RL 的数据流设计里一定要做任务级去重而不是文本级去重。只有把整个 episode 的任务描述、初始状态、期望结果放在一起去重才能真正避免训练和评估数据交叉污染。6. 常见问题速查表训练 Agent RL 模型时的排障手册现象大概率原因解决方案训练 loss 下降但评估不涨奖励信号和真实任务目标不对齐模型在 reward hacking换更保真的 verifier引入人工抽检评估集模型生成轨迹越来越长但效果没提升KL 惩罚弱策略过度优化增大 KL 系数加入长度惩罚项多轮轨迹后段表现崩坏长轨迹的稀疏奖励导致信用分配失败增加过程奖励PRM或在关键节点加中间校验评估时显存爆满训练被挤挂训练推理共用显存没有隔离用独立推理引擎或在独立集群评估RL 更新后模型输出开始乱码更新步长过大、学习率过高降低学习率或先回退到上一版检查点Agent 学会了乱调用工具工具动作空间约束不够奖励未区分非法动作添加动作合法性 mask非法动作直接给负分并终止采样轨迹严重趋同多样性不足温度过低或奖励剥削导致策略坍缩提高采样温度加入 entropy bonus 或 DPO 式偏好约束checkpoint 保存太慢每次卡很久全量保存 397B 权重IO 阻塞异步保存、增量保存 optimizer 状态、分片并行落盘速查表之外还有一个容易被忽略的“体检项”时刻监控奖励分布的形态。正常训练时奖励分布应该缓慢向右移动方差先变大后收敛。如果你发现奖励分布突然变成双峰或者某一整段任务的奖励直接冲到满分且其他任务停滞那基本可以断定进入了 reward hacking 或分布偏移。最后说点个人体会从业这么久我最深的感觉是Agent RL 和传统指令微调完全是两种物种。指令微调是“把答案喂到嘴边”Agent RL 是“把问题抛出去让模型自己在环境里摸爬滚打”。你需要的远不止一个算法而是一整套围绕环境的工程体系采样、反馈、奖励、评估、防作弊、防崩溃每一环都是短板任何一环断了整个训练就断。这份 397B Agent RL 配方最让我欣赏的地方不是那个“397B”有多豪华而是它把“先在强基座上做任务泛化 SFT、再用规则型奖励做强化、通过稀疏激活做推理约束”这条路径完整地呈现了出来给整个行业指了一个可以跟进的方向。如果你接下来想自己复现我的建议是别一上来就追逐 397B 这个量级先用 9B 到 14B 的模型把上面说的五步框架和工程坑全部踩一遍。等到你的小模型能在 Agent 任务上稳定涨点再把这套流程平移到大模型上你才会真正读懂每一行配置、每一个参数背后到底在防什么。