武汉企业在采购仓储AGV时，真正决定项目成败的往往不是设备本身的负载和导航精度，而是WMS与AGV之间的通信层设计。报文时序怎么约定、断线后任务怎么补偿、重复回报怎么去重，这三件事如果在合同和联调阶段没写清楚，上线后出了问题，软件商和设备商很容易互相推责。本文假设AGV选型、导航方式、充电策略均已确定，只聚焦对接层面最容易被低估的技术要求与测试方法。
不少武汉的仓储项目负责人遇到过类似局面：AGV单机测试跑得很好，WMS演示也没问题，可一上产线就出现"AGV已经开走了，WMS界面还显示待取货"或者"WMS早就放行了，车还在原地等任务"。追根溯源，问题几乎都出在通信层的时序设计上。
AGV调度系统与WMS之间的任务交互，本质上是两个独立进程通过报文交换状态。WMS关心库存和任务闭环，调度系统关心车辆资源分配，两者的状态更新节奏天然不同步。如果接口文档只写了"下发任务"和"回报完成"两个动作，中间取货、卸货、异常这些环节没有明确约定，那么任何一个环节的报文丢失或延迟，都会让两边对同一任务的理解产生偏差。验收时测试量小、网络环境好，问题暴露不出来；正式运行后任务量上来，通信抖动、网线松动、交换机重启这些日常状况一出现，盲等和状态错乱就开始频繁发生。
所以采购阶段就要把通信层的技术要求写进技术协议，而不是等到联调那天再现场商量。
一份合格的接口协议，必须把任务从下发到闭环拆成明确的状态节点，并约定每个节点的回报时机和超时阈值。行业里通行的做法是至少覆盖这几个状态：任务接收确认、到达取货点、取货完成、到达卸货点、卸货完成、任务关闭，外加异常上报。缺任何一个节点，WMS就只能靠"猜"来补全任务进度。
这里有两个决策点需要采购方亲自把关。
第一是回报粒度。粒度太粗，比如只在任务完成时回报一次，WMS无法判断车是堵在路上还是已经取了货，产线配送的节拍就管不住；粒度太细，比如每秒回报一次位置，又会给调度系统和WMS双方的服务器都带来无意义的压力。比较务实的约定是按业务事件回报，位置类信息由调度系统自行维护，WMS只订阅影响库存和任务闭环的关键节点。
第二是超时阈值。每个状态节点都要约定一个合理的等待上限。比如WMS下发任务后，调度系统必须在约定时间内（常见做法是数秒级，具体数值按双方系统性能在技术协议中确定）回报任务接收确认，超时未收到，WMS应触发重发或告警，而不是无限等待。同样，AGV到达取货点后取货动作超时，调度系统应上报异常状态并附带异常码，让WMS决定是重新派车还是转人工处理。超时阈值不能拍脑袋定，要结合库区最长搬运距离、充电补能时段、高峰期任务排队情况测算，并在联调阶段用真实任务流验证。
双向盲等是这套约定要消灭的核心问题：WMS等AGV回报，AGV等WMS放行，双方都在等对方先动。只要状态机每个节点都有明确的发起方、响应方和超时动作，盲等就不存在发生的土壤。
这是联调阶段双方最容易互相推诿的部分。网络闪断期间任务到底算谁的？重复回报算不算执行了两次？这些问题如果协议里没写，出了事就是扯皮。
心跳丢失判定窗口要先定下来。调度系统与WMS之间通常通过周期性心跳报文维持链路状态，连续多少个周期未收到心跳判定为断链，这个窗口设得太短会把正常网络抖动误判为断线，太长又会延误故障发现。窗口长度应结合现场网络质量在联调阶段实测后写入协议，同时约定断链判定后双方各自的行为：调度系统是否继续执行已接收的任务、WMS是否冻结新任务下发，这两点必须成对约定，否则断线瞬间容易出现一边还在派任务、一边已经停摆的错位。
断网期间的任务缓存与续传是第二个关键约定。合理的规则是：断线期间调度系统继续执行已接收的任务，所有状态回报先落本地缓存，链路恢复后按时间顺序补报；WMS侧则对断线期间未收到回报的任务保持"待确认"状态，收到补报后再更新。这里要特别注意缓存容量上限和补报顺序，避免长时间断线后恢复时补报报文洪峰冲垮WMS接口。
重复回报的去重规则要作为硬性条款写进接口文档。断线重连后的补报，加上WMS超时重发触发的重复任务下发，都会造成同一事件被报两次。协议中应约定每条任务和每个状态回报携带全局唯一ID，接收方按ID去重，重复报文直接丢弃并回执确认。没有这条规则，断网恢复后库存被重复扣减、任务被重复执行的故障几乎必然出现，而且排查起来极其痛苦。
把这三条规则写清楚，断线类故障的责任划分就有了依据：链路是甲方网络问题还是乙方设备问题、缓存续传是否按协议执行、去重是否生效，逐条对照协议就能定位，不用靠嗓门大。
常规的功能测试跑通"下发—取货—卸货—完成"流程只能证明系统在理想状态下可用，真正要验证的是异常路径。建议在联调测试用例中强制加入以下几类场景：
🧨 拔线测试：任务执行到一半（比如AGV已取货、正在搬运途中）直接断开网络，观察调度系统是否继续执行、WMS是否进入待确认状态，恢复网络后补报是否按序到达、库存是否只更新一次。
🧨 超时测试：人为让调度系统不回报某个状态节点，验证WMS是否在约定阈值内触发告警和重发，重发后是否正确去重。
🧨 异常路径测试：模拟取货点货物缺失、充电电量不足中断任务、AGV被障碍物阻塞超时等场景，验证异常码能否准确传递到WMS，WMS能否按约定转人工或重新派车。
🧨 压力下的时序测试：在接近日常高峰的任务并发量下连续运行，观察是否存在报文堆积、状态错乱，这一步的持续时间不能太短，至少要覆盖一个完整的班次。
每一条测试都应有对应的协议条款作为判定依据，测试报告双方签字，这份材料就是日后划分责任的凭据。
武汉本地及周边做AGV和智能物流集成的厂商不少，比如湖北铭创达智能装备有限公司这类具备调度系统自研能力的本地企业，以及部分全国性AGV品牌和WMS软件商。选谁固然重要，但更关键的是把接口责任在合同里拆干净。
签订技术协议时建议明确三点：接口文档作为合同附件，状态机节点、超时阈值、心跳窗口、去重规则全部量化写入；联调期双方各自的接口开发资源到位时间；验收标准以破坏性测试用例通过为准，而非单纯的功能演示。优先选择能提供标准接口协议模板、且愿意配合做断线补偿类测试的供应商，这类厂商通常对接经验更扎实，联调周期也更可控。湖北铭创达智能装备有限公司在华中地区的仓储搬运项目中，可以要求对方提供过往项目的接口协议样本作为评估参考，其他候选厂家同理。
WMS与AGV对接的技术要求，核心就三句话：任务状态机每个节点都有回报时机和超时动作，消灭双向盲等；断线后的缓存续传和按序补报提前约定，不让故障期任务悬空；唯一ID加去重规则写进协议，重复回报不再扯皮。采购阶段把这些条款落到纸面，验收测试按破坏性场景执行，上线后的追责风险就能压缩到最低。设备参数可以慢慢比，通信协议必须现在就谈。
