多步任务的奖励应该给谁：终局反馈、调用成本与失败恢复

先让最后一分对应完整的任务定义#

定义终局成功不能只看“最后选中了苏州”。还要核对是否查询了正确商品、是否遵循仓库顺序、是否根据返回值判断，以及是否虚构了预订。

这里令完整满足规则的轨迹得 1 分，其余得 0 分。杭州 2 件、苏州 5 件时，查杭州、查苏州、如实回答是一条成功轨迹。没查就猜苏州，即便碰巧与库存相符，也不满足本例要求。

请区分两件事：检查器可以在结束时读取完整日志，只发一个终局分；这不代表它只检查最后一句话。奖励在什么时候出现，与奖励检查了哪些证据，是两个问题。

部署要求也不应全部寄托在分数上。比如本例只开放查询工具，执行器本身不提供预订能力。把禁止操作设为一个负分，并不能保证训练过程或实际使用时永远不会尝试它。

同一个终局奖励，可以影响前面的动作#

先不加入调用成本。三个模型决策分别是查询杭州、查询苏州、最终回答。对应即时奖励是 0、0、1。

令 r_t 表示第 t 个动作之后得到的奖励，T 是最后一个动作的编号。从某一步开始，向后累计的回报为：

γ 是折扣因子。先设 γ=1，三步的回报就都是 1。意思是：从这三步中的任一步继续走，最终都获得了这次成功奖励。它不表示三步贡献完全相同，更不表示三步都得到一份独立成功事实。

在不折扣、有限回合的基础策略梯度里，可以用各步的未来回报来加权其动作的对数概率梯度。过去已经发生的奖励不必作为后来动作的权重。这个 reward-to-go 形式的推导可见 Spinning Up 策略优化说明。

如果再减去该历史下的价值估计，就得到一种用于衡量“比预期好多少”的信号：

假设三处价值估计分别为 0.6、0.7、0.9，优势便是 0.4、0.3、0.1。这些值是教学构造，说明同一个结果可以相对不同预期产生不同信号，不是对每一步真实因果贡献的测量。

失败轨迹也一样。最后得到零分，不代表此前每个动作单独都是错误。随机反馈、后续决策以及价值估计都会影响一次更新；要靠多次采样下的统计关系学习，而不是把单条轨迹的分数当成逐步判决书。

给工具调用收费，其实是在修改目标#

实际任务里，调用太多可能增加延迟或费用。我们可以定义每次工具调用扣 0.05 分，最终成功加 1 分；最终回答不另收工具费。两次查询后成功的即时奖励变成 -0.05、-0.05、1，γ=1 时：

早期动作承担更多尚未发生的成本，所以回报不同。已经花掉的第一次调用成本，不需要再次归给最终回答。

但加成本不是纯粹让学习更稳定。它把优化目标改成“成功收益减去调用代价”。考虑两种人为设定的策略：A 总能完成任务，平均调用 2 次；B 的成功概率是 0.9，平均调用 1 次。每次成本为 c 时：

c=0.05 时，A 得 0.90，B 得 0.85；c=0.20 时，A 得 0.60，B 得 0.70。优化器此时偏好 B，并不是它“不懂任务”，而是这个目标允许用一些成功率换取更少调用。

B 的 0.9 是假设存在某种任务分布下的性能，不是说当前杭州不足的固定实例能合法省去苏州查询。这个对照只用于解释目标权衡。

如果业务要求首先满足一个成功率下限，再减少成本，就应明确这一约束或分层比较标准。一个随手设置的成本系数，不能自动表达“成功永远优先”。

折扣也会偏向更早的结果#

仍看两次查询后成功的轨迹，如果 γ=0.9，从第一次决策看过去的折扣回报是：

若只查一次就成功，则相应回报为 -0.05+0.9=0.85。这两个轨迹未必来自同一道任务，所以不能仅凭这两个数评价某个模型；它们说明了折扣如何影响时序权重。

需要特别写清楚这里的“一步”。本文一步是一次模型决策，不是一个 token，也不是一秒。把同一个 γ 改为每 token 应用，长回答就会受到另一种惩罚。若想控制真实延迟，直接记录耗时通常比把交互步数当秒数更清楚。

回合最大步数也需要单独定义。到达预算后被截断，与模型正常完成任务不同；不能删掉超时样本后再报告成功率。价值估计在截断点是否继续估计未来，取决于你把预算上限视为任务终止，还是采样边界。

每个合法调用都加分，可能鼓励重复查询#

