多轮智能体强化学习几乎成了 Agent 训练的标准配置,但评估口径高度一致:只看任务有没有完成。论文作者指出,只看轨迹结果的评测,把「每一步都做得更好」和「出错之后还能救回来」混成了同一件事——而这两件事在真实部署里的权重完全不同。

一个被指标掩盖的问题

论文来自中科院自动化所复杂系统认知与决策智能重点实验室、国科大人工智能学院与清华大学,已在 arXiv 公开,并放出项目页与 MIT 许可的仓库。

他们把单轮 RL 里用惯的 Pass@K 推广成二维的 Pass@(K,T):K 是采样广度,T 是交互深度。实验覆盖 DeepCoder-MT、BFCL、InterCode-SQL、FrozenLake 四个基准,基座是 Qwen3-4B 和 Qwen3-8B,跑 GRPO、GiGPO、PPO。

第一个反直觉:预算一收紧,优势就翻转

固定 K=8 扫描 T,论文表格给出的画面很清楚:RL 相对基座的优势随交互预算放宽而越来越明显;预算一收紧,优势迅速缩水,部分任务上甚至反向。

最刺眼的一格在 BFCL-v3 的 25% 预算档:Qwen3-4B 基座是 3.0,GRPO 全预算 RL 反而只有 2.5,比基座还低;FrozenLake 同档,基座 30.3、GRPO 全预算 28.7。论文还算了每个任务在给定预算下的结构性上界,排除「预算太紧、任务本来就无解」的平凡解释:即使上界之下还留着大量空间,RL 依然没有优势。

第二个反直觉:单步动作其实没普遍变好

作者在匹配状态上做细粒度评估:从基座和 RL 轨迹等量抽取中间状态避免访问偏差,同一状态下各采 G=16 个下一步动作,用动作价值打分(FrozenLake 用有限时域动态规划算精确 Q* 值,折扣因子 0.95;DeepCoder-MT 用单元测试通过率)。

结论是分布不偏向 RL,甚至略微偏向基座:RL 只在 46.8% 的 DeepCoder-MT 状态和 42.8% 的 FrozenLake 状态上做出更好的单步决策,平均质量不比基座好、反而略低。

但强项很明确:错误恢复

换个视角结论就反过来。作者构造错误状态池,在前一步注入错误动作,此时 RL 选出更优动作的比例是 FrozenLake 65.7%、DeepCoder-MT 67.3%。从完全相同的错误状态继续往下跑,终局成功率 RL 是 FrozenLake 51.3% 对基座 38.6%、DeepCoder-MT 38.5% 对 22.9%。

BFCL 上的案例研究更贴近工程直觉:收集 191 条含工具调用错误的前缀(RL 侧 91 条、基座侧 100 条),两个模型从同一条前缀各接一步,RL 的错误纠正率 41.4%,基座只有 27.2%。论文附录还提到,RL 的优势在轨迹早期并不明显,甚至略逊于基座,要随交互推进才逐渐拉开。

机制:局部依然合理,轨迹整体换了策略

似然分析给出了解释。在基座策略下评估单步动作的负对数似然,RL 是 12.20、基座是 10.25,两个分布大幅重叠——RL 的单步动作没有跑出基座的支撑集。但换成整条轨迹的累积对数似然比,成功的 RL 轨迹达到约 228,成功的基座轨迹只有 26。

论文还做了长度匹配对照,把两边输出 token 数差控制在长序列的 10% 以内:Terminal 上匹配差 185.9 nats、BFCL 上 805.8 nats,95% 置信区间都高于零(89 个任务 193 对、146 个任务 283 对)。这说明轨迹层面的策略迁移并非单纯由输出更长带来。

训练动态则把这件事钉死了:DeepCoder-MT 上,轨迹级奖励 Rmulti 上涨 0.331 的同时,单步奖励 Rsingle 反而下跌 0.097。论文称这不是终点检查点的偶然,而是训练中逐步长出来的。

两个缓解方案,一个能落地一个不能

第一条路是过程监督信号。在 FrozenLake 上,精确的 Q 值过程奖励和 GiGPO 能在紧预算下稳住表现;换到 BFCL,没有精确的单步 oracle,GiGPO 和 PPO 在受限预算下都无法超过 GRPO,基本持平。论文的结论偏悲观:这类监督在多数真实任务里拿不到。

第二条是论文自己的 BudgetMix RL,改动很小:奖励机制不变,只改预算分布。每个任务按 10% 间隔构造候选预算并均匀采样,组内轨迹共享同一预算;训练时把总预算和剩余预算写进 prompt,超预算未完成记零奖励。论文称相对全预算 RL,25%、50%、75% 三档分别提升 7.5、5.3、4.0 个百分点,100% 档持平。

按表 1 的每任务增益行复算,25% 档 6.6 与 8.35 的均值 7.475 对上论文的 7.5,50% 档 5.3125 对 5.3,75% 档 4.0125 对 4.0,三档都能复算。

落地前有两道硬门槛

第一道是预算的告知方式。论文所有实验都把总预算与剩余预算写进系统提示,但真实部署里的上限往往是超时或成本天花板,不会事先声明。论文页评论区有读者直接追问:如果上限不被告知,模型学到的是更谨慎的早期策略,还是只在条件化于那个被写明的数字?论文没有回答。

第二道是复现边界。官方仓库自己写明,示例与工程检查并不是论文基准的数值复现,模型权重、私有基准测试、原始轨迹和完整实验结果都没打包。它提供的是一套诊断工具链:紧预算评估、错误前缀评估、训练动态追踪与 BudgetMix 审计。

所以呢

如果你的 Agent 上线时有交互轮次上限,评测口径最好加一维 Pass@T,而不是只报任务成功率。更要紧的是,如果任务里混着金融操作、数据库写入这类不可逆动作,单步决策质量才是真正该被考核的东西,而多轮 RL 在这一项上没有保证——它买到的是出错之后爬回来的韧性。

更准确的说法不是「多轮 RL 让 Agent 变聪明了」,而是「多轮 RL 让 Agent 在给足交互预算时更抗造」。

资料来源:论文 https://arxiv.org/abs/2611.06483 ,项目页 https://rethinking-agentic-rl.github.io/ ,官方仓库 https://github.com/GaryStack/Rethinking-Agent-RL 。