说白了，立库（ASRS）项目十个有九个，问题不出在堆垛机，也不出在货架精度，出在中间那一层：WCS。设备是买来的，WMS 是现成的，偏偏这两位"说"的不是一种话，中间就得有个翻译。这个翻译要是没做好，立库跑得越快，乱得越快。这事分两面看：一面是技术对接，报文通了就行；另一面是出了异常谁说了算——这才是真正要命的地方。
先给结论：WMS 是大脑，WCS 是小脑，ASRS 是手脚。对接的本质不是"连上"，而是三层对"库存真相"和"任务状态"的口径一致。口径不一致，报文通得再顺也是定时炸弹。
ASRS 和 WMS 到底怎么"对上话"：三层分工
先把三层的活儿分清楚：
| 层 | 管什么 | 输入 | 输出 | 掉链子的典型表现 |
|---|---|---|---|---|
| WMS（大脑） | 业务任务：哪票单先拣、补货先做哪个、波次几点释放 | 订单、波次策略 | 任务单：任务号、托盘号、源/目标站台、优先级 | 任务下了，设备那边没反应 |
| WCS（小脑） | 设备动作：把业务任务翻译成堆垛机指令 | WMS 的任务单 | 巷道、站台、托盘号的具体动作指令 | 宕机了没人知道，任务堆积 |
| ASRS（手脚） | 执行和回执 | WCS 的动作指令 | 执行结果：成功、失败、失败原因码 | 取货失败，原因没人看得懂 |
报文走的是这么个来回：WMS 下发任务，带任务号、托盘号（或 LPN）、源站台、目标站台、优先级；WCS 接单、排队、派给设备；设备执行完，WCS 把执行结果回传 WMS。这里面有三个最容易出事的细节：第一，超时了谁负责重发，是 WMS 还是 WCS，不能两边都发、也不能两边都不发；第二，同一个任务号必须幂等，网络抖一下重发了，设备不能执行两遍；第三，WMS 账上的库存和 WCS 手里的实物，口径必须一致——WMS 说"在库"的托盘，WCS 必须真找得到。这三条，是所有对接项目联调前必须白纸黑字定下来的，少一条，后面全是坑。
我见过太多项目，联调时只测"happy path"：任务下发、设备执行、回执成功，一气呵成，皆大欢喜。然后上线第一周，现实就开始上课了。
这里先讲一个选型阶段就埋下的雷：库存真相到底归谁？WMS 说"我是账，账说了算"，WCS 说"我手里是实物，实物说了算"。最常见的打架点是"在途"状态——托盘已经从货架上取下来、在输送线上跑着，WCS 认为它"不在库"，WMS 还认为它"在库可分配"。这时候如果有个紧急订单进来，WMS 把这托下发给另一个任务，设备到站台一取，扑空。这个口径问题不在联调时谈清楚，上线后天天吵架。我的立场很明确：账实必须以实物为准，WMS 的"在库可分配"必须扣掉 WCS 的在途量。这个规则写进接口契约，谁也别争。
我见过太多的坑：联调现场的三个经典翻车
第一个坑，WCS 宕了，WMS 还在下任务。某年旺季前联调，WCS 服务器半夜重启了十几分钟，WMS 那边浑然不觉，照常下发了几百个任务。WCS 恢复后，积压的任务一股脑涌向设备，顺序全乱——急单被压在后面，普通补货先跑了。现场花了整整一个白班才把任务队列理顺。复盘时才发现：WMS 根本不知道 WCS 掉线了，因为心跳检测的间隔设得太长，长到一次重启都发现不了。
第二个坑，库存对账口径打架。WMS 账上显示某托盘在立库 A 区，WCS 一查，托盘上周就被异常下架挪到人工区了，回传报文在网络抖动里丢了。结果就是：系统说有货，设备说没货，拣选任务在站台上空等。更麻烦的是，这种账实不符靠人工盘点根本追不上——立库一天进出的托盘数量，人工盘一个月也盘不完。最后是靠 WCS 的在库快照和 WMS 的账面逐托盘对，才把差异托盘一个个找回来。
第三个坑，异常回执没人处理。堆垛机报"取货失败"，WCS 转成一个通用错误码扔给 WMS，WMS 的接口程序不认识这个码，直接丢弃。任务既不算成功也不算失败，就悬在那儿。操作员在屏幕前等货，货永远不来，电话打到 IT，IT 说系统显示"已下发"。三方互相看，干瞪眼。查了一圈，根因可笑：错误码表是集成商随手定义的，WMS 那边根本没做映射。
说个反常识的判断：自动化程度越高，对"降级预案"的依赖越重。很多人觉得上了立库就高枕无忧，恰恰相反——立库最大的风险不是设备坏，而是系统觉得设备没坏。设备坏了你看得见，报文丢了你看不见。
还有一个很多人忽视的细节：任务优先级。WMS 的"急单优先"到了 WCS 那里，如果翻译成简单的队列插队，正在执行的任务被频繁打断，堆垛机空跑率直线上升——急单是快了，整体吞吐反而掉了。优先级策略必须两层一起设计：WMS 定业务优先级，WCS 定执行批序，两边各管各的，互不越界。凡是 WMS 直接指挥设备动作的项目，最后都乱成一锅粥。
让 ASRS 和 WMS 长久对上话：四条铁律
第一，接口契约先行。联调之前，先把任务状态机对齐：已下发、执行中、成功、失败、异常挂起，五个状态一个不能少，每个状态谁可以扭转、超时多久算失败，白纸黑字写下来。重试归属只能有一家，幂等键必须全链路透传，错误码表必须两边逐条映射——"通用错误"这种码不许出现。
第二，降级预案。WCS 宕了怎么办？WMS 必须能立刻暂停下发，已经在途的任务要能导出清单转人工。降级不是"等 IT 修好"，而是一套平时就演练过的切换流程。没演练过的预案，等于没有预案。我给客户的验收标准里永远有一条：WCS 断网十分钟，恢复后任务和库存必须对得上。对不上，尾款先别付。
第三，对账机制。每班次 WMS 和 WCS 对一次账：账面库存对实物位置。差异不许手工改账，必须走异常流程——查清托盘去哪了、报文丢在哪，再调账。账可以错，但错得有痕迹。手工改账一时爽，对账时哭的是全仓库。
第四，联调清单。报文压测、断网演练、异常码全覆盖测试，一个不能少。特别是断网演练：把 WCS 和 WMS 之间的网线拔了十分钟，再看恢复后任务和库存还对不对得上。对得上，这个项目才算真通了。很多项目栽就栽在"联调时一切正常"——联调时网络当然正常，不正常的样子你们一次都没见过。
最后给正在选型的朋友三个问题，签合同前问集成商：第一，WCS 宕机时 WMS 能不能自动暂停下发，在途任务清单能不能一键导出；第二，错误码表是不是逐条映射到 WMS，有没有"通用错误"这种糊涂码；第三，每班次的账实对账是自动跑还是靠人工。三个问题有一个答不上来，实施时就要加钱——不是可能，是一定。
下次集成商跟你说"接口都通了"，你就问他一句话：WCS 断网十分钟，你的货还对得上吗？
作者：老米｜仓储解决方案顾问
