Hands-on Modern RL

Appearance

旧页：工具调用与 Agentic 工程（已并入 10.2） ​

这一页保留为旧链接入口。核心内容已经合并到 10.2 工具调用、轨迹合成与 Agentic 工程。下面保留原文，方便从旧链接进入的读者对照。

12.3 工具调用 RL：Web Agent 与 Code Agent ​

上一节我们拆解了多轮 RL 的信用分配问题——7 轮交互失败了，该怪谁。现在我们聚焦另一个关键问题：模型怎么学会"使用工具"？监督微调（SFT）可以教会模型"工具调用的 JSON 格式长什么样"，但教不会它"什么时候该调用工具、调哪个工具、怎么组合多个工具"。后者需要策略性的决策能力——而这正是 RL 擅长的。

为什么 RL 对工具调用至关重要？ ​

想象你在训练一个模型帮用户做数据分析。SFT 阶段你给它看了上千个"正确调用工具"的示例，模型学会了：

json
{ "tool": "sql_query", "query": "SELECT * FROM users WHERE age > 30" }

它学会了这个格式。但到了实际使用时，模型面临的是策略性的决策：

  • 用户问"我们的高端用户有多少"，模型需要决定：是直接查数据库？还是先搜索内部文档了解"高端用户"的定义？
  • 查完数据库后发现有 10 万条记录，模型需要决定：是进一步筛选？还是做聚合统计？
  • 聚合后发现数据异常，模型需要决定：是报告异常？还是尝试其他查询方式？

这些决策没有"标准答案"——不同的策略可能导致不同的结果，而 SFT 只能教模型模仿专家的轨迹，无法教它探索更优的策略。RL 的优势在于：你只需要告诉模型"最终结果对不对"，模型自己会通过试错学到"什么时候该用什么工具"。

SFTRL
学什么工具调用的语法格式何时调用、调哪个、如何组合
训练数据需要人工标注的工具调用轨迹只需要最终结果（成功/失败）作为 reward
泛化能力只能处理见过的工具组合能探索新的工具使用策略
错误恢复不会教模型从错误中恢复模型通过试错学会修复策略
代表工作Toolformer[1]ReTool、VERL-TOOL、ToolRL

核心方法 ​

ReTool：推理中调用工具[2] ​

ReTool（Reasoning with Tools）的思路是让模型在推理过程中自由地调用工具，而不是预先决定"什么时候调用"。模型在生成回答的过程中，随时可以"暂停"文本生成，调用一个工具（比如计算器或代码解释器），拿到结果后继续生成。

RL 的作用是优化"何时调用工具"的策略。模型可能发现：对于简单的算术题，直接口算比调用计算器更快；但对于复杂的数值计算，调用计算器更准确。这种"因地制宜"的策略，SFT 很难教会，RL 可以通过 reward 信号让模型自己摸索出来。

VERL-TOOL：跨领域工具调用[3] ​

VERL-TOOL 是一个跨领域的工具调用 RL 训练框架，覆盖数学推理、SQL 生成、Web 搜索、软件工程等多种场景。它的关键创新是统一的工具调用接口——不同领域的工具（计算器、数据库、搜索引擎）被抽象为统一的 RL 动作空间，可以用同一套 RL 算法训练。

ToolRL：工具作为 RL 动作[4] ​

ToolRL 将工具调用视为 RL 中的一个特殊动作，扩展策略的动作空间。标准 LLM 的动作空间是词汇表（几万个 token），ToolRL 在此基础上增加了"调用工具 A"、"调用工具 B"等动作。策略网络需要在"生成文本"和"调用工具"之间做出选择。

python
class ToolAugmentedPolicy(nn.Module):
    """工具增强的策略网络：在文本生成和工具调用之间做选择"""

    def __init__(self, base_model, tools):
        super().__init__()
        self.base_model = base_model  # 基座 LLM
        self.tools = tools             # 可用工具列表

    def forward(self, state):
        """
        给定当前状态（对话历史 + 工具返回结果），
        决定下一步是生成文本还是调用工具
        """
        # 基座模型输出 logits
        logits = self.base_model(state)

        # 检测特殊的"工具调用 token"
        # 如果模型选择了工具调用 token，则解析参数并执行
        if self._is_tool_call(logits):
            tool_name, tool_args = self._parse_tool_call(logits)
            return ToolAction(tool_name, tool_args)
        else:
            return TextAction(logits)  # 正常文本生成

奖励设计：场景决定 Reward ​

工具调用的 reward 不像偏好对齐那样主观——它可以根据客观信号来设计。这实际上就是第 8 章提到的 RLVR（Reinforcement Learning from Verifiable Rewards） 在 Agentic 场景的直接应用。

场景Reward 来源类型特殊考量
代码生成单元测试通过率连续（0-1）部分通过也有部分 reward
数学推理最终答案是否正确二元（0/1）中间步骤可用 PRM
Web 搜索是否找到正确答案二元 + 路径效率惩罚鼓励更少的搜索轮次
SQL 生成查询结果是否匹配预期二元 + 执行时间惩罚避免生成低效查询
数据分析分析结论是否正确且完整多维评分同时评估准确性和可读性

一个值得注意的模式：很多 Agentic 场景的 reward 都包含效率惩罚。这不只为了让模型更快，更因为每次工具调用都有成本（API 费用、延迟、资源消耗）。一个好的 Agent 不只是"能完成任务"，还要"高效地完成任务"。

形式化地，工具调用 RL 的总 reward 可以表示为：

Rtotal=Rtask−λefficiency⋅T−λformat⋅1(format error)R_{\text{total}} = R_{\text{task}} - \lambda_{\text{efficiency}} \cdot T - \lambda_{\text{format}} \cdot \mathbb{1}(\text{format error})

其中 RtaskR_{\text{task}} 是任务完成奖励（0 或 1），TT 是使用的交互轮数，λefficiency\lambda_{\text{efficiency}} 是效率惩罚系数，λformat\lambda_{\text{format}} 是格式错误惩罚。这个公式把"成功完成任务"和"高效完成任务"统一到了一个 reward 信号中。

