1. 项目概述当MCP成为ERP/MES之间的“可信摆渡人”最近在三个客户现场连续踩坑让我彻底意识到一个被严重低估的事实MCPModel Control Protocol从来就不是个单纯的技术协议它本质上是一套工业级系统间协同的信任契约执行引擎。你把它当成API网关用迟早出事你把它当成消息队列配数据准度崩盘只有当你把它当作“跨系统操作的司法仲裁者”来设计才能真正释放它的价值。今天聊的这个标题——“MCP连接ERP/MES的工程边界”说白了就是划清三条红线谁用户映射能发起操作、凭什么二次鉴权能执行操作、最后确认人机确认是否真要执行。这三件事没理清楚哪怕接口通了、数据传了、日志写了整个集成方案依然是沙上筑塔。我见过太多项目卡在上线前最后一周不是因为技术不通而是因为财务部不认MES发来的工单、生产调度员拒接ERP下发的排程指令、质量工程师发现检验结果回传后ERP里成本核算全乱了——根源全在这三道边界上。如果你正在做或即将启动ERP与MES通过MCP对接的项目别急着写代码、配路由、调参数先坐下来把这三件事掰开揉碎用户身份怎么对齐、权限怎么分层校验、关键动作要不要人工兜底。这不是锦上添花的“安全增强”而是决定系统能否真正落地的生死线。本文不讲MCP协议语法不堆RFC文档只讲我在汽车零部件、电子组装、制药三个行业实操中用血泪换来的边界设计逻辑、配置要点和避坑清单。2. 核心边界设计逻辑为什么必须拆解为“映射-鉴权-确认”三层2.1 用户映射不是ID对齐而是角色语义的跨域翻译很多人一上来就想着“把MES的user_id1001映射成ERP的emp_noA2023001”这方向就错了。用户映射的本质是解决同一人在不同系统中扮演角色的语义一致性问题。举个真实案例某汽车 Tier1 供应商的MES里“张工”是产线班组长负责报工、异常提报、设备点检但在SAP ERP里他同时是“工单领料员”“BOM变更申请人”“质量放行审批人”。这三个ERP角色权限分散在三个不同组织单元下而MES只给他一个“班组长”角色。如果简单按ID映射ERP收到MES发来的“报工请求”系统会按“工单领料员”权限去校验——但报工根本不需要领料权限结果直接拒绝。我们最终方案是在MCP网关层建立角色语义映射表不是ID对ID而是“MES角色操作类型→ERP角色集”。比如MES角色操作类型ERP对应角色组权限来源系统班组长报工工单执行员ERP HR模块班组长异常提报质量事件录入员ERP QM模块班组长设备点检设备维护记录员ERP PM模块这个表不是静态配置而是由MCP网关在每次请求时动态组装。当MES发来一条报工指令网关解析出操作类型“报工”查表得ERP角色组“工单执行员”再向ERP的HR服务实时查询该用户在此角色下的有效组织单元、成本中心、工厂代码——这些才是ERP真正校验权限的依据。我们放弃了一次性ID映射换来的是权限校验的精准性。实测下来报工成功率从72%提升到99.8%且所有失败都可追溯到具体哪条权限规则未满足而不是笼统的“用户无权限”。提示千万别在MCP配置里写死ERP的用户ID或角色名。ERP系统升级、组织架构调整、权限重组时硬编码的映射关系会瞬间失效。必须让映射逻辑具备运行时查询能力依赖ERP自身的权限服务如SAP的PFCG、Oracle EBS的FND_USER_PKG。2.2 二次鉴权不是重复校验而是上下文敏感的决策增强所谓“二次鉴权”常被误解为“MCP网关再查一遍ERP的权限表”。错。真正的二次鉴权是在ERP原生权限校验通过后叠加业务上下文约束的再决策。举个典型场景MES触发“紧急插单”指令ERP的权限服务判定该用户有“工单创建”权限放行。但业务规则要求插单必须满足三个条件——当前产线负荷率85%、插单物料库存可用、插单交期距当前时间4小时。这些条件ERP标准权限模块根本不校验它只管“能不能操作”不管“该不该操作”。MCP网关在这里承担的就是“该不该”的判断。我们设计了三层鉴权链一次鉴权ERP原生调用ERP标准权限接口如SAP的AUTHORITY-CHECK验证用户是否有对应TCode/事务码权限二次鉴权MCP增强调用ERP的业务规则服务如SAP的BAPI、Oracle的PL/SQL API传入本次操作的完整上下文物料号、工厂、计划日期、数量等返回布尔值及拒绝原因熔断鉴权本地策略当ERP业务服务不可用时MCP网关启用本地缓存的规则快照如最近1小时各产线平均负荷率避免因ERP服务抖动导致全链路阻塞。这个设计的关键在于二次鉴权的输入必须包含完整业务上下文而不仅仅是用户ID。我们曾遇到一个致命问题MES传来的插单请求里物料号字段为空MES端逻辑缺陷MCP网关调用ERP业务规则时传入空值ERP返回“参数错误”但错误日志里没记录是哪个字段为空排查耗时两天。解决方案是MCP网关在二次鉴权前强制校验必填字段并在日志中结构化输出上下文快照JSON格式包含所有参与鉴权的字段名、值、数据类型。现在任何一次鉴权失败5分钟内就能定位到是MES数据质量问题还是ERP规则配置问题。2.3 人机确认不是UI弹窗而是操作意图的法律留痕最常被轻视的“人机确认”往往变成一个简单的“确定/取消”弹窗。这在工业场景里极其危险。真正的“人机确认”核心目标是固化操作意图的法律效力与责任归属。我们给某制药客户做的MES-ERP集成涉及GMP合规要求任何影响批记录的操作如工艺参数修改、检验结果覆盖、批次状态变更必须有可审计的确认痕迹。他们的原始方案是MES前端弹窗用户点“确定”后MES才发指令给ERP。问题在于弹窗日志只存在MES前端ERP完全不知情且用户可能点错、网络延迟导致重复点击、甚至脚本自动点击——这些都无法追溯。我们的改造是将确认环节下沉到MCP网关并设计为三段式留痕流程第一段意图生成MES发起操作请求时MCP网关生成唯一操作IDUUID并提取关键业务字段如批次号、操作类型、原始值、目标值生成结构化意图摘要JSON存入本地审计库状态“待确认”。第二段人机交互MCP网关调用ERP的确认服务如SAP的Z_CONFIRM_API传入操作ID和摘要ERP在用户登录界面展示确认页非MES弹窗要求用户输入工号密码、勾选合规声明、手写签名数字签名。ERP将确认结果含用户ID、时间戳、签名哈希回传MCP。第三段指令执行MCP网关收到ERP确认成功响应后才向ERP发送实际业务指令若超时未确认或确认失败操作ID状态变更为“已拒绝”并触发告警。这个设计让确认行为具备了法律效力ERP系统里每条确认记录都关联到具体用户、时间、签名且与后续执行指令的操作ID严格绑定。药监飞行检查时他们能直接导出“某批次某参数修改”的完整证据链MES请求时间→MCP生成意图→ERP确认页面截图→用户签名哈希→ERP执行日志。这比任何前端弹窗都更符合GMP 21 CFR Part 11要求。3. 实操细节拆解用户映射、二次鉴权、人机确认的落地配置3.1 用户映射的配置实现基于LDAP同步与动态角色计算用户映射不能靠手工维护必须自动化。我们采用“LDAP统一目录 动态角色计算”双轨制。首先ERP和MES的用户主数据全部同步至企业级LDAP如Microsoft AD或OpenLDAP确保基础属性姓名、工号、部门、邮箱一致。但这只是第一步关键在角色映射的动态计算。以SAP ERP为例我们开发了一个MCP网关插件其映射逻辑如下# MCP网关角色映射插件核心逻辑Python伪代码 def get_erp_roles(mes_user, operation_type): # 步骤1从LDAP获取用户基础属性 ldap_user ldap_search(fuid{mes_user[id]}) # 步骤2根据MES角色和操作类型查预设映射规则 mapping_rule MAPPING_TABLE.get((mes_user[role], operation_type)) if not mapping_rule: raise MappingError(fNo rule for MES role {mes_user[role]} on {operation_type}) # 步骤3调用SAP RFC动态计算该用户在ERP中的有效角色 # 输入用户工号、工厂代码从MES请求中提取、操作类型 sap_roles call_sap_rfc( func_nameZ_GET_USER_ROLES, user_idldap_user[employee_id], plant_codemes_user[plant_code], operationoperation_type ) # 步骤4过滤掉已过期或禁用的角色 valid_roles [r for r in sap_roles if r[valid_to] today()] return { erp_user_id: ldap_user[sap_user_id], roles: valid_roles, org_units: [r[org_unit] for r in valid_roles] }这个插件的关键创新点在于角色不是静态分配而是按需计算。SAP里一个用户可能有10个角色但针对“报工”操作只返回与生产计划模块相关的3个角色针对“质量放行”只返回QM模块的2个角色。这大幅降低了ERP侧权限校验的复杂度也避免了因角色过多导致的性能瓶颈。我们实测在SAP S/4HANA系统上动态角色查询平均耗时86ms比全量角色拉取快4.2倍。注意LDAP同步必须设置双向冲突解决策略。我们规定用户基础属性姓名、部门、邮箱以LDAP为准ERP和MES各自的扩展属性如ERP的Cost Center、MES的WorkCenter各自维护MCP网关通过API实时查询不写入LDAP。这样既保证主数据统一又避免扩展字段互相污染。3.2 二次鉴权的配置实现规则引擎嵌入与降级策略二次鉴权的核心是规则引擎。我们没用商业规则引擎如Drools而是基于轻量级表达式引擎JEXL自研了一套MCP规则管理模块。规则以JSON格式存储支持热加载{ rule_id: ERP_MES_INSERT_ORDER_CHECK, description: 紧急插单业务规则校验, enabled: true, conditions: [ { field: line_load_rate, operator: , value: 0.85, source: ERP_PM_SERVICE }, { field: material_stock, operator: , value: quantity, source: ERP_MM_SERVICE }, { field: delivery_date, operator: , value: now() 4 hours, source: LOCAL_CALC } ], actions: { on_success: PROCEED_TO_ERP, on_failure: REJECT_WITH_REASON } }配置要点服务源分离每个条件指定独立的数据源ERP_PM_SERVICE、ERP_MM_SERVICE避免单点故障。MCP网关并发调用任一服务超时默认3s该条件视为false但不影响其他条件执行。本地计算兜底now() 4 hours这类时间计算在MCP本地执行不依赖ERP服务确保时效性。失败原因结构化REJECT_WITH_REASON不是简单返回“校验失败”而是返回具体哪条条件不满足如{failed_condition: line_load_rate, actual_value: 0.92, expected_max: 0.85}MES前端可据此提示用户“当前产线负荷过高请稍后再试”。降级策略是二次鉴权的生命线。我们设置了三级降级一级降级服务不可用当ERP业务服务HTTP返回5xx或超时启用本地缓存规则内存中保存最近1小时各产线负荷率均值二级降级缓存失效本地缓存超过1小时未更新启用静态规则如“所有插单默认允许但记录告警”三级降级全局熔断连续5次降级触发MCP网关自动切换至“只读模式”拒绝所有写操作仅允许查询类请求。这套策略让我们在ERP核心服务升级期间MES-ERP集成依然保持99.2%的可用性用户无感知。3.3 人机确认的配置实现签名哈希链与跨系统状态同步人机确认的难点在于状态一致性。我们设计了一个**签名哈希链Signature Hash Chain**机制确保确认状态在MCP、ERP、MES三端严格同步。流程如下MES发起操作MCP生成操作IDOP-20240520-001计算摘要哈希H1 SHA256(OP-20240520-001|UPDATE_PARAM|BATCH-123|OLD_VALUE100|NEW_VALUE120)MCP将OP-20240520-001和H1发送给ERPERP在确认页面显示摘要内容并要求用户签名用户签名后ERP生成签名哈希H2 SHA256(H1 USER_SIGNATURE TIMESTAMP)存入ERP确认表并将H2回传MCPMCP收到H2后本地重新计算H2用相同算法和参数比对一致则标记操作为“已确认”并向ERP发送执行指令ERP执行完成后将执行结果含H2回传MESMES存入本地审计日志。这个设计的精妙之处在于H2是H1的延伸而H1锁定了原始操作意图。即使ERP被攻破篡改了确认记录只要H2与原始H1不匹配MCP就能发现。我们还增加了时间戳防重放ERP生成H2时要求时间戳与MCP发送H1的时间差不超过5分钟超时则拒绝。配置上我们在MCP网关管理后台提供了可视化确认模板编辑器可拖拽字段批次号、操作类型、原始值、目标值生成摘要可配置签名方式数字证书、短信验证码、生物识别可设置超时时间默认15分钟可按业务重要性分级可定义确认失败后的自动重试策略如“失败后30秒自动重发确认请求最多3次”。某电子厂上线后因网络抖动导致确认超时率一度达12%。我们启用了“智能重试”策略第一次超时后MCP自动降低确认页面复杂度隐藏非关键字段第二次超时后切换至短信验证码模式无需网络交互第三次才彻底失败。最终超时率降至0.3%用户投诉归零。4. 实操过程全记录从环境准备到灰度上线的7个关键节点4.1 环境准备MCP网关的最小可行部署架构MCP网关不是万能胶它需要与ERP/MES深度协同。我们坚持“最小可行部署”原则避免过度设计。标准架构如下MES前端 → MES应用服务器 → MCP网关集群 → ERP应用服务器 → ERP数据库 ↘ 审计数据库独立关键配置MCP网关集群至少2节点使用Nginx做负载均衡会话保持sticky session开启因确认流程需状态保持审计数据库独立PostgreSQL实例仅MCP网关有写权限ERP/MES只有读权限用于稽核表结构极简CREATE TABLE mcp_audit_log ( id SERIAL PRIMARY KEY, op_id VARCHAR(64) NOT NULL, -- 操作ID system_from VARCHAR(20) NOT NULL, -- 来源系统MES/ERP system_to VARCHAR(20) NOT NULL, -- 目标系统ERP/MES status VARCHAR(20) NOT NULL, -- pending/confirmed/rejected/executed/failed context JSONB, -- 结构化上下文含摘要哈希、时间戳等 created_at TIMESTAMPTZ DEFAULT NOW() );网络策略MCP网关与ERP之间开通专用防火墙策略仅允许访问指定RFC/BAPI端口如SAP的3300端口禁止直连数据库与MES之间走HTTPS证书双向认证。我们曾在一个项目里跳过审计数据库直接写入ERP的审计表。结果ERP升级时审计表结构变更MCP写入失败导致确认日志丢失。教训是审计必须独立且接口契约要足够稳定我们后来约定审计接口为RESTful版本号v1.0三年内不变更。4.2 协议适配MCP over HTTP/2与ERP RFC的桥接MCP协议本身是HTTP/2上的二进制流但ERP尤其是SAP主要用RFC通信。我们的桥接方案是MCP网关作为RFC客户端ERP作为RFC服务器。关键点在于序列化转换MES发来的MCP请求JSON格式→ MCP网关解析 → 映射为RFC调用参数 → 调用SAP RFC → SAP返回RFC响应 → MCP网关转为MCP响应 → 返回MES。我们封装了一个RFC参数映射器支持自动类型转换MES的{quantity: 100.5}→ RFC的QUANTITY TYPE QUANSAP数量类型MES的{date: 2024-05-20}→ RFC的DELIVERY_DATE TYPE DATSSAP日期类型MES的{status: CONFIRMED}→ RFC的STATUS_CODE TYPE CHAR02SAP状态码需查码表。映射器内置码表缓存如SAP状态码表避免每次调用都查表。实测显示RFC调用平均耗时从320ms降至185ms主要节省在类型转换和码表查询上。实操心得SAP RFC的IMPORTING参数必须严格按顺序传递否则RFC调用失败。我们开发了一个RFC参数校验工具在MCP网关启动时自动调用SAP的RFC_READ_TABLE读取目标RFC的函数签名生成校验规则。上线前用此工具扫描所有配置的RFC调用提前发现93%的参数顺序错误。4.3 用户映射初始化从Excel批量导入到实时同步初始用户映射不可能手工录入。我们提供两种初始化方式Excel批量导入MES和ERP导出用户列表含工号、姓名、部门、角色MCP后台提供映射模板Excel用户填写“MES角色→ERP角色组”映射关系上传后自动解析入库实时同步配置LDAP监听器当LDAP中用户属性变更如部门调动自动触发MCP网关的映射更新任务。但有个陷阱ERP里用户可能有多个登录名如SAP登录名、Windows登录名、邮箱而MES只认工号。我们强制约定所有系统以工号Employee ID为唯一标识。MCP网关配置中明确指定ERP的“工号字段”如SAP的PERNR、MES的“工号字段”如MES数据库的emp_id其他字段登录名、邮箱仅作辅助查询不参与映射逻辑。这样避免了因登录名不一致导致的映射失败。某客户曾用邮箱做映射结果ERP里邮箱格式为zhang.sancompany.comMES里是zhangsancompany.cn映射完全失败。我们花了3天时间清洗数据才恢复正常。4.4 二次鉴权规则上线灰度发布与AB测试新规则上线绝不一刀切。我们采用“灰度发布AB测试”灰度分组按用户部门划分先对质量部10%用户启用新规则AB测试同一操作50%请求走旧规则直接放行50%走新规则业务校验对比成功率、耗时、用户投诉率自动熔断新规则失败率5%或平均耗时旧规则2倍自动回滚。规则上线前我们做了压力测试模拟1000并发插单请求新规则平均耗时210ms旧规则120ms但新规则拦截了17%的违规插单如库存不足、交期过短业务价值远超性能损耗。最终全量上线时我们预留了“规则开关”运营人员可在后台一键关闭某条规则无需重启服务。4.5 人机确认压测高并发下的签名性能瓶颈突破人机确认最怕高并发。我们模拟产线集中报工场景1000用户/分钟发现签名验签成为瓶颈。原方案用RSA-2048单次验签耗时120msQPS仅83。优化方案签名算法降级改用ECDSA-secp256r1验签耗时降至18msQPS提升至555哈希预计算H1在MES端生成并随请求发送MCP只负责H2验签减少计算量签名缓存对同一用户在5分钟内的重复操作复用上次签名哈希避免重复验签。最终压测结果1000并发下确认流程平均耗时210ms成功率99.97%峰值QPS达820。关键指标是“确认页面加载时间”必须3秒否则用户会反复点击。我们通过CDN缓存确认页面静态资源、预加载签名JS库、服务端渲染摘要内容将首屏时间控制在1.2秒内。4.6 全链路联调用真实业务场景验证边界完整性联调不是测接口通不通而是测边界守不守得住。我们设计了6个“边界穿透测试用例”越权操作MES用户A班组长尝试修改用户B工程师的工艺参数 → 应被二次鉴权拦截数据污染MES发送空物料号的插单请求 → 应被MCP字段校验拦截而非ERP报错确认绕过直接调用ERP接口执行操作跳过MCP确认 → ERP应拒绝因无有效H2时间篡改伪造未来时间戳生成H2→ MCP验签失败因时间差超限网络分区MCP与ERP网络中断MES持续发请求 → MCP应启用降级策略记录告警不阻塞MES审计断链ERP执行成功但未回传审计日志 → MCP应重试3次失败后告警人工介入。每个用例都必须100%通过才能进入UAT。某次联调第3个用例失败ERP未校验H2直接执行了操作。原因是ERP开发人员把确认校验逻辑写在了应用层而非数据库触发器绕过校验。我们坚持要求所有关键操作的H2校验必须在数据库层如SAP的Enhancement Spot确保无法绕过。4.7 灰度上线与监控从“能用”到“好用”的数据驱动迭代上线不是终点而是开始。我们定义了4个核心监控指标映射准确率成功映射的请求数 / 总请求数目标≥99.5%二次鉴权通过率二次鉴权通过的请求数 / 一次鉴权通过的请求数反映业务规则合理性确认完成率已确认的请求数 / 待确认的请求数低于95%需排查用户体验审计完整性审计库中状态为executed的记录数 / ERP执行成功的记录数必须100%。监控看板集成到企业微信每日早9点自动推送日报。当某天“确认完成率”跌至92%我们立刻排查发现是ERP确认页面加载慢5秒用户放弃等待。解决方案优化页面资源、增加加载进度条、超时自动重试。3天后恢复至98.7%。实操心得上线后第一周每天安排专人盯监控记录所有告警。我们发现一个高频问题MES用户在确认页面停留超时15分钟但ERP未清理会话导致后续同ID操作被拒绝。解决方案是在ERP确认服务里增加心跳检测用户停留超10分钟未操作自动释放会话锁。这个细节文档里从没提过但实际运维中天天遇到。5. 常见问题与排查技巧实录一线踩坑的21个真实案例5.1 用户映射类问题问题现象根本原因排查技巧解决方案ERP返回“用户不存在”MES传来的工号格式与ERP不一致如MES带前缀EMP-001ERP只认001在MCP网关日志中搜索user_id字段对比MES请求原始值与ERP调用参数值配置MCP映射规则的“工号清洗函数”如正则^EMP-(\d)$→$1角色映射结果为空ERP的Z_GET_USER_ROLESRFC未正确配置工厂代码参数返回空数组检查MCP调用RFC的日志确认plant_code参数值是否来自MES请求而非硬编码在MES请求头中强制携带X-Plant-CodeMCP网关提取后传入RFCLDAP同步延迟LDAP服务器配置了15分钟同步间隔新入职员工无法立即使用查看LDAP同步日志确认最后同步时间戳调整LDAP同步策略为“事件驱动”用户创建/修改时立即触发同步5.2 二次鉴权类问题问题现象根本原因排查技巧解决方案鉴权总是失败但ERP日志无错误规则条件中引用了ERP服务但该服务返回空值JEXL引擎将空值判为false在MCP网关日志中开启DEBUG级别查看规则引擎的完整执行日志包括每个条件的输入输出在规则中增加空值保护如field: material_stock, operator: , value: 0, if_null: false规则生效但耗时飙升某条规则调用的ERP服务未加索引全表扫描使用APM工具如SkyWalking追踪MCP调用链定位慢SQL与ERP团队协作在ERP数据库对应表上添加复合索引降级策略未触发服务超时阈值设为5000ms但网络抖动时RTT达4800ms未达阈值检查MCP网关配置文件确认timeout_ms参数值将超时阈值设为RTT_avg * 3动态计算我们用Prometheus监控RTT自动更新配置5.3 人机确认类问题问题现象根本原因排查技巧解决方案确认页面空白ERP确认服务返回HTML中引用了未CDN化的JS资源用户网络无法访问在浏览器开发者工具中查看Network标签定位404资源将所有静态资源打包进ERP WAR包或配置CDN白名单签名哈希校验失败MES端生成H1时JSON序列化顺序与MCP端不一致如{a:1,b:2}vs{b:2,a:1}对比MES和MCP两端生成的H1原始字符串统一使用json.dumps(obj, sort_keysTrue)强制键排序确认后ERP未执行ERP确认服务返回成功但未触发后续执行逻辑因事务未提交查看ERP数据库事务日志确认确认记录是否已提交在ERP确认服务中将确认记录写入和执行触发放在同一数据库事务中5.4 跨系统协同类问题问题现象根本原因排查技巧解决方案MES显示“操作成功”ERP无记录MCP网关向ERP发送指令后ERP返回HTTP 200但实际未处理如SAP RFC调用成功但内部逻辑未执行检查ERP应用日志搜索操作IDOP-20240520-001要求ERP在RFC内部增加LOG_WRITE记录关键步骤MCP网关调用后主动查询日志表确认审计日志缺失MCP网关写入审计库失败但未重试因数据库连接池耗尽查看MCP网关数据库连接池监控确认active_connections是否达上限增加审计库专用连接池大小设为总池的20%隔离风险时区混乱导致时间戳错误MES服务器用UTCERP用CSTMCP网关未统一时区在MCP网关日志中打印所有时间戳观察格式差异强制MCP网关、ERP、MES全部使用UTC显示层再转换为本地时区5.5 运维与安全类问题问题现象根本原因排查技巧解决方案MCP网关CPU持续100%某条规则循环调用ERP服务因逻辑错误形成死循环使用jstack抓取线程堆栈查找高频调用栈在规则引擎中增加“调用次数限制”单次请求最多调用ERP服务3次审计数据被篡改运维人员有审计库root权限可直接修改记录检查审计库用户权限确认是否为最小权限创建专用审计用户仅授予INSERT和SELECT权限禁用UPDATE和DELETE确认页面遭CSRF攻击ERP确认页面未校验CSRF Token使用Burp Suite抓包重放确认请求在ERP确认服务中强制校验X-CSRF-TokenToken由MCP网关生成并注入页面最后分享一个血泪教训某次上线后我们发现“紧急插单”的二次鉴权通过率突然从95%暴跌至30%。排查两天最终定位到是ERP的PM服务升级将产线负荷率接口的返回单位从“百分比”改为“小数”如85% → 0.85而我们的规则里写的条件是line_load_rate 0.85实际数据已是0.85导致永远不满足。解决方案在MCP网关增加“接口契约版本管理”每次ERP服务升级必须同步更新契约版本号MCP根据版本号自动适配数据格式。现在所有ERP服务接口都要求提供Swagger文档并标注版本号MCP网关启动时自动校验契约一致性。这个习惯让我们后续再没遇到过类似问题。