这几年做自动化仓项目，我发现一个怪现象：WMS 厂商和 WES 厂商坐在一张会议桌上，聊接口、聊硬件都好好的，一聊到"任务到底谁来分"，两边就开始互相看对方，眼神里都写着同一句话——这活儿该你干。
散会之后，客户总会私下问我：老米，你说这到底归谁管？我一般先反问一句：你们合同里写了吗？十次有九次，答案是没有。没写，就对了。这篇文章要讲的三件事——波次释放、任务插队、异常拦截，恰恰是整个自动化仓里最容易扯皮、也最没人愿意认领的地带。
波次放行：WMS 定了调，WES 抢了麦
先说波次。传统逻辑很清楚：WMS 按订单优先级、承运商截单时间组波，一波一波往下放，WES 负责把每一波执行掉。一个定策略，一个干执行，听起来分工明确。
但 AMR 和穿梭车进场之后，事情变了味。WES 厂商会跟你说：我们能看到每台机器人的实时状态、每个巷道的拥堵情况，动态成波、动态释放，效率比 WMS 那种"定时放波"高得多。听起来很有道理，对吧？问题是，WMS 厂商不干：波次是订单策略，是履约承诺，凭什么你来定？
2023 年，南加州 Inland Empire 一个 20 多万平方英尺的电商仓，四五十台 AMR，上线后就卡在这儿。WMS 按承运商截单时间，每 20 分钟放一波；WES 那边呢，机器人上一波还没消化完，下一波已经压下来了。结果拣选员在巷道里等任务，机器人却在空转。两边开会，WMS 说我的波次逻辑没问题，WES 说你的释放节奏我跟不上。客户夹在中间，两边说的都像有道理。
我的判断很直接：波次的"策略"归 WMS——按什么规则组波、优先级怎么排，这是订单和履约的事；波次的"节奏"必须 WES 有话语权——一次喂多少、什么时候喂，得看设备的胃口。更准确地说，这件事没有"归谁"，只有"共管"。选型的时候就要把这句话写进两份合同：WMS 负责波次策略配置，WES 负责释放节奏控制，接口上 WMS 下发波次、WES 反馈实时消化能力。谁的字段、谁的逻辑，落到纸上。
插队任务：最烫手的山芋
插队任务，是我见过扯皮最凶的一块。场景大家都熟：客服一个电话打进来，某个大客户的急单，两小时内必须出库。WMS 里把订单标成最高优先级，推给 WES。WES 的销售当年拍胸脯说支持动态插队，真到上线，傻眼了：已经排好的任务序列，插一单进来要重算路径，整场效率往下掉。WMS 说我优先级已经标了，剩下的归你；WES 说你标了，可我执行不动。
2024 年，俄亥俄一家 3PL 的仓，旺季的时候一天插队几十次，高峰期几乎每小时都有。最后查下来，WES 根本没有插队独立通道，所有插队都走正常任务重排，系统越算越慢，正常订单也被拖下水。客户气得不行：买的时候你们可不是这么说的。
这件事的解法，我这些年总结下来有三条，缺一不可：插队权限归 WMS——谁可以插队、一天能插几次，得有配额，超过配额走人工审批，没有配额的插队就是灾难，WES 会被无限插队拖垮，这是物理规律，不是系统 bug；插队执行归 WES——要么预留产能，要么单独通道，保证插队任务不打乱全局节奏；插队任务的 SLA 写进合同——从下达到开始执行，最长不超过多少分钟，数字可以谈，但必须有。
异常拦截：智能系统装傻的地方
第三块，异常拦截。机器人卡住了、标签扫不上、重量校验不过——任务卡在半路，谁来拦截？谁来决定重试还是转人工？WMS 厂商的说法是：我是上层系统，异常应该 WES 先处理，处理不了再上报。WES 厂商的说法是：我只管设备执行，业务异常比如订单本身有问题，得 WMS 定。
听起来都有道理，实际呢？两边都不认的异常，就在系统里"消失"了。我经手过一个项目，上线头三个月，异常任务 WES 认为已经上报了，WMS 认为根本没收到。查了一个多星期，根子让人哭笑不得：WES 发的异常码，WMS 的字典里没有，接口直接丢弃。一单货在传送带上躺了两天，没人知道。
所以异常这件事，必须分两层。设备层异常——卡住、掉线、扫不上，归 WES，先自救：重试、绕行，实在不行再上报。业务层异常——订单取消、库存对不上，归 WMS 判定。中间必须有一张"异常码对照表"，两边签字画押，联调的时候逐条测。这张表，很多项目根本没有，接口调通了就以为万事大吉。记住：接口通了，不等于异常通了。
扯皮的根子，和写进合同的办法
说到这儿，扯皮的根子其实已经很清楚了。
先说 WES 的定义本身就是糊的。十年前 WMS 管一切，设备是哑巴；AMR、穿梭车起来之后，设备有了"脑子"，WES 应运而生。但 WES 的边界从来没有行业标准，每家厂商的 WES 功能范围天差地别——有的 WES 几乎是个小 WMS，有的只是个设备调度器。选型时你以为买的是同一个东西，其实根本不是。演示看起来都差不多，合同里写的可是两码事。
再说两边都在"优化"，但优化的目标打架。WMS 优化的是订单履约：准时率、截单满足率；WES 优化的是设备效率：机器人利用率、巷道吞吐。履约要"快"，设备要"顺"，天然冲突。波次、插队、异常，每一件事都是这两个目标的碰撞点。所以扯皮不是态度问题，是目标函数就不一样。
最要命的一条，合同里没写。SOW 里写"乙方负责任务分配模块"——WMS 的 SOW 里有这句话，WES 的 SOW 里也有这句话。重叠的边界加上模糊的措辞，等于扯皮的温床。
那怎么写进合同？我给客户的模板很简单，一张表，三列：事项、负责人、共管方。事项至少包括这八项：波次策略制定、波次释放节奏、插队权限与配额、插队执行通道、设备异常自救、业务异常判定、异常码字典维护、接口字段归属。每一项只写一个 owner，不写"配合"。写"配合"等于没写。
除了这张表，我还坚持加几条硬条款：联调验收标准写死——异常码对照表逐条测试 100% 通过，插队任务从下达到执行开始不超过 5 分钟，数字可以谈，但必须有个数字；异常码字典的维护责任明确到人，任何一方新增异常码，48 小时内同步对方；再加一条兜底——边界争议 48 小时内由客户方裁定，裁定之前两边不得停工扯皮。这一条，是我被坑过几次之后，加上就再也没拿下来过的。
回到开头那个会议室。下次 WMS 厂商和 WES 厂商再坐到一桌，聊到任务分配又开始互相看的时候，我一般会打断一下：别看了，合同第几页第几条，翻出来。边界这东西，开会吵是吵不清楚的，只能写清楚。写清楚了，两边该干嘛干嘛；写不清楚，上线之后每一单异常、每一次插队，都是一次新的扯皮。而扯皮的成本，最后都是客户在付。
