AI与自动化成为2026年供应链韧性的核心支柱

详细拆解

ABI Research 那份调查访问了 490 位供应链从业者，两个数字让我停了一下。65% 的受访者说，在决定采购什么技术时，AI 或生成式 AI 能力是重要或非常重要的因素；77% 的供应链正在考虑或已经部署 AMR、AGV 这类移动自动化。我的第一反应不是把它归入『AI 很火』那一栏，而是把它当成系统上的负载和产能数字来看。

把它想成一个队列。工作从队头进来：采购订单、到货、需要人拍板的异常。后面有一组被卡住的资源在消化这些工作：盯着屏幕的计划员、库房里的拣货员、路上的车、还有俯瞰整条线的控制塔。当进来的速度超过被卡住的资源能清掉的速度，队列就开始堆积。我们感受到的晚到、断货、加急运费，其实就是这个堆积。ABI 这两个数字不是人气投票，它是一个信号——被卡住的资源，大多是人，已经清不掉进来的活了，于是买家把自动化当成产能补充去抓。

我这些年在系统日志和算法里打转，这类报告最让我不舒服的地方，是它太容易被翻译成一句『该升级了』。一座控制塔或者一队 AMR，说到底只是队列里又一个资源。跟任何资源一样，它有利用率曲线，也有失效模式，而且它完全可能被部署到一个从来不是瓶颈的地方。这篇剩下的部分，我会像建模任何一次过载那样去建模 2026 年的韧性问题：先找到被卡住的资源，给它一个利用率的数字，然后再决定往里加什么。

先把报告点名的四个结构性 disruption 翻译成队列语言，因为这些词听起来像新闻标题，贴到负载曲线上才落地。地缘政治波动，是到达率的方差。多数计划系统都是按一个平稳的均值调的：我们预期大概这么多订单、这么多到货、这么多异常。真正要命的是方差。按均值定尺寸的队列，尾巴一来的瞬间就塌了，因为根本没有给尖峰留缓冲。你感受到地缘政治风险，不是作为一个平均值，而是作为『那一周方差翻倍』的那一周。

零部件短缺，是一台服务器半离线。想象你流程里有一个工位，过去按历史节奏收到某个子总成，现在只收到六成。下游工位开始挨饿。挨饿是堆积的镜面像：根因相同，都是产能错配，症状相反。你不是产能过剩，你是喂不饱，挨饿工位前面的队列空了，它后面的却卡住不动。

劳动力短缺是最干净的一种：被卡住的资源缩小了。拣货员或计划员流失快过补人，产能就掉到到达率以下，队列每个班次都在单调增长。这里没有谜团，就是一个数字越过了 1。安全合规要求，是一道服务时间税。每多插一道你必做的校验，就给每件货加了固定的处理时间。到达量不变，服务时间上去，吞吐下来。而且这道步骤你不能跳，所以守住吞吐的唯一办法，是在别处加产能来吸收这笔税。均值到达并没变，可更长的服务时间叠上方差，才是压垮你的东西，因为你以为还有的那点缓冲其实早没了。

这里有个报告列成四条子弹、队列却读成一层叠加重载的地方。四个 disruption 不是排队来的。地缘政治的方差，叠在新合规步骤拉长的服务时间之上，而此时劳动力已经缩水、某个关键零部件已经只剩六成。换算成队列语言，就是方差乘上更高的基础服务时间、再除以更小的产能。数字不是相加，是相乘，所以一条能分别扛住每个 disruption 的供应链，两个一起到就开始垮。2026 年的问题正是这种堆叠，不是任何单条标题。

现在看那两个调查数字，当成症状而不是排行榜。490 个受访者里，65% 大约是 319 人说 AI 或生成式 AI 对他们采购决策重要，77% 大约是 377 人在考虑或部署移动自动化。我把 77% 看得更重，因为它是一个运营信号——移动自动化直接在不加人头的前提下补了物理产能，它正面对的是劳动力短缺那个『被卡住的资源在缩小』的 disruption。65% 是决策支持信号：控制塔、生成式 AI 分诊，这类帮你应付地缘政治和零部件冲击带来到达方差的工具。两者都是产能采购，没有哪一个是『转型』，谁要是把 65 和 77 读成成熟度排名，我会反对。它量的是被卡住的资源已经饱和到什么程度。

对样本本身我留一个注脚，因为我本能地不信任太圆的调查数字。490 个受访者是实打实的样本，大到让 65 和 77 不算噪声，但它同时也是一批回答了『技术调查』的人，天然偏向本来就在逛工具的人。把方向当成稳的，把精确百分比当成地板而不是天花板。你自家运营里那些被卡住的资源，才是唯一该驱动你预算的数字。

