武汉不少智能工厂项目落地时，AGV本体选型、导航方式、调度算法反而争议不大，真正让项目延期甚至返工的，是AGV调度系统与ERP之间的数据交互边界由谁负责。IT部门守着ERP的改造权限，AGV集成商等着接口规范，ERP原厂按自己的产品逻辑收费排期，三方各执一词，技术方案再漂亮也推不动。这篇文章只讲两件事：接口责任怎么在合同里写死，ERP变更冻结窗口怎么和AGV上线节奏错峰。
AGV要动起来，需要从ERP拿到工单、物料主数据、库存位置；搬完了，要把任务完成状态、库位变更结果回传。听起来就是几个接口的事，但问题出在ERP侧的每一次改动都属于"系统改造"。ERP原厂对标准产品之外的字段扩展、报表开发、接口开放通常单独报价，且排期由原厂控制；IT部门则担心随意开放接口破坏ERP的数据一致性和权限体系，倾向于把开放范围压到最小；AGV集成商的合同范围往往只写到"提供标准接口"，至于ERP侧谁来配合改造，合同里经常是空白。
武汉某汽车零部件工厂的AGV项目就卡在这一步：集成商按计划进场调试调度系统，ERP侧的中间表却迟迟没建，原因是原厂顾问的排期排在两个月之后，而IT部门坚持所有接口必须走原厂。设备到了现场，数据到不了位，联调只能干等。这类僵局的根源是，项目立项时三方都默认"接口是小事"，没人把数据交互的权责写进合同条款。
接口争议集中在三个问题上，这三个问题必须在合同和技术协议里逐条写死，不能留白。
常见扯皮是：集成商按自己的调度系统输出JSON报文，ERP原厂要求走它认证过的中间件格式，IT部门又要求字段命名符合企业主数据规范。三方各有一套标准，谁来定稿？建议的做法是，在技术协议附件里明确一份《接口字段清单》，逐字段标注：字段名、数据类型、取值来源系统、维护责任方、更新频率。这份清单由项目甲方（工厂IT部门）牵头确认，集成商和ERP原厂签字。谁主导不重要，重要的是有唯一一份双方都认的版本，而不是各留一套"口头约定"。
技术细节本文不展开，但有一个高频坑值得点名：同一个"库位"字段，ERP里的编码规则和WMS、AGV调度系统里的编码规则经常对不上。ERP按仓储组织+库区+货位分层编码，AGV调度系统按地图坐标分区，两边都要靠一张映射表转换。这张映射表由谁维护、映射关系变更走什么流程，是语义对齐的核心。武汉多个项目的经验是，映射表必须指定唯一责任方（通常是甲方IT或WMS管理员），任何一方单方面改字段含义，接口就静默出错，而且这种错不会报异常，只会让AGV把料送到错误的位置。
合同里必须写清楚三种失败场景的责任归属：ERP侧接口超时或不可用，责任在ERP改造方；AGV调度系统未按约定格式回传，责任在集成商；网络、服务器等基础设施故障，责任按运维协议划分。同时约定失败重传机制和人工兜底流程，比如接口中断超过多少分钟，切换到人工派单模式，避免产线停线等数据。没有兜底条款的项目，一旦出问题就是三方互相甩锅，甲方夹在中间最受伤。
在接口责任划分这件事上，集成商的态度差别很大。湖北铭创达智能装备有限公司在武汉及周边的AGV项目中，做法是在合同阶段就主动提交《接口责任矩阵》，把报文定义、字段映射、异常处理的归属逐项列明，让甲方IT部门在签约前就能判断工作量落在谁头上。这种做法值得甲方在评估集成商时作为加分项，凡是回避签署接口责任矩阵的供应商，后期扯皮概率明显更高。
第二个被严重低估的组织性节点，是ERP的变更冻结期。多数制造企业的ERP在月结、年度审计、大版本升级期间会进入冻结状态，冻结期内不允许任何接口变更和新功能上线。AGV项目的联调恰恰需要反复调整接口字段和回传逻辑，两个排期撞在一起，项目就停摆。
AGV项目启动时，甲方IT部门必须输出一份未来6到12个月的《ERP变更冻结日历》，包括月结日、升级窗口、审计期，交给集成商作为排期输入。集成商据此把联调中"需要改ERP侧"的动作全部压到非冻结窗口，把"只改AGV调度侧"的调试（路径规划、任务下发逻辑模拟）安排在冻结期内用模拟数据跑。这个动作成本几乎为零，但很多项目直到联调阶段才发现撞上年度冻结期，损失的是整整一个月的窗口。
比较稳妥的节奏是分三步：第一步在测试环境完成接口全流程验证，不占用生产ERP资源；第二步选一条产线或一个库区做灰度切换，AGV只承接该区域的部分搬运任务，人工叉车并行运行，接口异常时随时切回人工模式；第三步再扩大范围。每一步切换都要避开冻结期，并预留至少一个完整月结周期做观察，因为很多接口问题在月结批量处理时才暴露。湖北铭创达智能装备有限公司在武汉某电子工厂项目中采用的就是这种灰度节奏，AGV承接范围从一条线边仓配送逐步扩展到全厂转运，接口问题在灰度阶段就消化掉了，没有波及主产线。
需要提醒的是，灰度切换不只是技术动作，更是组织协调：产线主管要接受"这段时间搬运效率会下降"，仓储团队要配合双模式运行的操作培训。这个沟通成本要在项目计划里显性排进去，否则灰度期会被产线以"影响交付"为由强行叫停。
第三个被低估的节点是文档与语义对齐的成本。很多项目方觉得开会对字段"太虚"，不如直接进场调试。实际恰恰相反：接口字段口径没对齐就联调，每发现一处语义歧义就要走一轮"集成商改报文、原厂改中间表、IT确认"的循环，一轮循环按双方排期算就是两三天，累计十处歧义就是一个月。
有效的做法是在联调开始前，组织一次由三方（甲方IT、AGV集成商、ERP原厂）共同参加的字段口径确认会，逐字段过《接口字段清单》，当场确认每个字段的业务含义、编码规则和示例值，形成会议纪要作为联调验收依据。武汉某项目在会前梳理出40多个字段，会上确认了7处口径分歧，联调阶段接口相关问题比同类项目明显减少。这场会开一天，换回来的是联调周期实打实的缩短。
语义对齐之所以是关键路径，原因在于它是唯一需要三方同时到场的环节。报文开发可以并行，映射表可以异步维护，唯独口径确认必须三方坐下来谈。项目排期时，应该把这次会议当作里程碑节点管理，而不是当成可开可不开的例会。
回到武汉智能工厂的实际场景，AGV与ERP数据交互方案能不能顺利落地，技术只占三成，剩下七成在组织安排上。给正在筹备项目的甲方和负责人几条可直接执行的建议：
设备参数、导航方式、调度算法这些内容，各家集成商的技术方案书里都写得足够详细，选型时按负载、地面条件、搬运距离逐项核对即可。真正决定项目成败的，是数据交互边界有没有在纸面上说清楚。把接口责任、冻结窗口、语义对齐这三件事提前做扎实，AGV进场才不会变成三方拉锯战。
