2. 任务协同的总体架构

在 AMR 与 WMS/WCS 协同工程中，最容易出问题的往往不是单点功能，而是“任务在系统之间怎么走、走到哪一层该由谁负责”。如果 WMS 直接指挥每台 AMR，或者 WCS 越权修改订单分配结果，系统就会在异常场景下互相覆盖状态，导致重复搬运、任务丢失或库存对不上。因此，本节先建立一个清晰的分层任务流模型，把订单到执行的全过程拆成三层职责，并明确每层的接口边界。

一、三层任务流模型：订单域、调度域、执行域

从业务视角看，一个出库订单最终变成 AMR 的一次物理搬运，中间要经过三次关键“翻译”：

• WMS 任务池层（订单域）：把客户订单、波次、补货需求翻译成“仓内作业任务”，例如“从 A-01-02 货位取 3 箱物料到出库缓存位”。它关心的是库存、批次、先进先出、任务优先级，不关心由哪台 AMR 执行。
• WCS 调度层（调度域）：把 WMS 下发的作业任务翻译成“设备可执行的动作序列”，例如“AMR-07 前往 A-01-02，举升货架，送往出库缓存位”。它负责任务拆分、路径规划、交通管制、设备选型与任务分派。
• AMR 车队管理层（执行域）：把 WCS 的动作指令翻译成“电机、举升、导航、避障”等底层控制，并实时上报位置、电量、故障、任务进度。它只对“这一台车怎么安全走完这段路”负责。

这三层不是简单的上下级，而是“职责分离、状态回传”的协作关系。WMS 拥有任务的定义权，WCS 拥有任务的调度权，AMR 车队拥有任务的执行权。任何一层都不能越权修改另一层的核心状态。

二、各层职责划分与关键边界

把三层放在一起看，职责边界可以用一句话概括：WMS 管“做什么”，WCS 管“谁来做、怎么做”，AMR 管“做到位”。

这里有一个容易被忽视的边界：任务号的所有权。WMS 生成的任务号在整个生命周期内保持不变，WCS 只能引用它、不能重新编号；WCS 拆分出的动作指令可以有自己的指令号，但必须携带原始任务号。这样当 AMR 上报“任务完成”时，WCS 能准确回写到 WMS 的对应任务，避免“做了但没销账”。

三、接口边界上的三个关键约定

接口边界不是画一条线就完了，真正落地要约定三件事：

1. 状态机对齐：WMS 任务状态通常为“待分派→已分派→执行中→已完成/已取消”；WCS 指令状态为“已接收→已下发→执行中→已完成/失败”。两边必须建立映射关系，例如 WCS 的“已下发”对应 WMS 的“已分派”，WCS 的“执行中”对应 WMS 的“执行中”。映射错位会导致 WMS 显示“待分派”而 AMR 已经在跑。
2. 异常责任归属：AMR 因避障临时停车，属于执行域异常，由 AMR 车队管理层自行恢复并上报“延迟”；若 AMR 故障无法恢复，WCS 负责将任务重新分派给其他 AMR，并通知 WMS 更新任务状态；若库存不足导致任务无法执行，则由 WMS 取消任务并释放已分配库存。每一类异常都要有明确的“第一责任层”。
3. 幂等与去重：接口消息可能重复投递。WMS 下发任务时携带唯一任务号，WCS 收到重复任务号应直接忽略并返回“已存在”；WCS 上报完成时携带任务号+指令号，WMS 重复收到同一完成消息不应重复扣减库存。这是工程上最常被忽略、却最容易造成数据不一致的细节。

四、为什么必须是三层而不是两层

有人会问：WMS 直接对接 AMR 车队管理层不行吗？在简单场景下似乎可以，但一旦出现多车、多任务、多区域，就会暴露两个问题：

• WMS 被拖入实时调度：WMS 的事务处理周期通常是秒级甚至分钟级，而 AMR 调度需要百毫秒级响应。如果 WMS 直接选车、算路径，会把业务系统拖垮，也无法处理交通管制、死锁避免等实时问题。
• AMR 车队管理层缺乏全局视野：单台 AMR 只知道自己的位置和任务，不知道其他区域的任务排队情况、库存优先级、波次截止时间。WCS 作为中间层，恰好承担“全局优化+局部执行”的翻译角色。

因此，三层模型不是人为增加复杂度，而是把“业务逻辑的稳定性”和“执行控制的实时性”分开，让每一层都能独立演进。WMS 可以换版本而不影响 AMR 控制，AMR 可以换品牌而不影响订单流程，这正是任务协同工程的核心价值。

总结来说，从订单到执行的任务流分层模型，本质是给“任务”赋予清晰的归属和生命周期：WMS 是任务的出生地，WCS 是任务的调度中心，AMR 车队是任务的执行末端。三者通过标准接口传递任务号、状态和异常，既保持解耦，又能协同完成从订单到物理搬运的完整闭环。