PLC与AI Agent架构同构：从梯形图到LangGraph的状态机思维

从梯形图到LangGraphPLC和AI Agent原本就是同一种架构思想干过工业自动化的人第一次接触AI Agent框架的时候大概率会有一个隐约的熟悉感。我也一样早期调三菱FX系列的时候一个扫描周期里又是读输入又是刷输出中间夹着几十步梯形图逻辑后来接触LangChain和LangGraph发现Agent的“观察-思考-行动”循环不就是把PLC那个扫描周期给放大了吗一边是继电器触点、线圈和定时器一边是LLM调用、工具调用和状态节点。表面上是两个世界的东西脱掉外壳之后底层逻辑框架几乎一模一样。这个观察起初只是个闲谈但越往深挖越觉得有价值。PLC工程师学AI Agent或者AI工程师回头理解PLC都有一条极其陡峭但又极其通透的捷径——因为这两套东西本来就是同一个思想在两个领域的投影。本文不打算讲“PLC是工业老古董、AI是未来”这种外行话而是认真拆一拆为什么PLC的梯形图逻辑、扫描周期、状态位、通信协议和AI Agent的感知循环、上下文状态、工具调用、环境交互本质上是一回事。这个视角能让你用一套已经熟练的心智模型快速理解另一边的世界。1. 先破题CPU指令周期、PLC扫描周期和Agent行动循环的“同构性”1.1 PLC的扫描周期工业自动化最朴素的“灵魂循环”PLC的工作原理说穿了不复杂通电之后CPU就在那里高速地重复做三件事——读输入、跑程序、写输出。这个循环叫扫描周期老派工程师习惯叫它“扫表”。一个标准的扫描周期拆开看长这样读取输入映像区把X0、X1这些物理输入端口的电信号通/断、0/1采集进内存得到一个“此刻世界长什么样”的快照。执行用户程序CPU基于输入映像区、当前内部继电器状态M区、定时器T、计数器C从左到右、从上到下地扫描梯形图计算出每个输出线圈Y区应该是什么状态。刷新输出映像区把计算结果统一写到输出模块让Y0、Y1这些物理端口真正带上电或断电。这个循环之所以叫“扫描”而不是“执行一次”是因为它永不停止。PLC从上电那一刻起这个循环就在跑直到断电。普通的扫描周期在几毫秒到几十毫秒之间依据程序大小和CPU主频而定。1.2 AI Agent的“感知-决策-执行”循环换个名字的老朋友AI Agent的架构今天讲得天花乱坠的什么ReAct模式、什么Plan-and-Execute、什么多智能体协作本质上都在说一个循环观察ObservationAgent通过工具调用、API请求、用户输入或者环境反馈获取当前状态。比如一个客服Agent先接收到用户问题再查询订单数据库拿到订单状态。思考Thought大语言模型基于当前上下文和观察结果推理出下一步该做什么输出一个决策。比如“用户要退款需要先调用退款接口再发送确认消息”。行动ActionAgent执行工具调用这个工具可能是HTTP API、Python函数、数据库查询甚至是一个机器人控制指令。循环行动的结果会作为新的观察反馈进系统然后再次进入思考。直到Agent认为任务完成才输出最终答案。如果你把这个循环和PLC扫描周期放到一起对比会发现惊人的结构相似性。PLC读输入Agent做观察PLC跑梯形图逻辑Agent做LLM推理PLC写输出Agent执行工具调用。唯一的区别是PLC的“模型”是工程师预先写死的梯形图Agent的“模型”是权重经过训练的大语言模型。一个靠固化逻辑一个靠参数涌现但架构上都是“感知-决策-执行”的闭环。1.3 一个类比接线员、车间主任和数字员工用大白话再捋一遍这个同构性。PLC可以理解成一个不知疲倦的车间巡查员他每天固定时间巡视一遍车间的所有传感器读输入对照手里那本厚厚的操作手册用户程序做判断该开哪台机器、该关哪个阀门写输出然后循环往复。而AI Agent是一个数字世界的车间主任他先看一眼当前情况观察对着脑子里的大模型做判断思考然后安排工具去干活行动干完再回头看一眼有没有干对新的观察。这两个人的工作文档、汇报周期、决策机制不同但角色的完整闭环是一模一样的。理解了其中一个人另一个人你就已经会了大半。1.4 为什么这个同构性容易被忽视因为两者包装差异太大。PLC的“语言”是梯形图、指令表、结构化文本Agent的“语言”是Python、JSON、自然语言Prompt。PLC跑在专用硬件上Agent跑在通用服务器上。PLC的每个扫描周期开销极其稳定Agent的每次推理延迟飘忽不定。这些差异就像同一家公司换了制服和办公系统老同事一眼认出来新员工却觉得是两家公司。2. 有限状态机视野下的PLC程序与Agent工作流万物皆状态流转2.1 梯形图本质上是并行状态机工业自动化领域最经典的一个判断是PLC程序的核心骨架就是有限状态机FSM。梯形图看起来是一堆触点串联并联的电路图但你在上面做的工作其实是在定义系统当前处于什么状态在什么条件下迁移到什么状态迁移过程中执行什么动作。举个最典型的例子十字路口红绿灯PLC程序。你写这段程序的时候本质上在构建一个四状态的状态机南北绿灯/东西红灯南北黄灯/东西红灯南北红灯/东西绿灯南北红灯/东西黄灯。每个状态持续固定的时间用定时器T0、T1控制时间到了就切换到下一个状态。梯形图里那些常开触点、常闭触点就是状态迁移的触发条件输出线圈就是状态下的动作。这个思维模式和AI Agent的LangGraph工作流设计完全兼容。LangGraph里每个节点是一个状态节点之间的边是迁移条件节点内部可以执行工具调用或LLM推理。比如一个订单处理Agent可以拆成订单已接收→信息校验→支付处理→发货执行→售后确认。每个节点的状态更新、条件判断和PLC的状态机思路是同一套逻辑。2.2 状态位、M继电器和Agent的Memory同一个东西PLC里最常用的编程元素之一就是M继电器也叫内部辅助继电器。它不是物理存在的只是内存中的一个位用来记录“系统现在处于什么模式”“这台设备是不是处于自动状态”“启动按钮是否已经被确认过”。用M0、M1这类标志位工程师把所有需要跨扫描周期记忆的信息都存储下来。有经验的老工程师会反复叮嘱新人梯形图里的M位就是PLC的短期记忆。Agent世界里和M位对应的东西叫Memory、State或Context。一个客服Agent需要记录“用户是否已经验证过身份”“当前对话是否处于退款流程中”“昨天处理到哪一步了”。这些状态信息要么放在对话历史里要么放在显式的状态变量中。LangGraph的State对象本质就是一组结构化的M位按更丰富的类型和维度进行扩展。我在接入Agent项目的时候下意识沿用PLC编程的习惯——先把所有状态位列出来会话状态、工具调用状态、错误重试状态、任务完成状态。然后再设计状态迁移条件。这个习惯让我写Agent工作流的速度比直接上手Prompt工程快得多因为工业界的“状态机优先、动作其次”思维天然适配Agent任务的模块化拆分。2.3 边沿触发的妙用从“电平”思维升级到“事件”思维PLC编程里有一对非常关键的概念电平触发和边沿触发。电平触发是“只要条件为真就一直生效”边沿触发是“只在条件从假变真或从真变假的那一刻生效”。比如一个启动按钮如果用常开触点电平触发按下去就一直启动如果加上上升沿指令P指令、微分指令只会在按下的瞬间触发一次不理会按钮按了多少秒。Agent世界里这个区分也很重要。你的Agent在收到用户重复消息时是每次都当作新事件处理还是只在状态变化时触发特定动作一个日志监控Agent如果在每次轮询时都记录“当前无异常”日志会被刷爆正确做法是只在状态从“正常”变为“异常”时发送告警。这就是边缘触发思维在Agent设计中的体现——从轮询思维升级为事件驱动思维。2.4 从状态机到工作流引擎PLC顺控程序与Agent编排的殊途同归PLC里还有一种经典编程范式叫顺控程序用步进指令STL或状态位依次激活的方式把一套复杂的流程切成一系列有序步骤。每个步骤有自己的进入条件、执行动作、退出条件。典型的场景是机械臂的上料-加工-下料流程每一步都不能跳序必须在前一步完成后才能启动后一步。当我第一次看到LangGraph里的条件边、循环边、并行分支时脑子里第一个念头就是这不就是PLC顺控器做成了软件库吗PLC顺控强调严格的前后依赖Agent工作流更灵活允许分支和并行但核心骨架都是按条件流转的有向图。把Agent的编排逻辑想象成一张“软PLC顺控图”你就能非常自然地理解为什么LangGraph的图结构能表达复杂流程。3. 六维对比输入、输出、循环、异常、协议、工程方式的全面映射3.1 输入模块与工具集传感器和API都是“世界的接口”PLC的输入模块负责把外部物理信号转成CPU能读的比特流。传感器类型五花八门限位开关、光电传感器、温度变送器、编码器、模拟量模块。每一种输入都有它的信号特性、响应时间、精度限制。工程师要做的是选对输入模块并正确接线保证信号稳定。AI Agent的“输入模块”就是工具集ToolsHTTP API、数据库查询、文件读取、搜索引擎。每一个工具都有它的输入参数、返回格式、限制条件。Agent工程师的工作同样是定义清楚每个工具的能力边界和调用方式让大模型拿到可靠的“感知输入”。传感器读数和API调用本质上都是“从外界获取信息以更新系统认知”的过程。3.2 输出模块与工具调用Y线圈和Function Call的对应关系PLC的输出模块继电器输出、晶体管输出、可控硅输出负责把CPU算出的结果变成物理世界的动作电磁阀得失电、电机启停、指示灯亮灭。输出模块同样有类型之分继电器输出能带动大负载但慢晶体管输出响应快但负载能力弱。硬件工程师要根据负载特性选择输出类型。Agent的输出端是工具执行。LLM决定调用哪个工具传递什么参数然后工具真的去执行外部动作——发一封邮件、下一笔订单、控制一个机械臂。为了保证可靠性Agent的工具调用同样需要“驱动能力匹配”一个是重命令比如发邮件要确认执行一个是轻查询比如查天气可以直接返回。这完全对应PLC输出的“带继电器还是带晶体管”的选型思维。3.3 循环频率的差异扫描周期与LLM推理延迟的工程权衡PLC的扫描周期追求确定性用户程序的执行时间被严格控制重要的控制系统甚至要求扫描周期恒定否则PID调节的采样间隔会抖动导致控制品质下降。这也是为什么PLC要跑在RTOS上中断优先级和看门狗都是标配。Agent的推理延迟则大得多且不稳定一个LLM调用可能要几百毫秒到几秒加上工具往返时间整个循环可能达几十秒。这带来的工程问题是——如何保证Agent在循环较慢的情况下依然能正确响应答案是设计更长的超时、更完善的异步机制、更智能的上下文压缩。但不管怎么调你都甩不掉那个“循环越短响应越快成本越高”的基本权衡这和PLC工程师选择扫描周期长度的思路是一模一样的。3.4 异常处理PLC看门狗和Agent重试机制是同一个焦虑PLC领域最恐怖的一幕是程序跑飞了循环卡住了输出卡死在某个状态现场设备失去控制。为此PLC系统普遍配备看门狗Watchdog如果程序不再周期性地喂狗硬件自动复位CPU把所有输出拉到安全状态。同时还要做“急停回路”——靠硬接线保证在任何软件故障下都能切断危险输出。Agent领域同样有这种焦虑LLM可能返回错误格式、工具可能超时、外部API可能返回异常。如果Agent卡在一个死循环里和PLC卡死一样危险——虽然不会炸设备但会一直调用付费API、一直给用户重复消息。Agent的世界里对应物是重试机制、最大轮数限制、超时熔断、错误恢复分支。LangGraph提供了循环限制和条件退出这相当于给Agent装了一个“软件看门狗”。PLC工程师第一次给别人讲解Agent的错误恢复时讲的其实就是“喂狗”思维的数字化演绎。3.5 通信与协议Modbus和工具调用协议的“同一张底牌”PLC的世界里设备间通信靠工业协议Modbus RTU、Profibus DP、EtherNet/IP、OPC UA。这些协议的核心任务就是定义“谁发数据、谁收数据、数据格式是什么、怎么确认”。一台西门子S7-200 SMART和一个森兰变频器走Modbus通信本质上是约定好寄存器地址和功能码让两个设备能交换控制字和状态字。Agent的世界里协议变成了API规范和JSON SchemaAgent调用一个天气API时需要约定好endpoint、请求方法、参数格式、响应结构。两者不同的是工业协议的时间确定性要求极高一个周期内必须完成一次数据交换API则容忍更大的延迟但底层的“约定接口、交换数据、校验状态”三板斧原封不动地出自同一套通信思维。懂得Modbus报文的人看懂RESTful API的入参出参完全没障碍。3.6 工程方式从梯形图版本管理到Prompt/Graph版本管理的演进PLC的工程化一直是个痛梯形图程序的版本管理、多人协同、仿真测试长期处于“能用但不好用”的状态。很多工厂里程序版本靠文件名后缀V1.2_daily_0805这种土办法管理。博途等现代IDE已经做了改进在联机调试、在线监控方面做得不错但整体工程化水平相对软件行业还是差距明显。Agent项目反而继承了软件工程的正规军打法Git管理Prompt和Agent定义、单元测试工具函数、端到端测试整个Agent流程、CI/CD自动部署。这对有PLC背景的工程师是一个值得学习的方向。我一直建议习惯写梯形图的朋友无论如何都要用Git管理Agent项目里的所有定义文件这比PLC工程的进步先进了不止一个时代。4. PLC早就教会我们的Agent工程问题并发、竞态与变量命名4.1 Agent的并发问题PLC老工程师早就知道该怎么问“AI Agent怎么扛并发”这个热搜词本身就很有意思。因为并发问题在PLC领域其实是一个早已被翻来覆去研究过的话题。PLC跑在单线程循环中每次扫描只能处理一个快照。哪怕外部信号在同一时刻发生变化PLC也只能在下一个扫描周期才感知到。这种“单线程周期快照”模型天然规避了大部分并发问题——没有多线程竞争只有先后顺序差异你拿到的永远是上一周期的统一快照。但Agent服务要面对用户并发请求就要真正处理多线程、异步、状态隔离。每个用户对话都是一个独立的状态实例当一个Agent在处理A用户请求时B用户请求不能被阻塞。PLC工程师处理并发的方式是“把并发拉平成排队”而Agent服务器并行执行时需要一个重要的约定——“每个请求拿到的状态不能互相污染”。这个问题在PLC里叫变量隔离在Agent里叫State并发安全本质上问的是这个状态位是全局共享的还是任务独立的。懂了PLC的M区和D区的分区思维设计Agent多租户隔离会异常自然。4.2 竞态条件的Agent版本条件判断与状态更新的顺序陷阱PLC程序员最忌违的一件事是在梯形图的不同位置重复修改同一个M位。因为扫描周期内变量的读写顺序会影响最终结果——同一扫描周期内先写的M位可能被后面的程序覆盖也可能被后写的逻辑读取。这就是PLC领域的竞态条件。老工程师写程序时有统一规范一个M位只在一个Network里写其他地方只能读。Agent的LLM推理链里也存在同样的坑。如果你让一个Agent先做判断“用户是否有权限”然后调用工具删除数据再修改变量标记“权限已核验”这个顺序可能因为LLM的“输出漂移”而出现意外模型可能先调用删除工具再判断权限。解决办法和PLC一样——用结构化流程把读写顺序固定下来在LangGraph里就是显式地把条件判断作为一个独立节点把工具调用作为后续节点用边来强制顺序。这不是想出来的流行方案而是工业级系统一贯的硬约束。4.3 变量命名和注释PLC梯形图和Prompt工程共用的生存法则干过非标设备调试的朋友都懂一个没有注释、命名混乱的梯形图程序三个月后连写它的人都看不懂。我在调试客户的老设备时经常面对一堆X0、Y1、M100没有任何注释逻辑全凭猜。可以说梯形图时代的糟糕代码比软件行业的腐烂代码更让人痛苦——因为现场改错的代价大得多。这个教训原封不动地适用于Agent工程你写的System Prompt如果不加注释、不结构化、没有版本记录几天后模型升级一换所有行为全部漂移却不知道是改了什么导致的。我在Agent项目里沿用PLC时代的习惯每个节点的职责写清楚、每个工具的参数注释齐全、每个State字段标注含义。Agent创建的代码效果好不好另说工程规范先立起来。5. AI代码生成正在拉平PLC与Agent的技术门槛5.1 AI辅助PLC编程从梯形图到代码生成的实践路径现在“AI PLC代码生成”已经是一个非常火的方向。AI可以通过自然语言描述来生成结构清晰的PLC程序比如提出“设备启动时先启动润滑泵3秒后启动主轴电机停止时主轴先停4秒后停润滑泵”大模型可以基于结构化语言或者说专门训练的模型直接生成对应的梯形图逻辑或结构化文本ST。这个能力让非标自动化项目的起步速度快了不止一倍。但这里有个陷阱得提醒AI生成的PLC程序和AI生成的Agent代码一样都只是“初稿”不能直接上现场。因为PLC程序必须处理外围信号的真实验证——急停信号接没接、传感器极性对不对、机械限位在哪个位置。AI不知道这些硬件细节。所以我的经验是把AI生成的程序当作“第一版草稿”然后基于安全规范做一轮严格审核加上急停、互锁、异常分支。这跟用AI生成Agent后必须人工审查工具权限边界、输入输出校验是同一个流程。5.2 大模型时代的PLC学习曲线从“记语法”到“问问题”传统的PLC学习曲线陡峭得吓人要记梯形图的每一条指令要懂电气接线要会看时序图要了解各种通信协议。一个PLC工程师的成熟周期通常要3到5年。但现在有了大模型学习路径完全变了。你可以直接问“定时器TON的接通延时是什么意思”得到一句人话解释加示例程序甚至可以直接让AI生成一个特定功能的梯形图片段然后照着理解。这极大拉低了入门门槛也改变了老工程师的学习方式。我也在用这个思路补AGENT的方向不用再从头啃LangChain的所有文档直接让大模型生成一段代码解释一遍然后实际测试验证——先把AI Agent跑起来再慢慢消化细节。这跟学PLC时的“先上电让电机转起来再研究油门曲线”的思路完全一致。5.3 双向奔赴Agent写代码PLC工程师写Agent还有一个有意思的演变AI可以帮助写PLC代码同时PLC工程师也在借助AI理解Agent架构。现在一个原本做电气自动化的工程师如果想要转型做AI Agent开发好用的AI辅助工具已经把“理解库结构、写API调用、调Prompt”这个过程简化为对话和验证。关键的门槛从“会不会写代码”变成“懂不懂系统架构、有没有工程思维”。而这一点恰恰是PLC工程师的强项——他们在现场调试中摸爬滚打出来的对时序、状态、错误恢复的理解和Agent工程需要的能力高度重叠。我在带团队工作时观察到一个规律有PLC调试经验的工程师学习Agent开发的适应速度通常快于纯前端或纯后端的同事。因为Agent开发的核心问题状态怎么流转、超时怎么办、异常分支怎么处理在PLC生态里已经有了十几年实战训练。一个是控制电机一个是控制API调度器的思维是互通的。6. 以PLC为锚点重构AI Agent的认知框架说到底PLC和AI Agent的底层共性不是巧合而是自动化和智能化共同继承的控制论思想。自动控制领域有句老话叫“反馈是控制的核心循环是系统的灵魂”。PLC每秒几十次地反馈、判断、输出Agent每隔几秒到几十秒地观察、推理、行动——它们都是这个理念的不同物理形态。这也解释了为什么从事PLC工作的人看AI Agent会有那种“似曾相识”的感觉你早就掌握了状态流转的建模方式、循环的执行逻辑、异常处理的兜底方案、通信协议的解构能力。只不过从前你把这套能力用于梯形图和变频器现在可以用它去理解LangGraph、Prompt和工具调用。AI Agent并非从石头缝里蹦出来的新物种它是自动控制思想在数字世界的延伸只是换了一张更聪明的脸。理解到这一点之后你会发现Agent的学习路径清晰了许多从观察——每个传感器和API都是感知系统到决策——梯形图里的每一段逻辑都是LLM推理的确定化版本再到行动——Y线圈和工具调用都是在世界某个角落做出改变。循环往复万物皆然。下次你打开LangGraph的Graph定义时试着把它想成一张程序流程图——那些节点就是你的状态步那些边就是你梯形图里的条件触点。你会发现自己其实一直在写同一种程序只是穿了不同的编程语言外衣。这种“熟悉的陌生感”是学习新技术的最好盟友。