多步工具调用 RL 为何会崩？监督信号如何救场

关联论文：2606.26027
作者：spark
更新：2026-07-10

一句话结论：tool-use 场景下纯 RL 训练容易"突然崩盘"，不是能力没了，而是少数控制 token 的概率出现尖峰把生成结构打坏。把 SFT 与 RL 交错训练能稳住训练，但 OOD（分布外）评测会掉点；要在交错基础上叠加多样化监督信号（off-policy 示范、错误示范、提示性 hint 等），同步与异步方案各有取舍，才能换得既稳又泛的 tool-use 策略。

解决的真问题

Agentic RL 在数学、代码单步任务上成绩亮眼，但一进入多步工具调用场景（Search → Read → Code → Test → Submit 这种长链路），训练曲线就开始"莫名其妙"地塌：

灾难性塌缩（catastrophic collapse）：训练中段 reward 突然掉到接近 0，工具调用结构也开始乱（多出括号、错位 JSON、工具名乱码）。
塌了 ≠ 不会：检查发现模型在某些格式/路径上仍然能答对，只是被概率尖峰"遮住"了。
纯 RL 不稳 / 纯 SFT 不泛：只加 SFT 解决了格式稳，但探索不够；只跑 RL 又塌。两者怎么排、怎么配、信号从哪来，是个开放题。

论文系统地拆解了"崩在哪"和"哪种监督信号能稳住、哪种会过拟合"。

核心方法：定位塌缩 + 监督信号调度

1. 塌缩根因：控制 token 的概率尖峰

作者在多个模型/多个 tool-use benchmark 上观察到一个反复出现的现象：塌缩发生时，特定控制 token（如 <tool>, </tool>, {}, :, 引号）上出现不正常的概率尖峰。一旦这些 token 概率压过工具名/参数 token，模型就会吐出半截结构化内容，后续解析失败、reward 反馈为 0、梯度继续压那些 token，形成正反馈。

这意味着两件事：

能力没丢：把控制 token 概率抹平后，模型在相同状态下的"理想下一步"分布与未塌缩版本差异很小。
修复点不在策略目标本身：在 reward shaping / 长度惩罚 / entropy bonus 上做文章，是绕远路；要直接处理 token-level 概率分布异常。

2. 监督信号库

为对冲塌缩，作者系统测试了多种监督信号（按是否需要"正确答案"区分）：

信号类型	形式	直观作用
off-policy 示范	用 teacher / 历史 checkpoint 生成的成功轨迹做 SFT	给一个"安全区"，把控制 token 概率拉回正常带
hint-based 引导	在 prompt 中给"先列步骤再调用工具"等提示	引导探索方向，不直接给答案
错误示范监督	故意展示反例轨迹并附解释	让模型学会"什么样的格式会失败"，从反面拉结构
格式/工具 schema 约束	强制结构化输出 / schema 校验	把尖峰可能性从源头切掉
过程级 reward + 终止奖励	工具调用合法即给稠密 reward	解决稀疏 reward 下 RL 找不到方向
多任务混合采样	不同 tool-use 任务按比例混 batch	缓解 OOD 退化

3. 训练调度：同步 vs 交错

作者把"RL 与 SFT 怎么排"作为单独变量考察，给出两种基本范式：

同步（synchronous）：每条 query 先用当前策略 rollout → 用 SFT 损失对 rollout 中的"好"样本做一次额外梯度更新 → 再做 RL 更新。SFT 与 RL 共享同一批样本。
交错（interleaved）：把 SFT 数据与 RL rollout 数据按固定节奏切换（典型如每 N 步 RL 之后做一次 SFT 步），SFT 数据来自 off-policy 池。

关键实验结论：

交错训练稳定性显著优于同步：交错不会像同步那样出现尖峰反复——SFT 步像"冷却"过程，把控制 token 概率拉回正轨后，RL 再去探索下一片区域。
交错在 OOD 评测上掉点：格式 OOD（控制 token 名字换了、工具 schema 改了）下交错模型明显退化；同步训练 OOD 表现相对更好。
同步在 in-distribution 上限更高：同一任务族、同一格式下，同步训练的 reward 略高。
错误示范监督可以缓解交错 OOD 掉点：把"错在哪个格式"显式喂给模型，相当于给 SFT 数据加对抗性。