python
def compute_agent_reward(task_success, num_turns, max_turns=10):
    """计算 Agentic RL 的综合 reward"""
    # 任务完成的基础 reward
    success_reward = 1.0 if task_success else 0.0

    # 效率惩罚：使用轮次越多，惩罚越大
    efficiency_penalty = -0.1 * (num_turns / max_turns)

    # 工具调用格式错误的额外惩罚
    # （如果模型生成了无法解析的工具调用）
    format_penalty = -0.5 if has_format_error else 0.0

    return success_reward + efficiency_penalty + format_penalty

Web Agent RL：教模型上网 ​

Web Agent 是 Agentic RL 最直观的应用之一：训练一个能够浏览网页、填写表单、搜索信息的智能体。这听起来简单，实现起来却充满了挑战。

动作空间。Web Agent 的动作不是"生成文本"，而是浏览器级别的操作：点击某个元素、在输入框中输入文字、滚动页面、导航到新 URL。每个动作都需要精确定位目标元素——这通常通过坐标（x, y）或 DOM 元素 ID 来实现。

状态空间。Web Agent 接收的状态通常是两部分：页面截图（视觉信息）和 DOM 树（结构信息）。截图提供了视觉布局，DOM 树提供了精确的元素定位。两者缺一不可——仅用截图很难精确点击小按钮，仅用 DOM 树又无法理解视觉布局。

奖励信号。Web Agent 的 reward 基于任务完成度。比如"在携程上预订一张明天北京到上海的机票"，reward 取决于：是否找到了正确的航班？是否成功填写了所有信息？是否提交了订单？

Web Agent RL 的主要挑战是状态空间的巨大规模和动态性。一个网页可能有上千个 DOM 元素，页面内容会动态加载，同一个网站在不同时间的布局可能不同。这意味着 Agent 需要强大的泛化能力——不能记住"某个按钮在屏幕左上角"，而是要理解"提交按钮通常长什么样"。

ReLook：用眼睛给网页打分[5] ​

现有的 Web Agent reward 主要依赖 DOM 结构匹配或任务完成度的二元判断。ReLook 引入了一种全新的 reward 来源——视觉反馈。它的工作流程是：Agent 生成网页代码 → 渲染成截图 → 用多模态 LLM 对截图进行视觉评分 → 将视觉评分作为 RL 的 reward 信号。这种"看到效果再打分"的方式，比纯文本 reward 更符合人类对"好网页"的判断——毕竟用户看到的是渲染后的页面，不是源代码。

Agent Workflow Memory：从经验中学习工作流[6] ​

Agent Workflow Memory（AWM）解决的是 Web Agent 的记忆问题。AWM 从 Agent 过去的成功经验中抽取可复用的工作流（workflow），并在未来的任务中主动提供相关的工作流来指导 Agent 的行动。比如，Agent 在多次购物任务中学到了"先搜索 → 加购物车 → 填写地址 → 支付"这个通用流程，AWM 就会把这个工作流存储起来，下次遇到类似的购物任务时自动激活。AWM 在 WebArena 和 Mind2Web 上的实验表明，这种"从经验中学习"的方式显著提升了 Agent 在新网站上的泛化能力。

Web-Shepherd：专为网页导航打造的 PRM[7] ​

上一节我们提到 Web-Shepherd 作为 PRM 在真实场景的落地案例。这里我们更详细地讨论它在 Web Agent 中的具体应用。传统的 Web Agent reward 只有"任务最终是否完成"这一个信号。Web-Shepherd 在每一步操作后都给出一个评分——"这次点击是不是对的？""这个表单填得对不对？"。它用结构化的检查清单（checklist）来引导评估，配合 4 万条标注数据训练出的专用 PRM，评估成本仅为 GPT-4o-mini 做判官的 1/10。这让 Web Agent 的训练可以用更密集的步骤级 reward 来替代稀疏的 episode 级 reward，训练效率和最终性能都大幅提升。

Code Agent RL：写代码、调试、迭代 ​

Code Agent RL 训练的是能够写代码、执行代码、阅读报错、修复代码的智能体。这比 Web Agent 更接近"真实程序员"的工作方式——不是一次性写出完美代码，而是通过"写 → 执行 → 报错 → 修复"的循环迭代来完成任务。

Code Agent 的 RL 训练有一个天然的优势：reward 非常明确。代码要么通过所有单元测试（reward = 1），要么不通过（reward < 1，按通过率给部分分）。这比 Web Agent 的"任务完成度"更容易量化和自动化。

python
def code_agent_reward(generated_code, test_cases):
    """Code Agent 的 reward：基于测试通过率"""
    results = []
    for test_input, expected_output in test_cases:
        try:
            # 在沙箱中执行生成的代码
            actual_output = execute_in_sandbox(generated_code, test_input)
            results.append(actual_output == expected_output)
        except Exception:
            results.append(False)  # 执行异常 = 测试不通过

    # 基础 reward = 通过率
    pass_rate = sum(results) / len(results)

    # 额外奖励：代码简洁性（越短越好，但有最低要求）
    # 额外惩罚：执行时间过长
    return pass_rate

Code Agent RL 的一个关键发现来自 ICML 2025 的研究：单步 reward 可以有效引导多轮代码生成。也就是说，你不需要对每一轮的"写代码 → 执行 → 报错 → 修复"过程都给 reward——只需要给最终代码是否通过测试这一个信号，模型就能学会"写出正确的代码 → 修复错误"的完整策略。这和上一节的 ORM 思路一致——如果 reward 足够明确，稀疏信号也能工作。

rStar2-Agent：14B 打败 671B 的实战标杆[8] ​

如果说前面的讨论还在讲"理论上的可行性"，那么 rStar2-Agent 就是最有力的实战证明。微软训练的这个 14B 参数模型，在 64 张 AMD MI300X GPU 上用仅 510 步 RL 训练，就在 AIME24 数学竞赛上达到了 80.6% 的准确率——超越了 671B 参数的 DeepSeek-R1。

