零售门店 Agent 从哪里开始？先把库存、销量和在途订单对上

门店员工发现货架快空了，问系统“今天要不要补这款商品”。如果 Agent 只读取库存表里的一个数字，答案很可能不够用：仓库里有货，不代表货已经分配到这家门店；采购单已创建，也不代表货物已经发出；收银销量上升，还可能是一次短期促销。补货建议要把几个口径放在同一条时间线上。

先定义“现在能卖多少”

零售系统中的库存字段常代表不同状态：账面库存、可售库存、预留库存、盘点差异、门店在途和仓库可用量。需要由业务团队说明哪些状态能相加、哪些已经被订单占用，以及数据更新时间。门店、仓库、商品和规格也要有稳定的编码关系；否则同一个商品在 POS、进销存和采购系统里名称相似、编码不同，查询结果就可能被错配。

随后再看销量。日销量、近几周的移动平均、星期差异、促销期以及节假日影响回答的是不同问题。短期促销带来的销量不应未经判断就成为长期补货依据；缺货期间的销量也会低估真实需求。Agent 不必自己重新定义零售预测模型，但应清楚展示采用的统计窗口和数据新鲜度，让店长知道建议依赖哪些事实。

让建议能解释自己的依据

一条可复核的建议，至少应显示门店与商品、当前可售量、最近销量区间、在途或已承诺的数量、数据更新时间和使用的补货规则。若结果里有缺失字段或数据过期，应明确标为待核对，而不是填一个看似完整的数字。补货点可以来自企业现有规则，例如安全库存、供应周期与最小起订量；规则应由采购和运营负责人维护，Agent 负责按规则组合信息并解释差异。

在此基础上，Agent 可以提示候选动作：补多少、从哪里补、预计何时到货，或建议先核实库存。建议还应指出触发它的条件，例如“按近四周非促销销量估算，当前可售量低于门店设定阈值；系统显示另有一笔调拨在途”。如果在途数据缺失，结论就该降级为待确认。解释信息让员工能判断建议是否适合当前现场，而不是只能点击接受。

采购动作保留在原有授权链路里

补货建议和采购订单不是同一件事。试点阶段可以让 Agent 只读查询并生成待审核草稿，由有权限的店长或采购人员确认。确认前再查询一次库存与在途状态，避免建议生成后数据已经变化；确认后通过现有业务接口写入，并保存操作者、依据、审批状态和接口返回结果。接口超时后先查询是否已创建，再决定是否重试，避免重复下单。

权限也要跟随业务范围。区域经理能查看多家门店，不代表每个店员都能读取整个区域的采购数据；员工身份、组织关系、门店范围应由企业现有系统判定。Agent 仅拿到完成当前任务所需的字段和动作，不要使用一个无限制账号替所有人查询和下单。若需要调拨、锁定库存或修改价格，还要单独定义授权与审批条件。

上线前可以挑选一批已结算的历史门店日样本，离线生成建议，与实际到货、缺货记录和现有规则对照。再做小范围只读试点，检查数据映射、刷新延迟、建议理由和店员纠错入口。记录建议被采纳、修改或拒绝的原因，分辨问题来自数据、规则还是场景本身；不要仅凭订单量增加就推断补货更准确。

关于零售行业更广的智能化改造，可看零售行业智能化升级实践；若要接入 POS、库存或采购系统，再参考企业 Agent 系统接入的身份与接口边界。先把一段门店流程的字段和责任人对齐，通常比让 Agent 同时覆盖选品、定价、营销和采购更容易验证。