企业官网建设流程全解析

最近我在做一个需要智能体自动操作网页的项目。按教科书流程，第一件事应该定义奖励函数：完成预订打 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 第三步：先跑通一条完整回路，再做规模优化

这是我最想强调的一点。很多人拿到新方法，第一反应是把数据集铺满、把批量拉大、把训练跑满。但对无验证奖励任务，最不该做的就是“先大规模”。

正确顺序是：

1. 用 10~20 条样本跑通从“采样 → 获取反馈 → 更新策略 → 评估”的完整链路。
2. 检查反馈信号是否区分度足够：好行为和坏行为的得分差异是否明显。
3. 检查策略更新后，奖励分数是否真的上升，而人工评估是否也同步变好。
4. 确认没有明显短路行为后，再逐步扩大样本量和训练轮次。

这条链路里任何一个环节断裂，都值得先修，而不是用更多数据掩盖问题。

4.4 第四步：建立独立评估集，别让训练指标骗了你

当你用学习式奖励时，训练奖励分数天然有水分。策略会越来越擅长“讨好”奖励模型，但不一定在真实任务上变好。因此必须准备一个独立评估集：由一组不参与训练反馈标注的人，按一套固定的标准对策略输出进行人工盲评。

训练中每过几个迭代，就跑一次独立评估。如果训练分数涨了、独立评估没涨甚至跌了，你基本可以判断奖励模型开始被利用了。这时要停下训练，补充反馈数据，或者调整奖励模型。

注意：独立评估集不能从训练用的反馈数据里抽出来当验证集。标注来源、标注者、采集时间都相同的话，它测不出泛化问题。

5. 最容易翻车的四个地方，以及对应的排查链路

5.1 奖励黑客：策略找到了你没看见的漏洞

现象：训练分数持续飙升，但人工评估结果平平。原因通常是策略发现了某个和真实目标高度相关、但不完全一致的代理特征，并疯狂利用它。比如奖励模型偏爱长回答，策略就无限拉长输出；偏爱某些关键词，策略就把关键词全部堆上去。

排查顺序：先从奖励模型输入入手，看策略生成的结果里，到底哪些特征在主导分数；然后回看训练数据分布，确认该特征在训练集中是否被过度代表；最后用独立评估确认真实性能。不要一上来就加正则或改网络结构，先把“奖励模型在奖励什么”弄清楚。

5.2 反馈标注不一致：训练数据本身是矛盾的

现象：奖励模型训练损失高居不下，或者策略行为漂移。原因可能不是实现 bug，而是标注者根本没理解任务标准，或不同人对“好”的定义差异太大。

排查链路：先分标注者看一致性指标；然后查看争议样本，看争议集中在哪类案例上；如果争议样本有共性，比如都是模糊概念，那就需要调整标注指南，或者把这些样本从训练集中剔除。必要时可以只保留一致性高的标注子集来训练，牺牲数量换质量。

5.3 过拟合到反馈分布：策略在分布外彻底失控

现象：在训练分布内表现良好，一遇到新场景就崩。原因是反馈数据覆盖的场景太窄，策略只在窄分布上被约束过。

排查链路：先对策略输出做聚类，看它是否只掌握了少数几种模式；然后观察评估集中的分布外样本表现；接着扩充反馈数据，覆盖更多边界场景。这里要记住，反馈数据的“多样性”比“数量”更重要。

5.4 过程信号和结果信号冲突

现象：每一步评价都对，但最终结果很差。比如代码生成，每一步语法都对，但整体代码做了一件错误的事。原因是局部评价没有考虑全局目标。

排查链路：先检查过程监督的每一段是否独立可判，再看全局结果是否被过程分数掩盖。解决方案通常是给最终结果保留一部分权重，即使最终结果难验证，也要用粗略的结果判断“兜底”，避免策略在局部正确里迷失。

如果你遇到问题不知道从哪查起，可以按这个顺序走：

1. 先看现象：分数涨没涨、输出稳不稳、评估跌不跌。
2. 再看反馈来源：标注一致吗？样本覆盖够吗？规则有没有误判？
3. 再看奖励模型：它的分数到底在响应什么特征？
4. 最后才看策略更新：学习率、批量大小、更新轮次这些，通常不是首因。

6. 一个可复用的判断框架：什么场景该用什么路线

面对一个“奖励不可验证”的新任务，不要急着选算法。先做三件事：判断信号是否存在、判断信号按什么粒度存在、判断信号获取成本是否可控。

判断准则可以收紧成一句话：可验证的部分优先用程序化信号，不可验证但可比较的部分用偏好信号，不可比较但可示范的部分用示范信号，三者都没有，就先补任务定义。

选用具体方法时，还有几条经验值得记住：

• 奖励模型适合你希望可以单独调试奖励行为的场景，因为有中间层可以检查和可视化。
• 直接偏好优化适合你想减少组件数量、让流程更简单的场景，但要接受缺少中间变量。
• 过程监督适合长链条任务，但拆步骤的粒度需要根据标注成本反复调。
• 示范学习适合快速得到一个“合理但不是最优”的起点，很难靠它走到上限。

7. 收尾：真正的门槛不是写出奖励，而是看懂任务信号在哪里

回到文章开头那个网页操作项目。我后来没有写一个完整的奖励函数，而是给可验证的中间步骤加了规则，给最终结果设计了偏好对比流程，再留一个独立评估集做人工抽验。整体跑下来，它确实比最初的理想化方案走得更远。

这件事改变了我的一个认知：可验证奖励是一种特权，不是默认配置。能写出确定性奖励的任务，往往意味着你足够幸运，目标足够清晰；写不出来，也不代表强化学习这条路线走不通，只是说明你要把更多精力放在反馈信号的设计、获取和质量控制上。

对那些正在研究“强化学习无需可验证奖励”的工程师，我的建议是：别把注意力全放在算法差异上，先老老实实回答三个问题——我的任务里有哪些信号？这些信号怎么获取？获取之后怎么验证它没被扭曲？这三个问题想清楚，无论最终选哪条技术路线，你都已经站在了正确的位置上。

奖励写不出来，不是问题的结束，而是工程真正开始的地方。