LLM Agent与PLC持续物理控制：PLCBench的启示与实践

PLCBench 这类工作要回答的问题非常直接：当一个大语言模型（LLM）驱动的自主 Agent 拿到了 PLC 的访问权，它能不能把一次正确的操作，变成一段持续稳定的物理控制流程。这个问题并不是把“今天这版模型更会生成代码”平移成“这版模型更会控制设备”，而是从符号世界跨入物理世界的一次能力检验。标题里刻意用了 sustained 这个词，说明它评估的不是单步动作正确率，而是长时间、多步骤、带反馈、有扰动的闭环控制能力。

这篇内容会围绕 PLCBench 的标题拆开讲：PLC、LLM Agent、持续物理控制这三个词各自意味着什么，为什么把它们放在一起之后问题会变难，以及如果要在自己环境里搭一个最小验证系统，应该从哪些地方入手。对象读者可以是两类人：一类是熟悉 PLC 和工业自动化、想了解 LLM Agent 能做什么的工程师；另一类是熟悉大模型应用、想往工业控制方向尝试的算法工程师。两边的知识盲区不同，所以后面的内容会尽量把概念解释到位，同时保留足够的技术细节。

1. 先理解标题在问什么：从文本工具到物理控制的跨越

1.1 LLM Agent 擅长的是符号世界，不是物理世界

LLM Agent 已经在很多软件场景里证明了价值：读取文档、操作数据库、调用外部 API、写自动化脚本。这些场景有一个共同特征，就是它们都工作在符号世界里。用户的指令、数据库的记录、API 的返回结果，最终都可以转换成文本或结构化数据，Agent 的上下文窗口可以容纳，错误可以回滚，最坏情况下损失的是时间和数据，而不是物理设备。

物理世界是完全不同的约束。控制一台 PLC 意味着可能在真实设备上打开阀门、启动电机、调节温度。一个逻辑正确但时序错误的动作，轻则设备停机，重则损坏机械结构或触发安全风险。更麻烦的是，物理世界不是静止的：当 Agent 读取一个模拟量、经过推理、生成计划、再写回控制字的这段时间里，系统的状态可能已经发生了变化。LLM 的慢思考在软件接口里可能只是延迟增加，在工业控制里可能直接导致控制失败。

这是 PLCBench 这类基准测试存在的第一层原因：它考察的不是模型的知识量，而是 Agent 在动态、有噪声、不可回滚的环境里做出可靠决策的能力。只有真正在模拟 PLC 环境里跑过一遍，才能理解一个看似普通的寄存器读写在物理闭环里意味着什么。

1.2 持续控制比单次正确动作难得多

很多评测任务属于一次性决策：给你一个状态，输出一个动作，然后看动作是否正确。这种评估方式对代码生成、问答、数学推理都很合理，因为环境在评估期间可以被视为静止的。但工业控制不是这样。

一个反应釜从开始加热到到达目标温度，中间要经历升温、接近、超调、回落的过程；一个储罐从低液位补到目标液位，中间可能越过上限报警；一条输送带启停之间，还要考虑顺序逻辑和互锁条件。每一个时刻的动作是否合理，取决于上一时刻的动作和当前的状态。Agent 做一次判断是容易的，持续几十步甚至几百步地维护系统在目标状态附近，才是真正的挑战。

sustained 这个表达暗示了评估的时间维度。这类评测通常会规定一个任务窗口，比如在 30 分钟内把反应釜温度维持在 90 到 95 度之间，评估 Agent 是否持续读取状态、持续调整、并在扰动出现后主动恢复。这个评价尺度比单步正确率更能区分一个 Agent 系统是否真正掌握了控制逻辑。换句话说，单步正确率高，不代表能在持续控制中不出问题；而持续控制稳定，才是工业场景真正需要的指标。

1.3 PLCBench 评估的是完整 Agent 系统

还要注意标题里的另一个词：Autonomous LLM Agents。PLCBench 不只是在测试基础模型能不能生成梯形图或结构化文本，它测试的是一个包含规划、工具调用、状态读取、动作执行、结果验证、记忆维护在内的完整 Agent 系统。模型能力是其中一环，工具设计、上下文管理和错误恢复机制同样重要。

