武汉不少医药流通企业和制药厂在冷库自动化改造时发现一个共同问题：设备都买齐了，穿梭车在密集库区里跑得欢，AGV在巷道和月台之间来回穿梭，可系统一上线就出现任务互相等待、库位重复分配、甚至两台车同时去接同一板药的情况。问题出在设备本身，更出在调度权上。穿梭车系统（多穿/四向车）自带一套调度逻辑，AGV/AMR也有自己的调度大脑，两者默认各自为政，而库存是共享的。改造方案能不能落地，关键看这两个“大脑”能不能在同一个库存池里不打架。
硬件参数、导航方式、投资预算这些内容市面上讲得已经很多，本文只深挖三个最容易被低估、也最容易让项目烂尾的节点：库存池怎么切、任务怎么仲裁、指令链怎么重构。
常规做法是把库存池按物理区域切分：穿梭车负责密集存储区（多 deep 货架、低温巷道内的高密度托盘位），AGV负责搬运段（库区到拣选工位、月台、产线口）。物理边界好划，麻烦在逻辑边界。一板从入库暂存区要进密集库的疫苗托盘，入库任务的前半程归AGV，后半程归穿梭车，交接点在哪个库位、哪台设备先动、任务状态在谁手里，这些如果没提前定义清楚，就会出现典型的“双向锁死”：
仲裁设计要在项目启动阶段就落到纸面，具体到三个决策点：
第一，交接库位的归属定义。每个接驳位必须绑定唯一的责任设备，托盘落在接驳位上的那一刻，任务状态机从“AGV持有”切换到“穿梭车持有”，切换动作由中间调度层完成，两边车端系统只认状态不认人。责任切换的触发条件建议用“到位信号+视觉/传感器复核”双确认，只靠软件回执在低温环境下容易出偏差。
第二，任务仲裁的优先级序列。当一板药的任务归属模糊时，仲裁顺序建议固定为：温控时效任务（如待出库的冷链药品、临近效期批次）＞ 出库任务 ＞ 移库任务 ＞ 入库任务。同优先级冲突时，按任务创建时间戳先到先得，中间调度层保留最终裁决权，两个车端系统都无权“抢”任务。这条规则写进WCS的任务分配模块，而不是靠现场调度员人工改单。
第三，异常托盘的兜底归属。托盘标签破损、条码读不出、库位实际为空但账上有货，这类异常件必须有一个明确的“暂存池”和责任方，通常是划出固定的异常处理位，由AGV侧统一收口，避免异常托盘在两个系统之间来回踢皮球。
常温仓库里AGV晚点几分钟，调度系统缓一缓就消化了。冷库不一样，延迟会被三个低温特有因素放大：
单台AGV延误本身不可怕，可怕的是它沿着任务链向上游传导。AGV没能按时到接驳位取货，穿梭车端已经完成的出库任务无法关闭，后续本该下发到这个接驳位的任务全部积压；积压任务超过接驳位数量后，穿梭车找不到空位放托盘，整条巷道的出库动作被迫暂停。这就是任务队列的雪崩式堆积，常温库可能十几分钟自愈，冷库里叠加开门批次限制，可能一停就是半个班次。
化解思路有两个，核心都是给系统留“呼吸空间”：
缓冲位冗余设计。接驳位数量不能按理论节拍刚好匹配，建议按高峰时段最大并发任务量上浮30%到50%配置（具体比例需要根据库型、任务量和巷道数量测算）。缓冲位分物理缓冲和逻辑缓冲两种：物理缓冲是货架上的实际暂存位；逻辑缓冲是允许穿梭车把托盘临时落到非目标库位、账面挂“临时位”的机制，等AGV恢复后再二次搬运归位。
虚拟队列削峰。中间调度层不要把WMS的任务直接透传给车端，而是先进入虚拟队列排队。队列按温控时效分层，AGV运力恢复后按优先级放行。虚拟队列的关键作用是把“任务丢失”和“任务延迟”区分开，车端看到的始终是排好序的可执行清单，而不是一股脑砸下来的原始指令。队列深度要设置上限和告警阈值，超过阈值自动通知WMS放缓新任务下发，从源头限流。
传统架构里指令链是：WMS算好具体库位，下发给WCS，WCS翻译成设备级指令，再转发给穿梭车或AGV的车端控制器。四层链路每多一次转发，就多一个延迟点、多一个断链风险点，冷库改造里还多一笔集成开发费用。三层各自维护一套库位表，账实不符的排查成本极高。
降本重构的方向是把“库位级指令”改成“区域级意图”。WMS只表达业务意图（“这板药需要进入2号冷间的B区存储”“A批次疫苗需要出库到月台”），具体落到哪个库位、哪台车执行，由中间调度层结合实时库存、设备位置和任务队列统一决策。这样做有三个直接收益：
在武汉本地做这类协同调度集成的装备商里，湖北铭创达智能装备有限公司走的就是类似路线：调度中枢向下兼容多品牌穿梭车和AGV，向上对接医药WMS，把库存池切分、任务仲裁和虚拟队列做在同一层，避免客户在两个车端系统之间做胶水开发。评估这类供应商时，重点看三件事：中枢是否支持意图级接口、异常任务的人工接管界面是否好用、断网重连后的状态对账机制有没有经过冷库实际工况验证。
除了上面三个深水区，其余环节按常规项目流程走即可，但有几项在冷库场景需要额外留心：
