AI 该向 PLC 学什么？

2026 年 10 月 11 到 12 日夜间，法国多家连锁超市的制冷系统被远程操纵：攻击者改掉了温度设定与除霜周期，冷柜温度被拉到 50°C，除霜周期从 1 小时拉长到 8 小时以推迟报警。约 300 家 Intermarché 和 Netto、100 家 Coopérative U、80 家 Carrefour 受影响，ANSSI 已立案调查。

这套系统没有报错，没有崩溃，没有一个环节"理解错了"。它精确地执行了那些被改过的指令。

德国工程师 Hans-Peter Selk 在 11 月 9 日的长文里，就用这件事做整篇论证的支点：一条技术上可执行的指令，并不自动等于一条有意义的、被允许的、安全的指令。 他给这种缺口的补法不叫"更强的模型"，叫智能接口（Intelligence Interface）——把 PLC 用了四十年那套动作回路，当成人类、AI 系统与机器之间的公共契约。

一、最简单的部件，往往是最可靠的

PLC 从来不属于最耀眼的技术。但它是"可靠"这件事的一个好样本：它捕捉状态，处理信息，做出决定，触发一个明确的动作，然后检查预期的效果有没有真的发生。

这听起来简单。而这正是它强的地方。

今天的 AI 系统走的是相反的方向：能力增长得很快，但"如何把这些能力以可控、可靠的方式接进真实流程"这个问题，仍然没有答案。

所以 AI 也许该向 PLC 学点什么。不是把 AI 变成一台 PLC，而是为"人、AI 与机器"之间设计一套共用的协作架构。

二、一条合法指令，也可以是错的

法国超市的例子把这条区分摆到了台面上。

问题不是控制系统没能理解一条指令，而是它做了自己被编程去做的事。但一条能执行的指令，不自动是一条有意义、被允许、安全的指令。

所以控制系统要检查的，远不止一条指令的语法是否成立。它至少要回答四件事：

• 当前状态是什么？ 这条指令在此刻的机器状态下成立吗。
• 谁被授权发它？ 写这条指令的这个主体，有没有这个权限。
• 预期的效果是什么？ 执行完之后，应该观察到什么。
• 还在允许的范围内吗？ 有没有越过运行时允许行为的边界。

智能接口就落在这四个问题上，而不是落在模型的参数量上。

三、把控制回路当成公共积木

整套架构的基本单元，是一个反复出现的五步序列：

• 感知：现在有哪些信息可用。
• 解释：它意味着什么，这个判断有多可靠。
• 决定：哪个动作是合适的、且被允许的。
• 执行：被授权的那个动作被执行。
• 验证：预期的效果发生了没有。

这个序列可以套到完全不同的参与者身上。

这里有个区分很重要：这是一套交互模型，不是在主张人、AI 和机器内部的工作方式相同。

人思考和语言模型不是一回事，神经网络跑起来和 PLC 扫一个周期也不是一回事。智能接口不规定任何一方的内部机制。它只把"接口上的协作"标准化。

四、四类回路，和一个反直觉的结论

并不是所有过程都需要同一种处理方式，所以这套架构区分了四种功能回路：

• 反射回路：对明确定义的事件立即反应，比如急停。
• 控制回路：把一个状态持续调到目标值，比如温度调节。
• 审议回路：权衡备选方案、预测与可能的后果，通常由 AI 承担。
• 社会／询问回路：不同参与者之间的协调——追问、批准、澄清误解。

这四类回路可以跑在不同的速度上。但它们不是同一个过程的四个时间阶段，它们干的是不同的活，而且会互相作用。

比如：AI 在准备一个更长远的决定，同时一条独立的控制回路在保证眼前的安全。

这里有个关键点："能提出一个好决定"不应该自动包含"不经进一步检查就执行它"的权力。

五、给"断言"一套共同语言

人和 AI 沟通时反复出现一个问题：双方都在用看起来很精确的数字和说法，而它们并不那么精确。

温度 6.2°C 只有在同时说清"怎么测的、不确定度多大、这个读数在哪个范围内有效"之后，才算一条可靠的信息。

所以一条断言不该只有一个值。它至少要带上：

• 单位与含义
• 容差或不确定度
• 有效域（validity domain）
• 测量的方向或参照
• 来源与时间戳
• 这条断言的状态

"状态"这一项要区分几个层级：未知 / 估计 / 基于模型 / 有统计支撑 / 已保证——而且"已保证"得是真的被证明过才算。

接受方可以比发送方更保守地评估一条断言。但它不允许在没有新证据的情况下，把这条断言升级到更高的确定性等级。

这条规则要防的是一件事：一个假设在传递过程中，悄悄变成一个人人当作事实的结论。

六、近似卡：让复杂的结论可以被追溯

另一个想法是标准化的近似卡。