在算账之前，先补一个报告模糊掉的区分。买工具和装产能不是同一件事。一座控制塔的授权本身不会缩短你的队列，它只是让你的队列变得可见。一张 AMR 的采购单本身不会多加拣货量，只有当它被映射到行走时间主导循环的那个区域，它才加拣货量。我把这个区分摆在眼前，是因为 65 和 77 描述的是意图，不是已装产能。这两者之间的缝隙，就是大多数韧性预算蒸发的地方。

我给劳动力这个情形算一笔账，免得空口白话，而且每个假设我都写出来，因为不写假设的算账只是口号。假设一个中型分销作业，单班八小时、每天处理 1 万行拣货。拣货是被卡住的资源。一个训练过的拣货员每小时清 150 行。要在八小时里清掉 1 万行，你需要 1 万除以（150 乘 8），也就是 8.3 个拣货员，算 9 个。现在加上劳动力短缺这个 disruption：假设有效在岗人数掉 15%，那你实际只有 7.6 个拣货员。利用率变成 1 万除以（7.6 乘 150 乘 8），大约是 1.16。一个跑到 116% 利用率的队列是不会稳定的，堆积每个班次都在涨，准时率直接跌穿地板。这就是把劳动力短缺表达成一个负载数字，而不是一句抱怨。

再看那 77% 的群体部署移动自动化。把一台 AMR 建模成一次产能补充：它从拣货员的一个循环里拿走大约每小时 40 行的行走和备货工作，约等于 0.27 个全职拣货员当量。十台 AMR 就是 2.7 个拣货员当量，把有效产能从 7.6 抬到 10.3。利用率掉到 1 万除以（10.3 乘 150 乘 8），大约 0.81。我会要求一个库房在站台利用率低于 85% 时才算『劳动力缺口补上了』。在这条线以下，队列才有界，准时率才守得住。这一步，正是那 77% 真正在买的东西：在瓶颈所在处补产能，而不是幻灯片上一个 logo。

瓶颈一旦点名，解药的选择就变简单，而简单正是重点。如果被卡住的资源是物理产能，一块屏幕帮不了你——再多的可见度也缩短不了一个缺拣货员的队列。那是劳动力情形，对应 77% 的答案，机器人。如果被卡住的资源是决策延迟，机器人也帮不了你——给一个没人分诊异常的队列加物理产能，只是把堆积搬到另一个工位。那是方差情形，对应 65% 的答案，控制塔。选错边是这里最贵的失误，因为两边都要真金白银，而只有一边碰到你真正的瓶颈。

在到达方差这一侧，那 65% 看重 AI 的人买的是决策支持，而真正值回票价的是一个带异常检测的控制塔。把它想成蹲在队列顶上的一个观察者，数着有多少件已经等过了它的服务等级窗口。要紧的 KPI 是异常漏检率：发生的所有异常里，有多大比例是在超过 SLA 之后才到人手里的。我会把这个压在 2% 以下。过了这条线，你是从客户那里、而不是从自己屏幕上发现问题的；一座控制塔如果连 2% 漏检都守不住，那它只是穿了塔名的外壳的一块看板。

为什么是 2% 不是 5%？因为漏检会随量复利。按月 1,200 票到货、8% 异常算，5% 漏检约等于每月 5 个异常晚到客户那里；2% 是 2 个。五个和二个晚发现之间的差别，就是你信不信一座控制塔的差别。阈值不是妆容，它是一个工具配不配叫这个名字的分界。

用写明的假设给它一个数字。假设一个站点每月处理 1,200 票到货。在一个 disruption 窗口里，假设 8% 会产生异常，也就是每月 96 个异常。人工检测通常只在一半以内、且在 SLA 内抓到，其余都是晚到的——靠客户投诉或没兑现的承诺才浮上来。一座带 AI 检测、把漏检压在 2% 以下的控制塔，最多只让这 96 个里大约 2 个溜过 SLA。这就是把整个价值主张写成一个阈值，而不是一句承诺。

生成式 AI 在这幅图里只配一个窄活：给每个异常草拟分诊建议，让计划员去批，而不是从零写。KPI 是人机闭环里的自动解决率——系统给出一条路径、计划员原样接受的异常占比。我会把目标定在至少 60% 原样接受，同时把人工改写率当成质量警报。如果改写率爬过 25%，说明模型在猜而不是在帮，你就把它退回『只建议』模式。人留在环里是故意的。我不是把异常队列交给一个模型然后走人。这条线，就是工具和负债之间的分界，也是最常被厂商 demo 悄悄跳过的部分。