4. 学习率与泛化

RL 步学习率过大会显著放大控制 token 尖峰，塌缩更早；中等 RL lr + 较大 SFT lr 的非对称配置在多个模型上最稳。
泛化到新工具族（学过的 search/edit 类 → 没学过的 browser 类）：仅用 SFT 难以迁移，错误示范 + 交错 SFT 的组合迁移最好；纯 RL 几乎迁移不动。

5. 伪代码风格的核心流程（交错方案）

init policy π_θ, SFT_pool, tools, tasks
for step in 1..T:
    if step mod (K_RL + K_SFT) < K_RL:
        # RL 阶段：与环境交互
        rollouts = rollout(π_θ, tasks, tools)
        rewards = judge(rollouts)            # 过程级 + 终止奖励
        update π_θ via PPO/GRPO on rollouts
    else:
        # SFT 阶段：拉回控制 token
        batch = sample(SFT_pool)             # 含正常 + 错误示范 + hint 提示
        update π_θ via cross-entropy on batch
        # 监控：若某控制 token 概率 > 阈值则触发紧急 SFT
        if max_token_prob(π_θ, control_tokens) > τ:
            emergency_sft_step(π_θ, SFT_pool)

emergency_sft_step 是论文隐含的实操经验：当监控到控制 token 概率超阈值，强行插入一次 SFT 步，比任何 entropy bonus 都管用。

关键实验与数据要点

多模型：在论文覆盖的实验里，多个 7B–70B 级别开源与商用闭源模型都观察到 control-token 尖峰，提示这是 tool-use RL 的结构性问题而不是某个模型的 bug。
任务族：包含 web search 类、code execution 类、file operation 类等多步工具链。
关键定量（论文摘要与正文表述）：交错训练相对纯 RL 显著降低塌缩概率；OOD（格式/内容 OOD）下交错模型准确率相对同步训练明显退化（原文未给出统一数值表，以任务族内对比报告）；错误示范监督是缓解 OOD 退化的最有效单一信号。
学习率敏感性：RL lr 偏大时塌缩出现时机前移；不对称 lr（SFT lr 较大）是稳态最高配。
代码开源：Tool-RL-Box 提供训练 pipeline。

亮点

定位到 token-level 机制：把"agentic RL 塌缩"这个黑盒现象拆到控制 token 概率尖峰，给出可观测、可监控的诊断信号。
监督信号库系统化：不是只加 SFT 一招，而是把 off-policy、hint、错误示范、schema 约束、过程奖励等列成统一实验变量。
同步 vs 交错的清晰取舍：明确给出"交错稳但 OOD 弱、同步上限高但易尖峰"的 trade-off，并指出错误示范是补偿手段。
可落地的工程经验：紧急 SFT 步、非对称 lr、控制 token 概率监控——全是直接能在生产 pipeline 加上的。
开源代码：Tool-RL-Box 直接复用，门槛低。

局限

任务族与模型覆盖仍有限：tool-use 任务主要是 search/code/file 三类，对 browser-use、GUI 操控、长链路 (10+ 步) 任务的外推性需要再验证。
定量数据不够公开统一：原文中"显著降低塌缩"等表述以图表形式给出，未在摘要里给统一数值表，本文不便给出确切百分比。
错误示范的构造成本：错误示范的"反例"怎么造、按什么分布采样，原文未完全展开；实践中可能需要专门做数据管线。
emergency SFT 的触发阈值 τ：是经验值而非自适应；对不同模型族未必通用。
奖励模型本身：用 judge 模型打分的过程级 reward 仍受 judge 偏差影响，论文未深入讨论 judge 的稳定性。
未明确给出与具体 SOTA 的 head-to-head 数字：相对于同期 RL+tool-use 工作（如 ToolLLM、ReAct、Search-R1 等）的统一 benchmark 头对头比较未在摘要中量化呈现。

对工程落地的启发

