字数：约 6,514 字｜预计阅读：12 分钟
微信简介建议： OSI 模型真正有用的地方，不是七个名词，而是一个旧直觉——复杂系统出问题时，别只盯着最上面那层界面。
一家做消费电子出口的公司，花了大半年选型部署了一套供应链 AI 系统。演示日效果惊人：左边实时显示在途订单，右边自动弹出异常预警，中间有个对话框——打字问"深圳仓 SKU-3172 库存多少"，三秒钟出答案。VP 当场拍板推广到全部区域。
推广没发生。
运营中发现，库存数据来自一张凌晨同步一次的快照表。仓库系统和 ERP 的物料编码不统一。承运商状态只有"已发货""已签收"两种，货在港口停了八天，系统里没有任何信号。供应商交期录的是合同天数，不是实际天数。
AI 的回答依然流畅。它建议"从备用供应商紧急调货"，但系统里没标注那个供应商上次延误三周、已经被客户拉黑了。它建议"将订单拆分到两个仓发货"，不知道其中一个仓的库存已经被另一个大客户锁定。
答案在语义上合理，在运营现场不可用。
我过去一年接触到的供应链 AI 项目，凡是卡住的，大多不是卡在模型上——模型确实比两年前强了很多。它们卡在应用下面那些看不见的地方：数据口径、系统通信、业务上下文、关系推理、权限和行动写回。
模型是最上面那一层。很多企业买到的也只是最上面那一层。
一个 1984 年的旧直觉
把这件事讲清楚，需要借一个老东西。
1984 年，国际标准化组织发布了 OSI 参考模型，把通信系统拆成七个抽象层，从最底下的物理层到最上面的应用层。今天实际跑的互联网协议栈并不严格按这七层走，TCP/IP 只用四层，很多协议跨层工作。OSI 作为施工图纸早就过时了。
但它到现在还被广泛使用。
原因很实际。Cloudflare 在解释 OSI 模型时讲过一个朴素的道理：它最大的现实价值，是帮人在网络出问题时缩小排查范围。Wi-Fi 连着但网页打不开，你知道问题大概不在物理层，可以跳过检查网线那一步，往上几层去找。所有应用都断了而不只是一个网站，那问题大概也不在应用层。
分层不是为了好看。分层是为了出故障时，让你少走弯路。
供应链不是网络协议栈，硬套七层蛋糕图只会误导。但"分层排查"这个直觉，在供应链 AI 项目里异常管用。
Logistics Viewpoints 的一篇分析提过这个判断：供应链 AI 更像一个架构问题。公司最容易买到的、老板最容易签字的，是应用层——copilot 对话框、控制塔界面、风险仪表盘。但决定这些应用能不能从演示走进运营的，是下面的结构。
那篇文章把供应链 AI 拆成五层来理解：数据层（data）、通信层（communication）、上下文层（context）、推理层（reasoning）、应用层（application）。
和 OSI 七层不是一一对应关系。只是用了同一个直觉：应用层表现不好，别只怪应用，往下看。
数据层：数据不是少，是各说各话
一家典型的中等规模制造企业，数据散在这些地方：ERP 的物料主数据和订单、WMS 的库位和库存、TMS 的运单和承运商状态、供应商通过邮件或 EDI 回传的交期确认、港口和海关的公开运行数据、IoT 传感器采集的温度和设备状态，以及天气、政策之类的外部风险数据源。
量不是问题。
WMS 里叫"良品"的状态，在 ERP 里叫"可用库存"，口径不同——一个含质检暂存，一个不含。TMS 里"已提柜"意味着货在路上了，ERP 发货状态还停在"待发"。供应商在邮件里确认"可以提前五天交"，这个信息从来没有进入过任何系统字段。
这跟普通的业务报表问题不是一个量级。
一个 SaaS 公司做 BI 报表，数据大部分来自自家产品数据库，格式统一、时区统一、ID 体系统一，口径没那么分裂。供应链的数据天然分散在不同公司、不同国家、不同系统架构的组织手里。你公司的 ERP 是十年前实施的 SAP，仓库用的是本地供应商的 WMS，承运商给你的只有 EDI 报文或一封邮件，港口的数据格式跟你的字段完全对不上。每换一个供应商、每新开一个市场、每接入一个物流商，就多一套口径。不是先治理再上线的问题——治理本身就是一个持续追赶的过程，因为供应链的参与方一直在变。
AI 模型接的是这样的底座。它不知道自己读到的库存数是不是已经被锁定的，不知道承运商状态是十分钟前的还是昨晚的，甚至不知道"供应商编号 V-3027"在 ERP 和采购系统里分别叫两个名字。
Gartner 在供应链 AI 路线图中把"稳固的数据基础"列为关键前提，具体包括数据质量治理、数据湖仓和 data fabric 架构。data fabric 的思路值得说一下：它不要求企业推倒所有系统搬到一个中央平台，而是在现有系统之上铺一层统一的数据访问和语义标准——底下是私有部署的 ERP、云端的 WMS、还是二十年前的老系统都行，外面看一套口径。Gartner 的说法是，data fabric 可以连接分散在云上、本地、新旧系统间的供应链应用，让首席供应链官使用一致、可信、实时的数据来支撑 AI 扩展。
听起来稀松平常。但大部分挂掉的供应链 AI 项目，就败在这里。模型脚下的地板是碎的，上面怎么走都费劲。
通信层：不是人问 AI，是系统与系统之间怎么说话
很多人想象的供应链 AI 场景是这样的：一个人打开界面，问 AI 一个问题，AI 回答。像聊天。
实际运营不是这样。一个跨国订单从下达到交付，经过计划、采购、工厂、质检、仓储、报关、运输、目的港、末端配送、客服、财务。这些环节各自有系统，有些是公司内部的，有些是供应商或物流商的，有些跑在第三方平台上。
如果 AI 只在自己内部系统里转，它不知道工厂排产变了，不知道承运商临时换了船期，不知道港口因为台风封了两天。
Google 2025 年 4 月发布 Agent2Agent 协议（A2A），背景很直接：企业越来越多地用自主 agent 来支撑业务流程，包括供应链计划、采购执行和物流调度。但这些 agent 分属不同供应商、不同框架、不同系统，彼此间没有通用的沟通方式。A2A 建在 HTTP、SSE、JSON-RPC 等已有标准上，提供能力发现、任务管理和协作机制，让不同的 agent 可以跨系统找到彼此、交换信息、协调动作。
翻译成供应链里的具体场景：你公司的计划 agent 发现需要提前两天发货。它需要知道承运商那边的运输 agent 能不能响应。承运商的 agent 接到请求后确认船期和空间，把结果写回你的系统。这个来回不需要人在中间传话。
没有通信层，AI 就变成一堆彼此不说话的独立助手。每个都很聪明。计划部门的 AI 不知道仓储部门的 AI 已经发现了缺货。运输那边的 AI 不知道客户那边的 AI 已经答应了新交期。每个 agent 在各自正确的前提下独立决策，拼在一起一塌糊涂。有时候比没有 AI 还混乱，因为它们各自行动得更快了。
上下文层：说得通不等于推得动
这是很多项目里最隐蔽的断裂点。也是最容易被误解的一层——很多人以为上下文就是多给模型塞资料，建一个大而全的知识库。不是这样。
供应链运营里的上下文是一组非常具体的约束和记忆：
这个供应商上次延误三周，原因是它的二级供应商工厂失火，不是自身产能不足，这次的情况不同。这个客户虽然订单金额不大，但它是某个战略大客户的关联方，交期敏感度极高。这个仓库的 500 件库存系统里显示"可用"，其中 300 件已经被销售锁定、等待另一个订单确认。上一次走这条海运航线，清关多等了四天。替代料号已经有了，但质量认证还没完成，不能直接替换。
这些信息在运营人员的脑子里，在某些人的邮件往来里，在某个已经离职的人留下的 Excel 批注里。但它们不在系统的结构化字段里。
没有这些，AI 给出的建议语义上完全合理。"建议从备用供应商紧急采购"——逻辑清楚，语句自信。运营人员一看就知道不对，那个供应商正在被客户审核整改，现在根本没法用。
这里有个恶性循环：运营人员看了两三次这种"逻辑正确但运营荒唐"的建议后，就不再看了。AI 不是被公司关掉的。它是被一线冷掉的。界面还在，每天还生成一堆建议，只是没人点开。
这种冷掉比上线失败更难被管理层发现。系统的使用量报表可能还不错，因为有人登录进去看别的功能；但 copilot 建议的采纳率是零，只是没有谁在追踪这个数字。
上下文层要解决的不是信息量问题，是业务连续性问题——AI 需要像一个在场一年、知道哪些坑不能踩的运营人员那样理解现场。当然，今天的技术做不到完全还原人脑的隐性判断，但至少那些可以结构化的约束——锁定库存、供应商黑名单、客户优先级、异常历史、审批链条——应该在系统里有结构化的记录，能被模型读到。
Anthropic 发布 MCP（Model Context Protocol）时描述过一个问题：即使大语言模型能力在增强，它们仍然会被数据孤岛和遗留系统限制。AI 助手对接不同数据源和工具，如果每个都做一套定制化对接，很难规模化。MCP 是一个开放协议，让 AI 应用可以标准化地连接外部数据源和工具，支持资源读取、工具调用和提示模板，使用 JSON-RPC 2.0 通信。
但 MCP 文档里反复强调的一点常被忽略：安全、授权和工具调用风险。
对供应链来说这是核心问题。上下文层除了给模型提供信息，还得管住谁有权看什么、谁有权执行什么。计划经理看到的库存和销售看到的库存可能需要不同的展示口径。采购能发起紧急订单，但审批链条里必须经过财务。仓库可以调拨，但跨区域调拨需要总部同意。
如果上下文层缺失，AI 要么什么都不知道，给出空洞的建议；要么什么都知道但没有权限边界，给出在组织里推不动的建议。它说的每句话都对，但没有人能按它说的去做。
这一层解决的是"AI 能说"到"组织能动"之间的距离。很多项目低估了这段距离。
推理层：供应链是网络，不是列表
这一层容易被高估，也容易被低估。
高估，是因为很多人觉得"AI 推理能力"是全部——只要模型够聪明，别的都能补上。低估，是因为很多实际部署的供应链 AI 根本没用到适合这类问题的推理方式。
供应链天然是一个网络结构。一个终端产品的物料清单可能牵涉二十家以上的供应商。一个港口拥堵可能影响三个洲的交付。一家工厂排产变化会推倒下游五个环节的时间表。
但很多 AI 拿到问题后的做法是平面的：去文档库或数据库里找最相关的文本片段，拼一个回答。这是基础 RAG（检索增强生成），在很多场景下有效——比如回答产品手册里的问题、查找合同条款。在供应链里，仅靠找几段相关文本，回答不了"这个延误会影响谁、影响多少层、替代路径在哪里"。
Microsoft Research 的 GraphRAG 项目走了一条不同的路：用图结构组织信息。从数据中抽取知识图谱，构建层级化的节点和社区关系，生成摘要，再用这个结构化的图来做检索和生成。它不靠语义相似度找片段，而是沿关系链条追踪上下游影响。
供应链本身就是一张图。供应商连着工厂，工厂连着仓库，仓库连着客户，客户连着回款，回款连着下一轮采购决策。每个节点出问题，影响沿着边传播。一个理想的推理层，应该能让 AI 理解这张图：港口拥堵→这三条航线受影响→这两个客户的订单会延迟→其中一个客户有替代仓可以走陆运→但陆运成本增加 12%→这个成本谁承担需要确认。
今天能做到这一步的供应链 AI 项目不多。大多数停在"找相关文本、生成流畅回答"的阶段。不是基座模型能力不够。是数据有没有被建成图，关系有没有被抽取出来，推理在结构上有没有被支撑。
应用层：最容易被看见，也最容易制造错觉
终于到最上面了。
控制塔、计划工作台、copilot 对话框、自动排产建议、风险仪表盘、异常自动升级、供应商协同门户——全是应用层。用户看得见，老板能看，投资人参观时能看，采购选型时最先比的也是这些：界面好不好看，对话顺不顺，演示里解决了什么问题。
这也是为什么应用层最容易制造错觉。
演示时用的数据是供应商准备好的。编码是统一的，口径是一致的，状态是实时的，异常记录是完整的——这些条件在真实企业里往往不存在，但在演示环境里都满足了。对话框里的回答精准、自信、没有矛盾，因为底下那几层已经被手工铺好了。
采购决策者看到的是"这个 AI 能回答复杂的供应链问题"，看不到的是"它在我们自己的数据上能不能回答同样的问题"。签约拍板的依据是应用层的表现，但交付能不能成功取决于下面四层的现状——而这四层在签约前很少被认真评估过。
常见的故事是这样的：AI 供应商来演示，效果惊人。签约部署后发现接入真实数据要半年。接完数据发现口径不一致，又要清洗。清洗完发现系统之间不通信，要做集成。集成做完发现业务上下文——客户优先级、锁定库存、供应商黑名单、审批权限——在系统里根本没有结构化。每推进一步，就掉进下面一层的坑里。
最后那个漂亮的控制塔还在，对话框还在。但它能回答的真实问题越来越少。
从应用层开始很自然——它最可见，最容易立项，最容易让各层级看到"我们在用 AI 了"。从应用层开始不是问题。把应用层当成全部才是。
控制塔不是供应链的大脑。它只是一块屏幕，把下面几层的能力投射出来。下面的图是清晰的，屏幕上就清晰。下面是糊的，屏幕上再好看也只是一张静态画。
不是推倒重来的故事
写到这里要说一句。这篇文章不是在论证供应链 AI 不能用，也不是建议所有企业暂停采购。
分层视角的价值在于：让你知道已经有了什么、缺了什么、下一步该补什么。
也许你的数据层其实做了八成——ERP 和 WMS 已经打通，主数据治理做了几年，编码大部分统一了。那接下来可能该把承运商和供应商的实时数据拉进来，在通信层推一步。
也许通信基本没问题——API 都接好了，EDI 跑了几年。瓶颈在上下文层：系统里没有记录异常历史、锁定状态和权限矩阵，AI 给的建议逻辑上通但组织里推不动。
也许什么都还没有，刚开始看供应链 AI。那至少在评估供应商时，除了看演示界面，多问几个下面几层的问题。
五个可以直接用的问题
这张检查表不需要技术背景。评估项目、与供应商对话、内部立项或做中期复盘时，逐条过一遍。
① 数据层：AI 接的是什么样的数据？
它读取的是实时、统一口径的运营数据，还是每天同步一次的展示库？ERP、WMS、TMS 和供应商数据之间，物料编码、库存口径、状态定义统一了没有？有没有接入外部数据——港口状态、天气、政策、市场价格？
如果数据层是过时的快照，上面的应用再好看也是静态画面。
② 通信层：建议能变成跨系统的动作吗？
AI 给出建议之后，这个建议能不能自动写回 ERP、触发采购流程、通知承运商调整运输计划？还是只能显示在屏幕上，等人手工复制粘贴到另一个系统里？
只能生成建议不能行动的 AI，是一个高级报表。
③ 上下文层：AI 知道组织里的约束吗？
它知不知道这个供应商上次为什么延误？知不知道这批库存已经被锁定？知不知道这个客户是战略客户、交期不能滑？知不知道替代料号的质量认证还没过？权限标了没有——谁能看什么，谁能批什么？
没有上下文的 AI 建议，运营看两次就不会再看。
④ 推理层：它能追链还是只会报点？
当一个供应商延迟交货，AI 能不能追踪到受影响的订单、客户承诺、在途库存和替代方案？还是只能告诉你"供应商 V-3027 延迟了"这一个点？
供应链是网络。只报点不追链的 AI 在复杂异常面前接近没用。
⑤ 应用层：界面背后有什么？
控制塔好看，copilot 会说话。多问一声：数据从哪来？更新频率多少？系统之间怎么通信？上下文怎么保持？推理跑的是全文检索还是结构化知识图谱？行动怎么写回？
如果这些问题的答案是"不清楚"或"后续再做"，应用层大概率会停在演示阶段。
回到开头那家消费电子出口公司。他们没有放弃那套 AI 系统，但调整了计划：先用三个月补数据层——统一物料编码和库存口径，把承运商和港口数据拉进来做实时同步。然后开始做系统间的通信，先不追求全自动，至少让计划系统能读到仓库和运输的最新状态。
copilot 还没有重新上线。
这看起来像倒退。做下层的人知道，这是在往可以运行的方向走。
你们公司那套供应链 AI，上一次有运营人员认真采纳它的建议，是什么时候？如果你需要想很久才能回答这个问题，不妨从第一层开始往下查一查。
*免责声明：本文不构成任何证券买入、卖出、持有建议，不提供目标价或收益承诺。文中提及的公司、产品、协议和技术项目仅用于说明产业结构和技术机制，不代表推荐或背书。*