这意味着，即使同一个模型，给它一组合适的工具接口，和给它一堆原始寄存器地址，最终的持续控制表现会差别很大。好的工具封装可以让 Agent 专注于决策，而不是在地址换算和字节序上消耗注意力；差的环境抽象会让模型频繁产生非法动作。PLCBench 这类评估框架的价值，在于它把模型能力和系统设计放到同一个可重复的测试环境里比较，让人看到瓶颈到底在哪一层。对做工业应用的开发者来说，这比单纯比较模型排行榜更有参考价值。

2. PLC 是 LLM Agent 打开物理世界的一扇门

2.1 为什么偏偏是 PLC

PLC（Programmable Logic Controller，可编程逻辑控制器）是工业现场最普及的计算设备之一。它没有通用操作系统那么复杂，但有明确的 IO 地址、扫描周期、程序区、寄存器区。相比单片机、工控机，PLC 更标准化，品牌之间虽有差异，但核心模型相似：读取输入、执行用户程序、刷新输出，按固定周期循环。

这让它成为 LLM Agent 接触物理世界相对合适的接口。只要掌握了一类协议的读写方式，剩下的工作就是把物理量映射成寄存器地址，再把点位表转成结构化文本喂给模型。一台 PLC 的当前状态、报警、过程值，几乎都能通过通信协议读出来；需要执行的动作，也能通过写寄存器或修改程序块写进去。

实际工程项目里，西门子、三菱、汇川这几个品牌出现频率很高，它们的软件环境、地址命名和通信协议差异明显。但无论哪个品牌，Agent 要解决的第一个问题都是：如何建立可靠的数据通道。这也是为什么很多相关项目在初期会优先选择 Modbus TCP，因为它简单、通用、容易排查。

2.2 LLM Agent 与 PLC 的完整交互链路

典型交互链路可以拆成以下几个环节：

1. 任务描述转成结构化目标，例如把 3 号储罐液位保持在 40% 到 60% 之间。
2. Agent 规划，决定需要哪些状态信息。
3. 通过通信协议读取 PLC 的输入、输出、寄存器、报警区。
4. 把读取到的原始值结合点位表，转成当前现场状态。
5. 根据状态生成决策：要么修改控制参数，要么写离散输出，要么生成一段新的控制逻辑。
6. 执行动作，写寄存器或下载程序。
7. 等待一段时间后重新读取状态，校验动作是否生效，必要时修正。

每一个环节都有自己的失败模式。状态读取可能因为通信超时失败，点位表映射可能因为工程师换过地址而错误，动作写入可能被 PLC 的写保护拒绝，生成的控制逻辑可能忽略了互锁条件。所以评估 LLM Agent 是否可靠，不能只看最后一步动作输出，而是要看整条链路在每个环节上的表现。

2.3 一个最小交互模型：Modbus TCP 示例

在本地验证环境里，Modbus TCP 是最容易上手的协议。下面是一段读取保持寄存器和写线圈的代码，用于理解 Agent 和 PLC 交互的最小模型：

from pymodbus.client import ModbusTcpClient PLC_IP = "192.168.1.10" PLC_PORT = 502 client = ModbusTcpClient(PLC_IP, port=PLC_PORT) client.connect() # 读取保持寄存器，起始地址 0，数量 10 read_result = client.read_holding_registers(0, 10) if not read_result.isError(): print("registers:", read_result.registers) else: print("read error") # 写单个线圈，假设地址 1 对应设备启动信号 write_result = client.write_coil(1, True) if write_result.isError(): print("write error") client.close()

这段代码里，地址 0 到 9 的寄存器代表什么，地址 1 的线圈控制哪台设备，都必须由点位表决定。点位表通常是一张 Excel 表，记录每个地址对应的标签名、数据类型、单位、量程、读写属性。对 LLM Agent 来说，点位表就是它的地图。如果没有点位表，模型即使读到了寄存器原始值，也无法理解当前系统状态。

2.4 数字量、模拟量与程序下载的差异

PLC 的 IO 大致分成两类：数字量和模拟量。数字量只有 0 和 1，常见于启停按钮、限位开关、继电器输出。接线时还要区分漏型和源型，比如热词里提到的输出脉冲接入西门子 PLC 的 NPN 接法，PLC 公共端接电源正，就属于典型的漏型输入接线。这类信息虽然属于硬件层，但 Agent 如果要诊断问题，同样需要理解。

