摘要大语言模型进入供应链系统后最容易实现的是知识问答、报表总结、风险解释和系统查询。但当问题从“发生了什么”进一步变成“接下来应该怎么做”系统就开始面对库存、产能、运输、交期、成本和计划稳定性等大量相互耦合的约束。这类问题本质上属于约束满足与组合优化仅依赖大语言模型难以稳定生成可执行方案。一种更可靠的技术路线是由 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}\leI_{w,k},\qquad\forall w,k$$3. 运输容量约束在简化的单周期模型中$$\sum_i\sum_wq_i y_{i,w,m}\leU_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( intentintent, contextcontext ) model model_builder.build(decision_request) solve_result solver_service.solve( modelmodel, time_limit_seconds60 ) if solve_result.status in {OPTIMAL, FEASIBLE}: solution_check solution_validator.validate( solutionsolve_result.solution, contextcontext ) if not solution_check.is_valid: return { status: INVALID_SOLUTION, errors: solution_check.errors } explanation agent.explain( solutionsolve_result.solution, tradeoffssolve_result.objective_breakdown ) return { status: solve_result.status, solution: solve_result.solution, explanation: explanation } if solve_result.status INFEASIBLE: return infeasibility_service.diagnose( modelmodel, contextcontext ) 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 Solver2. 求解参数自适应根据历史实例调整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 独立验证结果是否真正可执行 业务系统 完成计划下发和实际执行当问题规模继续扩大时还可以进一步加入预测模型知识图谱本体求解器自动选择参数自适应大邻域搜索分解算法。但无论技术栈怎样变化一个核心原则不会改变大语言模型擅长理解模糊问题优化算法擅长解决确定性约束。真正有价值的工业 AI并不是让其中任何一种技术取代另一种技术。而是让 Agent、数据、数学模型和专业求解算法形成完整的智能决策闭环。#晞德求索 #智能决策 #供应链管理 #工业软件 #大模型 #AIAgent #求解器
供应链Agent决策架构
摘要大语言模型进入供应链系统后最容易实现的是知识问答、报表总结、风险解释和系统查询。但当问题从“发生了什么”进一步变成“接下来应该怎么做”系统就开始面对库存、产能、运输、交期、成本和计划稳定性等大量相互耦合的约束。这类问题本质上属于约束满足与组合优化仅依赖大语言模型难以稳定生成可执行方案。一种更可靠的技术路线是由 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}\leI_{w,k},\qquad\forall w,k$$3. 运输容量约束在简化的单周期模型中$$\sum_i\sum_wq_i y_{i,w,m}\leU_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( intentintent, contextcontext ) model model_builder.build(decision_request) solve_result solver_service.solve( modelmodel, time_limit_seconds60 ) if solve_result.status in {OPTIMAL, FEASIBLE}: solution_check solution_validator.validate( solutionsolve_result.solution, contextcontext ) if not solution_check.is_valid: return { status: INVALID_SOLUTION, errors: solution_check.errors } explanation agent.explain( solutionsolve_result.solution, tradeoffssolve_result.objective_breakdown ) return { status: solve_result.status, solution: solve_result.solution, explanation: explanation } if solve_result.status INFEASIBLE: return infeasibility_service.diagnose( modelmodel, contextcontext ) 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 Solver2. 求解参数自适应根据历史实例调整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 独立验证结果是否真正可执行 业务系统 完成计划下发和实际执行当问题规模继续扩大时还可以进一步加入预测模型知识图谱本体求解器自动选择参数自适应大邻域搜索分解算法。但无论技术栈怎样变化一个核心原则不会改变大语言模型擅长理解模糊问题优化算法擅长解决确定性约束。真正有价值的工业 AI并不是让其中任何一种技术取代另一种技术。而是让 Agent、数据、数学模型和专业求解算法形成完整的智能决策闭环。#晞德求索 #智能决策 #供应链管理 #工业软件 #大模型 #AIAgent #求解器