> ## 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 该向 PLC 学什么？ - URL: https://www.hubwiz.com/blog/valid-command-not-safe-command-intelligence-interface/ - Published: 2026-11-11T07:31:20.000Z - Updated: 2026-11-11T08:18:05.000Z - Description: 控制系统没有报错，也没有崩溃。它精确地执行了一条被改过的指令——这正是问题所在。 - Author: admin - Tags: 工业 AI, PLC, AI Agent, 安全, 人在回路 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 | 评估数据、生成提案、请求一个动作、检查结果 | | 机器 | 采集传感器值、执行控制算法、报告系统状态 | 这里有个区分很重要：这是一套**交互模型**，不是在主张人、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 智能体上，每一步都有具体的落点： | 回路步骤 | PLC 里的对应物 | 智能体里的对应物 | 能拿到的证据 | | ---- | ---------- | ------------ | ------------ | | 感知 | 输入映像区的一个字 | 工具调用返回的结构化结果 | 调用日志、返回体 | | 解释 | 比较指令、模拟量标定 | 模型的推断与归纳 | 引用了哪一块、哪一行 | | 决定 | 输出映像区的一个位 | 一份计划、一次写操作请求 | 计划文本、待执行的参数 | | 执行 | 输出模块驱动继电器 | 改工程、写变量、下装 | 变更前后的差异 | | 验证 | 反馈触点、诊断缓冲 | 编译结果、仿真、读回核对 | 编译 0 错、读回值一致 | 这张表里最容易被跳过的是最后一行。前四行在聊天框里就能完成，第五行必须回到真实的系统里去做。 **二、三条今天就能用的判据** 1. **一条断言必须自带有效域。** 只给数值不给范围、不给不确定度的结论，接收方应该按"未知"处理，而不是按"估计"处理。 2. **能力不等于权限。** 一个能读完整套工程的智能体，不等于它被允许改任何一个块。分析权限与执行权限要分开授予，这是原文第 4 步和第 7 步的分界线。 3. **执行器不能是提示词。** "请不要执行危险操作"写在系统提示里，那是建议；写在一个它绕不过去的检查里，那才是执行器。原文第 9 节讲的独立性——不能有第二条旁路——在单机上等价于：**校验必须在它执行的那条路径上，而不在它读的那段文字里。** **三、我们在这张图上的位置** 把原文那套搬进博途工程，能落地的部分很具体：改之前先预演一遍，再看编译错误列表，再下装到 S7-PLCSIM Advanced 跑通，最后读回变量与状态核对——**四道检查全部通过才算落地**。这套顺序对应的是原文第六步"独立批准"与第七步"验证"里，属于软件的那一半。 不属于软件的那一半，必须留给硬件：急停、硬互锁、时间参数整定，归安全回路和真机负责。任何把仿真通过当成"安全已验证"的说法，都是越界。 想从这条链路的入口开始，可以看 [TiaLink（博途 MCP 网关）](https://tia.hubwiz.com/tia-link?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=intelligence-interface&utm%5Fcontent=cta)：它给智能体的写入权限是可分层的，写入前有预演、写入后有编译与读回。 **四、一句冷静的话** 这是一份架构提案，不是标准。作者自己列了前提条件，也说要不要成为标准得看独立测试。工业界这类思路已经存在多年（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：（本文为全文编译，保留原文结构与作者的保留意见） - 法国超市事件的细节（受影响门店数、温度、除霜周期、ANSSI 立案）来自 [AI 复现 PLC 漏洞](https://www.hubwiz.com/blog/ai-reproduce-plc-vulnerability-danfoss/) 一文整理的公开报道，原文此处只作一句概述 - 封面：Wikimedia Commons，Shixart1985，《Emergency stop button on a control panel in a factory》，CC BY 2.0 **相关阅读**：[MCP 已经接进 PLC：但写设定值这一步，必须由人按下](https://www.hubwiz.com/blog/mcp-reached-plc-human-approves-setpoint/)——这篇讲的是同一件事的工程实现：读走只读白名单、写只进提案表、写回由人执行。｜[AI 降低了 PLC 攻击门槛：AA26-231A 之后的防御清单](https://www.hubwiz.com/blog/ai-generated-plc-attacks-aa26-231a-ot-defense/) > **这是「AI × 工业 / PLC」专题的一部分。**完整地图见：[AI × 工业 / PLC 完全指南](https://www.hubwiz.com/blog/ai-industrial-stack/)