过去几十年，PLC工程的核心工作方式几乎没有发生根本变化。工艺工程师编写 Control Narrative、I/O List、Cause & Effect、P&ID 等设计资料，控制工程师阅读这些文档，在头脑中完成需求理解、逻辑拆解和异常情况推演，然后再进入 TIA Portal、Studio 5000、CODESYS 等开发环境，一点一点创建变量、设备、功能块、梯形图和控制程序。PLC编程工具越来越强，但从“工程需求”到“可执行控制逻辑”之间，长期存在着一道高度依赖人工经验的鸿沟。
大模型和AI Agent正在开始改变这道鸿沟。真正值得关注的并不是“AI能够写几段Structured Text”，而是一套新的PLC工程范式正在出现：
Requirements Understanding → Intermediate Representation / Plan → Logic Synthesis → Project Build → Verification → Human Approval
可以把它称为 AI-native PLC Engineering。它意味着AI不再只是附着在PLC开发软件旁边的聊天机器人，而逐渐成为控制工程生命周期中的一个执行主体：阅读需求、理解项目、制定工程计划、生成控制逻辑、修改工程对象、调用编译和仿真工具、发现错误并重新修正，最后将经过验证的工程结果交给工程师批准。
从PLC Copilot走向PLC Engineering Agent
早期工业Copilot的典型使用方式，是工程师问：“TON怎么使用？”“解释一下这段梯形图”“帮我写一段SCL代码”。AI实际上只是一个知识助手或代码助手，人仍然需要把AI输出复制、修改、组合并放进真实PLC工程。
2026年的情况正在发生明显变化。
Rockwell Automation在FactoryTalk Design Studio 2.05中引入了 AI Agent Explorer，包括Plan Agent和Build Agent。Plan Agent能够读取I/O List、规格书、P&ID、L5X等工程资料，分析差异和缺口，并生成结构化的controller project plan；Build Agent则可以执行这一计划，直接创建library definitions、devices、tags以及controller code，同时逐步验证执行结果。Rockwell已经把路径明确推进到“design assets → project plan → working control project”，而不仅仅是代码问答。
Siemens也在沿着相似方向推进。早期Engineering Copilot主要根据自然语言生成SCL代码并导入TIA Portal，而2026年推出的 Eigen Engineering Agent 已经进一步进入TIA Portal项目上下文，可以生成PLC代码、创建HMI、配置设备，并在完成任务以后检查自身结果、继续修正。换句话说，AI从“给工程师建议”转向了“直接操作工程环境”。(西门子新闻)
CODESYS走的是另一条非常值得注意的路线。CODESYS V3.5 SP22增加了面向AI工具的MCP Server，使外部LLM可以通过标准化工具接口读取并操作CODESYS工程。官方已经展示，通过自然语言即可创建POU、变量和程序逻辑，并允许AI执行“生成代码—编译—读取错误—修改—再次编译”的完整循环。这里最关键的变化并不是模型，而是PLC IDE第一次越来越像一个可以被Agent调用的“工具环境”。(CODESYS)
因此，AI-native PLC Engineering与普通PLC Copilot的分界线其实非常明确：
Copilot产生内容，Agent改变工程状态。
前者回答“应该怎么做”；后者开始真正执行“把它做出来”。
第一层：Requirements Understanding——先理解工程，而不是先生成代码
PLC工程自动化最大的误区，是把问题简单理解成“自然语言生成PLC代码”。
事实上，真正困难的是需求理解。
例如Control Narrative中写：
“系统处于AUTO模式，入口阀打开并且液位正常时允许启动泵；低液位、入口阀关闭或者电机故障时停止泵。”
对于工程师而言，这句话似乎非常清楚，但要真正成为PLC程序，还存在大量没有显式写出的工程语义：
启动后是否自保持？故障解除后是否允许自动重启？STOP与START同时发生时谁优先？液位信号需要持续多久才算低液位？传感器断线如何处理？AUTO切换到MANUAL时当前输出是否保持？PLC重新上电以后状态是什么？
因此，AI-native PLC Engineering第一步不是“Code Generation”，而是Requirement Engineering。
Agent需要同时读取Control Narrative、I/O List、P&ID、Alarm List、设备数据表、控制标准、已有Function Block Library以及既有PLC工程，然后建立一个项目级语义模型。Rockwell的Plan Agent之所以重要，也正在于它把“先理解、再计划”明确变成了一个独立工程阶段。
未来成熟的PLC Agent甚至应该能够主动发现需求问题。例如两个章节分别规定“故障解除后自动恢复”和“任何Trip均需人工Reset”，Agent不应该自行猜测，而应该把二者标记为Requirement Conflict。又比如“压力过高后关闭阀门”没有给出阈值、延迟时间和复位条件，Agent应该输出Requirement Warning，而不是凭模型经验补全。
这实际上形成一种新的能力：
Requirements Linting。
未来控制工程师写Control Narrative，很可能就像程序员使用静态代码检查器一样，在编程之前先看到大量关于歧义、缺失、冲突和不可验证条件的提示。
第二层：Intermediate Representation / Plan——AI-native PLC的真正核心
直接执行：
Control Narrative → LLM → PLC程序
从工程角度看并不是理想路线。LLM必须同时完成需求理解、逻辑设计、变量生成、功能块选择、厂商语法适配、XML组织和图形布局，任何一步出现错误都很难追踪。
更加可靠的架构是：
Engineering Documents
↓
Requirements Understanding
↓
Semantic IR / Project Plan
↓
Logic Synthesis
↓
PLC Project Build这里最重要的是中间的 Intermediate Representation，IR。
IR不应该只是PLC代码换一种写法，而应该表示控制本身。例如“Pump P101”具有Auto、Manual两个模式；启动许可包括液位正常、入口阀打开、电机无故障；低液位属于Trip；Trip具有高于Start的优先级；故障以后禁止自动重启；启动命令采用Reset-priority latch。
这些信息都应该在真正出现AND、OR、TON、RS之前完成建模。
ABB研究团队公开的Spec2Control很好地说明了这一思想。该系统不是让LLM直接自由生成最终PLCopen XML，而是采用多步LLM工作流，将自然语言Control Narrative首先转换为结构化控制表示，再由确定性程序生成IEC 61131-3 FBD以及PLCopen XML。在10份Control Narrative、65个复杂案例上的实验中，研究团队报告控制策略连接正确率达到98.6%，并估计能够减少94%—96%的人工工作量；项目目前同时提供开源版本，并计划集成进入ABB商业工程工具。(arXiv)
Rockwell的“Plan Agent → Build Agent”虽然没有把中间层称为IR，但从软件架构上看，Structured Project Plan实际上承担了非常类似的角色：AI首先形成可检查的工程计划，工程师可以查看和修改，然后Build Agent再按照计划改变PLC项目。
这说明一个非常重要的趋势正在形成：
大模型负责把模糊的工程语言转化为明确的机器可执行意图，而不是直接承担全部代码生成细节。
第三层：Logic Synthesis——从控制语义到IEC 61131-3
进入Logic Synthesis以后，很多任务反而不应该继续交给LLM自由发挥。
如果IR已经明确规定：
“P101运行许可 = AUTO ∧ Level_OK ∧ Valve_Open ∧ ¬Motor_Fault”
那么系统接下来需要完成的是确定性的逻辑综合：选择AND、NOT、RS、TON等标准块，进行类型检查、连接分析和优先级处理。
对于简单组合逻辑，可以生成FBD或LD；对于包含大量数学运算和数据处理的逻辑，可以生成ST；对于Starting、Running、Stopping、Fault等状态明显的设备流程，则更适合生成状态机或SFC。
因此，真正成熟的系统目标其实不应该局限于：
Control Narrative → FBD
而应该升级为：
Control Narrative → Control Model → IEC 61131-3
FBD只是一种后端表示。
这一阶段还会催生一个非常重要的工程资产：Function Block Knowledge Base。Agent只需要判断“这里需要一个On-delay Timer”或者“这里需要一个Motor Control Block”，真正采用Rockwell AOI、Siemens FB、CODESYS Function Block还是企业自己的标准库，则由目标平台后端确定。
于是同一份控制语义理论上可以输出：
Control IR
/ | \
/ | \
Siemens Rockwell CODESYS
↓ ↓ ↓
TIA Portal Logix CODESYS Project
这时候所谓“AI-native”，就不再等于某一个大模型会写某一种PLC语言，而逐渐接近真正意义上的控制软件编译系统。
第四层：Project Build——代码生成只是工程生成的一部分
真实PLC项目远不只是几十个POU。
一个完整控制项目还包括设备树、I/O映射、Data Type、Tag、Task、Program、Library、网络配置、HMI变量以及各种厂商特定工程对象。
所以AI-native PLC Engineering最终必须从“Code Generation”升级到“Project Generation”。
Rockwell Build Agent已经开始直接创建devices、tags、libraries和controller code；Siemens Eigen开始操作TIA Portal中的PLC、HMI和设备配置；CODESYS MCP Server则把整个IDE暴露成AI可以调用的一组工程工具。三者实际上都在说明同一件事：
PLC工程软件正在从“人操作GUI的软件”，演化成“人和Agent共同操作的工程平台”。
这会进一步改变PLC工程软件的架构。未来PLC IDE是否拥有稳定API、项目对象模型、版本控制接口、编译接口、仿真接口和机器可调用工具协议，重要性可能不亚于GUI本身。
PLCopen XML以及IEC 61131-10在这里也具有重要意义。PLCopen的XML交换机制本来就希望在PLC编程环境与高层工程工具、模拟器、验证工具和文档系统之间建立标准化接口，其中甚至明确包含“由高层工程工具生成图形和逻辑信息”的使用场景。这种原本为工程数据交换设计的接口，在AI时代恰好可以成为Agent生成PLC工程的重要中间通道。(PLCopen)
第五层：Verification——AI-native PLC真正的护城河
这是整个体系最重要的一层。
PLC领域不能仅仅用“代码看起来正确”或者“98%的连接一致”判断程序质量。控制程序具有高度非线性的后果：100条连接正确99条，并不意味着控制系统99%安全。一条错误的联锁、一处错误的NOT、一次不该发生的自动重启，就可能改变整个设备行为。
因此，真正应该验证的是：
Behavioral Equivalence——生成程序的行为是否满足原始工程需求。
这意味着AI在生成控制逻辑以后，还应该自动生成测试场景。例如某需求规定“液位低于20%持续2秒后停泵”，系统就应该生成19%、20%、21%的边界条件，1.9秒、2.0秒、2.1秒的时间条件，以及液位短暂跌落又恢复的瞬态测试。
理想架构甚至应该让“生成程序”和“生成测试”由相对独立的Agent完成：
Requirements
/ \
/ \
Logic Agent Test Agent
↓ ↓
PLC Project Test Cases
\ /
\ /
PLC Simulator
↓
Behavior Compare
↓
Verification
这是为了避免一个非常隐蔽的问题：如果同一个模型错误理解了Requirement，然后又根据同一个错误理解生成测试，那么错误程序完全可能“全部测试通过”。
CODESYS已经开始出现非常早期但很有代表性的闭环：AI可以生成代码，调用编译器，读取错误，再自行修正。Siemens现有Engineering Copilot体系中也已经出现Test Case Generator等专门功能。下一阶段真正重要的竞争点，很可能就是把编译、静态分析、仿真、单元测试、时序测试和数字孪生纳入Agent Harness。(CODESYS)
换言之：
未来优秀的PLC AI不是最会写代码的模型，而是最善于证明自己生成的代码没有问题的系统。
第六层：Human Approval——AI越深入控制核心，人越不能消失
AI-native并不意味着Human-out-of-the-loop。
恰恰相反，随着Agent越来越接近实际控制系统，Human Approval的重要性反而会提高。
一种合理的职责划分应该是：
AI负责理解、规划、生成和验证；工程师负责批准。
而且批准不应该只是一个简单的“Accept”按钮。工程师需要能够看到：
原始Requirement是什么，AI如何解释它，生成了哪些IR规则，这些规则对应哪些PLC Network或POU，经过了哪些测试，哪些需求仍存在不确定性。
这形成完整的：
Requirement → IR → Logic → Test → Result
追踪链。
例如工程师点击某一个Motor Trip输出，应当能够反向看到：
“该逻辑来自Control Narrative第4.3.2条，由IR INTLK_017生成，对应PLC Network 27，已经通过Test Case 83、84、85验证。”
这种 Requirements Traceability，很可能比单纯的代码生成速度更重要。
在Safety PLC领域，这一点尤其关键。IEC 61508-3不仅要求安全相关软件遵循软件安全生命周期，还对开发工具、测试工具、配置管理和验证过程提出明确要求。Rockwell当前也保持了明显的产品边界：FactoryTalk Design Studio Copilot可以解释Safety PLC代码和安全设备配置，但不能修改安全相关内容。(IEC Webstore)
所以短期内更现实的路线不是让AI自主部署Safety Logic，而是：
AI生成 → 自动验证 → 工程师审核 → 安全流程批准 → 部署。
AI能够进入工程执行层，并不意味着它能够跳过工业控制原有的责任体系。
从“AI写PLC”走向“PLC工程的Agentic Harness”
把这六个阶段放在一起，可以看到AI-native PLC Engineering真正的系统形态：
Control Narrative
P&ID / I/O List
Cause & Effect
Standards / Existing Project
│
▼
Requirements Understanding
│
▼
Semantic IR / Project Plan
│
▼
Requirements Linting
│
▼
Logic Synthesis
│
▼
Project Build
Devices / Tags / PLC
HMI / Libraries
│
▼
Compile / Static Analysis
│
▼
Simulation / Test Agent
│
▼
Behavioral Verification
│
▼
Requirements Traceability
│
▼
Human Approval
│
▼
Deployment这里面大模型本身只占据其中一部分。
真正决定一个AI PLC工程系统是否可靠的，是它周围的Harness：
工程文档解析器、Semantic IR、企业标准库、Function Block Knowledge Base、PLC IDE工具接口、确定性代码生成器、编译器、仿真器、测试框架、版本管理、Requirement Traceability以及审批机制。
因此，未来PLC工程领域真正形成技术壁垒的，很可能并不是“我们用了哪一个大模型”，而是：
谁能够建立一套让大模型可靠地理解工程、操作工程、验证工程，并且无法轻易越过工程边界的Agentic Engineering Harness。
AI-native PLC Engineering真正改变的，是工程师的工作对象
传统PLC工程师的主要工作对象是：
Rung、Network、Function Block、Tag、Code。
AI-native PLC Engineering出现以后，工程师的工作对象会逐渐向上移动：
Requirement、Constraint、Architecture、Standard、Test、Approval。
工程师不再需要亲手构建每一个AND、OR和TON，而更多地告诉系统：
“我要设备实现什么行为？”
“什么情况下绝对不能启动？”
“发生故障以后允许怎样恢复？”
“公司的标准控制模板是什么？”
“什么样的测试能够证明这段程序正确？”
AI再负责把这些意图转化为工程计划和控制软件。
这并不是PLC工程师退出工程，而是PLC工程师逐渐从代码构造者变成控制意图与工程约束的定义者和审核者。
这也是AI-native PLC Engineering最深层的意义。
过去我们习惯把PLC编程理解为：
Engineer → Code → PLC
未来它越来越可能变成：
Engineer → Engineering Intent → AI Engineering Agent → Verified PLC Project → Engineer Approval → PLC
Rockwell的Plan & Build Agents、ABB的Spec2Control、Siemens的Eigen Engineering Agent以及CODESYS MCP Server，目前采用的技术路线并不完全相同，但它们正在从不同方向汇聚到这一结构。
因此，所谓 AI-native PLC Engineering，并不是给传统PLC IDE增加一个聊天窗口，而是重新设计整个控制软件工程流程，使需求、计划、逻辑、项目、验证和审批从一开始就能够同时被人和AI理解、执行和检查。
从这个角度看，Control Narrative自动生成FBD只是这场变化最早、最直观的一个入口。真正正在出现的，是一种新的工业软件开发模式：
让AI理解控制意图，让编译器生成确定性逻辑，让验证系统证明行为正确，最后由工程师决定它是否可以进入真实机器。
PLC仍然执行确定性的实时控制，而AI开始承担越来越多确定PLC“应该如何控制”的工程工作。
这才是AI-native PLC Engineering真正值得关注的地方。