动机:从聊天机器人到自主智能体
现代 LLM 越来越多地被部署,不仅作为对话助手,而且作为自主智能体(Autonomous Agents),能够在多个步骤中与外部工具、API、数据库和环境进行交互。这一转变——从单轮聊天机器人到多步智能体——引入了根本性的新 RL 挑战,要求我们重新思考如何训练、评估和部署语言模型。
要求新 RL 方法的关键差异:
- 多步推理:智能体必须跨越 10–100+ 次工具调用进行规划,而不仅仅是生成单一响应。
- 外部环境反馈:奖励来自真实世界的执行(测试套件通过、网页加载、代码编译)——而不仅仅是人类偏好分数。
- 结构化动作:动作不仅是 Token,而是结构化输出(JSON 工具调用、API 负载、代码块)。
- 长视野与稀疏奖励:成功/失败可能只能在多个中间步骤之后才能确定。
LLM Agent 的轨迹缓冲区
在 LLM 智能体的语境下,传统的 RL 回放缓冲区经历了结构性的转变。Agent 缓冲区——通常称为轨迹缓冲区(Trajectory Buffers)、经验池(Experience Pools)或记忆库(Memory Banks)——不再存储低维数值 Tensor,而是管理复杂的文本历史、工具执行输出和显式推理步骤。
LLM Agent 缓冲区的数学结构
在经典 RL 中,回放缓冲区存储扁平元组 。对于 LLM 智能体,这扩展为高维的 Token 化文本结构:
- :完整上下文状态——系统 Prompt、用户目标、对话历史,以及当前环境变量(例如 HTML 源代码、目录结构、数据库 Schema)。
- :智能体的生成输出,通常由一段思维链(Chain-of-Thought,CoT)推理字符串紧接一个结构化工具调用组成:(12.2)
- :评估信号,来自外部执行环境(单元测试通过、编译器标志、API 响应码),或由 LLM-as-a-judge 系统验证。
- :更新后的上下文窗口,将工具输出文本或错误日志直接附加到对话历史中。
操作范式
LLM 智能体通过三种主要的优化方法论来利用专门的轨迹缓冲区:
A. 自我纠正与思维细化
此类别中的两种代表性方法是 STaR [419] 和 Reflexion [326]。当智能体在一次多步执行轨迹中失败时,次优序列会被保存到缓冲区。该框架随后采样此轨迹,并提示 LLM 对其过去的表现生成显式文本批评:
一旦修正后的轨迹获得正向奖励,它就被移至最优经验池,用于通过微调(在成功轨迹上做 SFT)或 RL(采用二元通过/失败奖励的 GRPO [323])来更新网络权重。
B. 离策略探索
此范式以 ReAct [409] 及相关工具使用框架为代表,涉及广泛的自主探索。在自主探索过程中(网页导航、数据库查询、代码生成),智能体记录数千条探索性执行路径。轨迹缓冲区充当一个过滤器:
- 成功过滤:只保留达成目标的轨迹用于训练。
- 效率排序:在成功轨迹中,优先选择最短/最高效的工具使用路径。
- 多样性采样:维持多样化的解决策略集合,以防止模式坍塌。
优化算法(通常是 GRPO [323] 或过滤后的 SFT)只在高效、成功的轨迹上计算 Loss,丢弃迂回曲折的运行。
C. 非参数化的上下文学习(基于经验的 RAG)
轨迹缓冲区可以不修改神经网络权重,而是作为向量数据库。给定一个新的用户目标 ,系统检索最相关的过往经验:
最相似的 top- 条成功历史运行被直接注入到 Prompt 上下文中作为少样本示范。这种方式:
- 需要零训练——纯粹的检索增强生成
- 如果缓冲区中存在相似经验,可即时适应新任务
- 随缓冲区规模扩展(经验越多,覆盖越好)
- 与参数化学习互补(罕见情况用检索,常见模式用权重)
范式对比
| 特性 | 传统 RL 缓冲区 | LLM 智能体缓冲区 |
|---|---|---|
| 数据格式 | 连续向量 / Tensor | Token 化文本、JSON、代码块、工具输出 |
| 数据量 | 海量(– 条) | 中小规模(– 条轨迹) |
| 主要目标 | 打破数据相关性 | 提供推理示范 |
| 采样 | 随机均匀 / PER | 语义检索 / 成功优先 / 多样性 |
| 状态大小 | 固定(例如 8484 像素) | 可变(每个状态 1K–128K Token) |
| 动作空间 | 离散/连续向量 | 结构化文本(推理 + 工具调用) |
| 奖励来源 | 环境模拟器 | 外部执行 / LLM 评判 / 单元测试 |
表 12.1:传统 RL 缓冲区与 LLM 智能体缓冲区
Agent RL 的主要技术
| 方法 | 类型 | 核心思想 |
|---|---|---|
| STaR[419] | 迭代式 SFT | 通过在自身成功轨迹上微调来自举推理能力 |
| Reflexion[326] | 上下文内 RL | 语言自我批判存入情景记忆;不更新权重 |
| ReAct[409] | Prompt 工程 | 在单次生成中交错进行推理(「思考」)与行动(「工具调用」) |
| LATS[438] | 树搜索 | 在动作序列上进行蒙特卡洛树搜索;反向传播奖励 |
| AgentQ[294] | 离策略 RL | 在智能体轨迹上用 AI 生成的偏好对做 DPO |
| OpenHands[366] | GRPO | 基于执行奖励的组相对优化(测试通过/失败) |
| Voyager[362] | 技能库 | 存储成功的代码片段并检索,用于组合式复用 |
| RLEF[201] | 在线 RL | RL from Execution Feedback——来自代码/测试执行的二元奖励 |
表 12.2:用 RL 训练 LLM 智能体的关键方法。
STaR:自学习推理者(详解)
STaR [419] 是一种迭代式自我改进方法,无需外部奖励模型即可自举推理能力。其核心洞见是:如果模型偶尔能正确解决某个问题,它就能从自身的成功中学习。
算法:
- 生成:对数据集 中的每个问题 ,采样一条推理轨迹 及其后的答案 。
- 过滤:仅保留满足 (答案正确)的轨迹。定义成功集合 。
- 合理化(关键创新):对模型失败的问题,生成一段「合理化」——以正确答案为条件的推理轨迹:。这教会模型从解答反向推理。
- 微调:在 上通过 SFT 更新 。
- 迭代:用改进后的模型从第 1 步重复。
收敛动态:每次迭代 都会提升模型的解题率 。若 (能解 30% 的问题),经合理化 + SFT 后,。通常在 3–5 次迭代后收敛到 –。
Reflexion:语言强化学习(详解)
Reflexion [326] 提出了一种激进的范式:不更新权重的 RL。智能体不依赖基于梯度的学习,而是通过存放在情景记忆中的自然语言自我批判来改进。
完整架构:
- Actor:在环境中执行动作的 LLM 智能体 。
- Evaluator:二元信号(任务成功/失败)或标量启发式指标(例如通过的测试用例数)。
- 自我反思生成器:给定失败轨迹 与环境反馈,生成自然语言反思 :(12.6)
- 情景记忆:过去反思的滑动窗口缓冲区 (通常取 以适配上下文)。
- 重试循环:在下一次尝试中,反思被注入到 Prompt 中:(12.7)
反思示例:「在上一次尝试中,我在验证输入格式之前就调用了搜索 API,导致 400 错误。下次我应当先验证 JSON schema,再发起 API 调用。」
优势与局限:
优势局限无需梯度计算;可与冻结的 API 模型(GPT-4)配合受限于上下文窗口;无法无限累积知识迭代快(每次重试只需数秒,而 RL 训练需要数小时)无法泛化到未见任务(记忆是任务特有的)可解释:自我纠正可被人阅读依赖模型自身识别错误的能力可与任何基础智能体架构组合当基础模型太弱、无法生成有用批判时效果下降
ReAct:推理 + 行动(详解)
ReAct [409] 通过在单次生成流中交错进行显式推理步骤与环境动作,确立了工具使用智能体的主流 Prompt 范式。
生成格式:
形式化定义:一条 ReAct 轨迹是 ,其中:
- :思考(Thought,内部推理,不执行)
- :动作(Action,工具调用,在环境中执行)
- :观察(Observation,环境响应,追加到上下文)
为何有效:思考形成一种「内心独白」,帮助模型在行动前进行规划,减少冲动性的工具调用。显式的推理轨迹也使智能体的决策过程可审计、可调试。
用 RL 训练 ReAct 智能体:
- 动作级奖励:只有动作接收奖励信号(思考是辅助性的)。
- 思考质量:被隐式优化——更好的思考 更好的动作 更高的奖励。
- 格式约束:在奖励中对格式错误的动作(缺少 JSON、幻觉出的工具)加入格式惩罚。
- RL 目标:
LATS:语言 Agent 树搜索(详解)
LATS [438] 将蒙特卡洛树搜索(Monte Carlo Tree Search,MCTS)应用于 LLM 智能体的动作选择,用推理算力换取显著更优的轨迹。
算法(针对 LLM 智能体调整):
- 选择:从根节点(初始状态)出发,使用 UCB1 遍历树:(12.8)其中 = 子树的平均奖励, = 访问次数, = 探索常数。
- 扩展:在叶节点处,通过 LLM 采样(temperature )生成 个候选动作:
- 模拟:对每个候选动作,在环境中执行该动作,并用快速 rollout 策略(贪心解码)继续,直到终止状态或深度上限。
- 反向传播:将终端奖励沿所有祖先节点向上回传,更新 和 计数。
- 重复:在固定的计算预算内运行第 1–4 步(例如 50–200 次迭代)。
- 动作选择:选择根节点中访问次数最多的子节点。
针对 LLM 的适配:
- 价值函数:用一次单独的 LLM 调用估计状态价值:「按 0–1 评分,这个状态有多大可能导向任务成功?」
- 基于反思的剪枝:当某个分支失败时,生成一段反思并剪掉相似的分支。
- 缓存:在每个节点存储 LLM 输出,避免回溯时重复生成。
- 深度预算:将树深度限制在 10–20 步(智能体很少需要更多)。
性能:在 WebShop(网页导航)上,LATS 达到 75% 成功率,而 ReAct 为 40%。在 HumanEval(代码)上,树搜索使 pass@1 从 68% 提升到 94%。代价是每个任务多出 10–50 的推理 FLOPs。
AgentQ:在 Agent 轨迹上做 DPO(详解)
AgentQ [294] 通过从轨迹结果自动生成偏好对,把离线偏好学习(DPO)与在线智能体执行衔接起来。
流程:
- Rollout:用当前 policy 为每个任务执行 条轨迹。
- 评估:用基于执行的奖励(二元通过/失败或标量指标)为每条轨迹打分。
- 偏好对构造:为每个任务构造偏好对:(12.9)在同一任务的各条轨迹中,奖励最高者为 chosen;最低者为 rejected。
- DPO 更新:在轨迹级对数概率上应用标准 DPO loss:(12.10)
- 迭代:更新后的 在下一轮生成新的(更好的)轨迹。
关键设计选择:
- MCTS 引导的探索:在 rollout 阶段使用 LATS 生成多样且高质量的轨迹(更好的训练数据)。
- 步级 DPO:不比较完整轨迹,而是在动作级比较——在相同前缀下,哪一个后续动作能导向成功?
- 自我对弈改进:每次 DPO 迭代都产生更好的 policy,它生成更好的轨迹,进而产生更好的训练偏好对——形成良性循环。
结果:在 WebShop 上,AgentQ 在 3 次 DPO 迭代内相对基础 policy 取得绝对提升:成功率 50% 82%。
Voyager:通过技能库实现终身学习(详解)
Voyager [362] 引入了组合式技能累积——智能体构建一个不断增长的可复用代码函数库,这些函数充当高层动作。
架构:
- 自动课程:LLM 基于智能体当前的技能清单提出逐步加难的任务:「你现在能采木头并合成木板了。下一个挑战:做一个工作台。」
- 技能生成:对每个任务,智能体编写一个解决它的 JavaScript 函数(可执行代码):(12.11)
- 验证:在环境中执行代码。若成功,则加入技能库。若不成功,则结合错误反馈迭代(最多重试 5 次)。
- 技能库(向量数据库):每个通过验证的技能存储以下内容:•函数签名 + docstring(用于检索)•任务描述的嵌入(用于语义搜索)•依赖关系(它调用了哪些其他技能)
- 检索 + 组合:对新任务,检索最相关的 top- 个技能并组合它们:(12.12)
关键洞见:技能是可组合的——复杂行为由简单且已验证的函数组合而成。智能体永不遗忘(技能库持久保存),并且单调改进(只加入已验证的技能)。
RLEF:从执行反馈中做 RL(详解)
RLEF [201] 将使用确定性执行奖励的在线 RL应用于代码生成智能体,确立了智能体训练中最简单有效的范式。
训练循环:
- 采样任务:从训练集中抽取一个带测试用例 的编程问题。
- 生成:智能体使用当前 policy 产生一条解题轨迹(读取文件、编写代码、运行测试)。
- 执行:在沙箱(sandbox)环境中运行测试套件。奖励:(12.13)
- 更新:使用 作为奖励信号应用 GRPO/PPO。
- 重复:用新任务进行数千次迭代。
为什么执行反馈非常适合 RL:
- 零噪声:与人类偏好不同,测试结果是确定性的。相同代码 每次得到相同奖励。这消除了会使 RL 训练不稳定的奖励噪声。
- 可无限扩展:可以用程序无限生成任务(随机算法、API 集成测试、数据变换)。
- 无奖励作弊:与学习得到的奖励模型不同,测试套件无法被「糊弄」(前提是测试写得好)。智能体必须真正解决问题。
- 稠密信号:部分测试通过()比二元通过/失败提供更丰富的梯度。
OpenHands / SWE-Agent:用于软件工程的 GRPO
OpenHands [366] 与 SWE-Agent [404] 应用 GRPO 训练能自主解决 GitHub issue 的智能体——阅读代码、编写补丁并运行测试套件。
训练细节:
- 环境:包含完整 repo、测试套件和开发者工具(git、grep、lint)的 Docker 容器。
- 动作空间:Bash 命令、文件编辑、git 操作、测试执行。
- 轨迹长度:解决一个 GitHub issue 通常需要 15–50 个动作。
- 奖励:二元——生成的补丁是否通过该 issue 的回归测试?
- 组大小:每个 issue 采样 – 条轨迹用于 GRPO 归一化。
- 课程:从标记为「good first issue」的 issue 开始,逐步推进到复杂的多文件重构。
最先进的结果:SWE-bench Verified 上,RL 训练后解决率从 30% 提升到 55%(相较仅做 SFT 的基线)。
用例:用于生产力副驾的 Agent RL
本节提供一份完整蓝图,说明如何应用智能体 RL 技术训练一个基于 LLM 的协同助手(co-pilot),使其能够在整套生产力应用(文档、表格、演示、邮件、消息、云存储)中工作。
架构概览

