AutoStore秋季新品:每小时540订单行,非计划停机降35-45%

详细拆解

10月13日，AutoStore给仓储自动化配上了一组数字，而这几组数字具体到了值得拿来算一算的程度。FlexBinsPort一个工位通吃所有标准箱高，四季度上市，官方给的存储利用率提升是10%到15%；CubeFleet把实时的CubeAnalytics数据换成阈值告警，宣称非计划停机比固定保养少35%到45%；Pio Pal按机器人即服务交付，工位额定每小时最高540个订单行；AutoCase从2027年一季度开始接600×400毫米的箱。

四个数，四个率，没有一个是进出口方真正买的东西。你买的不是存储利用率，你买的是每天发出去多少订单行、每订单行多少钱，写在一年谈一次的费率表上。发布会上所有东西都是手段，手段只有在动了那个真正开票的数字时才算数。

所以在兴奋之前，先把这件事建模。密集立体库是一个穿着硬件外衣的排队系统：订单行按某个速率到达，工位是服务台，机器人的唯一任务是让箱子到工位的速度快过拣货员的消耗速度，而空间决定了你能放多少箱、挖一箱要挖多久。这么一看，问题就从「哪个产品最好」变成了「哪个参数动一格，整个系统就变样」。

发布日期是整篇通稿里最没人讨论、也最有用的一条事实。10月13日发布，距离旺季那堵墙大约六周，而没有哪个站点会蠢到在11月去改造一套正在跑的立体库。厂商选在这个时点发布，是因为采购对话发生在预算季，而安装发生在旺季之后。把日历老实读一遍，你得到的是这样一条链：2026年四季度下单，2027年一季度调试，2027年二季度才出现第一个干净的、可测量的收益季。

第二个信号藏在商业模式里。Pio Pal是按机器人即服务卖的，不是按设备卖的。当厂商把硬件挪到「按工作量计价」上，它其实在告诉你客户的资产负债表长什么样：大家宁可出运营费用，也不愿意再背资产。这是一条融资事实，不是技术事实，它改变的是你该谈什么——你买的不是一台机器，你买的是一个单价，而单价是可以重谈的。

谁会被波及？任何货物压在密集立体库电商仓里的进出口方，具体说是消费品、服装、小零件、备件，凡是SKU尾巴长、订单行短的那类货。如果你的货是整托进整托出、走常规配送中心，这四个数字今年明年都碰不到你的成本。如果你的货是一行一行拣进包裹里的，这四个数字迟早会落到你的费率表上，因为仓方的每订单行成本就是你的每订单行成本。

从排队工程师的起点开始：服务台。在货到人体系里，工位就是服务台，机器人车队只是喂料层，唯一职责是让箱子到达工位的速度快过拣货员的消耗速度。这两者之间有一个交叉点。在交叉点以下，工位空等箱子，你每加一台机器人都是净收益；在交叉点以上，机器人在工位前排起队，你每加一台机器人都是闲置的铁。厂商爱报机器人速度，因为速度好测。真正决定你成本的是工位节拍，而节拍属于拣货员、属于箱子呈现方式、属于工位的人机工程，不属于机器人。

把那个头条数字拆开，它拆起来很顺手。每小时540个订单行，等于每行6.67秒。工位不直接产出订单行，它产出的是「取箱次数」。每小时订单行数等于3600除以每次取箱的秒数，再乘以每次取箱拣出的行数。如果一次取箱20秒、平均每箱拣1.4行，这个工位每小时产出252行。要在20秒节拍下做到540，你需要每箱3行；要在1.4行的订单结构下做到540，节拍必须压到9.3秒。

这些输入没有一个属于厂商。每次取箱多少秒，由你的拣货方式和包装决定；每次取箱拣几行，由你的订单结构决定，而电商大多数是单行订单，这个数通常在1.2到1.8之间。这才是我要跟你争的那个参数。它没写在通稿里，它因客户而异，它能让最终数字差出一倍。把额定的540写进预算，而你的真实订单结构只能跑出250，那你等于把预算建在一个自己永远够不到的数上。

接下来是那条非线性，它决定了自动化的收益是跳变的，而不是按比例来的。假设一个站点12个工位、每天开16小时、每工位每小时300行，日产能是57,600行。如果你的峰值日是48,000行，利用率0.83，每个工位后面的队列难受但有限。把峰值推到53,000行，利用率到0.92。排队论里，服务台后的等待时间大致按rho除以（1减rho）放大，所以从0.83走到0.92，等待时间不是多11%，而是接近多2.4倍。硬件一点没变，一个参数动了，整个系统的行为就换了形状。

