面向工具使用与多步任务的强化学习

深入解析 · 训练智能体模型

面向工具轨迹的 RL：稀疏奖励、长程与可核验信号。

单轮 RLHF 优化一次回答。智能体 RL 优化一条轨迹：一串模型轮次与工具调用、环境响应交错的序列，主要由终态是否正确来评判。这一转变打碎了 RLHF 容易的部分——奖励稀疏且仅在终点出现，信用必须在许多步之间分配，且环境如今成了训练系统的一部分。本文讲为何工具使用 RL 很难，以及什么让它变得可行：可核验的奖励与有纪律的环境设计。

STEP 1

优化的单位是轨迹，而非一轮

一次 rollout 现在长这样：s0 → a0 → tool → o0 → a1 → tool → o1 → … → done。策略发出动作；环境发出观测；奖励通常只在 done 到来。模型被训练在长程下的部分可观测中行动，而它发出的多数 token 是工具调用的管道，不是你在意的那个东西。这更接近经典 RL 而非 RLHF，连同后者所有的不稳定性。

STEP 2

稀疏的终端奖励与信用分配问题

若一个 14 步的任务失败了，哪一步是错误？单一终端标量几乎不给策略任何关于哪里出错的信息，只告诉它确实出错了。稀疏奖励下每步的梯度信号微小且高方差；策略需要海量样本才能学到哪些动作要紧。

# Sparse, terminal: one scalar for the whole trajectory
r = verify(final_state)        # 1.0 if correct else 0.0
# every step shares the same return -> weak credit assignment
for step in traj:
    advantage[step] = r - baseline(step)

这是核心难点。缓解手段：缩短程长、用组相对基线（GRPO）在同一任务上比较多条轨迹以从二元结果中榨出信号，以及——在你负担得起时——逐步奖励（见 T6）。诚实的表述：稀疏奖励的长程 RL 极耗样本且不稳定；你靠环境与奖励设计去对抗它，而非优化器技巧。

STEP 3

可核验奖励才是让这一切根本可行的东西

代码与数学之所以是智能体 RL 的突破领域，是因为它们有便宜、程序化、难以被博弈的核验器：测试过没过、证明能不能被核验、SQL 是否返回预期行。可核验奖励是客观的、能规模化到数百万 rollout，并对困扰习得奖励模型的奖励黑客有抵抗力。

# Verifiable reward: an executable oracle, not a learned RM
r = 1.0 if run_tests(agent_patch) else 0.0

设计工具使用 RL 之前先问：成功有没有一个便宜的程序化谕示？有，你就有一个强项目。若成功只能由模型或人类评判，你就有一个难得多、贵得多、更可被黑的项目——先把核验器解决掉。

STEP 4

环境如今是模型的一部分

在智能体 RL 中，训练分布是通过与环境交互生成的，所以环境的性质成了训练的性质。它必须确定到足以成为稳定信号、快且可并行到足以支撑数百万 rollout、被沙箱化使智能体无法作弊或造成伤害，且可重置到干净状态。一个 5% 概率超时的不稳定工具会注入 5% 的奖励噪声，策略会乐于学会利用它，或被它搞糊涂。

多数工具使用 RL 的失败是环境 bug，不是算法 bug：非确定性工具、过期夹具、有漏洞的核验器、把答案泄进观测的环境。策略必然会找到每一个。对待环境要比对待训练代码更严苛。

STEP 5

工具使用 RL 为何真的难——具体地说

程长——方差随步数累积；30 步任务比 3 步任务有多得多的失败方式，而稀疏奖励只看终点。
部分可观测——策略基于一个上下文窗口行动，那是真实状态的有损视图；工具输出可能巨大、被截断或具误导性。
探索成本——每次 rollout 都跑真实工具；探索比采样文本 token 贵几个数量级。
奖励稀疏——二元终端信号、弱的逐步信用、高方差梯度。
分布漂移——随着策略改进，它会访问核验器与环境从未被测试过的状态。

这些没有一个是致命的，但合在一起就解释了为何工具使用 RL 比训练梯子上任何其他一级都需要更多基础设施、更多算力，以及更审慎的评估。

STEP 6

何时不要做工具使用 RL

没有便宜核验器就跳过它（你会在被改进之前先被奖励黑客）；若程长长到没有你负担不起的过程奖励就无望做信用分配，跳过；若在几千条强轨迹上做 SFT 已经达标——它通常以一小部分成本带你走完大半路——也跳过。工具使用 RL 恰在成功易核验、难示范时见效；没有可信核验器，你训练的不是智能体，是一个奖励利用者。