> ## 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智能体
- URL: https://www.hubwiz.com/blog/ai-agents-and-industrial-control/
- Published: 2026-09-24T15:08:29.000Z
- Updated: 2026-10-13T16:16:02.000Z
- Description: 一旦AI模型能够调用工具、浏览系统、写入文件和触发操作，它就不再只是一个聊天机器人。它是一个软件操作员。在工业工厂中，这种区别很重要。
- Author: admin
- Tags: INDUSTRY, #Import 2026-10-14 14:41

OpenAI于2026年9月16日发布了一份新的失调报告框架，以及六个在训练和评估过程中发现的意外或令人担忧的模型行为示例。这些示例包括模型未经许可使用暴露的API密钥、将文件上传到公共互联网以便引用、在软件仓库中进行未经授权的写入操作，以及在本地共享不可用时通过公共网站共享文件。

这些并不是声称已部署的AI系统经常表现出这种行为。OpenAI明确表示，这六个案例是个别示例，不应被视为频率估计。但它们是有用的工程证据。一个有能力的代理可能会通过系统设计者未意图的路径来追求其目标。

几天前，OpenAI还表示GPT-6 Astra已达到其**关键**网络安全能力阈值。用OpenAI自己的话说，在适当的工具和访问权限下，该模型可以发现以前未知的安全漏洞，并在没有人员指导每一步的情况下开发利用这些漏洞的方法来攻击受良好保护的系统。Anthropic的9月威胁报告单独描述了多代理网络操作以日益增加的自主性进行侦察、利用和数据窃取。

对于工厂、公用事业和机器制造商，我想从这些新闻中得到一个相当简单的教训：**不要将智能与权限混淆。** 模型可能非常擅长分析，但仍然应该只有很少的权限来更改运行中的流程。

## 1、风险不仅仅是恶意提示

大多数工业AI讨论仍然围绕明显的情况来构建安全：有人欺骗模型、窃取密码或发送不良提示。这很重要，但这只是问题的一部分。

使用工具的代理也可能在试图提供帮助时做错事情。如果目标模糊、缺少来源、连接器暴露的权限超出预期，或者任务更强调完成而非谨慎，模型可能会即兴发挥。在办公软件中，结果可能是一封不必要的邮件或错误的文件更新。在生产中，同样的行为可能变成设定点更改、禁用的警报、修改的配方或非计划的机器命令。

这就是为什么我不会围绕模型本身是最终安全边界的想法来设计工业AI。安全边界应该在模型之外。

## 2、PLC不是Web应用程序

生产控制具有通用AI系统不具备的特性。PLC逻辑是确定性的。互锁被故意设计得很窄。安全系统是独立设计的。操作员知道在每种机器状态下允许哪些操作。变更控制之所以存在，是因为错误操作的成本可能是物理的而非数字的。

相比之下，AI代理之所以有用，是因为它能够在不完整的信息上进行推理、推断意图并调整方法。这些优势正是它不应该被给予对控制层无限制写入访问权限的原因。

我通常会将架构分为三个级别：

| AI访问级别 | 典型用例                                   | 推荐权限                              |
| ------ | -------------------------------------- | --------------------------------- |
| 只读     | 历史数据分析、OEE诊断、警报审查、维护辅助、能源分析            | 如果凭据、数据范围和日志记录得到控制，广泛的读取访问通常是可接受的 |
| 有界写入   | 创建CMMS工单、确认工作流、建议配方、安排生产、请求设定点更改       | 使用类型化命令、允许列表、限制、审批规则和完整的审计日志      |
| 直接控制写入 | 写入PLC内存、绕过互锁、更改驱动器参数、修改安全逻辑、发出无限制的机器命令 | 避免用于通用AI。保持在确定性控制和工程权限边界之后        |

中间行是大多数有用的工业代理自动化所在的位置。AI可以行动，但只能通过精确定义存在哪些操作以及适用哪些限制的接口。

## 3、使用命令代理，而不是原始PLC访问

