数学PRM为何不适合Agent工具调用？过程监督的边界与务实评估方案

最近在给某智能体项目做训练和评估时，我踩了一个特别典型的坑：团队里有人提议，把数学推理场景里训练 Process Reward Model（PRM，过程奖励模型）那套方法直接搬过来，给 Agent 每一步的工具调用打分。理由听着很充分——“这不都是过程的中间状态吗？先判断每一步对不对，最后再汇总，总比只看最后结果要强吧。”方案听着合理，但我们实际跑了两轮实验，效果一塌糊涂。我只能说：拿着做数学题的 PRM 来评判 Agent 调用工具，基本是行不通的。

这篇文章不是要全盘否定过程监督，而是想把我拆过的数据、踩过的坑、以及最后换用的评估方案都摊开讲一遍。如果你也在做 Agent 的训练、评测，或者正准备给工具调用环节引入“过程奖励”，这篇文章应该能帮你省下不少冤枉时间。

1. 数学题里的 PRM 到底强在哪：它吃透了三样看不见的前提

1.1 先分清 PRM 和 ORM，再讨论它为什么“能打”

在讨论“为什么不能搬”之前，得先把 PRM 的本体逻辑聊清楚。PRM 是 Process Reward Model，过程奖励模型，和 ORM（Outcome Reward Model，结果奖励模型）相对。ORM 只看最终答案对不对：对就给 +1，不对就给 -1，简单粗暴。而 PRM 要做的事是给解题过程中的每一步中间推理打分——好比老师批改一道几何证明题，“设 x = ...，根据已知条件可得...”这一步值多少分，“由勾股定理可得...”这一步又值多少分，模型得像批改作业一样逐行评判。

在数学推理场景里，PRM 之所以能训练出来，核心在标注数据可以自动化生成。常用的方法叫蒙特卡洛估计：拿到当前这一步，往后随机采样几十上百条完整推理链，统计其中有多少条最终能走到正确答案，这个比例就当作当前这一步的过程分数。这个过程能跑通，不是因为它有多聪明，而是因为数学题恰好满足了一些非常苛刻的前提条件。当时我也觉得这套东西“很成熟”，直到把它套到工具调用上才发现，所谓成熟，是有前提的成熟。

1.2 三个前提条件，一个都不能少

第一个前提是存在外部可验证的最终答案。数学题有确定性答案，用脚本一比对就能判定对错。这个信号客观、廉价、可以无限量产生，所以能批量制造训练数据。有了这个“锚”，蒙特卡洛采样才有一个衡量标准：走了一半，后面怎么采样，最后到底对不对，锚是清楚的。

第二个前提是推理路径可分解成语义明确的中间步骤。数学题的正确解法虽然路径多样，但每一条路径都能拆成若干逻辑严密的步骤，比如“移项”“合并同类项”“代入公式”。这些步骤的边界清楚，语义独立，打分模型能从标注数据里学到“这一步对在哪儿、错在哪儿”的因果。

第三个前提是步骤质量与最终结果之间有强相关性。在数学里，如果中间某一步是错的，后面大概率推不出正确答案；如果某一步是对的，后面到达正确答案的概率也理应更大。PRM 学的正是这种相关性，而且这种相关性在数学领域是稳定、可迁移的。

这三样是我后来才真正看明白的关键。因为所有试图把数学 PRM 移植到 Agent 工具调用上的方案，默认这三条仍然成立。但实际情况是，工具调用场景里这三条几乎全都塌掉了。

2. 工具调用和数学推理的结构性差异：过程监督遇上了开放战场

2.1 状态空间的性质完全不同

数学推理本质上是在一个“相对封闭”的语义空间里推进。给定题目条件和前文步骤，下一个合法步骤是什么，范围是有限的，而且每一步的“对错”基本由逻辑关系决定，不依赖外部世界。但 Agent 的工具调用面对的是开放环境：一个搜索接口返回什么内容，受实时数据库影响；一个代码执行器的结果，受运行环境、依赖版本、网络状况影响；甚至同一个工具、同一个输入，先后两次调用都可能返回不同的结果。