rStar2-Agent 的核心创新是 GRPO-RoC（Group Relative Policy Optimization with Resampling on Correct）算法。传统 GRPO 在组内采样后只做一次比较，而 GRPO-RoC 会对正确的轨迹做重采样——如果模型在某条轨迹上成功了，就在这条成功轨迹的基础上继续探索，看能不能找到更好的路径。这比单纯的组内比较提供了更精细的学习信号。

这个结果有两个重要 insight：(1) Agentic RL 的训练效率远超预期——510 步 RL 训练就能超越 40 倍大的模型，说明 RL 的数据效率在大模型上非常高；(2) 小模型 + RL 可以打败大模型 + SFT，关键在于 RL 让模型学会了"如何有效地使用工具和推理策略"，而不仅仅是模仿专家行为。

Agnostics：任何语言都能做代码 RL[9] ​

现有的 Code Agent RL 几乎都默认用 Python 做代码执行和验证。Agnostics 打破了这个限制：通过一个语言无关的代码执行验证器，它可以对任何编程语言做 RL 训练。验证器的工作流很简单：从模型输出中提取代码 → 编译（如果需要）→ 执行 → 对比结果。无论代码是 Python、Rust、Go 还是 SQL，验证器都一视同仁。这意味着你可以用同一套 RL 框架，训练一个"什么语言都会写"的代码模型——而不需要为每种语言单独设计训练管线。代码、数据和配置均已开源。

不执行也能评分：Agentic Code Reasoning[10] ​

到目前为止，所有 Code Agent RL 的 reward 都依赖代码执行——运行代码，看结果对不对。但 Meta 的研究表明，还有一种更优雅的方式：让模型在不执行代码的情况下推理出代码的行为。这种方法叫"半形式化推理"（Semi-Formal Reasoning）：模型需要显式列出前提、追踪每条执行路径、写出形式化的结论——就像数学证明一样，不能跳步，不能含糊。

这种方法在真实世界的补丁验证上达到了 93% 的准确率。它的核心价值在于：不需要沙箱，不需要执行环境，没有安全风险。你可以把它理解为 Code Agent RL 的"低成本替代方案"——如果 reward 信号只需要"这段代码大概是对的还是错的"，半形式化推理就够了；如果需要精确的输出匹配，还是得老老实实执行代码。

代码自举的 Scaling Law[11] ​

第 8 章讨论了 RL 的 Scaling Law——更多训练步数，更强推理能力。Agentic RL 领域也有自己的 Scaling Law。ZeroTIR 方法让模型在没有监督示例的情况下，自发学会生成和执行代码来辅助推理。研究者发现了一个可预测的关系：训练步数与代码执行频率、最终准确率之间存在幂律关系。这意味着你可以在训练早期就预测出最终模型的表现——如果训练了 100 步后代码执行频率还在上升，说明模型还在持续学习，可以继续训练；如果频率已经趋于平稳，说明学习接近饱和，可以提前停止。

这个发现对工程实践非常重要：它给了你一个免费的训练进度指示器——不需要跑完整个训练，只需监控代码执行频率就能判断"该不该继续训"。ZeroTIR 被 NeurIPS 2025 收录。

思考题：Web Agent 和 Code Agent 的 reward 设计有什么本质区别？这对 RL 训练策略有什么影响？

Web Agent 的 reward 通常是二元且不可分的——要么任务完成了，要么没完成，中间状态很难量化。这导致 reward 信号极度稀疏，训练难度大。

Code Agent 的 reward 是可分的——10 个单元测试过了 7 个，reward = 0.7。这种连续的 reward 信号让训练更容易：即使代码不完全正确，模型也能得到"方向对了"的信号。这就是为什么 Code Agent RL 的进展比 Web Agent RL 快得多。

对训练策略的影响是：Web Agent RL 更需要 PRM（每步评估）来提供密集信号，而 Code Agent RL 用 ORM（只看最终测试结果）就能取得不错的效果。

搜索工具 RL：SearchR1 与搜索增强推理 ​

前面讨论的 Web Agent 和 Code Agent 各有侧重，但有一个工具场景特别重要、也特别有挑战性：搜索引擎。搜索和计算器、数据库等工具不同——搜索返回的结果是开放式的、非结构化的，而且"好"的搜索策略极度依赖上下文。问"GRPO 和 PPO 的区别"时，模型不需要搜索；但问"2025 年诺贝尔物理学奖得主是谁"时，模型必须搜索——内部知识可能已经过时。

2025 年，SearchR1[12]（Jin et al.）开创性地将 RL 引入搜索工具训练，让模型自主学习何时搜索、搜什么、怎么用搜索结果。随后 ReSearch[13]、ToRL[14] 等工作从不同角度推进了这一方向。

为什么 prompting 不够？ ​

在 SearchR1 之前，主流做法是通过 prompting 教模型"你可以在推理过程中调用搜索引擎"。ReAct[15]、Self-RAG[16] 等方法都走这条路。但 prompting 有三个根本局限：

搜索时机判断无法穷举。 你可以在 prompt 里写"当知识不确定时搜索"，但什么是"不确定"？模型可能对过时信息充满信心（不知道自己不知道），也可能对显而易见的常识过度搜索。

搜索 query 的策略性无法模仿。 面对"比较三个量子计算平台的最新性能数据"这种任务，搜索策略需要根据前一次搜索的结果动态调整——第一次搜"quantum computing benchmark 2025"发现太宽泛，第二次改为"IBM quantum advantage vs Google Sycamore 2025"。这种自适应查询生成是策略学习问题，不是语言建模问题。

多轮搜索的长期优化。 一个复杂任务可能需要 5-10 次搜索。过早停止 = 信息不足，过晚停止 = 资源浪费。这个 trade-off 恰恰是 RL 的用武之地。

SearchR1 的 MDP 建模 ​

SearchR1 将搜索增强推理建模为一个特殊的 MDP：

  • 状态 sts_t：当前推理上下文（已生成文本 + 之前的搜索结果）
  • 动作 ata_t：两类——(1) 继续生成 token，(2) 生成搜索 query 并触发搜索（通过 <search>...</search> 标记）
  • 转移：搜索动作触发搜索引擎，结果被追加到上下文中
  • 奖励：基于最终答案正确性（RLVR）+ 搜索效率惩罚
