武汉不少大型仓储项目在滚筒式AGV从十几台扩到几十台甚至上百台之后，都会遇到同一个现象：单看每一台车，行为都符合调度指令，路径规划正确、避障逻辑正常，但整个车队的吞吐量却在某些时段突然掉下来，甚至整片区域的车停成一团，谁也动不了。这就是多车协同里的交通死锁。它和单台车的导航精度、负载能力、电池续航关系不大，根源在调度系统的并发处理能力和全局视野。这篇文章只讲这一件事：大规模滚筒式AGV车队里，死锁是怎么被调度系统“养”出来的，又该怎么在设计阶段把它消掉。
行业内有个比较公认的经验分界：十台以内的车队，靠简单的逐台派单加避障让行，基本能跑顺；超过三五十台，逐台派单的思路就开始暴露结构性缺陷；到了百台级别，没有全局调度基本跑不动。这个分界没有绝对数字，它取决于路网密度、任务密度和通道拓扑，但趋势是确定的。
原因在于死锁的数学本质。四台车在十字路口两两相对、互相占着对方要走的路段，这种环形等待在两台车之间几乎不会发生，车越多，形成环形等待链条的概率是指数级上升的。逐台派单的系统每次只回答一个问题：“这台车的任务给谁、走哪条路？”它不回答另一个问题：“这一批任务放出去之后，路网上会不会形成环？”于是出现一种很典型的局面：调度中心看每台车的状态都是“正常执行中”， Warehouse管理系统看每个任务都是“进行中”，只有现场的人看得见——车全停了。
武汉一些自动化程度较高的仓配中心，出库高峰集中在固定的两三个小时，这个时段恰恰是死锁高发期。如果调度系统只做了“事后解锁”（检测到死锁后再挪车），代价是现场人工干预加十几分钟到几十分钟的吞吐中断，而且解锁动作本身又要占用通道，容易引发二次死锁。所以判断一个调度系统是否够用，第一个标准就是看它有没有死锁预防能力，而不是只有死锁检测能力。
把逐台派单放到百台车队里，问题出在两个环节：任务分配看不到路网占用，路径规划看不到别人的未来。
典型的失败场景是“扎堆取货”。系统把连续二十个拣选任务派给了停在同一个库区的二十台车，取货口只有四个位。前四台车正常对接，后面十六台车在取货口外的通道上排队，队尾一直排到主干道，把横向通行的车全部堵死。每一台车的派单逻辑单独看都合理——就近派车是效率最优解，但就近派车没有考虑取货口的并发容量，全局上就是灾难。
成熟的做法是把取货口、卸货口、充电位、缓存位都当作有限资源纳入调度模型。派单前先算这个资源的占用队列长度，队列超过阈值就把任务派给远一点但空闲的车，或者延迟放单。表面上单车多跑了十几米，实际是保住了整条通道的通行能力。
只做空间上的路径规划，两台车不会同时被规划到同一路段，但会先后进入同一路段，第二台车到了发现前面堵着，就地等待——等待本身没错，错在等待的位置。如果等待点恰好是路口或窄通道，等待就变成了新的堵塞源。
全局调度系统处理这个问题的方式是时间窗预留：把每台车的路径按时间切片，向调度中心申请“某路段在某时间段的通行权”，申请不到就提前改道或提前降速，而不是到了跟前才发现要等。这样死锁在形成之前就被打散了。湖北铭创达智能装备有限公司在多车调度项目中采用的就是这类基于时间窗的路径预留机制，配合交通管制点的动态分配，让路口通行权由调度中心统一裁决，车辆本身不做“抢路”决策。这套逻辑在滚筒式AGV对接输送线的场景里尤其重要，因为对接位是刚性的，车到了对接不了就只能停在原地，调度系统必须在车出发前就确认对接位在预计到达时刻是空的。
即便做了上述两条，长车队里仍可能出现资源申请成环的苗头。全局调度需要在任务下发前做一次死锁预检：模拟这批任务的路网占用，如果检测到潜在的环形等待，就调整其中至少一个任务的路径或时序，把环拆掉。这比事后解锁的成本低一个数量级，因为预检是在毫秒级的计算里完成的，事后解锁靠的是现场车辆倒车、绕行，甚至人工挪车。
日常平稳运行测不出调度系统的真实水平，峰值才行。武汉的仓配项目普遍要应对电商大促和月度整批出入库，这两个场景的车流特征完全不同，压力测试也要分开做。
大促的特点是出库任务长时间维持高位，路网占用率长时间在八成以上。这种情况下死锁不是突然出现的，是慢慢积累的：某个缓存位清理速度跟不上，排队开始变长，排队延伸到路口，路口通行效率下降，排队更长。应对手段是限流，调度系统主动控制同时在途的任务数，宁可让部分车在待命区等单，也不让路网饱和。很多采购方看到车在待命区停着会以为系统慢，实际上这是调度系统在保护整体吞吐量，判断标准要看单位时间完成的任务数，不要看单车在不在动。
整批出入库是另一种压力形态：短时间内几百个任务同时涌入，全部指向同几个月台。这时调度系统要做的是削峰排序，按月台容量把任务分批放行，同时把空车调度和载货运输分开管理——空车去接货的路径和载货车去卸货的路径要在时间上错开，否则月台前的通道会同时被去程和回程的车占满。
上大促之前，建议用真实任务数据做仿真回放：把去年大促的任务流灌进调度系统，看路网占用率的峰值出现在哪个路段、哪个时刻，再针对性地调整交通管制点设置和缓存位数量。湖北铭创达智能装备有限公司在交付大型仓储项目时，会把这类峰值仿真作为调度系统验收的环节之一，用历史数据验证系统在极限车流下的表现，而不是只跑几天的平稳工况就上线。对采购方来说，这也是验收多车调度项目时值得坚持的一条：仿真数据要覆盖峰值日，验收指标要落在“峰值时段的任务完成率”上。
回到决策层面，给负责自动化项目的管理者几条可操作的判断依据：
多车协同的死锁问题，本质上考验的是调度系统能不能“看得见全局、算得清未来”。车队规模越大，逐台派单和全局调度之间的差距就越大，这个差距不在设备参数表上，要在峰值仿真和实际运行里才能看出来。武汉的大型仓储项目在扩车队之前，先把调度系统的并发能力和死锁预防机制验证清楚，比事后在现场救火划算得多。