一、项目背景

这个项目的客户是某头部美妆品牌商，他们使用我们自研的 XpShop 全渠道电商系统承载 S2B2B2C 业务，下游连着几百家经销商门店，上游对接品牌方的供应链与仓储履约。补货这件事过去高度依赖采购员的经验：每天看销量、看库存、看在途，凭手感决定给每个门店补多少。问题有三——一是人工判断慢且不一致，资深采购员和刚上岗的新人给出的建议能差出一大截；二是缺货与积压并存，热门品经常断档，长尾品又堆在仓库吃资金；三是采购员大量时间耗在"拉数据"而非"做决策"上。

我们当时想得很清楚：补货是一个多步骤、跨系统、需要判断的流程，不是靠一个提示词、一个模型就能硬扛下来的。销量预测要历史数据建模，库存研判要实时查库，补货建议生成要理解业务规则，最后还得有人拍板。于是我们决定在 XpShop 供应链系统上构建"辅助采购"多智能体，把流程拆成几个职责单一的 Agent，由 AI 网关做编排、路由与计量。这里用的是我们采用的私有化 AI 底座（vLLM 推理 + 向量库 + RAG 知识库 + 算力调度监控分层架构）和 AI 网关协同的方案。

二、落地场景

整个补货流程被拆成四个 Agent 串行 + 并行协作：

• 预测 Agent：拉取近 90 天历史销售数据（含促销标记、季节因子），调用底座里的时序模型产出未来 14 天销量预测；
• 库存 Agent：并行查询实时库存、在途订单、安全库存阈值，结合仓库 WMS 接口判断当前可用量；
• 分析 Agent：把预测 Agent 和库存 Agent 的结果汇总，调用大模型（经网关路由到合适的底座模型实例）生成结构化补货建议——每个 SKU 的建议补货量、到货窗口、优先级；
• 确认 Agent（人在回路）：高风险或大额建议不自动执行，转人工采购员在管控台确认后才落单到 ERP。

AI 网关在这个架构里承担两个角色：一是编排层（Orchestration），定义 Agent 间的串行/并行/回退关系；二是路由与计量，把每个 Agent 的请求路由到底座不同模型实例（轻量分类用私有小模型，复杂生成用大模型），并统一计量 token 与成本。底座与网关的协同还体现在：网关的限流信号会反向驱动底座弹性扩缩容，形成算力—流量联动闭环。

三、关键技术挑战与解决思路

① 多 Agent 编排

我们没用某开源社区的重量级编排框架，而是在网关编排层用声明式定义工作流。预测和库存是两个可并行的叶子节点，都完成后再触发分析 Agent；分析 Agent 失败（如模型超时）则回退到"基于安全库存的兜底规则"而非整条链路崩掉。编排定义存为可版本化配置，改流程不需动业务代码。

② Agent 间上下文传递与状态管理

各 Agent 不直接互相调用，而是通过一个共享的"任务上下文对象（TaskContext）"传递状态：预测 Agent 写入 forecast 字段，库存 Agent 写入 inventory 字段，分析 Agent 读取两者生成 suggestion。上下文用带 TTL 的缓存保存，避免一次补货任务跨 Agent 时状态丢失；同时上下文里只放脱敏后的业务数据，不夹带敏感字段（复用网关的脱敏关卡）。

③ 工具调用的权限与重试

Agent 要查数据库、调 ERP 接口，这些工具调用统一收口到网关的工具代理层。每个工具声明所需权限（如"只读库存""写入采购单需人工确认"），Agent 拿不到越权工具。调用失败按指数退避重试，三次失败后标记该工具不可用并走兜底逻辑，不阻塞主流程。ERP 写入类操作强制要求人在回路确认，Agent 本身无落单权限。

④ 人在回路

高风险定义得很具体：单笔补货金额超阈值、或建议量超过历史峰值的 2 倍、或涉及新供应商的，一律转人工。确认 Agent 把建议推到采购员管控台，附上模型给出的依据（销量预测曲线、库存缺口），采购员一键确认或修正。这层是"守最后一关"的保险，而不是流程负担——日常 70% 的低风险建议其实可自动预填，只把异常留给人工。

