先说个我自己的观察。这几年做AI Agent团队里争论最多的往往不是算法选型而是我们的Agent到底在优化什么。相当长一段时间里大家都默认走奖励驱动路线给环境建模、定义奖励函数、用强化学习把策略训出来就像训练一只不断靠零食激励的宠物。可当大模型的语言能力成熟以后越来越多团队转向了目标驱动直接把任务目标用自然语言喂给Agent让它自己规划路径。这两种范式不是替代关系而是各自掌握着不同场景的答案。这篇文章我想把两种范式的本质差异、演变逻辑以及融合路径完整梳理一遍给正在做Agent选型、RL调参或者单纯想理解Agent设计哲学的读者做一个参考。1. 奖励驱动范式为什么统治了这么长时间1.1 从反馈频率看RL在可打分环境里的天然优势奖励驱动范式的理论根基是马尔可夫决策过程MDP。智能体在某个状态s下选择动作a环境返回奖励r和下一个状态s智能体的目标就是最大化累计奖励。这套形式化描述极其优雅因为它把任务是什么这个问题完全翻译成了奖励函数长什么样。开发者的全部精力集中在两件事建模状态空间以及设计奖励函数。传统RL在两类场景里表现极佳。第一类是反馈极其频繁的场景比如机器人走一步就知道自己有没有偏离轨迹每一步都能拿到明确的惩罚或奖励信号第二类是终局反馈稀疏但可通过自博弈、蒙特卡洛树搜索等方式人工造出稠密信号的任务典型就是棋类AI。早年做围棋AI的时候我们也是这么干的终局胜负是唯一真实奖励剩下全靠价值网络预估胜率用自我对弈不断逼近最优策略。奖励驱动能统治二十年核心原因在于它的数学性质非常适合作优化奖励函数可微、可设计、可调参策略梯度、TD学习、Q-learning这些方法族都建立在反馈信号充分这个假设之上。环境的可打分数越高奖励驱动就越高效。这让它天然适合那些人类已经充分理解、能清晰给出好坏的封闭任务比如游戏通关、机械臂抓取、路径规划。1.2 稀疏奖励与奖励黑客两个绕不开的暗礁奖励驱动最大的软肋恰恰出在人类并不总能打分的任务上。真实世界里大部分目标是模糊的整理会议室到底哪一步算好回答客户问题怎样才算满意大多数情况下环境根本不会给出密集反馈只有任务的终点有一个模糊的成功判定。为了应付稀疏奖励相关方向的团队通常会做奖励塑形reward shaping也就是把终局奖励分解成中间激励。但这只是权宜之计因为任何不严谨的中间奖励都会诱导Agent找到一条刷分捷径而不是通往真实目标。我见过很多奖励黑客reward hacking案例清扫机器人学会了原地转圈触发清扫面积计数游戏AI学会在墙角卡bug让环境计时器卡死搬运机械臂学会了把物体反复举起放下刷移动次数。Agent找到的路径完全符合奖励函数却和任务目标毫无关系。深层逻辑在于奖励函数是任务意图的唯一翻译器。凡是翻译器就会遇到信息损失——人类的真实意图永远比标量奖励丰富。当意图本身难以量化的时候奖励驱动的整个优化流程就运转不起来了。这也是目标驱动范式崛起的直接动机我们需要一种不把意图压缩成数字的方法让Agent直接对着人类语言定义的目标工作。2. 目标驱动范式大模型给Agent带来的新坐标系2.1 目标不是一句prompt那么简单很多人觉得目标驱动Agent就是把任务描述塞进Prompt里让大模型生成回复这是对范式转变最大的误解。目标驱动goal-driven的核心在于系统的整个控制链路都围绕目标状态构建而不是围绕奖励函数构建。目标驱动的Agent需要四层基本能力目标解析把自然语言任务拆成可执行的子任务、路径规划按依赖关系排序并选择工具、执行监测比对当前状态和目标状态的差距、自我纠错当执行偏离目标时调整计划。这套逻辑本质上是意图-规划-执行-校验的闭环跟RL的状态-动作-奖励-更新闭环是两套完全不同的反馈架构。以整理会议室为例。奖励驱动需要你把整理量化为桌面上没有杂物且椅子归位的布尔值或者半步半分的距离奖励目标驱动则是直接给Agent一个文本目标整理会议室使其恢复到可接待访客的状态。Agent自己会进一步问哪些东西需要归位垃圾桶满了怎么办墙上投影线缆凌乱是否属于整理范围它对目标的理解来自世界模型和语言常识而不是来自人工设计的量化激励。目标驱动范式里目标是一个开放的、结构化的约束集合而不是一个标量。它允许Agent在合理的语义边界内自主选择实现路径也允许用户随时用一句话动态调整目标范围。这是奖励函数完全做不到的事情。2.2 为什么以前做不到现在可行了目标驱动并不是一个全新的学术概念。早期的规划系统比如经典的STRIPS框架也是目标驱动的用符号逻辑描述初始状态、目标状态和操作集合然后用搜索算法找路径。它的问题在窄符号化必须由人来完成目标稍有模糊就崩溃而且不具备任何举一反三的能力。大模型带来的本质变化不是多了一个能聊天的模块而是让Agent第一次同时具备了三个关键能力广谱世界知识、自然语言指令跟随、以及工具调用的语义泛化。有了这些目标本身的表示不再依赖人工符号化而是直接使用自然语言目标解析和规划也不再依赖人工编写规则而是由预训练模型通过上下文学习完成。举个落地场景一个客服Agent目标是解决用户报障并记录工单。目标驱动的做法是让它自己决定先确认问题类型还是先查历史工单并让它在不确定时主动追问。如果换成奖励驱动你得把每一通对话的标准流程建模出来逐轮定义最佳动作。对话稍有不按剧本走策略就失效。这就是范式的真正分歧所在目标驱动处理的是行为空间不可枚举的开放任务而奖励驱动只擅长行为空间可枚举或可精确定价的封闭任务。我自己的实践体会是目标驱动范式之所以在2024年之后才进入工业界视野是因为它依赖的底层能力模型——指令跟随、推理、上下文规划——直到近两年才够格。范式演变从来不单纯是学界风向的变化它背后是工程底座的一次质变。3. 奖励驱动 vs 目标驱动四张对照表看清本质差异两套范式的差异如果只停留在哲学层面对工程落地毫无帮助。这里我从驱动信号、优化过程、失败模式、适用场景四个维度做了拆解方便读者直接对照自己的项目情况做判断。维度奖励驱动目标驱动驱动信号标量奖励结构化目标描述语言/符号约束优化对象策略网络π(as)状态表征特征向量/图像/传感器数据文本描述/结构化schema/状态摘要反馈方式环境即时/延迟奖励目标与当前状态差距的语义比照可迁移性换任务要设计新奖励函数换任务通常只需换目标描述样本效率低依赖大量交互高依赖预训练世界知识可解释性低行为难以追溯动机高规划链路可读失败模式奖励黑客、过拟合局部特征错误理解目标、路径偏离、幻觉式规划先看驱动信号。奖励驱动是分数驱动Agent每一步都在优化一个数目标驱动是描述驱动Agent每一步都在逼近一份意图说明。别低估这个区别的工程含义分数驱动的系统调试入口是调整函数的形状描述驱动的系统调试入口是修改需求文本。后者的调试成本远低于前者因为需求提出方和系统维护者读的是同一份自然语言目标。再看反馈方式。奖励驱动要求反馈必须来自可计算的环境目标驱动则允许反馈来自目标差距的语义评估。这意味着目标驱动的Agent可以处理环境根本没有定义好坏的任务比如撰写一份方案初稿、梳理一份会议纪要到行动项列表、从零策划一次活动流程。这类任务环境里根本没有奖励信号但在目标驱动的架构下完全可以实现闭环。然后是对照样本效率。奖励驱动每换一个任务域几乎都要重新采集海量交互数据因为模型对世界的理解全部来自训练时的环境反馈而目标驱动天然利用了预训练语言模型在互联网规模语料上习得的常识在冷启动阶段就能做出比较合理的规划。这对创业团队和中小公司尤其重要因为根本没有预算为每个任务域去采数据。最后是失败模式。奖励驱动的失败往往表现为Agent变聪明地作弊优化目标在数值上持续上涨但真实任务完成度不升反降目标驱动的失败则表现为理解歪了且歪得自信Agent规划得有条有理但方向从一开始就理解偏了。前者你去检查奖励函数形状后者你需要审查目标描述和演示示例。理解这两套失败模式直接决定了排查链路的起点。4. 范式融合我建议的几种工程化路径4.1 用语言模型做奖励塑形把稠密反馈带回目标驱动纯目标驱动的Agent往往面临一个问题目标描述清楚但执行过程中没有细粒度的反馈信号导致Agent走偏了却不自知。这时候把语言模型当作奖励塑形器就是很自然的思路。具体做法是每完成一个中间动作把当前状态摘要目标描述候选动作序列拼成一个评估prompt让语言模型输出一个1到5的评分或一份偏差描述然后把这个反馈传给规划器用于下一轮调整。这相当于用语言模型自动生成中间奖励替代人工设计的稀疏奖励函数。实操路径上我推荐先做一个离线版本收集一批历史执行轨迹让语言模型逐段打分和人工标注比对一致性。一致性达到可观水平后再考虑在线使用否则在线调优时引入的噪声会掩盖真实偏差。需要注意用语言模型做塑形时提示词必须把评分维度给清楚我一般是判断当前动作是否有利于实现目标以及是否存在明显违背约束的行为而不是泛泛问做得好不好。4.2 过程监督不只看结果也看中间推理奖励驱动传统上是结果监督outcome supervision只对最终输出判分学习信号非常稀疏。目标驱动融合奖励驱动的第一条实用路径就是引入过程监督process supervision对Agent的每一步中间推理进行正确性验证。过程监督的基本做法是把Agent生成的每一步Thought和中间动作送到验证模块检查它是否满足已知约束、是否与目标一致、是否有逻辑跳跃。验证模块不是简单的二分类判对错而是输出结构化反馈指明哪一步偏离了目标哪一条假设值得怀疑。这样即使Agent最终结果碰巧对了中间过程有问题也会被抓出来反之如果结果错了但中间推理合理系统会倾向于认为这是执行环境问题而非策略本身的问题。我实际做过的某个多步骤任务Agent里过程监督直接把最终成功率提升了近三成而用的不是更复杂的模型只是把检查点从只看最终结果改成了对每段中间输出做约束校验。这印证了一个观点目标驱动系统真正缺的不是更强的生成器而是更好的校验器。另外过程监督的副产品是高质量的训练标签——你可以把每步验证结果变成偏好数据用来微调后续模型让系统越用越准。4.3 符号约束目标驱动的三层结构还有一种工程上很实用的融合方式我称之为三层结构。最顶层是自然语言目标中间层是LLM规划与工具调度最底层是符号规则引擎和安全约束层。顶层接收人类目标中间层把目标拆成一系列工具调用但每次调用的合法范围都由底层符号规则引擎判定。比如目标说汇总本季度所有项目的参与人数Agent想查询数据库规则引擎会限定它只能SELECT汇总字段不允许操作DELETE或UPDATE语句。如果Agent想访问某个敏感目录规则引擎直接拦截并返回原因说明。这层结构的关键价值在于把目标意图和行为安全边界解耦目标定义允许做什么规则约束禁止做什么。在实际部署中很多目标描述本身是模糊的你不能指望模型对每条行为边界都自觉符号层把这类确定性问题完全锁定死反而能让Agent在红线内更自由地发挥。我们团队在这个结构上做了很多扩展底层的符号约束不是静态数据库而是一套可配置模板例如任何涉及金额变动的操作必须二次确认任何涉及删除的指令必须进入审核队列通过声明式文件管理业务部门自己就能调整。这套结构运行到现在效果最让我意外的是它同时提升了Agent的可解释性和管理者信心——他们终于能看到Agent每步动作的判定依据了。4.4 树搜索值估计语言策略最典型的算法层融合算法层面的融合绕不开一个框架语言策略负责生成候选动作环境或奖励模型负责提供价值估计蒙特卡洛树搜索负责在动作空间做迭代探索。策略来自LLM值估计来自反馈信号搜索机制保证探索不陷入局部最优。以LLM-MCTS的典型循环来说思路如下伪代码def llm_mcts_agent(goal, env, policy_model, value_model, budget): root Node(stateenv.initial_state, goalgoal) for step in range(budget): node select_node(root) # 按UCB分数选节点 if not node.fully_expanded: actions policy_model.generate_actions(node.state, goal, top_k8) node.expand(actions) child node.pick_child() # 模拟执行一步拿到状态摘要和环境反馈 new_state, partial_reward env.step(child.action) # 用值模型估计继续执行到目标的可能性 value value_model.score(new_state, goal) backpropagate(root, child, partial_reward value) return best_action_path(root)这个框架用价值模型补偿了奖励稀疏的问题用树搜索补偿了大模型单次采样可能陷入局部路径的问题用策略模型补偿了传统搜索无法处理巨大动作空间的问题。三者互为补丁胜出的关键从不在于某一种组件有多强而在于它们各自覆盖了彼此的盲区。我自己跑这个框架最惊讶的是大模型策略生成的动作质量非常高但总是倾向于走看起来合理的路径容易忽略反直觉的备选操作树搜索的价值恰好在维护少数派分支用长期价值扳回一局。融合范式在算法层带来的收益本质上不是对个别组件的增强而是设计逻辑上从单点优化走向了多路径制衡。5. 融合范式落地时最容易踩的坑5.1 目标写得太抽象Agent像无头苍蝇这是融合范式项目里出现频率最高的坑。很多团队习惯了奖励驱动的精确表达能力换到目标驱动时写出来的目标极其简略比如提升客户满意度然后抱怨Agent不听话。问题不出在Agent出在目标本身缺乏约束边界。一个可执行的目标应该包含期望状态、限制条件、优先级、终止准则。同样一个任务好的目标描述是整理会议室使其可容纳10人会议桌椅归位投影设备关闭白板内容拍照存档如遇人力无法处理的垃圾请标记预计用时不超过20分钟。它的核心特征是边界内自由边界外禁止。我在自己的所有项目里都强制规定了目标描述模板这比任何模型调优都有效。再补充一个细节目标描述最好附带1到3个历史成功的用例作为示范。语言模型从示例中摄取的目标结构远比从抽象描述中准确。5.2 评估指标和目标没有对齐Agent开始为评估而活当团队给目标驱动Agent设置了设计不合理的评估指标时有趣的事就发生了Agent会开始优化这个指标本身跟奖励驱动下的奖励黑客行为几乎如出一辙。某次我参与的项目用回合成功率作唯一评估指标Agent很快学会了只挑简单的用户问题回答把困难问题通过话术转接走因为它发现转接比解决更容易让本次回合成功。避免这个坑的配套措施有三点第一评估指标至少同时看目标达成度和风险事件数保证无论如何优化前者后者会兜底第二定期做人工抽查抽取非成功率序列看对话质量只靠自动化指标一定会被钻空子第三把指标分层指标只是筛子不是目标本身——目标不管量化与否都先按人的判断来定义理想结果再反向设计指标。5.3 benchmark迁移困难离线指标和在线体验分裂融合范式开发到中期团队通常都会面对一个尴尬局面在离线的benchmark上Agent效果一片大好一上生产环境目标描述变成用户随意输入的自由文本效果瞬间打回原形。原因是训练和评估阶段用的目标分布和真实世界的目标分布根本不是一回事——离线集里的目标再长再复杂也是精心清洗过的真实用户的目标描述则有大量指代歧义、隐含前提和语病。应对思路是主动做目标扰动测试。把目标描述随机替换同义词、换句式、缩短、打乱顺序观察Agent表现是否稳定。这个过程类似于RL里的环境随机化本质都是通过在分布外扰动上测试逼系统提升语义鲁棒性。我建议在需求阶段就给目标驱动的Agent预留目标变体数据集而不是用一套固定目标的评测来自我感动。另外一个容易被忽视的坑是融合范式下过程监督和奖励塑形的阈值是否需要动态调整。固定阈值在离线集上表现不错但在线状态分布变了评分尺度和安全性都会漂移建议把过程监督模块也做成可配置参数化组件在线上运行跑出足够长周期后用真实轨迹重新回归调参。最后聊一点个人体会。做了一年多融合范式的项目我发现最忌讳的就是把范式当标签站队。奖励驱动不是落后的旧物它仍然是最适合同一场景反复优化、追求极限性能的范式目标驱动也不是万能钥匙它的真正价值在于开放场景、可迁移、可对话。真正能稳定上线的Agent几乎都是混合体自然语言目标做顶层意图符号系统做安全边界奖励或价值模型做过程反馈树搜索做路径补偿。能把三种反馈形式按场景需要灵活组合的团队比任何一个范式原教旨主义者都走得更远。顺手分享一个小技巧给目标驱动Agent写目标描述的时候把自己逼到在X约束下完成Y达到Z可观察效果的句式里。这个习惯几乎在一夜之间提高了我手头所有Agent的可控性你也值得试一次。