为什么 AI 帮你点外卖订机票时,经常在第三步突然"崩"成一团乱码?——一篇论文告诉你:崩的不是能力,是 5 个特殊 token 的概率压过了正确选项
- 关联论文：2606.26027（多步工具调用强化学习为何崩溃及监督信号如何修复 · spark · 2026-07-10 更新）
你大概遇到过这种场景:
让 ChatGPT/Agent 帮你"先搜资料,再写邮件,再订机票"——前两步还很顺,到了第三步,模型突然开始吐
}}}}}{、"""{"这种半截 JSON,工具名乱码,然后整个任务崩盘,reward 直接归零。
很多用户的第一反应是:模型不行,能力不够。
arXiv 2606.26027 这篇论文做了一件有意思的事——它去监控训练时的概率分布,然后告诉你:崩的不是能力,是 5 个"控制 token"的概率压过了正确答案。
论文核心结论:
多步工具调用场景下纯强化学习(RL,Reinforcement Learning,通过环境反馈让模型自我改进的训练方法)训练容易"突然崩盘",不是模型不会了,而是少数控制 token(如
<tool>,</tool>,{,:, 引号)的概率出现尖峰,把生成结构打坏。把 SFT(Supervised Fine-Tuning,用人工示范数据继续训练)与 RL 交错训练能稳住训练,但分布外(OOD,Out-of-Distribution,即"训练时没见过的格式")评测会掉点;要在交错基础上叠加多样化监督信号(离线示范、错误示范、提示性 hint 等),同步与异步方案各有取舍,才能换得既稳又泛的 tool-use 策略。
为什么这件事重要? 因为它意味着——AI Agent 训练里最常见的那种"突然崩盘"事故,有明确的诊断信号和工程熔断器,不再是"训着训着就废了,只能从头开始"。
它到底解决什么真问题
Agentic RL(让 Agent 通过环境反馈自己学习的训练方式)在数学、代码单步任务上成绩亮眼,但一进入多步工具调用场景(Search → Read → Code → Test → Submit 这种长链路),训练曲线就开始"莫名其妙"地塌。三种典型塌法:
- 灾难性塌缩(catastrophic collapse):训练中段 reward 突然掉到接近 0,工具调用结构也开始乱——多出括号、错位 JSON、工具名乱码。
- 塌了 ≠ 不会:检查发现模型在某些格式/路径上仍然能答对,只是被概率尖峰"遮住"了。
- 纯 RL 不稳 / 纯 SFT 不泛:只加 SFT 解决了格式稳,但探索不够;只跑 RL 又塌。两者怎么排、怎么配、信号从哪来,是个开放题。
论文系统地拆解了"崩在哪"和"哪种监督信号能稳住、哪种会过拟合"。
它怎么 work:三步拆解
1. 崩的根因:控制 token 的概率尖峰
作者在多个模型/多个 tool-use benchmark(基准测试)上观察到一个反复出现的现象:塌缩发生时,特定控制 token(如 <tool>, </tool>, {}, :, 引号)上出现不正常的概率尖峰。一旦这些 token 概率压过工具名/参数 token,模型就会吐出半截结构化内容,后续解析失败、reward 反馈为 0、梯度继续压那些 token,形成正反馈。
这意味着两件事:
- 能力没丢:把控制 token 概率抹平后,模型在相同状态下的"理想下一步"分布与未塌缩版本差异很小。
- 修复点不在策略目标本身:在 reward shaping(奖励塑形,人为调整奖励函数让训练更稳)/ 长度惩罚 / entropy bonus(熵奖励,鼓励模型探索多样性)上做文章,是绕远路;要直接处理 token-level 概率分布异常。
2. 监督信号库:六种"止崩药"系统对比
为对冲塌缩,作者系统测试了多种监督信号(按是否需要"正确答案"区分):
| 信号类型 | 形式 | 直观作用 |
|---|---|---|
| 离线示范(off-policy) | 用历史 checkpoint(训练中间快照)生成的成功轨迹做 SFT | 给一个"安全区",把控制 token 概率拉回正常带 |
| hint 引导 | 在 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 数据来自离线池。
关键实验结论:
- 交错训练稳定性显著优于同步:交错不会像同步那样出现尖峰反复——SFT 步像"冷却"过程,把控制 token 概率拉回正轨后,RL 再去探索下一片区域。
- 交错在 OOD 评测上掉点:格式 OOD(控制 token 名字换了、工具 schema 改了)下交错模型明显退化;同步训练 OOD 表现相对更好。
- 同步在分布内(in-distribution)上限更高:同一任务族、同一格式下,同步训练的 reward 略高。
- 错误示范监督可以缓解交错 OOD 掉点:把"错在哪个格式"显式喂给模型,相当于给 SFT 数据加对抗性。
关键实验与数据要点
- 多模型覆盖:多个 7B–70B 级别开源与商用闭源模型都观察到控制 token 尖峰,提示这是 tool-use RL 的结构性问题而不是某个模型的 bug。
- 任务族:包含 web search 类、code execution 类、file operation 类等多步工具链。
- 学习率敏感性:RL 学习率偏大时塌缩出现时机前移;SFT 学习率较大 + RL 学习率较小的非对称配置在多个模型上最稳。
- 代码开源:Tool-RL-Box 提供训练 pipeline。
⚠️ 诚实标注: - "交错训练显著优于同步" / "交错 OOD 掉点" / "错误示范监督是缓解 OOD 退化最有效单一信号"——均为摘要级定性结论,原文以图表形式给出,未在摘要中给出统一数值表,本文不便给出确切百分比。 - 论文摘要未明确给出与 ToolLLM / ReAct / Search-R1 等同期 SOTA 的 head-to-head 统一 benchmark 数字。 - "多个 7B–70B 模型都观察到"是规模 claim,具体模型名单需回正文核验。 - 累积应力窗口等具体超参数在摘要中未完整披露。
数字 vs. 实际落地
工程上你可能踩到的坑:
| 坑 | 描述 | 解法 |
|---|---|---|
| 控制 token 定义需要先验知识 | 不同模型系(Qwen / Llama / Mistral)的控制 token 集合不同,直接套用 <tool> 等符号会失效 |
先做 token-level 分析找出"危险 token 集合",不要照搬论文符号 |
| τ 阈值是经验值 | 论文未给通用最优值,0.7~0.9 是常见范围,但不同模型差异大 | 先做消融实验确定合适阈值,不要直接抄 |
| 错误示范构造瓶颈 | 错误示范需要人工或 LLM 辅助标注,且要覆盖"真实的失败分布"而非随机噪声 | 收集线上失败 case → 反例标注 → 灌入 SFT 池,性价比最高 |
| 交错节奏的经验性 | 论文未给通用最优比例(K_RL : K_SFT) | 开始可试 5:1 或 10:1,在具体任务上做网格搜索 |
| judge model 偏差 | 过程级 reward 依赖 judge 模型,judge 偏差会传导给 agent policy | 在 judge 本身做偏差检测(如 DIF 分数) |
| 格式 schema 变化时的灾难性 | 工具名/参数名/schema 任何变化都会触发 OOD 退化 | 建立 schema 版本管理机制 |
为什么这件事对从业者重要
- 崩的不是能力,是控制 token——这个诊断让"训练突然崩盘"从玄学变成可监控的工程问题。
- 监控点比改 reward 更管用:比起调奖励函数/加 entropy bonus,在标准面板里加上"控制 token 概率分布直方图"立竿见影。
- emergency_sft_step 是最便宜的熔断器:监控到控制 token 概率超阈值 → 强行插入一次 SFT 步,比任何奖励工程都管用。
- 交错 vs 同步不是孰优孰劣,而是稳定性优先还是上限优先——生产选交错,离线冲榜选同步。
- 错误示范即数据:线上失败 case 反例标注 → 灌入 SFT 池,是被低估的性价比最高的增量。
必须警惕的边界
- 任务族与模型覆盖仍有限:tool-use 任务主要是 search/code/file 三类,对 browser-use、GUI 操控、长链路 (10+ 步) 任务的外推性需要再验证。
- 定量数据不够公开统一:原文中"显著降低塌缩"等表述以图表形式给出,未在摘要里给统一数值表。
- 错误示范的构造成本:错误示范的"反例"怎么造、按什么分布采样,原文未完全展开;实践中需要专门的数据管线。
- emergency SFT 的触发阈值 τ:是经验值而非自适应;对不同模型族未必通用。
- 奖励模型本身:用 judge 模型打分的过程级 reward 仍受 judge 偏差影响,论文未深入讨论 judge 的稳定性。
谁该读这篇
- Agent / RL 训练工程师:在生产里训过 tool-use 策略并遇到过塌缩的读者,强烈推荐;几乎所有监控点都可直接抄。
- RL 算法研究者:关心 agentic RL 收敛性、token-level 概率动力学、actor-critic(策略-评论家,一类经典 RL 算法)在长链路任务上的稳定性问题。
- LLM 平台架构师:评估"RL 训练 tool-use agent"在生产管线的成本/收益比。
- Agent 评测团队:把 OOD 评测纳入标准面板,避免训练-部署格式漂移。
- 不太适合:仅做单轮 LLM 应用的读者、纯 prompt 工程师——除非需要把自家 agent 升级到多步 tool-use,否则本文调参经验用不到。
一句话总结
Agentic tool-use RL 崩的不是能力,是控制 token 的概率分布。 交错 SFT+RL 是稳定性首选;同步训练上限更高但易尖峰;叠加错误示范监督可以补 OOD;控制 token 概率监控 + 紧急 SFT 步是最便宜的熔断器;过程级 reward + schema 约束从源头压住尖峰。格式与工具名只要变化,就要重测。
📎 论文 ID:2606.26027
三个标题变体
- 为什么 AI 帮你点外卖订机票时,经常在第三步突然"崩"成一团乱码?——一篇论文告诉你:崩的不是能力,是 5 个特殊 token 的概率压过了正确选项
- AI Agent 训练为啥突然崩盘?这篇论文把锅精确到 5 个 token,还给了个最便宜的熔断器
- 多步工具调用 RL 为何会崩?——把 SFT 当"冷却剂"、把错误示范当"反面教材",换来的既稳又泛
小红书风格卡片文案(可直接发布)
🤖 用 ChatGPT/Agent 帮你点外卖订机票时 有没有遇到过这种崩溃现场 💥
前两步还很顺 ✨
到了第三步突然开始吐 }}}}}{ """{"
工具名乱码 → JSON 解析失败 → 整个任务崩盘
reward 直接归零 😭
很多姐妹的第一反应是:模型不行,能力不够
arXiv 2606.26027 这篇论文说:不是能力问题,是 5 个 token 的锅 🔬
核心结论 💡:
多步工具调用场景下,纯 RL 训练容易突然崩盘
崩的不是模型会的能力,而是少数控制 token 的概率出现尖峰
把工具调用格式相关的 <tool>、</tool>、{、:、引号 这几个 token 概率一压
正常答案就被这些尖峰"遮住"了,模型吐出来的就是半截乱码
怎么修?三种监督信号 + 两种训练节奏 🛠️:
📌 三种监督信号(止崩药): - 离线示范:用历史成功轨迹做 SFT,给一个安全区 - 错误示范:故意展示"什么样的格式会失败",从反面拉结构 - hint 引导:prompt 里给"先列步骤再调用工具"等提示
📌 两种训练节奏: - 同步训练:SFT 和 RL 共享同一批样本,上限高但易尖峰 - 交错训练:每 N 步 RL 之后做一次 SFT 步,稳定性首选但 OOD 掉点
⚠️ 关键工程经验: - 监控控制 token 概率分布 > 改 reward 函数(立竿见影) - emergency_sft_step = 监控到尖峰 → 强行插入一次 SFT = 最便宜的熔断器 - 错误示范即数据:线上失败 case 反例标注 → 灌入 SFT 池 = 性价比最高 - 格式与工具名变化 → 必须重测 OOD
⚠️ 诚实标注: - "交错优于同步" / "交错 OOD 掉点" 均为摘要级定性结论,原文以图表给出 - 论文未明确给出与 ToolLLM / ReAct / Search-R1 等 SOTA 的统一 benchmark 数字 - "多个 7B–70B 模型都观察到"是规模 claim,具体名单需回正文核验
工程落地点 🛠️:
1️⃣ 把控制 token 概率分布作为标准面板——比改奖励函数更快 2️⃣ 生产环境选交错训练——稳定性 > 上限;离线冲榜选同步 3️⃣ SFT 池配比建议 5:3:2(正常轨迹:错误示范:hint 提示) 4️⃣ SFT 学习率比 RL 学习率高一个量级——常见稳态配 5️⃣ 格式 schema 强约束——从源头压住尖峰
💡 一句话总结: Agentic tool-use RL 崩的不是能力,是控制 token 的概率分布。 交错 SFT+RL 是稳定性首选,叠加错误示范监督可以补 OOD,控制 token 概率监控 + 紧急 SFT 步是最便宜的熔断器。格式与工具名只要变化,就要重测。
📎 论文:https://arxiv.org/abs/2606.26027 💻 代码:https://github.com/hypasd-art/Tool-RL-Box
💬 评论区聊聊:你做 Agent / RL 训练时,遇到过"突然崩盘"事故吗?是哪一种崩法?🤔