这就给你一条在花钱之前就能用的判断线。给工位装表，连续两周算峰值日最忙四小时的利用率。低于0.70，什么都别买，产能本来就在，问题在别处。0.70到0.85之间，买货位规划和排班，别买铁。高于0.85、且每天持续超过四小时，工位才真的是瓶颈，谈吞吐才有意义。我猜大多数站点会落在中间那一档，而中间那一档的建议是：一分钱都不用花。

存储那条数字值得单独拆，因为它最容易被读反。利用率提升10%到15%，听上去像白送的空间。在密集库里，空间不是白送的，空间是用「挖箱」换的。要取一个压在别的箱子下面的箱，得把它上面的箱子一个个吊出来、临时放好、再放回去。库填得越满，每次取箱的平均翻箱次数越高。同一个库现在多装了货，也多花了每订单行的机器人时间。密度和吞吐通过翻箱次数互相打架。

把账算出来，这笔交易才看得见。假设一个20,000箱位的库，当前占用率82%，提升10个百分点到92%，多出2,000个可用箱位。假设堆高带来的代价是每次取箱多翻0.7个箱，每翻一箱8秒机器人作业，合每次取箱多5.6秒。假设每天21,000次取箱，大致对应30,000个订单行、每行0.7次取箱。那就是每天32.7个机器人小时。按我假设的每机器人小时9美元（这是我的数，不是任何公开费率），翻箱税是每天294美元，一个月约7,644美元。

另一头，多出的2,000个箱位值多少，取决于你的仓储费率。按我假设的每箱每月0.35美元，它每月带来700美元。在我这套假设下，密度收益的代价大约是它回报的11倍。我不是说这个比值在你的站点成立，我是说那个0.7就是整场争论的全部，而所有报道里没人提它。去把你自己的真实平均翻箱数拉出来，CubeAnalytics本来就记着。低于0.2，密度这笔划算，拿走；高于0.5，你要的是吞吐不是密度，该去争工位和机器人速度。

下面这点我在FlexBinsPort的所有报道里都没见到，而它正是我最想在真实站点上验一次的东西。一个能吃下所有标准箱高的工位，它的服务时间分布比一个只吃单一箱高的工位更宽。均值可能一样，方差一定不一样：拣货员伸手取浅箱和深箱的动作不同，而随机箱高背后的挖掘深度，波动也比统一箱高大得多。排队论对方差很刻薄：M/G/1系统里的等待时间带一个「1加变异系数平方再除以2」的因子。把服务时间变异系数从0.3推到0.8，这个因子从约1.05走到约1.32。平均速度没变，工位后面多站了大约四分之一的队。服务台的灵活性是用方差买的，而方差是用等待时间还的。

这是个假设，不是实测，但它一个下午就能验完。在混箱高工位上记一千次取箱，在单一箱高工位上记一千次，各自算取箱时间的标准差再除以均值。如果混箱高工位的变异系数高出25%以上，说明这份灵活性正在吃你的排队时间，而解法不是庆祝新工位，而是把不同箱高分到不同工位上去。

停机那条数字需要同样的处理，先处理基准线。非计划停机比固定保养少35%到45%，这个对比的基准是「按日历做保养」，而这是能找到的最弱基准，因为按日历保养根本不看机器实际怎么被用。诚实的问题是：对照组到底是什么？如果站点本来就在做按状态保养，收益要打折。下一个问题是单位：这个降幅是停机小时、停机次数，还是「最终导致漏发的停机事件」？只有第三个才碰到你的每订单行成本。

还有一个系统性后果，只要把故障换成告警，它就一定会来。告警会生成工单。每一条提前触发的告警，都是一件得有人去干的活，得塞进某个窗口，用某个本来就排满的技师。加了检测却没加扳手时间，你并没有消除停机，你只是把它搬进了维修积压清单，并给它改名叫计划性停机。瓶颈从机器人故障迁徙到了技师可得性。把维修工单队列的长度和账龄跟停机数字一起看：如果停机在降、工单队列在涨，你是在向下一个月借钱。

停机下降到底值多少钱？假设非计划停机吃掉工位工时的3%，这是我的假设，不是公开数据。12个工位、每天16小时、26个工作日，合计4,992个工位小时每月，3%约等于150小时。降40%拿回约60个工位小时。按前面用的每工位小时300行，那是每月18,000行的产能回来。按我假设的每订单行0.42美元，这部分产能值7,560美元一个月，一年略超9万美元。这就是天花板。在我这套假设下，任何高于这个数的收费都是从你口袋挪到别人口袋。