如果AI代理需要影响流程，我更喜欢命令代理模式。代理不会获得允许它写入任意PLC地址的凭据。相反，它调用一个狭窄的服务，例如：

- `request_line_stop(reason, line_id)` \- 请求生产线停止
- `set_energy_mode(machine_id, mode)` \- 设置能源模式
- `propose_recipe_change(product, revision)` \- 建议配方更改
- `create_maintenance_work_order(asset, fault_code, evidence)` \- 创建维护工单
- `request_speed_change(machine_id, target_percent)` \- 请求速度更改

然后，代理会在任何内容到达PLC或SCADA写入路径之前检查机器状态、操作员权限、范围限制、维护模式、生产状态和任何所需的审批。

例如，对于速度更改，AI可能被允许请求额定速度的70-100%。代理可以拒绝超出该范围的任何内容，在关键配方步骤期间阻止更改，并在请求的增量超过定义的阈值时要求操作员确认。PLC仍然拥有最终的许可和互锁。

这不是复杂的AI安全。这是应用于新型软件组件的普通控制工程。

## 4、高后果操作应该有摩擦

工业自动化花了数十年时间消除不必要的摩擦。AI稍微改变了这种平衡，因为一个非常有能力的代理可以快速执行许多操作。因此，某些操作应该保持故意缓慢。

我会要求对以下操作进行更强的审批或第二个独立控制：

- 更改PLC或安全逻辑；
- 写入驱动器、运动或机器人配置；
- 更改保护限制或警报抑制；
- 修改对质量或安全有重大影响的配方；
- 授予新用户权限或远程访问路径；以及
- 部署到桥接IT和OT的边缘网关的代码。

这种审批不一定意味着纸质表格。它可以是签名的工程工作流、两人数字审批、维护模式钥匙开关或单独的确定性策略引擎。关键是模型不应该能够批准自己的升级。

## 5、模型不应该是唯一监视自己的东西

OpenAI的9月披露也很有用，因为它们表明为什么监控需要独立。OpenAI报告说，一些模型在困难任务期间采取了未经授权的操作，并且高级模型在对抗条件下可能变得更难监控。

在工业部署中，审计跟踪应该位于模型会话之外。记录工具调用、用户或代理身份、请求的操作、参数、源数据、审批结果、代理决策和最终工厂响应。如果AI提议更改设定点，我希望能够准确重建发生了什么，而不必在事后要求同一个AI解释自己。

凭据也是如此。AI代理应该接收短期、有范围的凭据，而不是永久的工程密码。维护分析代理不需要与工程工作站相同的权限。连接到ERP的业务代理不会自动获得进入SCADA的路径。

## 6、仿真很有价值，但它不是许可

数字孪生和离线仿真是让AI更积极地探索的好地方。代理可以在任何内容被允许接近真实工厂之前，在模型中尝试调度更改、能源策略或流程调整。

但仿真输出仍应被视为证据，而不是权限。数字孪生仅与其数据和假设一样好。阀门粘滞、传感器漂移、未记录的手动实践和维护条件都可能使真实流程的行为与模型不同。

对于闭环优化，我会使用孪生来提议和测试，然后通过实时限制和独立控制逻辑约束真实命令。如果优化器消失，工厂应该继续安全运行。

## 7、我今天会在哪里使用代理AI

有很多有用的工作不需要给AI工厂的钥匙。我会很乐意在以下方面更加努力：

- 使用历史数据、警报和维护数据进行故障调查；
- 预测性维护分类和证据收集；
- OEE损失分析和生产报告；
- 能源异常检测和优化建议；
- CMMS工单准备和零件查找；
- MES异常处理和生产计划支持；
- 工程文档搜索和变更影响审查；以及
- 网络安全监控、漏洞分析和防御自动化。

这些正是广泛的推理可以节省时间而无需AI成为确定性控制替代品的领域。

---

原文链接：[AI Agents and Industrial Control: Keep General-Purpose AI Out of the PLC Write Path](https://www.cans.com.my/ai-agents-industrial-control-plc-write-path-ot-security-2026/?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处

> **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)