当前位置：首页 > news >正文

供应链Agent决策架构

news 2026/8/14 22:47:36

摘要

大语言模型进入供应链系统后，最容易实现的是知识问答、报表总结、风险解释和系统查询。但当问题从“发生了什么”进一步变成“接下来应该怎么做”，系统就开始面对库存、产能、运输、交期、成本和计划稳定性等大量相互耦合的约束。

这类问题本质上属于约束满足与组合优化，仅依赖大语言模型难以稳定生成可执行方案。

一种更可靠的技术路线是：由 AI Agent 负责自然语言理解、上下文组织和任务编排，由统一领域模型表达订单、库存、供应商和物流资源，由模型生成器将业务规则转成变量、约束和目标，再由 MIP、CP-SAT、网络流、Routing 等优化算法完成方案搜索，最后通过独立验证器检查结果是否真正可执行。

本文以供应商延期后的订单重分配为例，从系统架构、数据流、数学建模、求解器选型、工程实现、性能优化和常见误区等方面，拆解一个可以落地的供应链 AI Agent 决策架构。

适用读者

本文适合：

AI Agent 开发工程师
运筹优化算法工程师
供应链、APS、WMS、TMS 系统开发者
工业软件架构师
数据与算法平台负责人
制造业数字化技术管理者

一、供应链AI真正难的不是预测，而是决策

假设一家制造企业突然收到供应商通知：

某个关键零件的交付时间延迟三天。

大语言模型很容易给出下面这些建议：

优先保障重要客户；
使用现有安全库存；
寻找替代供应商；
必要时采用加急运输；
延后低优先级订单。

这些建议方向都没有问题。

但真正执行时，系统必须继续回答：

哪几张订单继续按期交付？
哪几张订单需要延期？
哪些库存应该分给哪个客户？
哪些订单值得使用加急运输？
替代供应商应该分配多少采购量？
调整后是否超过物流容量？
是否破坏已经冻结的生产计划？
有没有比当前方案成本更低的其他方案？

这时，问题已经从“语言生成”变成了：

大量决策变量 + 大量业务约束 + 相互冲突的优化目标

这正是运筹优化擅长处理的问题。

需要说明的是，本文所说的“优化求解能力”并不特指某一种算法。

它可以包括：

混合整数规划（MIP）；
约束规划（CP）和 CP-SAT；
最小费用流、最大流等网络优化算法；
车辆路径和路径规划算法；
启发式与元启发式算法；
大邻域搜索；
针对具体业务设计的专用优化算法。

因此，更准确的问题不是：

大模型和求解器谁更强？

而是：

哪类问题应该交给大模型，哪类问题应该交给确定性的优化算法？

二、Agent和求解器应该如何分工

一个供应链智能决策系统可以采用下面的职责划分：

用户业务语言 ↓ AI Agent 意图理解 / 实体解析 / 任务拆解 ↓ 领域模型与业务规则 订单 / 物料 / 库存 / 供应商 / 仓库 / 运输 ↓ Decision Request 结构化决策请求 ↓ Model Builder 变量 / 约束 / 目标 ↓ Optimization Engine MIP / CP-SAT / Flow / Routing / Heuristic ↓ Solution Validator 独立结果验证 ↓ AI Agent 影响分析 / 方案解释 / 备选方案比较 ↓ ERP / APS / WMS / TMS / MES

核心原则是：

AI Agent 负责理解“业务想要什么”，优化引擎负责计算“怎样做到”。

Agent 不应该直接承担严格约束求解。

求解器也不应该直接负责理解模糊的自然语言。

三、完整系统架构

如果进一步按照工程模块拆分，可以设计为：

┌─────────────────────────────┐ │ 用户交互层 │ │ 自然语言 / API / 事件 │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ AI Agent编排层 │ │ 意图识别 / 任务拆解 / Tool │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ 供应链领域模型 │ │ Order / SKU / Inventory │ │ Supplier / Warehouse / Lane │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ 数据与业务规则校验 │ │ 完整性 / 一致性 / 冻结规则 │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ Optimization Request │ │ 目标 / 约束 / 场景 / 参数 │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ Model Builder │ │ 模型模板 / 变量 / 约束生成 │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ Optimization Engine │ │ MIP / CP / Flow / Routing │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ Solution Validator │ │ 可行性 / 业务规则 / 版本 │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ Explainability Layer │ │ 原因 / 影响 / Trade-off │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ 业务执行系统 │ │ ERP / APS / WMS / TMS │ └─────────────────────────────┘

