1. 一次评测翻车让我重新审视“过程奖励模型”这个标题看着像吐槽但我是认真踩过坑才这么说的。半年前我在做一个 Agent 工具调用评测方案当时想了一个自认为很巧的思路把数学推理领域验证过的 PRM也就是过程奖励模型直接拿来对 Agent 的每一步工具调用打分。理由听起来很充分——解数学题是多步推理Agent 调用工具也是多步推理既然 PRM 能看出“哪一步对、哪一步错”那它也一定能看出 Agent 哪一步工具调得对、哪一步调得不对。这里插一句背景。PRM 近年在数学推理评测里确实很能打它的核心价值就是给模型每一步推理过程分配一个质量分数而不是像结果奖励模型那样只盯着最终答案。数学题里的“过程”和“结果”天然可区分所以大家很自然地想把它泛化到更复杂的智能体场景。我当时就踩进了这个泛化陷阱第一批评测样本跑完PRM 给出的过程分数和人工判断的一致性低得离谱。尤其是它特别喜欢把“过程中出现了失败信号”直接等同于“这个 Agent 动作质量差”完全没考虑过很多工具调用失败其实是有效的策略性探索。这篇文章想把这次翻车过程中观察到的现象和背后的原因讲透分四个层面展开PRM 在数学题上到底是怎么起效的、Agent 工具调用和数学推理的本质差异在哪、具体会翻车在哪些场景以及如果真要做 Agent 工具调用评估应该怎么设计更合理的方案。不管你是做智能体质量评测的还是想给自己的 Agent 加一层“过程监控”能力的这篇都会有用。2. 数学题 PRM 在自己的地盘上确实有两把刷子2.1 先弄清“过程奖励模型”解决的是什么问题要理解 PRM 为什么在数学推理场景里受欢迎得回到一个基础矛盾结果奖励模型只能给整个回答打一个总分数一旦最终答案错了你根本不知道错在哪一步。在复杂的多步推理里这种“单标签反馈”的信息量太低等于告诉你考试成绩不及格但不说你是哪个知识点不会。PRM 做的事就是把推理轨迹按 token 或按步骤切分为每一个局部步骤预测一个质量分数。它会根据模型的隐藏状态判断“这步推论是否符合逻辑、是否朝着最终答案前进”然后用这些中间分数去指导搜索、剪枝或强化学习。在数学题这种环境里它的判断对象是完全自包含的每步推理只依赖之前写下的表达式和已有公理不用考虑外部世界的反馈所以过程分数可以做到相对独立、可解释。我在实际看 PRM 做数学题评分的时候最直观的感受是它对“某一步突然跳过了关键推导”或“某一步引入了一个无关条件”这类错误识别相当准确。原因很朴素数学推理步骤是强约束的存在大量范式化的中间状态PRM 在训练的时候见过海量类似模式模型很容易学到哪种 token 序列看起来像“在推进”哪种不像。2.2 数学环境给 PRM 提供了三样“特权”支撑 PRM 在数学题里好用的并不是它的算法有多么通用而是数学题环境恰好提供了三样别的场景很难复制的前提。第一动作空间高度封闭。数学题的解题动作说白了就是交换律、结合律、移项、代入、展开、求导这些有限操作每一步都建立在明确定义的规则上。PRM 可以覆盖这些规则的全部组合模式。第二中间状态天然可验证。推理过程里出现的每一步都可以脱离环境单独判断对错。比如化简到一半你可以直接说这一步等号变换不成立不需要知道题目外部发生了什么。第三终点状态唯一。数学题的标准答案只有一个过程的正误和最终结果之间有很强的因果关联。过程对答案大概率对过程错答案往往也错。这种单峰分布让过程分数有了很直接的监督信号。这三样特权组合在一起PRM 在数学题上几乎是在一个“真理可判定的封闭宇宙”里工作。它看到一步就是一步不需要考虑上下文扰动更不需要考虑外部系统状态。2.3 数学 PRM 使用的默认假设过程可切片、错因可定位从方法论上看过程奖励模型的本质假设是“整体质量可以被局部步骤的得分累加或组合得出”。这个假设在数学题里大体成立因为错因能定位对错能拆解。举个我在评测里常见的例子一道应用题前面建方程全对最后一步计算失误。PRM 会把前面步骤标为高分把最后一步标为低分整条轨迹的错误被准确锚定到一个局部位置上。这种细颗粒度定位能力是它显著优于结果奖励模型的地方。但正是这个“默认假设”在迁移到 Agent 场景时埋下了隐患。因为 PRM 是根据训练数据学会“哪类步骤看起来好”的一旦遇到它没见过的步骤类型比如一次实际 API 调用返回了异常数据、一个需要多轮试探才能成功的查询它的先验就会跑偏。它不是没能力而是被训练成只在一个特定世界里打分。用数学题训练出来的 PRM 评判 Agent 工具调用本质上是让一个只见过封闭推理链的裁判去给一场开放世界的实时博弈做判罚。3. Agent 工具调用和数学推理之间隔着三个本质差异3.1 动作空间从“封闭推演”变成“开放交互”数学题的每一步本质上是符号变换Agent 调用工具则远不只是“选一个算子”。真实工具调用里每一次调用至少包含选工具、填参数、处理返回、决定是否重试、判断是否切换方案这几个子问题。开放 API 的参数空间巨大返回结果的格式和语义充满不确定性外部服务的状态也在随时变化。讲一个我在评测里反复看到的现象同一个任务Agent 第一次调用某个查询接口因为上游数据尚未同步而返回空结果隔了两步再调用同一个接口返回值却是完整的。数学题的中间步骤不会因为“外部时间流”而改变真假工具调用却完全依赖外部系统的即时状态。PRM 在这样的时候毫无还手之力因为它看到的只是“调用了接口、返回了空”这样的 token 序列它没有能力知道换成当前时间点再调用一次就能成功。这种开放动作空间带来的直接后果是Agent 工具调用的“过程质量”必须包含时序和上下文维度而这两样东西都不在数学 PRM 的视野里。3.2 中间状态从“纸面推导”变成“运行环境事实”数学推理里中间状态就是草稿纸上的表达式它不改变环境。Agent 调用工具则不同每一次调用都可能产生真实世界中的副作用。查询数据可能落库、发送消息可能真的触达用户、修改配置会影响后续所有步骤。这些行为无法脱离环境单独评价。我在某个跨平台数据同步项目里遇到过一种情况Agent 先调了“创建资源”接口再调“写入配置”接口最后调“发布上线”。整个过程看起来非常自然如果把轨迹丢给数学 PRM它大概率会给一个不错的过程分。但真实情况是“创建资源”接口因为权限校验失败返回了 403Agent 完全没有看返回体就直接继续往下执行最后发布上线虽然成功但是基于一个残缺资源发布的整个结果是脏的。数学 PRM 看不到这种环境状态错位因为它的训练数据里没有“工具调用之后的外部事实”。它以为过程推进得行云流水就是好但在 Agent 场景里真正的关键是每一步调用之后外部世界的状态是否符合预期而不是调用本身看起来流不流畅。3.3 正确路径从“唯一终点”变成“多解可达空间”数学题通常有唯一标准答案所以过程分数可以以终局为导向来分配良好的单步推演会被奖励偏离主线的步骤则被惩罚。Agent 工具调用不一样完成同一个目标的方式可能有几十种而且很多路径之间没有哪条是绝对“错误”的。我举一个很典型的例子让 Agent 帮用户查“本周某商品在所有平台上的最低价”。有的 Agent 会先把各平台的价格接口全部调一遍再统一比价还有的会先用第一个接口试探返回的数据结构灵活调整之后再批量查询。两条路径都能完成任务但过程完全不同。数学 PRM 更倾向于给那种看起来“线性收敛”的轨迹高分对于先尝试再调整的策略它会误以为前面几步是在绕路然后给低分。问题的根源是数学题里“过程好”是“结果好”的充分条件但 Agent 工具调用场景里结果好坏和过程好坏是相互独立的两个维度只有结合最终任务达成度和执行路径成本才能判断一次调用序列到底算不算合理。过程奖励模型的单一步骤质量视角在这里会严重失真。4. 三个真实翻车场景PRM 和人工评判完全错位4.1 把“试错”当扣分项把“有效探索”当噪声Agent 在真实环境里几乎必然遇到试错。调用 A 接口失败读取错误信息换 B 接口成功这种模式在工具调用场景里是高效的甚至是唯一可行的策略。因为很多外部服务的返回值无法预先判断只有真调一次才知道。但数学 PRM 看到失败步骤的反应完全不同。它的训练数据里包含失败步骤的推理路径通常是低质量的于是它会毫不犹豫地把那次失败的调用标为低分。人工评审则会认为Agent 从失败里提取了关键信息并据此成功切换策略整段过程应该给高分。我记得有一轮人工和 PRM 交叉评审的记录有一个任务Agent 一共调了四次接口前三次都因为目标站点接口升级而返回格式错误最后一次换了一个兼容接口成功拿到数据。PRM 给出的过程分近乎最低理由很可能是“前面几步大量重复且未前进”人工给出的分数却很高理由是“Agent 展示了异常的鲁棒性在未知变更下用最短路径定位到可用接口”。这种认知错位在工具调用评测里几乎每轮都会出现。4.2 无法区分“低效执行”和“合理试探”有另一类场景更加典型Agent 面临一个未知的目标服务它的行为是先并行调用了三个不同来源的接口然后从返回值中挑出可用的部分完成拼接。这种做法在工程上是极其常见的容错策略。PRM 却会把前两个接口的调用标记为多余步骤因为它看到的是两个中间步骤“没有直接产生最终答案”它不知道这些中间递归是必要的。我在自己的内部评测里试过对这个现象做统计结果让我印象很深在工具调用任务的评估集里PRM 给出的低分步骤里有大约四成被人工标注为“有价值的探索性行为”。换句话讲PRM 不是在给过程质量打分它是在给“动作是否立刻导向最终结果”打分。它学到的数学题的线性推进模式在 Agent 场景里反而成了一种偏见。4.3 只看动作文本完全屏蔽环境反馈还有一类翻车是最致命的Agent 调用了一个接口语法完全正确参数填得也很规范甚至接口文档都是按预期来的结果返回了一个业务层面的错误比如“余额不足”或“无操作权限”。这类问题的语义完全寄托在环境反馈里从动作序列的字面上根本看不出来。数学 PRM 面对这种情况会非常自信地给出一个偏高的过程分因为从 token 层面看这分明是一个结构完美的工具调用。可实际效果是这一步调用没有产生任何有效价值甚至因为没能及时处理错误让后续步骤也连带着崩掉。我在评测里经常看到这种分数和效果严重分离的样本。这也让我彻底意识到单纯拿“看起来像不像推理”来做评分在工具调用评测里是没有意义的因为它缺少最关键的信号来源工具返回的环境事实。5. 用一份专项测试验证数学 PRM 跨界的极限5.1 测试是怎么设计的为了不让自己对 PRM 的批判停留在凭感觉我专门设计了一次内部专项测试。评测集分两组一组是 30 个数学应用题另一组是 30 个工具调用任务所有任务都人工录制了完整的多步执行轨迹并由两位同事独立打分后合并成最终标签。工具调用组覆盖了几类典型场景多接口聚合查询、异常重试、参数修正后重新提交、跨服务数据流转。每一轮执行轨迹都保留完整调用链和返回结果。然后我用同一个数学 PRM 对两组任务分别做过程评分再把它的分数和人工标签做一致性对比。5.2 结果差距不是一个量级数据很直观。数学应用题组里PRM 和人工评分的一致性在 0.85 左右错误步骤的定位也能做到七成以上和人工标注重合。工具调用组里一致性直接掉到 0.5 上下浮动接近随机水平。更让人头疼的是PRM 完全无法稳定识别哪一步是关键失误常常把一个“成功重试后的成功步骤”标成低分而把“形式正确但业务上失败的高风险调用”标成高分。这个对比让我彻底丢掉幻想PRM 的能力边界是由它的训练环境定义的。同样是多步决策数学推理和工具调用在底层状态、反馈来源和成功判据上完全不同跨领域直接迁移必然失配。评测维度数学应用题组工具调用任务组评分一致性约 0.85约 0.5错误步骤定位七成以上重合无法稳定定位对探索性步骤的容忍度低线性推进优先低误伤严重对环境反馈的感知不依赖也不存在完全缺失对多路径优劣的判断单路最优会惩罚合理试错可解释性分数能对应到具体步骤分数和效果常常脱节5.3 从测试里看出的三个“隐藏错位”第一难度评价错位。数学 PRM 会认为很多简单的机械调用“过于简单”给低分而人工觉得这种按部就班的操作恰恰是最稳妥的。第二风险感知错位。它只会看这一步 token 有没有异常模式完全不知道某些步骤涉及修改线上数据风险权重远高于查询。第三路径选择错位。它总想找到一条所谓的最优单链而 Agent 场景的多步任务最优路径往往是带分支、带重试、带条件跳转的。如果只是拿它来做排序比如给一堆 Agent 的运行轨迹排高下它的结果会让大部分认真设计了容错逻辑的 Agent 被错杀。如果拿它的分数去训练一个下游决策模块那引入的噪声会直接污染整个策略。6. 如果真想评估 Agent 工具调用应该往这个方向设计6.1 把“过程评估”和“结果评估”彻底拆开我在踩完坑之后重构评测方案的第一件事就是把两个目标分开。最终任务完成度、任务结果质量、对真实世界的影响这些属于结果评估优先级最高信号来源于环境日志。过程评估则只负责回答一个问题给定最终结果Agent 的执行路径是否高效、是否合理、是否有异常风险。两者不能混在一个模型里更不能用一个数学 PRM 全权代理。结果评估应该用硬性检查逻辑任务是否成功、返回值是否符合预期、数据是否一致、副作用是否符合约束。过程评估则依赖于对动作序列的分析但需要把环境返回结果一并纳入而不是只对着动作文本猜。6.2 奖励信号优先从环境里取而不是从模型里猜这句话是我最想强调的干货。Agent 工具调用评测和数学推理评测最大的不同在于我们拥有失败与否、返回是否有效的真实可观测量。评价一次工具调用到底好不好完全可以看返回值调用成功且返回内容被正确使用了这是好信号调用成功但返回内容被忽略这是差信号调用失败后正确切换策略这也是好信号。把这些来自执行环境的结果性信号作为主要判据远比让模型对着 token 猜靠谱得多。我在评测 Agent 时会为每一步动作建立一张标注表包含动作类型、参数合法性、返回状态、返回内容消耗方式、是否引发副作用、是否需要重试。这张表才是过程质量计算的原料而不是模型生成的隐藏状态。信号来源可见范围可靠性数学 PRM 是否利用工具返回状态环境高否返回内容是否被消费上下文高否完成目标的程度环境最高否步骤的文本流畅度模型视角中低是局部推理一致性模型视角中是6.3 如果一定要过程分那就训练一个“Agent 专用 PRM”有些评测场景确实需要过程分比如要对 Agent 的长期表现进行增量式监控或者要给强化学习提供密集奖励。这种需求我不反对但要造一个 Agent 领域的 PRM而不是把数学 PRM 搬过来。怎么造核心是让模型看见环境状态。训练样本里的每一步输入不应该只包含 Agent 的推理文本和动作文本还应该包含工具返回结果、状态变化摘要和任务完成标志。目标标签也不是单纯的人类主观分而应该是“基于结果信号折算的过程分”比如调用失败后是否有效恢复、是否选择最优工具、是否节省了不必要的调用次数。训练数据要多路径采样。同一个任务刻意保留一条直线路径、一条带试错路径、一条带并行探索路径让模型学会区分“计划性探索”和“盲目乱试”。我见过不少团队自己训练 Agent 评估器最容易犯的错误就是只用最优路径做正样本、错误路径做负样本导致模型学会的标准过于苛刻把合理的多样性策略全杀掉。6.4 现实团队最该采用的“半自动评估”组合方案如果你没有足够的人力去收集多路径训练数据也没有时间训练专用 PRM我给一个可落地的折中方案。先用规则校验器跑所有执行轨迹参数格式对不对、有没有调用未授权工具、有没有重复调用同一接口、有没有在失败后长时间无恢复动作。这些规则不需要模型就能发现大量问题。然后把规则筛选后仍然模糊的样本交给人工抽评少部分再辅助大模型做标记。这种做法核心思路是能用确定性逻辑判定的绝不用模型猜模型只处理规则覆盖不到的长尾情况。我用这套组合方案重新跑之前那 30 个工具调用任务评估效率和人工一致性都比直接用数学 PRM 高了一个档次。评测不是越智能越好匹配场景的确定性检查往往就是最优解。7. 最后掏心窝子的话现在回过头看这次翻车给我最大的教训就是做 Agent 评估的难点根本不在“推理过程有多严谨”而在“能不能感知环境并追踪结果”。数学题 PRM 是个成熟的工具但它的成熟是被封闭规则世界塑造出来的把这个工具直接塞进开放交互场景就像让只会闭卷答题的人去当现场调研员——理论功底再好也会被真实世界的混乱反馈击穿。我后来在多个 Agent 项目里验证过凡是把环境反馈信号纳入评估体系的做法无论用规则还是用轻量模型表现都远好于依赖纯文本过程打分的方案。如果你现在也准备给 Agent 工具调用做评测我的建议只有一条先别急着找现成的 PRM先把执行日志、返回结果和任务完成度这些真实信号接好再考虑要不要上过程模型。这一步搞定了评测框架的基本盘就稳了至于过程打分那是后面细化的事情不是整个方案的起点。