一文了解Agentic RL领域最新进展
今年Agentic的概念特别火,本质上就是让一个LLM能做到边想边搜边做,不对的话就自己反思再边想边搜边做,一直到任务完成开始。从去年开始我们就有在做training-free的各种Agentic的技术(像Agentic Rag等等),这几天有空就稍微总结了一下相关的工作,本文是对Agentic Rl领域的文献总结,读者阅读完全文会对Agentic RL领域有所了解,希望能对大家未来研究工作有所启发。
Search-o1: Agentic Search-Enhanced Large Reasoning Models
2023,2024年的大家的范式都是来了一个query, 有很多模块去理解这个意图,然后做一个比较好的plan,然后按照这个plan每一步去执行(可以是single-agent也可以是multi-agent的范式),然后有一个agent去把前面每一步的answer做一个聚合。这篇虽然不是做RL的,但是主要是提出了这种用一个LLM自主检索增强生成机制(Agentic RAG )机制,在当时应该还是算比较新的。
具体来说,Search-o1在推理过程中,模型会生成特殊token template <|begin_search_query|> 和 <|end_search_query|> 来包裹的搜索的query。当检测到 <|end_search_query|> 时,LLM会暂停推理过程,提取搜索查询,并调用检索函数 Search 获取相关文档。检索到的文档被放到到推理链中,并用特殊符号 <|begin_search_result|> 和 <|end_search_result|> 包裹,使模型能够利用外部知识继续推理。
另外还有一个Reason-in-Documents 模块,该模块独立于主推理链运行,对检索到的文档进行深入分析。基于当前的搜索查询、之前的推理步骤和检索到的文档内容,生成一个中间推理序列,用于分析检索到的文档。根据中间推理序列,生成提炼后的知识,并将其注入到推理链中,从而保持推理的连贯性,而不是直接把所有检索到的内容直接放到上下文里面(一方面token爆炸,另外一方面LLM也容易抓不到重点被噪声带偏)
Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning
到这篇文章开始大家就开始把Search-o1这种范式训练进模型里面了
Search-R1支持多轮检索和推理,通过特殊token template <|search|> 和 <|/search|> 触发搜索,<|information|> 和 <|/information|> 包含检索到的内容,<|think|> 和 <|/think|>包含推理过程,<|answer|> 和 <|/answer|> 包含最终答案。通过这样的轨迹来训练模型拥有这种Agentic的能力,掌握什么时候该搜,什么时候该想,什么时候该回答用户的问题。训练算法上尝试了PPO和GRPO,通过实验发现GRPO 收敛快,但训练后期performance会突然掉下来;PPO 虽然收敛慢,但更稳定,最终performance更高;奖励计算上这篇文章直接暴力的用结果奖励,即看最后答案是对还是不对。
另外这篇文章也提到了后面很多文章都follow的一个trick,叫Retrieved Token Masking,即我们算Loss的时候,对网上检索到的内容,即<|information|> 和 <|/information|> 这里面是不能算Loss的,如果这部分也算loss模型容易混乱,这个也很make sense,就是只优化模型自己的行为。
ToRL: Scaling Tool-Integrated RL
前面的论文都是教会LLM边搜边想,即LLM的工具都只有搜索,这篇开始加入了计算的Tool(python):
具体实现上面,在ToRL的 rollout 过程中当检测到代码终止标识符(output)时,系统暂停文本生成,提取对应的代码块执行,并将执行结果以
```output\nOBSERVATION\n```\n
的格式插入到上下文中,其中 OBSERVATION 为执行结果。之后系统继续生成后续的推理,直到LLM给出最终答案或继续产生代码。
这篇文章也提出了一些trick:
- Tool Call Frequency Control: 这块主要是说因为我们要去执行这些代码的时候,GPU肯定是停下来等执行结果的,那么如果这个过程LLM一直在调用工具整个训练就会比较低效,因此为了保持相关高效的训练效率,引入了一个超参数C,表示每次响应生成允许的最大工具调用次数。一旦超过此阈值,系统将忽略进一步的代码执行请求(只有代码 没有执行结果),迫使模型切换到纯文本推理模式。
- Error Message Processing: 有时候我们代码执行也会失败,失败往往堆栈会很长,如果都加进去上下文就会太长了,因此为了减少上下文长度并仅保留相关的错误信息,只提取最后一行错误消息(例如,NameError: name 'a' is not defined)。
- Sandbox Output Masking: 这块和Search-R1类似,算loss的时候,代码执行的结果都不算,即屏蔽了OBSERVATION输出。
奖励计算上面,从结果来说正确答案获得1的奖励,错误答案获得-1的奖励。此外如果生成的代码执行是报错的,会减少-0.5的奖励。
ToolRL: Reward is All Tool Learning Needs
这篇文章主要在Tool use这样对Agent很重要的场景下做了很多RL的实验,主要的结论有下面几个:
- LLM进行推理的时候,并不是轨迹越长效果就越好,而且过长的奖励可能会降低性能。
- 更细粒度的奖励分解可实现更稳定、更有效的学习,让过程更加可控
- 类似课程学习,比较动态奖励尺度有助于模型从学习简单行为平稳过渡到学习复杂行为。
这篇文章的奖励分为两个部分,一个是格式奖励,例如检查输出中是否包含 <|think|>、<|tool_call|>、<|response|> 等特殊 token,并且它们的顺序是否正确。另外一个就是正确性奖励,目的是检查模型在具体工具调用上的「语义/参数/值」层面的准确性。包括三个子方面:每个工具名称匹配(tool name matching)、工具里面参数名称匹配(parameter name matching)、参数值匹配(parameter content/value matching)。这篇文章的奖励和Search R1直接反过来了,几乎完全舍弃了最终答案奖励,只用格式 + 工具正确性奖励 来驱动整个 RL 训练。
Acting Less is Reasoning More! Teaching Model to Act Efficiently
这篇工作提出在模型带有调用外部工具能力的场景下,仅仅优化“最终答案是否正确”是不够的。因为如果模型不受限制,往往会频繁调用工具——这不仅增加了计算/时间成本,还可能导致模型过度依赖工具、削弱自身的内在推理能力。因此,文章设计了一个新的优化目标:模型在保证答案正确性的前提下,尽可能减少工具调用次数。这样,既有“做对”又强调“用少”的双重要求。文章将这种优化方式称为 “工具生产率”(tool productivity):即正确答案数 / 工具调用次数,类似ToRL讲的Tool Call Frequency Control。
奖励设计上,若答案错误则为 0,工具效率部分则在答案正确时才发挥作用。具体来说,当模型用了 m 次工具调用,而当前问题/模型估计最少需要 n 次调用时,r_tool会根据m和n用像余弦或正弦函数进行衰减设计,使得当𝑚=𝑛时奖励最高(约为 1),而调用次数过多或在某些变式中调用次数为 0 而预期不是 0 时,则给出较低奖励。
R1-Searcher: Incentivizing the Search Capability in LLMs via Reinforcement Learning
这篇论文提出了一种两阶段的Agentic RL训练框架,核心思想是让模型先学会主动检索,再学会基于检索结果作答。整个过程围绕“如何奖励模型正确地使用外部工具”来做的。
Stage 1:鼓励模型学会检索
第一阶段采用 Retrieve Reward 和 Format Reward 两个信号,重点不在答案正确性,而在于让模型学会用检索工具完成任务。
- Retrieve Reward:只要模型在生成过程中调用了外部检索(调用次数 ≥ 1),就能获得奖励。目标是激励模型主动发起搜索查询,而不是凭记忆直接回答。
- Format Reward:通过格式规范来约束模型的输出结构,防止生成混乱内容。判断标准包括:
- 思考过程与最终答案分别封装在 <|think|>...<|/think|> 与 <|answer|>...<|/answer|> 中;
- <|answer|> 标签中只能出现最终简短答案;
- 检索查询必须封装在 <|begin_of_query|>...<|/end_of_query|> 中,且不能绕过检索直接产出文档。
阶段一的奖励为两者之和,核心目的是——让模型学会“思考→发起检索→组织格式”这一完整流程。
Stage 2:让模型学会正确利用检索
第二阶段转向任务准确性,采用 Answer Reward + Format Reward 作为奖励信号。这时模型不仅要调用检索,还要根据检索到的内容作出准确回答。最终reward同样是两者相加。
Group-in-Group Policy Optimization for LLM Agent Training
在做agentic rl的training的时候,我们常面对这样一个难题:虽然可以对整条轨迹(episode)打一个最终奖励,但那种端到端的奖励信号往往很稀疏、回报延迟长、训练效率低下。为了解决这一点,GiGPO 提出了双层优势估计结构:
宏观层面(trajectory-level):将多个完整轨迹划为组,计算各组之间的“宏相对优势”(macro relative advantage),以反映哪条轨迹整体表现更好。
微观层面(step-level):引入“锚状态”(anchor state)分组机制:回溯查找在不同轨迹中反复出现的环境状态(即找到同样一个状态下在不同轨迹中选了不同action的那些anchor state, 找的过程可精确匹配,也可语义匹配),然后将处于相同锚状态下所采取的动作归为一组。基于该组,计算“微相对优势”(micro relative advantage),即仅在这一锚状态对应的动作 token 上计算损失(loss),从而让训练算法能够更精准地辨识“哪些具体步骤对最终结果贡献最大”。
最终,GiGPO 将宏观优势与微观优势融合(如加权和形式),既考虑了整条轨迹的成功与否,也兼顾了轨迹中关键步骤的贡献,从而在无需额外 critic 模型、无额外 rollout 的条件下,实现了更细粒度的信用分配(credit assignment)机制,credit assignment也是agentic rl里面很重要的问题。
ARTIST:Agentic Reasoning and Tool Integration for LLMs via Reinforcement Learning
这篇文章会更强调把推理和工具调用一起联合优化:即模型不仅要“知道答案”,还要“知道何时、如何、调用哪个工具”以及“如何基于工具反馈调整推理路径”。
- Prompt Template:模型输出采用结构化模板,按照顺序输出 <|think|>…<|/think|>(内部推理)、 <|tool_name|>…<|/tool_name|>(工具/环境调用)、 <|output|>…<|/output|>(工具返回内容)、 <|answer|>…<|/answer|>(最终答案)这一流程。
- Roll-out Process:每一条 rollout 由上述结构化片段组成,策略模型在每一步选择是继续内部思考(think)还是执行工具调用(tool_name)或是根据返回输出调整(output),直至输出最终答案。工具可能是代码执行、API 调用、搜索、操作环境等。模型以这些实际交互输出作为反馈,整合入推理链内,从而实现 基于反馈的循环改进。
奖励设计:
- Answer Reward:当 <|answer|> 标签中的答案正确时给予正向奖励,确保模型目标聚焦于任务完成。
- Format Reward:鼓励模型遵循上述结构化模板流程。包括检查是否按照 “推理→工具调用→工具输出→答案” 的执行顺序及结构,确保可解析、可评估。
- Tool Execution Reward:衡量工具调用的“成功率”——即 Tool success / Tool total,鼓励模型生成语法正确、可执行、有效的工具查询。
Agent RL Scaling Law: Agent RL with Spontaneous Code Execution for Mathematical Problem Solving
这篇文章做了一些实验,有下面几个重要的结论
- 随着训练step的增加,自发调用代码执行的频率(code-usage freq)上升。
- 同时,平均响应长度(average response length)也随着训练进展变长。
- 最关键的是:训练步数越多,最终任务准确率(数学题解答正确率)也越高。
也就是说越多的训练投入代表越丰富的“练习量”,而模型也越倾向于“练习中学会使用工具(代码)”,从而解题更熟练、准确率更高。就像学生做题量多了 → 用工具(辅助思考、计算)越熟练 → 成绩更好。作者称之为 Agent RL Scaling Law:工具使用频率、响应长度、任务准确率这三者与训练规模(步数/预算)之间呈正相关的规律。
另外在训练中,为了提高稳定性与效率,作者引入了 重放缓冲区过滤(replay buffer filtering)机制:同一个prompt会生成多个响应(trajectories),将这些响应按最终答案的准确率分组,对于:
- 准确率 > 0.8 的组 → 过滤掉(学习梯度太小/已经“做得很好”)
- 准确率 < 0.2 的组 → 同样过滤(太差、可能噪音)
- 保留中间区间的组(0.2–0.8)供训练 → 优先学习“尚可但还有改进空间”的样本。
另一个 trick 是: 强制最大工具调用次数(Nₘₐₓ)。在每条 rollout 轨迹中,若执行代码调用次数超过 Nₘₐₓ,即插入一句 “工具调用次数已用尽。您无法再调用该工具。”,模型此后必须依靠自身推理完成答案。这个设计保证了模型不能无脑无限调用代码,而是学会在有限调用次数下,合理决策调用时机。
ARPO:Agentic Reinforced Policy Optimization
这篇文章可以理解为用熵来做细粒度的credit assignment,作者发现模型在每次工具调用后的 初始生成阶段 熵值会显著升高——这意味着外部工具反馈带来的是 高不确定性。
基于此,ARPO 的核心思路是在工具使用之后不确定性升高的环节投入更多探索(证明更可能给模型带有有价值的信息):结合 全局采样(global trajectory sampling) 与 熵驱动的局部采样(entropy-driven sub-sampling),当熵的变化超过某个阈值(认为这一步tool use比较关键,可以加大探索力度),就触发分支采样(branch sampling)。具体地,当分支路径数达到部分采样预算上限,或者所有路径提前终止,就停止分支;否则继续补充全局轨迹直到满足预算。
此外,在优势归属估计(Advantage Attribution Estimation)方面,ARPO 将一条 rollout 拆解为两类路径:
- 共享路径(Shared Path):在分支点之前,所有 rollout 的 token 是一致的 → 这些 token 的优势(advantage)应当一致。比如在问答任务中,提问与第一步推理阶段在分支前所有分支共享,则共享奖励信号。
- 分支路径(Branched Path):从分支点开始,rollout 之间走向不同、结果可能差异很大 → 自此之后应分别计算各自的优势。比如一个分支调用了 “搜索”,另一个调用了 “计算器” 结果不同,那奖励归属就不同。
在奖励函数设计上,ARPO 同时综合考虑答案正确性、工具调用格式正确性,以及多工具协作。如果模型在推理过程中调用了比如 <|search|>、<|python|> 等多种工具,并且保证最终答案正确、调用格式合规,就会额外获得奖励。
Chain‑of‑Agents: End‑to‑End Agent Foundation Models via Multi‑Agent Distillation and Agentic RL
这篇文章我觉得主要讲故事和选场景上取了巧,作者提出了一种新的范式——称为 Chain-of-Agents (CoA),其核心思想是:用一个LLM来模拟多 agent 系统的角色协作流程,而不是在外部搭建多个独立 agent 通过 prompt/workflow 协调。具体来说,他们先通过 “多 agent 知识蒸馏(multi-agent distillation)” 从已有的多 agent 系统(包含角色扮演、工具调用、观察反馈等)生成轨迹,再用这些轨迹对模型做SFT,最后在可验证的 agentic 任务上做 RL 优化。
在奖励设计上,除了正常的最后结果的奖励也有:
- 对于 Web agent 任务,他们放弃了传统的 F1、EM 等指标,因为在开放域场景下这些指标容易失效。取而代之的是LLM-as-Judge」机制:用 Qwen‑2.5‑72B‑Instruct 来判断模型输出是否与标准答案语义匹配,结果为 0 或 1 二值奖励。
这样就使得 SFT 阶段先取得一个“角色协作流程”的冷启动,RL 阶段则优化模型在真实 agentic 执行中的效果(包括工具调用、角色切换、链式思考、验证、自反等)。
ASearcher:Beyond Ten Turns: Unlocking Long-Horizon Agentic Search with Large-Scale Asynchronous RL
现在主流的 online rl训练数据轮数都少于10轮,训练数据质量也不高 经常出现理解不了不确定性的问题,网页信息无法精确提取以及会被误导答案干扰(实验了search R1和Search o1都不行)。所以他的核心有两个
- 一个是做了一个更难的数据集:用一个数据合成的agent 在一些qa问题中 既注入有关的上下文确保正确性 又进行题目模糊化增加理解的难度 增加难度
- 提出并实现了一个大规模、异步训练引擎,使得 agent 能够在“长‐回合”搜索中训练,而不是局限于 ≤10 轮调用。具体而言,他们允许每条轨迹更长(数十轮工具调用,以及极大的输出token数)并通过“完全异步”收集轨迹并训练,从而显著提升训练效率。
当然和标准的agentic rl流程不同,agent上专门多了一个总结网页内容的环节,这个和Search-R1一开始那个reasoning-in-document类似
Atom-Searcher: Enhancing Agentic Deep Research via Fine-Grained Atomic Thought Reward
作者觉得之前的文章奖励太稀疏 — 传统做法主要在最终答案正确与否上打分(outcome-based reward),导致中间过程几乎没有信号,优化效率低下。另外之前的 “Think”太粗糙/太笼统 — 在很多 agentic 系统中,模型只是被要求 “思考(think)” 然后做动作,但并没有具体引导去做「反思 (reflection)」「验证 (verification)」「规划 (planning)」等细粒度的思维步骤。论文认为这限制了 reasoning 的效率和可解释性。
为了解决这两点,作者提出了两个核心思路:
- Atomic Thought(原子思维)范式:将一个较大的 <|think|> 模块细分为多个功能上明确的子单元(Atomic Thoughts),比如 <|Plan|>, <|Reflection|>, <|Verification|> 等。这样模型在 rollout 过程中不仅“思考”,而是以更结构化、更可监督的方式「思考」。
- 过程 + 结果混合奖励+动态调度(这个和Agent RL Scaling Law那篇文章的结论对应了):除了继续使用最终答案的 outcome reward,作者设计了一个专门的 Reasoning Reward Model (RRM) 来对这些 Atomic Thought 单元打分,从而得到 Atomic Thought Reward (ATR),作为过程级别的信号。在训练初期,因为模型尚未擅长产生正确答案,这时 ATR(过程奖励)权重大,鼓励模型先“学会正确思考路径”。随着训练推进,最终答案的重要性提升,模型的思考路径能力渐强,过程奖励的权重逐渐下降,这样可以转向强调结果。
另外可能觉得template比较多,所以也是先sft再rl的方式进行训练。
DEEP THINK WITH CONFIDENCE
这篇文章的核心观点在于:在多路径推理/思考过程中,不应将所有轨迹一视同仁,而应依据置信度区分其“质量”。基于此,作者提出了数种置信度指标,并在实验中发现“最弱环节”相关的两个指标效果最优。具体来说:
- Bottom-10% Group Confidence:对每条推理轨迹,先用滑动窗口(例如每 n token 一个窗口)计算每个窗口的 token-置信度平均值,得到一组窗口置信度;然后取其中最低 10 % 窗口的平均值,作为该轨迹的底部置信度指标。这个指标试图反映“推理途中最薄弱那部分”的平均置信度。
- Lowest Group Confidence:同样基于滑动窗口,对轨迹中所有窗口取最低一个窗口的置信度,作为该轨迹的最差段落的置信度指标。即关注“最糟糕的一段”。
有了这两个指标之后,在思考模式上,作者分别探讨了两种场景:
- 在线模式(online thinking):在推理过程中实时监控置信度信号,一旦路径落入低置信度状态,可以及时中止、剔除或者调整;最终,当多条路径都输出答案时,每条轨迹的输出置信度(例如使用 Bottom-10% Confidence)会参与投票加权,对高置信度路径赋予更大权重。
- 离线模式(offline thinking):先生成多条完整轨迹,然后再依据置信度进行筛选或加权,只让高置信度的轨迹参与最终的答案决定。
整个方法是 training-free, inference-time only 的,和self-evlove相关的工作,如SE-Agent(SE-Agent: Self-Evolution Trajectory Optimization in Multi-Step Reasoning with LLM-Based Agents)一样都可以产生高质量的轨迹来做agentic rl的训练
Towards General Agentic Intelligence via Environment Scaling
当然现在还有一个趋势,就是Environment Scaling,核心在于:要让 Agent在真实工具调用、功能调用场景中变强,仅靠模型规模或海量轨迹并不足,关键是“环境的多样性与可扩展性”。当前很多相关训练方法存在两类瓶颈:一类是“环境规模小”、交互场景单一(比如固定工具集);另一类是“环境构造人工干预重”、数据难以真实/可信。因此:
- 现在不同任务使用的工具不同,具接口返回格式各异,很难统一度量模型的“推理与环境交互”能力。因此作者把工具调用抽象为底层的「数据库读/写」操作(read/write on underlying database)——即:每个 API/工具 可以看成对某个数据库状态的查询或变更。比如调用一个获取信息的API,如 get_weather(city),就是Read 操作;调用一个修改环境的API,如 book_flight(city),就是Write 操作。这就让agent 的外部交互变得结构化、可组合、可扩展。
- LLM Agent 要面对的任务非常多样:旅行规划、医疗诊断、金融分析、代码修复、文件管理……每个任务下的工具集(toolset)差异很大。因此作者认为要将工具按照「领域(domain)」分组,每个领域用一个数据库 schema 表示,然后自动构造工具序列、初始化数据库状态、组合用户意图,从而生成多样、可自动化的环境场景。
这种方式降低了「人工交互+场景设计」的负担,使得环境可规模化生成、内容多样。
两阶段 Agent 训练:
- 阶段 1:在通用领域中训练 agent 具备基础的工具调用能力(general tool-calling skills)。
- 阶段 2:进一步在特定垂直领域(domain-specific context)中训练,使其在特定环境下表现更贴近实际。