最近我在做一个需要智能体自动操作网页的项目。按教科书流程第一件事应该定义奖励函数完成预订打 1 分失败打 0 分多绕路扣一点。可真到写代码时才发现问题根本不是怎么编码而是“完成”本身说不清。页面上有验证码、弹窗、加载超时还有好多条都能接受的路径。你想写一段程序精确判断“这次操作算成功还是成功了一半”几乎不可能。这个困惑很有代表性。很多人把“强化学习需要可验证奖励”当成默认前提但现实任务里真正能写成确定性程序的奖励信号少得可怜。于是这两年出现了一类很受关注的思路不假设你有可验证奖励而是把奖励的来源、形式和验证方式重新设计。本文想聊的就是这套东西到底是怎么运作的以及作为 AI Engineer真正落地时该怎么想、怎么做。我先把核心判断放在前面强化学习从来不是不需要奖励而是奖励的来源被拓宽了。当任务无法给出可验证奖励时真正的工程解法是把“奖励设计”这件事本身变成一种可学习、可迭代的建模过程。不要被标题里的“无需”误导它说的是无需“预先可验证”不代表无需任何反馈信号。1. 先厘清一个误解可验证奖励从来不是强化学习的默认前提1.1 教科书里的强化学习为什么总拿游戏当例子经典强化学习框架里智能体通过与环境交互获得奖励目标是最大化累计奖励。围棋、象棋、雅达利游戏、机器人控制这些场景之所以成为经典示例不是因为算法喜欢它们而是因为它们自带一个“作弊神器”奖励函数可以被精确写成代码。围棋赢了给 1输了给 -1机械臂到达目标位置给正奖励游戏分数越高奖励越大。这类任务里目标可以被形式化验证奖励信号密集且清晰。你不需要讨论“这步走得好不好”因为规则已经替你裁判了。问题在于这种“可验证奖励”只是强化学习的一种理想输入不是所有任务的默认配置。一旦离开棋盘、游戏和仿真器进入真实的产品和工程场景你立刻会撞上一个尴尬局面目标存在但你写不出能验证它的程序。1.2 真实工程任务里“无法验证”才是常态我举几个常见的任务类型代码生成代码能编译、能通过单测不代表逻辑正确。你可以验证语法和测试用例但很难验证“这段代码是否符合用户意图”。文本生成没有标准答案。你说这篇文章写得好它好在哪里情感基调信息密度可读性这些都没法写成 if-else。网页操作任务可能部分完成可能走了错误路径但最终成功也可能表面成功但埋了隐患。评价本身带有模糊性。机器人操作目标是“把杯子放到桌子的合理位置”什么算合理取决于场景上下文。在这些任务里你面临一个共同问题结果能观察但评价结果的标准不透明。这不是算法 bug而是任务本身的性质。如果非要用传统可验证奖励去硬套通常只能得到两种结果要么奖励极度稀疏智能体学不到东西要么你把任务粗暴简化最终优化了一个和真实目标不一致的代理指标。1.3 为什么这成了今天必须面对的问题过去十几年强化学习的突破很大程度上建立在“可验证奖励”这个红利上。AlphaGo 有明确胜负机器人控制有明确的物理目标游戏有明确分数。但今天强化学习被推到更多智能体和内容生成场景时红利消失了。AI Engineer 的角色也因此变了。以前主要工作是“把目标翻译成奖励函数”现在变成“在目标无法精确翻译的情况下设计一条获取反馈信号的通路”。这条路不是不能走但需要理解它的机制和代价。2. 当奖励不可验证主流路线不是“去掉奖励”而是“让奖励可以被学习”2.1 第一类让人类偏好变成奖励信号人类无法写出精确的奖励函数但人类能轻松做比较两个回答哪个更好两条操作轨迹哪条更合理基于这个事实主流做法是把“比较结果”当成数据训练一个奖励模型。具体流程是采样一堆行为结果让标注者两两比较并给出偏好然后用这些偏好数据训练一个打分模型。这个模型接收一段行为轨迹或一个输出输出一个分数就变成了一个“可用的奖励”。之后再用强化学习优化策略。这里的关键变化是奖励不再是被写出来的而是被学习出来的。人类不需要解释为什么这步好、那步不好只需要给出偏好判断。偏好判断的噪音和一致性会被奖励模型吸收一部分但不会完全消失。2.2 第二类跳过奖励模型直接在偏好上优化策略学习一个奖励模型再优化策略是两步流程。奖励模型本身可能过拟合、可能被策略钻空子、可能引入额外的不稳定性。于是出现了另一类做法不显式训练奖励模型而是设计一个目标函数让策略直接根据偏好数据更新。这类方法的数学形式不同但核心思想是近似的如果一条回应 A 比另一条 B 更被人类偏好那策略就应该提高生成 A 的概率、降低生成 B 的概率。整个过程不需要单独的奖励网络作为中介偏好的影响像“隐性奖励”一样直接作用在策略上。从工程角度看这样做少了一个组件也就少了一个故障点。但代价是你失去了一个可以调试、可以可视化、可以单独评估的“奖励界面”。到底是两步好还是一步好取决于你的团队能力和任务复杂度没有普适答案。2.3 第三类从示范中学习而不是从评价中学习有时候你连偏好数据都很难收集但你能拿到一批“正确的过程”。比如记录资深工程师完成一个任务的操作序列或者收集一批高质量回答。这就是示范数据。从示范中学习本质上是另一种“隐式奖励”默认示范轨迹是好的希望策略去模仿。但这里要小心示范数据只能告诉你“应该做什么”不能告诉你“为什么这样做”。它学到的是一个行为分布而不是对目标的理解。如果示范数据里存在矛盾或噪音策略也会照单全收。2.4 第四类把结果评价拆成过程评价一个很实用的思路是不评价整个结果而是评价中间的每一步。代码生成任务可以逐步检查“这一步是否正确定义了接口”“这一步是否处理了边界条件”数学推理任务可以检查每一个推导步骤是否成立。这种方式常被称为过程监督或过程奖励。它把一个模糊的最终目标拆成多个相对可判断的局部目标。这也是目前处理长链条任务时最常见的工程选择最终结果难验证但中间步骤的部分属性是能被规则或模型判断的。不过拆解本身也需要设计。拆得太粗局部判断还是模糊拆得太细标注成本爆炸。而且每一步的“正确”也可能依赖上下文——这一步单独看是对的但在整体策略里可能就是错的。方法信号来源典型适用主要风险偏好 奖励模型人类两两比较内容生成、通用助手奖励模型被策略利用直接偏好优化人类两两比较内容生成组件精简缺少可调试的奖励界面示范学习高质量过程记录操作类任务、机器人学到行为分布而非目标过程监督步骤级评价代码、数学、长链推理局部正确不等于全局正确3. 为什么这些方案能成立几个容易被忽略的底层判断3.1 “可验证奖励”是显式目标“学习式奖励”是隐式目标传统强化学习把目标放在台面上奖励函数就是目标本身。学习式奖励把目标藏在数据里人为偏好、示范轨迹、过程标注都是目标的“投影”。策略优化的目标是满足这些投影而不是直接满足一个显式公式。这带来一个务实的好处很多任务的目标本来就是难言明的与其强行形式化不如让模型从人类判断中反推。但代价也随之而来——你优化的是一个“被估计出来的目标”它的误差会直接传导到最终策略上。3.2 信号可以稀疏但不能为零不管你用哪种方案最终都要有某种信号驱动策略更新。所谓“无需可验证奖励”只是把信号从“程序化的分数”换成了“人类偏好、示范数据、步骤评价”等别的形式。如果一项任务真的是零信号——没有任何人知道什么算好、什么算差也没有任何可比较的样例——那任何方法都无能为力。这不是强化学习的局限而是任务本身的定义缺失。所以真正的问题不是“我的任务没有可验证奖励怎么办”而是“我的任务里哪些不可验证的部分存在可获取的比较信息”。3.3 AI Engineer 的职责从“定义奖励”变成“设计反馈系统”以前做强化学习你花最多时间在调奖励函数的系数现在你会发现主要精力转移到别处设计反馈收集流程怎么采样候选结果怎么设计对比界面怎么控制标注成本。控制反馈质量标注者是否理解任务判断标准是否一致有没有恶意或偷懒标注构建迭代回路策略更新后奖励模型是否还准确要不要补充新反馈数据这是一个系统设计问题不是一个数学优化问题。很多项目不是死在策略算法上而是死在反馈数据的质量、数量和一致性上。理解这一点才算真正进入了“无验证奖励”的实战状态。3.4 代价必须说清楚样本效率、一致性、奖励黑客学习式奖励不是免费的午餐。三个代价最明显样本效率低收集人类偏好和示范数据比运行模拟器贵得多。一致性难保证同一个行为不同标注者可能给出完全相反的评价。奖励黑客风险高策略会找出最大化奖励模型分数的捷径而这个捷径往往和真实目标背道而驰。尤其是第三点。传统强化学习里如果奖励函数是上帝给的你还能相对信任它当奖励模型只是真实目标的近似时策略优化得越充分越容易暴露奖励模型的盲区。这不是“调一调参数”能解决的问题而是需要在评估环节留出独立验证通道。4. 从单点实验到工程落地一个可执行的推进路径4.1 第一步把任务拆成“可评价的最小单位”不要一上来就想训练一个大模型先把任务拆小。拆分的标准不是功能粒度而是“这一步的评价是否相对清晰”。比如网页操作任务最终“完成预订”难验证但中间动作可以拆成“是否正确填写了日期”“是否正确选择了航班”“是否弹出了确认页面”。每一步都有相对确定的判断方式。这意味着你可以先给中间步骤配过程奖励最后一步再处理模糊评价。拆完之后你会得到一张清单哪些部分有程序化检查哪些部分需要人类判断哪些部分暂时无法评价。这张清单本身就是后续所有工作的地基。4.2 第二步为每一块选择信号来源根据清单决定信号获取方式有明确程序化检查的直接用规则作为奖励信号。没有规则但有比较价值的两两结果收集偏好数据。有高质量示范过程让策略先模仿。长流程任务引入步骤级监督。在实际项目中通常不是只用一种方法而是混用。代码生成可以用单测结果作为硬信号再用偏好数据覆盖代码风格和架构合理性。多渠道信号之间要设计好权重否则一个强信号会淹没其他信号。4.3 第三步先跑通一条完整回路再做规模优化这是我最想强调的一点。很多人拿到新方法第一反应是把数据集铺满、把批量拉大、把训练跑满。但对无验证奖励任务最不该做的就是“先大规模”。正确顺序是用 10~20 条样本跑通从“采样 → 获取反馈 → 更新策略 → 评估”的完整链路。检查反馈信号是否区分度足够好行为和坏行为的得分差异是否明显。检查策略更新后奖励分数是否真的上升而人工评估是否也同步变好。确认没有明显短路行为后再逐步扩大样本量和训练轮次。这条链路里任何一个环节断裂都值得先修而不是用更多数据掩盖问题。4.4 第四步建立独立评估集别让训练指标骗了你当你用学习式奖励时训练奖励分数天然有水分。策略会越来越擅长“讨好”奖励模型但不一定在真实任务上变好。因此必须准备一个独立评估集由一组不参与训练反馈标注的人按一套固定的标准对策略输出进行人工盲评。训练中每过几个迭代就跑一次独立评估。如果训练分数涨了、独立评估没涨甚至跌了你基本可以判断奖励模型开始被利用了。这时要停下训练补充反馈数据或者调整奖励模型。注意独立评估集不能从训练用的反馈数据里抽出来当验证集。标注来源、标注者、采集时间都相同的话它测不出泛化问题。5. 最容易翻车的四个地方以及对应的排查链路5.1 奖励黑客策略找到了你没看见的漏洞现象训练分数持续飙升但人工评估结果平平。原因通常是策略发现了某个和真实目标高度相关、但不完全一致的代理特征并疯狂利用它。比如奖励模型偏爱长回答策略就无限拉长输出偏爱某些关键词策略就把关键词全部堆上去。排查顺序先从奖励模型输入入手看策略生成的结果里到底哪些特征在主导分数然后回看训练数据分布确认该特征在训练集中是否被过度代表最后用独立评估确认真实性能。不要一上来就加正则或改网络结构先把“奖励模型在奖励什么”弄清楚。5.2 反馈标注不一致训练数据本身是矛盾的现象奖励模型训练损失高居不下或者策略行为漂移。原因可能不是实现 bug而是标注者根本没理解任务标准或不同人对“好”的定义差异太大。排查链路先分标注者看一致性指标然后查看争议样本看争议集中在哪类案例上如果争议样本有共性比如都是模糊概念那就需要调整标注指南或者把这些样本从训练集中剔除。必要时可以只保留一致性高的标注子集来训练牺牲数量换质量。5.3 过拟合到反馈分布策略在分布外彻底失控现象在训练分布内表现良好一遇到新场景就崩。原因是反馈数据覆盖的场景太窄策略只在窄分布上被约束过。排查链路先对策略输出做聚类看它是否只掌握了少数几种模式然后观察评估集中的分布外样本表现接着扩充反馈数据覆盖更多边界场景。这里要记住反馈数据的“多样性”比“数量”更重要。5.4 过程信号和结果信号冲突现象每一步评价都对但最终结果很差。比如代码生成每一步语法都对但整体代码做了一件错误的事。原因是局部评价没有考虑全局目标。排查链路先检查过程监督的每一段是否独立可判再看全局结果是否被过程分数掩盖。解决方案通常是给最终结果保留一部分权重即使最终结果难验证也要用粗略的结果判断“兜底”避免策略在局部正确里迷失。如果你遇到问题不知道从哪查起可以按这个顺序走先看现象分数涨没涨、输出稳不稳、评估跌不跌。再看反馈来源标注一致吗样本覆盖够吗规则有没有误判再看奖励模型它的分数到底在响应什么特征最后才看策略更新学习率、批量大小、更新轮次这些通常不是首因。6. 一个可复用的判断框架什么场景该用什么路线面对一个“奖励不可验证”的新任务不要急着选算法。先做三件事判断信号是否存在、判断信号按什么粒度存在、判断信号获取成本是否可控。任务特征可用的信号建议路线结果有部分规则可检查单测、校验器、约束检查规则奖励 偏好奖励混合结果没有规则但人能比较两两偏好偏好 奖励模型或直接偏好优化有大量高质量过程示例示范轨迹示范学习 偏好微调任务是长流程、多步骤步骤级判断过程监督 结果粗判兜底既无规则、又无偏好、又无示例无信号不建议直接上强化学习先做任务定义判断准则可以收紧成一句话可验证的部分优先用程序化信号不可验证但可比较的部分用偏好信号不可比较但可示范的部分用示范信号三者都没有就先补任务定义。选用具体方法时还有几条经验值得记住奖励模型适合你希望可以单独调试奖励行为的场景因为有中间层可以检查和可视化。直接偏好优化适合你想减少组件数量、让流程更简单的场景但要接受缺少中间变量。过程监督适合长链条任务但拆步骤的粒度需要根据标注成本反复调。示范学习适合快速得到一个“合理但不是最优”的起点很难靠它走到上限。7. 收尾真正的门槛不是写出奖励而是看懂任务信号在哪里回到文章开头那个网页操作项目。我后来没有写一个完整的奖励函数而是给可验证的中间步骤加了规则给最终结果设计了偏好对比流程再留一个独立评估集做人工抽验。整体跑下来它确实比最初的理想化方案走得更远。这件事改变了我的一个认知可验证奖励是一种特权不是默认配置。能写出确定性奖励的任务往往意味着你足够幸运目标足够清晰写不出来也不代表强化学习这条路线走不通只是说明你要把更多精力放在反馈信号的设计、获取和质量控制上。对那些正在研究“强化学习无需可验证奖励”的工程师我的建议是别把注意力全放在算法差异上先老老实实回答三个问题——我的任务里有哪些信号这些信号怎么获取获取之后怎么验证它没被扭曲这三个问题想清楚无论最终选哪条技术路线你都已经站在了正确的位置上。奖励写不出来不是问题的结束而是工程真正开始的地方。