这带来一个致命的判断差异：在数学题里，一步推理的“过程分”在产出那一刻就已经基本确定了——逻辑上对不对，看上下文就够了。但在工具调用里，一次调用的“对错”在发出请求那一刻根本没法下结论。搜索调用发出后，你得等返回结果，再看结果和任务目标的关系，才能说这步好不好。也就是说，工具调用的过程分不是“事前可预测”的，而是“事后归因”的。硬要用 PRM 那种“依据前文预测当前步质量”的思路，等于在工具返回之前就替环境写了剧本。

我把这个差距拉一张表，你一眼就能看懂：

这张表里最扎眼的其实是最后一行。PRM 在数学上有用，靠的就是步骤和结果之间的强因果。一旦因果变弱，过程分的可靠性就断崖式下跌，这个是再怎么调模型都补不回来的。

2.2 步骤语义的粒度和类型层级完全不同

数学题的“步骤”是高度同质的：基本都是一段推理文本，模型可以把它们当作同一类对象来打分。但 Agent 的轨迹里，“步骤”可以是一句规划思考、一次工具调用、一段工具返回的观察、一次异常重试、一次最终回复。这些步骤的语义天差地别，而且对不同任务的重要程度也不一样。

搜索一条信息的时候，真正有用的可能只有一次查询和一次点击；前面那些“规划思考”如果模型非要给个分，团队里两个标注员都很难达成一致。有人觉得“思考得越长越谨慎，应该加分”，有人觉得“废话太多，直接调工具更快”。这种主观性直接决定了：就算你组织一批人标注过程分数，标注一致性也会低到没法用。而标注一致性恰恰是训练 PRM 的基本盘——数学题标注员之间可以轻松达成一致“这一步错了”，Agent 轨迹里连“这一步算不算有用”都吵不清楚。

这还没算动作类型带来的落差。有些 Agent 轨迹里，一次失败的重试可能是完全合理且必要的（比如第一次调用超时，第二次换备用接口成功）；但在局部看，第一次失败明明就是“工具报错”，PRM 很可能给它一个低分，然后因为低分去惩罚一个实际上非常正确的行为。这就是把不同粒度的步骤放在一个评分器下，必然出现的误伤。

2.3 标签自动化的条件彻底崩塌

数学 PRM 最诱人的地方就是标注便宜：只要有一批数学题和答案，蒙特卡洛采样就能造出过程标注，成本几乎可以忽略。但工具调用场景里，这个自动化管线每一步都有问题。

首先是结果信号稀疏。一个多步 Agent 任务，通常只有在最后一步才能判断成不成功，中间几十次调用都没有天然的“对错”信号。其次是轨迹长度差异大，一个简单任务可能只调两三次工具，复杂任务可能调二十几次，甚至中途需求还会变。这时候你用蒙特卡洛从某一步往后采样，会发现大量轨迹失败的原因是“任务本身太难”“工具本身不稳定”“环境状态变了”，而不是“当前这一步过得不好”。信噪比太低，噪声塞满，学出来的 PRM 基本就是在拟合环境随机性。

我见过有人想补救：把工具返回的内容截断、清洗、嵌入向量，作为步骤打分模型的特征。但问题在于，这个动作本身又引入了大量的特征工程偏差。你一旦开始手动定义“什么是好的工具返回”，本质上就回到了规则判断，这跟 PRM 想学的“通用过程奖励”已经不是一个东西了。

3. 强行套用的三个典型失败场景：都是我们实测过的

3.1 同一个工具调用，换个上下文评分就“翻脸”

我们最早想验证 PRM 的可行性，做了一个很小的测试：用微软开源的某数学过程奖励模型，直接对 Agent 轨迹步骤做打分，看分数和人工判断是否吻合。挑了几个特别简单的“搜索资料”轨迹出来，结果当场就发现问题。

有个任务目标是“查某个公开人物的出生年份”，Agent 第一次搜索返回了正确信息，过程模型给了 0.85 的高分；第二次同样是一次搜索，查询词也规范，但返回结果是已经变更后的旧页面数据，过程模型还是给了 0.82 的高分。从查询词这个局部特征看，两次调用确实“长得一模一样”，但第二次的调用其实对整个任务没有任何贡献——信息已经拿到了，再搜一次属于多余动作，而且拿到的还是脏数据。

