## 库存补货建议生成与确认 {.case data-case-id="059"} | 字段 | 值 | | --- | --- | | 案例编号 | `059` | | 行业 / 部门 | 零售 / 供应链 | | 角色 | 供应链计划员 | | 难度 | `复杂` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取库存与在途数据） | 补货决策现在是"谁想起来谁补"：有的门店缺货了才发现，有的仓压了一堆滞销库存。目标：定时让获授权 Agent 经 App/Extension 读取各仓库存与在途数据，逐 SKU 比对库存与安全水位，低于安全水位的生成补货建议（建议量只按系统参数计算，参数缺失标"待确认"不猜），交供应链计划员逐条确认后才生成采购申请——绝不自动下单，也不自动创建采购单。路由顺序：先校验数据完整性（库存或在途任一侧不可达或缺失即按取数失败处理，不出建议不判红线），数据完整可判后才判红线——低于安全水位的 SKU 无论置信度多高都必须经人工确认，绝不因"数据很全、判断很有把握"跳过确认直接建单，最后才走常规归档。指标：低于安全水位的 SKU 100% 出现在建议清单；自动创建采购单 0 例；同一建议重复生成 0 例（幂等）；参数缺失 0 例被猜出。 - **覆盖**：定时读取库存与在途数据、逐 SKU 比对安全水位、生成补货建议（参数缺失标"待确认"）、计划员逐条确认后生成采购申请、零结果回执。 - **不覆盖**：自动创建采购单、自动下单或付款、自动调整安全水位或系统参数、自动拆分或合并建议。 - **假设**：有一个经授权能读取库存与在途数据的 Agent（通过 App/Extension）；SKU 主数据含安全水位与补货参数，均以系统值为准；采购申请的最终审批走采购平台既有流程。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每日定时由获授权的查询 Agent 经 App/Extension 读取各仓库存与在途数据，App/Extension 在读取侧即完成聚合，Agent 只接收 SKU、仓、当前库存、在途量、安全水位、建议量、参数状态等白名单字段，逐 SKU 比对库存（含在途）与安全水位并回传。建议量只按系统参数计算，任何参数缺失就标"待确认"不猜，绝不套用同类 SKU 参数。红线：低于安全水位的 SKU 无论置信度多高都必须经人工确认后才生成采购申请，绝不自动创建采购单——工作流不直接下单、不付款，执行在采购平台由人触发。 触发：定时（计划）发起调用，调用时带入平台/调度器签发且原样传递的 `period_key`（如上一完整周）、团队频道、查询 Agent 和审批人（供应链计划员）；统计窗口由该可信输入界定，Agent 不根据执行时刻铸造周期。 结果分流（依次判断：先数据完整性，再红线，最后常规）： 取数失败（库存或在途任一数据源不可达、数据陈旧、SKU 主数据取不到）：这是第一道判断，先于其他所有路由——告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不出建议、不判红线、不当作"本期无需补货"，也不基于单边数据出建议。 触及红线（数据完整且库存低于安全水位）：在数据完整可判的前提下，无论置信度多高，一律进入计划员逐条确认，绝不自动建单；确认后生成采购申请——写入由获授权 Agent 经 App/Extension 调用可信采购平台（作为调用输入或已授权连接）创建，带业务键=SKU+仓库+平台签发的 period_key+期望变化（创建采购申请）+目标采购平台（响应未知先查后写），按重试上限有限重试，仍失败升级值班并置"待处理"保留补偿，全程留审计；驳回则不建单留审计，本次失败结束。同一建议不重复生成：生成前先查该建议是否已有采购申请，再决定是否创建；同一 SKU 在同一仓库同一周期只建一张申请，重复调用不会产生第二张一样的申请。 参数缺失（数据可达但安全水位或补货参数缺失）：区分于取数失败——这是业务字段缺失不是系统故障，建议量不猜，该 SKU 标"待确认"仍进确认清单，由计划员确认时补全参数或人工定量；不用同类 SKU 参数或历史均值补。 正常（数据完整且库存不低于安全水位）：归档发汇总回执并留审计时间戳；本期全部正常即发"本期无需补货：发汇总回执并留时间戳，不静默结束"的零结果回执。 审批：补货建议必须经供应链计划员逐条确认；审批为二值确认或驳回，不设自动超时，无默认通过/否决，也不设自动确认。 异常：查询 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。取消只停止尚未调度的后续图，不召回已创建申请、不自动补偿；保留 Effect 与采购平台 receipt，恢复时按完整业务键查询权威状态，由恢复 Owner 决定保留结果、另建补偿行动卡或升级。 完成：建申请、驳回、参数缺失呈交、零结果回执、取数失败升级各自留审计时间戳后结束。 ``` ![案例 059 库存补货建议生成与确认：定时让获授权 Agent 读取库存与在途数据逐 SKU 比对安全水位（App 在读取侧聚合，Agent 只接收白名单字段）；依次路由——先判数据完整性：任一数据源不可达或缺失按取数失败告警留审计重试升级、不出建议不判红线；再判红线：低于安全水位无论置信度强制进入计划员逐条确认（绝不自动创建采购单），确认后生成采购申请留审计（生成前先查已有申请、业务键=SKU+仓库+平台签发 period_key+期望变化+目标采购平台），驳回不建单留审计；参数缺失（业务字段缺失，区别于取数失败）标待确认仍进确认清单；正常归档发汇总回执，本期全部正常发零结果回执；回传不合结构停在原等待点](../../../media/cases/fig-case-059-01-flow.svg){#fig-case-059-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **定时触发**：计划到点（每日）发起一次调用，带入平台/调度器签发且原样传递的 `period_key`、团队频道、查询 Agent 与审批人（供应链计划员）；Agent 不推断周期。 2. **比对库存与安全水位**：获授权 Agent 经 App/Extension 读取各仓库存与在途数据，App 在读取侧完成聚合，Agent 只接收白名单字段，逐 SKU 比对并回传（SKU、仓、当前库存、在途量、安全水位、建议量、参数状态）；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **依次路由（先数据完整性，再红线，最后常规）**： - **取数失败（第一道判断）**：库存或在途任一数据源不可达、数据陈旧或主数据取不到，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不出建议、不判红线、不当作"本期无需补货"，也不基于单边数据出建议。 - **触及红线（库存低于安全水位）**：数据完整可判时，无论置信度多高，强制进入计划员逐条确认，绝不自动建单（红线是路由条件，不是仅返回的字段）。确认后生成采购申请——写入由获授权 Agent 经 App/Extension 调用可信采购平台（作为调用输入或已授权连接）创建，业务键=SKU+仓库+平台签发的 period_key+期望变化（创建采购申请）+目标采购平台（响应未知先查后写），有限重试、升级、待处理补偿并全程留审计；驳回则不建单留审计，本次失败结束。生成前先查该建议是否已有采购申请再决定是否创建；同一 SKU 在同一仓库同一周期只建一张申请，重复调用不会产生第二张一样的申请。 - **参数缺失**：数据可达但安全水位或补货参数缺失，与取数失败分开处理，建议量不猜，该 SKU 标"待确认"仍进确认清单，由计划员确认时补全参数或人工定量。 - **正常**：数据完整且库存不低于安全水位，归档发汇总回执并留审计时间戳；本期全部正常即发零结果回执，不静默结束。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时比对 + 数据完整性校验 + 红线强制人工 + 多路分流"流程——它知道"比对库存"需要一个发消息并等待回调的 Agent 环节、"先校验数据完整性、再判红线、最后常规分流"需要一个条件路由且完整性与红线优先级最高、"计划员逐条确认"需要一个审批环节、"建申请与回执"各需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **低库存 SKU 被跳过确认**：最危险的漏判。规则把数据完整性校验放在第一道、把"库存低于安全水位"设为其后的强制人工红线，参数再全、置信度再高也不能自动建单——建单是采购副作用的前置门，必须由人按下；数据不完整时宁可取数失败，也不出建议或判红线。 - **参数缺失被猜出来**：参数缺失是业务字段缺失，与数据源不可达的取数失败分开处理；建议量只按系统参数计算，缺安全水位或补货系数就标"待确认"，绝不套用同类 SKU 参数或历史均值，由计划员确认时补全。 - **库存或在途数据源不可达、数据陈旧**：不当作"本期无需补货"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认；绝不基于单边数据出建议。 - **同一 SKU 重复建申请**：按“SKU + 仓库 + 平台签发的 period_key + 期望变化（创建采购申请）+ 目标采购平台”去重，重复调用不重复生成同一建议；建单前先查是否已有采购申请（响应未知先查后写），重复触发当期命中既有建议时只发一条已存在回执。 - **取消后的建单结果**：取消不召回已创建申请，也不自动补偿；保留采购平台 receipt，恢复时按完整业务键查权威状态，由恢复 Owner 决定保留、另建补偿行动卡或升级。 - **计划员驳回建议**：不建单、留审计，本次失败结束；要补货就重新确认一次，没有"AI 自动改判"。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **本期无需补货（结果为 0）**：仍发一条零结果汇总回执并留时间戳，让"没消息"变成可核验的记录。 - **查询 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态——宁可晚补，不可错补。若需响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并提醒计划员。 数据完整性校验先于一切路由，数据不完整即取数失败、不出建议也不判红线。所有补货建议（含参数缺失标"待确认"的）都必须经供应链计划员逐条确认后才生成采购申请，这是红线也是职责分离：建议由工作流生成，建单由人确认，下单与付款走采购平台既有审批流，三者不落在同一个人手里也绝不让工作流代办。确认时计划员能看到 SKU、仓、库存与在途、安全水位、建议量与计算依据，参数缺失处标着"待确认"，是"有依据的决策"而非盲目拍板。审批只有确认或驳回两种结果，驳回即不建单留审计；审批没有时限、不设自动确认，也没有"超时默认通过"。 本工作流对库存与在途数据的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统，更不直接下单或付款——采购申请生成后进入采购平台既有审批流，下单与付款由采购平台由人触发执行。团队频道、审批人作为调用输入提供；库存与在途数据源的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。数据源不可达或陈旧属于取数失败（第一道路由），走失败回执与升级。生成的采购申请自带幂等约束：建单写入由获授权 Agent 经 App/Extension 调用可信采购平台（作为调用输入或已授权连接）完成，建单前先查该建议是否已有采购申请（响应未知先查后写），业务键=SKU+仓库+平台签发的 period_key+期望变化（创建采购申请）+目标采购平台，同一建议重复调用不重复建单，按重试上限有限重试、仍失败升级值班并置"待处理"保留补偿，每步留时间戳与操作人。取消只停止尚未调度的后续图；App/Extension 保留采购平台 receipt，并支持恢复 Owner 按完整业务键读取权威状态后决定保留、补偿或升级。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），不额外外带商品与供应商商业信息，并按 10% 抽查四层实际记录。 - **回放集与基准**：取最近 3 个月 80 个 SKU 快照（含正常、低库存、参数缺失、数据陈旧样本）回放，人工基准答案为按系统参数计算的应建议清单；每日全量回放并记录扫描、确认、建单时间戳与操作人。 - **红线防线**：基准为低于安全水位的 SKU 中，进入计划员确认或生成申请的比例（召回率）100%；自动创建采购单 0 例。 - **不猜参数**：参数缺失的 SKU 100% 标"待确认"呈交，0 例出现猜测的建议量或套用的同类参数。 - **幂等核验**：对同一 `period_key` 重复调用 3 次，同一 SKU、仓库、期望变化与目标采购平台生成的采购申请数 ≤ 1，重复调用只发已存在回执；建单前未查重先建 0 例。 - **单边数据防线**：任一数据源陈旧或缺失的当期，生成建议或判红线的次数为 0，100% 按取数失败处理（第一道路由先于红线）。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），商品与供应商商业信息 0 次外带，按 10% 抽查四层实际记录。 - **结果可见**：建申请、驳回、参数缺失呈交、零结果、取数失败 100% 各有可见回执，不静默结束；每次运行留审计时间戳与操作人。 - **取消恢复**：在建单请求已发出后取消的回放中，已创建申请 0 次被召回或自动补偿，receipt 保留率 100%；恢复 Owner 100% 按完整业务键查询权威状态，并明确选择保留、另建补偿行动卡或升级。 ### 复用与变体 - **同构迁移**：门店要货建议、备件补库建议、包装材料补货建议。 - **双审变体**：建议金额区间超阈值的 SKU 建单前加签采购负责人，提示词里写明即可。 - **写回系统**：确认后再加一个 Agent 环节，由它通过 App/Extension 把"已建申请"状态写回补货台账；写回须是获授权 Agent 经 App/Extension 的幂等动作（业务键=SKU+仓库+平台签发的 period_key+期望变化+目标台账），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计，幂等可重放。若不需要写侧能力，改为只读汇总或仅留 Loop 回执更安全。