把博途交给AI：TIA_Portal_Openness_MCP的实战体验

工控圈也开始玩 MCP 了

6 月 14 日这周，linux.do 上一个帖子让不少自动化工程师停下了滑动的手指：有人把 Siemens TIA Portal（博途）接到了 MCP 协议上。项目叫 TIA_Portal_Openness_MCP，最新版本是 v2.2.1，支持博途 V20 和 V21，作者把 Openness 这套向来劝退人的 .NET API 直接封成了一个 MCP Server，Cursor、VS Code、Claude Desktop 这类客户端配一下 JSON 就能让 AI 帮你建项目、加硬件、写 SCL、生成 WinCC Unified 画面、编译、诊断、保存——一条龙。

对自动化行业来说，这是个挺微妙的时间点。Siemens 自己今年初推出了集成在 TIA Portal V20+ 的 Copilot，但那是个把 PLC 代码往云端发的 SaaS 助手，很多工厂的 IT 安全策略根本过不去。MCP 这条路意味着：用户可以自己选 Claude、GPT、DeepSeek、Qwen，甚至本地 Ollama 跑的 Llama 3.1，数据全程不出工程师工作站。

本文基于一位长期使用者在 linux.do 的分享，加上对项目仓库的实测，聊聊这个项目目前的真实状态。

它解决的是什么问题

搞过博途自动化二次开发的人都知道，Openness 是西门子官方那套 .NET 接口套件，理论上能从代码里操控博图软件——新建项目、加硬件、生成程序块、编译、导入导出全流程。但是真正写起来非常劝退：

• 必须把当前 Windows 用户加进 Siemens TIA Openness 用户组，否则直接拒绝访问；
• 注册表路径、版本号、Assembly 引用一个都不能错；
• 一切操作都得离线，设备在线状态下大量 API 直接报 This function is not supported in online mode；
• 文档分散，示例代码大多停留在 V15、V16 时代。

这就导致一个尴尬的局面：Openness 本来是为「PLC 工程自动化」准备的金钥匙，但用它的门槛比直接手撸 PLC 还高。

TIA_Portal_Openness_MCP 的思路很直接——把这层脏活全部封装成 MCP 工具调用。作者交付的是一个预编译好的 TiaMcpServer.exe（.NET Framework 4.8），不需要你再去配 Openness SDK、不需要你写一行 C#。一个典型的 Cursor MCP 配置长这样：

{
  "mcpServers": {
    "tia-portal": {
      "command": "D:\\tia-mcp\\tools\\tiaportal-mcp\\src\\TiaMcpServer\\bin\\Release\\net48\\TiaMcpServer.exe",
      "args": [
        "--tia-portal-location", "D:\\app\\TIA20\\Portal V20",
        "--tia-major-version", "20"
      ]
    }
  }
}

配好之后，你在 Claude Desktop 或者 Cursor 里就能直接对 AI 说「帮我生成一个电机启停的 SCL 块，导入到现有项目里编译一下」，剩下交给模型 + MCP。

两种用法：MCP 还是 CLI？

项目实际上提供了两条调用链路，定位完全不同。

MCP 方式：自然交互，但链路长

这是项目主打的形态。把 TiaMcpServer.exe 作为 MCP Server 挂在客户端里，AI 通过 tools/list 拿到一组工具描述符——Bootstrap、CreateProject、PlcBuildAndImport、CompileAndDiagnosePlc、EnsureUnifiedHmiButtonAction、ApplyUnifiedHmiScreenDesignJson、SaveProject 等等——然后边聊边调。

体验上是「AI 助手式」的：你说一句它做一步，做完反馈错误你接着改，特别适合在原型阶段把一个想法快速捏出来。

但毛病也比较明显：

• 客户端兼容性：作者文档里专门有一篇 docs/mcp-ide-and-tool-visibility.md 在解释「为什么某些 IDE 里看不到某个工具」——MCP 协议虽然定了，但各家客户端的工具描述符缓存策略五花八门；
• 上下文一长就飘：博途工程稍微复杂一点，光是 Tag 表、UDT、DB 块的命名规范说明就能塞满几千 token，模型一旦上下文超载，命名冲突和地址重叠就开始出现；
• 可控性差：AI 决定先调哪个工具、参数怎么填，出问题之后追溯链路要看一长串对话历史。

CLI 方式：粗暴但好用

另一条路是绕开 MCP 客户端，直接命令行。项目暴露了 generate、patch、compile、describe、export / import、prewarm 这些命令。

说实话，对真的想拿它干活的工程师，CLI 反而更香：

• 出问题第一时间能看到 stderr，不用猜 AI 为什么没调这个工具；
• 想批量生成 50 个相似的程序块？写个 shell 脚本就完事；
• 可以接到 Jenkins、GitLab CI 里，把博途工程的编译诊断变成流水线的一部分；
• 调试成本明显更低。