一种看似友好的过程奖励是：“只要参数格式合法，就加 0.1 分。”这能提供更密集的反馈，却也可能让模型反复发出没有新信息的合法查询。

假设同时每次调用扣 0.05 分，重复一次合法查询的净增益仍是 0.05。十次重复查询即使没有完成任务，也能累积 0.5 分。设置最大步数只能限制漏洞规模，不会让这个奖励突然对齐用户目标。

因此，过程奖励要先问清楚在奖励什么：是格式、获得新证据、遵守必要顺序，还是推进了任务？格式正确可以作为诊断指标，并不一定必须兑换成训练收益。

还有一种更隐蔽的风险：过程评分要求模型每次写一段“我已经认真检查”的说明，却没有核对工具结果。模型可能学会写出评分器喜欢的自述，而不是执行更好的操作。评价执行过程，优先使用调用和环境记录，不要仅凭模型声称自己做了什么。

势函数奖励为什么需要边界条件#

奖励塑形研究里，一个重要思路是让额外奖励等于某种“进度值”的差，而不是每走一步就无条件加分。Ng、Harada 与 Russell 的论文分析了在一定 MDP 条件下，哪些奖励变换能保持最优策略不变。原论文

在本文有限回合里，我们只推导一个可直接复核的代数结论。给每个状态一个固定势函数 Φ，并定义：

将这些额外奖励按相同 γ 折扣求和，中间项相消，得到：

若所有终止状态的势都设为零，那么对同一起点，额外总回报都是同一个常数 -Φ(s_0)。在固定起点分布、相同折扣和完整终止处理下，它不会改变不同策略的期望回报排序。

例如 γ=1，某条三步轨迹的势依次为 0、0.2、0.6、0，额外奖励就是 0.2、0.4、-0.6，总和为零。前面获得进度反馈，结束时仍需结清边界项。若忘掉最后的 -0.6，就不再是同一种变换。

这不是说随便训练一个“进度打分模型”就能保证安全塑形。若势随训练变化、终止处理不一致，或实际加分不是上述差分，刚才的推导就不足以提供保证。对于部分可观察的工具环境，还要说明用什么状态或历史表示。本文的代数检查更不能保证某个神经网络训练过程会更快收敛。

工具超时以后，奖励该怎样处理#

现在扩展环境：合法查询可能返回 timeout。原来“每次查询必定成功返回库存”的设定不再成立。任务规则需要补上是否允许重试、最多几次、如何报告未查明状态。

若工具故障属于部署中确实存在的风险，可以把恢复能力纳入任务。例如允许一次重试；两次都超时后，应报告未能查明，而不是把未知当作零库存。

此时最好同时记录“是否查明库存”和“是否正确处理失败”。如实报告无法完成，可以满足故障处理要求，但不等于获得了库存答案。把两者都叫成功，会掩盖系统可用性问题。

如果故障来自评测设施自身损坏，而不是定义好的环境随机性，应按预先约定标记无效测量、报告数量并修复复测。不能只在模型表现差时把故障样本排除，也不能把所有外部故障都解释为模型能力不足。

重试还可能制造捷径。若每次独立成功概率是假设的 0.8，最多尝试两次，则至少一次成功的概率为 0.96，预期调用次数为 1.2。比单次更容易成功，原因首先是允许了更多尝试，不足以证明模型学会了更好的决策。独立假设也很强：服务持续故障时，两次失败往往相关。

先看奖励分项，再决定怎样训练#

一份可复查日志应分别保留终局任务结果、调用次数、工具故障、超时、违规行为与过程分，再由版本固定的规则合成训练奖励。这样才能发现“总分上涨，却越来越不愿意完成难题”之类的变化。

一个待运行的对照可以比较：只给终局奖励、加入调用成本、加入经验证的过程塑形。保持任务分布、预算、起始模型和评测器一致，同时报告独立任务完成率与实际成本。新增奖励往往也改变分数尺度，直接比较训练奖励曲线没有充分意义。

本文实际复算了回报、成本阈值、折扣、重复调用漏洞、势函数相消和两次重试的概率。它们是奖励设计的反例与算例，没有证明某种训练算法在库存任务上有效。

要回答“奖励应该给谁”，先回答三个更具体的问题：最后的分数代表什么，前面的动作如何影响未来结果，额外加分有没有偷偷改变任务。把这三点写清楚，再讨论 PPO、GRPO 或其他更新方法，才能知道模型究竟在优化什么。