先把链路掰开：RCS 与 WMS 分工，从一单任务说起
RCS 和 WMS 到底谁指挥 AMR？先看一单任务是怎么流转的。
你可以理解为打车：WMS 是那个下单的乘客，RCS 是滴滴的派单系统，AMR 是司机。乘客只管说"我要从 A 点到 B 点搬一箱货"，至于派哪辆车、走哪条路、路口谁让谁，乘客一概不管——这是派单系统加司机之间的事。
具体到仓库：WMS 管的是业务单据——出库单要从库位 A 拣 20 件货送到打包台。它生成一个"搬运任务"：起点、终点、货物信息、优先级、时间窗，然后扔给 RCS。RCS 接到任务后干的是车队调度员的活：看哪台 AMR 电量够、离起点近、手里没活儿；规划路线；如果有两台车要抢同一个路口，RCS 负责交通管制，让一台先走。AMR 本体只管按 RCS 给的路径开，遇到障碍物自己停，电量低了自己回充电桩。
链路就是这么三级：WMS 下任务 → RCS 派车管路 → AMR 执行。分工清楚了，后面 90% 的扯皮都不会发生。
分工对照表：谁负责什么，一句话都不能含糊
我把 RCS 和 WMS 的分工列成一张表，项目启动会上直接贴墙上，能省掉至少三个月的扯皮：
| 事项 | 归谁 | 说明 |
|---|---|---|
| 业务单据（拣选/补货/越库） | WMS | 任务的"为什么" |
| 任务生成（起点/终点/优先级） | WMS | 任务的"是什么" |
| 选哪台车执行 | RCS | 按电量/位置/负载综合评分 |
| 路径规划 | RCS | 地图、站点、禁行区都在 RCS 里 |
| 交通管制（路口让行） | RCS | 多车协同的核心能力 |
| 充电调度 | RCS | 哪台车什么时候去充、充多久 |
| 车体状态监控（电量/故障） | RCS | 实时采集，上报异常 |
| 任务完成回执 | RCS → WMS | "搬完了"，WMS 才能结单 |
| 异常上报（货没搬到） | RCS → WMS | WMS 决定重派还是转人工 |
记住一条铁律：WMS 永远不直接指挥单台 AMR。WMS 说"我要货从 A 到 B"，RCS 决定"派 7 号车走 3 号通道"。凡是 WMS 越过 RCS 直接给车下指令的项目，最后都死在"两台车在路口顶牛、谁也不知道该听谁的"上。我见过一个项目，WMS 厂商图省事做了个"简易调度"直接发指令给车，RCS 那边也在调度，同一台车同时收到两个矛盾指令，原地打转 40 分钟——这就是典型的双头指挥。
选型分界线：什么规模才配拥有独立 RCS
这是被问得最多的问题，也是"伪需求"重灾区。先开炮：5 台以下的 AMR 车队，根本不需要独立 RCS。
道理很简单：5 台车跑一个小仓库，交通冲突的概率极低，大部分 AMR 厂商自带的车队管理功能（fleet manager）就够用了。花几十万上一个独立 RCS，相当于给 5 个人的小公司配一个 HR 部门——钱花了，事没多干。
分界线我按车队规模和场景复杂度画三条：
第一条线：车队数量。 5 台以下，厂商自带调度够用；5～20 台，看场景复杂度决定；20 台以上，独立 RCS 基本是刚需。注意这是经验值不是标准，关键看下面两条。
第二条线：多品牌混跑。 只要仓库里跑着两个以上品牌的 AMR，独立 RCS 就是必选项。各家厂商的调度系统只认自家的车，A 家的调度管不了 B 家的车，交通管制直接失灵。这时候需要一个中立的 RCS 做"总调度"，通过标准接口（比如 VDA 5050）跟各家车队对接。单品牌车队？厂商自带的调度通常调得比第三方 RCS 还顺手，因为协议是私有的、优化是定制的。
第三条线：任务复杂度。 如果只是点对点搬运（A 点到 B 点），调度逻辑简单；但如果涉及多车协同（比如两台车接力搬一个大件）、动态优先级插队、充电与任务的联合排程，厂商自带调度的能力天花板就很明显了。这时候独立 RCS 的价值在于算法：好的 RCS 能把车队整体 Uptime 做到 95% 以上，差的调度能让 20 台车跑出 10 台车的效率。
三条线画完，决策框架就一句话：单品牌 + 20 台以下 + 点对点搬运 = 别买独立 RCS；三条里占两条，直接上。
扯皮实战一：接口责任不清，两边一起甩锅
2023 年，华东某电商仓，12 台 AMR，WMS 和 RCS 分属两家厂商。项目上线第三周，出库任务频繁超时。WMS 厂商说："任务我早就下发了，是 RCS 派车慢。"RCS 厂商说："我们收到任务就 5 分钟延迟了，WMS 下发不及时。"
两边各执一词，吵了两周。最后我去现场，干了一件事：在 WMS 和 RCS 之间加了一层日志，把"任务下发时间戳"和"RCS 接收时间戳"都记下来。数据一摆出来，真相大白：WMS 下发任务后，平均 4 分 37 秒 RCS 才收到——问题出在中间件的消息队列上，WMS 厂商为了"削峰"把任务攒批发送，RCS 厂商的接口又没有做推送确认。两家都没撒谎，但两家都有责任：一个不该攒批，一个不该不做回执确认。
教训：WMS 和 RCS 之间的接口，必须定义三件事——任务下发的实时性要求（比如 3 秒内）、RCS 的接收回执、超时重发机制。这三条写进合同技术附件，扯皮时直接看日志，一分钟定责。没写进合同的，上线后全是"口头约定"，出事就是罗生门。
扯皮实战二："交通管制归谁"引发的顶牛事故
2024 年，华南某 3PL 仓，18 台 AMR 跑在 6000 平米的仓库里，通道最窄处只有 2.2 米。某天上午，两台满载的 AMR 在窄通道迎面相遇，双双急停，僵持了 20 分钟，最后人工去挪开一台才解决。当天少发了约 300 单。
复盘发现：RCS 的交通管制逻辑里，窄通道被设成了"双向通行"，因为实施时图省事，直接复制了宽通道的模板。而 WMS 那边，任务下发时根本不知道通道宽度——在 WMS 的世界里，地图是不存在的。
这个案例说明一个反常识的判断：RCS 和 WMS 分工最大的坑，不在"谁派车"，而在"地图信息谁维护"。地图（通道宽度、单双向、禁行区、充电桩位置）是 RCS 的核心资产，但地图变了（比如临时堆了货、某通道施工）却往往是仓库现场人员先知道。信息链路应该是：现场 → WMS（业务人员天天在用）→ 同步到 RCS。但很多项目里，WMS 和 RCS 的地图各维护一套，三个月就对不上了。
做法：指定 RCS 的地图为唯一可信源，WMS 只做任务不碰地图；现场地图变更走标准流程 24 小时内同步。地图对不上那天，就是车队顶牛那天。
维护的坑：RCS 上线只是开始
RCS 最大的坑不在选型，在运维。三个高频坑：
第一，充电策略没人调。 RCS 默认的充电策略通常是"电量低于 20% 去充"，但 20 台车如果同时低电量，充电桩排队能排到任务超时。正确做法是按任务波次做充电排程：波次间隙集中充电，高峰期让电量 30% 以上的车先顶着。这个策略要按实际波次数据调，实施商交付时的默认值基本不能用。
第二，MTBF 数据没人看。 AMR 厂商标称的 MTBF（平均无故障时间）通常是实验室数据，现场的真实 MTBF 要自己统计。RCS 里有每台车的故障记录，拉出来按月统计，MTBF 掉得最快的那台车，八成是轮子或激光雷达要换了。等它彻底趴窝再修，停机损失是预防性维护的 5 倍以上——这是我用三个项目的维修账单算出来的。
第三，RCS 和 WMS 的版本升级不同步。 WMS 升级改了任务接口字段，RCS 没跟着升，任务下发直接报错。凡是两家厂商的系统，升级前必须做联调测试，写进运维 SOP。别信"向下兼容"的承诺，现场打脸率 100%。
这钱花得值不值，看这一个数
回到最初的问题：RCS 和 WMS 谁指挥 AMR？答案是分层指挥，WMS 管业务、RCS 管车队，边界一句话：WMS 决定"搬什么"，RCS 决定"怎么搬"。
独立 RCS 这钱花得值不值，看这一个数：车队综合效率（fleet efficiency）= 实际完成任务数 ÷（车辆数 × 单车理论最大任务数）。上 RCS 之前测一个月，上了之后再测一个月，效率提升超过 15%，这钱就花得值；提升不到 10%，说明你的场景根本不需要独立 RCS，厂商自带调度够用了——把钱省下来多买两台车更实在。
作者：大刘｜自动化设备工程师，前集成商技术负责人