推理 + 搜索的交互过程：

用户: "2025 年图灵奖颁给了谁？"

模型推理: "这个问题涉及 2025 年的最新信息，我需要搜索一下。"
模型动作: <search>2025 Turing Award winner</search>
搜索返回: "The 2025 ACM Turing Award was given to..."
模型推理: "现在信息充足了。"
最终答案: [完整答案]

Reward: 答案正确性 - λ × 搜索次数

训练使用 GRPO 的组采样 + 组内比较。关键设计：搜索返回的文本在 loss 中被 mask 掉——模型不应因为搜索引擎返回了好结果而被强化。搜索行为从 RL 训练中自发涌现——即使 SFT 没有教过搜索，模型也会逐渐学会在合适时机触发搜索。

SearchR1 的关键发现 ​

  • 搜索行为从 RL 中涌现。RL 不仅能优化已知策略，还能发现新策略
  • 搜索频率的 Scaling Law。训练步数越多，模型在需要搜索的问题上搜索频率上升，在不需要搜索的问题上搜索频率下降——模型学会了区分两种场景
  • 泛化到未见过的搜索场景。在数学问题上训练的搜索策略能泛化到历史、科学问题

技术谱系：SearchR1 之后 ​

工作核心创新引用
SearchR1[12:1]RL 训练模型自主搜索，GRPO + RLVR819
ReSearch[13:1]推理与搜索深度融合，每步推理可包含搜索策略反思—
ToRL[14:1]扩展到计算工具（代码执行器），发现工具使用的 Scaling Law131
ReTool[2:1]区分推理型 vs 计算型任务，RL 让模型策略性选择工具247
ZeroTIR[11:1]无监督示例下模型自发学会代码执行，幂律 Scaling LawNeurIPS 2025

ToRL[14:2] 训练的 32B 模型在数学推理上超越了不使用工具的 70B 模型，证明了"小模型 + 工具 > 大模型纯推理"。ReTool[2:2] 进一步让模型学会策略性的工具选择——不是所有问题都需要工具，而是根据问题特征动态决定。

python
def search_reward(answer, ground_truth, num_searches, max_searches=5):
    """搜索 RL 的 reward 函数"""
    correctness = 1.0 if verify_answer(answer, ground_truth) else 0.0
    efficiency_penalty = -0.05 * num_searches  # 搜索成本惩罚
    return correctness + efficiency_penalty

工具调用策略的训练流程 ​

把上面的概念串起来，一个完整的工具调用 RL 训练流程通常包含三个阶段：

阶段一：SFT 教格式。 用人类标注的工具调用轨迹做监督微调，教会模型"工具调用的 JSON 格式长什么样"。这一步不涉及策略优化——模型只是学会了如何正确地格式化一个工具调用请求。

阶段二：RL 教策略。 在 SFT 模型的基础上，用 RL 优化工具使用的策略。模型开始探索不同的工具使用方式——有时候该调工具却不调，有时候不该调却调了。Reward 信号（任务成功/失败）告诉模型哪种策略更好。

阶段三：迭代优化。 随着 RL 训练的进行，模型会发现自己策略中的弱点——比如"在某些场景下总是忘记先搜索再回答"。这些弱点可以通过增加针对性的训练数据来修复，形成一个持续改进的循环。

python
# 简化的工具调用 RL 训练循环
def tool_rl_training_loop(
    model, tool_env, tasks, num_epochs=100, group_size=4
):
    """工具调用 RL 的核心训练循环（简化版）"""
    optimizer = torch.optim.Adam(model.parameters(), lr=1e-6)

    for epoch in range(num_epochs):
        for task in tasks:
            # 生成多条轨迹（group sampling，类似 GRPO）
            trajectories = []
            for _ in range(group_size):
                traj = model.interact_with_tools(task, tool_env)
                trajectories.append(traj)

            # 计算每条轨迹的 reward
            rewards = [compute_agent_reward(t.success, t.num_turns) for t in trajectories]

            # 组内比较（GRPO 思路）：用相对排名来计算 advantage
            mean_reward = np.mean(rewards)
            std_reward = np.std(rewards) + 1e-8
            advantages = [(r - mean_reward) / std_reward for r in rewards]

            # 策略梯度更新
            for traj, advantage in zip(trajectories, advantages):
                loss = traj.total_log_prob * (-advantage)  # 策略梯度
                loss.backward()

            optimizer.step()
            optimizer.zero_grad()

注意这个训练循环的核心思路和第 8 章的 GRPO 非常相似——都是"组内采样多条轨迹，用相对比较来计算 advantage"。区别在于：GRPO 比较的是多条文本回答，这里比较的是多条工具调用轨迹。

与 RLVR 的联系 ​

你可能已经注意到，工具调用 RL 的 reward 设计和第 8 章的 RLVR 非常相似。这不是巧合——Agentic RL 就是 RLVR 在多轮交互场景的自然延伸。RLVR 的核心思想是"用可验证的结果作为 reward，不需要训练 Reward Model"。在工具调用场景中，工具的执行结果天然就是可验证的：代码是否通过测试、SQL 查询结果是否正确、搜索结果是否包含目标信息——这些都可以自动化验证，不需要人工标注。

这也是为什么 Agentic RL 被认为比偏好对齐（RLHF/DPO）更适合 Agent 训练的原因之一：偏好对齐需要训练一个 Reward Model 来模拟人类偏好，而 Agent 的任务通常有客观的评判标准，直接用可验证奖励就可以了。

思考题：SFT 教格式 + RL 教策略的两阶段范式，和第 2 章的 DPO 有什么异同？

相同之处在于两者都是"先 SFT 再 RL"——先用监督学习教模型基本的格式和能力，再用 RL 优化策略。这是大模型训练的通用范式。

不同之处在于目标：DPO 的 RL 阶段优化的是"回答的偏好排序"（人类更喜欢哪个回答），而工具调用 RL 的 RL 阶段优化的是"工具使用策略"（什么时候该用什么工具）。前者需要 Reward Model（或隐式的偏好模型），后者可以用可验证奖励（不需要额外的 Reward Model）。

