最近几个月圈子里聊AI编码工具翻来覆去绕不开三个词Skills广场、MCP协议、Rules规范。如果你是个写PLC、上位机、SCADA的工业自动化工程师大概率会看得一头雾水——这些不是网页开发那边的新名词吗跟我们OPC UA有什么关系但我的判断是这场AI编码工具的生态战争已经开始烧到工业现场了OPC作为设备互联的老牌中间层现在正面临一个很现实的“选边”问题。我把话说透一点现在的AI编码工具早就不只是“帮你自动补全代码”的编辑器了。Claude Code、Cursor、Gemini CLI、Qwen Code这些工具各自在搭建自己的“应用生态”。Skills是给AI装技能包MCP是让AI能去调外部数据和系统Rules是给AI定边界和规矩。这三件事放在一起基本决定了未来几年“人怎么跟AI协作写工程类代码”的格局。而对做工业通信的开发者来说OPC UA这套东西恰好是数据密集、协议复杂、文档量大的典型场景正是AI工具最能发力的地方。这篇文章不站任何工具厂商的队我只想站在一个既写工业代码、又折腾过AI工具链的从业者角度把这三样东西拆开讲清楚再聊聊OPC“选边”到底该怎么选。1. 生态战争里的三张牌Skills、MCP、Rules1.1 Skills广场像给手机装App一样给AI装能力先说说Skills广场。这个概念的典型代表是Claude的Agent Skills还有Gemini CLI Extensions里那些可插拔扩展。以前我们调AI写代码靠的是在对话里反复描述需求“帮我写一个OPC UA客户端要支持证书连接、要处理重连、要输出日志”。模型每次都要现场理解、现场发挥效果还不稳定。Skills的思路不一样。它把一类任务沉淀成一个“技能包”里面通常有一个SKILL.md文件写明这个技能什么时候用、怎么用再附带脚本、模板、参考文档。这个技能包可以安装给AI之后它再遇到同类任务就直接按技能包里的流程走。你可以把Skills理解成AI的应用商店装哪个技能AI就会哪样“手艺”。这件事对工业开发者的意义在于上位的规则、下位的库、甚至你们公司内部的通信流程都可以封装成技能包。比如“欧姆龙PLC网关联调”“WinCC导出报警记录”“KepServerEX标签批量导入”这类重复性工作做成Skill之后AI再收到相关需求就不是从零硬编而是照着你们公司的套路干活。所以你说Skills广场是“生态战争”但它争的不是用户停留时长而是“谁家的AI更懂行业现场”。1.2 MCP协议AI世界的USB-C接口再看MCP协议。全称Model Context Protocol是Anthropic提出来的开放协议现在已经被OpenAI、Google这些大厂陆续接受基本成了AI Agent连接外部工具的事实标准。MCP解决的是什么问题就是AI模型再聪明也没法凭空访问你们车间的实时数据、数据库、工单系统。MCP给模型开了一扇门通过Server暴露数据资源和可调用工具AI客户端统一通过JSON-RPC 2.0去调用。我打个比方以前每个AI工具想接数据都得自己造一根专用线缆接数据库要写一个插件接OPC UA又要另一个插件厂商之间还不通用。MCP就是要做那根“USB-C线”你只要把数据源包成一个MCP Server任何支持MCP的AI客户端都能用。对于OPC UA来说这意味着你不用专门给某个AI编码工具写插件只要把OPC UA的数据读取、节点浏览、订阅报警包成MCP工具Cursor能用Claude Code能用后面新出的工具大概率也能用。选边选MCP等于买了一个生态通用接口。1.3 Rules规范给AI立规矩比会写代码更重要最后是Rules规范。Cursor里有.rules文件Claude Code有CLAUDE.mdGemini CLI也有类似的项目说明。这东西说白了就是给AI立规矩哪些库能用、哪些写法禁止、命名风格是什么、安全边界在哪。工业现场跟纯Web开发很不一样AI生成的代码如果不符合规约轻则没法上线重则引发设备误动作。我见过很多人一上来就让AI猛写代码生成了几百行看着挺像样结果连SecurityPolicy都没指定OPC UA握手根本过不去。Rules的价值就在于把这类“老工程师脑子里的禁忌”固化到项目里。你写清楚“所有UA连接必须显式指定安全策略”“写操作必须走审批流程”“异常不能静默吞掉”AI就会照着这条线走。这三个东西组合起来才构成完整的AI编码工具生态MCP解决AI能访问什么Skills解决AI擅长什么Rules解决AI被允许怎么干。2. OPC UA工业圈的慢变量为什么要“选边”2.1 为什么工业现场绕不开OPC UA聊完AI这边回过头看OPC UA。老实说OPC UA在工业圈已经不算新技术了十几年前就有了但这两年明显在加速铺开西门子WinCC做OPC UA服务器和利时、三菱FX5U、汇川AM系列都陆续支持OPC UA通信KepServerEX常年是工程师电脑里的标配Node-RED里opcua转mqtt的节点下载量一直很高。为什么大家都往OPC UA上靠因为它跨平台、有完整的信息模型、安全体系比老掉牙的OPC DA强太多一个协议能同时覆盖PLC、SCADA、MES甚至云平台。但是OPC UA也有一个特点本身是个“开发负担不轻”的协议。你要自己写客户端得处理端点发现、安全策略协商、证书信任、命名空间、节点ID匹配、订阅与轮询的选择线上环境再加一层用户认证。这些逻辑其实高度雷同但每上一个新项目就要重新写一遍。2.2 传统OPC开发的三个痛点把OPC UA的实际开发捋一遍痛点基本集中在三块。第一是样板代码太多。连接一个支持OPC UA的PLC客户端代码翻来覆去就是建立连接、创建会话、浏览节点、读取值这几步但刚开始接触这套协议的人光证书信任和Endpoint配置就能卡一整天。第二是调试手段偏老。很多时候你连不上服务器第一反应是拿UaExpert这种通用客户端挨个试安全策略试通了再回头改代码过程非常磨人。第三是数据到应用之间的胶水层太厚。采集上来的数据要进MQTT、进数据库、进AI模型中间一堆转换、映射、补包的活这些年全靠Node-RED这类工具扛着Node-RED的opcua节点社区也一直很活跃但真要接复杂的UA信息模型时配置量也不少。2.3 “选边”的本质生产方式变了这些痛点其实一直存在以前大家觉得没办法只能堆人来写。但AI编码工具爆发之后我突然意识到真正要被选边的不是“用哪个AI工具”而是“OPC开发这件事本身该换一种干法”。现在的选择是你是继续所有代码纯手写AI只当文本补全器还是把公司积累的通信规范写成Rules让AI按规矩生成大部分客户端代码你是继续给上位机写传统客户端让数据在人机界面上滚动还是把UA数据包成MCP Server让AI Agent自己去“查数”“报状态”“辅助诊断”这四种组合没有标准答案。但如果不提前想清楚后面一定会很被动。因为AI生态迭代太快了你今天选的工具链三年后大概率不是主流你今天做的Skills、Rules、MCP封装却可以沉淀下来跨工具复用。所以“选边”不是押注某个公司的赛道而是决定你要不要把工程经验变成可复用的资产。3. 三条可落地的选边路径3.1 路径一用AI写OPC UA代码用Rules兜底这条路径最适合传统自动化团队。目标很简单保留现有架构把AI当成一个“特别懂编码规范的实习生”你负责审它负责写。很多OPC UA客户端代码套路化严重——UaClient初始化、连接回调、读节点、订阅数据变化这些生成代码本来就是大模型的强项。你要做的不是重复描述需求而是先把公司规范写进Rules。我自己的CLAUDE.md里写过类似的约束# OPC UA 开发规范 - 客户端连接必须显式指定 SecurityPolicy禁止默认 None仅测试环境可放宽 - 禁止在源码中硬编码用户名、密码、证书路径一律从环境变量读取 - 读取节点前先确保 NodeId 存在必要时先 Browse 再 Read - 订阅逻辑必须支持断线重连并恢复订阅 - 所有异常需要保留原始 StatusCode禁止只 print 后继续 - 写操作必须二次确认日志记录操作人、时间、写入前值把这种规则喂给AI之后你会发现生成代码的质量稳定很多基本不会出现“端点都连不上还硬着头皮读”的低级代码。这条路需要投入的成本主要是一次性整理Rules收益是后面所有AI辅助写代码的产出都对齐了标准。适合谁适合那些设备种类杂、项目制交付、但不想引入额外中间件的团队。3.2 路径二用MCP让AI Agent直接读写OPC UA第二条路径更有意思也更新。核心思路不要面向“代码”直接面向“数据”。你写一个MCP Server把OPC UA的几个关键动作封成工具然后让支持MCP的AI客户端自己去调用。工程师的提问从“帮我写一个读温度的程序”变成直接在AI对话框里说“帮我看看三号线的当前温度和过去一小时有没有超限记录”。这个体验是完全不同的。因为MCP Server背后连的是真实的OPC UA服务器AI拿到的不是虚拟数据而是现场或模拟器的实时值。如果再配合一个Flowise或Dify之类的Agent框架你甚至可以搭出一个“设备问答助手”产线负责人用自然语言就能查数据。我做最小验证时用的就是FastMCP加asyncua几十行代码就能把“读节点”“写节点”“浏览子节点”暴露给AI。这个方向的价值很大但也要注意MCP把设备数据暴露给LLM之后权限管理、写操作审批、调用频率限制都要重新设计不然AI一个幻觉发作真去写了一个不该写的PLC点事情就大了。3.3 路径三混合选边不跟某一个工具绑定我实际更推荐第三条路混合选边。没必要时隔一个但可以分场景打组合拳。场景推荐路线理由传统上位机项目甲方指定WinCC/组态环境路径一AI生成代码 Rules规范不改变交付形态风险最低要快速做数据中台多协议汇聚到MQTTOPC UA转MQTTNode-RED再考虑MCP先打通数据管道后续接哪套AI都行想做设备诊断问答、报表自动生成路径二OPC UA封装成MCP ServerAI能主动取数体验最好团队刚接触AI工具成员水平参差Rules 少量Skill先用起来沉淀规范避免一次步子迈太大这套组合的核心原则是Rust上的数据通道保持稳定AI工具层保持可替换。你今天用Claude Code明天换Gemini CLI只要MCP Server和Rules文件是通用的迁移成本就极低。真正该被绑定的是你封装的协议和数据模型而非某个IDE或某个模型厂商。3.4 选边前的自我检查清单如果你还是犹豫不妨对着这几个问题过一遍你们团队的代码资产是能写成规范让AI遵守的还是高度依赖个别人经验你们的设备数据未来除了进SCADA需不需要被AI Agent、报表系统、大数据平台消费安全上能不能接受“AI直接调设备数据”这种模式不能的话就选路径一。团队成员有没有意愿维护一份“活的Rules文档”没有的话别急着搞Skills。这些问题想清楚了选哪条路是自然的。4. 实操一个能跑起来的“AI OPC UA”最小方案这部分我直接分享自己做过的验证过程。照这个跑一遍你就知道MCP、OPC UA、AI编码工具是怎么串起来的。4.1 准备环境能用模拟器解决的绝不上真设备别一开始就拿车间里的真PLC实验风险太大。我用的是Prosys OPC UA Simulation Server也有免费版加上一个KepServerEX做备用验证。UaExpert作为通用UA客户端方便排查连接问题。AI客户端我同时备了Cursor和Claude Code因为都要支持MCP。机器上需要装Python 3.10以上。组件方面用到asyncua、fastmcp、node-red可选。Node-RED我习惯用Docker起docker run -d --name node-red -p 1880:1880 nodered/node-red:latest然后在Node-RED里安装opcua节点npm install node-red-contrib-opcua这套环境搭完之后后面所有跟设备通信相关的尝试都可以在本地模拟完成不碰真实产线。4.2 用模拟器生成工业数据启动Prosys Simulation Server后默认会带一批模拟节点比如“Counter”“Random”“Simulation”之类的变量。这些节点就是我们的数据源。我用的是默认端口4840Endpoint是opc.tcp://localhost:4840。为了验证方便安全策略先选None用户匿名等整个链路跑通之后再升级加密。这一步要特别强调不要一上来就模拟“高层次安全模型”先保证链路通。实际现场踩坑最多的就是证书、策略不匹配导致握手失败你根本分不清是代码写错还是配置不对。先用最宽松的模型把数据调通再逐级加固排查范围会小很多。别嫌这个流程“土”这是我在十几个项目里验证过的高效路径。4.3 用Node-RED把OPC UA转MQTT可选为什么做这一层因为不是所有AI工具都支持直接连MCP但MQTT几乎是数据中台的标配。Node-RED在这里当“笨胶水”从OPC UA读值转成JSON丢到MQTT Broker。流程非常简单一个OPC-UA节点连上Prosys订阅几个变量一个function节点把payload整理成{ tag: Temperature, value: 25.4, ts: ... }一个MQTT Out节点发布到topic。这个链路单独看没什么特别但它验证了一件事OPC UA的数据完全可以脱离“上位机组态”这套体系流通到互联网技术栈里。后面把MQTT再接回AI上游也只是加一个桥接的事。Node-RED之所以在工业圈火就是因为它把这层胶水做到了可视化、低门槛。工程师不用写一行业务代码就能把OPC UA的实时数据送到下游。4.4 用MCP Server把OPC UA暴露给AI这是整个方案里最核心的一步。我用FastMCP加asyncua写了一个最小可用的MCP Server把“读节点”“写节点”“浏览节点”三个能力暴露出去。核心代码大概是这样的import asyncio from fastmcp import FastMCP from asyncua import Client UA_ENDPOINT opc.tcp://localhost:4840 mcp FastMCP(opcua-gateway) mcp.tool() async def read_tag(node_id: str) - str: 读取 OPC UA 节点的当前值node_id 形如 ns2;i1 client Client(UA_ENDPOINT) try: await client.connect() node client.get_node(node_id) value await node.read_value() return str(value) finally: await client.disconnect() mcp.tool() async def browse_children(node_id: str) - list[str]: 浏览指定节点下的子节点返回 NodeId 列表 client Client(UA_ENDPOINT) try: await client.connect() node client.get_node(node_id) children await node.get_children() return [c.nodeid.to_string() for c in children] finally: await client.disconnect() if __name__ __main__: mcp.run(transportstdio)保存成opcua_mcp_server.py然后跑起来。启动之后在Cursor的MCP配置里添加这个服务AI就能调用这两个工具。我实测的第一句是“浏览一下模拟服务器的根节点”AI通过browse_children返回了节点列表然后我再说“读取Counter节点的当前值”AI自动调用read_tag。整个体验非常像你雇了一个“懂工业协议的助理”你说人话它去操作UA客户端。强烈建议你先用stdio transport跑通后面再考虑HTTP/SSE。stdio模式下工具调用是在本机完成的权限模型清楚出问题也好查日志。4.5 数据安全与权限千万别裸奔链路跑通之后第一件事就是收紧安全而不是急着接更多场景。我给生产环境的建议OPC UA服务器必须关闭匿名访问至少使用账号密码重要点位建议证书认证。安全策略至少Basic256Sha256不要用None。MCP Server里把“写节点”工具单独隔离默认不对AI开放需要时通过审批后临时启用。对MCP工具调用做日志审计记录谁、什么时候、读了哪些点、写了哪些值。如果数据要出车间务必走网关单向转发不要让AI客户端直接触碰生产网段。这些听着好像“过于谨慎”但设备数据不是开玩笑的。AI生成代码写错了可以改AI直接写错一个模拟量还能补救真到产线上写错一个阀门开度那就不只是代码问题。“选边”选得越激进安全边界就越得建得保守这两件事是配套的。5. 常见问题与排查记录5.1 OPC UA连接失败、握手不过最大的坑是安全策略不匹配。Prosys默认可能同时暴露多个Endpoint不同Endpoint对应不同SecurityPolicy。你代码里没指定或者指定了一个服务器不支持的策略连接就会在握手阶段直接失败。排查方法很简单用UaExpert连一下同一个服务器看看哪个Endpoint是活的把字符串复制出来在代码里显式指定。另外证书信任也经常引发奇怪问题。本地测试时如果证书不受信任可以在UA服务器端选择“接受临时证书”但生产环境必须建立正规的证书颁发流程别图省事。5.2 MCP Server启动成功但AI工具里看不到tools我遇到两次都是因为配置格式问题。Cursor的MCP配置里command要写成Python解释器的绝对路径后面跟脚本路径如果你直接写python环境变量没对上导致Server虽然拉起来了但握手失败工具列表自然是空的。解决办法是先手动在终端里跑一遍python opcua_mcp_server.py确认没有报错弹出再去配置里指绝对路径。还有就是模型对工具的描述不敏感你给tool取名叫read_tag但描述写得含糊模型不一定知道该调用它所以描述要写成人话。5.3 AI生成的OPC UA代码质量忽高忽低这不是模型笨而是你没有把规范和示例喂进去。AI很喜欢“自由发挥”所以你需要用Rules限定它最好再给一段高质量参考代码。你可以在Rules里明确“仿照examples/opcua_client.py的风格写新代码”这样生成结果的稳定性会大幅提升。如果某个工具频繁用它自己编造的库不用跟它争直接在Rules里禁止那类库即可。实测下来“禁止法”比“说服法”有效得多。5.4 Rules文件写了但不生效大概率是路径不对或文件命名不匹配。Cursor识别的是.cursor/rules/*.md或者在项目根目录放.rules文件Claude Code识别的是CLAUDE.md不同工具有各自的优先级。还有一点容易忽略Rules文件本身也有“是否启用Glob匹配”的配置如果你只针对特定目录写规则而AI生成的文件在其他目录规则自然管不到。我在项目里会把“全项目通用规范”放在根目录把“模块级规范”放在子目录层级清晰避免互相覆盖。5.5 模拟器没问题换真机就出问题这是最经典的“最后一公里”翻车现场。模拟器用默认命名空间、地址是裸NodeId但真实PLC厂商的UA服务器命名空间索引和节点结构千差万别。比如西门子S7-1500的OPC UA服务器节点结构跟Prosys模拟器完全不同。解决办法是先在UaExpert里浏览真机节点把真实NodeId抓出来确认用Read能读到值再把这个地址写死到MCP工具的参数里做验证。模型方面能自动浏览出节点结构再读取体验最好但底层需要额外做缓存和映射这不是一个Demo能解决的。我把这几类高频问题整理成了表方便你排查时直接翻现象常见原因处理建议UA握手失败安全策略不匹配用UaExpert确认Endpoint代码显式指定UA提示证书错误证书不受信任本地测试可临时信任生产走正式CA流程MCP工具列表为空MCP Server配置格式不对手动运行脚本排查报错配置绝对路径AI生成代码乱用库Rules缺约束增加禁止项附高质量参考代码Rules没生效文件路径/命名不对确认工具规则优先级通用规范放根目录换真机读不到数据节点结构不同先UaExpert浏览真机节点再写死NodeId验证AI调用MCP工具超时同步阻塞/网络改为异步客户端超时时间调到10秒以上6. 选完边之后我的一点个人体会试完这几条路之后我最大的体会是“选边”这件事真正的答案藏在你对“资产”的定义里。今天选Cursor还是Claude Code是别人的生态战争跟你关系不大但你在MCP Server里封装的数据节点、在Rules里沉淀的工程约束、在Skills里固化的业务流程这些才是你自己的资产。工具会换厂商会变但你把工业经验转成AI能理解和执行的规则这件事的价值不会消失。实际操作中还有个小技巧分享给你别一上来就搞复杂的Skill先从一份干净的CLAUDE.md或者.cursor/rules开始把最常用的OPC UA开发规范写进去等AI生成的代码质量稳定了再考虑把某个高频场景比如“KepServerEX标签映射”“WinCC报警导出”抽成Skill。步子小一点失败成本就低很多。直接上手时用Prosys模拟器加一个MCP Server跑通“AI读实时数据”这个体验比看一百篇文章都管用。等你在对话框里问出第一句“当前温度是多少”并且AI答对的时候你就会明白OPC UA这层老协议在这一轮AI工具生态里不是被边缘化而是被换了一种更直接的消费方式。工具在打仗OPC要做的是把数据准备好谁赢都能接得住。