这说明什么问题？工具调用的质量高度依赖上下文和结果反馈，它不是一个“局部可判”的孤立事件。而 PRM 的设计假设恰恰是“每一步都有一个与上下文解耦的内在质量”，这个假设在数学里成立，在工具调用里不成立。同一个动作，在序列中的位置不同、结果不同、任务需求不同，“对错”可以完全相反。你让模型怎么学？打个不恰当的比方，这就像要求一个裁判只看起跑姿势就能判定整场比赛谁赢，完全不管中途天气变了、对手摔了、赛道出问题了。

3.2 早期的“正确动作”可能把任务带进死胡同

第二个失败场景更隐蔽，也更致命。有一次我们测试的是“根据用户给出的需求，整理一份可执行的环境配置步骤”这类任务。Agent 的第一步先调用了一个代码仓库搜索工具，来回搜索依赖版本信息。从每一步单独看，这些搜索调用都“挺合理的”，查询词清晰、工具返回正常、没有异常行为。PRM 给每一步的分都很高。

但是整个任务最后失败了，原因恰恰是最开始那次搜索拿到的依赖版本列表是旧的，Agent 沿着这个错误前提往下规划，后面所有步骤都建立在错误的地基上。等它发现不对劲的时候已经绕了很远，最终给的配置命令根本无法运行。在数学题里，“从错误的前提出发”通常很快就能被后续逻辑暴露出来，因为步骤之间有强制推导约束。但在 Agent 里，一个看起来正常的工具调用可能返回错误信息，而错误信息在短期内不会暴露，Agent 还会顺着错误继续走好几步。

这就是过程监督在 agent 场景里最尴尬的地方：**它只能看到动作表面是否规范，看不到动作背后的信息是否可靠。**而工具调用场景里，偏偏是信息的可靠性决定成败。你扣一百次“步骤规范分”，都不如最后结果里那个 404 报错来得有说服力。我们后来统计过这种“前期合理但信息错误导致整体失败”的轨迹，占比不低。在这种数据分布下，PRM 给的分数跟最终成败的相关性，甚至不如直接拿轨迹长度当特征来预测。

3.3 把“过程分”当成“结果分”来扣，等于惩罚正确行为

第三个场景是关于动作冗余的。工具调用场景里，“多做”不一定是好事。我们有一条基线轨迹只用了 3 次工具调用就完成了任务，而 PRM 对后发现，凡是调用次数多的轨迹，过程分普遍更高——因为每一步都孤零零地看，每一步都“有理由、有动作、有结果”。但站在任务效率的角度，这完全是浪费。

后来我们试着对过程分做了个简单修正：如果工具已经返回了足够信息，Agent 再重复调用同类工具，就把这步判定为“冗余”，减去 0.5 分。结果模型训练出来之后，Agent 反而变得“畏首畏尾”，很多本来该用工具验证一下的信息（比如数值计算、时间核对）它也懒得调了。原因很简单：模型的“冗余”定义和实际任务需要不一致，它没法判断什么时候该保守、什么时候该果断。

这件事让我彻底想明白了：**数学 PRM 的评分是围绕着“推理正确性”展开的，而 Agent 工具调用的评分必须围绕“任务达成效率”展开。**这是两个完全不同的目标函数。前者可以用局部逻辑论证来打分，后者本质上是全局决策质量和环境互动的综合结果。目标函数都换了，方法怎么可能直接搬运？

4. 那 Agent 工具调用的评估到底该怎么做：我现在的务实方案

4.1 先问清楚：你的评估信号到底从哪来

踩完这些坑之后，我对 Agent 评估的第一原则变成了：先想清楚信号来源，再决定用哪套方法论。很多时候我们选择 PRM，不是因为它是任务的最佳解，而是因为“自动标注很便宜、看起来很酷”。这在数学里是优势，在工具调用里就是陷阱。

工具调用场景真正可靠的信号源只有几类：一是任务本身有可判定的成功标准，比如“代码运行通过”“搜索结果包含目标实体”“生成的配置可以执行”；二是工具返回中自带的校验信号，比如 API 返回码、编译错误、测试用例通过情况；三是用户或人工的最终评价。这三类没有一个是天然“每步都有”的，大部分任务只在最后给你一个稀疏信号。接受这个现实，比硬造一个密集信号要重要得多。

