从入行到现在的十多年里我经手过不少控制系统项目从PLC到DCS从伺服到运动控制卡从ISA-95金字塔底层的传感器校准到顶层的MES对接都摸过一遍。这几年AI概念大热尤其是大语言模型带火“Agent”这个词之后客户跟我聊的需求画风就开始变了从“能不能做个数据看板”变成“能不能让AI直接控制产线出问题自动处理”。每次听到这类需求我一般都会先沉默两秒因为懂得人都知道把“实时控制”和“工业Agent”这两个词放在一起本身就是一个非常危险的信号。今天我就掰开揉碎讲清楚为什么我说“实时控制的工业Agent”在当前阶段是一个伪命题以及如果你真想在这个方向上做一些实事到底应该把劲使在哪里。先给不熟悉的读者打个底这篇文章聊的不是某个具体的产品而是一类技术方案的可行性。“工业Agent”指的是以大模型为推理核心、能够自主感知环境、做决策、执行动作的智能体它通常被认为是工业自动化的下一个形态而“实时控制”指的是在严格的时间约束内完成数据采集、计算、决策和输出的一整套控制系统行为常见于伺服驱动、过程控制、安全联锁等场景。这两者听起来是实现“无人化工厂”的绝配但实际上它们的底层逻辑相互冲突。这篇文章适合所有从事工控、智能制造、AI落地的工程师和项目决策者也适合那些正在评估“AI能不能直接帮我控制设备”的工厂负责人。1. 概念拆解为什么“实时控制”和“Agent”天生八字不合1.1 实时控制的真实定义确定性才是灵魂做我们工控这行的人听到“实时”这个词脑子里浮现的绝对不是“快”而是“确定性”。我一直跟年轻工程师强调实时系统的核心指标不是平均响应时间而是最坏情况响应时间也就是WCETWorst-Case Execution Time。系统必须保证在极端工况下也能在规定的时限内完成指定动作。否则设备就等着撞机、烧料、爆管甚至出安全事故。工业场景里的实时性要求是分级的。比如伺服驱动的电流环控制周期通常是微秒级1kHz、2kHz甚至更高频率的调节无时无刻不在进行运动控制器的插补周期一般是1ms到4ms大型PLC的扫描周期在几毫秒到几十毫秒而过程控制中的DCS循环常见的是100ms到500ms。再往上走到MES或ERP层面的调度分钟级、小时级都算“准实时”。这里面最要命的是一旦周期确定整个链路里的每个环节都必须为这个周期服务传感器信号必须在规定时间内被采集到位控制器必须在规定时间内完成运算执行器必须在规定时间内完成动作。任何一个环节抖动都会导致控制品质下降或设备报警。这在工业现场就是天条没有讨价还价的余地。1.2 Agent的本质一个“慢思考”的软件体再来看Agent。大模型驱动的Agent本质上是一个“慢思考”的软件体它的工作方式是感知输入 → 大模型推理 → 输出动作 → 观察反馈 → 再次推理。这个过程里每一步都要消耗毫秒到秒级的时间。我实测过不少大模型的单次推理延迟即使使用高端的GPU一个中等复杂度的决策请求从输入到输出往往也要几百毫秒甚至几秒。更要命的是大模型的推理时间不是稳定的。上下文长度一变、并发请求一多、任务复杂度一高响应时间就开始大幅波动。之前在一台A100上用某个开源模型跑产线异常诊断的场景同样的输入响应时间从400ms到2.5s之间来回跳完全无法预测。你想想这种特性放到伺服控制环里会发生什么——电流环指令晚到1ms电机可能就振动了晚到10ms飞车都有可能。Agent的特性决定了它只能做“有容错空间”的决策而工业实时控制恰恰是“零容错空间”的领域。这两个东西放在一起就像是让一个严谨查阅资料、反复思考才下笔的学者去当F1赛车的换挡机械师反应速度根本不在一个量级上。2. 硬件与架构层面的硬伤Agent进不了控制环2.1 大模型推理的物理延迟是绕不过去的坎很多人会说我把大模型部署到工厂本地用高性能推理卡延迟是不是就下来了我可以负责任地告诉你就算部署在企业级的A100/H100集群上大模型单次推理的延迟依然处于“毫秒到秒”这个量级。为什么因为Transformer架构的推理过程是序列生成的必须一个一个token地输出前一个token没算完后一个token就无法开始。输出长度越长延迟就越大。就算你非常克制地把输出控制在20个token以内再加上输入文本的prefill时间一次推理的延迟至少也有几十毫秒。这还只是纯推理时间没算上视觉编码——如果Agent要“看”摄像头画面图像预处理和特征提取又是一轮时间和算力的消耗。更进一步说工业控制的环境往往没有你想象的那么好。车间里高温、高湿、粉尘大你不能指望每台设备旁边都塞一台高性能服务器。工业级的GPU服务器的成本、功耗、散热在大多数产线上都是很难落地的事情。个别有钱的客户可以堆算力但堆了算力也改变不了算法本身的延迟上限。2.2 通信链路和系统调度的不确定性就算Agent的推理延迟能压缩到20ms以内控制闭环里还有另外两座大山通信链路和系统调度。工业现场常用的通信方式包括EtherCAT、Profinet、EtherNet/IP、Modbus TCP等工业以太网协议它们本身是有确定性保证的。但一旦你要把Agent接入进来通常会通过OPC UA、MQTT或REST API这类通用协议。这些协议跑在标准TCP/IP协议栈上存在网络拥塞、缓冲区排队、重传等不确定性。我曾经在一个项目里测过通过OPC UA从设备读取一个变量的时间正常情况下是20ms到50ms但在网络繁忙时最坏能到200ms以上。这种波动放在实时控制里是不可接受的。操作系统的调度也一样。Windows/Linux的通用任务调度器没法保证Agent进程能百分百抢占到CPU时间片。哪怕你用实时内核也只是把确定性边界往后推了一点真正跑大模型推理时GPU的驱动、显存的管理仍然存在随机性。工业控制里的硬实时系统通常要用FPGA或专用DSP用裸机或者RTOS来跑固定的任务循环每一个周期都是被精确计算好的。Agent这种重量级应用根本塞不进去。3. 工业现场的真实处境Agent到底该站在哪一层3.1 控制层级的金字塔每一层都有不同的时间尺度做工业自动化的工程师都知道ISA-95的层级金字塔。在规划任何一个智能化改造方案的时候我建议先把这个金字塔画出来再把Agent放进去看看它到底属于哪一层L0/L1层现场设备层和过程控制层。伺服、变频器、PLC、DCS在这里做实时控制周期从几百微秒到几十毫秒这是“实时控制”的核心地带。L2层监督控制层。SCADA、历史数据库、先进控制APC在这里运行能做秒级、分钟级的优化控制。L3层生产管理执行层。MES在这里做生产调度、质量管理、物料追踪时间是分钟级到小时级。L4层企业经营管理层。ERP、供应链系统在这里运作时间尺度是小时级到天级。你仔细看这个金字塔真正称得上“实时控制”的层是L0/L1。而Agent最合适的栖息地其实是L2/L3甚至L4。为什么因为这些层级对响应时间的要求没有到“硬实时”的严苛程度允许Agent慢慢思考、调用工具、查资料、生成策略。我之前参与过一条新能源电池产线的改造项目客户的初始需求就是“让AI Agent直接控制涂布机的张力”。我跟客户反复沟通后把方案改成了“Agent负责监控张力波动趋势并给出修正建议由PLC侧的自动模式执行具体调节”。最终Agent跑在L2层既实现了智能诊断和优化建议又保留了实时控制层的稳定和安全。这个方案最后顺利上线客户满意度也高因为产线的良率确实提升了。3.2 人机协同才是当前最务实的落地方式很多客户一听“Agent不能直接控制设备”就觉得很失望但我觉得这才是真正的机会所在。Agent在实时控制的“外围”有一大堆用武之地比如工艺参数的智能推荐Agent读取历史生产数据分析不同参数组合下的良率表现输出建议配方。异常工况的诊断与处理预案Agent监测到报警后快速检索操作手册和历史案例给操作员呈现可能的原因和处置步骤。预测性维护建议Agent结合振动传感器、温度、电流等特征推断设备健康状态给出维护计划。生产排产的实时优化Agent根据订单交期、设备状态、物料库存等因素动态调整生产优先级。这些场景有一个共同点就是决策时间是秒级、分钟级甚至更长且决策结果可以由人来确认后再执行或者由L2层的优化控制器去执行。Agent在这个模式下不是一个“控制执行者”而是一个“辅助决策的大脑”。我自己的经验是在落地任何工业Agent项目之前一定要先定义清楚“AI不能碰的东西”。通常我会和客户列一个清单明确哪些回路是绝对不允许Agent干预的比如安全联锁回路、急停回路、核心张力控制回路。然后再列出Agent可以自由调用的范围比如辅助告警分析、报表生成、排程建议。这个边界越清晰项目实施越顺利客户的信任度也越高。4. 从“伪命题”到“真命题”的探索路径4.1 什么条件下Agent才能逼近“实时”当然我也不是全盘否定“实时控制的工业Agent”未来实现的可能。如果你非要往这个方向走有几个技术路径是可以探索的小型化专用模型把通用大模型蒸馏成非常小的专用模型只处理特定控制场景的决策。这类模型参数量小、推理快部署在边缘侧延迟可以压到10ms以内。专用推理硬件用FPGA或ASIC做专用加速将Transformer的前向推理延迟压缩到“亚毫秒”级别。这个方向研究界已经有进展但距离工程化推广还有距离。分层混合架构让实时控制仍然由PLC/DSP执行但Agent作为“降级模型”驻留在边缘侧通过白名单方式只允许输出特定类型的参数调整量并且必须在PLC侧经过可行性校验后才会生效。这种架构下Agent即便偶尔出问题也不会直接导致设备失控。强化学习与动态规划结合用强化学习预先计算最优控制策略库Agent在运行时只需查表匹配而不是现场推理。这个思路本质上把“大模型推理”变成了“知识库检索”实时性有了保障。以上几条路线我都在不同场合跟同行讨论过。说实话除了“分层混合架构”其他几条都还在实验室阶段或者试产阶段距离大规模工业应用还有不少路要走。4.2 给从业者的实用建议别跟物理规律对着干最后分享几个我自己踩坑踩出来的经验希望能帮正在做技术选型的各位少走弯路第一选型时不要被概念迷惑。“实时控制”和“Agent”如果真的要在同一个系统里出现一定要想清楚时间边界实时部分的核心周期是多少、Agent的决策可以被延迟多少容忍度。第二把安全放在首要位置。任何Agent输出如果要对设备做动作至少要在执行链路上加一道硬逻辑判断。这个判断可以是PLC里的区间检查、速率限制、互锁条件等绝不能省。第三先从“非实时决策”场景切入。如果你所在的企业想试点工业Agent强烈建议从工艺优化建议、报警辅助分析、预测性维护这些场景开始既能快速见效果又不会惹出安全事故。第四实时性与智能性的融合大概率是长期渐变的过程。不要指望一蹴而就但也不要因为“Agent不能直接做实时控制”就否定它的价值。它在控制金字塔的上层能干的事情一点都不少。我自己最近接手的一个项目就是在DCS上做了一个“智能操作指引”模块Agent会在关键参数越限时给出三步处置建议操作员确认后执行DCS侧有完善的报警死区和联锁保护这套系统的上线率很高运维人员反馈也积极。这件事再次印证了我的判断把Agent当成“副驾驶”而不是“驾驶员”才是当前工业智能化最正解的姿势。未来的某一天也许专用的实时推理硬件真的能把Agent塞进电流环里但那一天肯定不是现在。在那之前我们这些工程人还是要脚踏实地先把手头的确定性系统守住再去谈更宏大的智能化愿景。
