Software 2.0

TIA-Portal-CLI：PLC AI编程工具

admin -

Claude Code和Codex的应用正在从Web应用和代码库扩展到PLC工程领域。我这次研究的Tia-Portal-CLI使得西门子TIA Portal可以由AI智能体操作，同时建立了默认预运行、显式--apply命令和无在线PLC操作等边界。重要的不仅仅是"AI可以编写PLC代码"，而是它如何从机制上缩小危险操作的范围。

今日结论：

  • Tia-Portal-CLI是一个开源软件，允许Claude Code/Codex等通过CLI处理西门子TIA Portal离线项目。
  • 其本质不在于自然语言操作，而在于"执行边界"，如JSON输入/输出、默认预运行、显式--apply命令和禁止在线操作。
  • 截至2026年9月2日，它是一个隐藏的宝石，虽然规模仍然较小，但在v2.0.0发布后经历了快速的技术变革，有大量更新。
  • 另一方面，成功的编译并不保证作为设备的正确性。隔离的测试项目、模拟、人工审批和变更管理至关重要。
  • 类似的运动正在PLC、CAD/CAE、EDA和ROS 2中重叠，"领域工程智能体化"正在成为一股技术浪潮。
AI需要完善的TIA Portal开发文档？可以使用 博途编程文档MCP ，支持Claude Code、Codex、Cursor、OpenCode等各种主流编程智能体！

1、Tia-Portal-CLI改变了什么？

传统上，要从外部自动化TIA Portal，需要为每个用例使用西门子Openness API创建C#工具，单独实现项目连接、白名单注册、XML导出/导入和异常处理。

Tia-Portal-CLI将这些重复性工作整合到一个CLI中。AI智能体和工程师可以从shell调用命令并以JSON格式接收结果。公开的README列出了超过100个动词，针对PLC块、标签、硬件、PROFINET、SINAMICS、WinCC HMI、库、模拟等。

基本结构如下：

Claude Code / Codex / Cursor
→ tia <verb> --json
→ tia.exe
→ Siemens Openness API
→ TIA Portal V19–V21 offline project

值得注意的是，它不包含专门为AI设计的庞大智能体基础。它将TIA Portal端转换为现有AI编码智能体擅长的形式："调用CLI、读取结构化结果并决定下一步操作。"

2、最大的价值不是"能够编写"，而是缩小危险区域

在工业自动化中，仅仅将API交给AI是不够的。随着操作能力的提高，错误推理、过度更改和目标误识别的影响也会增加。

Tia-Portal-CLI针对这些风险设置了多重边界。

2.1 默认为预运行写入

与更改相关的动词在正常执行期间返回"计划更改的内容"，只有在附加--apply时才反映更改。你可以在命令级别将AI提案与实际更改分开。

2.2 不操作在线PLC

README明确指出，联机、下载到PLC和Multiuser签入不在范围内。换句话说，这个开源软件不是为了自行将代码写入运行设备而设计的。

2.3 本地/本地部署完成

它没有将项目数据发送到云服务的配置，而是在Windows上与TIA Portal在同一交互会话中运行。能够轻松采用不向外传输客户特定标签名称、设备结构或DB内容的配置在制造业中非常重要。

2.4 包含更改后的编译、审计和重新验证

不仅可以连接XML重写，还可以将编译、差异、审计和交叉引用连接到后续阶段。在重新执行期间将现有状态视为无操作的设计也是接近声明式协调的概念。

结合这四点，可以解读为创建了提案→预运行→人工确认→应用→编译/审计的狭窄执行走廊，而不是给予AI自由。

3、从公开基准测试中可见的另一个设计哲学

在作者发布的实际测量中，报告称单独调用5个命令需要20.1秒，而仅在批处理中附加一次需要8.1秒。此外，对于小规模项目，完整快照为219.5KB，markdown大纲tree为2.6KB。

这不仅仅是关于速度改进。AI智能体随着读取输出的增加而消耗令牌，重要信息被淹没。使用tree把握整体并将仅必要细节输出到文件的设计正在将上下文工程引入PLC自动化。

然而，这些是在作者环境中的实际测量。不能保证在不同的TIA Portal版本、项目规模或PC性能下获得相同的值。将这些数字视为可重新验证的设计文档而非"性能保证"是合适的。