4.2 结果信号为主、过程信号为辅的组合评估

我目前给团队定的评估框架大致是这样的：对每个任务，先收集一组明确可量化的结果指标，再用少量过程指标做诊断，但绝不把过程指标当成训练奖励。结果指标里包括任务成功率、单任务工具调用次数、工具调用有效率（有效结果调用占比）、任务完成时长等；过程指标里包括异常重试率、无效查询占比、退出路径占比等。这些过程指标只用来定位问题，不进训练目标。

如果一定要在训练里给 Agent 提供密集信号，我建议用“启发式规则”而不是“学习出来的 PRM”。比如：工具返回非空且状态码正常，给一个小的正向偏置；连续两次重复同样的错误查询，给一个负向偏置；工具明确报错后重试一次以上，不给惩罚。这些规则的共同点是：每个信号都是基于环境反馈的确定事实，不需要模型“脑补”这一步的隐藏质量，所以不会出现“评分翻脸”的问题。

提示：把训练信号和安全相关的奖励分开算。比如工具调用是否越权、是否访问敏感资源，这类信号可以直接用规则强判断，没必要让通用奖励模型背这个锅。

4.3 数学 PRM 有没有可以借鉴的部分？有，但要改到认不出来

我不是说过程监督这条路完全没有价值。在两类场景里，它依然值得尝试。第一类是代码生成类任务，因为有单元测试，天然存在“中间步骤可验证”的条件——跑过哪几个测试、卡在哪个用例，这些都能提供细粒度的确定性信号。第二类是模拟器环境中自带稠密反馈的任务，比如游戏、机器人控制，环境本身就是信号源。

但这两个场景和数学 PRM 都有本质区别：它们的“步骤质量”仍然由环境反馈直接定义，而不是由一个学习出来的模型去预测。换句话说，真正有用的不是 PRM 这个模型，而是“基于客观信号的步骤级奖励”这个理念。如果哪天有人跟你说“我要给 Agent 搞一个通用 PRM”，你可以先问他：这个模型的训练标注是从哪来的？如果答案是“从结果信号里采样估计出来的”，那就要警惕了——这大概率是在复制我们在数学里用过的那套蒙特卡洛流程，而这套流程在 Agent 场景里的信噪比，我们上面已经验证过了，基本是行不通的。

4.4 实操里我还踩过的一个小坑，顺带提醒你

即便用了规则奖励，也还有一道坎：工具调用特征实在太碎了，规则写得不好很容易误伤。比如我们把“搜索返回结果为空”设成负向信号，但有些任务里空结果本身就是有效信号——查询一个冷门术语，返回空说明确实没有对应条目，Agent 可以据此下结论，这时候空结果不该被扣分。所以规则奖励一定要配合“任务类型”的条件分支，别指望一套规则走天下。

另外还有一个工程细节：评估和训练要分开跑。我们的做法是训练时用“结果奖励 + 规则奖励”组合，评测时只跑结果指标。否则规则信号的噪声和偏差会渗透到你看不见的角落，最后你可能花了一个月在调一个连自己都不理解的诡异行为——这种事我经历过一次，体验极其糟糕。

5. 写在最后：踩坑之后我的判断

拿数学题的 PRM 评判 Agent 工具调用，我的结论就一句话：**领域的因果结构变了，方法的根基就没了。**数学题的过程监督是建立在可验证终点、强逻辑约束和同质步骤之上的，而 Agent 的工具调用面对的是一堆充满随机性的开放式交互，三者一个都不具备。强行移植，结果不是评分的噪声大，而是你会把噪声当成信号去优化，最后训练出一个看起来在认真调用工具、实际上完全不会做任务的 Agent。

我现在更愿意把时间花在“定义清楚什么算成功”和“设计客观的稀疏反馈”上。工具调用的核心是“用最少、最准的动作完成任务目标”，这个目标本身就是最好的评估标准。复杂的东西不一定更有效，至少在 Agent 评估这件事上，回归朴素让我少踩了至少一半的坑。如果你正卡在类似的方案选择上，希望这篇能帮你早一步看清问题。