精工智能第二战区开发组在云某彩项目中完成了公司首例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请求方法改成POSTJSON body通信链路一次性打通。前后调试耗时约半天——这在接口对接类项目中属于正常范畴但如果一开始就仔细核对对方的接口文档和端口规划还能再压缩。方案定型在别人搭的框架里做改造比另起炉灶更稳联调通过后团队开了一次AGV调度方案讨论会。议题只有一个云之彩的方案能不能复用后续其他项目再有MES对接AGV的需求是从零再搭一遍还是拿云之彩的版本改讨论结果是一致倾向于后者——基于WMS原有接口体系进行改造把AGV调度功能嵌入现有的仓储调度框架内而不是新建一套独立调度系统。这个决策的核心逻辑有两个第一WMS和AGV的天然关联。原材料出入库、成品上下架本来就是WMS的管理范畴AGV的搬运任务本质上就是仓储作业的执行延伸。在WMS体系里加一层AGV调度能力业务语义上是通的。第二后续项目的可复制性。云某彩的AGV方案一旦基于WMS接口体系定型其他项目只需要调整具体的设备通信参数IP、端口、接口地址和少数业务规则如搬运优先级、超时时间就可以快速适配。不用再从接口设计、通信协议、节点拆解从头开始做一遍。苏在当周的项目记录里写了一句话“在无先例的方向上充分理解业务流转规则再做技术选型能避免陷入为技术而技术的误区。”这句话说的是AGV但本质上说的是一种能力——不只是写代码的能力而是看懂制造业生产现场怎么运转、然后把运转规则翻译成系统逻辑的能力。从一次联调到一套可复用的能力云某彩AGV项目从方案设计到四节点联调通过前后大约两周。对精工智能而言它留下的价值不只是一套能跑的接口代码而是一条经验先跑通最小闭环再考虑可复用扩展。如果一开始就追求一套完美适配所有AGV品牌、所有调度场景的“通用方案”项目可能会卡在方案阶段很久。但先聚焦云之彩的具体需求把原材料、成品、半成品、基础调度四个确定性的节点打通把接口协议、回调机制、异常处理的“模版”跑出来后续再来做参数化和扩展反而是更高效的路径。现在回头来看MES给AGV发指令这件事技术本身不复杂。复杂的是怎么让系统理解车间里“什么时候该搬、搬什么、搬去哪”这些看似常识、但写在代码里处处都是判断逻辑的生产规则。而精工智能做这件事的价值恰好就在这里——既懂MES的业务逻辑也懂WMS的仓储调度还能在两者之间搭一座桥把AGV接进来。精工智能数字化工厂制造业Online持续在场赋能企业高质量发展。