【强化学习】Hands-on Modern RL项目实践|Agentic RL与轨迹信用分配、工具调用与轨迹生成

📅 2026/8/22 22:50:34
【强化学习】Hands-on Modern RL项目实践|Agentic RL与轨迹信用分配、工具调用与轨迹生成
Agentic RL 深水区轨迹信用分配、工具调用与轨迹生成前言在上一篇文章里我们把 Agentic RL多轮强化学习的整体框架搭了起来状态如何随工具调用演化、动作空间如何从生成 token扩展到文本 工具调用、目标函数如何从单步奖励升级为整条轨迹的折扣回报。但形式化只是起点真正让这套框架能跑起来、训得动的是两块硬骨头信用分配Credit Assignment一条七八轮甚至十几轮的交互轨迹走到最后才知道成败那么中间每一步的功劳或过错该怎么算工具调用与轨迹生成当模型的动作真的会读写文件、执行代码、访问网页时训练系统要如何安全地生成、记录、复用这些轨迹本文就沿着这两条线把 Agentic RL 的工程与算法细节讲透。一、信用分配为什么在 Agentic RL 里格外难信用分配问题在传统 RL 中早已存在但到了 Agentic RL 这里难度明显被放大了原因主要有三点轨迹更长。一个 Code Agent 完成一次任务可能要经历 10~20 轮写代码 → 跑测试 → 报错 → 修改的循环远比单轮 LLM RL 里一次生成的长度长得多。轨迹越长最终奖励要回溯到的中间步骤就越多信号也就越稀薄。动作类型更多样。轨迹里不再只有生成 token这一种动作还夹杂着调用工具“执行代码”放弃当前方向、切换策略等异质动作。不同类型的动作很难放在同一把尺子上比较贡献大小——一次成功的工具调用和一次高质量的推理片段究竟谁的功劳更大并没有天然的答案。环境不确定性更强。同一个搜索 query不同时间段可能返回不同结果同一段代码在不同的运行环境下也可能表现不一致。这意味着同一个策略在不同的 rollout 里可能得到截然不同的结果给信用分配又叠加了一层噪声——分数的波动里有多少是策略本身的问题有多少是环境随机性造成的很难剥离干净。正因如此“最终结果失败了责任该分给哪一步”成了多轮交互 RL 里最核心也最棘手的问题。二、从 Token-Level 到 Turn-LevelMDP 的粒度之争2.1 直接套用单轮方法为什么会失灵最朴素的做法是直接把 GRPO 这类为单轮任务设计的组相对优势估计方法搬到多轮场景里业界称之为 M-GRPO 一类的直接改造。但这种拿来主义很快暴露出两个问题一旦一组采样里的轨迹全部失败组内相对优势会退化为零模型完全学不到任何有效信号标准的 PPO Critic 网络在面对每轮几百 token、总共十几轮的超长序列时价值估计的方差会急剧增大训练极不稳定。这也是为什么多篇后续工作都指出把 GRPO 直接套到多轮任务上普遍存在不稳定的问题。2.2 把 MDP 的粒度从 Token 提升到 Turn一条自然的改进思路是把决策单元从最细粒度的 token提升到更符合任务语义的回合Turn层面——每一轮完整的模型回复被当作一个宏观动作macro action状态则是截止到这一轮为止的完整上下文。围绕这个思路出现了几条并行的技术路线ArCHer采用分层强化学习框架在 turn 级别用 actor-critic 算法估计价值在 token 级别再用策略梯度做具体的文本生成优化相当于把决定要不要继续往这个方向走和具体怎么把这句话写好拆成了两层问题。Turn-PPO在turn-level 的 MDP 建模基础上把 PPO 中的优势估计从 token-level 转移到 turn-level实验发现这比继续使用 token-level 的 GRPO 更加稳定尤其是在需要长程推理的任务里。StarPO-sRAGEN 框架针对多轮 RL 训练不稳定的问题提出按比例做轨迹过滤trajectory filtering把那些质量过低、信号过于嘈杂的轨迹提前剔除从源头上减少噪声进入梯度更新。这条路线背后的共同直觉是与其强迫一个针对单轮任务设计的算法去硬啃多轮轨迹不如先把问题的决策粒度调整到与任务结构相匹配的层次。2.3 Step-Level Advantage 的三类来源把决策粒度从 token 提升到 turn解决的是用多大的单位做信用分配的问题但还有一个更进一步的问题没有回答同一个 turn / step 内部这一步的优势值到底是从哪里算出来的综合近两年围绕 Agentic RL 信用分配的研究Step-Level Advantage 的构造方式大体可以归为三类来源。来源一学习型 CriticCritic-Based / 价值函数估计最直接的思路是沿用 Actor-Critic 的老办法——训练一个价值函数Critic对每个中间状态估计其价值V(st)V(s_t)V(st​)再用类似 TD 误差或 GAE 的方式把这一步的即时奖励与未来预期结合起来算出该步的优势AtrtγV(st1)−V(st) A_t r_t \gamma V(s_{t1}) - V(s_t)At​rt​γV(st1​)−V(st​)ArCHer 正是这条路线的代表它在 turn 级别训练一个 Critic 来估计价值token 级别再用策略梯度做具体的生成优化形成turn 级 Critic token 级 Actor的分层结构。这类方法的好处是理论上最完备、能给出精确到每一步的价值估计代价是需要额外训练并维护一个 Critic 网络而 Critic 在面对每轮几百 token、总共十几轮的超长序列时价值估计本身的方差就会明显增大训练稳定性因此打了折扣——这也是 Turn-PPO 等工作反复强调turn 级 Critic 比 token 级 Critic 更稳的原因把 Critic 估计的对象从 token 提升到 turn能显著压低这部分方差。来源二Critic-Free 的组内锚点比较Group-Based / Anchor State Grouping第二类来源完全绕开了训练一个 Critic这件事转而利用组内采样本身的结构去做相对比较。GiGPOGroup-in-Group Policy Optimization是这条路线里最具代表性的方案——它在不引入额外 Critic 网络、不增加额外 rollout 开销的前提下把组相对优势估计做成了两层嵌套结构Episode 级外层对同一任务、同一初始状态下采样出的一组完整轨迹像标准 GRPO 一样依据整条轨迹的总回报计算宏观相对优势衡量这条轨迹整体上完成得怎么样。Step 级内层GiGPO 引入了一种Anchor State Grouping锚点状态分组机制——它会回溯性地找出多条轨迹中重复出现的环境状态比如因为绕圈子、重复访问同一个网页而反复回到的某个状态把从相同状态出发的不同动作聚成一组在这组内部计算局部的微观相对优势A^t(i)Aepisode(τ(i))w⋅Astep(at(i)) \hat{A}_t^{(i)} A_{\text{episode}}(\tau^{(i)}) w \cdot A_{\text{step}}(a_t^{(i)})A^t(i)​Aepisode​(τ(i))w⋅Astep​(at(i)​)其中AepisodeA_{\text{episode}}Aepisode​是外层的轨迹级优势AstepA_{\text{step}}Astep​是内层锚点分组内部算出的步骤级优势www控制两者的相对权重。这个设计的巧妙之处在于由于多条轨迹处在相同任务、相同初始条件下采样很多轨迹会因为无效动作或原地打转反复经过同一个状态——这些重逢的状态恰好为构建 step 级分组提供了天然的锚点既不需要额外训练一个价值函数也不需要多做一次 rollout。在 ALFWorld、WebShop 等长时程智能体基准上GiGPO 相比 GRPO 分别取得了超过 12% 和 9% 的提升。这类方法的局限也很直接锚点分组依赖状态被多次重复访问这一前提在搜索、开放式问答等状态空间连续、几乎不会精确重复的环境里精确的状态匹配会变得很脆弱分组可能找不到足够的锚点。来源三过程奖励模型 / 隐式步骤奖励Process Reward Model, 显式或隐式第三类来源不再依赖状态是否重复而是直接训练一个模型去对每一步单独打分——这正是我们在信用分配讨论之初就提到的PRMProcess Reward Model思路的延伸。标准的显式 PRM如 OpenAI 的 “Let’s Verify Step by Step”需要人类专家对每一步推理标注对/错/中立代价高昂在 Agentic RL 场景里这个思路被进一步扩展为AgentPRM——不仅评估推理步骤本身还要评估工具选择是否合理、查询构造是否精准、信息利用是否充分等智能体特有的行为维度。为了绕开昂贵的人工标注近期工作转向隐式过程奖励不显式训练一个独立的打分模型而是让策略模型自己在训练过程中隐式地学出一个步骤级奖励函数。比如通过多轮 DPO 目标交替优化一个隐式 PRM 与策略模型本身从轨迹偏好中反推出每一步的奖励信号再把这个隐式步骤奖励转换为 step-level advantage与 episode-level advantage 加权合并后用于策略更新——这种做法不需要额外的 rollout也不需要显式的步骤标签代价是需要更精细的目标函数设计来保证训练稳定。这类方法的优势是不依赖状态重复,理论上可以覆盖任意环境;局限则是过程奖励模型本身也是一种代理奖励——如果监督信号存在偏差,或者步骤粒度切得过细,反而可能引入更高的方差,甚至被模型利用(reward hacking)。2.4 三类来源的对照与选择来源是否需要额外训练 Critic/PRM是否依赖状态重复代表方法主要风险学习型 Critic价值函数估计是Critic 网络否ArCHer、Turn-PPO长序列下价值估计方差大Critic-Free 组内锚点比较否是GiGPO状态空间连续、难以重复访问的环境中失效过程奖励模型 / 隐式步骤奖励是显式或隐式 PRM否AgentPRM、隐式 PRM 方法标注/训练成本高或引入新的代理奖励偏差2.5 一张更完整的对照表结合上一节讨论的决策粒度token / turn / trajectory与这一节讨论的优势来源Critic / 组内比较 / 过程奖励可以把本章出现的方法统一放进一张表里方法决策粒度Advantage 来源核心思路直接套用 GRPOM-GRPOToken-level组内相对比较轨迹级组内相对比较但多轮下易不稳定ArCHerTurn-level外 Token-level内学习型 Critic分层 actor-criticTurn-PPOTurn-level学习型 Critic把 PPO 的优势估计迁移到 turn 粒度StarPO-sRAGENTrajectory-level 过滤组内相对比较轨迹级按比例过滤低质量轨迹GiGPOEpisode-level Step-level锚点分组Critic-Free 组内锚点比较组内再分组双层相对优势AgentPRM / 隐式 PRM 方法Step-level过程奖励模型显式/隐式单独训练或隐式学出步骤级奖励函数这几条路线并非互斥实践中往往需要结合具体任务的轨迹长度、动作异质性、环境噪声水平以及状态是否容易重复出现这一关键前提去挑一个最合适的信用分配粒度与优势来源——状态空间较小、容易重复如 ALFWorld、WebShop 一类的具身/GUI 环境时Critic-Free 的锚点分组性价比很高状态几乎不重复的开放式搜索、代码任务里学习型 Critic 或过程奖励模型往往是更稳妥的选择。三、轨迹的结构从线性序列到带状态的对话树理解了信用分配的算法思路还需要正视一个更底层的现实问题Agentic RL 的训练数据长得和普通 LLM RL 完全不一样。在普通 LLM RL比如第几章讨论的 GRPO 训练里一条样本本质上仍然接近一条线性序列prompt - completion - reward。哪怕真实系统里会额外记录 token ids、attention mask、response mask、old logprob、policy version 等字段结构上依然是一进一出。而 Agentic RL 的一条轨迹更像一棵带状态的对话树一个 episode 可能包含七八轮交互每一轮都包含模型输出、工具调用参数、工具返回结果、环境状态变化、以及步骤级奖励。以修复 Python bug为例——模型先读代码然后修改一版跑测试发现失败再改一版再跑测试直到通过——这整条链路里的每一步都需要被完整记录下来而不是只保留最后的成败。这种结构上的差异直接带来了存储系统设计上的三项额外能力需求按任务类型检索比如分析模型数学做得好但代码做得差这类跨任务的能力画像按步骤切片定位到具体是哪一步决策出了问题而不是只知道这条轨迹失败了;去重与过期处理同一个任务不需要重复训练而旧轨迹也可能因为环境本身发生变化比如网页内容更新而失效需要及时淘汰。在实际选型上规模不到一万条轨迹时用 JSON 文件配合 SQLite 就能满足需求规模到一万到一百万条的中等量级可以引入 Redis 做索引、S3 做数据存储超过百万条的规模则需要上分布式数据库如 MongoDB、DynamoDB。对于包含图片、音频的多模态 Agent轨迹里更合理的做法是只存储引用URL而非原始数据训练时按需下载让轨迹索引本身保持在 KB 级别的轻量状态。四、工具调用 RL 的三个工程细节轨迹结构变复杂之后训练系统在实现层面也必须跟着做出相应调整。这里挑三个最容易被忽视、但直接决定训练质量与工程可维护性的细节。4.1 Loss Mask模型不为它没写的内容负责一个常见的实现误区是把多轮轨迹里的所有 token 不加区分地纳入 loss 计算。但工具返回的内容搜索结果、代码执行输出根本不是模型生成的模型不应该为这部分内容的质量负责——模型需要学习的是何时调用什么工具、如何理解工具返回的结果而不是如何输出工具返回的内容。解决方式是引入Loss Mask模型自身生成的 token 标记为参与训练mask1工具返回的 token 标记为不参与训练mask0。在检索增强场景里这个思路也被称为Retrieved Token Masking只对模型自身生成的 token 计算梯度屏蔽外部工具返回的部分——因为搜索结果的质量不受模型控制不该因为搜索引擎返回了低质量内容就惩罚模型本身。4.2 环境接口解耦不同任务对接的工具环境千差万别搜索引擎、代码执行器、网页、游戏如果环境实现和 rollout/训练逻辑强耦合换一个工具环境就要连带改动训练代码维护成本会迅速失控。比较通用的实践,是把环境收敛为一个最小接口集合(例如只暴露reset/step/format_observation三个方法),让环境实现与训练逻辑完全解耦——换工具环境不需要动训练代码。这个原则听起来理所应当,但在实际项目中,环境与训练逻辑相互纠缠仍然是一个高频出现的工程债务来源。4.3 多模态上下文的跨轮保持在多轮对话里第一轮用户上传的图片到第三轮模型可能仍然需要看到它。这就要求训练系统在 Rollout 端维护类似image_data的结构在训练端维护对应的多模态输入表示并在每一轮交互中自动合并确保跨轮的多模态上下文不丢失。五、代码执行的安全边界沙箱隔离方案怎么选Agent 的核心能力之一就是执行代码这也是最大的安全隐患所在。训练过程中模型会尝试各种策略去获取更高分数——如果不加限制它完全可能生成删除文件、读取环境变量中密钥这类探索性但破坏性极强的动作。这些行为并非恶意只是模型在探索动作空间但后果可能是灾难性的一个正在运行的训练任务被破坏,文件系统被清空,训练数据丢失。因此,Agent 执行代码必须放在隔离环境(sandbox)里运行。隔离方案的选择需要在安全性、启动开销与资源利用率之间权衡,实践中主要有四种方案:subprocess 资源限制:最轻量的方案。通过 rlimit 限制 CPU 时间和内存、chroot 限制文件系统访问、unshare 限制网络命名空间。隔离强度有限(进程仍与宿主共享内核),但启动开销极低,适合早期原型验证阶段。Docker 容器:工业界最常用的方案,通过 Linux cgroups 和 namespace 提供文件系统、网络、资源的三重隔离,且拥有成熟的镜像生态。主要开销在于容器启动(约 100 毫秒),可以通过预热容器池来优化。MicroVM(如 Firecracker):提供内核级隔离——每个 VM 运行独立的精简内核,即使某个 VM 被攻破,也不会影响宿主机或其他 VM。启动延迟约 125 毫秒,与 Docker 相当,但安全性显著更高,适合训练中存在不可信代码执行的场景。WebAssembly(Wasm):通过 WASI 提供指令集级别的沙箱,代码编译为 Wasm 字节码后只能调用宿主显式导出的函数,无法访问文件系统或网络。启动延迟仅约 1 毫秒,但生态仍在发展中,并非所有 Python 包都能支持。无论选择哪种方案,网络访问都需要被严格控制。训练中的 Agent 不应直接访问外网——这既有安全风险,也会破坏可复现性(同一个 Agent 第二次执行相同任务时,搜索引擎返回的结果可能已经变化,导致训练轨迹无法复现)。对于确实需要联网的场景(比如 Web Agent),更合理的做法是通过代理做请求过滤和缓存,而不是简单粗暴地断网。六、轨迹生成与合成:以 Search-R1 为例串起全链条理论和工程细节讲了这么多,不妨用一个具体案例把它们串联起来。Search-R1是较早证明让 LLM 在 RL 训练中自主学会调用搜索引擎这条路线可行的开源工作,它恰好把本文以及上一篇文章提到的多个概念全部实际落地:RLVR 思想:Search-R1 的 reward 就是答案对不对这一纯粹的可验证信号,不需要额外训练 Reward Model。GRPO 优化:Search-R1 默认使用 GRPO,用组采样 相对比较替代了 PPO 里的 Critic 网络。Agent Loop 的具体实现:Search-R1 的 Rollout 过程,就是模型在推理和调用搜索工具之间反复交替的具体体现。ORM 的实际选择:Search-R1 只使用了 ORM(终态奖励),后续工作(如 Atom-Searcher、Web-Shepherd)在此基础上进一步引入了 PRM(过程奖励),试图把稀疏的终态信号补充为更稠密的过程反馈。Search-R1 展示的搜索引导推理(Search-guided Reasoning)是一个动态的、策略性的过程:模型先粗略搜一轮,发现线索后细化查询,再针对性搜第二轮——这不是靠提示词教出来的固定套路,而是模型通过试错和奖励信号自己摸索出的策略。在更复杂的 Deep Research 场景里,业界(如 Tongyi DeepResearch)进一步把训练拆成了两个阶段:Agentic Mid-training(在大规模合成的工具调用轨迹上做持续预训练,让模型提前熟悉工具调用的行为模式),以及Agentic Post-training(先用高质量合成轨迹做 SFT 冷启动,再用定制化 GRPO 在真实与模拟环境中做 on-policy RL,最后做模型合并)。这种先合成轨迹打地基、再上 RL 精调的两段式思路,也正是当前工业界训练复杂 Agent 的主流范式之一。沿着这条主线继续往前走,课程后续还安排了 DeepCoder 和 FinQA 这类具体实验室(lab),分别对应代码类和金融问答类工具调用场景的轨迹合成与 RL 训练实践,是把本文讲的理论和工程细节真正落到可运行代码上的最后一步。七、总结把这两篇文章的内容拼在一起看,Agentic RL 的技术全景大致可以归纳为一条清晰的链条:形式化框架(状态/动作/转移/奖励/目标函数)→信用分配的决策粒度(Token → Turn → Trajectory)→Step-Level Advantage 的三类来源(学习型 Critic / Critic-Free 组内锚点比较 / 过程奖励模型)→轨迹的组织与存储(从线性序列到带状态的对话树)→工具调用的工程实现(Loss Mask、环境解耦、沙箱隔离)→轨迹合成与真实案例(Search-R1、Deep Research 两阶段训练)。信用分配问题之所以重要,是因为它直接决定了模型能不能从一次失败或成功的长轨迹中学到正确的东西;而工具调用与轨迹生成的工程细节,则决定了这套算法能不能在真实、安全、可复现的环境里真正跑起来。这两块拼图合在一起,才是 Agentic RL 从论文公式走向工业级训练系统的完整图景。参考与延伸阅读:GiGPO(Feng et al., “Group-in-Group Policy Optimization for LLM Agent Training”, 2025);Turn-PPO(Li et al., “Turn-Level Advantage Estimation with PPO for Improved Multi-Turn RL in Agentic LLMs”, 2025);ArCHer(Zhou et al., 2024);RAGEN / StarPO-s(Wang et al., 2025);AgentPRM(Xi et al., 2025)与隐式过程奖励相关工作(如 iStar,“Agentic Reinforcement Learning with Implicit Step Rewards”);“Let’s Verify Step by Step”(Lightman et al., 2023);Search-R1(Jin et al., “Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning”);开源课程 Hands-on Modern RL(walkinglabs)中关于信用分配与 Agentic RL 基础设施的相关章节。