把 AI 智能体接入 PLC 程序：从“能跑”到“敢用”的实战教程

把 AI 智能体接入生产 PLC 程序，不建议一上来就让 AI 直接写控制逻辑。更稳的做法是：AI 智能体作为"工业数据副驾驶"，先读 PLC、做诊断和参数建议，再经 HMI/SCADA 或上位机确认后，才把结果写回 PLC。 这样既保留 PLC 原有的硬实时和安全联锁，又能让 AI 真正参与生产流程。

下面按"可落地、可复现"的顺序整理。

1. 先定边界：AI 不能替代 PLC 的安全逻辑

PLC 负责的是确定性控制：毫秒/微秒级扫描、I/O 同步、故障安全、联锁保护。AI 智能体更适合做：

设备状态诊断
工艺参数优化建议
异常预警
生产调度辅助
报警归因
程序生成与校验辅助

如果涉及停机、急停、安全联锁、高压设备、批量参数修改，必须保留人工确认或双人复核。

推荐采用这条链路：

PLC 上报数据 → 智能体分析 → HMI/SCADA 确认 → 上位机写回 PLC → PLC 执行

AI 可以输出"建议值"，但最终执行权留在 PLC 和操作人员手里。

2. 推荐架构：四层就够了

层级	作用	关键技术
现场层	保留原有 PLC 程序和安全逻辑	PLC、HMI、传感器、执行器
采集层	把 PLC 数据读出来并标准化	OPC UA、Modbus TCP、S7
智能体层	做推理、决策、工具调用	Python、MCP、本地/云端 LLM
执行层	把建议写回 PLC 或触发工单	SCADA、MES、HMI、上位机

如果现场设备比较老，可以先加一个边缘网关或工控机，把 Modbus、S7 等协议转成 OPC UA，再交给 AI 智能体使用。

3. 协议怎么选？

协议	适用场景	注意点
OPC UA	新项目、跨品牌、语义化数据	推荐作为长期方案
Modbus TCP	老设备、点位少、快速接入	缺少语义，需维护点位表
S7 协议	西门子小型验证	不建议直接暴露到公网
MQTT	上云、非实时监控	不适合硬实时控制

新项目优先选 OPC UA。它不仅能传数值，还能携带单位、描述、时间戳和数据模型，对 AI 更友好。

4. 最小可行方案：Python 智能体读取 OPC UA

假设 PLC 已经配置好 OPC UA Server，地址为 opc.tcp://192.168.0.10:4840，我们要读取主轴温度和负载。

复制代码

from opcua import Client

class PLCReader:
    def __init__(self, endpoint: str):
        self.client = Client(endpoint)
        self.client.connect()

    def read_node(self, node_id: str):
        node = self.client.get_node(node_id)
        return node.get_value()

    def close(self):
        self.client.disconnect()

reader = PLCReader("opc.tcp://192.168.0.10:4840")

temperature = reader.read_node("ns=2;s=Spindle.Temperature")
load = reader.read_node("ns=2;s=Spindle.Load")

print("温度:", temperature, "负载:", load)
reader.close()

这里要注意：节点 ID 必须和 PLC 工程里的 OPC UA 节点一致。如果是 Modbus 设备，可以先通过网关转成 OPC UA，避免在 AI 层直接处理大量寄存器地址。

5. 让 AI 智能体具备"工具能力"

智能体不能只聊天，它需要能调用真实工具。可以封装三类工具：

复制代码

tools = {
    "read_plc": read_plc_tag,        # 读 PLC 点位
    "write_plc": write_plc_tag_safe, # 写 PLC 点位，带审批
    "query_manual": query_rag,       # 查设备手册/历史工单
}

智能体的工作流可以是：

读取当前 PLC 数据；
查询设备手册或历史案例；
判断是否异常；
生成建议；
如果涉及写 PLC，先走审批；
记录完整日志。

如果使用 MCP ，可以把 read_plc、write_plc、query_manual 注册成标准工具，让大模型按工具协议调用。这样比把 PLC 地址写死在 Prompt 里更安全，也更容易审计。

6. 写回 PLC 必须加安全闸

不要直接让 AI 调用 write_plc。建议加一层审批和校验：

复制代码

def write_plc_tag_safe(tag, value, operator, reason):
    if not is_tag_writable(tag):
        raise PermissionError(f"点位 {tag} 不允许写入")

    if not approve_write(tag, value, operator, reason):
        raise PermissionError("未通过人工审批")

    return plc_client.write(tag, value)

更严格的场景可以分级：

建议级：只推送到 HMI，不写 PLC；
参数级：操作员确认后写入非安全点位；
控制级：停机、联锁、批量修改必须双人复核；
安全级：禁止 AI 直接写入，必须由 SIS/安全 PLC 处理。

7. 用西门子 TIA Portal 导入 AI 生成的 SCL

如果 AI 智能体辅助生成了 PLC 程序，推荐先输出 SCL 源文件，再导入 TIA Portal。

操作步骤：

在 TIA Portal 中打开目标项目；
选择目标 PLC；
进入 程序块 → 外部源文件；
添加 AI 生成的 .scl 文件；
右键选择 从源生成块；
检查编译日志是否为 0 错误、0 警告；
在线监控、仿真验证后再下载到 PLC。

AI 生成的程序不要直接上线，必须经过仿真、离线测试、现场小范围验证。

8. 上线节奏：影子模式最稳

不要一上线就闭环控制。建议按这个顺序推进：

只读不写：AI 只采集数据、做诊断；
影子模式：AI 输出建议，但不执行，只记录日志；
人工确认：操作员在 HMI 上点击"采纳/拒绝"；
小范围闭环：只对非安全参数开放自动写入；
逐步扩大：积累足够正向案例后再扩展范围。

每一步都要保留日志：AI 输入了什么数据、用了什么规则、调用了哪些工具、谁确认、最终写入了哪些点位。

9. 常见坑

点位表没维护：AI 拿到的是裸数字，不知道单位，容易误判。
时间戳不对齐：不同设备时间不同步，因果分析会失真。
采样频率太低：秒级数据很难做振动、冲击类诊断。
直接写 PLC：没有审批和回滚机制，风险极高。
把大模型当实时控制器：LLM 延迟不稳定，不适合毫秒级控制。
老设备硬上 OPC UA：可以先用协议网关转换，不必改造 PLC 程序。

10. 一个可照抄的落地清单

先盘点 PLC 品牌、型号、可用协议；
优先启用 OPC UA，或用网关转 OPC UA；
建立点位表，包含名称、单位、量程、读写权限；
用 Python/Node-RED/C# 搭建采集服务；
把读 PLC、写 PLC、查手册封装成工具；
让智能体先做诊断和建议；
写操作必须经过 HMI/SCADA 或工单审批；
全程记录决策日志；
先在仿真或单台设备上试点；
稳定后再扩展到整条产线。