先说结论：AMR 和 WMS 对接这件事，接口怎么写只占 20% 的工作量，剩下的 80% 是决定——搬运任务到底由谁生成、车辆状态到底回传到哪一层。这个问题答错了，后面全是返工。
我做过 30 多个 WMS 上线项目，其中 9 个带 AMR。给一句可以直接抄的选型答案：10 台以下、单品牌试点，WMS 直控够用；10～50 台、单一品牌，走 RCS 中间层；50 台以上或者多品牌混编，上任务池模式。数字是经验区间，不是标准，自己按仓的复杂度上下浮动。
为什么核心问题是"谁生成任务、谁接收状态"？因为 WMS 懂的是业务（哪个订单、哪个库位、什么货），RCS 懂的是车（哪台车有空、哪条路堵了、哪台车快没电了）。两边的语言不一样，对接就是翻译。翻译错了，货就错了。
三种 AMR 与 WMS 对接方式，先看这张决策表
| WMS 直控 | RCS 中间层 | 任务池模式 | |
|---|---|---|---|
| 任务由谁生成 | WMS 直接下到车 | WMS 下业务任务，RCS 拆成车辆动作 | 独立任务服务统一编排 |
| 车辆调度谁管 | WMS 按简单规则 | RCS 全权（路径、避障、充电） | 任务池 + 各品牌 RCS |
| 状态回传 | 车直接回 WMS，颗粒度粗 | RCS 按约定状态回 WMS | 任务池聚合后再回 WMS |
| 适合车队规模 | 10 台以下 | 10～50 台，单一品牌 | 50 台以上，或多品牌混编 |
| 接口工作量 | 小 | 中 | 大 |
| 最大的坑 | WMS 不懂车，堵死 | 状态映射对不上 | 任务池成了新单点 |
| 实施周期（经验值） | 2～4 周 | 6～10 周 | 3～6 个月 |
方式一：WMS 直控——接口最少，但车一多就露馅
做法：WMS 直接给每台车下搬运任务（从 A 点搬到 B 点），车执行完把"完成"回传。
适用场景：10 台以下、固定线路的试点。比如只做"收货区到存储区"的整托搬运，线路就两条，这种可以用。
坑在哪：WMS 不知道车在哪、还剩多少电、前面堵没堵。2023 年，苏州一家 3C 配件仓，1.2 万平方米，18 台顶升式 AMR，直控接的老 WMS。上线第二周，WMS 一次扔了 40 多个任务，巷道口 6 台车顶在一起，谁也不让，人工去挪车挪了半小时。更隐蔽的坑：WMS 下的任务没有"任务类型"字段，AMR 分不清上架和补货，一托补货被拉到了发货月台，月台的人一脸懵。
救法：中间加了一层很薄的任务队列服务——WMS 只管扔任务，服务按车辆空闲、电量、位置决定派给谁。这其实就是任务池的雏形。代价：上线推迟了 6 周。
这个坑我见过三次。直控不是不能用，是只能用在"车少、路简单、任务单一"的场景，超出一步就翻车。
方式二：RCS 中间层——AMR 和 WMS 集成的当前主流
做法：WMS 只管业务任务（"把托盘 P123 从库位 A-01-02 搬到月台 D3"），RCS 负责拆成车辆动作、派车、路径规划、充电管理。状态由 RCS 按约定回传给 WMS。
这是目前 10～50 台、单一品牌项目最稳的走法。WMS 不用懂车，RCS 不用懂业务，各管一摊，权责清楚。
但有一个坑，几乎每家都会踩：状态映射。2024 年，广州南沙一家跨境电商仓，32 台叉式 AMR，两个品牌、两个 RCS，上面一套 WMS。联调时发现，A 品牌 RCS 的任务状态只有"执行中、完成、异常"三种，B 品牌有 9 种；A 品牌回传"暂停"，被翻译层理解成了"完成"，托盘还在半道上，WMS 里已经记成入库了，账实差了 60 多托，盘了一整天才对上。
救法：建一张统一状态映射表。要求：不管哪个品牌，RCS 侧的任何状态，回传 WMS 之前必须先落到 8 种标准状态上——待执行、执行中、暂停、异常、完成、取消、超时、人工接管。映射表由 WMS 侧维护，RCS 厂商配合，写进合同附件。这个坑我见过三次，第三次终于学乖了，合同里直接写死。
方式三：任务池模式——重活儿，适合多品牌混编大车队
做法：WMS 和各品牌 RCS 之间，再加一个独立的任务编排服务（任务池）。WMS 扔业务任务进来，任务池按全局最优分配到各品牌 RCS，状态由任务池聚合后再回传 WMS。
适用：50 台以上，或者注定要多品牌混编的大仓。好处是以后换 AMR 品牌，WMS 一行代码不用动，只换任务池的驱动，扩展性最好。
代价：任务池本身成了新系统，要有人维护；而且它是单点，挂了全场停摆，必须做高可用。接口加联调，按我的经验是 3～6 个月起步。小仓别碰，这钱不值。
反常识：接口最贵的从来不是开发
说个反常识的判断：AMR 对接项目里，接口开发（写 API、调通）一般只占总工作量的两成。真正烧钱的是联调阶段发现业务逻辑对不上——比如 WMS 认为"任务完成 = 货到了"，RCS 认为"任务完成 = 车到了"，货还没卸呢，车一到就算完成，账就错了。
这类问题在需求阶段多问一句就能避开，到了联调阶段再改，WMS、RCS、现场三方扯皮，一扯就是几周。所以我的做法是：签合同之前，先把 8 种标准状态里"完成到底指什么"写进附件，双方签字。丑话说前面，比上线前夜吵架强。
还有一个经常被忽略的：充电任务到底谁下？我的答案是 RCS 下，WMS 别碰。WMS 不知道充电桩被占了没。之前有个项目，WMS 定时给低电量车派充电任务，结果 8 台车同时去抢 4 个充电桩，排队排到任务超时。RCS 管充电，WMS 只管在任务超时时收到通知，这事就顺了。
上线前夜 checklist：一项都别漏
任务下发：
- 任务有全局唯一 ID，重复下发要幂等（同一 ID 下发两次，只执行一次）
- 任务必须带任务类型（上架 / 补货 / 出库 / 移库），RCS 不许猜
- 任务超时时间双方约定一致，超时后 WMS 能取消，RCS 必须响应取消
- 取消任务时，车上已经有货的，必须有明确的"货怎么办"规则
状态回传： 5. 8 种标准状态映射表双方签字，写进合同附件 6. RCS 给 WMS 心跳（建议 1 秒一次或等效机制），断线超 30 秒 WMS 必须报警 7. 状态回传失败要有本地缓存重发，不能丢状态 8. "人工接管"状态必须回传，WMS 要知道这台车现在是人在开
异常与现场： 9. 充电任务由 RCS 下发，WMS 不直接指挥充电 10. 急停、脱钩、货物掉落三类异常，RCS 要在约定时间内推到 WMS（或短信 / 电话到值班人） 11. 人工介入处理完，任务是继续还是作废，规则提前写死 12. 网络中断时车的默认行为（原地等待还是回充电区），提前定好
数据对齐： 13. 库位编码 WMS 和 RCS 用同一套，大小写、横杠一个都不能差 14. 托盘条码规则一致，RCS 扫到的码 WMS 必须认得 15. 月台、充电桩、暂存区在双方系统里的命名一一对应
压测： 16. 按旺季 1.5 倍任务量压测，连续跑 4 小时，看堵车和超时率 17. 模拟 RCS 断线、WMS 断线、单台车故障三种故障，走一遍恢复流程 18. 账实核对：压测期间随机抽 50 托，WMS 账面位置和实际位置必须一致
checklist 不是写出来好看的，上线前夜逐项打勾，负责人签字。剩下的现场特殊项（比如冷库低温、食品仓批次要求）自己往上加。
最后一句明天就能用的建议：如果你正在选 AMR 厂商，招标文件里加一条——"RCS 必须支持标准任务状态回传，状态定义以买方 WMS 的 8 种标准状态为准"。这一条，能帮你省掉后面至少一个月的扯皮。
作者：林晓｜WMS 实施顾问，做过 30+ 上线项目