它记录：这个结果是怎么算出来的、用了哪些量、在什么范围内成立、还有哪些误差项要算进去。

原文举的例子是烧水。把 200 公斤水从 10°C 加热到 60°C，近似公式是

Q = m × c × ΔT（200 kg × 4.18 kJ/(kg·K) × 50 K ≈ 41,800 kJ ≈ 11.6 kWh）

这本身是一个能看懂的物理近似。而一张近似卡会额外记录：用了哪些测量与假设、由此产生多大不确定度、哪些损失还没被算进去。

它最值钱的地方是：一个复杂的 AI 结论不必被盲信，它可以被追回成一个更简单、可验证的表示。

当能力不同的参与者一起工作时，这一点尤其重要。

七、能力可以分级，理解必须统一

不是每一个参与者都需要有能力理解全部东西。

一个简单的接受方，可以只处理"温度安全地低于 8°C"这样一条断言。能力更强的系统，可以在同一个问题上额外给出模型计算、预测或统计评估。

所以智能接口里要有能力档案：每个参与者必须说明自己能做什么、做不到什么。能力更强的系统，可以把信息压缩成更简单的接受方能理解、也能验证的形式——但不能靠隐瞒不确定度或有效范围来做到这一点。

原文用一个断电后的冷库来演示这三档：

• 一个简单系统能判断：测到的温度是否还在安全线内。
• 更进一步的系统能算出：按这个趋势，还会在安全线内待多久。
• 一个更强的 AI 系统能比较不同处置方案，并建议其中一个。

这三档能力并不等于三档权限。能力和权限必须分开。

八、完整序列：从意图到"已验证的动作"

这套东西在实战里长什么样？设想一个断电后的冷库，AI 要判断现在能不能启动一次除霜：

1. 意图：AI 提出启动一次 17 分钟的除霜。
2. 断言质量：它同时给出当前温度、测量不确定度、测量时间戳、所用假设，以及它的计算与计算的有效范围。
3. 能力检查：接收方的控制系统判断自己能不能充分评估这些量和这个计算模型。看不懂的信息不能当成既成事实。
4. 权限检查：控制系统判断这个 AI 到底有没有资格请求一次除霜。"能分析"不自动等于"能执行"。
5. 反馈：控制系统确认自己是怎么理解这个提案的，并说明在什么条件下它才是允许的。
6. 独立批准：一个独立的安全机制检查当前系统状态与允许的运行边界。只有全部条件满足，才放行。
7. 执行与回传：动作执行，实际测量值回传，与预期结果对比。

任何一个条件不成立，动作被拒绝，或者系统转入安全状态。

这样就形成一个闭环：AI 可以提出一个动作，但它不能仅仅因为把命令写得很像回事，就拿到了系统的控制权。

九、执行器：安全不能只是一条建议

整套架构的核心安全原则，是一个独立的执行器（enforcer）——在执行之前检查一个被请求的动作是否被允许的机制。

它至少检查三件事：

• 这个参与者有权做这个动作吗？
• 这个动作在当前的系统状态下安全吗？
• 它落在这个参与者的信任与授权框架内吗？

而这份"独立"，不能只存在于组织层面或逻辑层面。

如果 AI 能绕开检查、通过另一条通信路径、操作系统权限、或者第二个执行器通道达到同样的效果，那这个执行器就不够独立。

所以关键执行路径必须被技术上保护起来，使得没有一条不受控的旁路能绕过检查。视具体应用，这可能要求硬件隔离、受保护执行环境，或其他形式的安全执行器接口。

这个想法本身不新：Simplex 架构与其他运行时保证（Run-Time Assurance）方案早就在用独立的安全机制，去监控那些复杂或未被完全信任的功能，并在必要时接管。ASTM F3269-21 也描述了在飞机系统里把复杂功能的行为约束在安全边界内的方法。

智能接口想做的，是把这类安全思路放进一个更大的协作架构里——不只是为某一台控制系统，而是为人、AI 与机器之间的协作。

十、同样的道理适用于软件与 AI 智能体

这套原则不止于工业控制。

一个 AI 智能体完全可以被派去分析一个软件问题、提出一处改动、改代码、跑测试。一条常规的安全 CI/CD 流水线已经能兜住其中很多步骤。智能接口补的是另一件事：它让断言的质量与决策的边界也变成可理解的东西。

比如这个智能体得说清楚：

• 它认定的是什么问题，这个诊断基于哪些信息；
• 它提议改什么，可能带来哪些副作用；
• 究竟跑了哪些测试，结果是哪些；
• 它的这些断言适用于哪个版本、哪个环境；
• 它对"做这处改动"和"批准它发布"分别拥有什么权限。

然后由一个独立的批准机制去核对：这处改动是否满足事先约定的契约，是否可以在目标环境里执行。

