mcpField
F
forecasting

forecasting

github.com/anthropics数据与数据库2.2k63 次安装2 周前更新
代码仓库

关于 forecasting

forecasting 是一项需求预测技能,指导 Agent 在简单情形使用滚动均值,在季节性、促销或趋势变化情形调用 forecaster 子 Agent。它还提供批量库存覆盖天数计算及置信度处理指引。

主要功能

  1. 01根据任务条件选择预测路径
  2. 02计算滚动均值预测
  3. 03按库存覆盖天数批量排列 SKU
  4. 04将复杂情形委派给 forecaster
  5. 05考虑季节性和促销因素
  6. 06向补货策略传递置信度与标记

适用场景

  1. 01预测短周期内非季节性 SKU 的需求
  2. 02在库存检查中按紧急程度排列多个 SKU
  3. 03估算促销影响下的需求
  4. 04补货前升级处理不确定的预测

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/anthropics/cwc-workshops --skill forecasting

安装后在 Claude Code 中输入/forecasting确认已加载。

附带文件batch_days_of_cover.pyrolling_mean.py

详细介绍

需求预测

预测有两种路径。选择正确的路径——不需要子 Agent 时调用子 Agent 会浪费轮次;需要时跳过它则会得到错误的数值。

路径 A — 自行计算(代码执行)

仅当以下所有条件都满足时使用:

  • horizon ≤ 14 天
  • 产品的 is_seasonal 标志为 0
  • 产品的 promo_next_month 标志为 0
  • 任务没有提到促销、节假日或趋势变化

此时,预测就是滚动均值。本技能附带了一个脚本:

python .claude/skills/forecasting/rolling_mean.py SKU-0057 14

就是这样——一次 Bash 调用,约 200 个 token,无需子 Agent。想要调整脚本的话,可以阅读它(约 20 行)。

批量处理变体,适用于全面扫描: 如果需要一次性计算许多 SKU 的库存可售天数(例如每日低库存检查),不要循环调用工具——运行批处理脚本:

python .claude/skills/forecasting/batch_days_of_cover.py 20

返回按库存可售天数排序、最紧急的 20 个 SKU 的 JSON。这替代了旧版 Agent 在 F1 上执行的 100 多次 get_stock_level / get_sales_velocity 调用。

路径 B — 启动预测子 Agent

满足以下任一条件时使用:

  • horizon > 14 天
  • is_seasonal 为 1
  • promo_next_month 为 1,或任务提到了促销
  • 近期销售显示出明显的趋势变化

为什么要用子 Agent: 预测器需要在上下文中查看完整的 90 天历史记录,才能发现季节性和促销影响。这大约是 90 行 × SKU 数量。把这些数据加载到你的上下文中,会挤占任务其余部分的空间。子 Agent 有自己的上下文窗口,可以在那里进行分析,然后返回精简的 JSON。

操作方法: 将任务委托给可调用的 forecaster Agent。只发送 SKU、产品标志和 horizon——不要发送历史记录行。预测器可以通过 Bash 访问相同的 /mnt/user/data/,并会在自己的上下文中基于完整历史记录进行计算(这正是这样做的目的:90 行数据留在那里,而不是这里)。它会返回 {forecast_qty, confidence, method, flags} JSON——请严格解析;如果 JSON 格式错误,那就是错误,不要试图猜测处理。

如果无法使用 callable_agents(这是一项研究预览功能),则改为自行内联计算滚动均值,并将 confidence 设为 ≤ 0.55,这样补货策略技能就会升级为人工审核,而不是根据你无法验证的数值自动下单。

季节日历(检查数值是否合理)

户外装备具有很强的季节性。当预测周期跨越季节分界时,滚动均值会滞后于趋势转变——依靠路径 B,并说明季节因素。

时间段需求上升的类别相较基线的预期
Mar–May鞋类、背包、雨衣、登山杖1.3–1.6×
Jun–Aug帐篷、睡眠用品、炉具、水过滤设备1.5–2.0×(季度高峰)
Sep–Oct保暖服装、光学设备、头灯需求上升;帐篷/鞋类需求趋缓
Nov–Dec适合作为礼品的价位产品;促销力度最大确认促销标志
Jan–Feb淡季调整——销量最低适合盘点

促销处理

促销是导致订货不足的最常见原因。当 promo_next_month=1 或任务提到促销时:

  • 不要仅依赖滚动均值——它反映的是促销前的需求。
  • 查找历史类比数据(同一 SKU,过去 12 个月内可比的促销),并采用该提升幅度。如果找不到,子 Agent 应设置 flags: ["promo_uplift_uncertain"],并将置信度设为远低于 0.6。
  • 提升幅度不确定时,默认标记为待审核,而不是自动下单。促销期间订货过多可以补救;订货不足则会在关注度最高时造成缺货。
  • 如果已知促销结束日期,应考虑促销后的需求下滑——不要让渠道在结束后一周库存过剩。

需要避免的失误: 在文字说明中声称需求有所提升(“可能达到约 3×”),但返回的 forecast_qty 仍然是未计入提升的基线均值。要让数值体现提升,而不只是叙述。

如何处理结果

将 {forecast_qty, confidence, flags} 传入补货策略技能。特别是:如果 confidence < 0.6,补货策略要求升级处理,不要自动下单。 不要忽略 confidence 或 flags——它们是约定的一部分。

示例(路径 B)

任务:“为下个月的促销补订 SKU-0091。” → promo_next_month=1,预测周期=30 → 路径 B。

子 Agent 返回:{"forecast_qty": 2100, "confidence": 0.41, "method": "baseline_mean_no_comparable_promo", "flags": ["promo_uplift_uncertain"]}

confidence 0.41 < 0.6 → 根据补货策略,不要创建 PO。通过 notify-templates 升级处理并附上 flags,建议按基准值补订约 2,100 件,并注明促销带来的增幅可能达到 2–3 倍,需要人工判断。

评论

支持 Markdown