> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI 原生工业控制：不让 AI 碰实时回路，只让它当"架构师"
- URL: https://www.hubwiz.com/blog/ai-native-industrial-control-architect/
- Published: 2026-11-04T16:37:58.000Z
- Updated: 2026-11-04T16:39:09.000Z
- Description: 它把 AI 的位置说清楚了：不是替 PLC 按按钮，而是决定"谁按哪个按钮"。演示台是三颗 RGB LED，所以这是设计稿，不是业绩单。
- Author: admin
- Tags: 工业 AI, 工业控制, Agent, IEC 61499, 形式化验证

同一件事（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 非独占许可）**。这不是一篇有实验数据的论文，是一篇**架构与挑战清单**的论文——所以我们既讲它说了什么，也讲它**没证明什么**。

![同步辐射装置控制室](https://www.hubwiz.com/blog/content/images/2026/11/bessy-cover.jpg)

*控制室里的屏幕仍是"人看界面、人下判断"。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 挪到了"能被人拦住"的位置上。

## 七、给工程师的读法与动作

**该抄的三条：**

1. **把 AI 的动作空间画成台阶**（咨询 → 生成 → 编译 → 部署），每一级都要求人显式触发。这和上一篇论文的四级台阶、和我们工具里的"预演—编译—仿真—人确认"是同一个东西——**说明这是行业收敛出来的共识，不是某家偏好。**
2. **执行层必须保持确定性。** 不管上面叠多少 Agent，最后动执行机构的仍是扫描周期里的普通逻辑。这条守住，AI 就只是"写程序的"。
3. **给遗留留降落伞。** 任何 AI 原生方案，如果不能随时退回"生成一份标准 IEC 61131-3 程序"，就没法进厂。

**不该信的一条：**

- **"无人工干预"是在三颗 LED 的台上成立的。** 真厂的噪声、异常、换型、保养、报警风暴，一个都没进这个实验。看到"全程无人干预"先问：故障注入做了吗？最坏情况测了吗？

**落地顺序建议（我们的话）：** 先把**厂上下文**（I/O 表、标签、模块配置、现有程序 + 一页纸的现场说明）做出来 → 再把**虚拟调试**跑成常规动作 → 最后才谈"按需生成部署"。跳过前两步直接上第三步，等于让 AI 在没有地图的车间里开车。

**和工具怎么接：** 论文的 B 技能（按需生成 + 部署）在三菱那边是 GX Works3 + MCP，在博途这边对应 **TIA Openness + MCP**。要让 AI 在"能被人拦住"的位置上干活——读工程上下文、生成块、编译、仿真验证，每一步都由人决定是否保存——走 [TiaLink（博途 MCP 网关）](https://tia.hubwiz.com/tia-link?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=ai-native-industrial-control-architect&utm%5Fcontent=architect)这条路；要把厂上下文与工程读取这一层先搭起来，从 [TIA Forge 总入口](https://tia.hubwiz.com/tia-forge?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=ai-native-industrial-control-architect&utm%5Fcontent=cta)进。

## 边界

- **这是一篇愿景 + 挑战清单的论文，不是评测报告。** 它的"结果"只有表 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](https://arxiv.org/abs/2610.34773?ref=hubwiz.com)
- 论文引用的相关方向：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 代码总差一步：一句"有蓝色盘吗"说清了缺的是什么](https://www.hubwiz.com/blog/plant-aware-plc-copilot-four-levels/)
- [虚拟 PLC 五年：S7-1500V 都发布三年了，TSN 的"确定性"还在纸上](https://www.hubwiz.com/blog/virtual-plc-2026-2030-standards-tsn-codesys-siemens/)
- [代码锁在二进制里：AI 改 PLC 工程的四个台阶](https://www.hubwiz.com/blog/ai-operate-codesys-project-four-steps/)
- [AI PLC 编程：99% 成功率在这个行业算灾难](https://www.hubwiz.com/blog/ai-plc-programming-tia-portal-what-works/)

本文由汇智网编译整理，转载请注明出处。文中的"我们的整理"与"边界"为编译者补充，不是论文内容。

> **这是「AI × 工业 / PLC」专题的一部分。**完整地图见：[AI × 工业 / PLC 完全指南](https://www.hubwiz.com/blog/ai-industrial-stack/)