训练多轮智能体时我经常遇到一种很微妙的场景任务明明跑完了模型也确实拿到最终奖励——用户丢来一个复杂问题它连续调了好几次工具读文档、查数据库、修正代码最后输出一个正确结果。看起来一切正常可在强化学习更新阶段却不知道应该怎么奖励中间步骤。是把高分给第一步的意图识别还是给倒数第二次的代码修正如果所有步骤都拿一样奖励模型学到的就不是“哪一步关键”而是“多折腾几步碰运气”。类似的问题在多轮智能体研究里有一个专门名字信用分配。CREST 论文提出的“验证器约束信用分配方法”我认为值得关注的不是又外挂了一个验证器而是它把验证器从裁决者变成了约束条件。先由验证器判断哪些步骤真正推进了目标再在约束范围内做信用分配。这个视角对做工程和训练的人来说都很重要。多轮智能体的训练难点往往不是模型不会完成任务而是任务完成了却不知道应该把成功归功于轨迹里的哪个动作。如果只看最终奖励第一步选错工具、第二步问了无关内容、第三步突然做对最后整体结果正常模型在梯度更新时就会把运气当成能力。CREST 这类方法的价值就是尝试把“整段成功”拆成“逐步理解成功”。1. 多轮智能体的最终奖励为什么不能直接指挥每一步1.1 一次多轮调用里有大量“没有独立答案”的决策多轮智能体的一个典型轨迹并不是“问一句答一句”而是模型为了完成一个目标反复生成动作、读取工具返回、修正计划。举个例子一个负责写数据报表的 Agent 可能要经历这些环节理解用户含糊的需求决定先查哪个表。发起数据库查询发现字段不存在。读取报错信息重新查询。对结果做聚合发现口径不对。修改查询条件最终生成表格。这种轨迹里只有最后一步“生成表格”有明确成功标准。前面的每次查询可能只是在试错也可能是在探索正确方向。每一条轨迹都会包含好几轮工具调用和中间状态可大部分中间步骤并没有标准答案。如果按单轮对话的强化学习思路处理我们只能给整段轨迹一个最终分数。模型没有收到任何关于“第2步为什么会失败”的细粒度反馈只能猜测。失败可以回溯到某个查询写错也可以回溯到前面漏掉了一个约束条件甚至可能是解读需求时就偏了。最终奖励处于长期延迟状态策略网络很难知道哪个动作和结果之间存在稳定因果关系。1.2 平均分配信用必然带来“试探性漂移”另一个容易踩的坑是把最终奖励平均分摊到轨迹的每一个动作上。这种做法工程上最简单但效果通常不稳定。平均值意味着每一个动作都拿到相似的梯度信号模型会认为“多调用工具”和“精确调用工具”都有价值。结果就是策略越来越倾向于执行更多冗余动作而不是尽早找到关键路径。在真实业务里更麻烦的是多轮智能体的失败往往具有后效性。一个动作现在看起来无害却会在后续几轮里放大错误。比如第一次输出的记录格式不完整后续所有规则解析都建立在残缺字段上最后生成的分析结论可能完全错了。如果只看最终失败模型并不知道问题出在第一次动作还是出在中间没有检查字段完整性。所以多轮智能体训练不是“给最终奖励加一个折扣因子”就能解决。折扣因子只能处理时间远近不能处理“哪个状态才是真正导致任务成败的关键节点”。CREST 的思路在这里体现出真正的意义它引入验证器来提供过程层面的约束让信用不再无条件扩散到整条轨迹。2. 验证器约束约束的到底是什么2.1 验证器先解决“过程有没有推进”的问题如果给一个智能体看完整轨迹再由一个验证器对每个中间状态打分它输出的应该是“当前这一步对最终目标推进了多少”而不是简单的“好或坏”。这里的“验证器”不等于最终答案评分器。最终评分器只关心结果是否正确而验证器更关心过程是否合理。尤其是多轮智能体里一个动作可能没有直接产生正确答案但它让后续查询所需的 schema 对齐了或者把用户需求收敛到了可执行范围这种动作就值得获得正面信用。验证器的关键价值是把“reward model”那种最终反馈转换成一个过程信号。它不需要为每一步提供人工标注只需要对“当前状态之后是否还有可能成功”给出一个估计。随着智能体不断探索验证器看到的状态越来越多就能逐步学会判断哪些决策是有价值的。这也是为什么验证器约束可以被理解成信用分配路线的“护栏”。2.2 约束是“只允许在已验证范围内分配信用”只看论文标题“验证器约束信用分配方法”里最值得拆的字是“约束”。常规强化学习在做 credit assignment 时策略更新会受到整段回报的影响。很多步骤之间没有明显信息边界模型必须靠大量采样去平均掉噪声。CREST 这类方法的差异在于它不是直接拿最终奖励对每一步做同权回溯而是先经过验证器得到一组可置信的过程评分再以这组评分为边界来分配信用。换句话说模型的信用分数不能随意给到所有位置只有那些被验证器识别为“和任务推进相关”的步骤才值得获得主要梯度更新。没有被验证器支持的步骤即使最终任务成功也会被压缩信用。这就解决了平均分配带来的问题。用一个比喻来理解如果多轮轨迹是一条山路最终奖励是山顶的旗帜强化学习就是让运动员自己摸索哪段路最重要。验证器约束则会先站在半山腰观察告诉你“你刚才跨过的那段石阶很关键岔路口反而让你绕了远路”。于是训练信号不会均匀地撒到每个动作上而会更聚焦地在关键决策附近形成梯度。2.3 如果要在训练循环里落地它会大致长成什么样由于原始材料没有给出完整代码和公式我在这里只给一个符合常见设计思路的伪代码结构用来帮助理解“验证器约束”如何嵌入训练。# 伪代码不是 CREST 的原始实现 # 只用来展示验证器约束的参与位置 rollout_buffer [] for task in tasks: # 采集一批任务 trajectory, final_return run_policy(task) rollout_buffer.append((trajectory, final_return)) for trajectory, final_return in rollout_buffer: for step in trajectory: # 1. 用验证器给每个中间状态一个过程分数 process_score verifier.evaluate(step.state) # 2. 把最终回报当成全局信号和验证器一起形成约束 step_credit final_return * process_score # 3. 用 step_credit 而不是全轨迹平均回报来更新策略 update_policy(step.state, step.action, step_credit)这里最重要的是第 2 步。如果不乘process_score那么最终回报会均匀地传给所有步骤。乘了之后验证器给分高的步骤获得更高信用验证器给分低的步骤即使出现在成功轨迹里也不会被盲目鼓励。当然真实实现里还要考虑基线、归一化、验证器误差和样本效率。但理解这个结构后再看论文里的公式就不会被复杂的符号带偏。3. 它和过程奖励模型、奖励塑形有什么本质差异3.1 过程奖励模型仍然是在“造每一步的奖励”现在很多研究都在做过程奖励模型希望给每一步输出一个分数再把这些分数累加成为强化学习的奖励。这种方案的问题在于过程奖励模型需要密集的监督信号。为了训练它往往要收集大量人工标注的“这个步骤是否正确”数据。在多轮智能体场景里标注成本会被显著放大。因为一个工具调用是否正确不仅取决于当前动作还取决于它后面能不能衔接下一个动作。验证器约束的方法不一样。它不需要把验证器的输出当成精确的“每一步奖励真值”只需要把它当成一个排序信号或者权重边界。即使验证器打分不那么完美只要它能把一些明显无效、偏离目标的步骤排除在高信用之外策略更新就会比平均分配稳定不少。3.2 奖励塑形更容易被“打游戏式”的漏洞钻空子奖励塑形的基本思想是给靠近完成目标的中间状态额外加分从而缓解稀疏奖励。问题是塑形函数必须精心设计。如果你奖励“查询次数少”模型会倾向于少查询但不验证结果如果你奖励“偶尔修正动作”模型可能故意制造错误再通过修正动作来获取分步奖励。人工设计的状态判断在多轮 agent 这种开放动作空间里非常脆弱。验证器约束更像一种辅助判断而不是直接制造奖励。它判断的是状态本身是否让任务更接近成功不是简单惩罚步数或鼓励修正次数。这能在一定程度上避免被策略“钻空子”因为验证器的评价粒度在状态层面而不是动作表层的文字特征。3.3 关键差异是“因果性”还是“相关性”多轮智能体很容易陷入相关性陷阱。一个动作出现频率高且整体成功率也高策略就可能学会复制这个动作。可它不一定想清楚了为什么要做。一旦环境稍有变化这种相关性就会失效。验证器约束希望把信用放在“让状态发生关键变化”的动作上。验证器看的是状态变化过程比如需求是否被明确、数据格式是否正确、计划是否可行、是否已经排除错误分支。它更接近因果推理不是因为这个动作后面发生了成功而是因为这个动作改变了状态使成功概率显著上升。所以CREST 的价值不只是给强化学习加了一个新模块而是把过去“用最终结果倒推每一步”的范式改成“先理解过程再决定把成功归因给谁”。对多轮智能体这种具有明显状态流转的任务来说这个过程理解比单轮对话准确得多。4. 把它落到训练工程里真正要处理的是四件事4.1 验证器从哪来自训、复用还是大模型即服务落地 CREST 类方法时第一个实际问题是要有一个验证器。如果只在论文实验里可以专门训练一个小型验证器或者复用已开源的过程奖励模型。但在公司项目里这个验证器必须能和你的任务对齐。任务领域是代码还是数据库问答验证器能力口径就不一样。你很难拿一个通用代码验证器去给业务数据分析的多轮轨迹打分。一个更现实的办法是让强模型扮演验证器。你可以设计一个验证 Prompt输入“初始目标、当前状态、上一步动作、工具返回结果”让它输出当前状态是否更接近目标。用大模型做验证器的问题在于推理成本高、延迟大但它对冷启动友好。先用它跑少量训练再蒸馏一个小模型是比较常见的过渡路线。4.2 验证器给的是序数不是基数验证器打分通常不等于真实成功率。同一个验证器在任务 A 上给 0.9 分在任务 B 上给 0.6 分这两个分数之间不一定有“0.3 的真实差距”。所以落地时最好不要直接把它当成精确回报值。更稳妥的做法是把验证器分数用到相对排序上或者在最终回报上做归一化。先对一整批轨迹里的所有中间状态求验证器分数的分布再判断某个步骤在该批样本里处于什么位置。这样做可以在一定程度上缓解验证器本身校准误差带来的偏差。4.3 策略更新时还要考虑数据的多样性如果只根据验证器给高分的步骤去更新策略会引入一个隐患策略会变得更加激进地追求“看起来推进状态”的动作而这些动作未必真的被验证器全面评估过。要尽量避免这种情况最直接的方法是保持探索数据多样性。多轮智能体训练里既要收集成功轨迹也要收集失败轨迹。失败轨迹里那些把状态引入死巷的动作同样是验证器的重要训练样本。CREST 类方案的长期可用性依赖验证器见过足够多的“坏状态”而不是只看成功案例。4.4 日志要记录到“状态级”而不是“轨迹级”工程排障也要跟着改。很多 agent 训练日志只记录第几轮成功、最终奖励多少、平均步数多少。但对于验证器约束的信用分配方法这些远远不够。至少要在日志里保留每个状态的验证器分数、动作的 credit 权重、最终回报三条信息。这样如果策略出现退化你能看到到底是验证器给出的过程分数异常还是信用权重归一化出了问题还是动作本身有错误。没有状态级日志这类方法一旦训练异常几乎无法还原问题。5. 这套方法适合谁又不适合谁5.1 适合多轮推理、工具调用和任务型 Agent需要明确的是验证器约束不是所有场景都需要的。如果任务是单轮文本分类只要给整段文本一个奖励就够了完全不需要中间步骤。如果任务是格式固定的两轮对话中间步骤也很少验证器带来的复杂度大于收益。它真正适合的是多轮决策和状态变化明显的场景。比如智能体需要通过多轮查询完成数据分析。智能体需要动态选择不同工具并组装结果。智能体需要根据环境反馈修正计划。智能体面对的任务有多种可行路径但只有部分路径能成功。这些场景都有共同的痛点轨迹长、中间动作因果复杂、最终结果难以直接归因。验证器约束正好处理这类“结构性稀疏”问题。5.2 不适合验证器能力远弱于策略的场景如果验证器本身判断不准确而策略已经很强那么强加验证器约束反而可能拖后腿。好的 rollout 被验证器给了低分模型会放弃本来正确但不符合验证器偏好的行为。类似情况经常出现在开放领域对话里。对话是否推进了用户目标往往取决于用户的主观满意度。验证器很难凭空判断一个礼貌但没提供信息的回应到底算不算进展。这时候更倾向于使用人工反馈或用户信号而不是单纯依靠验证器。所以验证器约束方案存在一个隐式前提任务拥有能被客观判断的“中间状态进步”。如果任务没有明确的中间状态或者状态进步高度主观这种方法需要非常谨慎。5.3 最容易被低估的是验证器偏差的生命周期验证器的偏差会随着策略更新而变化。第一轮训练时策略生成的动作比较简单验证器看得懂。训练几轮后策略会做一些更复杂、更隐晦的动作验证器可能还没见过打分稳定性就会下降。因此验证器不能是训练前期训练完就固定不动的。它会陷入“反馈闭环偏差”策略利用验证器分数更新新策略又产生验证器不熟悉的状态验证器再给出不稳定信号策略被带偏。比较好的做法是每隔一段时间用新策略生成的轨迹重训或微调验证器并且定期检查验证器对某一类状态是否失效。6. 如果把 CREST 读成一套可复用的方法可以按三步走6.1 第一步先定义你要验证的“关键状态单元”不管论文里的实现细节如何落到自己的项目里第一步都是定义状态单元。你不能把“模型说的每一句话”都当作状态最好是把“一个回合、一次工具调用产生后的结果”作为关键状态。分析型 Agent 里的状态单元可能是初始问题、第一次查询计划、工具返回结果、修正后的查询语句、最终输出。定义状态单元时把握一个标准这个状态是否可能影响后续决策。如果它不影响后续任何判断那么它就不应该承载信用。如果它改变了后续动作的选择空间那么它就是验证器应该关注的节点。6.2 第二步用验证器输出“过程进展分”建立信用约束把最终回报和一个过程分相乘是理解 CREST 最直接的方式。实际操作时可以用更简单的做法把过程分按排序分成高、中、低三档只对高档步骤增加信用中档保持中性低档适当降低信用。这种粗粒度版本可以作为实验起点。因为它不需要验证器做精确定量评估只需要它能区分“推进、中性、偏离”三态。很多业务任务里强模型作为验证器对三态判断的准确率已经足够支持训练信号的排序稳定性。6.3 第三步小步更新策略密切观察验证器分数分布不要把 batch size 一次拉满。先在一小段数据集上做 1 到 2 轮训练比较配置更新前后验证器分数的变化。如果策略更新后所有轨迹的过程分都显著下降说明模型开始走验证器不理解或者不认可的路径这时要先停下来修正验证器而不是继续堆训练步数。一个比较实用的调试顺序是检查每个步骤的验证器分数是否出现大幅波动。检查低信用步骤是否恰好都集中在某类工具调用上。检查高信用步骤是否集中在重复性动作而非关键转折上。如果高信用步骤看起来像“自说自话”考虑验证器存在偏好目标。CREST 这类方法再先进也只是把人为判断转换成结构化的信用权重。真正决定质量上限的仍然是任务定义、验证器能力和数据覆盖度。把这几点做好才谈得上让多轮智能体从“完成任务”迈向“理解自己为什么能完成任务”。