这套架构里一个非常重要的设计原则是：

LLM 不直接自由生成底层数学模型。

更稳妥的方式是：

LLM决定“需要哪些模型能力” ↓ Model Builder使用经过测试的模板 ↓ 生成确定性的优化模型

四、数据层需要统一哪些业务对象

供应链决策往往横跨多个系统。

例如：

ERP 存订单和采购数据；
WMS 存库存；
TMS 存运输资源；
APS 存生产计划；
MES 存生产执行进度。

如果 Agent 直接面对这些系统的原始字段，很容易出现语义不一致。

因此可以先建立统一领域模型：

Order 订单 OrderLine 订单行 Product 产品 SKU 库存单元 Supplier 供应商 Warehouse 仓库 Inventory 库存 TransportLane 运输线路 TransportMode 运输方式 PurchaseOrder 采购订单 ProductionOrder 生产订单 Shipment 运输任务 DecisionScenario 决策场景

典型关系包括：

Order contains OrderLine OrderLine requests SKU Warehouse stores SKU Supplier supplies SKU Shipment uses TransportLane ProductionOrder consumes SKU

简单系统中，普通关系数据库加统一 Schema 已经足够。

只有当对象关系、继承关系和跨系统语义越来越复杂时，才需要进一步考虑知识图谱或正式本体。

五、Agent如何把自然语言转成决策请求

假设计划员输入：

供应商 S1 延期三天，优先保证 A 类客户，不要调整已经发运的订单，加急物流成本最多增加 20 万。

AI Agent 不应该直接开始“排计划”。

首先应该转换成结构化请求：

{ "intent": "SUPPLY_DISRUPTION_REPLAN", "disruption": { "supplier_id": "S1", "delay_days": 3 }, "priority_policy": { "customer_class": "A", "weight": 10 }, "frozen_objects": { "shipment_status": [ "DISPATCHED", "IN_TRANSIT" ] }, "constraints": { "max_extra_expedite_cost": 200000 }, "objectives": [ "MINIMIZE_WEIGHTED_TARDINESS", "MINIMIZE_EXTRA_LOGISTICS_COST", "MINIMIZE_PLAN_CHANGES" ] }

接下来由规则层完成：

客户 A 对应哪些订单；
S1 供应哪些 SKU；
哪些订单因此受到影响；
哪些发运任务已经冻结；
20 万成本上限是否合法；
哪种优化模型适合当前场景。

只有这些条件经过确认，才能进入数学模型。

六、一个最小供应链分配模型

下面以一个简化的“订单—仓库—运输方式分配”问题为例。

实际项目可能还涉及采购、生产和多周期库存，但这个模型已经可以说明核心结构。

1. 集合

定义：

$\mathcal I$：订单集合；
$\mathcal W$：仓库集合；
$\mathcal M$：运输方式集合；
$\mathcal K$：SKU 集合；
$\mathcal A_i$：订单 $i$ 可以选择的合法“仓库—运输方式”组合。

2. 参数

定义：

$q_i$：订单 $i$ 的需求数量；
$k(i)$：订单 $i$ 对应的 SKU；
$I_{w,k}$：仓库 $w$ 中 SKU $k$ 的可用库存；
$c_{i,w,m}$：订单 $i$ 从仓库 $w$ 通过方式 $m$ 发运的总成本；
$T_{i,w,m}$：该方案预计产生的延期时间；
$p_i$：订单优先级权重；
$h_{i,w,m}$：相对于原计划的变更成本；
$U_m$：运输方式 $m$ 在当前决策周期内的可用容量。

3. 决策变量

定义：

$$
y_{i,w,m}\in{0,1}
$$

其中：

$$
y_{i,w,m}=1
$$

表示订单 $i$ 选择从仓库 $w$ 通过运输方式 $m$ 履约。

为了便于说明，这里假设订单不能拆单。

实际模型可以扩展为允许拆单的连续或整数数量变量。

七、核心约束

1. 每张订单只能选择一个方案

$$
\sum_{(w,m)\in\mathcal A_i}
y_{i,w,m}=1,
\qquad
\forall i\in\mathcal I
$$

2. 仓库库存不能超用

