Agent规格说明书 · 第③张 · 共3张 · 最终张
无菜单推单 Agent
Omakase Replenishment Agent
Layer 3.0 · 自主决策
每日推单 · 闭环
这个Agent存在的理由：经销商不应该猜该订多少货。猜测产生的误差，要么是压货（A类失真），要么是断货（消费者体验受损）。 系统直接告诉经销商：你该订什么、订多少、什么时候送到。不需要人猜。
⚠️ 关键前提：这是三个Agent中执行层级最高的。 它直接产生补货订单，影响真实资金流动。因此它对前两个Agent的依赖是硬依赖——A值校准Agent必须完成本周校准，蝴蝶效应Agent必须确认目标节点无A类失真，Omakase才能为该节点生成推单。任何一个前置条件不满足，推单暂停。
0 三Agent协作关系 · 顺序不可倒置
每周执行顺序（固定，不可并行）
节点门控（Gate）： Omakase在运行前检查每个目标节点的门控状态。只有同时满足「A值校准已完成本周校准」且「蝴蝶效应确认该节点无A类失真」的节点，才会生成推单。被蝴蝶效应暂停的节点自动跳过，不生成推单。
1 业务合约
输入承诺
来自A值校准的干净r值 + 来自蝴蝶效应的节点健康状态 + 当前库存水位 + 经销商的账期和信用状态
输出承诺
精确的SKU×数量×时间的补货推单 ，发给经销商确认。不是建议范围，是具体的订单草稿。
对谁负责
对经销商 负责（推单要准确，不能造成压货）· 对门店 负责（不能因为推单不及时导致断货）· 对公司现金流 负责（推单量直接影响回款节奏）
成功标准
推单后28天内经销商消化率保持 >70% · 门店断货率 <5% · 推单量误差 <15%（实际补货量 vs 推荐量）
失败标准
推单后经销商出现A类压货（消化率下降到60%以下）· 或推单后28天内有门店出现断货超过3天
2 触发条件
上游触发
蝴蝶效应扫描完成后 · 主触发
每周一蝴蝶效应Agent完成全量扫描后，Omakase接收健康节点名单，为所有通过门控的节点生成本周推单。这是主触发，覆盖所有正常经销商节点。
TRIGGER: inf_events.event_type = 'BUTTERFLY_SCAN_COMPLETE' · 周一 08:00
条件触发
水位低于1a · 紧急补货
当任何节点库存水位跌破1a（预警线），不等下周定时窗口，立即生成紧急补货推单。这是断货预防的最后防线。优先级高于常规推单。
TRIGGER: inf_heartbeat.water_level = 'WARN' OR 'LOW' → 即时触发
阻断条件
以下情况自动跳过，不生成推单
① 蝴蝶效应标记A类失真（OMAKASE_PAUSE事件存在）· ② 经销商信用评级D级（账期超期）· ③ A值校准本周未完成（数据不可信）· ④ 经销商主动申请暂停
BLOCK: 任一条件满足 → 跳过该节点 · 写入跳过原因日志
3 数据读取
数据源 表名 关键字段 用途 重要性
A值校准Agent
inf_node_targets
r_target, confidence, calibrated_at
计算补货量的基准动销速率。confidence必须≥MED才使用。
核心·门控
蝴蝶效应Agent
inf_events
event_type='OMAKASE_PAUSE', node_id, sku_id
门控检查。有PAUSE事件则跳过该节点。
核心·门控
Dcloud/SAP
inf_heartbeat
inventory_units, water_level, inflow_units
当前库存水位，计算距离满仓还差多少，即补货量。
核心
年级系统
inf_node_targets
grade, target_water_level
不同年级的目标水位不同（年级1高水位保障，年级3-4适当精简库存）
核心
经销商信用
inf_nodes
credit_grade, overdue_days, overdue_amount
账期超期的经销商暂停推单，防止信用风险扩大
门控
历史推单
inf_actions
action_type='REPLENISHMENT', quantity, actual_received, outcome
对比历史推单量和实际接单量，校准推单准确率
参考·学习
季节/大促日历
inf_events
event_type='CAMPAIGN', multiplier, sku_ids
大促前按倍数放大推单量，大促后按消化情况缩减
参考
4 决策逻辑 · 五步推单计算
1
门控检查（Gate Check）
对每个目标节点×SKU组合，检查三个门控条件。任一不满足则跳过，不进入计算。
FOR each node × sku in target_list:
GATE_1: inf_node_targets.calibrated_at >= THIS_WEEK_MONDAY
→ A值校准本周已完成
GATE_2: NOT EXISTS OMAKASE_PAUSE event(node, sku, active)
→ 蝴蝶效应未标记失真
GATE_3: inf_nodes.credit_grade != 'D'
→ 经销商信用正常
IF all gates pass → CONTINUE to step 2
IF any gate fails → SKIP, log reason, notify DOM
2
计算目标库存量
根据年级和节点类型，确定目标水位（满仓应该是多少）。
-- 目标水位规则（按经销商层级）
经销商满仓目标：
年级1-2（成长期）: 2a ← 需要充足库存支撑铺货
年级3（成熟期）: 2a ← 维持正常
年级4-5（特殊）: 1.5a ← 谨慎，避免压货
-- a值计算
a = r_target × T （T=经销商补货周期，通常30天）
target_inventory = target_water_level × a
-- 案例：遵循自然500ml · 宝仓贸易
r_target = 4.82件/天, T = 30天
a = 4.82 × 30 = 144.6件 ≈ 145件
target_inventory = 2a = 290件（满仓目标）
3
计算补货量
用目标库存减去当前库存，再加上补货到达前预计消耗的量（在途消耗保护）。
-- 基础补货量
replenishment_base = target_inventory - current_inventory
-- 在途消耗保护（物流时间 × r值）
lead_time_days = 3 -- 从推单到到货的天数
lead_time_consumption = r_target × lead_time_days
-- 最终推荐补货量
replenishment_qty = replenishment_base + lead_time_consumption
-- 案例：遵循自然500ml · 宝仓贸易
current_inventory = 180件（当前库存）
replenishment_base = 290 - 180 = 110件
lead_time_consumption = 4.82 × 3 = 14.5 ≈ 15件
replenishment_qty = 110 + 15 = 125件
-- 最小推单保护（避免小额频繁推单）
IF replenishment_qty < 0.3a → 延迟到下次推单合并
4
季节和大促调整
根据日历事件，对推单量进行系数调整。大促前加量，大促后减量。
大促前14天
推单量 × 大促系数（通常1.3-1.5）。系数由管理层通过C1规则设定。
季节性月份
如有历史同期数据，应用seasonal_coeff（第一年无数据则coeff=1.0）
大促后2周
如消化率还在75%以上，正常推单。如消化率下降，减量50%，防止大促后二次压货。
正常周期
无调整，使用步骤3的计算结果。
5
SKU组合优先级排序
对同一经销商的所有SKU推单，按优先级排序生成推单清单。帮助经销商在资金有限时决定先订哪个SKU。
优先级评分 = 水位紧急度(40%) + 年级战略价值(30%) + 利润贡献(30%)
-- 水位紧急度
EMPTY/LOW = 100分，WARN = 70分，FULL = 0分
-- 年级战略价值（公司设定权重）
年级1遵循自然 = 90分（战略新品，优先铺货）
年级3红烧系列 = 80分（现金奶牛，保障供应）
年级4特级酱油 = 50分（谨慎推进）
-- 利润贡献（经销商视角）
进货利差最大的SKU优先
+ 推单样例 · 宝仓贸易（浦东）
年级2
遵循自然 500ml
水位1.4a→目标2a · r=4.82件/天 · 在途3天消耗15件
🔴 优先
年级3
红烧酱油系列
水位1.8a→目标2a · 正常补货 · r=8.4件/天
🟡 正常
年级3
红烧酱油大装
水位1.9a→目标2a · 接近满仓 · 小量补充
🟢 补充
年级1
遵循自然 1L
水位1.2a→目标2a · 需要补充 · r=3.1件/天
🔴 优先
年级5
特级酱油 885ml
⚠️ 蝴蝶效应暂停 · 消化率61% · 本周跳过
⏸ 已暂停
5 输出规格
📱
企微推单通知 · 经销商接收
企业微信
推送给经销商的推单卡片，包含完整SKU清单、数量、建议原因、总货款。24小时内确认，超时视为接受。经销商可以修改数量，但修改超过±30%需要DOM确认。
【🍣 本周补货推单】宝仓贸易
──────────────────────
📦 遵循自然500ml → 125件 🔴
📦 遵循自然1L → 96件 🔴
📦 红烧酱油系列 → 68件 🟡
📦 红烧酱油大装 → 24件 🟢
⏸ 特级酱油885ml → 本周暂停
合计：313件 / ¥28,400
建议到货日：2026-04-17（周四）
[确认接单] [修改数量] [本周跳过]
──────────────────────
24小时内未回复 = 默认确认
🗄️
写入推单记录
inf_actions
每笔推单写入inf_actions，后续跟踪实际接单量、到货量、结果，形成学习闭环。
INSERT INTO inf_actions VALUES (
action_type: 'REPLENISHMENT',
node_id: 'DIST-BC',
sku_breakdown: [
{sku:'ZR5', qty:125, priority:'HIGH', reason:'water_level_1.4a'},
{sku:'ZR1', qty:96, priority:'HIGH', reason:'water_level_1.2a'},
{sku:'HS', qty:68, priority:'MED', reason:'normal_replenishment'},
{sku:'HSL', qty:24, priority:'LOW', reason:'top_up'},
{sku:'TJ', qty:0, priority:'SKIP', reason:'OMAKASE_PAUSE'},
],
total_qty: 313,
total_value: 28400,
status: 'PENDING_CONFIRMATION',
created_at: NOW()
)
📊
推单结果跟踪 · 28天后
INFINITY OS界面
推单28天后，系统自动回顾：实际消化率是否达标？是否出现断货？推单量误差多大？结果写入学习日志，提高下次推单准确率。
推单结果回顾 2026-W15 · 宝仓贸易
──────────────────────
遵循自然500ml:
推单125件 → 实际接收122件 → 28天消化率81% ✅
推单准确率: 97.6% 结论: 推单量合理
遵循自然1L:
推单96件 → 实际接收96件 → 28天消化率69% ⚠️
消化率略低，下次推单减量10%
整体评分: 4.2/5.0
──────────────────────
学习更新: ZR1节点r值可能略高估，下周校准时参考
6 自主边界
+ 依赖关系
⚠️ 硬依赖：A值校准本周完成
⚠️ 硬依赖：蝴蝶效应扫描完成
⚠️ 需要：Dcloud库存数据实时接入
⚠️ 需要：企微发送权限配置
✅ 输出给：经销商（推单卡片）
✅ 输出给：一本账（推单量影响薪酬计算基数）
✅ 输出给：DOM（被跳过节点的通知）
📊 反馈给：A值校准（28天结果用于下次校准参考）
+ 核心SQL · Java团队实现参考
-- ① 门控检查：查询可以推单的节点
SELECT DISTINCT h.node_id, h.sku_id
FROM inf_heartbeat h
JOIN inf_node_targets t ON h.node_id=t.node_id AND h.sku_id=t.sku_id
JOIN inf_nodes n ON h.node_id=n.node_id
WHERE h.date = CURDATE()
-- Gate 1: A值校准本周已完成
AND t.calibrated_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)
AND t.confidence IN ('HIGH','MED')
-- Gate 2: 蝴蝶效应未暂停
AND NOT EXISTS (
SELECT 1 FROM inf_events e
WHERE e.node_id=h.node_id AND e.sku_id=h.sku_id
AND e.event_type='OMAKASE_PAUSE'
AND e.created_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
)
-- Gate 3: 信用正常
AND n.credit_grade != 'D';
-- ② 计算补货量（核心公式）
SELECT
h.node_id, h.sku_id,
t.r_target,
t.grade,
h.inventory_units AS current_inventory,
-- a值
ROUND(t.r_target * 30) AS a_value,
-- 目标水位（年级1-3为2a，年级4-5为1.5a）
ROUND(t.r_target * 30 * IF(t.grade <= 3, 2.0, 1.5)) AS target_inventory,
-- 基础补货量
GREATEST(0,
ROUND(t.r_target * 30 * IF(t.grade <= 3, 2.0, 1.5))
- h.inventory_units
+ ROUND(t.r_target * 3) -- 在途消耗保护（3天）
) AS replenishment_qty
FROM inf_heartbeat h
JOIN inf_node_targets t ON h.node_id=t.node_id AND h.sku_id=t.sku_id
WHERE h.date = CURDATE()
AND h.node_id IN (/* 步骤①的结果 */);
-- ③ 写入推单记录
INSERT INTO inf_actions (
action_type, node_id, sku_id, quantity,
priority, reason, status, created_at
) VALUES (
'REPLENISHMENT', ?, ?, ?,
?, ?, 'PENDING_CONFIRMATION', NOW()
);
🍣 Omakase推单 Agent · 问答
经销商拒绝推单
低置信度下如何推单
大促后库存积压
三Agent完整闭环
你好，我是Omakase推单 Agent 规格说明书。三张规格说明书的最后一张。问我任何关于推单逻辑、门控机制、闭环设计的问题。
↑
✅
三张Agent规格说明书完成
A值校准 → 蝴蝶效应 → Omakase推单