模拟量是连续值，比如压力传感器输出的 4 到 20mA 信号，经过 PLC 模块转换后变成 0 到 27648 或 0 到 4000 的整数，需要按量程线性换算成工程值。Agent 在读取水位时，如果不知道量程转换关系，得到的原始整数值毫无意义。因此点位表设计非常关键，它决定了模型对现场数据的可读性。

更复杂的一类是程序下载。让 Agent 生成梯形图或结构化文本，再下载到 PLC，能实现更强的人机交互，但风险也更高。一个语法正确但时序错误的程序，可能比读错寄存器更致命。基础评估里不建议一开始就让 Agent 具备改写程序的能力，先跑通寄存器读写和状态反馈闭环，再考虑程序生成。

3. PLCBench 这类基准测试会如何设计评估框架

3.1 任务不是问答，而是可验证的物理控制任务

从同类工作来看，PLCBench 这类基准的任务场景，应该是从工业现场常见操作抽象出来的。比较有代表性的有四类：

1. 启停控制类：在满足互锁条件时启动设备，停止时按顺序退出。
2. 过程调节类：把温度、压力、液位调整到目标区间并保持。
3. 报警响应类：检测到报警后，按规则安全处置并恢复。
4. 顺序生产类：按配方顺序完成多个步骤，每步都有前置条件。

这些任务的共同点是可以自动判定结果，评测不需要人工介入。比如保持液位在 40% 到 60% 这个目标，可以直接从寄存器值读取出来，逐秒统计是否越界，然后算出各项指标。这也是基准测试能够规模化评估的基础。

3.2 观测空间与动作空间需要明确约定

基准测试必须约定 Agent 能看到什么、能操作什么，否则不同 Agent 之间的对比没有意义。观测空间和动作空间可以按层级划分：

观测空间决定 Agent 能拿到多少信息，动作空间决定它能做哪些事。动作空间太大，Agent 容易产生探索性的危险行为；动作空间太小，又不足以完成复杂任务。一个合理的基准设计会把动作空间收敛到任务必需的最小集合，同时在安全层拦截越界动作。

3.3 持续物理控制能力如何量化

一次动作成功率高，不代表持续控制能力强。更好的评估方式是在完整的任务时间窗口内统计以下指标：

• 任务完成率：在限定时间内达成目标任务的次数占比。
• 越界次数：过程量超过安全阈值或被安全层拦截的次数。
• 恢复时间：系统进入异常后，Agent 恢复到安全或目标状态的耗时。
• 稳定度：达到目标后，状态偏离目标中心的程度和时间。
• 执行效率：完成任务所需的步数、调用轮数或 token 数。

把持续这个抽象概念量化之后，不同 Agent 策略之间的差异才变得可比。这也意味着，想要复现或扩展这套评测，最重要的工作就是先把任务场景和指标定义规范化。场景定义模糊，评测结果就无法重复。

3.4 评测过程本身也要有安全边界

即使是在基准评测环境里，评测过程也必须考虑安全边界。物理仿真参数设置不合理，或者对 Agent 的越界动作不加拦截，就可能得到不可复现的失败数据。常见做法是在环境外面加一层模拟联锁保护：当 Agent 的动作超过安全范围时，环境强制回退该动作，同时记录一次越界。这样既能测出 Agent 的问题，又不会让评测过程失控。

注意：评测环境里的安全层，通常模拟的是真实 PLC 中的硬件联锁和急停机制。研究阶段可以简化，但到了真机阶段，独立于 Agent 的物理安全层不能省略。

4. 在本地搭一个最小 LLM Agent PLC 控制验证环境

4.1 先用仿真 PLC 代替真实设备

如果直接在一台真实 PLC 上测试 LLM Agent，风险很高。更稳妥的做法是先用仿真环境。可选方案有三个层次：

• Python 模拟从站：用 pymodbus 的服务端模拟一组寄存器和线圈，适合验证通信和决策逻辑。
• OpenPLC 运行时：开源软件 PLC，能运行结构化文本程序，支持 Modbus TCP，能模拟简单过程。
• 厂商仿真器：西门子 PLCSIM、三菱 GX Simulator 等，功能接近真机，但依赖厂商软件环境。

建议从 Python 模拟从站开始，因为它启动最快，并且方便人为注入故障和噪声。如果目标是贴近真实 PLC 行为，再切到 OpenPLC 或厂商仿真器。

