说白了，WCS 任务仲裁这件事，拼的不是设备有多快，而是多台设备同时伸手要货的时候，WCS 到底先给谁。绝大多数仓库这个问题是糊弄过去的——默认先进先出（FIFO），看起来公平，结果在高峰时直接把 15% 到 20% 的产能吃掉。我见过太多项目，设备选型单上全是高端货，联调却栽在这个看似不起眼的小逻辑上。
这事分两面：给错设备优先级，轻则效率打折，重则整条线瘫痪。我亲历的两个坑，都和"同时要货"有关。
第一个坑在俄亥俄州哥伦布市的一个电商履约仓，2023 年旺季前上线。布局是这样的：三台连续式提升机从三层穿梭库往外吐货箱，全部汇入同一条主干输送线，再进环形分拣机。提升机单台额定每小时 450 箱，合计 1350 箱/小时；分拣机能力每小时 1600 箱。纸面算，产能绰绰有余。
上线第一周就出事了。合流点的仲裁用的是最简单的 FIFO——谁先到谁先进主线。问题是，三台提升机吐货的节奏完全不一致：A 机负责的货区订单密度高，吐货又急又密；B、C 机时快时慢。FIFO 之下，A 机的货箱把合流点塞得满满当当，主线输送带上全是 A 的箱子。B、C 机吐出来的箱子在合流点排队，最长等了 40 多秒，后面的箱子一路顶到提升机出口，提升机被迫停机。更要命的是，分拣机那头一直在等 B、C 机的货——那两个货区的订单大多是当日截单的急单，SLA 卡着下午 4 点发走。结果分拣机转着转着就断流了，利用率掉到六成多。
现场工程师第一反应是"提升机不够快"，差点又下单一台提升机。叫停之后我们看了一下午的 WCS 日志，结论很扎心：设备一台都不缺，缺的是仲裁逻辑。FIFO 只讲先来后到，完全不管这三个任务背后的订单截止时间、也不管分拣机正在挨饿。改法很直接：仲裁从 FIFO 换成"截止时间加权"——每个任务带上它归属波次的截单倒计时，截单越近的任务优先级越高；同时给每台提升机设一个最低保障配额，防止某台机被彻底饿死。上线当晚，同样的订单量，分拣机利用率回到九成以上，急单准时发走率从 91% 拉回 99% 以上。
第二个坑在印第安纳波利斯的一个服装退货仓，2021 年的事，更有意思。这个仓没有提升机，是两条退货质检线各带一条输送机，汇入一条主干进打包区。两条线同时要货的场景是每天下午 2 点到 4 点的退货高峰。原来的仲裁是"静态优先级"——1 号线永远优先于 2 号线，因为 1 号线处理高价值商品，管理层拍脑袋定的。
静态优先级的毛病是：它在设计时是合理的，在运行时是僵化的。高峰时 1 号线几乎不停，2 号线的货箱在合流点一等就是几分钟。退货质检是按件计时的工位，2 号线的质检员没货可检，站在那儿刷手机；1 号线的质检员忙到飞起，错检率往上走。更讽刺的是，2 号线处理的虽然是低价值商品，但它的退货周转直接关系到二手平台的上架速度——那部分毛利其实更高。一个月下来，2 号线的人均处理量掉了三成，两个班组差点打起来。
这个坑的解法不是换更复杂的算法，而是加一条"饥饿熔断"：任何任务在合流点等待超过 90 秒，优先级自动提到最高，插队一次。逻辑简单到 PLC 里几行就写完，但效果立竿见影——2 号线再也没有长时间断流，两条线的负载差从 3:1 收敛到接近 1.2:1。
讲完坑，拆一下常见的仲裁策略。我把现场见过的五种做法列个表，对比它们的代价和适用场景：
| 策略 | 逻辑 | 优点 | 代价/风险 | 适合场景 |
|---|---|---|---|---|
| 先进先出 FIFO | 谁先到合流点谁先走 | 简单，PLC 里最好实现 | 高峰时某条线会垄断主线，其他线饿死 | 流量均衡、各线节奏接近的场合 |
| 静态优先级 | 写死 1 号线 > 2 号线 | 确定性强，好排障 | 低优先级线高峰时长期断流 | 各线价值差异极大且流量稳定的场合 |
| 截止时间加权 | 按订单/SLA 倒计时动态排序 | 保急单，旺季救命 | 需要 WCS 能拿到订单维度的实时数据 | 电商履约、多波次截单的仓 |
| 饥饿感知轮询 | 轮流放行，等待超阈值自动提权 | 公平，防饿死 | 极端高峰下整体吞吐略低于纯吞吐优先 | 多线并行、人工工位在下游的场合 |
| 吞吐最大化 | 每次选切换成本最低的任务 | 单位时间过货量最高 | 可能系统性牺牲慢线，公平性最差 | 纯过货、无 SLA 压力的中转枢纽 |
选型的取舍在这儿：没有一种策略是免费的。FIFO 免费的是开发成本，贵的是高峰产能；截止时间加权保住了 SLA，贵的是 WCS 和订单系统的数据对接；吞吐最大化数字最好看，贵的是慢线工位的怨气。我的建议是，先看你的瓶颈到底是什么——是怕急单发不走，就用截止时间加权；是怕某条线饿死，就加饥饿熔断；两条都怕，就组合用。千万别一上来就写最复杂的算法，复杂度本身就是故障源。
还有一个容易被忽略的点：仲裁到底该放在哪一层。我见过不少项目把仲裁逻辑写进 PLC，理由是响应快。PLC 做毫秒级的互锁没问题，但仲裁是策略问题——它需要订单截止时间、波次状态、设备健康度这些上层数据，PLC 根本拿不到。正确姿势是分层：WCS 负责策略，每 1 到 2 秒算一次各任务的动态优先级，下发给 PLC；PLC 只负责执行，在合流点按收到的优先级放行，遇到光电开关异常这类毫秒级事件自己先保安全。分层之后还有一个好处：策略可以在线调参，旺季切一套参数、淡季切一套，不用停机改 PLC 程序。把策略和执行混在一起，是很多仲裁逻辑越调越乱的根因。
还有一个反常识的判断，很多人第一次听不服气：有时候，故意让最快的设备"饿一会儿"，整体吞吐反而更高。原理不复杂——合流点的瓶颈不在单台设备速度，而在主线输送带的连续流。一台 450 箱/小时的提升机如果独占合流点，主线会被它的货箱打成一段一段的断流；反而是让它等 10 秒、让另外两台的箱子先插进来，主线的货流更均匀，分拣机导入口的利用率更高。局部最优加起来，经常等于全局最差。WCS 仲裁的本质，就是在局部最优和全局最优之间做取舍。
最后给一句忠告：WCS 仲裁逻辑写完只是开始，一定要拿真实高峰的 WCS 日志回放验证——看合流点每台设备的等待时长分布，看有没有长尾等待，看 SLA 订单的实际放行顺序。纸面逻辑再漂亮，顶不过一次真实高峰的回放。调不好的现场症状都写在日志里，就看你愿不愿意看。
作者：老米｜20年美国供应链老兵，仓储解决方案顾问
