.png)
精工智能第二战区开发组在云某彩项目中，完成了公司首例MES系统对接AGV（自动导引运输车）的完整开发。在无现成方案可参考、无历史代码可复用的前提下，团队独立设计并实现了基础调度、原材料调度、成品调度、半成品调度四个核心节点的接口开发与联调，并基于WMS原有接口体系确定了可复用的方案架构。本文还原了从需求梳理到联调通过的全过程，提炼出一条“先跑通最小闭环，再做可复用沉淀”的技术落地路径。
AGV把货架从A点运到B点，看起来是一条直线。但要让MES系统告诉AGV“什么时候去哪搬什么”，这件事在精工智能内部此前没人做过。
项目提出需求：MES需要和AGV调度系统打通，由MES下发搬运任务，AGV执行完成后回传结果。张把这个任务交给了苏和李，说了一句：“方案你们自己搭，公司没有现成的代码可以参考。”
需求拆解：五个节点，先跑四个
AGV在制造场景里干的活，本质上就几类：把原材料从仓库搬到产线，把半成品从上一道工序搬到下一道，把成品从产线搬回仓库，以及车间内部的各种临时转运。但每一类的触发条件、目标地点、回传数据都不一样，不能用一个接口包打天下。
先画了一张调度节点图，梳理出五个独立节点：基础调度、原材料调度、成品调度、半成品调度、车间自动调度。每个节点的职责边界很清晰：原材料调度只管仓库到产线的物料拉动，成品调度只管产线完工到入库的搬运，半成品调度管工序间的流转衔接。
讨论中定了一条优先级策略：“先跑通前四个，自动调度延后。”理由是自动调度涉及产线节拍、设备状态、物料齐套等多变量输入，属于更复杂的决策型调度，而前四个是确定性任务，触发条件明确、执行路径固定，适合先验证通信链路和接口协议的稳定性。
接口联调：定位问题比写代码更花时间
接口开发本身不算复杂：MES这边定义任务下发接口，AGV调度系统那边对接接收指令并回传执行状态。但真正花时间的是联调阶段的通信打通。
现场的AGV调度系统使用特定端口进行通信，端口配置一开始填成了常规的HTTP端口（如8080），对方服务端根本没有监听，导致任务下发后超时无响应，回调接口迟迟收不到结果。
另一个问题是请求方法不匹配。AGV调度系统的回调接口只接受POST方式且要求JSON格式body，苏在日志里看到服务端不断返回405 Method Not Allowed，才意识到自己的请求方法设置错了。
两个问题定位后，端口改成55210，请求方法改成POST+JSON body，通信链路一次性打通。前后调试耗时约半天——这在接口对接类项目中属于正常范畴，但如果一开始就仔细核对对方的接口文档和端口规划，还能再压缩。
方案定型：在别人搭的框架里做改造，比另起炉灶更稳
联调通过后，团队开了一次AGV调度方案讨论会。议题只有一个：云之彩的方案能不能复用？后续其他项目再有MES对接AGV的需求，是从零再搭一遍，还是拿云之彩的版本改？
讨论结果是一致倾向于后者——基于WMS原有接口体系进行改造，把AGV调度功能嵌入现有的仓储调度框架内，而不是新建一套独立调度系统。
这个决策的核心逻辑有两个：
第一，WMS和AGV的天然关联。原材料出入库、成品上下架本来就是WMS的管理范畴，AGV的搬运任务本质上就是仓储作业的执行延伸。在WMS体系里加一层AGV调度能力，业务语义上是通的。
第二，后续项目的可复制性。云某彩的AGV方案一旦基于WMS接口体系定型，其他项目只需要调整具体的设备通信参数（IP、端口、接口地址）和少数业务规则（如搬运优先级、超时时间），就可以快速适配。不用再从接口设计、通信协议、节点拆解从头开始做一遍。
苏在当周的项目记录里写了一句话：“在无先例的方向上，充分理解业务流转规则再做技术选型，能避免陷入为技术而技术的误区。”
这句话说的是AGV，但本质上说的是一种能力——不只是写代码的能力，而是看懂制造业生产现场怎么运转、然后把运转规则翻译成系统逻辑的能力。
从一次联调到一套可复用的能力
云某彩AGV项目，从方案设计到四节点联调通过，前后大约两周。对精工智能而言，它留下的价值不只是一套能跑的接口代码，而是一条经验：
先跑通最小闭环，再考虑可复用扩展。
如果一开始就追求一套完美适配所有AGV品牌、所有调度场景的“通用方案”，项目可能会卡在方案阶段很久。但先聚焦云之彩的具体需求，把原材料、成品、半成品、基础调度四个确定性的节点打通，把接口协议、回调机制、异常处理的“模版”跑出来，后续再来做参数化和扩展，反而是更高效的路径。
现在回头来看，MES给AGV发指令这件事，技术本身不复杂。复杂的是：怎么让系统理解车间里“什么时候该搬、搬什么、搬去哪”这些看似常识、但写在代码里处处都是判断逻辑的生产规则。
而精工智能做这件事的价值，恰好就在这里——既懂MES的业务逻辑，也懂WMS的仓储调度，还能在两者之间搭一座桥，把AGV接进来。
精工智能数字化工厂，制造业Online，持续在场，赋能企业高质量发展。