一台 AGV 搬一次货，要穿过几套软件才能把货送到地方；订单从顾客下单到包裹出库，也要穿过同样数量的关卡。
多数人知道 OMS、WMS、WCS 这些缩写指的是什么，却分不清它们各自回答什么问题、管到哪一步为止。本文按职责把五套系统逐个拆开，再跟着一次搬运任务走一遍，最后给一张按仓储形态搭配系统的对照表。
01 先记住一句话
五个系统回答的是五个不同的问题，问的问题不同，管的粒度就不同。OMS 回答"这单该由哪个仓来发"，WMS 回答"东西在哪、能不能放这儿"，WES 回答"这一小时先干哪件、谁去干"，WCS 回答"用哪台设备、走哪条路"，RCS 回答"哪台车跑、怎么不打架"。
顺着这个问题链往下看，五套系统的关系就清楚了。回答越靠前的问题，系统视野越大、决策周期越长；回答越靠后的问题，系统离物理现场越近、决策周期越短。
每一层交给下一层的东西，比自己收到的东西细一层
注意"交给下游的东西"这一列。OMS 交给 WMS 的是一张履约单，WMS 交给 WES 的是一张出库单与波次，WES 交给 WCS 的是一条条可执行任务，WCS 交给 RCS 的是一条设备搬运指令。
往下传一层，粒度就细一层。整条链路上，上游只负责说清楚"要做什么"，具体怎么执行，是下游的事。
五套系统并非五个层级，OMS 与 WMS 同属计划层，WES、WCS、RCS 同属执行层
这套分层有个行业通用的参照标准，叫 ISA-95。它把企业和现场之间的控制系统划成五层：最下面是实际动的设备，往上是实时过程控制，再往上是制造运营管理，最上面是企业计划与物流。
拿这套层级去对照，仓储软件的落位就一目了然：WMS 和 OMS 处理的是计划类问题，属于第 3 层；WES、WCS、RCS 处理的是执行类问题，属于第 2 层；再往下才是输送线和堆垛机这些真正在动的设备。
02 逐个拆开看
OMS
订单管理系统：决定这单由谁发
OMS 管的是订单，不是货。它把来自电商平台、门店、批发、跨境小包的订单汇总起来，判断哪个仓能发、怎么拆单、拆成几单，然后把这些履约决定发给下游。
OMS 存在的意义是解决"多渠道、多仓"的复杂度。没有 OMS 的时候，这个判断通常由人在后台做：看哪个仓有货，看哪个仓离客户近，看能不能凑单一起发。
电商规模起来之后这个动作靠人做不动了，OMS 要做的事就是把它变成规则：按库存、按距离、按运费、按时效承诺自动路由。
需要注意的是，OMS 管的是虚拟库存。它看到的是"某仓有 500 件可用"，这个数字来自 WMS 的同步报表；真正在哪个库位上、有多少在质检、多少被冻结，OMS 不清楚，也不该清楚。
WMS
仓储管理系统：管住每一个库位
WMS 管的是库存账：每件货在哪、是什么状态、能不能动。收货、上架、拣选、复核、包装、发运，全部在这里记账。
WMS 的核心能力是库位策略。货到了，先决定放哪个库位：靠近出库口的留给高频货，同一物料尽量集中放，超过体积或重量限制的要拆分管理，这些规则直接决定拣选效率和库容利用率。
它还要管批次、序列号、效期、质检状态这些细粒度信息。同一箱料里有的在质检、有的已放行，在 WMS 里是两条不同的库存记录。
WMS 的输出是一张出库单加一个波次。波次是把一批订单按某种策略聚合成一次批量作业，让拣货员一趟走完，避免来一个订单走一趟。
WES
仓库执行系统：把单子变成任务
WES 是 WMS 和现场之间的翻译层。WMS 说"这 200 单今天发出去"，WES 负责拆解成：谁拣、拣哪几个货位、什么时候出发、怎么合并路径、货到了复核台谁来接。
这一层的工作重心是人机协同和节拍优化。仓里有多少个拣货员、每个人在哪、手上的单子要不要先结掉再接新的、堆垛机什么时候有空，这些判断在 WMS 里做不合适，在 WES 里做才顺手。
实际项目里，WES 经常被当作 WMS 的一个模块一起卖，甚至干脆没有独立系统。这不算错——人工仓里作业优化确实是 WMS 顺带的活。
但如果仓里有自动化设备，WES 就有独立价值了：WMS 一次下发一个包含几百个订单的波次，WES 要结合当前设备负载、库内拥堵情况、现场人员位置，把这个波次切成一条条此刻真的能执行的任务。
WCS
仓储控制系统：指挥设备怎么动
WCS 管的是设备：堆垛机、输送线、机械臂、分拣机。它把上层的一条条搬运任务翻译成设备听得懂的动作指令，同时管着设备当前在哪、有没有空、卡在哪个位置。
立体库里堆垛机怎么选、货从哪条巷道进、输送线上一堆货怎么排序、分拣机格口满了往哪转，这些是 WCS 的活。WMS 只需要说"把 A 库的货搬到 B 库"。
WCS 的技术门槛主要在设备协议和实时性。它要跟十几种品牌的设备打交道，每家的指令格式、状态回传、异常码都不一样，全都要翻译成一套统一模型。
RCS
机器人控制系统：让一群车不打架
RCS 管的是车队。仓库里有几十上百台 AGV 或 AMR，它们共用通道、交叉路口、充电位，谁先走、路口谁让、卡住了怎么解开，只有这一层知道。
RCS 要处理的问题有：多车路径规划、动态避障、交通管制、死锁检测、电量与充电调度、任务优先级。
WCS 和 RCS 的分工在行业里一直有两种做法：一种是把 RCS 嵌在 WCS 内部，WCS 直接管车；另一种是 RCS 独立，WCS 把搬运指令交给它。
两种做法都成立，选哪种取决于车队规模和设备种类。车队小、设备单一，嵌进 WCS 更省事；车队大、机器人品牌杂，RCS 独立出来才有价值。
03 它们之间怎么说话
多数人以为上游把活派给下游就结束了。实际情况不是这样：每一层都要把执行结果送回上一层，整条链路是双向的。
两类消息的字段构成不同，混在一起是接口出错的高发原因
这两类消息的字段构成不一样。指令下行说的是做什么，字段是任务单号、起点、终点、载具、优先级。状态上行说的是做到哪一步，字段是当前状态、完成时间、异常原因。
把两类消息混在一个接口里，或者用同一个状态字段既表示"要做"又表示"在做"，是接口层出错的高发原因。上下游对不上账，多半从这里开始。
还有一个容易被忽略的边界原则：越靠近执行的系统，接到的信息越少、越具体。往上游走一步，抽象程度就提高一级。
04 一次搬运任务的状态流转
任务从下达到结束，状态要经过若干步。不同厂商的状态名各不相同，含义却一致。
状态由回调推进，回调可以乱序到达，所以每一步推进都要设防
这里有个绕不开的现实：回调会迟到，也会重复。网络抖动会让"开始"的回调晚于"完成"到达，设备也可能因为内部重试逻辑把同一条"完成"发两次。
所以状态推进的每一步都要设防，常见的做法有三条：
状态更新附带"已完成不再改回执行中"的条件，迟到的开始回调不会把已完成的任务改回去
按任务号统计收到的完成回调条数，重发的那次不再重复扣减在途数量
取消有前置门槛：任务尚未被设备接手，才允许发出取消请求
这三条护栏的共同点是：不指望回调按顺序到达，也不指望它只来一次。
同理，跨系统调用的失败也不能只靠"对方会重试"。稳妥的做法是把失败的请求记录下来，交给后台任务重新找资源、重新下发，错误信息不会直接抛给操作员。
05 怎么按场景配
五套系统全上是最省事的做法，也是最费钱的做法。真正需要考虑的是：这套仓的作业形态是什么，瓶颈在哪一层。
纯人工仓，WMS 是唯一必须的系统。WES 可以省掉，因为波次策略本来就写在 WMS 里；WCS 和 RCS 更不需要，仓里没有设备。
有自动化设备的仓，WCS 就是必需的。WES 值不值得单买，看拣货段有没有人机混合——如果有，作业优化值得单独做。
多渠道多仓做电商，OMS 必需，因为路由决策本身就是它存在的理由。仓库内部的设备自动化可以慢慢加。
制造线边物流是个特例：没有电商订单，OMS 完全不需要，WMS 负责线边缓存库的账，AGV 上下料交给 RCS。
把这些判断放到一张表上：
纵向看，仓储越自动化，WCS 与 RCS 越靠前；横向看，系统越往上越省不掉
表里最值得注意的一格是"人机混合仓"里的 WCS 标着必须，而 RCS 标着不需要。人机混合的意思是拣货有人、设备只做搬运，搬运任务类型单一、路线固定，一个 WCS 把设备调度管住就够了，不需要上到车队调度的粒度。
另一格是"制造线边物流"里 OMS 标着不需要。线边物流的搬运需求来自 MES 的生产节拍，不来自订单，所以整条链路上没有订单履约的环节，OMS 自然用不上。
选型的顺序建议是这样：先按仓储形态定必选项，再看瓶颈在哪一层补可选项。
瓶颈在库存准确率，是 WMS 的库位策略和批次规则没做好；
瓶颈在拣货效率，是 WES 的波次和路径合并没做好；
瓶颈在设备利用率，是 WCS 的调度策略问题；
瓶颈在车队互相干扰，才轮到 RCS。
把不该上的系统砍掉，省下的预算往往可以直接换成上面那一层的优化。
06 实施时容易踩的坑
- 边界含糊，上下游互相写对方的表
最常见的做法是 WMS 直接更新 AGV 任务表，或者上游系统顺手把下游的库存改了。短期省事，长期是灾难：两边都在改同一份数据，出问题没人能判断该信谁的。
- 状态只有成功和失败两种
真实世界的搬运任务是长流程：创建、进行中、完成、取消，还要区分"下发成功但设备还没来"和"下发成功设备已经在路上"。状态划分太粗，卡单和重试就没法做。
- 只设计正常流程，不设计异常
下发失败了怎么办？回调丢了怎么办？任务取消时设备已经到门口了怎么办？这些问题在上线前就该有答案，否则线上会用人工加班来回答。
- 现场操作方式和系统设计脱节
设计时假设操作员一次只做一个动作，现场是连续处理多个任务。指令系统的动作链、循环、退出点这些机制，就是为了让系统能贴合这种连续作业而生的。
- 没有留痕，出事查不回去
每一次下发、每一条回调、每一条失败原因，都要有地方可查。成熟的做法是把回调原始报文、处理结果、成功标识都落在同一张表里，出了问题能直接翻出当时的记录。
这五条里，第三条和第五条最容易被跳过，因为正常跑起来的时候根本看不出问题。
判断一套仓储系统好不好用，看两件事：库存准不准，任务卡住之后能不能查清楚为什么卡住。前者是账，后者是账加过程记录。两者都做到了，剩下的都是效率问题。