4.2 用 pymodbus 模拟一个会变化的物理过程

下面是一个模拟从站示例。它创建了一个简单环境：当前液位会向设定值缓慢靠近，同时叠加随机扰动。这样一来，Agent 每轮读取的数值都会变化，而不是一直停留在初始状态。

from pymodbus.server import StartTcpServer from pymodbus.datastore import ModbusSequentialDataBlock, ModbusSlaveContext, ModbusServerContext import threading import time import random # 初始化寄存器：地址0为设定液位，地址1为当前液位 store = ModbusSlaveContext( di=ModbusSequentialDataBlock(0, [0] * 100), co=ModbusSequentialDataBlock(0, [0] * 100), hr=ModbusSequentialDataBlock(0, [100, 35] + [0] * 98), ir=ModbusSequentialDataBlock(0, [0] * 100) ) context = ModbusServerContext(slaves=store, single=True) # 后台线程模拟液位向设定值缓慢靠近 def physics_loop(): while True: ctx = context[0] setpoint = ctx.getValues(3, 0, 1)[0] level = ctx.getValues(3, 1, 1)[0] if level < setpoint: level = min(level + 1, setpoint) elif level > setpoint: level = max(level - 1, setpoint) level += random.uniform(-0.3, 0.3) ctx.setValues(3, 1, [max(0, min(100, round(level)))]) time.sleep(2) threading.Thread(target=physics_loop, daemon=True).start() StartTcpServer(context, address=("0.0.0.0", 502))

这段代码只能用于理解思路。实际使用时，要根据自己环境的 pymodbus 版本调整 API 细节，比如服务器地址、从站数量、寄存器数量。重点是理解：模拟从站可以替 Agent 提供持续变化的状态量。

4.3 Agent 主循环：决策、过滤、执行、验证

Agent 的核心不是让模型自由发挥，而是让它在受限的动作空间里工作。下面是一个简洁的结构示意。这里使用伪代码表达流程，不绑定具体模型名称：

def safety_filter(act): # 设定值不能超过量程 if "setpoint" in act and not (0 <= act["setpoint"] <= 100): return False # 不能随意关闭联锁 if act.get("action") == "disable_interlock": return False return True def agent_loop(task, max_steps=50): memory = [] for step in range(max_steps): state = read_plc_state() plan = llm_plan(task, state, memory) if not safety_filter(plan): log_abort(plan) return "aborted" execute(plan) time.sleep(2) new_state = read_plc_state() if is_task_done(new_state, task): return "completed", step memory.append({"plan": plan, "state": new_state}) return "unfinished", max_steps

关键点在于三个函数的分工：llm_plan负责推理决策，safety_filter负责在物理动作之前拦截风险，is_task_done负责客观判定任务是否完成。这样的结构把模型能力和安全机制解耦，任意模型输出都必须经过独立于模型的校验层，才能到达仿真 PLC。

4.4 安全联锁必须独立于 Agent 存在

任何让 LLM Agent 直接连接 PLC 的架构，都必须把安全联锁设计在 Agent 之外。可以这样理解三级结构：

• LLM Agent 负责建议动作。
• 安全层负责判断动作是否允许。
• PLC 自身的硬件联锁负责最终保护。

这三层不能合并。否则模型幻觉、输出格式错误、上下文污染都可能直接导致物理设备误动作。安全层的规则应该简单、明确、可测试，并且最好由懂工艺的工程师编写。比如设定值范围、允许启停的设备清单、互锁条件，都不应该由模型在运行时自行推断。

注意：在真机环境中，急停、机械限位、独立安全继电器等硬件级联锁不能由任何软件绕过，包括 LLM Agent 生成的程序。仿真阶段可以简化，但真机阶段必须严格遵守。

5. 常见问题与排查路径

5.1 状态读取不到或读到旧值

现象：Agent 每次读取到的寄存器值都一样，或者读取直接超时。

可能原因：PLC 的 IP 或端口配置错误；点位地址映射不正确；读取频率比数据刷新频率快；字节序或数据类型配置不一致。

排查顺序：

1. 先用 Modbus 调试工具读取同一地址，确认链路本身可用。
2. 检查点位表的地址换算，特别注意 0 起始和 1 起始的区别。
3. 检查 32 位寄存器的高低字节顺序。
4. 确认 PLC 扫描周期和数据变化频率。

