最近多轮智能体Multi-turn Agent的训练又出现了一个值得关注的方向CREST 论文提出把验证器约束引入信用分配环节。简单说就是不再把整条轨迹的成功或失败平均分给每一个动作而是用验证器先判断“哪些回合真正做对了”再只给这些回合分配正向信用。这个思路解决的是多轮 Agent 训练里最难缠的延迟奖励和稀疏反馈问题。先说结论如果你想做 LLM Agent 的策略训练、工具调用类智能体的强化学习或者正在搭多轮对话数据的自动标注和筛选流程这套方法思路可以直接借鉴。它不需要更换基座模型也不用引入新的推理范式核心是在奖励/信用计算模块里加一个“验证器约束”让模型知道“哪一步做错了、哪一步其实是对的”。本文会从方法动机、验证器如何约束信用分配、与传统 ORM/PRM 路线的对比、数据构造、复现环境准备、训练资源观察等几个维度展开所有内容基于论文标题和公开技术背景做拆解不涉及虚构实验数据。1. 核心方法速览能力项说明方法类型多轮智能体训练中的信用分配方法可配合 RL 或偏好优化使用核心问题多轮轨迹最终结果只有一个无法判断中间哪些动作贡献了成功核心机制引入验证器Verifier对每个回合或动作做正确性判断关键约束只有通过验证器的回合才被分配正向信用弱化“运气型成功”的干扰适用对象多轮工具调用 Agent、网页操作 Agent、客服/任务型多轮对话系统训练方式复用已有基座模型新增验证器训练和信用加权流程硬件门槛验证器训练一般可基于 7B/13B 量级模型具体看轨迹长度和批次设计接口能力方法本身是训练算法落地时可包装为奖励计算服务或数据标注管线是否支持批量适合批量离线构造轨迹数据再统一训练验证器和更新策略主要收益减少信用稀释提升多轮长轨迹下的策略收敛质量和稳定性从方法定位看CREST 不是一个新的推理模型而是一套“怎么教多轮智能体”的训练方法。论文重点在验证器约束机制和信用分配策略这也是近两年 Agent 强化学习方向最缺的一环结果奖励好拿过程奖励难标。2. 多轮智能体训练中的信用分配问题2.1 什么场景会产生信用分配问题只要 Agent 的任务包含多次决策信用分配问题就会出现。典型场景工具调用型 Agent用户要查某地天气Agent 需要依次调用地点解析、天气查询、结果整理等多个动作只有最终回复正确才算成功。网页操作型 Agent例如自动填表、自动下单中间涉及跳转、点击、输入等多步操作。多轮交互型 Agent客服机器人需要先问需求、再查库、再确认最后给出方案。这类任务有个共同点最终奖励是稀疏的。通常只有 0 或 1没有一个中间环节的“过程奖励”。当 Agent 执行了 8 步、最终成功时系统只知道“成功了”但不知道是第 3 步的查询动作做对了还是第 5 步的格式整理起了决定性作用。2.2 传统处理方式的缺陷业界最朴素的做法是均匀分配信用也就是把最终奖励平均回传给每个回合。假设轨迹有 T 步每一步都拿到 R/T 的信用。这样做的结果有两个问题第一正确动作被稀释。整条轨迹 8 步中只有 2 步是真正关键的正确决策但均匀分配时它们各自只拿到 1/8 的信用和那些无效动作没有区分度。第二错误动作被误伤或误赏。有些动作单独看是错的但因为最后结果碰巧成功也会被分到正向信用反过来有些正确动作因为后续步骤失败也被分到负向信用。这会让策略更新信号非常嘈杂。还有一种常见做法是只在最后一步给奖励前面的动作都不更新。这在 ReAct 类短轨迹里勉强能用但在长轨迹场景下学习效率太低模型很难知道前面十几步里哪一步值得模仿。2.3 为什么需要验证器来约束信用验证器Verifier本质上是一个“判断模型”它可以在轨迹执行的中间环节判断当前的回答是否符合预期、调用参数是否正确、动作是否导致状态发生合理变化。CREST 这类方法把验证器当成信用分配的门控验证器认为当前步正确才允许分配正向信用。验证器认为当前步错误就降低甚至清零该步的信用。验证器不确定的中间步骤不强行打分避免给策略增加噪声。这里的“约束”体现在不再是“最终成功则全步骤奖励”而是“最终成功且验证器确认该步正确该步才获得正向信用”。这样可以把最终结果的单一信号拆成多条带验证的中间信号让策略模型真正学到关键动作。3. CREST 验证器约束机制的原理拆解3.1 轨迹与验证器输出的关系先定义一个多轮轨迹格式s0 - a0 - s1 - a1 - s2 - ... - sT-1 - aT-1 - result其中 s 表示每一轮的状态或对话上下文a 表示 Agent 的动作result 是最终结果。传统 RL 训练时最终的奖励 r_final 会通过折扣因子回传给每一步。CREST 式的方法会在中间插入验证器 VV(s_i, a_i) - correct / incorrect / uncertain如果轨迹最终成功且 V(s_i, a_i) correct那么步 i 获得正向信用如果 V 判定为 incorrect哪怕最终轨迹成功步 i 也不能获得正向信用。反之如果轨迹最终失败但 V 判定某一步动作设计是对的可以考虑保留中性或微小正向引导避免模型把所有中间步骤都归罪于自身。3.2 验证器约束的几种形式从实现角度看验证器约束不一定要写成硬编码规则常见有四种形态第一种是掩码形式。计算每条轨迹的回合级优势或奖励时乘上一个 0/1 掩码credit_i final_reward * mask_i mask_i 1 if verifier(s_i, a_i) correct else 0这种形式最直接适合验证器精度较高的场景。第二种是权重形式。不直接清零而是给正确步更高的权重、给错误步更低权重。类似credit_i final_reward * w_i w_i 0.8 if verifier correct w_i 0.2 if verifier uncertain w_i -0.1 if verifier incorrect第三种是置信度门限形式。验证器输出概率值 p_i只有 p_i 超过阈值才发放信用。这样可以把“验证器自己也不确定”的步骤排除在更新之外。第四种是辅助奖励形式。把验证器对每一步的判定作为 shaping reward 加到环境奖励中变成更稠密的过程奖励。这种方式实现上更通用但需要处理好验证器噪声带来的偏置。3.3 为什么要用“约束”而不是“替代”这里有一个容易混淆的点验证器约束不等于普通的过程奖励模型PRM。PRM 试图给每一步打分输出的分直接当作奖励。而 CREST 这类“验证器约束信用分配”方法验证器的角色不是提供连续稠密分数而是给出一个约束条件决定哪些信用该发、哪些不该发。它更像是一个过滤器而不是一个打分器。过滤器思路有几个实际好处对验证器的要求更宽松。验证器只要能把明显错的步骤筛出来不需要精算出每一步有多好。可解释性更强。每个回合的“该不该奖励”可以回溯查看训练中出现问题容易定位。对噪声更鲁棒。打分型 PRM 的误差会直接污染奖励数值而约束型方法只影响信用是否发放数值波动更小。4. 与 ORM、PRM、结果奖励的路线对比奖励/信用方案粒度标注成本主要问题典型适用场景结果奖励整条轨迹低无法区分中间步骤贡献短轨迹、单轮任务ORM 最终结果验证整条轨迹中只有判断无中间信用需要筛选正确答案的训练集PRM 过程奖励每一步高标注噪声大模型误差直接污染奖励数学推理等可逐步验证任务验证器约束信用分配每一步中高验证器精度决定信用质量上限多轮 Agent、工具调用、长轨迹任务多轮 Agent 场景里PRM 的落地难点在于工具调用过程的“正确性”不像数学推理那样有唯一标准。模型调用了地图 API 拿到坐标这个动作“算对还是算错”没有统一答案。结果验证器更适合做最终答案的校验而 CREST 这种用验证器约束回传信用分配的方式正好站在两者中间验证器判断相对容易定义的分步规范信用分配再把稀疏结果转化为可学习的密度信号。5. 数据构造与验证器训练流程5.1 轨迹数据收集阶段要复现或借鉴 CREST 方法第一步是准备多轮轨迹数据。每条样本至少应包含{ task_id: task_0001, instruction: 查询北京到上海明天的高铁票, trajectory: [ {turn: 0, state: 初始状态, action: 解析出发地和目的地}, {turn: 1, state: 获得查询参数, action: 调用车票查询接口}, {turn: 2, state: 拿到候选车次, action: 筛选最早一班}, {turn: 3, state: 得到车次信息, action: 生成最终回复} ], final_result: success }收集时需要注意一个问题轨迹正负比例。如果采集策略太强全是成功轨迹验证器很难学会识别错误步骤。建议成功失败轨迹都保留最好能覆盖“中间步骤错了但最终侥幸成功”的反例这是验证器约束最有价值的地方。5.2 验证器训练数据标注验证器需要训练数据。当前常见标注方式有三种规则自动标注。对于工具调用类 Agent可以直接比对“应调用的工具名/参数”和“实际调用的工具名/参数”一致则 correct不一致则 incorrect。这类规则能覆盖大部分工具调用场景成本最低。模型辅助标注。用更强的模型对中间步骤做判断让强模型给出正确性标签。比如对第 i 轮动作让大模型回答“当前动作是否推进任务、是否合法、是否合理”。这个方案适合工具调用之外的自然语言动作。人工抽查标注。自动标注结果做随机抽查校对计算验证器在抽查集上的准确率。这一步建议保留因为验证器是会持续迭代的模块正确率基线需要不断追踪。5.3 验证器模型选择与训练验证器不需要和策略模型同规模。通常可以用比策略模型小一号的模型做验证器输入是当前状态和动作输出是二分类或三分类。训练目标可以写成# 伪代码验证器训练 verifier_input tokenizer.encode(state_text action_text) logits verifier_model(verifier_input) loss cross_entropy(logits, label) # label: 0incorrect, 1correct, 2uncertain验证器训练完成后要做一次独立评估不要用训练数据评估。评估指标建议同时看准确率、召回率和类别间混淆情况。一个常见问题是验证器会把“incorrect”误判为“uncertain”导致约束失效。如果出现这种情况优先调整训练数据中三类样本的比例。5.4 策略优化的整体流程CREST 风格方法的完整训练流程可以用下面的伪代码描述# 伪代码验证器约束信用分配 策略优化 for epoch in range(max_epochs): trajectories rollout(policy_model, task_prompts) labeled_rollouts verifier_label(trajectories) # 逐回合标注 credit_list [] for traj in labeled_rollouts: final_reward get_final_result(traj) # success / fail for i, turn in enumerate(traj): v_label turn[verifier_label] if v_label correct and final_reward success: credit 1.0 elif v_label incorrect: # 即使最终成功也不给正向信用 credit 0.0 else: credit 0.0 credit_list.append((turn, credit)) policy_model.train() for turn, credit in credit_list: loss policy_loss(policy_model, turn, credit) loss.backward() optimizer.step()这个流程里真正起到约束作用的是条件判断v_label correct and final_reward success。最终结果和验证器判定同时满足信用才发放。6. 复现实验的环境准备与评估设计6.1 环境准备清单CREST 方法是训练算法硬件需求主要来自三个部分策略模型推理、验证器模型推理、梯度更新。建议按以下清单确认环境操作系统Linux 服务器为主Windows 可做小规模测试。GPU如果策略模型是 7B~14B单卡 A100 40G/H100 80G 比较稳妥多轮轨迹长度较长时需要按 batch 数估算显存。加速框架PyTorch 2.x、HuggingFace Transformers、DeepSpeed 或 LLaMA-Factory 等训练框架。数据存储轨迹数据建议使用 JSONL 格式每条样本保留完整轨迹文本。评估环境需要准备可自动判分的任务集例如工具调用模拟器或带标准答案的 Agent 数据集。分布式策略模型超过 20B 时建议准备多卡环境并考虑 ZeRO-2 或 ZeRO-3。显存占用没有统一数值。它取决于策略模型规模、验证器规模、轨迹长度、batch size 和是否使用 LoRA。如果使用 LoRA 微调 7B 策略模型并配合序列长度为 2048 左右的数据单卡 24G 到 40G 是常见范围如果全参数训练 13B 甚至更大模型建议直接按 80G 显存规划。6.2 实验设计建议复现这类方法时最少要设计三组对比基线 1均匀信用分配。把所有回合都按最终结果分配不做验证器约束。基线 2结果奖励 最后一步更新。只对最终动作给奖励。实验组验证器约束信用分配。也就是 CREST 式方法。评估指标建议包含三个层面任务成功率最核心看方法是否真正提升了最终任务完成率。关键步骤命中率评估模型是否在“必要动作”上做得更准确。这比任务成功率更早反映信用分配的效果。训练稳定性观察奖励曲线是否比均匀分配更平滑。信用分配更准确时训练后期的奖励波动通常会变小。评估时要把任务按轨迹长度分层。例如 3 步以下短任务、5~8 步中任务、10 步以上长任务分开统计。信用分配方法的价值往往主要体现在长任务上短任务里均匀分配也够用。7. 关键技术细节与实现建议7.1 验证器输入的构造方式验证器需要感知“当前做了什么事”。最简单的方式是把前面的对话历史和当前动作拼接起来输给验证器。效果更好的方式是把环境状态中的关键字段也拼进去。以工具调用 Agent 为例一条验证器输入可以设计为【历史】用户查询北京到上海车票Agent已调用地点解析工具得到北京、上海。 【当前动作】Agent调用 query_train_ticket(departure北京, arrival上海, date明天) 【期望】动作是否正确推进目标关键点在于不要只让验证器看当前动作也要给它上文和任务目标否则很多动作单独看是正确的放在特定上下文里却是重复调用或错误调用。7.2 验证器噪声的处理任何一个验证器都会有误判。当验证器把正确的步骤错判为 incorrect 时策略模型会丢失正确的学习信号反过来把错误步骤错判为 correct 时会给策略注入错误信号。CREST 这类方法没有彻底消灭验证器噪声而是通过约束形式来降低噪声对训练的冲击。两种常用处理不确定类别兜底。让验证器在无法判断时输出 uncertain不参与正负信用分配。这个设计会让可用训练信号变少但信号质量更稳。置信度阈值控制。只用验证器置信度 top 20%~30% 的样本来更新策略其余样本过滤掉。训练步数会增加但每步的梯度方向更可靠。7.3 与不同策略优化算法的配合验证器约束信用分配并不是一个绑定 PPO 的方法。信用计算好之后可以插到不同的优化器中配合 PPO/GRPO。把逐回合信用当作优势函数或奖励信号做策略梯度更新。配合偏好优化。把验证器筛选出的正确回合和错误回合组成偏好对用 DPO 或其变体更新。配合加权 SFT。只使用验证器确认正确的轨迹片段继续做监督微调相当于做一轮高质量数据筛选。从工程实现角度加权 SFT 是最容易起步的方式。只需要修改数据集的 loss 权重不需要引入大量强化学习基础设施。建议第一次验证 CREST 思路时先用加权 SFT 模式跑通后再切换 RL 模式。8. 工程化落地与批量任务设计8.1 把验证器服务化为接口实际项目中验证器通常不是一个离线脚本而是一个在线打分服务。可以把它封装成 HTTP 接口供数据标注平台或策略训练程序循环调用。# 验证器服务示例实际接口路径需按项目实现调整 import requests url http://127.0.0.1:8080/verify payload { task: 查询北京到上海明天的高铁票, history: [用户发起了车票查询请求], action: 调用 query_train_ticket(departure北京, arrival上海) } response requests.post(url, jsonpayload, timeout30) print(response.json()) # 预期返回: {label: correct, confidence: 0.92}服务化之后数据管线和训练脚本都不需要重新加载模型只要发 HTTP 请求拿验证结果。这样在多卡训练时也可以避免验证器模型占额外显存。8.2 批量验证与自动标注管线如果有一段存量轨迹数据需要批量处理建议按下面的目录组织agent_training_data/ ├── raw_trajectories/ │ ├── task_0001.json │ └── task_0002.json ├── verified_trajectories/ ├── credit_assigned/ ├── verifier_checkpoints/ └── logs/批量验证时建议加上失败重试和断点续跑。验证器是模型推理单条请求可能因为超时或显存抖动失败。如果任务较多建议记录每条轨迹的处理状态{ task_id: task_0001, status: verified, credit_count: 2, total_turns: 5, verifier_version: v0.3 }做到“每条数据可溯源”后后续做数据清洗和训练集分析会省很多时间。9. 资源占用与训练效果观察9.1 资源占用观察方法如果是第一次跑这套训练流程建议从两组观察开始验证器训练单独跑。观察单条验证样本的推理显存、训练显存和吞吐。如果验证器是 7B 模型LoRA 训练时通常可以控制在 20G 上下具体仍是按实际批次变化。策略模型 RL 训练跑通后再同时启动验证器服务。观察验证器作为服务进程时是否和训练进程抢占显存。建议验证器用独立卡或纯 CPU 推理。用 nvidia-smi 定期记录显存变化是个基础操作nvidia-smi --query-gpuindex,memory.used,memory.total,utilization.gpu --formatcsv -l 5把输出重定向到日志文件训练结束后可以直观看到显存峰值和是否存在内存泄漏。9.2 训练效果判断信号CREST 式方法是否生效可以从训练曲线中找信号回合级信用是否比最终奖励更密集。如果一条 8 步轨迹最终成功在验证器约束下可能只有 2~3 步拿到正信用。这个密度比原来的 8 步全给要稀疏但比最终只给一次奖励要密集。策略模型对关键步骤的预测概率是否上升。可以固定几个关键动作做内部测试集观察这些动作的 logprob 随训练变化。长轨迹任务成功率是否相对基线有明显优势。如果只在短任务上有效果说明验证器约束带来的增量可能不够大需要检查验证器本身的判别能力。10. 常见问题与排查思路下表整理了复现或落地这类方法时最容易遇到的问题问题现象可能原因排查方式解决方案验证器把大量正确步骤判为 incorrect训练数据正负比例失衡negative 样本过多统计验证器在验证集上的类别召回率增加正确步骤样本或调整损失权重策略训练 loss 震荡严重验证器噪声过大信用发放不稳定抽样检查标注为 correct 的步骤内容给验证器增加 uncertain 类别或提高置信度阈值任务成功率没有提升验证器约束过强过滤掉了大部分训练信号统计平均每条轨迹有多少回合获得信用放宽阈值或对 uncertain 类别采用小权重显存 OOM轨迹过长批次内 token 总数超限查看训练日志和 nvidia-smi 日志减小 batch size、截断轨迹或启用梯度检查点验证器服务接口超时批量请求过多或推理并发设置过大查看服务端日志和 GPU 利用率增加排队机制或分批提交请求均匀分配时训练正常、加验证器后更差验证器本身准确率不足噪声超过了带来的信号单独评估验证器准确率先提升验证器准确率达到目标阈值再接策略训练最值得关注的坑是“验证器看起来有用但策略不涨”。常见原因是验证器在离线测试集上准确率高但实际轨道的状态分布和训练数据分布不一致。建议每跑一到两轮 rollout 后定期采样新的验证器负例加入下一轮验证器训练形成迭代闭环。11. 最佳实践与合规使用建议11.1 工程层面建议第一轮先小参数验证。先用 1B~3B 的小策略模型和短任务集跑通全流程确认验证器标注、信用分配、策略更新三段逻辑都正常再放大模型规模。保留一套最小可运行配置。把策略模型路径、验证器模型路径、轨迹数据目录、信用计算逻辑都固定在一个配置文件中方便复现。数据版本和验证器版本要做好对应。验证器更新后旧数据不要直接混用最好打上版本标签。批量任务要有状态管理。训练集和验证集分离状态文件定期备份。验证器服务如果暴露在网络中需要加访问鉴权避免被外部刷接口。11.2 合规层面建议多轮智能体训练中会大量使用用户对话、工具调用日志和行为轨迹数据。使用这类数据前务必确认数据来源是否有合法授权是否包含可识别用户身份的信息。涉及企业私有业务数据的要有脱敏处理流程。用户轨迹、浏览器操作记录、对话记录属于敏感数据的训练前要脱敏并限制访问范围。模型如果后续商用发布需要确认训练数据中是否包含受版权保护的文本或第三方服务输出内容。验证器约束信用分配本身是训练机制不涉及对具体内容生成方式的规避或滥用。但多轮 Agent 一旦被用于自动操作外部系统例如自动下单、自动发消息需要在测试环境中做充分验证并对失败动作设计安全边界。12. 总结与下一步CREST 论文提出的验证器约束信用分配方法解决的是多轮智能体训练中最实际的问题长时间跨度的多步决策中如何避免信用被均匀分配稀释。它的核心设计是引入验证器作为信用发放的“门”让最终结果的成功信号只在验证器确认正确的回合上生效从而减少错误动作被奖励的可能。如果想在自建项目里尝试这套思路建议第一步先做两件事一是收集一批带失败轨迹的多轮任务数据二是训练一个能区分正确/错误/不确定的验证器。先跑加权 SFT 版本确认验证器标注质量稳定后再上 RL会比直接复现完整论文流程稳妥得多。最容易踩的坑是验证器分布漂移解决方式就是周期性采样新轨迹、持续迭代验证器训练集。对做 Agent 训练的同学来说这类方法后续很可能和过程奖励模型、结果验证器进一步融合形成一套“结果校验 过程门控 信用分配”的完整训练管线。可以先把 CREST 的验证器约束思路沉淀成自己训练框架里的一个标准模块后续不管换什么策略优化算法都能直接复用。