更深层的区别是：DPO 依然在单轮范式中——输入 prompt，输出完整回答。工具调用 RL 在多轮范式中——模型需要在多步交互中做出连续决策。这使得后者面临更复杂的信用分配问题（上一节讨论的核心难题）。

下一节我们来看看工业界各家的 Agentic RL 实战经验——工业界实战。

参考资料 ​

Agentic RL 工程实战 ​

前面的章节里我们讲了多轮 RL 的信用分配、轨迹合成方法和工具调用的策略学习。现在我们要面对一个更"接地气"的问题：怎么把这些想法变成一个真正能跑起来的训练系统？Agentic RL 的工程复杂度远超标准 LLM RL——你不仅要管理 GPU 上的模型训练，还要管理 CPU 上的工具执行、网络上的环境交互、安全沙箱里的代码运行。这一节我们来拆解这些工程挑战。

环境瓶颈：为什么 Agentic RL 跑不快 ​

在标准的 LLM RL 训练中（如第 5 章的 PPO 或第 8 章的 GRPO），训练循环是纯 GPU 的：模型在 GPU 上生成回答，Reward Model 在 GPU 上打分，梯度在 GPU 上计算。整个过程中最慢的环节通常是 GPU 计算。

但 Agentic RL 的训练循环完全不同。模型每生成一个"工具调用"动作，就需要暂停等待工具执行的结果。这个执行过程发生在 GPU 之外：

这带来了三个核心瓶颈：

安全性。代码执行必须在沙箱中进行——模型可能生成"删除系统文件"或"读取环境变量"的恶意代码。Docker 容器是最常用的沙箱方案，但容器的创建和销毁有毫秒级的开销，在训练循环中累积起来就成了显著的瓶颈。

可复现性。RL 训练要求相同的输入产生相同的输出。但工具调用的结果可能是不确定的——搜索引擎对同一个 query 在不同时间可能返回不同结果，API 的响应时间可能波动。这导致同一条训练轨迹无法精确复现，增加了调试难度。

延迟。工具调用的响应时间从毫秒（本地代码执行）到秒级（网络 API 调用）不等。在标准 RL 训练中，GPU 的计算是连续的；但在 Agentic RL 中，GPU 经常在"等待"工具执行的结果，导致 GPU 利用率低下。

python
import asyncio
import docker

class ToolSandbox:
    """安全的工具执行沙箱：用 Docker 容器隔离代码执行"""

    def __init__(self, image="python:3.11-slim", timeout=30):
        self.client = docker.from_client()
        self.image = image
        self.timeout = timeout

    async def execute(self, code: str) -> dict:
        """在沙箱中异步执行代码，返回结果和状态"""
        try:
            container = self.client.containers.run(
                self.image,
                command=f"python -c '{code}'",
                detach=True,
                mem_limit="512m",      # 内存限制
                cpu_period=100000,
                cpu_quota=50000,        # CPU 限制（50%）
                network_mode="none",    # 禁止网络访问
                remove=True,
            )
            result = container.wait(timeout=self.timeout)
            output = container.logs().decode("utf-8")
            return {"success": result["StatusCode"] == 0, "output": output}
        except Exception as e:
            return {"success": False, "output": str(e)}

基础设施对比：标准 LLM RL vs Agentic RL ​

理解了瓶颈之后，让我们对比一下两种 RL 训练基础设施的核心区别：

组件标准 LLM RLAgentic RL
Rollout 引擎GPU 生成文本GPU 生成文本 + CPU 执行工具（异构计算）
环境交互无（纯文本生成）需要工具沙箱、Web 环境、代码执行器
Reward 来源Reward Model 打分（GPU）环境执行结果（代码通过/失败，可异步）
Episode 长度固定（生成 max_tokens）可变（不同任务需要不同轮数）
并行策略GPU 批量生成异步并发（多条轨迹同时等工具返回）
容错生成失败重试工具执行可能超时/崩溃，需要 fallback 机制
可复现性高（确定性生成）低（工具执行结果可能不确定）

这个对比揭示了一个关键洞察：Agentic RL 的训练基础设施本质上是一个分布式系统——它需要同时管理 GPU 计算、CPU 执行、网络通信、状态同步。这比标准 LLM RL 的"纯 GPU"训练复杂了一个数量级。

从形式化的角度来看，标准 LLM RL 的训练吞吐量主要受限于 GPU 计算时间：

Throughputstandard∝1TGPU\text{Throughput}_{\text{standard}} \propto \frac{1}{T_{\text{GPU}}}

而 Agentic RL 的训练吞吐量受限于 GPU 计算和工具执行的最大值：

Throughputagentic∝1max⁡(TGPU,Ttool)\text{Throughput}_{\text{agentic}} \propto \frac{1}{\max(T_{\text{GPU}}, T_{\text{tool}})}

当工具执行时间远大于 GPU 计算时间时（Ttool≫TGPUT_{\text{tool}} \gg T_{\text{GPU}}），GPU 大部分时间在空等——这就是为什么异步并发（下面会讨论）是 Agentic RL 工程优化的关键。

代表性框架 ​

AWorld-RL：完整的 Agentic RL 环境 ​

AWorld-RL 提供了一个完整的 Agentic RL 训练环境，包括多种工具（搜索、代码执行、数据库查询）、标准化的环境接口、以及配套的 RL 训练算法。它的设计理念是"把 Agentic RL 变得像 Gymnasium 一样易用"——你只需要定义任务和 reward，框架负责处理工具执行、沙箱管理、轨迹收集等工程细节。

Agent-R1：端到端 Agentic RL 框架 ​

Agent-R1（中科大出品）是 Agentic RL 领域的标杆开源项目。它对传统 MDP 进行了扩展，使其能更好地描述 LLM 智能体面临的复杂、动态环境。框架由 BaseTool（工具抽象）、BaseToolEnv（状态管理）和 ToolGenerationManager（多轮对话管理）等模块构成，高度解耦，易于扩展。它明确区分了过程奖励（Process Reward）和结果奖励（Outcome Reward），为解决长程任务中的稀疏奖励问题提供了有效手段。