对于每个仓库和 SKU：

$$
\sum_{i:k(i)=k}
\sum_{m}
q_i y_{i,w,m}
\le
I_{w,k},
\qquad
\forall w,k
$$

3. 运输容量约束

在简化的单周期模型中：

$$
\sum_i
\sum_w
q_i y_{i,w,m}
\le
U_m,
\qquad
\forall m
$$

实际项目中，运输容量通常还需要继续按照：

日期；
线路；
车辆类型；
区域；

增加维度。

4. 硬交期约束

如果某些订单不允许延期，可以直接在候选集合 $\mathcal A_i$ 中排除无法满足交期的方案。

例如：

预计到达时间 > 硬交期 ↓ 该仓库—运输方式组合不进入候选集合

这样比在目标函数中增加一个极大的延期惩罚更容易解释。

八、目标函数

可以构建：

$$
\min
\sum_i
\sum_{(w,m)\in\mathcal A_i}
\left(
c_{i,w,m}
+
\alpha p_iT_{i,w,m}
+
\beta h_{i,w,m}
\right)
y_{i,w,m}
$$

其中：

第一项控制物流和履约成本；
第二项控制加权延期；
第三项控制计划稳定性。

这里的 $\alpha$、$\beta$ 用于调整不同目标之间的权衡。

但实际项目中需要谨慎使用简单加权和。

例如：

核心客户绝不延期

和：

尽量减少物流成本

显然不是同一优先级。

这种情况更适合：

第一层： 满足硬约束 第二层： 保证核心客户 第三层： 最小化总体延期 第四层： 降低运输和计划变更成本

也就是分层优化或词典序优化。

九、不同问题应该选择什么算法

供应链没有一种 Solver 可以解决所有问题。

问题特征	优先考虑
网络运输、流量分配结构明显	Network Flow
采购、库存、供应、产能联合决策	MIP
排程、时间窗、资源互斥	CP / CP-SAT
车辆路径、配送路径	Routing / VRP
超大规模动态重排	LNS / 启发式
多层网络联合优化	MIP + 分解算法
需要秒级近似结果	启发式 / 局部搜索

Network Flow

如果问题天然就是：

Source ↓ Warehouse ↓ Distribution Center ↓ Customer

并且约束主要是网络容量和流量平衡，使用最小费用流通常比把所有问题都转成通用 MIP 更自然。

MIP

如果存在：

是否启用供应商；
是否开仓；
MOQ；
固定采购成本；
分段价格；
订单选择；
多种资源联合决策；

MIP 往往更容易表达。

CP-SAT

如果问题包含大量：

时间窗口；
资源互斥；
工序先后；
离散逻辑；

CP-SAT 更适合表达这类组合约束。

启发式与LNS

当问题规模非常大，并且要求秒级返回方案时，不一定需要证明全局最优。

此时可以采用：

规则构造初始解 ↓ 局部搜索 ↓ Large Neighborhood Search ↓ 得到高质量可行解

工程上真正重要的不是：

使用哪一种最“高级”的算法？

而是：

在给定规模、约束结构和响应时间下，选择成本最合适的算法。

十、Agent不应该自由生成求解器代码

一种风险较高的设计是：

自然语言 ↓ LLM生成完整MIP代码 ↓ 直接执行

这种做法可能产生：

漏约束；
索引错误；
单位错误；
变量维度错误；
Big-M 设置错误；
目标函数错误；
不同请求生成不同模型结构。

更可靠的方法是建立模型组件注册表。

CONSTRAINT_REGISTRY = { "inventory_capacity": build_inventory_capacity, "transport_capacity": build_transport_capacity, "single_assignment": build_single_assignment, "frozen_plan": build_frozen_plan_constraint, "budget_limit": build_budget_limit, "supplier_capacity": build_supplier_capacity } OBJECTIVE_REGISTRY = { "weighted_tardiness": build_weighted_tardiness, "transport_cost": build_transport_cost, "plan_change": build_plan_change_cost }

Agent 决定：

启用哪些约束 + 启用哪些目标 + 参数是什么

而模型代码本身仍然来自经过测试的模板。

十一、完整的工程执行流程

可以设计如下伪代码：