我把『原样接受』定在 60% 而不是往上推到 90%，原因是剩下那 40% 正是计划员判断活着的地方，而那份判断是模型复制不来的。靠压低改写率换来的高自动解决率，只是说明人不再核查，不等于模型变聪明。看改写率，别只看接受率；两者合起来才告诉你这个闭环健不健康。

这个季度我会把它拆成三条工作流，每条都有负责人、触发条件和量化目标。第一条：四周内，在你货量最大的站点把异常检测立起来。负责人是你的控制塔或计划负责人。触发条件是，任意一周里靠人工发现的异常（也就是客户或滞后报告发现的）超过异常总数的 20%，因为到那一步漏检已经过了我 2% 的线。目标：季度末把漏检压到 2% 以下，按周测量。

第二条：在拣货循环里行走时间占比最大的那个区域，试点 AMR。负责人是库房工程负责人。触发条件是该区域站台利用率连续两周高于 90%。目标：季度内把该区利用率降到 85% 或以下，同时把每人每小时拣货行数至少提 15%。

第三条：给你前 50 个零部件建一条供应商风险信号流。负责人是采购系统。触发条件是任何一个单源零部件在 30 天内没有合格备选。目标：从事件到告警的风险信号延迟低于 4 小时，且季度末至少 80% 的关键零部件有具名备选。这些都不需要一个半年项目，它们只是各自画了一条线的负载测量。

一个实在的节奏能防止这事烂尾。第一二周用来给队列打基线，因为你没法给一个没量过的队列设阈值——控制塔负责人拉最近八周的异常日志，库房负责人拉分区域的站台利用率。第三四周只在最大的单个站点立检测，而不是全面铺开，因为窄部署能给你一份干净的漏检前后对照。AMR 试点和供应商信号流基于同一份基线并行跑。到第六周，你每条阈值都该有一个数，只有到那时你才决定要不要放大。

我最常看到的坑，是那个被写进汇报就忘掉的试点。一个团队跑六周 AMR demo，在演示区打出一个好看的数字，宣布胜利，却从不对全站利用率做仪表化。demo 证明了机器人能搬箱子，没证明队列变短了。在放大之前，前置条件就是数据质量。一座控制塔好不好，只看它底下那根事件流。如果你的仓储系统给异常打的时间戳误差以小时计，你的 SLA 钟也就误差以小时计，那 2% 漏检目标就成了噪声。先把事件流修好。AI 是这件事最后百分之十，不是开头。

我会把事件流清理单独立成一个有 KPI 的 tracked 项目，因为它是决定上面那件贵价工具到底管不管用的、不体面的苦活。我会在那道线上守的阈值是：异常事件的时间戳精度在 15 分钟以内；如果你的仓储系统不能在异常发生后 15 分钟内告诉你它开了，那建在它上面的控制塔只是在给一团雾做装饰。先量这个，按周报，别让 AI 预算跑赢了数据质量预算。

这出完全相同的失败我看过三次。演示区被选中，是因为它干净、人手足、本来就是表现最好的区域，于是 AMR 显得漂亮，而它对照的基线本来就健康。别处的队列一动没动。解法是挑最差的区域做试点——就是那个利用率触发了项目的区域——并且把全站利用率当成主指标来报，而不是演示区产能。只要全站利用率没动，不管演示区多闪，试点就是失败的。

还有定错阈值的代价，而且它很少是零。把站台利用率放得太松，比如 95%，你会在检查里通过，而队列仍在两次测量之间悄悄增长，因为接近满负荷的利用率不给下一次方差尖峰留任何缓冲。把 AMR 的 KPI 设成『只要产能有提升』，你就会把机器人部署到从来不是瓶颈的区域，把资本花在不能缩短队列的地方。这条笔记里每一个阈值，都是队列上一个负载数字。

动它，你动的是产能，不是妆容。还有一句关于算法本身的安静提醒：它受自己的训练和喂给它的数据所限。它不会凭空发明一个你没录入的供应商，事件时间戳要是错了，它会很自信地把异常分错路。把它当成一个永不睡觉、也绝不质疑数据的快进初级分析师——有用，而且恰恰在你停止核查它输入的那个程度上危险。它是系统里的一个零件，不是系统本身。

当 ABI 那份报告落到你桌上、有人跟你说该『看看 AI 了』，别从那儿起步。先看你的队列。找到那个跑到 100% 以上的资源，把它大声念出来。然后再决定解药是一台机器人、一块屏幕，还是加一个班次，并且用那条真正给队列设界的阈值去衡量每一个。先量化，再谈优化。

↑ 返回核心要点

— 作者 拉维