代价是丢掉了「自然语言」这层皮，你得自己把任务拆成命令序列。但对老工程师来说，这反而是熟悉的姿势。

实测能做到什么程度

按作者给的 runbook，一条完整的「从零生成 PLC + Unified HMI」流程大致是这样：

1. Bootstrap 把 TiaPortal 进程拉起来；
2. CreateProject 建空项目；
3. 加硬件和网络配置；
4. PLC 部分用 PlcBuildAndImport 逐项导入，每次先 dryRun=true 做干跑校验；
5. CompileAndDiagnosePlc 编译并把诊断信息回传；
6. HMI 部分用 EnsureUnified* 系列工具建好画面骨架，再 ApplyUnifiedHmiScreenDesignJson 应用画面设计，BindUnifiedHmiTagDynamization 做动效绑定；
7. SaveProject 收尾。

实测下来，SCL 编写辅助这块是最有价值的。让 Claude 3.5 Sonnet 或者 GPT 写一个电机启停、PID 控制、状态机风格的功能块，输出质量明显比纯文本提问要高——因为 MCP 那边能把项目里现成的 Tag、UDT 结构当上下文喂给模型，生成的代码直接能编译过。

但是别高兴太早，几个明显的坑：

• 规范一致性：模型不会自动遵守你公司内部的命名规范、注释模板，得自己写大段 system prompt 约束；
• 复杂联锁逻辑：稍微多几个互锁条件，AI 就会忘记前面的 Tag 已经被另一个 FB 占用，生成的代码编译不过；
• HMI 画面布局：能生成结构正确的 Unified 画面 JSON，但美观度和实际生产环境的 HMI 比还差一截；
• 在线监控只读：项目目前只做了「在线只读监控」，不要指望它替你下载程序或者改运行态参数，这也是工程安全的基本盘。

它和 Siemens 自家 Copilot 是什么关系

这是绕不开的话题。Siemens 自家的 TIA Portal Copilot 走的是闭源 SaaS 路线，模型固定、代码上云、订阅制。TIA_Portal_Openness_MCP 走的是另一条路：

| 维度 | Siemens Copilot | TIA_Portal_Openness_MCP | | --- | --- | --- | | 模型选择 | Siemens 专有，无选择权 | 任意支持 MCP 的 LLM | | 数据流向 | 代码发往云端 | 本地 stdio/HTTP，可全离线 | | 接入方式 | 嵌在 TIA Portal 里 | 独立 MCP Server，IDE 无关 | | 成熟度 | 官方背书、稳定 | 社区项目、迭代快但不稳 | | 二次开发 | 不开放 | 源码可控、可扩展 |

对中大型集成商和有合规要求的工厂，本地 MCP 这条路几乎是唯一选择。对个人开发者和小团队，它是个非常便宜的 AI + PLC 实验平台。

怎么选模型

既然能接任意 LLM，模型选型反而成了关键变量。我们在不同模型下跑了同一个「带斜坡启停的电机控制 FB」生成任务：

• Claude 3.5 Sonnet / Claude 4：SCL 语法准确度最高，对 Siemens 数据类型（Time、TON、UDT）理解最到位；
• GPT-4.1 / GPT-5：对项目结构的全局理解强，跨文件改动比较稳；
• DeepSeek V3：写常规逻辑没问题，复杂联锁会漏分支，但价格优势明显；
• Gemini 2.5 Pro：长上下文有优势，能一次吞下整个项目导出的 XML 做分析。

如果懒得在多个 API Key 之间来回切，可以考虑用 OpenAI Hub 这种聚合平台一个 Key 调所有模型，反正 MCP 这边只需要兼容 OpenAI 格式的客户端就能跑通，省下来的精力都花在调 prompt 和补 system rules 上更划算。

一点判断

这个项目当前的定位非常清晰：SCL 辅助编写工具、AI 接入 TIA Portal 的实验平台、自动化工程生成的探索原型。

它不是能直接替代工程师的生产工具。复杂工程、联调阶段、规范一致性、工程可控性这几块离生产可用都还有距离。一旦你尝试用它做几千个 Tag 的大型项目，立刻能感受到 MCP 链路上下文管理的吃力。

但作为一个起点，它的价值在于：**第一次让普通自动化工程师能用自然语言驱动博途，而不需要先学一遍 Openness SDK。**这件事本身在过去十年的工控软件历史里是没发生过的。

接下来值得关注的几个方向：在线编辑能力的边界、HMI 自动生成的成熟度、以及多人协作时项目状态的一致性管理。如果作者能把这几块再打磨一两个版本，工控行业的「AI 助手」就真的不只是 Siemens 那一家说了算了。

参考来源

• bulaofen0036-coder/TIA_Portal_Openness_MCP - GitHub：项目主仓库，含 v2.2.1 完整交付包、文档、模板和示例配置。
• AI 接入博图 TIA 实战分享 - linux.do：原始讨论帖，作者分享了 MCP 与 CLI 两种用法的实际感受和取舍。