AReaL：全异步 RL 训练 ​

AReaL（清华 & 蚂蚁出品）的核心创新是全异步训练——将 Actor rollout、工具执行和 Learner 更新彻底解耦，不同组件以不同速率并行运行。实验显示，全异步策略将训练速度提升了最高 2.77 倍，同时原生支持多轮 Agentic RL 训练。对于需要频繁与工具环境交互的 Agentic 场景，异步架构能显著提升 GPU 利用率。

NeMo Gym：NVIDIA 的科学 Agent 训练平台 ​

NeMo Gym 是 NVIDIA 推出的 Agentic RL 训练基础设施，专注于科学 Agent 的训练。它提供了化学分子模拟、药物发现等科学计算环境，支持高效的并行工具执行和分布式训练。

Agentic RL Training Recipes ​

Agentic RL Training Recipes 是社区维护的开源训练方案集合，覆盖了从简单的工具调用 RL 到复杂的多轮 Agent RL 的多种训练方案。每个方案都包含完整的代码、配置和训练曲线。

异步并发：让 GPU 不再空等 ​

前面提到 Agentic RL 最大的工程瓶颈是 GPU 等待工具执行。一个关键的工程优化是异步并发——同时启动多条轨迹的工具调用，让 GPU 在等待一组工具返回的同时处理另一组轨迹。

python
import asyncio

async def rollout_single_trajectory(model, task, sandbox, max_turns=10):
    """单条轨迹的异步 rollout"""
    state = task.initial_state()
    turns = []

    for t in range(max_turns):
        # GPU: 模型生成动作
        action = await model.generate_async(state)
        turns.append(action)

        if action.is_final_answer():
            break

        # CPU/网络: 异步执行工具
        observation = await sandbox.execute_async(action)
        state = state.update(observation)

    return turns, task.evaluate(turns)

async def parallel_rollouts(model, tasks, sandbox, num_workers=16):
    """并行启动多条轨迹的 rollout，充分利用 GPU 和工具执行器"""
    coroutines = [
        rollout_single_trajectory(model, task, sandbox)
        for task in tasks
    ]
    # asyncio.gather 实现并发：一条轨迹在等工具返回时，其他轨迹可以使用 GPU
    results = await asyncio.gather(*coroutines)
    return results

这个设计的核心思想是：GPU 生成和工具执行是两种不同类型的计算，它们可以流水线化。当轨迹 A 的工具在 CPU 上执行时，GPU 可以同时为轨迹 B 生成动作。这就像餐厅的流水线——厨师（GPU）不需要等上一桌的菜上完才开始做下一桌的菜。

实际工程中，这种异步并发通常能把 GPU 利用率从 20-30% 提升到 70-80%，训练吞吐量提升 2-3 倍。但实现起来比听起来复杂得多——你需要处理超时、重试、状态同步等分布式系统的经典问题。

跨章节联系：Agentic RL 与前面章节的概念映射 ​

Agentic RL 不是凭空出现的——它和前面章节学过的几乎所有概念都有联系。下面的表格帮你梳理这些联系：

概念前面章节Agentic RL 中的对应
动作空间只有"生成 token"（第 5-8 章）扩展为"生成文本 + 调用工具"（异构动作）
Reward 来源RM 打分 / 偏好比较（第 6、8 章）环境执行结果（可验证，第 8 章 RLVR）
信用分配Token 级别（第 5 章 PPO）Turn 级别（跨多轮，ORM vs PRM）
GRPO 组内比较多条回答对比（第 8 章）多条轨迹对比（同样适用）
经验回放DQN 的 Replay Buffer（第 4 章）工具调用轨迹的回放（需要环境可复现）
策略梯度定理REINFORCE（第 4 章）多轮策略梯度（Turn-Level Discounting）
Actor-CriticPPO（第 5 章）Agentic PPO（Critic 评估轮次价值）
RLVR可验证奖励（第 8 章）工具执行结果的天然可验证性

值得注意的是，经验回放在 Agentic RL 中的使用比在标准 DQN 中更加微妙。DQN 的经验回放可以直接复用旧数据，因为环境是确定的（CartPole 的物理规律不变）。但 Agentic RL 中，工具的执行结果可能随时间变化（搜索引擎的结果会更新），所以旧轨迹可能不再有效。这意味着 Agentic RL 的经验回放需要过期机制——超过一定时间或者环境状态发生变化的旧轨迹应该被丢弃。

训练完之后，怎么知道你的 Agent 到底好不好？评测与 Benchmark 是 Agentic RL 中一个足够大的话题——从工具调用排行榜到端到端任务基准，从评测 Pipeline 搭建到评测驱动训练改进的闭环——我们把它独立成了一节：Agentic 评测体系与 Benchmark 全景。

Agent 奖励设计与评估体系 ​

前面的讨论假设你已经有了 reward 函数。但在实际项目中，设计一个好的奖励函数往往是 Agentic RL 最难的环节。这一节我们来拆解：如何从零开始设计 Agent 的多维奖励，以及如何把"人类直觉"转化为"可计算的 reward"。

Agent 奖励的三大维度 ​

一个好的 Agent 奖励函数通常需要覆盖三个正交维度：

任务完成度（Task Completion）。 Agent 最终是否完成了用户的目标？这是最基本的维度。对于可验证任务（代码执行、SQL 查询），这是 binary signal；对于开放式任务（写报告、搜索研究），这需要更细致的评估。

过程质量（Process Quality）。 Agent 的执行过程是否合理？即使最终结果正确，如果 Agent 用了 50 步去完成一个 5 步就能解决的任务，或者中间犯了多次不必要的错误，它的过程质量就不高。过程质量包括：工具使用效率、搜索策略合理性、错误恢复能力、信息综合质量。

执行效率（Efficiency）。 Agent 以多少资源完成了任务？包括交互轮数、工具调用次数、token 消耗量。效率维度的重要性随部署场景变化——对延迟敏感的场景（如客服）效率很重要，对质量敏感的场景（如研究报告）效率可以适当放宽。