4、使用3个开源软件比较与现有方法的差异

即使在相同的PLC领域，最近的开源软件也在选择不同的边界。

  • Tia-Portal-CLI：使用shell/JSON作为边界，专注于预运行和--apply。可从Claude Code、Codex、Cursor等使用。
  • tia-portal-mcp：通过MCP连接到西门子TIA Portal V21的专用桥接。配置为从MCP客户端作为工具调用。
  • TwinCAT-Agent：整合了Beckhoff TwinCAT的结构化文本规则、专用技能、本地/远程MCP和语法检查。
  • NiRuLogic：集成了IEC 61131-3梯形图编辑器、模拟器和Arduino的MCP，允许AI创建梯级并检查模拟结果。

我想用Tia-Portal-CLI评估的不是MCP和CLI之间的协议差异。而是它同时设计了不触及生产设备的生成/编辑能力和安全边界。

在工业工具中，不仅仅是"AI能做什么"，以下5点成为架构的中心：

  1. 可以读取什么
  2. 可以提议什么
  3. 哪些操作固定为预运行
  4. 谁批准应用
  5. 哪些路径在技术上不可达

5、仍然存在的风险

预运行很重要，但它不是万能药。

首先，成功的编译并不保证控制规范的有效性。联锁、异常条件、恢复、时间和设施特定的安全要求必须单独验证。

其次，虽然'--apply'增加了项目更改的清晰度，但如果审批者不理解差异，它是无意义的。你需要更改量限制、固定目标PLC、允许动词的允许列表、双方审批和审计日志。

第三，存在构建可重现性的约束。由于许可证，西门子的Openness程序集无法与CI运行器捆绑，因此仅靠公共CI无法实现完整的构建/测试重现。作者还解释说本地验证是必要的。

第四，必须按版本检查许可证。v2.0.0之前的版本是MIT，而主分支表示对后续版本应用AGPL-3.0的策略。对于企业采用，你应该与法务部门确认使用的版本、修改、分发和网络服务的存在。

因此，当前的建议不是"生产部署"，而是在隔离的测试项目中尝试。

6、如果是我，我会首先尝试这个

对于30-120分钟的首次实验，我会按照以下顺序进行：

  1. 阅读AGENTS.md、SECURITY.md和docs/BENCHMARKS.md以确认允许和禁止的操作。
  2. 在装有TIA Portal V19-V21的隔离PC上，仅运行只读的'init.ps1 -Check -Json'。
  3. 打开一个不是生产副本的一次性项目，仅尝试只读操作，如'doctor'、'tree'和'snapshot'。
  4. 提前记录"更改规范"、"验收标准"和"禁止操作"，仅向AI提供该范围。
  5. 让人工审查预运行结果，仅在测试项目中执行'--apply'、编译和审计。
  6. 重新执行相同操作以确认它是否变为无操作，或者差异和审计日志是否可追踪。

这里要寻找的成功标准不是生成的代码量。

  • 不会发生目标混淆
  • 预运行和应用清晰分离
  • 人工可以理解更改差异
  • 编译/审计可以由机器确定
  • 禁止的在线路径无法到达

只有在满足这五个点之后，你才能进入衡量AI利用生产力的阶段。

7、结束语

'Tia-Portal-CLI'不仅仅是AI生成PLC程序的演示；它是将AI编码智能体连接到工业工具的设计教科书。

这里发生的技术转变不仅仅是"代码生成目标的扩展"。

仓库智能体 → 工程工具智能体 → 领域约束执行智能体，AI智能体的责任边界正在转移。

如果同样的趋势在ROS 2、Simulink、CAD/CAE、EDA和PLC中继续，下一个竞争轴心将不是模型性能，而是每个专业领域的含义、约束、验证和批准是否能够嵌入到智能体框架中。

本文是基于公开信息的个人技术调查和分析。应用于工业设备时，请始终遵循组织的安全规定、变更管理、许可证和安全要求。

原文链接：Claude Code/Codex handles PLCs—The 'dry-run boundary' of the TIA Portal CLI

汇智网翻译整理，转载请标明出处