1. 先聊一个“过气”热词的现状MCP协议全称Model Context ProtocolAnthropic在2024年11月底开源的那个上下文协议放到今天来看热度确实降了不少。但工业物联网这个圈子里我反而觉得现在才是讨论它最有价值的时刻。去年那阵子各种行业群都在问“要不要上MCP”只要你的平台不宣传自己兼容MCP好像就落后了。一年半过去当初刷屏的人大多已经去追新概念真正在工厂里做设备联网、数据采集、产线数字化的人反倒冷静下来开始盘点这东西在我们这种现场环境里到底能干什么又是谁真的在用我这段时间的判断基本可以分成三层。第一层热度层面明显凉了MCP不是什么新鲜词了。第二层工具链层面确实成熟了官方SDK、社区实现、企业级网关多了一大堆不再像最初那样“demo能做生产没人敢用”。第三层也是更关键的工业场景里已经长出了一批不声不响但稳定运行的实际应用集中在设备监视、运维知识库、班报自动生成、质检辅助这类拿数据和文档就能干活的地方。所以这篇文章我不会再去吹“MCP将重新定义工业物联网”而是想以一个做设备接入和边缘计算的老兵身份把这十八个月里看到的使用形态、容易踩的坑、能落地的套路拉出来讲讲。如果你正在犹豫要不要在工厂、能源站、水务、环保这类场景里引入大模型能力或者已经被老板问过“别人都在用大模型管设备了我们什么时候上”那这篇文章应该能给你一个相对清晰的判断框架。我不保证你读完就能立刻上线全套系统但至少你能知道从哪下手、哪些方向是坑、现场要提前准备什么条件。2. 给工业人拆一下MCP到底是个什么协议2.1 一句话理解MCPMCP不是为了替代OPC UA、MQTT、Modbus这类工业通信协议出现的这点必须先讲清楚。它是一个应用层语义协议解决的是“AI应用如何标准化地去调用外部工具、读取外部数据、以及把结果交还给用户”的问题。你可以把它理解成给大模型装了一排标准插线板每个插线板后面接什么设备、接数据库还是接SCADAMCP不管它只管以统一的JSON-RPC 2.0格式把请求和响应包装好让AI应用不需要为每一个数据源单独写一套接入逻辑。这套逻辑对工业物联网特别有价值因为我们的现状就是协议碎片化。西门子的S7、三菱的MC、施耐德的Modbus、各种PLC私有口往上层还有OPC UA和MQTT在互相较劲。如果每一家AI产品都要直连这些五花八门的接口项目成本会高到吓人而且每做一个新项目都要把集成工作重新来一遍。MCP的聪明之处在于它把“接入工业数据”这件事收敛成了“为每一种数据源写一个MCP Server”而AI客户端只需要理解MCP协议。2.2 MCP三个核心概念用工厂的东西打比方MCP在交互层面定义了三种核心原语工具Tools、资源Resources、提示Prompts。我在给客户讲的时候通常直接用工厂里的实物来类比工具Tools相当于设备上对外开放的操作按钮。比如“读取3号空压机的实时功率”“查询某订单的质检报告”“给某条报警添加工单备注”。AI应用可以按需调用这些工具调用前还能先看参数说明。资源Resources相当于按路径读取的工艺文件比如设备台账、点位表、工艺参数配置文件。资源通常不是靠模型自动发现的而是由客户端或用户指定URI去读取。提示Prompts相当于工艺操作模板定义了一套标准化的对话或操作流程。比如“生成设备点检总结”这个模板配合工具和资源一起使用让大模型按固定结构把零散数据整理成报告。2.3 为什么它适合做AI和工业数据之间的胶水层这里我想展开讲一下“胶水层”这个概念。工业物联网项目的本质是把散落在现场设备、PLC、传感器、DCS、MES里的数据通过采集、清洗、存储、分析最后变成对生产有价值的动作。过去这个链条里数据到报表这一截已经很成熟了但数据到“人”这一截一直很粗糙。工程师想看一台设备为什么报警通常要在SCADA画面上翻半天趋势曲线再回看历史工单还要去翻维护手册。现在MCP给了我们一种可能让AI应用按标准方式去拿这些数据再把结果翻译成人话。换句话说MCP不碰数据链路本身它站在数据链路之上帮AI应用把散乱的接口收拢成统一入口。这个思路和工业物联网平台构建数据中台的方向高度一致。所以当我们聊“谁在用MCP”本质上是在问谁是那个愿意先把数据服务标准化的人谁就能让AI应用跑在统一的数据底座上。3. 一年半实战观察工业物联网里到底谁在用3.1 真正使用者不是“工业物联网”而是三类人如果只看“工业物联网”这个词你会觉得市场很大但实际用起来的远没有这么泛。据我看到的情况真正投入资源做MCP落地的主要是三类人。第一类是大型制造集团里的数字化团队像汽车、钢铁、化工、半导体这类行业。他们本身就有很强的IT团队已经建了数据中台设备数据也早就接到中央数据库了。对他们来说上MCP不是从零开始搞一套新架构而是在已有的数据服务外面再套一层标准化接口让内部的AI助手能读取设备数据。这类人用的最熟练因为他们本来就在持续建设数据底座MCP只是把最后一公里打通了。第二类是自动化集成商和装备制造商。他们的痛点很直接设备卖出去之后客户总问“你这设备有没有AI分析功能”。以前做一套远程运维诊断系统周期长、定制化程度高做一次要两三个月。现在拿MCP Server包一层Modbus或OPC UA采集再接上大模型问答一个能演示、能试用的运维助手几周就能出来。对集成商来说MCP降低了交付门槛也让他们的硬件在竞争时多了一个卖点。第三类是OT和IT融合走得比较前的企业内部创新团队。这类人通常不会一上来就搞大项目而是先用一个车间、一条产线做试点。他们选择MCP多是因为内部数据湖已经跑起来了但业务领导想要的是“能用自然语言问问题”的效果不是再上一套BI报表工具。MCP让他们能在不推翻现有系统的情况下快速把LLM能力接到工业数据上。3.2 先跑起来的三种典型场景场景一设备监视和远程运维问答。连接PLC或SCADA把实时数据通过MCP暴露给AI助手。一线工程师直接在对话框里问“3号空压机今天启停了几次”“哪个车间综合效率OEE最低”AI自动去查数据并汇总回答。这个需求在光伏、风电、空压站这些分布式的场景里尤其受欢迎因为无人值守站点多集中监控中心的调度员不可能每个画面都盯着。场景二运维知识库加告警联动。很多企业有厚厚一堆设备手册、故障处理记录、检修规程但现场员工根本来不及翻。把运维文档切好块做向量化让MCP Server同时挂上“文档检索”和“实时告警查询”两个工具AI收到告警信息后自动检索历史故障案例给出处理建议。我见到的很多MBR基于规则的维修系统改造都是从这一步切入的。场景三班报和巡检报告自动生成。这项工作看起来不起眼但使用频次非常高。以前班组交接班要整理设备运行数据、异常记录、产量信息写一份班报少说半小时。现在做一套MCP工具连接MES、SCADA、点检系统把数据拉出来大模型按固定模板生成初稿班组长只要审核修改。这类应用因为不涉及控制动作风险低、见效快上线阻力很小。3.3 还没真正跑起来的场景诚实地说闭环控制和实时安全联锁这些场景目前我没有看到真正规模化的MCP应用。原因不复杂MCP基于大模型的调用而大模型当前无论从延迟、确定性还是安全认证角度都不适合直接参与毫秒级的PLC控制回路。你可以用AI去分析“为什么这台设备停机了”但你不会用AI去直接触发紧急停机保护。这些场景仍然属于PLC、DCS和专用安全系统的地盘MCP短期内连边都沾不上。另外生产排产和供应链协同方面的MCP应用也仍然处于探索阶段。这类系统一旦出错影响的是几百个订单的交期不是一条报警能挽回的。所以即便有人在试也多半是只读的辅助建议不会直接修改排产结果。4. 落地套路我见过的三种MCP接入模式4.1 只读监视模式第一种模式最简单也是目前占比最大的。整体链路大致是现场PLC/传感器通过Modbus、OPC UA或S7协议进边缘网关网关负责把数据处理成JSON格式推送到MQTT或Kafka上层平台消费这些数据存成时序数据库再往上MCP Server暴露若干只读工具比如“查询设备实时状态”“查询历史趋势”“查询当前告警列表”。AI客户端收到用户提问后从MCP工具里挑一个执行把结果整理成自然语言回复。这种模式的价值是把过去只能靠人肉盯屏和翻报表才能得到的信息变成了像聊天一样随时能问的服务。我见过一个空压站项目调度员每天上班第一件事就是问AI“昨天7号空压机排气温度最高到多少有没有超限”原来这一查要打开SCADA翻点位配置至少五分钟现在十秒钟就出结果。这个模式几乎没有控制风险权限管控也简单全部设成只读即可。4.2 知识库加告警模式第二种模式在只读基础上加了文档检索和告警上下文关联。MCP Server里除了数据查询工具还接入了向量数据库或企业搜索服务。当有告警发生时系统先把告警信息格式化然后调用工具去匹配历史工单、故障案例和维修手册最后让大模型生成一段包含“故障现象、可能原因、建议处理步骤”的分析结果推送给运维群或者工单系统。生产级实现里有个细节值得注意时序告警往往是多条件组合触发的直接拿传感器名称去检索文档效果很差。我们一般会先做一步“告警标准化”把设备位号映射到设备类别、部件名称再拿映射结果去做检索。比如压力变送器报警光查“PT101”没有意义但如果把它映射成“液压站压力异常”就能检索到历史案例里那些同类型的故障处理记录。4.3 工单联动与闭环执行模式第三种模式开始涉及写操作了。MCP Server除了读数据还能创建工单、更新维修记录、修改参数设定值通常要二次审批。这种模式需要非常谨慎。因为AI模型的判断不是100%准确的一旦自动创建了错误工单或者自动修改了不该动的参数影响会被放大。我见过比较稳妥的做法是AI只负责生成“建议动作”真正执行前必须有人工确认。比如大模型识别到某台泵的振动值持续升高建议创建“轴承更换”工单系统先把建议推给设备工程师微信群工程师点“确认”后系统才真正调用MES接口创建工单。这样一来MCP负责把数据分析和操作建议标准化人还是留在决策闭环里。4.4 三种模式对比速查模式数据流向安全性实施成本典型场景只读监视OT到AI单向高无写操作低设备问答、报表生成知识库加告警OT文档到AI自动推送较高只读为主中告警研判、运维辅助工单联动与闭环执行AI可触发业务写操作需人工审批高工单创建、参数建议从我的实际感受来说大部分项目都是从第一种开始跑出价值以后再往第二种或第三种延伸。不要一上来就做成第三种否则光是把各系统的权限、审批流、审计日志对清楚就够前期协作拖上两三个月。5. 工业现场特有的几个大坑5.1 延迟和实时性的冲突大模型推理是有延迟的。GPT级别的大型模型一次推理可能要几秒就算本地部署的7B模型也需要几百毫秒而工业现场很多操作对延迟的要求是几十毫秒甚至更低。这意味着MCP没法用在需要快速响应的控制指令上。很多人一开始不理解这个区别尝试把AI放进PID控制回路里结果自然不理想。我建议所有准备上MCP的团队先把“AI能在秒级响应的事情”和“毫秒级必须交给PLC的事”划清界限这个边界画不清楚项目后面一定会扯皮。5.2 时序数据模型和MCP资源模型对不上工业物联网的核心数据是时序数据而MCP里的“资源”更偏向现代文档和结构化文件。时序数据库里的数据是持续追加的点位数量动辄几万、几十万用MCP把点位表全部列出来没有意义。实际做的时候需要我们在MCP Server内部封装好时间范围和聚合逻辑。用户问“过去24小时3号线的平均温度”MCP Server就该自己决定查哪个点位、用什么聚合粒度而不是让大模型去处理几百万条原始记录。5.3 权限模型太粗MCP协议本身对权限的定义非常基础只有“允许”和“拒绝”两级没有细化到用户角色、数据范围、字段级别。但工厂里的数据是有严格权限区分的操作员能看当班数据工艺工程师能看完整追溯记录维修主管能写工单厂级领导只能看报表。如果MCP Server把工具全量开放给所有用户很容易造成越权访问。我们在项目里通常会在MCP Server和上层AI应用之间再加一层企业身份认证网关把用户身份传入MCP工具调用按用户角色做数据过滤。5.4 协议版本和兼容性MCP协议还在演进2025年还经历过一次从“低级别的JSON-RPC原始交互”向“更高层的Streamable HTTP传输”演进的阶段。工业环境的系统生命周期一般很长很多SCADA和PLC要跑十几年如果AI数据服务层跟着协议版本频繁升级现场的稳定性无法保证。我个人习惯是MCP Server这一层尽量保持稳定把协议适配放在独立网关里不要让工业现场的业务服务和上游协议绑定得太紧。5.5 操作审计和责任问题AI一旦参与了工单创建、参数建议这类动作出问题时责任划分就开始模糊。比如系统根据AI建议修改了某个温度设定值结果导致产品批次报废算谁的这时候如果MCP Server没有完整的调用日志很难追责也很难在复盘时定位问题。我们在生产系统里对每一次MCP工具调用都要求记录谁发起的、输入参数是什么、返回结果是什么、最终有没有被人工批准执行。这三个字段缺一不可。6. 如果现在要试点我的建议路径6.1 不要一上来就做控制闭环很多客户第一次沟通时会说“我们想做一个智能控制”我一般都先泼一盆冷水。你连设备数据都没洗干净连告警处理率都没量化怎么谈智能控制我的建议是从风险最低、业务价值最明确的地方切入。通常选一个设备故障率较高的工段先把设备数据通过MCP暴露给AI让运维人员可以随时问设备状态再叠加历史检修记录检索。这个阶段不碰控制不碰写操作只解决“人找数据难”的问题。6.2 最小可行单元一个最小可行试点一般包括这些部分一台或几台关键设备的数据采集、一个边缘计算盒子或一台服务器、一个MCP Server、一个支持MCP的聊天客户端。数据采集最好用已有的网关不要为试点重新部署一套采集系统。MCP Server可以先做两三个核心工具比如“查询设备实时参数”“查询设备历史趋势”“查询最近告警”。客户端用现成的大模型应用即可重点是把数据链路打通让AI能真实读到现场数据。6.3 从试点到试产的关键门槛一旦试点跑通真正决定能不能推广的往往不是技术而是数据质量和管理规则。比如你要让AI去分析设备健康度就得先确认振动测点装没装、信号干不干净、采样频率够不够你要让AI自动出班报就得先定义清楚“异常”的判定标准。没有这些基础AI再强也只是在一堆积满灰尘的数据上跳舞。所以试点阶段最好就让工艺、设备、IT三个角色一起参与把指标口径和权限边界定清楚。6.4 一句话选型清单数据底板确保设备已联网数据能进时序数据库这是所有上层应用的前提。MCP服务层优先用官方SDK或成熟开源框架不要在协议层自己造轮子。AI模型本地化部署的数据合规要求低但性能弱一些云端API效果好但数据出园区要做安全评估。权限审计不要等上线后再补试点阶段就要埋好身份识别和日志记录。7. 给想亲自试的人一个能跑的展示案例7.1 演示目标我们用一个最精简的示例演示“如何把工业设备数据通过MCP暴露给AI”。这次我模拟一台空压机的数据源用Modbus TCP作为现场通信协议然后在Python里用FastMCP框架封装一个MCP Server。你不需要真的有PLC用Modbus模拟从站或者直接读一个本地JSON缓存即可。7.2 用Python写一个简单的MCP Server先装依赖pip install fastmcp pymodbus然后写一个最简化的服务端。这里我假设设备数据已经由边缘网关缓存在本地内存中实际项目中你可以从Redis、SQLite或时序数据库里读取。from fastmcp import FastMCP # 模拟从边缘缓存里读取设备数据 CACHE { compressor_01: {power_kw: 45.2, discharge_temp: 78.5, status: running}, compressor_02: {power_kw: 31.6, discharge_temp: 65.2, status: running}, compressor_03: {power_kw: 0.0, discharge_temp: 23.1, status: stopped}, } mcp FastMCP(air-compressor-monitor) mcp.tool() def get_compressor_status(unit_id: str) - dict: 读取空压机实时运行状态。 Args: unit_id: 空压机编号如 compressor_01 Returns: 包含功率、排气温度、运行状态的字典 if unit_id not in CACHE: return {error: funknown unit: {unit_id}} return CACHE[unit_id] mcp.tool() def list_all_compressors() - list: 列出当前所有空压机编号。 return list(CACHE.keys()) if __name__ __main__: mcp.run(transportstdio)这个Server通过标准输入输出进行交互支持任何MCP客户端以stdio方式连接。你可以在终端里用npx或者自己写个小客户端来调用。上面的代码只是一个演示生产环境中你要把CACHE换成真实的时序数据库查询并且把工具数量做得更大。7.3 客户端消费如果你不想用现成客户端只想验证MCP Server是否正常也可以直接手动模拟JSON-RPC请求。不过MCP标准把“工具发现”和“工具调用”分开了客户端一般会先调用tools/list拿到工具清单再根据清单调用tools/call。实际开发时直接使用社区SDK里的MCPClient更省事。这里放一个概念性的调用示意客户端问AI“2号空压机现在什么状态”AI会先通过tools/list发现有两个工具再根据问题选择get_compressor_status(unit_idcompressor_02)把返回的JSON整理成自然语言回答给用户。整个过程从外部看就是一次对话但背后走的其实是工具发现加工具执行的链路。7.4 演示效果对应到实际场景这套模式往后延伸就回到我们前面聊的三种落地模式了。把get_compressor_status换成“查询光伏逆变器发电效率”把list_all_compressors换成“查询场站列表”一个分布式能源监视助手就出来了。所以我说MCP的门槛其实不高难的是你能不能把现场数据先收拾干净并且定义清楚AI有哪些工具可以用、哪些数据不能碰。8. 聊几句真正的前景判断我个人不认为MCP会取代OPC UA或MQTT这些面向现场设备通信的协议它在工业物联网里的角色更像是一层“语义服务接口”把底层的数据采集和上层的AI应用解耦。过去一年半真正的价值已经被验证过了凡是数据底座建得好、工具定义清楚的地方MCP都能让AI实实在在帮上忙凡是数据一团乱麻、又想靠AI一步登天的地方基本都还在原地打转。各平台对大模型和MCP的态度也在不停变化今天一个样明天一个样但工业客户比较务实他们不会因为哪个技术热搜就跟风上项目他们关心的是这个协议能不能让我少跑几趟现场、少翻几份报表、少写几份交接班报告。从这个角度看MCP在工业物联网里不算过热反而处在一种“价值正在被稳步兑现”的状态。我在实际项目里最有感触的一点是MCP带来的最大变化不是算法变强了而是工业数据的使用门槛变低了。以前很多数据接上来之后只躺在数据库里只有少数工程师会用SQL去查现在只要有个MCP Server挂在那里车间主任、维修工都能用自然语言去问。你要是正在做工业物联网建设不妨从一个小工具开始试起把数据服务的能力开放出来后面你会慢慢发现现场提出来的新问题比你能做的还多。最后再分享一个经验别把MCP当项目唯一的卖点它只是让AI更好用的一种连接方式。一门心思追新协议很容易忽略底层数据治理而数据治理才是工业智能化的真正底盘。先把这个底盘打牢MCP这类上层协议要用随时都能用上。