python
def comprehensive_agent_reward(trajectory, final_result, task):
    """Agent 三维奖励框架"""
    # 维度 1: 任务完成度
    completion = task.evaluate_result(final_result)  # 0.0 ~ 1.0

    # 维度 2: 过程质量
    tool_calls = [t for t in trajectory if t.action_type == "tool_call"]
    effective_calls = [t for t in tool_calls if is_effective(t)]
    process_quality = (
        0.4 * (len(effective_calls) / max(len(tool_calls), 1))  # 工具有效率
        + 0.3 * reasoning_coherence_score(trajectory)            # 推理连贯性
        + 0.3 * error_recovery_score(trajectory)                 # 错误恢复能力
    )

    # 维度 3: 执行效率
    efficiency = compute_efficiency(
        num_turns=len(trajectory),
        num_tool_calls=len(tool_calls),
        total_tokens=sum(t.token_count for t in trajectory),
        baseline=task.expected_complexity  # 基准：任务预期复杂度
    )

    # 加权组合（权重可根据任务类型调整）
    return (
        0.50 * completion +
        0.30 * process_quality +
        0.20 * efficiency
    )

从 Rubrics 到 Reward Model：方法论 ​

人类专家评估 Agent 输出时，通常会用一套评分标准（Rubrics）。把这些 Rubrics 转化为可计算的 reward，需要经过三步：

Step 1：定义评分维度。 与领域专家一起确定"好 Agent 输出"的关键维度。例如，对搜索 Agent：答案准确性、引用质量、搜索策略、信息覆盖度。

Step 2：收集偏好数据。 让人类标注员（或用 LLM-as-Judge）对成对的 Agent 输出进行偏好比较。"A 和 B 哪个更好？为什么？" 这一步的核心挑战是标注一致性——不同标注员可能对"过程质量"有不同标准。解决方法是先在小样本上对齐标注标准，再大规模标注。

Step 3：训练 Reward Model。 用偏好数据训练 RM——这和第 8 章 DPO 的 Bradley-Terry 模型一致。关键区别在于：Agent RM 可能需要多个维度的独立评分（而不是单一分数），以便在 RL 训练中做细粒度的 credit assignment。

演化评分标准：RLER ​

Allen AI 的 DR Tulu 提出了 RLER[17]（Reinforcement Learning with Evolving Rubrics）——一个让评分标准随训练动态演化的框架。核心洞察是：

  • 训练初期：模型能力弱，用宽松的标准鼓励探索。只要答案大致方向对了就给 reward。
  • 训练中期：模型开始靠谱了，收紧标准。现在要求答案基本正确、引用至少部分可验证。
  • 训练后期：模型已经很强了，用严格的标准精修。要求答案精确正确、所有引用可验证、过程高效。

RLER 的实现方式是：维护一个评分标准版本库，每隔 NN 步训练就根据模型的当前表现调整评分标准的严格程度。这和课程学习（12.2 节）有相似的思想——但 RLER 是"评分标准在演化"，而不是"任务难度在增加"。

工具感知的奖励设计：ToolRL ​

ToolRL[18]（NeurIPS 2025）专门研究了工具调用场景下的奖励设计。它发现了一个反直觉的结论：在工具调用 RL 中，一个"粗糙但正确"的 reward 函数，往往比一个"精细但带偏差"的 reward 函数效果更好。

原因在于：精细的 reward 设计通常包含很多人为假设（比如"3 步以内完成是好的"），这些假设可能对某些任务不成立。而简单的"任务是否完成 + 基本格式检查"虽然信号粗糙，但至少不会误导模型。

ToolRL 的实践建议：

  1. 从最简单的 reward 开始：只看任务是否完成
  2. 观察模型的失败模式：是格式错误？工具选择错误？还是效率太低？
  3. 针对失败模式添加具体惩罚：模型过度调用工具 → 加效率惩罚；模型输出格式错误 → 加格式奖励
  4. 逐步迭代：不要一次性设计复杂的 reward，而是观察训练曲线逐步调整

LLM-as-Judge：自动化的奖励评估 ​

在无法定义精确 reward 函数的场景中（如报告质量、对话自然度），可以用 LLM 作为"自动评审"：

python
def llm_judge_reward(agent_output, task_description, judge_model):
    """用 LLM 做 Judge 的奖励函数"""
    prompt = f"""请评估以下 Agent 输出的质量。

任务: {task_description}

Agent 输出:
{agent_output}

请从以下维度打分（0-10）：
1. 任务完成度: 是否充分回答了用户的问题？
2. 准确性: 信息是否准确、有无幻觉？
3. 结构清晰度: 回答是否逻辑清晰、层次分明？
4. 引用可靠性: 引用来源是否真实可信？

输出 JSON 格式: {{"completion": X, "accuracy": X, "structure": X, "citation": X}}"""

    scores = judge_model.generate(prompt)
    return weighted_average(scores, weights=[0.4, 0.3, 0.15, 0.15])

LLM-as-Judge 的优势是灵活、低成本；劣势是可能存在系统性偏差（比如偏好更长或更"礼貌"的回答）。实践中，通常用 LLM-as-Judge 做初步筛选，再用人类标注做质量校准。

实践路线图 ​

根据项目阶段选择合适的奖励设计策略：

项目阶段推荐策略原因
早期验证简单 binary reward（成功/失败）快速验证训练流程是否通畅
中期优化多维 Rubrics + 手工 reward针对具体失败模式优化
后期精修RLER 演化标准 + LLM-as-Judge复杂任务的细粒度优化

核心原则：reward 设计遵循"先简后繁、观察驱动"的迭代原则。不要在训练开始前就设计复杂的 reward——先跑起来，观察模型的失败模式，再有针对性地添加奖励维度。

本章总结 ​

让我们回顾第 9 章的核心收获：

1. Agentic RL = 多轮 RL + 工具调用。 从"生成文本"扩展到"在环境中行动"，这是从对话模型到自主智能体的关键跨越。