处理建议：先恢复手动读取通路，再让 Agent 接入。在没有可视化工具的情况下直接排查通信问题会比较低效。

5.2 写寄存器成功但设备无动作

现象：写入操作返回成功，寄存器值也变了，但物理设备没有反应。

可能原因：写的是数据寄存器，而不是控制寄存器；控制逻辑要求多个条件同时满足，只写一个条件不会动作；设备处于手动模式或联锁状态。

排查顺序：

1. 查看设备控制逻辑和互锁条件。
2. 对比正常手动操作时哪些寄存器发生变化。
3. 查看 PLC 是否处于 RUN 模式。

处理建议：在 Agent 的可调用工具里增加读取设备状态的操作，先确认设备允许动作，再执行写入。

5.3 Agent 产生非法动作

现象：模型输出了超出动作空间的内容，比如直接生成一段梯形图、写一个负的设定值、或者跳转到一个不存在的工具。

可能原因：模型输出没有严格受限于 JSON 或动作 schema；提示词里没有给出动作白名单；没有接入安全过滤层。

处理建议：把动作空间收敛成固定格式，使用结构化输出校验。模型输出必须经过 safety_filter 之后才能执行，不能直接透传。

5.4 多步执行后状态漂移

现象：前十几步表现正常，后面越来越偏离目标，Agent 似乎忘记了最初的任务。

可能原因：上下文过长，早期目标信息被压缩或丢失；每次读取状态时没有对比目标值；缺少对历史动作结果的归纳。

处理建议：在 Agent 的上下文里保留简洁的任务目标和最近几步的状态摘要，不要把全部原始日志都塞进去。

5.5 联锁触发后 Agent 无法恢复

现象：安全过滤拦截了动作，Agent 进入死循环，不断生成被拦截的同类动作。

可能原因：安全过滤只返回拒绝，没有给出拒绝原因；Agent 没有从拒绝结果里提取约束；动作空间里缺少恢复和等待选项。

处理建议：安全层返回结构化拒绝信息，例如{"allowed": false, "reason": "value_out_of_range"}，让 Agent 能根据原因调整下一步动作。

以下是汇总表：

6. 最佳实践与扩展方向

6.1 给 Agent 暴露语义化工具，而不是原始寄存器

不要直接给模型写寄存器 0x0001 这种底层能力。更好的抽象是启动输送带、设置液位设定值、读取 3 号罐状态这类语义化工具。这样模型不容易产生非法值，评测也更容易记录动作含义。工具层封装得越干净，Agent 的表现越稳定。

6.2 完整记录执行轨迹

每一个动作、每一次状态读取、每一次安全拦截，都应该记录。这对复现失败、评估效果、审计行为都有价值。记录格式可以使用 JSON 行，每条包含时间戳、工具名、参数、返回结果、安全判定。有了完整轨迹，才能定位到底是模型推理错误、工具封装错误还是安全规则过严。

6.3 从仿真到真机的渐进路线

每进入下一阶段之前，都要确认上一阶段的指标达标。跨越阶段推进往往会在真机上暴露原型问题，排查成本会高很多。

6.4 发布前检查清单

在把这类系统从研究环境推向工程环境之前，至少检查以下内容：

• 点位表和寄存器映射是否与现场一致。
• 动作白名单是否覆盖所有必要操作。
• 安全过滤是否对模型输出强制生效，而不是只做提示。
• 日志是否完整记录每次读写和拦截。
• 是否有超时和自动回退机制。
• Agent 模型版本和依赖库版本是否固定。
• 是否有独立于 Agent 的急停和手动模式。
• 是否做过故障注入演练，比如通信中断、传感器漂移、联锁触发。

回到 PLCBench 的标题，真正决定一个 LLM Agent 能否把 PLC 访问变成持续物理控制能力的，往往不是单次推理正确率，而是环境建模、动作封装、安全层和状态跟踪这些系统设计环节。对想进入这个方向的开发者来说，最有价值的起步方式，不是先比拼模型效果，而是先搭好一套可控、可记录、可复现的仿真闭环，把问题和瓶颈量化出来。之后再逐步靠近真实 PLC 和真实工艺，在每一层加上足够的安全边界。