AutoCase虽然要到2027年一季度才来，也值得占一段，因为它改的是工作单位。一个能处理600×400毫米箱的库，已经不再是纯粹的拆零拣选系统，它开始在同一批服务台上服务两类需求。整箱流是大块、可预测、单位工作耗时长的那类；拆零流是细碎、突发、单位工作耗时短的那类。把长服务时间的类和短服务时间的类混在同一批服务台上，是排队论里最老的题目：长作业占住队列，短作业继承它们的等待。如果站点让这两类走同一批工位，我会要求把整箱作业排进专用时段，而不是穿插着跑，否则拆零那一侧会替整箱那一侧背方差。

如果库根本不是你的瓶颈，上面这些就全都不相干，而对不少进出口方来说库确实不是瓶颈。你在意的是货离开仓库那一天，而那一天由整条链上最慢的那个工位决定，它可能是收货月台、打包台、包裹交接线，也可能是承运商当天的末班车。部署在打包瓶颈上游的自动化，只会给你在打包工面前堆一个更大的垛。在做任何事之前，先跑一遍运营里最便宜的诊断：旺季连续三天在车间里走一圈，记下在制品堆在哪儿。在堆的地方买产能。如果堆的地方不是拣选工位，这四个数字一个都碰不到你的成本行。

商业机制比工程更要紧，因为硬件大概率不是你买，是你的仓方买。你买的是费率，而费率只有在合同里写了才会降。续约时有两个条款值得要。一个是拣货费阶梯下调：实测每工位每小时订单行越过约定值，拣货费降一档，测量方法写进合同。另一个是仓方提升利用率时你的仓储费不许涨，否则密度收益被仓方拿走、由你出钱。如果仓方是按机器人即服务的模式接Pio Pal，记得问一句：当它的量没跑满约定时，你的费率怎么算——带保底的单行价会把一个淡月直接变成罚款。

还有一条商业细节通常发现得很晚。在机器人即服务模式下，设备是厂商的，遥测数据通常也是厂商的。如果你就是站点本身，你的运营历史躺在一份可以随时终止的合同里，而退出条款决定你能不能带走它。问清楚终止时你能拿到什么：原始节拍日志、翻箱次数、维修记录。没有这些，你没法为下一轮采购重建基准线，只会把同一个论证再买一遍。也要问清楚：如果在你的环境里跑不到额定吞吐，风险谁担——厂商材料里的额定值是在一条参考订单结构上测出来的，而你的结构不是那条参考结构。

在买任何东西之前，还有一个更便宜的动作，而它恰恰是大多数站点跳过的那一步。翻箱次数是货位规划的函数，不只是密度的函数。把走得最快的货放最上层、最慢的放最深处，平均翻箱就下来了，一台新机器人都不用加。代价是一个周末的分析加一周的叉车工时。坑在时点上：旺季绝不能重排货位，重排必须留回滚文件，因为一次糟糕的重排会让你比原样更糟。另一个方向是打到达率而不是打服务率：订单合流和截单时间能削平峰值，而削平峰值是从另一侧推同一个利用率数字，资本开支为零。

什么会让我改口？两个测量值。如果一个站点能拿出旺季期间持续高于450的每工位每小时订单行，且变异系数低于0.3，那瓶颈就不在工位而在机器人车队，Pio Pal的额定值就值得付钱。如果堆高之后平均翻箱数回报低于0.2，那密度收益基本是白送的，FlexBinsPort那条数字可以按字面收下。这两个都能在一个月内测出来。在测出来之前，这份发布只是在别人的参考订单结构上跑出的一组额定值，而付钱的是你的结构。

把日历拼起来，顺序其实很朴素。2026年四季度下硬件单，旺季之后安装，2027年一季度调试，2027年二季度才有第一个可信的测量值；费率表在2027年1月或者你的合同周年日改，哪个先到算哪个。如果你想让这些东西出现在2027年的费率里，对话必须发生在现在——2026年10月或11月——趁站点还在排资本计划、趁旺季还没把所有变更申请冻住。错过这个窗口，同一套硬件你要再等一整年。

先量化，再谈优化。这周去拿的两个数是：你自己站点的每次取箱拣几行，以及一天里最忙四小时的工位利用率。这两个数会告诉你540和10%到15%到底是不是你的数，而拿到它们不要花一分钱。发布会上其他所有东西，都排在它们后面。

↑ 返回核心要点

— 作者 拉维