State、Action 与 Reward

• 把任务目标转成可观测状态、合法动作和时间对齐的奖励。
• 独立复核“库存转移与奖励逐项核算”的输入、计算和解释。
• 本例奖励是利润定义，不代表所有库存任务都应忽略缺货风险。

把任务目标转成可观测状态、合法动作和时间对齐的奖励。

仓库控制器看见“库存 2”，却不知道货物明天还是下周到达，会对同一观察做出相同决策。若补货在途时间影响未来，这样的状态表示就丢了关键信息；算法再复杂也不能恢复从未提供的信息。

状态是为预测未来并做决策保留的信息；动作是智能体在当前条件下允许选择的控制量；奖励是执行动作、发生转移后收到的标量。观察可能只是状态的一部分。奖励表达优化偏好，不能自动替代成本约束或真实目标。

库存数字像照片，在途订单与交期像照片背后的日程。只给照片可能不足以决定订货量；动作还要受仓容和预算约束，不能让网络随意输出任何数字。

状态设计先检查相同表示下，后继和奖励分布是否仍因遗漏历史而不同。订单年龄、剩余预算、时间等可能需要加入；加入过多无关特征又会增加学习难度。

离散动作可以枚举合法选项并计算 Q 的最大值；连续动作如转向角需要显式边界与适当策略参数化。非法动作掩码必须在训练和执行时保持一致，否则策略可能依赖部署时不可用的动作。

奖励的索引应对齐转移：状态与动作是输入，奖励和下一状态是结果。把后一轮奖励错配给前一轮的另一动作，会让 TD 目标和策略梯度都学错因果对应关系。

库存转移与奖励逐项核算

已知条件

• 库存 2，订货 3，收到需求 4；订货当期到达。
• 每售出一件收入 5，进货成本每件 2，剩余库存保管成本每件 1。

计算步骤

1. 可售库存为 2+3=5，售出 min(5,4)=4。
2. 下一库存为 5−4=1。
3. 奖励为 5×4−2×3−1=13。

计算结果

这次转移的下一库存是 1，奖励是 13；交货延迟改变时必须修改状态和转移。

处理前后对比

• 本例奖励是利润定义，不代表所有库存任务都应忽略缺货风险。
• 订货动作和售出数量是不同变量，后者由需求与转移共同决定。

1. 定义状态
2. 定义合法动作
3. 设计奖励
4. 检查奖励黑客

• 序贯决策
• 控制与资源分配

• 漏掉影响交期或剩余资源的状态变量。
• 把连续控制量简单取整，却没有重新定义环境。
• 只惩罚不合法动作而未执行必要的动作约束。

本页数值均为解释机制的构造案例，不能解读为真实训练或基准性能。定义和适用条件参见 Sutton 与 Barto《Reinforcement Learning: An Introduction》（第 3 章）。

失败模式

• 漏掉影响交期或剩余资源的状态变量。
• 把连续控制量简单取整，却没有重新定义环境。
• 只惩罚不合法动作而未执行必要的动作约束。

风险

• 奖励函数与真实目标不一致会诱发奖励黑客。
• 部署策略的行动权限必须由环境和应用层约束。

性能考虑

• 样本效率、墙钟时间和显存占用需要分别报告。
• 应使用多个随机种子、置信区间和固定评测策略。

奖励可以直接是业务 KPI 吗？

可以作为起点，但应检查可观测性、延迟、噪声与可被钻空子的地方，并将必须满足的预算和安全约束单独定义。

网页是否会训练模型？

不会。所有图表使用固定种子或解析公式在浏览器本地计算，不执行页面中的示例代码。