MCP协议刚发布那阵我印象特别深工业物联网的同行群里几乎每天有人转发“AI终于能直接读PLC了”。“这是AI界的USB-C”“工业软件要被重新定义”这些话刷了一个多月。我当时是泼过冷水的在群里跟人争论过我说这东西在互联网场景可以快速铺开但在工厂里光是一个OT网络隔离就够折腾半年。一年半过去热度确实降下来了也没出现所有人预想的那种“设备全部标配MCP Server”的盛况。但说句实话我反而比当时更乐观了。真正跑起来的那批人已经找到了自己的位置他们不怎么在网上发声就是在产线边上闷头解决一个又一个实际问题。这篇分享就写写我这一年半观察到的、接触过的、亲手验证过的内容MCP协议在工业物联网领域到底是谁在用、怎么用、卡在哪、接下来往哪走。如果你是工业软件的产品经理、做设备数采和系统集成的工程师或者工厂IT/OT团队的成员正在评估要不要把MCP引入自己的项目那这篇东西应该能给你省掉不少试错时间。1. 一年半前吹的牛现在兑现了多少1.1 当时的三句口号听着都像要颠覆行业2024年底那波MCP宣传里有三句话出现频率最高工业物联网圈子尤其容易被打动。第一句是“MCP是AI界的USB-C”所有数据源、工具、业务系统都能统一接进来AI想连谁就连谁不再为每个系统单独开发接口。第二句是“让每个业务系统都变成AI的一个外设”SPC软件也好、MES也好、SCADA也好都像电脑接显示器一样一插就能用。第三句更狠直接说“做接口开发的要失业了”以后系统对接就是配一个server地址的事不需要写定制胶水代码。这三句话放在工业物联网的语境里格外戳人因为这个领域的信息化欠账太重了。大部分工厂的MES数据库字段含义只有两个老工程师知道SCADA报警记录乱成一锅粥PLC程序里的中间变量名根本看不出是干什么用的。传统做法是想给AI喂数据先花两三个月做数据清洗、接口开发、点位梳理项目还没上线客户已经没耐心了。所以MCP一出来大家都觉得终于有个标准化的东西能把这笔烂账理清楚。1.2 一年半后的真实状态口号兑现了一大半方式跟预想的不一样先说结论USB-C这个方向没错但它更像是USB-C刚普及的头两年接口标准虽然统一了很多设备却还只支持老接口你得加转接头。在工业现场这个转接头就是MCP Server。也就是说MCP协议确实成了一个公共的“接口语言”但设备侧不可能一夜之间原生支持中间层的工作量并没有消失只是从“写死的私有接口”变成了“可复用的标准化适配层”。“接口开发失业”这种话就更没影了但工作形态确实变了。以前给AI对接一个数据源要自己设计REST接口或者消息队列字段命名、鉴权方式、错误处理全凭个人发挥。现在大家做的是同一件事把工业数据包装成标准的tools和resources代码量没有少太多但可复用性、可迁移性大幅提高。我给A工厂写的一个Modbus TCP的MCP Server稍微改改点位配置就能复用在B工厂这在以前是不可想象的。热度上当然没法与刚发布时比。不过我觉得这恰恰是好事说明概念炒作期已经过了留下来的是真正解决了实际问题的部分。现在再去MCP相关的技术社区看工业话题的讨论从“MCP是什么”变成了“MCP怎么接OT数据”参与的人也从布道师变成了干活的人。2. MCP在工业语境下到底解决什么问题按说协议本身出来一年半了不该再花篇幅科普。但我发现一个很普遍的问题身边做工业物联网的同行对MCP的理解大多还停留在“就是把数据给AI用”再往深就说不清了。这一章我用大白话把这个问题讲透想直接看案例的可以跳到第四章但打算实际落地的话建议读完很多坑其实就是理解不到位埋下的。2.1 MCP本质上是给AI加了一套“外设总线”MCP的全称是Model Context Protocol模型上下文协议。它定义了一套规则一个AI客户端怎么去发现、调用外部数据源和能力。协议里有三个核心概念tools是工具对应AI可以主动调用的动作或查询resources是资源对应可以被读取的数据对象prompts是提示模板对应固定流程的复用。举一个具体场景。用户问AI“查一下3号车间的温度”AI收到这句话后会自主判断自己缺少这个数据于是决定调用一个名为query_temperature的工具把请求通过MCP协议发给对应的MCP Server。Server收到请求后去底层设备取回温度值再返回给AI。整个过程对用户是透明的用户只看到AI回答了一个数字但数据流的路径被规范了。你可以这么理解MCP Server就是一个带说明书的外设。以前给AI接数据是提前把数据全塞进AI的肚子里它读到什么取决于你喂了什么。现在给AI接一个MCP ServerAI需要的时候自己会去问这个外设要数据不再需要全部灌进上下文。这个差异是质的大模型按需取用而不是被动消化。2.2 工业数据消费长期存在的三个断层工业物联网这几年其实不缺数据传感器加上去、网口焊上去数据就哗哗往平台里流。但“数据被存下来”和“数据被AI消费”之间隔着三个断层大部分MCP项目做到一半才发现真正要解决的是这些层。协议断层最容易理解。设备侧有Modbus、OPC UA、PROFINET、S7、EtherNet/IP等一堆工业协议AI侧的接口标准却是HTTP加JSON。两边对话需要翻译MCP就是这个翻译框架的一部分。语义断层更致命。PLC的寄存器地址40001到底是温度还是压力只有点位表知道。就算接口全通了AI拿到一个数字4012它也不知道单位是摄氏度还是帕斯卡。MCP Server能把原始点位映射成有业务含义的tool比如query_temperature和query_pressureAI拿到的是“懂业务”的接口而不是冷冰冰的寄存器编号。权限断层容易被忽略。AI通常被当成一个只读型应用但传统数采平台动不动就给运维账号这个账号权限太大没人敢交给AI。MCP Server可以在应用层做细粒度的只读控制只暴露AI该看的东西这是它能被OT安全团队接受的一个重要原因。2.3 与OPC UA、MQTT不是替代关系是叠加这个问题我几乎每次交流都会被问答案是MCP不替代OPC UA也不替代MQTT三者各管一段经常一起用。OPC UA解决的是设备之间、设备与上位机之间的通信与信息建模问题跑在工业网络里讲究实时性和确定性。MQTT解决的是海量数据在不可靠网络下的传输问题发布订阅模式适合遥测数据回传。MCP解决的是AI应用如何按需访问数据和工具的问题属于应用层通常部署在办公网或云端的AI基础设施上。打个比方OPC UA是连接车间设备的工业总线MQTT是往数据中心运数据的卡车MCP则是AI去数据仓库取货时手里拿的取货码和开箱工具。三者完全可以串起来用这也是目前工业落地的常见架构设备通过OPC UA或MQTT把数据送到边缘网关边缘网关上的MCP Server把这些数据以tools方式暴露给上层AI。提示听到有人说“MCP会取代OPC UA”基本可以判断他没做过工业现场。两者解决的根本不是同一个问题不存在谁替代谁。3. 真正在用的是这四类人以及他们的真实用法回到标题那个问题到底谁在用。我这一年半接触下来MCP在工业物联网的落地不是均衡铺开的而是被四类人各自找到了切入点。他们的出发点、切入场景、对MCP的理解方式都不一样但有一个共性都不是冲着“追逐新技术”去的而是奔着解决具体问题去的。3.1 系统集成商最积极的一批拿MCP当AI外挂工具箱系统集成商是最早动手的群体原因很简单他们常年帮工厂做数采、做SCADA、做数据中台最清楚客户手里那一堆老旧设备有多难搞。我认识一家做汽车零部件产线数采的集成商客户有一批西门子S7-300的老PLC上了十年原厂技术支持都快没了。以前客户想看OEE报表他们得专门开发一套Web界面或者定时把数据推到BI工具里。现在他们的做法是在边缘网关里部署一个MCP Server把“读取关键设备状态”“查询今日产量”“统计报警次数”这些能力包装成MCP tools再对接进大模型对话应用。客户管理人员直接在对话框里问“今天3号线为什么停线了”Agent自动调取报警信息和历史工单返回一份带排查建议的摘要。对集成商来说最大的收益不是技术上的炫酷而是方案的可复制性。同样的MCP Server换一套点位配置就能迁移到下一个客户售前试用周期从几周压缩到几天。这在报方案的时候是非常实在的竞争优势甲方看到你用自然语言就能查产线数据感官上比一堆传统报表强太多。3.2 设备OEM厂商给设备出厂就配一个“AI说明书”第二类积极的使用者是设备制造商。注意不是那种几百亿营收的大厂而是有研发实力、以卖设备整机为主的中型OEM。他们的思路很有意思而且非常“生意经”。你想一台设备卖出去客户用得好不好直接决定后面会不会回购配件、续保服务。但设备的数字化能力通常很弱使用手册厚厚一本故障代码几百条操作工基本不翻一出问题就打售后电话。OEM厂商的售后成本居高不下客户体验也没有多好。现在一些OEM的做法是在设备附带的边缘网关或触屏一体机上跑一个MCP Server把设备实时状态、故障字典、维护手册全部通过MCP暴露出来。然后在设备旁边贴一个二维码客户扫码就能用AI助手直接对话“E102报警是什么意思”“这台设备本周有没有异常趋势”所有回答都通过MCP Server落到设备真实数据和故障字典上不是模型凭空编的。这类应用的价值不在技术门槛多高而在于它把售后工程师的重复性咨询自动消化掉了客户也觉得新设备更“智能”了。3.3 工业软件平台公司把MCP当成API的自然语言入口第三类是各种工业软件平台公司做MES、EAM、能源管理、数字孪生的都有。他们原本都有自己的API接口但客户用得很少原因很现实调用API需要开发能力大部分工厂的工艺员和车间主任不会写代码。这些公司的优化方向是在自家平台上架一个MCP Server把现有查询类API包一层然后接入大模型对话界面。客户就能用自然语言完成以前得写代码才能做的事比如“把二季度各车间能耗做个对比”“找出本周所有超过48小时的工单”。这套东西的底层还是原有API但交互方式完全变了。MCP对这类公司的另一个价值在于内部交付。实施工程师最头疼的就是调试各客户环境的接口差异现在很多厂商内部已经用基于MCP的Agent辅助实施问问题就能定位配置项问题。这个变化不对外宣传但实际使用率非常高几乎是润物细无声地替代了部分内部工具。3.4 工厂IT/OT融合团队自己动手从内部知识库干起第四类人可能会让一些读者意外不是大型央企而是一些拥有IT/OT融合团队的中型制造企业集中在电子、锂电、化工这类数字化基础相对好的行业。他们最先切入的场景不是实时设备数据而是内部知识库。原因很实在设备数据接入要动工控网络要走一堆安全审批知识库则简单得多。他们把设备维修手册、故障代码表、SOP文档、历史检修报告整理好通过MCP Server接进企业内部的AI助手工人直接用企业微信就能提问。效果出乎意料得好一线维修工以前遇到问题要翻三份文档现在直接问AI给的是带排查步骤的结构化答案。我很欣赏这类团队的一点是他们懂得从“低风险数据”切入绕开安全审批的深水区等项目跑顺了再逐步申请接入实时设备数据。这个策略特别务实也符合工业环境下“软件迭代”的现实逻辑。4. 已经跑通的三个场景和一段可以抄作业的最小实现上面讲的是谁在用接下来讲用在哪儿。我挑了三个实际见到过、验证过的场景最后一个还附了一段可以本地跑起来的最小代码。工业场景讲究可复现这段代码一定得让你亲手跑通才算把MCP在工业数据里的工作方式讲明白。4.1 场景一对话式OEE与产线指标问询OEE是工厂最关心的指标之一但口径复杂涉及可用率、性能率、良率的拆解。传统做法是上个看板挂在大屏上但看板不会解释“为什么OEE跌了”人得自己对着数据找原因。现在集成商的做法是把OEE计算逻辑封装成MCP toolAI被问到“今天2号线的OEE为什么掉到70%”时自动调取设备状态、停机记录、产量数据返回的不只是一个数还会给出“可用率下降是因为15点20分有40分钟换型停机”这样带根因分析的结论。用户不需要自己打开多个系统去对照这是传统报表完全做不到的。4.2 场景二故障代码反查设备报错维修工的第一反应是翻故障代码表。这个表可能是Excel可能是PDF可能是老师傅脑子里的经验。MCP Server可以把这个故障知识库结构化AI收到“E102报警”就查表返回含义、可能原因、处理步骤。这个场景落地最容易因为知识库数据相对静态不需要实时取数对网络和安全的要求最低。有家电子制造厂已经把这个功能接进了班组的平板电脑上老师傅和新人看到报错先问AI而不是电话求助故障处理的平均时间缩短了不少。别小看这个不起眼的场景它是目前投入产出比最高的落地方式。4.3 场景三巡检记录自动生成与异常摘要巡检工在手机上报了几十条记录值班长想知道今天有什么异常。以前是靠人翻聊天记录和Excel表现在Agent通过MCP Server查询巡检数据接口自动汇总出“今日共报异常6条其中2条与液压系统相关建议优先处理”。把它理解成把最枯燥的重复性整理工作交给机器数值不创新、不编造只做归类与摘要工厂很愿意接受这种边界清晰的AI应用。4.4 一个改改就能用的MCP Server示例下面这个示例建议在本地直接跑一遍能跑通的话对MCP的理解会上一个台阶。它把一台Modbus TCP设备的几个寄存器读数包装成MCP tools然后用任意支持MCP的客户端调用。环境准备很简单Python 3.10以上安装两个库pip install fastmcp pymodbus然后新建一个server.py文件# server.py # 基于 fastmcp 的最小示例把 Modbus TCP 设备的数据暴露为 MCP tools from fastmcp import FastMCP # 创建 MCP server客户端会看到这个服务名 mcp FastMCP(modbus-demo-server) # 这里模拟从设备读到的一组实时数据 # 真实场景中用 pymodbus 通过 Modbus TCP 读取寄存器即可 DEVICE_DATA { 温度: 36.5, # 对应从站寄存器地址 0x0001 压力: 2.8, # 对应从站寄存器地址 0x0002 今日产量: 1240, # 对应累计寄存器 运行状态: 运行, # 从状态寄存器解析 } mcp.tool() def read_device_value(name: str) - str: 读取设备实时数据参数name可选温度、压力、今日产量、运行状态 if name in DEVICE_DATA: return f{name}: {DEVICE_DATA[name]} return f未知点位: {name} mcp.tool() def read_all_points() - str: 一次性读取当前设备所有关键点位 return , .join(f{k}{v} for k, v in DEVICE_DATA.items()) if __name__ __main__: mcp.run() # 默认使用 stdio 方式适合本地调试代码逻辑很简单定义了两把工具一把单点查询一把全量查询。真正的Modbus读取逻辑写在read_device_value内部用pymodbus读寄存器、做字节序转换、按点位表映射成有业务含义的字段名。这个示例刻意没写安全逻辑但工业现场部署时要注意这个Server不应该暴露在公网鉴权和传输加密要放在网关层处理。跑起来之后在支持MCP的客户端里配置这个server输入“读取设备所有点位”模型会自己决定调用read_all_points而不是手动去发HTTP请求。关键点在这里AI不再直接解析数据库或报文而是通过一个有业务边界的接口拿数据数据含义在Server层就被转换好了。提示这个示例偏向教学。真实环境建议使用支持MCP能力的边缘网关或者先把设备数据汇聚到OPC UA网关再在网关上层部署MCP Server。不要拿裸PLC直接做实验。5. 卡住规模化落地的六个现实问题前面几章讲的是“可以跑”这一章回答“为什么还没有狂奔”。我在这块踩过坑也亲眼看过别人踩坑如实写出来。这些问题大多不是MCP协议本身的缺陷而是工业场景特有的约束跟协议叠加之后才变得棘手。5.1 工业场景无法容忍“幻觉”第一个问题是老生常谈但在工业场景里格外尖锐。办公室场景中AI答错一道题最多重问一遍。产线场景中AI把“产量”说成“不合格品率”可能直接导致错误的经营决策。MCP本身不解决模型幻觉它只保证“取到的数据是真实的”。如果模型在生成回答时自己发挥给查询结果加了点编造的语境杀伤力比传统软件还大。目前的应对手段是在Agent层加约束强制MCP Server返回的结果必须逐字展示模型只做摘要不做补充。但这不是协议层面能解决的需要应用层自己去限制。任何声称“MCP可以根治幻觉”的说法都不要信。5.2 控制回路动不得MCP现在基本只能“读”MCP定义的tools理论上可以执行任意动作包括写操作。但在工业场景里“写”意味着下指令比如修改PLC运行参数、触发设备动作。这个权限没有人敢轻易交给AI出了安全事故不是技术问题是责任问题。我观察到的现状是所有真实项目里的MCP Server基本都是只读的。偶尔有“写”的尝试也只局限在生成参数建议、由人工确认后手动下发。真正意义上AI直接写PLC参数的案例目前我没有看到一个投入生产。这不一定永远是禁区但短期一两年内别指望MCP能在控制回路上有多大作为。5.3 OT网络隔离与安全策略工业网络的安全基线是物理隔离至少也是严格的防火墙策略。AI应用通常部署在办公网或云端想访问车间里的设备数据必须跨网络。这不是技术不能实现而是安全部门不会轻易松口。最常见的解法是在DMZ区放一台边缘服务器一边通过工业协议与工控网通信一边通过MCP与办公网AI应用通信。但这意味着MCP Server本身成了网络边界的一部分鉴权、审计、漏洞管理都要提上日程。目前MCP生态里成熟的工业级安全方案还很少很多项目都是拿开源方案自己改这对传统制造业客户来说是个顾虑。5.4 上下文长度与设备规模之间的矛盾这个坑比较隐蔽。MCP的一大优势是AI按需调取数据不用把所有数据塞进上下文。但按需的前提是AI需要知道有哪些工具可以调。如果接的不是一台设备而是一个工厂的500台设备每台暴露5个tools工具列表就变成2500条。模型的上下文窗口再大也架不住每轮对话都要过一遍完整的工具介绍。目前治标的方法是做工具路由上层先有一个粗粒度的入口tool根据用户问题里提到的设备类型、车间编号动态决定是否加载细粒度tools。但MCP协议对这种分层路由的支持还不成熟各家都在做自定义扩展没有统一规范。5.5 数据本身没被结构化协议通也没用经常有客户问能不能用MCP直接读SCADA的数据。当然能但读出来的寄存器地址叫40001谁来告诉AI那是温度还是压力MCP能解决接口问题解决不了数据治理的历史欠账。点位表混乱、字段命名随意、单位不统一、历史数据大量丢失这些才是真正让人头疼的问题。有个锂电池行业的POC项目给我印象很深他们的MCP Server开发只用了两周点位梳理和数据质量验证却花了两个月。这个比例相当真实不要指望协议替你补数据的课。5.6 MCP生态本身还在变动工业客户倾向再等等最后说一个现实问题MCP自身还在快速演进。一年半里传输方式从stdio为主演进到Streamable HTTP鉴权方案、服务发现机制、各类SDK的API都在变。工业客户对稳定性要求极高看到协议还在“长身体”通常的选择就是观望。这是我判断未来一两年会进一步分化的原因互联网场景继续激进应用工业场景会慢慢形成自己的约束性实践或行业模板。等协议稳定下来、安全方案补齐了才是工业物联网真正放量的时候。6. 往后两年我看好的方向和建议如果看到这里你应该对“谁在用、卡在哪”有一个整体认知。最后一章说点我自己的判断算是在群里吹过的牛的回访供参考。6.1 设备知识问答会比实时数据查询更快铺开原因在前面已经写过知识库数据静态、低风险、不需要动工控网。它更像是企业知识管理而不是数据采集落地阻力小价值直观。我判断接下来最先普及的仍然是“设备手册问答”“故障代码反查”这类应用等到这些场景被验证透了实时数据类的需求才会跟进。6.2 边缘网关带上MCP能力会成为新的卖点硬件厂商一定会跟上而且已经在跟了。以后主流的边缘网关、工业AI一体机会把MCP Server做成内置功能用户不需要自己写Server逻辑配置一下点位表和词表就行。这会把MCP的使用门槛从“会编程”降到“会配置”使用人数会明显上一个台阶。6.3 “先读后写、先离线后上云”是我验证过的推进路径如果要给正在评估MCP的同行一个路径建议我会说先做只读再考虑写先做离线内网部署再考虑上云。把MCP Server安全放进内网接一个知识库能回答问题就已经成功。不需要一步到位去做AI控制设备这种大而全的命题那既不是技术问题也不是协议问题是整个体系信任度的问题。6.4 别把协议当银弹把它当“最小可行标准接口”最后说说我的核心理念。MCP不是银弹它更像是一个大家约定好的插座标准。它能降低对接成本但不会消解你本来就要做的数据治理、安全设计和需求梳理。真正决定项目成不成活的还是你对那台设备的理解、对那个工厂业务的理解。协议只负责把路修好车要你自己造货要你自己搬。我这一年半最大的体会是MCP在工业物联网的落地靠的不是技术突破而是一批务实的人把它一点点磨进真实的业务流程里。这个速度不快但每一步都很扎实。以后看到MCP相关的工业试点别急着下判断多蹲下来看看他们到底在解决什么问题。很多时候问题是真的场景是真的剩下的只是时间问题。