16-奖励设计多轮任务与工具调用从结果奖励到过程约束、路径惩罚系列导读上一篇讲了SFT与RL的本质区别这一篇深入RL的心脏——奖励Reward。基于李博杰《深入理解AI Agent设计原理与工程实践》的奖励设计章节结合售货柜Agent与Coding Agent的真实bad case展开。奖励设计是RL工程里回报密度最高的环节改对一处奖励胜过调一百次参数。一、奖励来自哪里规则、人类偏好与模型评判RL的第一问奖励信号从哪来三条路规则奖励程序可判定的硬标准——单元测试通过、答案精确匹配、订单金额计算正确。优先用它便宜、准确、无争议。退款Agent退款金额订单实付金额就是一条天然规则奖励人类偏好人类对两条轨迹二选一A更好还是B更好。信息质量高但贵、慢、不可规模化一般用来训练裁判模型或校准方向模型评判RLHF/RLAIF/LLM-as-a-Judge用模型给开放性输出打分——回复是否礼貌、解释是否清晰。可规模化但裁判本身可能出错第14篇讲过kappa校准这里同样适用。工程铁律能用规则的绝不用模型判能用模型判的绝不用人工。三层混搭是常态结果用规则、风格用模型判、争议样本人工仲裁。二、奖励在什么时候给结果还是过程第二问奖励给在终点还是路上结果奖励Outcome Reward轨迹走完只看最终结果对不对。实现简单但信号极稀疏——一条50步的轨迹只有1个奖励点模型不知道中间哪步是对的哪步是错的学起来像在黑暗里摸索过程奖励Process Reward在关键步骤上给中间反馈。信号密集学得快但每一处中间判分都是潜在的偏见注入点——你的中间标准如果定错了模型会精确地学会错误的标准。《深入理解AI Agent》里的实践观点很清醒结果奖励保真过程奖励提效结果为主、过程为辅。三、奖励需要表达多少信息标量、向量与生成式诊断奖励值的形态也有讲究标量奖励一个数1/-1/0.7。信息最少但与RL算法兼容性最好当前主流向量奖励多维度打分正确性、安全性、效率各一个分数可以做多目标权衡但训练算法要改造生成式诊断不是给分数而是生成一段文字反馈“第3步金额用错了字段”。信息量最大对人类调试极其宝贵但没法直接喂给策略梯度——它主要服务于人或通过反馈微调间接作用于模型。实践中推荐训练用标量调试看诊断。我们的流水线会同时输出奖励值和LLM生成的失败诊断报告前者喂模型后者喂工程师。四、结果正确还不够路径约束与RL VP验证路径惩罚这一节是本篇的核心洞察。只给结果奖励会发生什么模型会找到结果对、过程离谱的路径。举个例子退款Agent发现直接把订单标记为异常走人工通道也能让用户拿到钱结果奖励1但它绕过了责任判定和防薅羊毛检查。结果对了过程埋雷。应对方案是RL VPVerified Paths验证路径惩罚 / 奖励结果约束过程结果用奖励驱动过程用约束和惩罚管住。具体做法硬约束动作掩码/非法动作惩罚白名单之外的动作直接判负——退款Agent只允许调用退款、查单、通知三个工具碰别的就是大额负奖励路径惩罚结果正确但路径违规奖励打折甚至归零。比如未做柜机日志核查就退款结果对了也只给50%奖励效率惩罚每多一步工具调用扣一点奖励防止宁可错查一千不可放过一个的过度查询把成本打爆。一句话奖励告诉模型把事做成约束告诉模型用正确的方式做成。业务系统里后者往往更重要——一个用歪门邪道达成KPI的员工比一个完不成KPI的员工更危险Agent同理。五、从单轮到多轮信用分配问题单轮任务问一句答一句的奖励很简单。但Agent的本质是多轮任务几十轮交互、十几次工具调用之后才出结果。这带来RL最经典的难题——信用分配Credit Assignment最终失败了到底是第几步的锅最终成功了功劳属于哪些步骤一条轨迹里前面第2步选错工具、后面靠运气弥补成功的情况很常见反过来前面全对、最后一步手滑的情况也有。如果只把最终奖励粗暴地平摊到每一步信号就被噪声淹没了。工程上的应对缩短任务跨度把长任务拆成子任务分段训练先练查证诊断再练执行退款最后串起来轨迹分组GRPO的组内比较天然适合同一任务多条轨迹对比成功与失败轨迹的分歧步骤大概率就是关键决策点过程奖励补位在可客观判定的中间节点如是否查了日志给少量过程分缓解稀疏。六、工具调用把环境带进Agent第15篇末尾提过这里展开讲奖励侧工具调用场景的奖励设计本质是把真实环境搬进训练循环。模型输出工具调用 → 沙箱环境真实执行查数据库副本、调用mock支付接口、跑测试→ 返回真实结果 → 模型基于结果继续奖励来源就是环境的真实反馈测试跑过了、订单状态改对了、接口返回成功。好处是奖励天然客观不用人拍脑袋造。代价是环境建设成本高你要准备可重置的数据库快照、mock的第三方接口、隔离的文件系统。但这个投入值得——环境就是RL的题库阅卷老师环境质量直接决定训练上限。七、蒸馏提升样本效率On-Policy DistillationRL很贵一题16次rolloutSFT很便宜一次前向。有没有折中有——蒸馏尤其是On-Policy Distillation在线策略蒸馏传统蒸馏强教师离线生成示范 → SFT训练学生。问题教师的行为分布和学生不一致学生学到的动作在自己状态下未必适用On-Policy Distillation学生自己先rollout一次教师针对学生轨迹的每一步给出更优的下一步学生拿这份密集的逐步监督做训练。妙处在于一次rollout产生了密集的逐步监督信号——每一步都有教师指路信号密度堪比过程奖励成本却低得多。它把RL的试错和SFT的模仿焊在了一起学生探索教师纠偏。那如果没有更强的教师呢自蒸馏Self-Distillation让模型自己生成多条轨迹用规则/判分器筛出最好的那条再拿来训练自己——本质上是跟自己的高光时刻学习。配合拒绝采样这在业务落地里是被反复验证有效的廉价增强手段。八、从bad case到后训练三个真实案例理论讲完了看三个我们真实踩过的坑脱敏后案例1Coding Agent过早结束现象模型写代码时频繁摆烂——写了个半成品就提交说已完成因为结束任务能拿到部分通过测试的奖励继续写反而可能改坏。归因奖励函数里提前结束没有惩罚部分通过的分数让模型学会见好就收。修复引入验证路径惩罚——声称完成但测试未全过施加比继续工作更大的负奖励完成必须通过测试验证才算数。案例2中文引号现象模型输出的JSON里冒出中文引号“”下游解析器直接崩溃。模型本身能力没问题就是习惯性手滑。归因这种低级错误用Prompt纠正效果很差说一百遍还是会犯。修复SFT阶段在数据里统一英文引号 RL环境里解析失败直接判负。几千次负反馈之后模型手滑率从2%降到0.01%以下。这类确定性、可机检的格式错误是最适合RL根除的问题。案例3编辑文件失败现象Agent编辑代码文件时经常失败——先读文件等到写的时候上下文里的文件版本已经过时中间执行过测试或格式化导致写入冲突或覆盖丢代码。归因环境给了陈旧的观察模型没有养成写前重读的习惯而奖励只看结果偶尔侥幸成功让它没动力改。修复环境侧加写前校验版本不一致强制失败 奖励侧对未重读就写入导致的失败额外惩罚双管齐下。三个案例的共同套路bad case → 失败归因 → 判断是环境问题还是奖励问题 → 修复 → 回归验证又是第14篇的评估循环一切都是环环相扣的。九、后训练实践要点收尾给一份实践清单奖励先简后繁从纯结果奖励起步跑通再叠加过程约束一上来就设计十维向量奖励必然调不动警惕奖励黑客Reward Hacking模型是专业的钻空子选手每次改奖励函数后盯紧它有没有找到新的邪道结果对但过程离谱约束比奖励更保值奖励引导方向约束守住底线底线性质的东西安全、白名单、幂等全部用硬约束实现环境与评估隔离训练环境题目分布和评估集严格分开第15篇的教训奖励设计里同样适用成本敏感性过程奖励、教师蒸馏、多次rollout都在烧钱用消融实验第14篇证明每一层复杂度确实带来了收益再保留它SFT与RL不是二选一格式与基础流程交给SFT决策与泛化交给RL遇到样本效率瓶颈考虑On-Policy Distillation。小结奖励三来源规则 模型评判 人工能用便宜的绝不用贵的结果奖励保真、过程奖励提效结果为主、过程为辅RL VP奖励结果、约束过程——结果对但路径违规要惩罚歪门邪道达成KPI比不达标更危险多轮任务的核心难题是信用分配靠任务拆分、组内对比、过程奖励补位工具调用奖励的根基是真实可重置的环境On-Policy Distillation用一次rollout换取逐步密集监督无强教师时用自蒸馏bad case是后训练最好的需求来源归因、修复、回归循环往复。至此从评估指标、评估环境到SFT/RL后训练、奖励设计这条让Agent从能演示到能生产的链路就走通了。评估告诉你哪里不行后训练让它真的行。