AI 原生工业控制：不让 AI 碰实时回路，只让它当"架构师"
它把 AI 的位置说清楚了：不是替 PLC 按按钮，而是决定"谁按哪个按钮"。演示台是三颗 RGB LED，所以这是设计稿，不是业绩单。
同一件事（AI 进控制系统），有两种做法，差别不在模型强弱：
- AI 辅助（AI-assisted）：旧架构不动，把 AI 接在工程工具链旁边——写代码、查手册、报故障。AI 是外挂。
- AI 原生（AI-native）：架构重画，AI 是内核。论文的原话是「AI 作为内在核心，而不是外部增强」。
鹏城实验室（Pengcheng Laboratory）这篇论文，就是把这两代之间的分界线画出来，并且给出了它认为的第三代长什么样。它最值钱的一句判断在第四节：
不是让 AI 去做直接的实时控制——那件事风险极大——而是把 AI 提升为自主的控制架构师：把自动化任务翻译成确定性、可验证的控制应用；执行机构仍然由确定性逻辑管着。
换句话说：AI 不按按钮，AI 决定"谁在什么时候按哪个按钮"。 这句话如果成立，很多"AI 会不会搞坏设备"的争论可以直接绕过去——因为最后动的那个东西，不是 AI。
本文完整解读 Lisi Liu 等六人（鹏城实验室新型网络部，通讯作者 Shengkai Liu / 香港中文大学深圳），2026-10，《From AI-assisted to AI-native Industrial Control: Architecture, Agent Design, and Challenges》（arXiv 2610.34773，arXiv 非独占许可）。这不是一篇有实验数据的论文，是一篇架构与挑战清单的论文——所以我们既讲它说了什么，也讲它没证明什么。
控制室里的屏幕仍是"人看界面、人下判断"。AI 原生控制要改的，正是这个分工。（图：Nylki，CC0，Wikimedia Commons）
一、先把旧架构拆开：PLC = IDE + RTE
论文用一个等式开场，很工程师：
PLC = IDE + RTE
- IDE（集成开发环境）：厂商的工程套件，通常跑在 Windows 上，负责编程、配置、诊断；
- RTE（运行时环境）：真正执行程序的实时环境，可能是裸机、专有 RTOS，或者带实时扩展的通用 OS。
商业 PLC 的 RTE 通常是软硬一体的垂直整合系统，卖的就是确定性、可靠性和安全。
执行模型主要两种：多数在跑的是 IEC 61131-3 的同步扫描周期；IEC 61499 用事件驱动，面向可重构的分布式系统。
由此得出了论文认定的两个"原罪"：
| 特征 | 后果 |
|---|---|
| 封闭架构、功能固定 | 厂商锁定、互操作性差、第三方难集成 |
| 人被驱动的被动模式 | 选型 → 安装 → 编程与虚拟调试 → 现场调试与运行，四个阶段；任务一改，就要回头重做工程 |
这里有个说法很关键，值得单独拎出来——能力型（capability-oriented）vs 任务型（task-oriented）：
传统 ICS 并不直接交付"针对任务的自动化解决方案"，它交付的是一套能力基座，具体控制程序要你自己写、自己调。
翻译成买机床的比喻：厂商卖你一台机床加一本说明书，加工什么、怎么装夹，是你的事。 论文的主张是——AI 原生要卖的，是"你告诉我要加工什么，我把夹具、程序、节拍一起给你"。
而"AI 辅助"这一代，AI 只是在选型、编程、调试这些环节帮你——基座没变，所以它的天花板也没变。
二、AI 原生的第一性原理：非确定性是"特性"，不是故障
这句话是全文最激进、也最该被质疑的地方。论文说，AI 原生基础设施的前提是：
AI 模型和 Agent 是主要的执行实体，而非确定性是系统固有的、可管理的特性，不是异常。
这和工业控制几十年的信条是正面冲突的：控制的全部价值就在"确定性"。所以论文必须补一句来救场——AI 的产物是确定性、可验证的控制应用，不是 AI 直接输出 PWM。非确定性被关在"生成阶段"，执行阶段仍然是确定的。
它的架构分两半：
1）AI 原生基础设施（三层，自下而上）
| 层 | 内容 |
|---|---|
| 物理基础设施 | 异构算力、存储、网络 |
| 支撑层 | Agent 之间的通信、资源调度 |
| 模型 / 运行时 / 工具层 | 各类模型、专用 Agent 运行时、微调与训练工具链 |
注意它和"云原生"的区别：云原生的假设是服务是主体；AI 原生的假设是模型与 Agent 是主体。
2）一组协作的 Agentic AI：ICS Agent（核心）、Vision Agent、Digital Twin Agent……论文给 Agentic AI 定了三个特征：自主（autonomy）、进化（anagenesis）、可执行（actionability）。
"进化"这个词（anagenesis）在论文里不是修辞，它是第七项技能，下面会讲。
三、ICS Agent 的七项技能：一张能对照自己工作的清单
论文列了七项，我按"跟现场的关系"重排了一下，并标出今天能做到什么程度（这一列是我们的判断，不是论文内容）：
| # | 技能 | 论文怎么描述 | 今天能到哪一步（我们的判断） |
|---|---|---|---|
| A | 需求分析 | 直接从多模态输入（文字、工程图、形式化规格）理解任务，转成统一的机器可执行内部表示 | 半可做。多模态读图已经能用，但"统一内部表示"目前每家各搞一套 |
| B | 按需生成控制应用并部署 | 打破 IDE/RTE 分离：不写"针对某个 RTE 的程序"，而是生成"控制应用"并调度算力与网络去跑它 | 实验阶段。虚拟控制器让这一步有落点，但实时性与认证还没解决 |
| C | 兼容遗留系统 | 能挑一套最合适的老 RTE 配置、生成安装指导，并生成对应的 IEC 61131-3 / 61499 程序 | 最现实的一项。这条等于给旧世界留了桥 |
| D | Agent 互操作 | 和 MES Agent、SCADA Agent、机器人 Agent 交换正式化指令（例如让机器人 Agent 去执行安装接线） | 远期。跨 Agent 的指令协议还没有标准 |
| E | 虚拟调试 | 和 Digital Twin Agent 交互，在高保真虚拟环境里验证、调试、优化 | 可做。这一项是七项里最容易先变现的 |
| F | 主动监控与维护 | 部署后持续监控、检测异常、预测故障，甚至触发自主维护流程 | 可做一部分。异常检测成熟，自主触发维护要权限设计 |
| G | 进化（anagenesis） | 从运行数据、仿真结果、Agent 生态交互中持续学习，改进已有技能、长出新技能 | 概念。这是"活的系统"的卖点，也是最难验收的一项 |
两个细节值得停一下：
技能 B 的措辞很讲究。 它特意说"生成控制应用 + 调度资源"，而不是"生成针对某 RTE 的程序"。这是一次抽象层级的抬升——从"给这台 PLC 写程序"抬到"给这个任务交付一个能跑的应用"。这也解释了它为什么依赖虚拟化和容器（我们上一篇讲虚拟 PLC 时的那条线，在这里接上了）。
技能 C 是这套愿景的"降落伞"。 它明确说：AI 原生可以包含 AI 辅助模式——需要的时候，退回生成一份普通的 IEC 61131-3 程序给你。愿意降级，才可能被现实接受。
四、演示：三颗 RGB LED 组成的"产线"（这一节请冷静读）
论文的实验部分很短，但信息量在于它诚实。
场景是一个分选任务，两种情形：
- Case #1：传送带上只有一种产品，到位后机械臂搬到固定库位；
- Case #2：多种产品，相机 + 视觉模型识别类型，机械臂搬到对应库位。
但硬件是这样的（原文）：
用三颗 RGB LED 分别模拟传送带电机、红外反射传感器、机械臂。
- 两个 Agent（ICS Agent + Vision Agent）跑在 OpenClaw 上，主机是一台 Intel i5-7300H / 8GB DDR4 的迷你 PC；
- ICS Agent 用 DeepSeek V4，Vision Agent 用本地轻量视觉模型；
- 所有 LED 和相机接在树莓派 4B 上，和迷你 PC 同一个 VLAN；
- 生成的控制应用部署并运行在树莓派 4B 上。
输入就是一段文本提示（论文给了原文），比如 Case #1 里会写明：三个 LED 分别代表什么状态、每个 LED 的 RGB 引脚是 17/22/27、部署到 IP 为 XXX 的树莓派……
论文的表 I 用五个生命周期阶段做对比，结论全部是"Successfully completed"，并且强调提交任务提示后全程无人工干预。
我们的读法（这部分是我们的判断）：
| 它证明了 | 它没证明 |
|---|---|
| 从"文字需求"到"生成 → 部署 → 运行"的链路能贯通 | 任何实时性指标（扫描周期、抖动、最坏响应时间） |
| 需求变更后能重新生成并重新部署 | 任何安全等级、失效模式、故障注入结果 |
| 多个 Agent（控制 + 视觉）能在同一流程里协作 | 真实 I/O、真实执行机构、真实产线的噪声与异常 |
| 一个小而完整的闭环是可行的 | "无人工干预"在真厂里成立 |
一句话：三颗 LED 证明的是接口通了，不是控制行了。 这不是贬低——把链路打通本身是必要工作；但它离"能上产线"还有安全、实时、责任三道门。
五、论文自己列的五道坎（这部分比愿景更值钱）
它把挑战分两侧讲，我按"你会先撞到哪道"重排：
1）AI 侧：幻觉 + Agent 运行时本身就是攻击面
论文指出：LLM、VLA 模型等仍受幻觉和上下文推理能力有限的困扰，长程或复杂任务里决策不可靠；而 Agent 运行时（如 OpenClaw）带来安全、隐私、保密问题，在 ICS 里这些问题会直接传导成控制失效甚至物理事故。
它的解法方向是三条：约束 AI 生成的行动、引入形式化/半形式化验证、保证行为有界。
这三条和我们在站内反复讲的"预演—验证—回滚"是同一套东西，只是论文把"有界（bounded）"明确提出来了——AI 的动作空间必须有物理边界，而不是靠提示词祈祷。
2）ICS 侧：正确性与实时性
控制应用和普通 IT 软件的要求不同：确定性、时延、执行时间、功能正确性，每一条都硬。
论文给的可行方向：把生成的控制逻辑映射到时间自动机（timed automata）、混合自动机或依赖模型上，去验证时序约束和可达性（reachability）。
对做工程的人，这条的现实含义是：AI 生成的控制逻辑要能被形式化地"翻译"出来，才谈得上验证。 如果你的逻辑连结构都不规整（一堆置位/复位混在一起），自动翻译就无从下手——这反而给"编程规范"找到了新理由。
3）ICS 侧：异构部署与在线迁移
传统控制逻辑是静态绑定在某台控制器上的。AI 原生希望它能被拆分、分布、按负载动态迁移。虚拟化提供了"逻辑与硬件解耦"的基础，但论文也不客气：控制应用往往和 CPU 架构、内存层次、专用加速器强耦合，加上严格的实时约束，在线迁移和动态资源重分配非常难。
4）基础设施侧：AI 原生基础设施还没有标准
论文自己说得很清楚：AI 原生基础设施"仍处早期，缺乏统一架构与标准"，图 2 只能当概念参考。开放问题包括：Agent 的标准构造、标准化的通信机制、训练/推理工具链、跨异构基础设施的资源调度。
5）我们补一条：责任
论文没提，但现场一定会问：AI 生成的控制应用出了事故，谁签字？ 在你现在的流程里，答案是"下载程序的工程师"。AI 原生把"生成"交给 AI 之后，这条责任链必须重新画——这不是技术问题，是合同和规程问题。
六、我们的整理：三张对照表
表 1｜两代的分界（这张最该打印出来贴墙）
| 维度 | AI 辅助（今天） | AI 原生（论文愿景） |
|---|---|---|
| AI 的位置 | 工程工具链旁边（copilot），或嵌在控制逻辑里的专用模块（视觉检测） | 架构内核：Agent 是主要执行实体 |
| 系统交付物 | 能力基座 + 你自己写的控制程序 | 任务解决方案：直接交付能跑的控制应用 |
| 变更方式 | 任务变 → 重新编程 → 重新调试（被动触发） | 需求变 → 重新生成 → 重新部署（主动） |
| 决定性的假设 | 确定性不可让渡，AI 只能在外围 | 非确定性是可管理的特性，但产物必须确定、可验证 |
| 典型失败 | 生成物对不上你的厂、编译过但跑不对 | 验证不充分、责任不清、平台不可靠 |
表 2｜七项技能，按"先做哪个"排
| 顺序 | 技能 | 理由 |
|---|---|---|
| 1 | E 虚拟调试 | 最容易先变现：便宜、可重复、不碰真机 |
| 2 | C 兼容遗留 | 有降落伞才有人敢上：能退回生成普通 61131-3 程序 |
| 3 | A 需求分析 | 值钱但依赖"统一内部表示"，先做半自动（人审） |
| 4 | F 监控维护 | 数据侧成熟，注意权限与误报成本 |
| 5 | B 按需生成部署 | 要虚拟化 + 实时性 + 认证三件事同时到位 |
| 6 | D Agent 互操作 | 等标准；现在能做的是"人和 Agent 的接口" |
| 7 | G 进化 | 最难验收，先当研究课题 |
表 3｜"架构师"模式 vs "AI 直接控"
| AI 直接控制回路 | AI 当控制架构师（论文立场） | |
|---|---|---|
| AI 的输出 | 每个周期的控制量 | 一份确定性、可验证的控制应用 |
| 出错的后果 | 立刻作用在设备上 | 会在编译/仿真/评审时被拦住 |
| 能不能验收 | 几乎无法验收（概率性输出） | 可以：编译、仿真、形式化验证、HIL |
| 实时性 | 受模型推理延迟限制 | 不受限：执行仍在实时环境里 |
第三列是这套方案唯一能说服现场的地方：它把 AI 挪到了"能被人拦住"的位置上。
七、给工程师的读法与动作
该抄的三条：
- 把 AI 的动作空间画成台阶（咨询 → 生成 → 编译 → 部署），每一级都要求人显式触发。这和上一篇论文的四级台阶、和我们工具里的"预演—编译—仿真—人确认"是同一个东西——说明这是行业收敛出来的共识，不是某家偏好。
- 执行层必须保持确定性。 不管上面叠多少 Agent，最后动执行机构的仍是扫描周期里的普通逻辑。这条守住，AI 就只是"写程序的"。
- 给遗留留降落伞。 任何 AI 原生方案，如果不能随时退回"生成一份标准 IEC 61131-3 程序"，就没法进厂。
不该信的一条：
- "无人工干预"是在三颗 LED 的台上成立的。 真厂的噪声、异常、换型、保养、报警风暴，一个都没进这个实验。看到"全程无人干预"先问：故障注入做了吗？最坏情况测了吗？
落地顺序建议（我们的话）： 先把厂上下文（I/O 表、标签、模块配置、现有程序 + 一页纸的现场说明）做出来 → 再把虚拟调试跑成常规动作 → 最后才谈"按需生成部署"。跳过前两步直接上第三步，等于让 AI 在没有地图的车间里开车。
和工具怎么接： 论文的 B 技能（按需生成 + 部署）在三菱那边是 GX Works3 + MCP，在博途这边对应 TIA Openness + MCP。要让 AI 在"能被人拦住"的位置上干活——读工程上下文、生成块、编译、仿真验证，每一步都由人决定是否保存——走 TiaLink（博途 MCP 网关）这条路；要把厂上下文与工程读取这一层先搭起来，从 TIA Forge 总入口进。
边界
- 这是一篇愿景 + 挑战清单的论文，不是评测报告。 它的"结果"只有表 I 的五个阶段"Successfully completed"，没有任何量化指标（无时延、无成功率、无工时对比、无故障注入）。演示硬件是三颗 RGB LED 模拟传送带/传感器/机械臂，控制应用跑在树莓派 4B 上，Agent 跑在一台 i5-7300H/8GB 的迷你 PC 上。
- 我们未复现：没有 OpenClaw 环境、没有树莓派 + LED 台架、没有 DeepSeek V4 的对应配置。文中所有系统描述、技能清单、数字与提示词原文均译自论文。
- 版权：论文为 arXiv 非独占许可（nonexclusive-distrib 1.0），我们不转载其图 1/2/3/5（PLC 架构、AI 原生架构、技能示意、有限状态机）；正文配图改用 Wikimedia 的控制室实拍（CC0）。
- 作者背景：鹏城实验室新型网络部，受 PCL 重大项目 [PCL2025A13] 支持——这解释了它为什么强调网络与资源调度那一层（D 技能与异构部署），这可能是它的视角偏好。
- "表 2/表 3""七项技能能做到哪一步""落地顺序建议""五道坎的第 5 条（责任）"均为我们的整理与补充，不是论文内容。
- 论文为预印本（arXiv 2610.34773v1），正式发表版本可能变化。
来源
- 主源文：Lisi Liu、Bin Wang、Quan Tang、Chuan Pang、Feng Gao、Shengkai Liu《From AI-assisted to AI-native Industrial Control: Architecture, Agent Design, and Challenges》，arXiv 2610.34773，2026-10。https://arxiv.org/abs/2610.34773
- 论文引用的相关方向：Agents4PLC（IEEE TSE 2026）、ReACT（IECON 2025）、IEC 61499 形式化验证（IEEE OJ-IES 2023）、cloud-fog automation（IEEE JSAC 2025 / IEM 2024）
- 配图：Wikimedia Commons，Nylki，CC0
同主题阅读
- AI 写 PLC 代码总差一步：一句"有蓝色盘吗"说清了缺的是什么
- 虚拟 PLC 五年：S7-1500V 都发布三年了，TSN 的"确定性"还在纸上
- 代码锁在二进制里：AI 改 PLC 工程的四个台阶
- AI PLC 编程：99% 成功率在这个行业算灾难
本文由汇智网编译整理，转载请注明出处。文中的"我们的整理"与"边界"为编译者补充，不是论文内容。
这是「AI × 工业 / PLC」专题的一部分。完整地图见：AI × 工业 / PLC 完全指南