必加监控：把"控制 token 概率分布"作为 agentic RL 训练的标准面板。出现尖峰 → 立刻 SFT，比改 reward / 改 prompt 都快。
交错优于同步当稳定性优先：生产环境里 1 次崩盘 = 1 次停机 + 半天排查，交错更划算；同步方案用于内部 benchmark 冲上限。
数据配比：SFT 池里正常轨迹:错误示范:hint 提示 ≈ 5:3:2（凭经验，可按任务族调）是论文验证下的较稳组合。
学习率非对称：SFT lr 比 RL lr 高一个量级是常见稳态配。
过程级 reward：避免在多步链路里只用终止 reward，工具调用合法即给分，让 RL 拿到更密的梯度。
格式与 schema 强约束：用 JSON schema / grammar 约束解码，把尖峰的"自由度"从源头压住。
OOD 评测必须做：训练集 + 格式换名 + 工具换名都要测，避免交错方案上线后在新格式下崩。
错误示范即数据：收集线上失败 case → 反例标注 → 灌入 SFT 池，是性价比最高的增量。

与同方向工作的关系

ToolLLM / ToolBench：提供大规模工具调用数据与训练范式；本文贡献主要在"训练阶段稳定性与 OOD 行为"。
ReAct / Reflexion / AutoAgent：提示工程层面的反思与重试，互补；本文提供训练阶段的对策。
Search-R1 / ZeroSearch / DeepRetrieval：检索类 RL 的成功范式，本文结论"交错稳但 OOD 弱"与其训练实践一致。
OpenRLHF / Verl / TRL 等 RL 框架：在 PPO/GRPO 之上，本文是 agentic tool-use 场景下的具体工程调参指南。
PRM / Process Reward Model：本文的"过程级 reward + 终止奖励"思路与近期 process reward 工作方向一致，互补。
Agentic SFT 数据工作（如 OpenThoughts、OpenCodeReasoning）：本文给出的"控制 token 尖峰"诊断为这些数据集的清洗/过滤提供新视角。

适合谁读

Agent / RL 训练工程师：在生产里训过 tool-use 策略并遇到过塌缩的读者，强烈推荐；几乎所有监控点都可直接抄。
RL 算法研究者：关心 agentic RL 收敛性、token-level 概率动力学、actor-critic 在长链路任务上的稳定性问题。
LLM 平台架构师：评估"RL 训练 tool-use agent"在生产管线的成本/收益比。
Agent 评测团队：把 OOD 评测纳入标准面板，避免训练-部署格式漂移。
不特别适合：仅做单轮 LLM 应用的读者、纯 prompt 工程师——除非需要把自家 agent 升级到多步 tool-use，否则本文调参经验用不到。

关键 takeaway

Agentic tool-use RL 崩的不是能力，是控制 token 的概率分布。 交错 SFT+RL 是稳定性首选；同步训练上限更高但易尖峰；叠加错误示范监督可以补 OOD；控制 token 概率监控 + 紧急 SFT 是最便宜的熔断器；过程级 reward + schema 约束从源头压住尖峰。格式与工具名只要变化，就要重测。

工程落地与核查（Jay）

事实核查摘要

断言	核查结论	备注
"控制 token 概率尖峰导致灾难性塌缩"	claim 成立，来自 abstract 的核心观察	但具体是哪些 token 在哪些任务上尖峰，需回正文 §3 核验
"交错训练稳定性显著优于同步"	方向性可信，abstract 有明确结论	但"显著"是定性描述，无具体数字，解读诚实标注了这一点
"交错在 OOD 上掉点，同步在 ID 上限更高"	可信，abstract 明确描述了 trade-off	同样无具体数字
"错误示范监督是缓解 OOD 退化的最有效单一信号"	可信，abstract 明确
"RL lr 偏大时塌缩时机前移；非对称 lr 最稳"	可信，对应 abstract §4 的学习率分析
"多个 7B–70B 开源与闭源模型都观察到尖峰"	规模 claim 可信，abstract 提到多模型	但具体模型名单需回原文核验
GitHub: https://github.com/hypasd-art/Tool-RL-Box	需核实，abstract 未给出链接	需回原文 §5 或项目页确认
SFT_pool 配比 5:3:2	经验值，非原文精确数字	解读已在 §5 标注为"凭经验"，未误导

可读性精修建议

