Agent 工具调用奖励设计

这道题问的是奖励函数设计，但我觉得本质是在问一个更根本的问题：你怎么让[[Agent]]真正理解你想让它干什么。因为奖励函数就是Agent的指挥棒，一旦信号给歪了，Agent就会钻空子，做出看起来分数很高但实际没用的行为。

先说设计原则，核心就是目标对齐。你定的奖励必须直接反映业务目标，而不是一个代理指标。比如你让Agent送外卖，如果只看准时率，它可能为了准时疯狂拒单，或者把单都甩给别人，那系统整体就崩了。所以奖励要能引导Agent做正确的事。

还有一个关键点是信号密度。奖励分两种，稀疏和稠密。稀疏奖励就是只有最后成功才给分，比如下棋赢了才得1分，中间什么反馈都没有。这样Agent探索起来非常困难，收敛很慢。稠密奖励是每一步都给反馈，比如走一步棋根据局面好坏给点小分，这样学得快。但稠密奖励设计起来复杂，而且容易让Agent沉迷于刷局部小分，偏离最终目标。所以真正落地时，我一般会混合使用：主体是稀疏奖励，确保大方向正确，中间加一些稠密的小奖励来引导探索。

具体到方法，手工设计是最常用的，适合规则明确的场景。如果任务复杂到说不清奖励是什么，那可以用逆强化学习从专家轨迹里反推，或者用[[RLHF]]从人类反馈里学。

我拿美团外卖的智能调度举个例。骑手路径规划，要同时优化准时率、骑手负载均衡和用户体验。我会这么设计奖励函数：

R = w1准时 + w2负载 + w3用户满意度 + w4成本

准时项：准时送达+1，超时-5。这里动机是对超时要强惩罚，但注意，提前太久送达也要稍微扣分，因为客户可能还没准备好。负载项：骑手当前单量越接近平均值，奖励越高。这是为了避免马太效应，防止单量集中在少数骑手身上。用户满意度项：用预估送达时间的准确度和餐品完好度来近似，因为真实满意度很难实时拿到。成本项：直接就是负的总行驶距离，激励骑手少跑路。