AI Agent 补货落地拆解:3 个已注册 Agent 如何执行补货建议

背景:为什么补货适合用 Agent 来做

补货是一类典型的"半结构化知识工作":流程相对固定(取数 → 运算 → 调方案 → 生成订单),但每一步都要理解业务语境——哪个仓、什么渠道、促销期怎么调系数。纯自动化脚本扛不住语境变化,纯人工又困在重复劳动里。AI Agent 的价值恰好在中间:让业务人员用自然语言驱动一条确定性的执行链路。

本文拆解轻易云智能补货平台当前已落地的 Agent 体系。需要说明的是,以下均为已上线事实,不涉及任何未兑现的效果承诺。

平台结构:A/B/C/D 四层链路

Agent 不是悬空的"聊天框",它操作的是一条清晰的分层链路:

• A 数据明细层:仓库、商品、分类、供应商、销售渠道等主数据,加上采购单、销售单、入出库单、调拨单等业务单据,按统一主键落库。数据源以吉客云开放平台 7 个核心接口为主(仓库 erp.warehouse.get、商品分类 erp.goodscate.get、商品 erp.storage.goodslist、供应商 erp.vend.get、销售渠道 erp.sales.get、采购单 erp.purch.get、即时库存 erp.stockquantity.get),辅以 Excel 适配器导入手工台账。
• B 取数加工层:声明式定义过滤、聚合、时间窗口、多源在途合并,沙箱内同步执行,30 秒内返回维度对齐的明细表。
• C 运算层:运算脚本消费 B 层输出,取数结果先分块落库为 PENDING 行,再经 BullMQ 按 500 行/批 fan-out 异步运算,200k 行熔断兜底;方案级 6 态、行级 7 态(PENDING / DRAFT / ADJUSTED / EXCLUDED / CONFIRMED / ORDERED / FAILED)闭环。
• D 方案与订单层:补货参数具名保存为方案模板,重算产版本化新批次并保留血缘;行级人工调整(调数量 / 排除 / 确认)后,按 orderKey 拆单生成补货订单,建议快照进订单明细,支持双向溯源。

三个已注册 Agent 的分工

设计上有一条硬纪律:所有写动作走"脚本 + 既有执行链路",Agent 不发明新的写入路径。Agent 产出的是脚本与参数,执行仍由沙箱与队列完成——这让 Agent 的能力边界清晰可审计,而不是一个可以任意操作数据库的黑盒。

一个典型工作流

1. 业务人员对取数脚本工程师说:"拉一下 2C 事业部近 30 天按商品 × 仓库的销量明细。"
2. Agent 生成 / 调整 FetchScript,用业务语言复述要执行的取数口径,请求确认。
3. 确认后脚本进入沙箱执行(child_process 子进程 + isolated-vm 双层隔离,SQL 仅读强制),输出行数、耗时、参数写入通用审计表。
4. 业务人员对运算脚本工程师说:"按周补货模板跑一版方案,促销品的系数上调一档。"
5. Agent 生成 ComputeScript 并复述运算口径,确认后取数落库为 PENDING 行,BullMQ 批次异步运算;失败行可按方案级重试。
6. 运算完成后,业务人员在方案里逐行调整,确认后按 orderKey 拆单为补货订单。

知识库如何让 Agent "懂业务"

Agent 检索依赖向量 + 关键词混合召回、RRF 融合、MMR 重排的知识库(1536 维向量),把补货规则说明、口径定义、历史方案沉淀为可检索的知识。这样 Agent 回答"为什么这个 SKU 建议补 200 件"时,引用的是业务自己的规则文档,而不是模型的臆测。

落地经验:三条值得借鉴的设计

1. 确认前置,而非事后审批:写动作(试跑、提交方案)前用一句业务语言确认,比事后翻审计日志有效得多——人在理解上下文的那一刻做判断。
2. 沙箱与熔断是 Agent 敢上线的前提:双层隔离、SQL 仅读、200k 行熔断、500 行/批 fan-out,把"Agent 犯错"的爆炸半径限制在可控范围。
3. 可追溯性优先于自动化程度:每条建议可逐行回查维度、原始变量、公式与调整记录,方案重算保留 parentPlanId 血缘。先让业务敢信,再让系统多做。

这套体系的启示是:供应链场景里,Agent 的落地关键不在模型多强,而在执行链路是否确定、权限边界是否清晰、每次写动作是否有人兜底。