库存管理系统与自动化导引车AGV的调度接口
“接口”，在库存管理系统（WMS）与自动化导引车（AGV）的集成项目中，通常被理解为“数据通道”或“技术握手”。但在过去几年参与超过二十个仓储自动化项目的经验里，我逐渐确信一个反常识的判断：接口的本质不是连接，而是契约，一份明确约定了WMS的决策权边界与AGV的执行权范围的契约。许多项目上线后频繁出现任务丢失、车辆死锁、数据不一致，根源并非通讯中断，而是这份“契约”在关键节点上含糊不清。本文将以实际案例和工程决策为线索，拆解设计调度接口时必须面对的三个关键抉择与一个检验标准，帮助你从“接口能跑通”走向“系统能扛住”。
一、契约的真相：为什么说接口是WMS与AGV的权力边界
2019年我参与一个医药电商仓的项目，WMS与AGV调度系统采用标准HTTP接口对接。上线后第三天，某区域AGV集体死锁。排查发现，WMS下发了“将托盘A从X区搬运到Y区”的任务，但AGV到达X区后未找到托盘，因为该托盘被另一台AGV临时移开了。AGV无法回告“任务无法执行”，只报告“已到达目的地”，而WMS未收到“任务完成”状态，在超时后重复下发相同任务，最终导致车辆循环撞车。
问题出在接口缺少一个中间状态：“任务受理但受阻”。WMS把任务视为“指令”，AGV把任务视为“期望”。两者对“什么算完成”的定义不一致，契约出现了真空。从那以后，我坚持在接口定义阶段画出完整的状态机，明确每个阶段谁有决策权、谁有义务反馈。下面这张状态转换图揭示了一个健康接口应有的闭环：
真正可靠的接口，必须在每个状态转换点配备清晰的“责任书”：谁该发起、谁该响应、超时后谁该负责。比如“拾取货物”状态，AGV必须向WMS发送货物条码和车辆当前坐标；WMS需返回确认或冲突提示。若不返回，AGV需要重试策略，这些细节才是契约的核心。
二、关键抉择①：底层协议，RESTful还是MQTT？
协议选型往往是项目最早做出的技术决定，却对后期运维质量影响最大。我见过一个项目坚持全用RESTful，结果在高频状态上报阶段直接把应用服务器打满；也见过全用MQTT导致关键指令丢失后无法追溯。没有“最好的协议”，只有适合场景的协议组合。下面分场景拆解。
1. RESTful：稳如老狗的“指令快递员”
当WMS需要下发一个不可丢失的任务指令（例如“紧急转移冷库货物”），并且需要立即确认AGV是否收到时，RESTful的同步请求-响应模式是最直接的保险。它的优势在于天然符合IT传统架构：
- 调用方发出请求后，必须收到HTTP 200才认为成功，逻辑清晰；
- 失败时可以立即重试或回滚；
- 易于对接防火墙、负载均衡、日志审计。
但同步模式有一个致命短板，延迟天花板。一个POST请求从建立TCP连接到收到响应，即使在局域网内也至少需要100-500毫秒。当AGV车队达到50台以上，每台每秒上报3个事件（位置、电池、状态），WMS就需要每秒处理150个REST请求。加上应用层解析、数据库写入，很快达到瓶颈。我曾在一个跨境仓看到，AGV数量从30台增加到60台后，RESTful状态上报的平均响应时间从200ms暴涨到3.2秒，直接拖瘫WMS。
2. MQTT：只发布不等待的“广播电台”
MQTT的发布-订阅模式正是为高频低延迟场景设计的。Agent（AGV）只需向特定Topic发布消息，WMS作为订阅方在消费端异步处理。延迟可以控制在10-50毫秒级别。且MQTT支持QoS级别：QoS 0（至多一次）、QoS 1（至少一次）、QoS 2（正好一次）。对于AGV状态上报，我通常推荐QoS 1，保证不丢失但又不会像QoS 2那样带来重复消费开销。
但MQTT的软肋也很明显：缺乏原生请求-响应模式。如果WMS要查询某台AGV的当前电池电量，不能直接发一条指令等回复，而是需要通过成对的Request/Response Topic（或等待该AGV定期发布）。这种异步模式要求双方都有良好的事件关联机制，容易引入“发出去收不到回执”的难题。
3. 怎么选：双模架构是成熟团队的及格线
经历了多次矫枉过正后，我现在的推荐方案是RESTful + MQTT 双模，用两张表说清对应关系：
| 功能域 | 推荐协议 | 原因 |
|---|---|---|
| 下发任务（创建、取消、修改优先级） | RESTful | 需要WMS立即确认，失败重试可通过调用方控制 |
| 任务状态变更上报（拾货、放货、故障） | MQTT QoS 1 | 量大，延迟要求高，允许消费者端去重 |
| AGV心跳/位置/电池状态 | MQTT QoS 0 | 允许丢失个别包，实时性最高 |
| WMS主动查询（如“任务执行进度”） | RESTful | 频率低，请求-响应天然匹配 |
| 异常事件/紧急停车 | MQTT + RESTful双重保障 | 关键事件需要冗余通道 |
这种混合架构在2019年的一个冷链项目中经过验证：50台AGV，高峰期每秒1200条消息，RESTful通道仅处理任务下发（峰值30 req/s），MQTT扛住状态上报，系统运行2年未出现因协议选型导致的事故。
读者评论
文章把接口比作“契约”非常精辟，很多项目死锁确实不是通讯断了，而是责任边界没划清。状态机的7个必选状态图很实用，尤其是“已受理但受阻”这个中间态，以前经常被忽略。建议每个上线前先对着状态图逐项走查。
双模架构（RESTful+MQTT）的推荐很务实，实测数据也说明问题。不过实现复杂度会上升，需要团队同时掌握同步和异步通信。联邦制调度是平衡全局最优和鲁棒性的好方案，但WMS的优先级干预机制设计要小心，防止RCS频繁重算。
异常部分说到痛处了，验收时80%的接口没覆盖异常场景，这个数据我信。‘任务卡住10分钟怎么办’这种问题必须在接口定义时就有超时机制和回告策略，否则上线后就是灾难。建议所有任务级别都强制带estimated_duration和超时处理。
作为甲方，最关心的是接口标准能否落地。文章提到状态转换必须由AGV主动上报、WMS被动监听，这能避免两边数据不一致。但实际选型时，供应商往往在协议和调度模式上拍脑袋，很少愿意在异常处理上多花时间。这篇文章可以作为技术谈判的参考清单。