差别很大：被评估的不再只是 AI 产出的结果，还有它的依据、不确定度、授权和实际效果。 这些一起进入标准化流程。

十一、这套架构能做什么，不能做什么

智能接口不是在承诺 AI 系统会自动变得不出错。

它没法把错误的信息变成正确的信息，也不能保证一个模型在自己的有效域内一定工作正常。

它的安全保证依赖一批明确的前提：执行器本身必须是正确的、被保护的；所用的证据必须可信；模型必须适配它被用到的场景；执行器侧不能有不受控的执行路径。

而且还有一条很现实的权衡：一个对任何动作都存疑就拒绝的系统，是安全的，也完全没用。

所以这类架构不仅要证明安全，还要证明可用。这需要可复现的测试、定义清楚的有效域，以及可验证的一致性判据。

十二、核心：标准化协作规则，而不是内部智能

PLC 证明了：一条定义清楚的控制回路能可靠到什么程度。AI 打开了新的可能：识别复杂关联、为决策做准备。

下一阶段可能是把这两个世界——再加上人——用一个共用的、可验证的接口连起来。

需要被标准化的不是内部智能。需要被标准化的是协作规则：意义、断言质量、能力、授权、委托、执行与反馈。

这就是智能接口的想法。

它能不能成为一个独立标准，要拿它与已有工作的对照、技术实现和独立测试来衡量。原文作者自己写得很清楚：很多积木已经存在，决定性的问题是这些积木的组合能不能形成一套可行、跨领域的架构。他把这篇文章当成一个想跟开发者、工程师和安全专家讨论的提案。

我们的整理

一、PLC 那五步，对应到智能体身上是什么

原文的五步回路是给"任何参与者"设计的，落到 AI 智能体上，每一步都有具体的落点：

这张表里最容易被跳过的是最后一行。前四行在聊天框里就能完成，第五行必须回到真实的系统里去做。

二、三条今天就能用的判据

1. 一条断言必须自带有效域。 只给数值不给范围、不给不确定度的结论，接收方应该按"未知"处理，而不是按"估计"处理。
2. 能力不等于权限。 一个能读完整套工程的智能体，不等于它被允许改任何一个块。分析权限与执行权限要分开授予，这是原文第 4 步和第 7 步的分界线。
3. 执行器不能是提示词。 "请不要执行危险操作"写在系统提示里，那是建议；写在一个它绕不过去的检查里，那才是执行器。原文第 9 节讲的独立性——不能有第二条旁路——在单机上等价于：校验必须在它执行的那条路径上，而不在它读的那段文字里。

三、我们在这张图上的位置

把原文那套搬进博途工程，能落地的部分很具体：改之前先预演一遍，再看编译错误列表，再下装到 S7-PLCSIM Advanced 跑通，最后读回变量与状态核对——四道检查全部通过才算落地。这套顺序对应的是原文第六步"独立批准"与第七步"验证"里，属于软件的那一半。

不属于软件的那一半，必须留给硬件：急停、硬互锁、时间参数整定，归安全回路和真机负责。任何把仿真通过当成"安全已验证"的说法，都是越界。

想从这条链路的入口开始，可以看 TiaLink（博途 MCP 网关）：它给智能体的写入权限是可分层的，写入前有预演、写入后有编译与读回。

四、一句冷静的话

这是一份架构提案，不是标准。作者自己列了前提条件，也说要不要成为标准得看独立测试。工业界这类思路已经存在多年（Simplex 在 1980 年代就提出，ASTM F3269-21 是 2021 年的航空标准），把它推到"人 + AI + 机器"的通用协作层，是这篇的价值，也是它还没被验证的部分。

判断这类架构有没有用，不必看它画得多完整，看一个问题就够：当 AI 提议的那件事是错的时候，系统里有没有一个地方，在它执行之前把它拦下来。

来源

• Hans-Peter Selk，《What AI Can Learn from PLCs: A Common Interface for Humans, AI and Machines – and Why Every Decision Must Remain Verifiable》，2026-11-09：https://hansikspost.substack.com/p/what-ai-can-learn-from-plcs（本文为全文编译，保留原文结构与作者的保留意见）
• 法国超市事件的细节（受影响门店数、温度、除霜周期、ANSSI 立案）来自 AI 复现 PLC 漏洞 一文整理的公开报道，原文此处只作一句概述
• 封面：Wikimedia Commons，Shixart1985，《Emergency stop button on a control panel in a factory》，CC BY 2.0

相关阅读：MCP 已经接进 PLC：但写设定值这一步，必须由人按下——这篇讲的是同一件事的工程实现：读走只读白名单、写只进提案表、写回由人执行。｜AI 降低了 PLC 攻击门槛：AA26-231A 之后的防御清单

这是「AI × 工业 / PLC」专题的一部分。完整地图见：AI × 工业 / PLC 完全指南