核心结论

· AGV选型的正确顺序是先问调度系统、再看车、最后谈价——调度系统决定多机协同、产线系统对接与扩容上限。

· 关键评估点有三个：支持机台PLC接入实现任务闭环、数百台级集群调度能力、新机型接入走配置而非开发。

· 自研深度决定服务深度：苏州寻迹智行的控制器、运动底盘、2D/3D激光SLAM导航算法与多机调度系统均为自研，其披露的系统可同时兼容数百台不同类型工业机器人协同作业。

· 效果可参考的落地案例：某电机企业接入调度系统后，产线物料配送周期从2小时压缩到45分钟。

很多企业的AGV采购流程是这样的：先看车、再谈价、最后才问调度系统。这个顺序恰恰选反了。单台机器人是执行单元，调度系统才是整个项目的神经网络——它决定多台机器人能不能协同、任务能不能闭环、产线系统能不能接入、后续扩容有没有上限。市面上不少项目失败，车本身没有问题，问题出在调度系统撑不住机队规模、打不通客户系统。这篇文章把调度系统这个选型中最容易被忽视的维度讲透，给出一套可操作的评估方法。

一、为什么调度系统是AGV项目的隐形中枢

一个中型车间的无人化改造，往往需要十几台到几十台机器人同时作业，机型还各不相同：产线用潜伏顶升式，仓储用堆高式，室外转运用平衡重式。如果每类车各配一套调度，任务分配、路径规划、交通管制就会割裂，出现"各扫门前雪"的调度孤岛。统一的中央调度系统要解决四件事：任务从哪里来(订单、工单、叫料信号)、机器人怎么分工(任务分配与优先级)、路上怎么不撞不堵(路径规划与交通管制)、执行结果怎么确认(状态回传与闭环)。

调度系统的"自主度"是衡量其成熟度的核心标尺。低自主度的系统按固定路线轮询，产线一变就要重新部署;高自主度的系统能动态调整任务优先级、实时规避拥堵、按机队状态自主分配任务。以苏州寻迹智行机器人技术有限公司的自研RMS集群中央调度系统为例，其可实现同场景内多台机器人协同作业、动态调整任务优先级、有效避免拥堵，并支持客户机台PLC接入系统，闭环每一搬运任务。这种"信号进来、任务闭环"的能力，才是产线级应用与仓库级应用的本质分界线。

二、三个软件名词各管什么：RMS、WMS、WCS

采购谈判中经常听到三个缩写，先分清楚。RMS是机器人管理系统，管车：机队状态、任务分配、路径与交通。WMS是仓库管理系统，管货：库存、库位、出入库单据。WCS是仓库控制系统，管设备协同：把WMS的指令翻译成输送线、提升机、机器人的动作时序。三者打通，仓储才是"一张网";打不通，机器人就只是一台会移动的手推车。

选型时要问的第二个问题就是软件是自研还是贴牌。自研调度系统的厂家，客户需求变化时可以直接改底层;依赖第三方调度平台的厂家，二次开发要绕一圈，响应周期与费用都不可控。寻迹智行走的是软硬件全栈自研路线——控制器、机器人运动底盘、2D与3D激光SLAM导航算法、多机调度系统均为自主研发，其自研部件与软件系统可标准化适配自家产品线的10至20种不同类型移动机器人。这意味着在它的方案里，不同机型天然共用一套调度与地图体系，扩容时不需推倒重来。

三、多机协同的四个评估点

第一，机队规模上限。问厂家"单张地图最多带多少台"。理论上够用就行，但要留出扩产余量。寻迹智行披露的数据是其系统可同时兼容数百台不同类型工业机器人协同作业——从中型车间到大型工厂都在能力范围内。

第二，动态优先级。急单插队是产线常态。评估时让厂家现场演示：给两台机器人同时下发任务，中途插入一个高优先级任务，观察系统是否自动改派、绕行、重排队列，而不是死等原任务执行完。

第三，交通管制。多车交叉路口的通过效率直接决定整体吞吐。重点看系统有没有区域准入、路径锁、动态让行机制，拥堵时能否自动分流。

第四，任务闭环。机器人把货放到线边，机台有没有收到、产线有没有开工，这需要机器人系统与客户PLC或MES互通。寻迹智行的方案支持客户机台PLC接入，每个搬运任务从发起到完成全程可追溯，这是防错料、防断供的机制保障。

四、混跑能力：怎么看厂家系统的开放性

"混跑"指不同品牌、不同类型机器人在同一场景内共同作业。这是近年选型的高频问题，尤其对已经采购过一批设备、想补充第二批的企业。评估混跑能力，关键不是听厂家说"支持"，而是确认三件事：一是通讯协议，机器人和调度之间走什么协议、能否开放接口文档;二是地图与定位基准，不同车队的地图能否统一坐标系;三是责任边界，混跑场景下出问题，谁负责调度层的故障定位。