def handle_supply_chain_decision(user_input): intent = agent.parse_intent(user_input) context = domain_service.resolve_context(intent) data_check = validator.validate_input(context) if not data_check.is_valid: return { "status": "INVALID_INPUT", "errors": data_check.errors } decision_request = request_builder.build( intent=intent, context=context ) model = model_builder.build(decision_request) solve_result = solver_service.solve( model=model, time_limit_seconds=60 ) if solve_result.status in {"OPTIMAL", "FEASIBLE"}: solution_check = solution_validator.validate( solution=solve_result.solution, context=context ) if not solution_check.is_valid: return { "status": "INVALID_SOLUTION", "errors": solution_check.errors } explanation = agent.explain( solution=solve_result.solution, tradeoffs=solve_result.objective_breakdown ) return { "status": solve_result.status, "solution": solve_result.solution, "explanation": explanation } if solve_result.status == "INFEASIBLE": return infeasibility_service.diagnose( model=model, context=context ) return { "status": "UNKNOWN", "message": "在给定求解时间内未找到可行方案，也未证明模型不可行。" }

这里有一个非常重要的工程细节：

UNKNOWN ≠ INFEASIBLE

如果 Solver 在规定时间内没有找到可行解，不能直接告诉用户：

当前业务没有可行方案。

只有求解器明确证明模型不可行时，才能进入不可行诊断流程。

十二、为什么还需要独立结果验证

求解器只保证：

结果满足模型中已经写进去的约束。

但模型可能漏掉业务规则。

例如：

某客户禁止拆单；
某危险品不能走某条运输线路；
某供应商尚未通过认证；
某订单已经发运；
某库存实际上处于质量冻结状态。

如果这些规则没有进入模型，Solver 给出的“数学可行解”仍然可能无法执行。

因此需要独立 Validator。

def verify_solution(solution, context): errors = [] errors += check_inventory(solution, context) errors += check_supplier_qualification(solution, context) errors += check_transport_capacity(solution, context) errors += check_frozen_shipments(solution, context) errors += check_customer_rules(solution, context) errors += check_budget_limit(solution, context) return errors

最终应形成：

Optimization Model ↓ Solver ↓ Candidate Solution ↓ Independent Validator ↓ Executable Solution

十三、动态供应链场景不要每次全量重算

供应链异常通常是局部发生的。

例如：

供应商S1延期

真正受影响的可能只有：

S1 供应的 SKU；
使用这些 SKU 的订单；
相关仓库；
相关供应商；
相关运输线路。

因此没有必要每次都重新优化整个供应链网络。

可以先计算影响子图：

Disruption ↓ Affected SKU ↓ Affected Order ↓ Candidate Warehouse ↓ Alternative Supplier ↓ Transport Lane

再构建局部优化问题。

这种方式有两个好处：

模型更小，求解更快；
新方案对现有计划的扰动更小。

十四、计划稳定性为什么重要

纯数学优化容易出现一种情况：

新方案目标值只改善一点，但大量计划被重新调整。

业务现场可能完全无法接受。

因此可以引入计划变更成本。

假设原计划中订单 $i$ 使用方案 $(w_i^0,m_i^0)$。

定义：

$$
h_{i,w,m}

\begin{cases}
0, & (w,m)=(w_i^0,m_i^0)\
c_i^{change}, & \text{otherwise}
\end{cases}
$$

于是目标函数会自然倾向于：

如果收益不明显，就不要随便修改已有计划。

还可以增加冻结区间：

已经发运： 完全冻结 未来24小时： 原则上禁止调整 24—72小时： 允许有限调整 72小时以后： 允许重新优化

这比每次异常都从零开始重新求全局最优更符合真实供应链。

十五、性能优化的几个关键手段

1. Warm Start

将当前业务计划作为初始解。

Solver 不需要从零开始搜索。

2. Rolling Horizon

不要一次优化未来几个月的所有细节。

可以：

近期： 高精度决策 中期： 聚合决策 远期： 容量级预测

然后随着时间滚动不断重新优化。

3. 分解问题

对于超大规模供应链，可以拆成：

采购 ↓ 生产 ↓ 库存 ↓ 运输

分别优化，再通过协调机制迭代。

4. 先构造可行解，再继续优化

工业系统通常更关心：

10 秒得到一个能执行的方案。

而不是：

等半小时证明它是数学最优。

因此可以设置：

第一阶段： 快速寻找可行解 第二阶段： 降低延期 第三阶段： 降低成本和计划变更 时间到： 返回当前最好方案