"GRPO" 首次出现在伪代码注释中，未做说明。GRPO（Group Relative Policy Optimization）是近期 RL 算法变体，非所有读者熟悉，建议加注"（一种无需 value model 的 RL 算法）"。
"emergency_sft_step" 是从 emergency_sft_step(π_θ, SFT_pool) 伪代码推断的函数名，解读中用了"紧急 SFT 步"描述——这个措辞是推断而非原文精确翻译，建议改为"应急 SFT 步（emergency SFT step）"并标注为推断。
§2 监督信号库表格 中"过程级 reward + 终止奖励"的"终止奖励"指 final reward，与过程级（每步 reward）相对，中文表意清晰，无需修改。
"错误示范监督" 一节的"反例标注"说法在解读的"工程落地"节出现，但原文对错误示范的构造方式未展开，建议加注"实践中需要专门的数据管线"以诚实说明工程实现不确定性。

工程落地关键点

1. 实际系统怎么用

tool-use agent 的 RL 训练建议 pipeline：

数据准备
  ├─ 正例轨迹（成功执行轨迹）→ SFT_pool 正常部分
  ├─ 错误示范轨迹（已知失败 case）→ SFT_pool 错误部分
  └─ hint prompt 模板 → SFT_pool hint 部分

训练循环（交错方案）
  for step in 1..T:
      if RL phase:
          rollout → PPO/GRPO update
          监控: max(control_token_prob) > τ? → 触发 emergency SFT
      else SFT phase:
          sample from SFT_pool (5:3:2)
          cross-entropy update

监控面板（生产必需）
  ├─ 控制 token 概率分布直方图（每 100 step）
  ├─ reward 曲线（每 epoch）
  └─ OOD 评测（每 N epoch）

2. 主要坑

控制 token 的定义需要先验知识：不同模型系（Qwen vs Llama vs Mistral）的控制 token 集合不同，需要先做 token-level 分析找出"危险 token 集合"，而不是直接套用论文的 <tool> 等符号。
τ 阈值是经验值：0.7~0.9 是常见范围，但不同模型差异大。需要先做消融实验确定合适阈值，而非直接照搬。
错误示范的构造瓶颈：错误示范需要人工或 LLM 辅助标注，且要覆盖"真实的失败分布"而非随机噪声。构造质量直接影响缓解 OOD 退化的效果。
交错节奏（K_RL : K_SFT）的经验性：论文未给出通用最优比例，需要在具体任务上做 grid search。开始可尝试 5:1 或 10:1。
judge model 的偏差：过程级 reward 依赖 judge 模型，judge 本身的分布偏差会传导给 agent policy。需要在 judge 本身做偏差检测（如 DIF 分数）。
格式 schema 变化时的灾难性：工具名/参数名/schema 任何变化都会触发 OOD 退化，需要建立 schema 版本管理机制。

3. 可行性评估

短期（1–2 月）：在现有 RL pipeline 里加入控制 token 概率监控 + emergency SFT 熔断，技术成本低，立竿见影。
中期（3–6 月）：构建错误示范数据管线 + schema 约束解码，是主要的工程投入。需要配套的标注平台和 schema 校验逻辑。
长期（季度+）：建立完整的 OOD 评测体系 + 自适应 τ 阈值，是持续运营成本。
预期收益：控制 token 概率监控 + emergency SFT 是目前已知的最低成本塌缩预防方案，建议作为 tool-use RL 训练的标配。

4. 与竞品工程取舍

方案	训练稳定性	OOD 泛化	工程成本	备注
纯 RL	❌（塌缩）	中	低	不推荐多步 tool-use
纯 SFT	✅	❌（过拟合）	低	只适合任务固定场景
交错 SFT+RL（本文）	✅	⚠️（掉点）	中	稳定性首选，OOD 需额外补偿
同步 SFT+RL	✅（更稳）	✅（ID 上限高）	中	适合内部冲 benchmark，prod 有尖峰风险
+ 错误示范监督	✅	✅（缓解 OOD）	中高	推荐生产配置

推荐生产配置：交错 + 错误示范 + 过程 reward + 控制 token 监控，同步方案仅用于离线评测冲榜。