生产力副驾的形式化 MDP 定义
生产力协同助手环境被形式化为部分可观测马尔可夫决策过程(Partially Observable Markov Decision Process,POMDP):
- :状态空间——完整的工作区环境状态:文档内容、邮件会话、日历事件、文件系统、用户权限。并非完全可观测:智能体只能看到 API 查询返回的内容。
- :动作空间——结构化 API 调用(见下)。每个动作是一个 JSON 对象,指定目标应用、操作和参数。
- :转移函数——对大多数操作是确定性的(写入文档 文档已更新),但对依赖网络的动作是随机的(邮件送达时间、Teams 可用性)。
- :奖励函数——多分量(见奖励设计一节)。
- :观测空间——API 响应、渲染后的文档视图、错误信息。
- :观测函数——将状态映射为观测(API 响应格式化、因上下文窗口限制而截断)。
- :折扣因子(长视野,通常 10–50 步)。
动作空间设计
动作空间必须是结构化的、类型安全的且可组合的:
按应用划分的动作分类:
应用复杂度关键动作Outlook中等search, read, draft, send, move, flag, create_ruleExcel高read_range, write_range, insert_formula, create_chart, pivot_table, run_macroWord中等read_paragraphs, insert_text, format_section, find_replace, insert_tablePowerPoint中等add_slide, insert_shape, set_text, set_layout, add_image, apply_themeTeams低send_message, create_meeting, search_chat, add_members, post_to_channelSharePoint中等list_files, upload, download, search, create_page, set_permissions
状态表示
智能体在每一步的观测(上下文窗口):
上下文预算管理(对 128K 窗口至关重要):
- 系统 Prompt:2K Token(能力、安全规则、输出格式)
- 用户意图 + 对话:4K Token
- Tool 历史(滑动窗口):最近 8–12 个动作 + 观测,较早的则做摘要。总计:最多 80K Token。
- 当前观测:最多 32K Token(大型电子表格、邮件会话)
- 预留:10K Token 用于智能体的推理 + 下一动作生成
状态压缩策略:
- 选择性纳入:只纳入与当前子目标相关的 API 响应(使用一个辅助的“相关性评分器”)。
- 结构化摘要:将大型电子表格表示为 schema + 样例行,而非完整数据。
- 层级式记忆:将完整轨迹存储在外部;向上下文中注入压缩后的摘要。
Reward 设计:多目标信号
生产力副驾的 Reward 函数必须平衡多个目标:
| 组件 | 权重 | 信号类型 | 定义 |
|---|---|---|---|
| 0.40 | 二元/标量 | 任务成功完成(邮件已发送、文档已创建、公式正确) | |
| 0.25 | LLM 评判者 | 输出质量:格式、清晰度、内容正确性 | |
| 0.15 | 标量 | 对步骤过多的惩罚: | |
| 0.15 | 二元 | 无不安全动作(未经确认即删除、发送给错误的接收者、权限违规)。若有任何违规则 。 | |
| 0.05 | 稀疏 | 在可用时使用显式用户反馈(点赞/点踩) |
表 12.3:生产力副驾训练的 Reward 组件。
中间 Reward(稠密信号):
- 成功的 API 调用(200 响应):+0.05
- 正确的信息检索(由下游使用所验证):+0.10
- 优雅地从错误中恢复(用修正后的参数重试):+0.08
- API 错误(4xx/5xx):–0.03
- 重复相同动作(循环检测):–0.10
- 当意图确实有歧义时提出澄清性问题:+0.05
训练流水线:端到端
模拟环境架构
任务课程设计
训练效果在很大程度上取决于任务难度的递进:
| 级别 | 步数 | 应用 | 示例任务 |
|---|---|---|---|
| L1:单步 | 1–2 | 1 | “读一下 Bob 发给我的最新邮件”“A1 单元格里是什么?” |
| L2:单应用 | 3–5 | 1 | “为预算邮件起草一份总结要点的回复” |
| L3:多步 | 5–10 | 1 | “根据销售数据创建数据透视表,并将表现最优者加粗” |
| L4:跨应用 | 5–15 | 2–3 | “找出 Q4 预算邮件,提取其中的数字,填入一张新的 Excel 工作表” |
| L5:复杂工作流 | 10–30 | 3+ | “准备一份周报:从 Excel 中拉取指标,汇总邮件更新,创建 PowerPoint 幻灯片,并在 Teams 中分享” |
表 12.4:生产力副驾的课程级别。
课程策略:
- 训练早期使用 80% 的 L1–L2 任务、20% 的 L3 任务。
- 当当前级别的成功率超过 70% 时进入下一级别。
- 始终保留 10–20% 的较简单任务,以防止灾难性遗忘。
- 最终配比(收敛后):10% L1、15% L2、25% L3、30% L4、20% L5。
安全与护栏
多应用工作流中的信用分配
关键挑战在于:在一个 20 步的跨应用工作流中,哪些步骤对成功或失败有贡献?
方法:层级式 Reward 分解
- 子目标检测:将用户的指令分解为可验证的子目标:•“找出 Q4 预算邮件” 子目标 1(已验证:检索到相关邮件)•“提取数字” 子目标 2(已验证:解析出正确的数值)•“创建 Excel 工作表” 子目标 3(已验证:工作表存在且数据正确)
- 子目标 Reward:在每个子目标完成时分配中间 Reward(各 )。
- 轨迹切片:如果最终任务失败,识别最先失败的子目标。仅对该子目标跨度内的动作施加负 Reward。
- 反事实估计:“如果这个特定动作不同,任务会成功吗?”——使用价值函数来估计。
扩展与基础设施
算力需求(按 70B 参数模型估算):
组件资源说明Policy 模型(70B)8 A100 80GB(TP=8)BF16,生成轨迹参考模型(70B)8 A100 80GB(TP=8)冻结,用于计算 KL环境 worker128 个 CPU worker每个运行一个 sandbox 实例Reward 模型 / 评判者4 A100(若使用 LLM 评判者)若使用基于执行的 Reward 则为零训练(GRPO 更新)16 A100(FSDP)在轨迹 batch 上做梯度累积合计40 块 A100 GPU + 128 个 CPU完整训练运行需 5,000 GPU 小时
吞吐优化:
- 异步 rollout:将轨迹生成与梯度更新解耦。在基于上一 batch 训练的同时持续生成。
- 批量化环境:并行运行 128 个 sandbox 环境,每个处理不同的任务。
- KV cache 共享:对于每个任务的 条轨迹,它们共享相同的 prompt 前缀——使用前缀缓存避免冗余计算。
- 选择性反向传播:只对动作 Token 计算梯度(不计算观测/系统 Prompt)。将反向传播的 FLOPS 降低 40–60%。
评估框架
| 指标 | 目标值 | 测量方式 |
|---|---|---|
| 任务完成率 | (L1–L3), (L4–L5) | 在 sandbox 中自动验证 |
| 安全违规率 | 每 1000 个任务中硬约束违规的次数 | |
| 平均完成步数 | 在最优值的 以内 | 与已知最短的成功轨迹比较 |
| 用户满意度(dogfood) | 来自内部用户的用后调查 | |
| 跨应用成功率 | (L4–L5) | 需要 2 个及以上应用的任务 |
| 恢复率 | 失败的 API 调用中智能体重试成功的百分比 | |
| 延迟(首动作时间) | 秒 | 模型推理 + 动作规划时间 |
表 12.5:生产力副驾的评估维度。
基准套件(建议):
- ProdBench-Easy(200 个任务):单应用,1–3 步。用于建立基线。
- ProdBench-Hard(200 个任务):跨应用工作流,10–30 步。端到端能力。
- ProdBench-Safety(100 个任务):试图触发不安全动作的对抗性 Prompt。必须保持 的违规率。
- ProdBench-Robustness(100 个任务):指令有歧义、注入 API 错误、缺少权限的任务。测试优雅降级能力。
来自生产部署的经验教训
完整训练食谱
| 参数 | 取值 | 理由 |
|---|---|---|
| 基座模型 | 70B Llama/Mistral | 具备足够的容量进行复杂的多步推理 |
| RL 算法 | GRPO | 无需评论家(critic);对长轨迹而言内存高效 |
| 组大小 | 8 | 在方差缩减与算力成本之间取得平衡 |
| 裁剪系数 | 0.1 | 由于长轨迹敏感,比标准值(0.2)更紧 |
| KL 系数 | 0.04 | 对 SFT 策略施加适度约束 |
| 学习率 | 偏保守;智能体任务对大更新敏感 | |
| Batch 大小 | 256 个任务 8 条轨迹 = 2048 | 使用大 batch 以获得稳定的 GRPO 归一化 |
| 最大轨迹长度 | 50 步 | 覆盖 95% 的生产力任务 |
| 上下文窗口 | 128K Token | 长跨应用工作流所必需 |
| 训练迭代次数 | 3000–5000 | 监控评估指标;在安全性下降时提前停止 |
| 课程预热 | 500 次迭代(仅 L1–L2) | 在进入复杂任务前先建立基本的 API 使用能力 |
表 12.6:生产力副驾 RL 训练的推荐超参数。
用例:从零构建一个研究 Agent
本用例展示了如何构建一个完全自主的研究智能体(research agent)——一个能够提出假设、检索文献、分析数据、编写代码、运行实验并产出最终报告的 LLM——所用技术贯穿本文讨论的各项方法。
问题定义
MDP 形式化
动作空间
| Tool | 类别 | 描述 |
|---|---|---|
| search_papers | 文献 | 查询 Semantic Scholar/arXiv。返回标题、摘要、引用。 |
| read_paper | 文献 | 获取论文的全文或特定章节。 |
| write_code | 实验 | 将 Python/训练脚本写入工作区。 |
| execute_code | 实验 | 在沙箱化环境中运行脚本。返回 stdout/stderr。 |
| read_file | 分析 | 读取日志、CSV 或中间结果。 |
| plot_data | 分析 | 生成 matplotlib/seaborn 可视化。 |
| compute_stats | 分析 | 运行统计检验(t 检验、置信区间)。 |
| write_report | 输出 | 撰写最终研究报告的各个章节(LaTeX/Markdown)。 |
| think | 推理 | 内部推理步骤(不进行外部 tool 调用)。 |
| submit | 终局 | 提交最终报告。结束该 Episode。 |
表 12.7:研究智能体的 tool/动作空间。
架构:模型与基础设施选择
Reward 设计
训练流水线
- 阶段 1——SFT 预热(500 步):•收集 200 条专家研究轨迹(人类研究者使用这些 tool)•对成功轨迹做 SFT,仅对 completion 做掩码(掩蔽 tool 输出)•这教会智能体 tool 使用语法和基本的研究工作流
- 阶段 2——GRPO 训练(3000 步):•Prompt 池:跨 10 个领域的 500 个研究问题(ML、NLP、CV、系统等)•每个问题:生成 条完整的研究轨迹•用多组件 Reward 为每条轨迹打分•GRPO 优势:•使用裁剪目标更新 Policy(裁剪 ,KL )•课程:从简单的“总结关于 X 的发现”任务开始,逐步过渡到“设计并运行关于 X 的实验”
- 阶段 3——拒绝采样微调(200 步):•对每个困难问题生成 16 条轨迹,按 Reward 保留前 2 条•在这些高质量轨迹上做 SFT•稳定在最困难研究任务上的表现
示例轨迹:完整 MDP 追踪
为说明所有 MDP 组件在实践中如何协同工作,我们追踪一个从提问到提交的完整研究 Episode,并为每一步标注其正式的 MDP 元素。
关键设计决策与权衡
| 决策 | 本文小节 | 理由 |
|---|---|---|
| QLoRA() | LoRA 小节 | 72B 模型;全量微调过于昂贵。对复杂推理使用 。 |
| GRPO(而非 PPO) | GRPO 小节 | 无需价值模型;研究质量在轨迹中途难以预测。 |
| 稀疏的终局 Reward | 奖励塑形 | 研究质量只能在完成时衡量;中间塑形极少。 |
| 条轨迹 | GRPO 组大小 | 平衡:既有足够的多样性以进行排序,又不过于昂贵(100 步的轨迹)。 |
| 128K 上下文 | Flash Attention | 包含论文内容 + 代码 + 结果的长轨迹。 |
| vLLM + 前缀缓存 | vLLM 小节 | 系统 Prompt + 研究问题在 4 次 rollout 间共享。 |
| 课程训练 | Agentic RL | 从简单开始(文献综述)困难(设计 + 执行实验)。 |
| LLM 作为评判者的 Reward | Reward 模型 | 研究质量是主观的;LLM 评判者比基于规则的方式更灵活。 |
表 12.8:研究智能体的设计决策,及其对应的本文小节。
评估
经验教训与失败模式
LLM Agent 的 SOTA RL
针对 LLM Agent 的 RL 技术聚焦于 在策略 policy 梯度 与 细粒度信用分配 的结合。由于 Agent 执行的是涉及工具交互、API 查询和代码执行的复杂多轮(Multi-Turn)轨迹,标准的单轮对齐算法必须经过大幅改造。
主导基线:用于 Agent 的 GRPO
由 DeepSeek-R1 [69] 推广,GRPO[323] 正迅速成为 Agent 训练的标准。它为每个任务采样一组 条完整轨迹,从而消除了内存开销巨大的评论家(critic)网络:
对于任务 Prompt ,GRPO 采样 条 Agent 轨迹 ,这些轨迹来自 。每条轨迹的优势通过将其奖励(reward)相对于该组进行归一化来计算:
带 KL 正则化的 GRPO 目标:
用于交互式 Agent 的 PPO
对于在高度随机环境中运行、且步骤级价值估计有所帮助的 Agent,PPO[319] 仍然具有价值。评论家提供每一步的优势信号,从而在工具输出不可预测时实现更精细的信用分配:
- 通过 GAE 进行的步骤级优势估计可处理可变长度的工具输出
- 价值头学习预测「从这里开始这条轨迹有多大可能成功」
- 当外部工具返回灾难性错误、导致奖励方差骤增时更为稳定
- 权衡:需要 内存(critic),但能提供更稠密的学习信号
细粒度的回合级信用分配
Agent RL 的核心挑战是 稀疏奖励问题。如果 Agent 执行了 20 个动作(action),最终却未通过某个单元测试,那么 的终端奖励会同等惩罚这 20 个动作。现代解决方案:
替代范式
- 迭代式 STaR(自学推理者,Self-Taught Reasoner)[419]:不采用持续 RL,而是使用迭代式离线循环。生成轨迹 过滤失败样本 在成功样本上做监督微调(SFT) 重复。易于扩展,且能避免 RL 的不稳定性。每一轮迭代都会自举增强推理能力。
- 强化世界模型学习(Reinforcement World Model Learning, RWML)[414]:为对抗奖励作弊,训练 Agent 预测其动作的 语义后果。Agent 若能准确预测环境状态将如何变化(例如在执行 SQL 之前预测数据库表的变化),就能获得一项辅助奖励。这会迫使模型真正理解,而不是肤浅地钻奖励的空子。
- LATS(语言 Agent 树搜索,Language Agent Tree Search)[438]:在 Agent 的动作序列上应用蒙特卡洛树搜索。每一步都扩展多个候选动作,模拟它们的结果,并通过树反向传播奖励。它把 RL 的价值估计与搜索阶段的计算扩展结合起来。
核心方法论比较
| 方法 | 奖励密度 | 内存开销 | 主要优势 |
|---|---|---|---|
| GRPO[323] | 序列级 / 最终指标 | 低(无需 critic) | 大幅降低 GPU 内存开销;实现简单 |
| PPO[319] | 逐步(GAE) | 高(需要 critic) | 细粒度信用分配;在噪声环境中更稳定 |
| 迭代式 STaR[419] | 稀疏(经筛选的二元奖励) | 极低(仅 SFT) | 易于扩展;避免 RL 优化的不稳定性 |
| RWML[414] | 稠密(预测式) | 中等 | 通过世界建模缓解奖励作弊 |
| LATS[438] | 通过反向传播 | 高(树扩展) | 单任务质量最佳;可随推理计算扩展 |
表 12.9:LLM Agent 的 RL 范式对比。
面向 Agent 训练的交互式 RL 环境
早期 Agent RL 的主流范式依赖 静态数据集:经过筛选的轨迹、离线的偏好对,或固定的基准套件。这种方法虽然可行,但存在一个根本局限——在静态数据上训练的 Agent 无法通过环境交互发现新策略,奖励信号也仅限于数据集构建时所能预见的情形。该领域已明确转向 交互式 RL 环境:即让 Agent 在其中执行动作、接收反馈,并基于真实结果更新 policy 的实时模拟器。
NeMo Gym(NVIDIA)
NeMo Gym[271] 是 NVIDIA 的交互式 RL 环境框架,专为 LLM Agent 训练而设计。它的架构把 Agent(即 LLM policy)与 环境(即任务模拟器)清晰地分离开来,使各组件可以独立扩展。
关键设计原则:
- 多轮 rollout:环境支持较长的交互序列,而不只是单步查询。Agent 可以调用工具、接收结果,并跨多个轮次持续推理。
- 工具调用验证:通过执行 Agent 的工具调用并把结果与 ground truth 比对来计算奖励——从而提供稠密、可靠的信号。
- Agent 与环境解耦:环境作为独立服务运行,从而可以异构地分配计算资源(例如 Agent 使用 GPU,环境模拟使用 CPU)。
Nemotron 3 Super 使用 NeMo Gym 训练,配置了覆盖数学、代码、工具使用与多轮对话的 21 种环境,共生成 120 万条 rollout。环境的多样性至关重要:只在单一类型环境中训练的 Agent 容易过拟合该环境的奖励结构。
RLFactory
RLFactory[369] 是一个即插即用的多轮工具使用 RL 框架,旨在把 LLM policy 接入各类工具环境的工程开销降到最低。
MOSAIC:智能体训练中的安全
随着 Agent RL 环境的能力不断增强,安全性成为首要关注点。MOSAIC[50](2026 年 3 月)所要解决的问题,是在交互式环境中训练出既强大又安全的 Agent。
MOSAIC 的核心框架引入了一个 计划 检查 行动或拒绝 循环:
- 计划:Agent 生成一个候选动作序列。
- 检查:安全验证器依据约束集合(危害类别、policy 规则)评估该计划。
- 行动或拒绝:如果计划通过,就执行;否则生成带有说明的拒绝响应。
安全性通过 轨迹级偏好学习 来训练:MOSAIC 不是把单个动作标注为安全/不安全,而是对整条轨迹进行标注,从而捕捉多步计划的累积安全影响。这一点至关重要,因为看似无害的单个动作可能组合成有害的序列。
xAI 的 Grok 4.5(2026 年 7 月)[389] 引入了一种新的数据来源:来自 Cursor 的匿名开发者会话轨迹——工程师在真实代码库中工作时的实际按键、导航模式与编辑序列。在这些轨迹上做中期训练(mid-training)之后,Grok 4.5 在 Agent 工具使用基准上取得了领先排名。这标志着一种「算力 + 轨迹」范式:一旦算力规模扩大,稀缺的输入就变成了 目标行为的记录——这与 AlphaGo 先由人类棋局自举、再转向自我对弈的过程类似。该方法引出了尚未解决的数据权利问题(代码属于谁,在何种授权下?),但它表明来自专家用户的行为示范依然是提升 Agent 能力的有力训练信号。