别让奖励信号骗了你：从 Critical-State RL 看多轮工具调用的可训练状态诊断

从今天觉醒,技术赋予每一个人数字生命

别让奖励信号骗了你：从 Critical-State RL 看多轮工具调用的可训练状态诊断

① 技术背景：多轮工具调用里，最贵的往往不是"错"，而是"不知道该改哪一步"

让模型学会调用工具，单轮任务已经不算太难。真正让人头疼的是多轮：模型先查天气、再订机票、最后填表提交，中间任何一次调用出问题，整条链路都可能崩。更麻烦的是，当你拿到一条失败轨迹，想用强化学习去修它时，会发现一个尴尬的事实——奖励只告诉你结果好坏，却不告诉你哪一次调用该背锅。

这就是多轮工具调用训练的核心痛点。假设模型在第 3 步本该调用 get_user_profile 获取用户 ID，但它没调，直接在第 4 步用了空参数。最终任务失败，奖励为 0。这个 0 到底该归咎于第 3 步的"漏调"，还是第 4 步的"瞎填"？如果奖励还依赖后续交互，那么同一动作在不同后续采样下可能得到不同回报，这种方差反映的是下游随机性，而不是当前动作本身的优劣。

Critical-State RL 要回答的问题很具体：给定任务定义的候选调用和局部奖励，如何判断某个状态下的奖励是否真的捕捉到了动作对任务成功的影响，以及相对参考策略是否还有改进空间？ 它把这套判断做成诊断，再用嵌套采样把"动作相关的奖励方差"从"续写噪声"里剥出来，最后只在被选中的状态上做 contextual-bandit 训练。

对在校学生和转行者来说，这个思路值得写进作品集：它不是"再训一个更大的模型"，而是"先诊断再训练"的工程方法论——会读调用链、会区分信号与噪声、会用小实验验证假设，这些能力在真实项目里比调参更稀缺。

② 主流方案盘点：大家各自在修哪一段

方案一：全轨迹 RL（如 PPO/GRPO 类）。职责是把整条多轮交互当成一个序列，用最终任务奖励回传。代表做法是各类 agentic RL 框架。优点是通用、不需要额外标注；缺点是信用分配粗糙，长轨迹上方差大，容易把"下游运气"误当成"当前动作好"。

方案二：过程奖励模型（PRM）。职责是给中间步骤打密集分数，缓解稀疏奖励。代表工作是数学推理领域的 PRM 及其向 agent 场景的迁移。优点是信号密；缺点是过程标注成本高，且 PRM 本身可能被"看起来合理"的中间步骤骗过。

方案三：拒绝采样 / Best-of-N 微调。职责是从多次采样里挑成功轨迹做 SFT。优点是实现简单、稳定；缺点是无法区分"哪一步关键"，且对失败轨迹几乎不利用。

方案四：Critical-State RL（本文）。职责是先做状态级诊断：对每个候选调用，评估其局部奖励是否反映动作对任务成功的影响，以及相对参考策略能否改进；再用嵌套采样分离动作相关方差与续写噪声；最后只在这些"临界状态"上用 contextual bandit 训练。优点是训练目标集中、样本效率高；缺点是需要任务定义的候选调用与局部奖励，诊断本身有额外开销。

③ 对比与优劣：统一维度看差异

一个容易被误判的点：Critical-State RL 并不是"只训一个 token"。它选的是状态——即某次模型调用所处的上下文位置。论文在 BFCL v4 上的观察很说明问题：缺函数任务中，诊断选中的是"工具变为可用之后的那次响应"；缺参数任务中，选中的是"缺失参数被补上之前的那次响应"。训练这些被选中的响应能带来提升（缺函数任务约 14 个百分点），而训练其他位置则持平甚至更差。这说明"训哪里"比"训多少"更关键。

④ 选型建议：按场景给答案，而不是唯一答案

场景 A：课程作业/入门项目，只有最终成败信号。 先用拒绝采样微调打底，成本最低、最容易复现。等你能稳定跑通多轮评测后，再引入状态诊断做对比实验——这本身就是作品集里很好的"消融研究"。

场景 B：有任务定义和局部奖励的 agent 项目（如函数调用、表单填写）。 优先试 Critical-State RL 的诊断思路：先写一个脚本，对每条失败轨迹枚举候选调用位置，检查"该位置的局部奖励是否随动作变化而显著变化"。这一步不需要训练，就能帮你定位瓶颈。

场景 C：长链路、下游随机性强的场景（如多步检索+操作）。 重点用嵌套采样做方差分解：同一状态多次续写，看奖励波动是来自动作还是来自后续采样。若后者占主导，说明该状态不适合作为训练点。

场景 D：面试/作业被追问"你怎么知道该训哪一步"。 标准回答框架：先定义候选动作集合与局部奖励，再做"动作相关性检验"，最后用对照实验证明"训选中状态 vs 训其他状态"的差异。这正是本文实验设计的可复用模板。

⑤ 未来展望：诊断会变成一等公民

已经出现的趋势是：agent 训练正从"端到端一把梭"走向"先定位、再优化"。Critical-State RL 把"可训练性"本身变成一个可计算的量，这个方向很可能延伸到更多场景——日志里的重复调用规避、记忆管理等，论文也提到这套 recipe 可跨模型、跨任务复用。仍未解决的问题也很清楚：候选调用与局部奖励仍依赖任务定义，诊断的误判会直接传导到训练；嵌套采样的计算开销在长轨迹上不容忽视；以及当任务成功标准本身模糊时，"临界状态"的判定会变得主观。

对学习者而言，最值得带走的一句话是：不要急着调学习率，先问清楚你的奖励信号到底在奖励哪一步。 能把这个问题讲清楚、并用小实验验证，就已经具备了一个合格 agent 工程师的核心素养。