一、项目背景

XpShop 新普MALL 是一套面向 S2B2B2C 形态的企业级电商生态，其供应链一侧长期存在"补货靠人拍脑袋"的痛点。我们当时接到的需求是：在品牌商—经销商—门店的多级组织树下，让辅助采购从经验驱动转向数据驱动。这个诉求听起来朴素，落地却并不简单——补货决策横跨销售、库存、在途、履约多个系统，任何一环数据失真都会传导到最终结果。

过去采购专员每天要翻销售报表、查库存台账、比对在途采购单，再凭借经验手写补货建议，既慢又容易漏看。每逢大促前的备货高峰，人工测算往往赶不上节奏，要么缺货断档、要么积压占仓。这个项目里，我们决定用多智能体（Multi-Agent）协作来承载"预测→库存→补货建议"的完整链路，而不是用一个超长提示词硬扛。我们采用的自研 AI 网关与私有化部署底座，承担了统一接入多模型、智能路由、计量配额，以及 RAG 检索与对话状态管理的基础能力，使我们把精力集中在业务编排而非底层推理运维上。

二、落地场景

落地场景围绕辅助采购展开，由三个核心 Agent 协作完成，彼此通过编排器（Orchestrator）串联：

• 预测 Agent：拉取近 90 天销售流水、促销日历、季节因子与节假日权重，输出 SKU 维度的未来 14 天销量预测，并给出预测置信区间。
• 库存 Agent：查询实时可售库存、在途采购单、安全库存阈值与履约前置周期，计算各仓库的缺口与覆盖天数。
• 分析 Agent：综合前两者结果，调用大模型生成带解释的补货建议（补什么、补多少、优先级、为什么），并标注置信度。

上层编排器负责把三者串起来，对异常 SKU（如销量突变、数据缺失）触发人工复核。最终建议经人确认后回写到 XpShop 的供应链与仓储履约模块，形成"建议—确认—执行"的闭环，而非模型直接改库。

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

多 Agent 编排（串行/并行/回退）。 预测与库存彼此独立，适合并行执行以缩短时延；分析 Agent 必须等两者都返回才能工作，是串行依赖。我们采用 DAG 编排描述这种依赖，并对每个节点配置回退模型。当主模型实例超时、限流或返回异常时，编排层依据路由策略自动切到备用实例，保证整条链路不卡死。下面是我们在生产中实际使用的编排定义片段：

{
  "graph": "predict || inventory -> analyze -> review",
  "nodes": {
    "predict":  {"model": "forecast-7b", "fallback": "forecast-3b", "timeout_s": 20},
    "inventory":{"model": "tool-caller", "fallback": "tool-caller-v2", "timeout_s": 15},
    "analyze":  {"model": "reason-34b", "fallback": "reason-13b", "timeout_s": 30},
    "review":   {"type": "human_in_loop", "trigger": "confidence<0.6"}
  }
}

上下文传递与状态。 三个 Agent 之间不能各说各话，否则分析 Agent 拿到的是残缺信息。我们用一个共享的 ContextStore 传递结构化状态：预测 Agent 写入 forecast 字段，库存 Agent 写入 stock 字段，分析 Agent 读取二者后写入 suggest。状态以 JSON 形式随调用链传递，避免把长文本原文在 Agent 间反复搬运，既省 token 又降低因拼接错位引发的幻觉。这里的关键认知是：Agent 间传递"结论与关键参数"远比传递"过程文本"可靠。

工具调用权限与重试。 库存 Agent 要查 WMS 与 ERP，这属于写权限敏感的工具调用。我们给每个工具定义了最小权限 schema，并在 AI 网关侧做二次鉴权，确保模型不能越权读改核心业务数据。工具调用失败时按指数退避重试，三次仍失败则标记该 SKU 为"数据缺失"，交由分析 Agent 降级处理（仅依据预测侧给保守建议）而非整链报错，从而保证局部故障不影响全局产出。

案例片段（已脱敏）：库存 Agent 的工具 schema 片段—— {"name":"query_stock","description":"按 SKU+仓库查询实时库存","parameters":{"sku":{"type":"string","required":true},"warehouse":{"type":"string","required":true}},"permission":"read:wms","retry":{"max":3,"backoff":"exponential"}}

人在回路。 补货最终影响真金白银，不能全自动放行。我们设定当分析 Agent 的置信度低于 0.6、或建议补货金额超过设定阈值、或涉及新供应商时，一律进入人工复核队列。人确认后结果才回写执行系统，保证"模型提建议、人做决策"的边界清晰。这个节点不是流程累赘，而是把不可量化的业务判断（如供应商关系、临时促销）交还给最擅长的人。

四、效果数据

下表为脱敏示意数据，统计口径为某区域经销商集群上线前后对比（约一个季度）：

需要说明的是，上述数值为内部脱敏示意值，用于说明趋势，不构成审计口径。

五、可复用经验总结

第一，复杂流程要拆 Agent 而不是堆提示词。把"预测、查库存、分析"拆成职责单一的 Agent，每个都更易测试、更易替换模型，整链可观测性也更好。第二，人在回路要守最后一关。涉及资金与履约的补货建议，必须保留人工确认节点，模型只做提效不做免责。第三，工具权限与重试是工程落地的硬骨头，越早用 schema 加网关鉴权收口，越省后续救火成本。第四，结构化状态传递比搬运原文更可靠，这也是多 Agent 系统能否稳定的隐性关键。这套以编排器为骨架、以共享状态为血脉、以人在回路为底线的设计，在我们后续其他智能体场景里也被反复复用。