先这样答
Agent RL 的奖励设计通常采用组合策略，根据任务链路长度和可校验程度，将结果奖励、过程奖励与规则奖励配合使用。
结果奖励只关注最终状态，例如测试用例通过、答案正确或任务完成标志。它的优势是客观且不易被模型钻空子，适合结果明确且可校验的场景。但对于步骤多的长链路任务，结果奖励信号过于稀疏，存在信用分配困难的问题，模型很难知道具体哪一步做对了。
过程奖励针对中间步骤打分，比如评估工具选择是否正确、参数是否合理或规划逻辑是否清晰。它能提供密集的反馈信号，加快模型学习速度，适合长链路推理或工具调用任务。过程奖励依赖中间步骤标注或专门的过程奖励模型（PRM），且打分器本身存在被模型 hacking 的风险。
规则奖励是确定性函数，主要评估格式合规、JSON 可解析程度以及是否有越权操作。它最稳定但覆盖面窄，适合作为兜底约束条件。
在实际设计中，通常以结果奖励为主，配合规则罚分来限制越权、超时或死循环。过程奖励多用于冷启动阶段维持训练稳定，例如给正确的工具调用格式发放小额奖励。同时，过程奖励的权重应低于结果奖励，防止模型为了刷过程分而偏离最终目标。在 Agent 场景下，工具调用失败后的合理重试不应直接扣分，可以通过增加效率项来鼓励一次成功。最终的奖励函数必须与真实的业务指标对齐，用户确认解决的权重应高于系统层面的表面完成。
面试官会怎么追问
-
「GRPO 提升 Function Calling 时除结果奖励外如何设计过程奖励？」 可以针对工具调用的中间环节设置阶梯分数。模型正确输出工具名称给基础分，参数符合 JSON 格式给附加分，参数取值合理再给一档分数。这样能在长链路调用中提供密集信号，引导模型逐步掌握工具使用规范。
-
「如果 Agent 调用工具失败并触发了重试，奖励函数应该怎么处理？」 不应对工具调用失败直接进行严厉罚分，因为根据错误信息进行重试是 Agent 的合理行为。可以采用效率惩罚机制，鼓励一次调用成功并给予额外效率奖励，多次重试完成任务只给基础结果分，引导模型减少冗余动作。
-
「怎么防止模型在训练中刷过程奖励的分数？」 需要严格控制过程奖励的权重，使其始终低于结果奖励。同时引入规则罚分进行约束，如果模型输出冗余的中间步骤或陷入死循环，直接触发规则惩罚并终止当前 episode，确保模型行为以达成最终结果为导向。
回答的坑
- 认为过程奖励越多越好。过程打分器本身存在缺陷，过度依赖过程奖励会导致模型学会迎合打分器的漏洞，偏离真实的业务目标。
- 忽视 Agent 场景与传统 RL 的差异。把工具执行报错等同于传统强化学习中的失败并给予负奖励，会破坏 Agent 基于报错信息进行反思和重试的能力。
同系列的题