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 Server，AI需要的时候自己会去问这个外设要，数据不再需要全部灌进上下文。这个差异是质的，大模型按需取用，而不是被动消化。
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_pressure，AI拿到的是“懂业务”的接口，而不是冷冰冰的寄存器编号。
权限断层容易被忽略。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 tool，AI被问到“今天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相关的工业试点，别急着下判断，多蹲下来看看他们到底在解决什么问题。很多时候问题是真的，场景是真的，剩下的只是时间问题。