5. 限制重排范围

对动态异常，只重新求解受影响区域。

十六、预测模型应该放在哪里

预测模型非常重要，但它负责的是：

未来可能发生什么？

例如预测：

销量；
到货时间；
运输时长；
缺货概率；
供应商延期风险。

求解器负责的是：

知道这些以后应该采取什么动作？

因此更完整的数据流应该是：

历史与实时数据 ↓ 预测模型 需求 / ETA / 风险 ↓ AI Agent 构造业务场景 ↓ Model Builder ↓ Optimization Engine ↓ 决策方案 ↓ 执行 ↓ 实际反馈

预测与优化不是替代关系，而是上下游关系。

十七、算法自进化可以发生在哪里

所谓“算法自进化”，工程上并不意味着让大模型自动修改 Solver 源代码。

更现实的是以下几个方向。

1. 自动算法选择

根据实例特征：

变量规模 约束密度 网络结构 时间窗口数量 历史求解表现

自动选择：

Network Flow MIP CP-SAT LNS Hybrid Solver

2. 求解参数自适应

根据历史实例调整：

Time Limit；
搜索策略；
邻域大小；
MIP Gap；
初始解策略。

3. 初始解学习

利用历史优秀方案预测：

仓库分配；
供应商选择；
运输方式；
订单优先级。

预测结果不直接作为最终决策，而是作为 Solver 的 Warm Start。

4. 业务偏好学习

如果计划员长期反复修改 Solver 输出，例如：

宁愿增加少量物流成本，也不愿频繁调整仓库。

系统可以识别这种偏好，并建议调整目标权重。

但权重更新应经过离线验证和人工审批，而不是在线无限自动变化。

十八、常见技术误区

误区一：让AI Agent直接输出最终方案

自然语言结果无法严格保证库存、运输和交期约束。

Agent 更适合构造决策任务，而不是直接替代求解。

误区二：预测就是决策

预测告诉系统未来可能发生什么。

优化回答应该采取什么行动。

两者是不同问题。

误区三：目标函数越多越智能

把：

交期 成本 库存 利用率 稳定性 风险 碳排放

全部塞进一个加权目标，往往只会让模型越来越难解释。

应优先划分：

硬约束 一级目标 二级目标 偏好项

误区四：Solver没找到解就是业务不可行

错误。

必须区分：

INFEASIBLE

与：

UNKNOWN / TIME LIMIT

误区五：数学最优就是业务最优

业务还要考虑：

数据可信度；
计划稳定性；
人员执行成本；
管理偏好；
风险容忍度。

误区六：所有问题都应该使用Agent

如果输入固定、规则固定、流程固定，普通程序通常更稳定。

如果只是网络流问题，专用网络优化算法可能更高效。

Agent 真正的价值是：

判断当前问题应该调用哪种能力。

十九、一个可以落地的MVP

第一次建设供应链 AI Agent 时，不建议一开始就做“大而全”的数字供应链大脑。

可以分四个阶段。

第一阶段：数据统一

先统一：

Order SKU Inventory Supplier Warehouse Shipment

第二阶段：固定一个决策问题

例如：

供应异常后的订单重新分配。

不要同时做采购、生产、库存、运输全部优化。

第三阶段：建立固定模型模板

支持：

库存约束；
运输容量；
订单优先级；
加急成本；
冻结订单；
计划变更成本。

第四阶段：接入AI Agent

允许用户直接询问：

S1延期以后哪些订单受影响？ 如果必须保证客户A，会牺牲哪些订单？ 加急预算增加10万元能改善多少？ 为什么系统选择仓库W2，而不是W1？

这样即可形成一个完整的：

理解 ↓ 建模 ↓ 求解 ↓ 验证 ↓ 解释

闭环。

总结

供应链 AI 从“问答”走向“决策”，真正困难的地方不是让大模型知道更多供应链术语，而是让系统能够在复杂约束下稳定产生可执行方案。

一个更可靠的架构应该形成明确分工：

AI Agent 理解业务目标并组织任务 领域模型 统一订单、库存、供应商和物流语义 Model Builder 将结构化业务条件转换为优化模型 Optimization Engine 搜索满足约束的高质量方案 Solution Validator 独立验证结果是否真正可执行 业务系统 完成计划下发和实际执行

当问题规模继续扩大时，还可以进一步加入：