2. 信用分配是核心难题。 7 轮交互失败了，该怪谁？ORM 只看结果（简单但信号稀疏），PRM 每步都评（密集但标注昂贵）。在实践中，两者的组合（如 MLMT-RL 的多粒度奖励）效果最好。

3. RLVR 是 Agentic RL 的天然选择。 工具执行结果是客观可验证的——代码是否通过测试、SQL 查询结果是否正确——不需要训练额外的 Reward Model。

4. 环境是工程瓶颈。 安全沙箱、可复现性、低延迟——这些工程问题直接决定了 Agentic RL 能否从论文走向生产。

思考题：如果你要训练一个"能独立完成软件项目"的 Code Agent，你会怎么设计 RL 训练方案？

这是一个开放性问题，没有标准答案，但有几个关键考量：

Reward 设计：不能只看"最终代码是否通过测试"。一个好的 Code Agent 还需要：代码可读性（是否写了注释？命名是否清晰？）、架构合理性（是否合理地拆分了模块？）、鲁棒性（是否处理了边界情况？）。这些可以用多维度 reward 来建模。

信用分配：一个软件项目可能需要几十轮交互。纯 ORM 在这里会非常困难——信号太稀疏。PRM 或某种"里程碑式 reward"（比如"完成了数据库设计"是一个中间里程碑）可能更合适。

课程学习：不能一开始就让它做完整项目。从单函数 → 单文件 → 多文件 → 完整项目，逐步增加任务难度。

安全约束：代码执行沙箱是必须的，但还需要防止模型学会"走捷径"——比如通过硬编码测试用例来通过测试（而不是真正解决问题）。

到这里，我们已经覆盖了 Agentic RL 的核心理论和工程实践。下一节，我们来看看工业界各家的 Agentic RL 实战经验——工业界实战：各家的 Agentic RL 都怎么做的？，拆解 LinkedIn、Bespoke Labs、Moonshot、Alibaba 通义、Salesforce、Amazon 六家公司的训练方案、踩坑记录和关键取舍。

参考资料 ​

  1. Schick T, Dwivedi-Yu J, et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." NeurIPS 2023. —— SFT 教工具调用格式的代表工作，证明 LLM 可以自学使用工具。 ↩︎

  2. Feng J, et al. "ReTool: Reinforcement Learning for Strategic Tool Use in LLMs." arXiv:2504.11536, 2025. —— 用 RL 优化推理过程中的工具调用策略。 ↩︎ ↩︎ ↩︎

  3. verl-tool Team. "verl-tool." GitHub, 2025. —— VeRL 的工具调用增强版，跨领域工具调用 RL 训练框架。 ↩︎

  4. Qian C, Acikgoz EC, et al. "ToolRL: Reward is All Tool Learning Needs." NeurIPS 2025. —— 将工具调用视为 RL 中的特殊动作，扩展策略的动作空间。 ↩︎

  5. Li Y, Zhang C, Lv R, et al. "ReLook: Vision-Grounded RL with a Multimodal LLM Critic for Agentic Web Coding." arXiv:2510.11498, 2025. —— 用多模态 LLM 对网页渲染截图进行视觉评分作为 RL reward。 ↩︎

  6. Wang Z, Mao J, et al. "Agent Workflow Memory." ICML 2025. —— 从 Agent 过去经验中抽取可复用工作流，增强 Web 导航的泛化能力。GitHub ↩︎

  7. Chae H, et al. "Web-Shepherd: Advancing PRMs for Reinforcing Web Agents." NeurIPS 2025 Spotlight. —— 首个网页导航专用步骤级 PRM，相比 GPT-4o-mini 做判官，成本降至 1/10。 ↩︎

  8. Shang N, Liu Y, Zhu Y, et al. "rStar2-Agent: Agentic Reasoning Technical Report." arXiv:2508.20722, 2025. —— 14B 模型用 GRPO-RoC 算法在 AIME24 上达 80.6%，超越 671B DeepSeek-R1。 ↩︎

  9. Boruch-Gruszecki A, et al. "Agnostics: Learning to Code in Any Programming Language." arXiv:2508.04865, 2025. —— 语言无关的代码 RL 训练管线，通过通用执行验证器支持任何编程语言。项目主页 ↩︎

  10. Ugare S, Chandra S. "Agentic Code Reasoning." arXiv:2603.01896, 2026. —— 通过半形式化推理在不执行代码的情况下进行 93% 准确率的补丁验证。 ↩︎

  11. Mai X, Xu H, Wang X, et al. "Agent RL Scaling Law: Agent RL with Spontaneous Code Execution for Mathematical Problem Solving." NeurIPS 2025. —— ZeroTIR 方法：无监督示例下自发学会代码执行，发现训练步数与性能的幂律关系。 ↩︎ ↩︎

  12. Jin B, et al. "Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning." COLM 2025. 首次将搜索工具使用建模为 RL 问题。GitHub ↩︎ ↩︎

  13. Chen M, et al. "ReSearch: Learning to Reason with Search for LLMs via Reinforcement Learning." arXiv:2503.19470, 2025. 推理与搜索深度融合框架。 ↩︎ ↩︎

  14. Li X, et al. "ToRL: Scaling Tool-Integrated RL." arXiv:2503.23383, 2025. 将工具使用 RL 扩展到计算工具，发现工具使用的 Scaling Law。 ↩︎ ↩︎ ↩︎

  15. Yao S, et al. "ReAct: Synergizing Reasoning and Acting in Language Models." ICLR 2023. 推理与行动协同的经典 prompting 方法。 ↩︎

  16. Asai A, et al. "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection." ICLR 2024. 通过自我反思进行检索增强生成。 ↩︎

  17. Shao R, Asai A, et al. "DR Tulu: Reinforcement Learning with Evolving Rubrics for Deep Research." arXiv, 2025. 演化评分标准的 RL 训练，评分标准随训练进程动态调整。 ↩︎

  18. Qian C, et al. "ToolRL: Reward is All Tool Learning Needs." NeurIPS 2025. 工具调用场景下的奖励设计研究，发现简单正确的 reward 优于精细但带偏差的 reward。 ↩︎

Built for reusable bilingual course delivery

Copyright © WalkingLabs