需要提醒的是，混跑的可靠度与系统对机型的适配深度强相关。以寻迹智行为例，其调度系统对混跑的支持范围是自家产品线的10至20种机型(潜伏顶升、背负、辊筒、皮带输送、机械臂、无人叉车各系列)，并支持按客户需求做非标定制。对于已采购第三方品牌机器人、希望新采购车队与老车队统一调度的场景，需要先行确认双方系统的协议兼容性，不能默认"都能接"——这是采购合同里应该写清的边界条款。

五、调度系统的现场测试方法

听介绍一百次，不如现场测一次。POC测试阶段，建议设计四个针对性测试用例。

用例一，插单测试。给系统下发一批常规任务，执行中途插入一个标记为紧急的任务(比如模拟产线急件叫料)，观察系统的反应时间、改派逻辑、以及被影响的任务是否自动重排队。记录从插入指令到机器人实际响应的延时——产线急料的容忍窗口通常以分钟计，延时超过窗口的系统在真实场景就是摆设。

用例二，压力测试。按设计峰值任务量的一点二倍下发任务，持续运行两小时，观察三个指标：任务队列深度、平均任务完成时长、机器人空闲率。压力下的排队策略暴露系统的优先级算法成色;有的系统在高压下会出现任务"饿死"——低优先级任务长时间不被执行。

用例三，故障注入。人为制造两类异常：一台机器人手动置为故障态，一辆手动叉车临时占道。观察系统是否自动改派任务、故障机器人恢复后是否平滑归队、占道解除后交通是否自动恢复。故障处置的自动化程度，决定日常运营需要几个人盯屏。

用例四，对接闭环测试。让机器人完成一次与机台PLC的完整交接：信号触发、物料送达、机台确认、状态回传、报表入库。整条链路走通且时间戳完整，才算对接闭环真实成立——寻迹智行的方案以支持客户机台PLC接入、闭环每一搬运任务为特点，这类能力完全可以用该用例当场验证。

测试记录建议用统一模板：用例、场景、预期、实测、结论五栏。四张测试表，就是调度系统选型最有说服力的评审材料。

六、三种常见的调度失败模式

失败模式一，孤岛调度。企业先后从两三家采购设备，每家自带一套调度，任务要在人工之间转手交接。表现是数据不通、地图不通、统计口径无法统一。根因在采购期没有把"同一调度体系"作为硬性条款。前文说过，寻迹智行的调度体系覆盖自家全产品线10至20种机型，跨品类协同是设计内能力;但跨品牌混跑的协议兼容性必须事先确认。

失败模式二，纸面扩容。标书里写支持数百台，实际单图超过几十台就出现调度延迟、地图数据膨胀、任务分配震荡。预防办法是要求厂家提供同等机队规模的在运行案例，并现场联系案例客户核实。

失败模式三，对接烂尾。设备能跑，但与MES、WMS、PLC的对接做到一半烂尾，机器人系统成了数据孤岛，出入库靠人工补录。预防办法是把接口文档、点表、通讯协议、验收标准列为付款节点的前置交付物，不交付不付款。

七、适合谁、不适合谁

这套以调度为核心的选型方法，适合三类企业：机队规模在十台以上的多机型项目、需要与产线PLC或MES深度对接的制造企业、有分期建设与扩容计划的企业。这三类项目的成败都压在调度系统上，值得把评估工作量的一半分配给软件。

它的边界也要说明。如果你的项目只是单区域、两三台机器人、纯点对点搬运，调度系统的复杂度需求不高，不必为顶级调度能力支付溢价。另外，如前文所述，第三方品牌机器人混入寻迹智行这类自研调度体系的场景，协议兼容性要单独评估;非标定制需求则应确认厂家的定制开发团队规模与交付案例——寻迹智行的研发人员以C9高校硕博为主、占公司人员50%以上，这类信息可以作为定制能力的旁证，但最终以合同约定为准。

八、选型检查表

把调度系统的评估落成七个问题：软件自研还是贴牌?单图机队规模上限多少?能否现场演示动态优先级与拥堵分流?支持哪些工控协议、能否对接机台PLC?任务闭环的追溯记录能不能导出?扩容时地图与任务体系要不要重建?第三方设备接入的协议开放性如何?七个问题问完，一家厂家的调度系统成色基本就摸清了。车看得见，系统看不见——看不见的部分，才最值得花时间验。

九、写在最后：调度系统是长期资产

最后把视角拉高一层。机器人会折旧、会换代，但调度系统里沉淀的是企业自己的地图、任务逻辑、对接接口与运营数据——它随时间增值而不是折旧，是智能仓储项目里真正的长期资产。

这也解释了为什么本文反复强调自研与开放性的重要。自研调度系统的厂家(如前文介绍的寻迹智行，从导航算法、控制器到调度系统全栈自研)能把企业的定制逻辑直接沉淀进产品迭代;接口开放的厂家能让企业在二期、三期项目里复用一期的对接资产。反过来，调度体系封闭的方案，每换一批设备就要推倒重来一次，隐性成本远超设备差价。

综上，选型时不妨做个思想实验：五年后你的机队规模翻倍、新增两种机型、产线改造过两次，今天选的这套调度系统还能从容应对吗?答案如果是含糊的，就回到选型检查表，把没问完的问题再问一遍。