⑤ 网关对 Agent 高频调用的限流与成本治理

多个 Agent 在短时间内可能并发打满底座 GPU。网关对每个 Agent、每类模型设令牌桶限流，超阈值降级到私有小模型或排队。计量按"部门—应用—Agent—模型"四级维度沉淀，月底能看清"预测 Agent 花了多少、分析 Agent 花了多少"，避免多 Agent 协同变成成本黑洞。

案例片段（已脱敏）： 一次补货流程的 Agent 编排定义（YAML 示意）：yaml workflow: replenish steps:  - id: forecast    agent: 预测Agent    model: ts-forecast-private    parallel_with: [inventory]  - id: inventory    agent: 库存Agent    tool: wms.query_stock    parallel_with: [forecast]  - id: analyze    agent: 分析Agent    model: llm-gen-private    depends_on: [forecast, inventory]    on_fail: fallback_rule_based  - id: confirm    agent: 确认Agent    human_in_loop: true    risk_rule: "amount>50000 OR qty>2*peak"    depends_on: [analyze]一次补货任务运行日志（脱敏后摘要）：[10:02:01] 预测Agent 拉取 SKU-A 90天销量 → 14天预测均值 320/日 [10:02:03] 库存Agent 查 WMS → 可用 180，在途 0，安全库存 200 [10:02:09] 分析Agent 生成建议 → 补货 3,200，优先级 HIGH [10:02:11] 确认Agent 触发人在回路(金额超阈) → 推送采购员 u_203 [10:05:40] 采购员确认 → 落单 ERP PO-20260418-0771

四、效果数据

运行约一个季度后，统计脱敏示意数据（均为脱敏示意值，非审计级精确数字）：

• 补货建议采纳率：采购员对系统建议的采纳率约 82%，较上线前纯人工判断的一致性显著提升，新老采购员产出差距明显收窄；
• 库存周转提升：核心 SKU 库存周转天数约从 41 天降至 29 天，周转效率提升约 29%；
• 缺货率下降：热门品缺货率约从 6.8% 降至 2.3%，断档客诉相应减少；
• 人工采购工时下降：采购员用于"拉数据、算缺口"的事务性工时约下降 45%，更多精力投入到供应商谈判与异常处理上；
• 成本可控：借助网关四级计量，多 Agent 协同的月度 AI 成本稳定在可预期区间，未出现超预算激增。

五、可复用经验总结

• 复杂流程拆 Agent，而非堆提示词：补货这种多步骤、跨系统的任务，硬塞进一个超长提示词，既难维护又易出错。按职责拆成单一 Agent，每个只干一件事，编排关系和失败回退都清晰可控。
• 人在回路守最后一关：大模型不是用来替人背锅的。把高风险、大额、异常的建议转人工，日常低风险建议自动预填，既保安全又不牺牲效率。确认 Agent 是流程的保险丝，不是流程的累赘。
• 上下文对象解耦 Agent：各 Agent 通过共享 TaskContext 而非互相直调传递状态，链路可观测、可重放、易调试。上下文里只放脱敏数据，复用网关脱敏能力。
• 工具调用必须收口与鉴权：Agent 调数据库、ERP 这类动作，统一走网关工具代理层做权限声明和失败重试，写类操作强制人工确认。否则 Agent 一旦获得越权工具，风险不可控。
• 网关治理多 Agent 成本：多 Agent 并发很容易把底座 GPU 打满、把账单打爆。网关的限流 + 四级计量是让多智能体"跑得起也养得起"的前提，算力—流量联动闭环让底座扩缩容有据可依。

结语：多智能体协同不是把多个模型拼在一起那么简单，真正落地靠的是清晰的职责切分、可靠的编排与回退、以及对工具调用和成本的可治理。在 XpShop 供应链这个场景里，我们体会到——把复杂流程拆成会协作的 Agent，比训练一个"什么都会"的巨模型，工程上要稳健得多，也更容易让业务方真正用起来。