工业Agent无法取代实时控制：真正的落地场景在哪？

1. 我的判断这不是技术演进是概念错位最近几个月工业Agent这个词的出镜率高得吓人。但凡哪个大模型厂商搞一场发布会不提一嘴用大模型做工业控制好像就落后于时代了。更夸张的说法我也见过不少——什么实时控制的工业Agent已经落地LLM 直接发指令给 PLC毫秒级响应诸如此类。我一个做工业自动化和边缘计算超过十年的人看到这些宣传语的时候第一反应不是兴奋而是困惑紧接着是头疼。不是我不愿意拥抱新技术。大模型在工业领域的潜力我承认而且我认为应用前景非常大。但实时控制这四个字和Agent这个架构目前放在一起确实是个伪命题。这个伪命题不在于技术本身无用而在于我们把两个完全不同时间尺度、完全不同确定性要求的系统硬生生捏在了一起。要理解我的判断先别急着聊大模型也别急着聊什么智能体框架。得先搞清楚一个核心问题——工业上说的实时到底意味着什么。如果连这个基准都没对齐那实时控制的工业Agent就是彻头彻尾的空中楼阁不管前面的定语堆得再多。写这篇文章我不打算给谁泼冷水也不想显得自己守旧。我只想用最朴素的工程逻辑拆一拆这个命题到底哪里出了问题顺便聊聊工业 Agent 真正能落地的位置在哪里。给那些正在被各种宣传话术轰炸的工程师、技术决策者一个参考坐标系。2. 先对齐概念工业实时控制到底是什么级别的硬约束2.1 PLC 的扫描周期不是响应快而是确定性锁定很多人一听到实时控制第一反应是延迟越低越好。这其实是个误解。低延迟是必要不充分条件真正的核心要求是确定性——也就是说某个任务的完成时间必须是可预测的最坏情况下的执行时间是已知且有上界的。拿最经典的 PLC 循环扫描来说。一个中端 PLC 的扫描周期通常设置在 1ms 到 10ms 之间。什么意思就是 PLC 从采集输入信号开始到执行用户程序再到更新输出信号整个过程必须在一个固定周期内完成。你设置 5ms它就每 5ms 必须跑完一圈。跑不完怎么办不是等下一拍而是报警、停机因为这意味着控制时序已经乱了。这里有个关键点很多人没意识到PLC 对程序执行时间是有严格预算的。工程师在写梯形图或 ST 代码时心里得估算这段逻辑大概占几个毫秒那部分逻辑又占几个毫秒。整个扫描周期的执行时间必须在一个确定范围以内不允许出现这次跑得快、下次跑得慢的不可控波动。这种设计不是保守而是工业现场的物理规律决定的——电机要在准确的时间点换向阀门的开度要在精确的相位更新伺服轴的插补计算差一个毫秒都可能撞机。2.2 伺服控制和运动控制微秒级的战场如果说 PLC 的扫描周期是毫秒级那运动控制就是另一个量级的游戏了。以伺服驱动器的电流环控制为例典型周期是 31.25μs 到 125μs也就是微秒级别。速度环和位置环通常在 250μs 到 1ms 之间。这意味着在每一个微秒级别的时间片里控制器都得完成当前电流的采样、坐标变换、PID 计算、PWM 占空比更新。这不是什么高精尖实验室的东西这是今天任何一台稍微像样一点的 CNC 机床、注塑机、包装机都在跑的基础逻辑。伺服驱动器为什么用 DSP 或者专用运动控制芯片而不是用一颗通用 CPU 跑 Linux因为通用操作系统根本没办法保证微秒级的时间确定性——线程调度延迟、内存访问抖动、缓存未命中随便一个干扰都能让你的控制周期闪一下。2.3 工业现场对确定性的执念不是强迫症有人可能会说你是不是把工业控制说得过于玄乎了很多场景也没那么严苛吧没错确实有相对宽松的场合。比如一些过程控制温度、压力、液位调节时间常数大PID 控制的采样周期做到几百毫秒甚至一秒都是没问题的。但请注意即便是这些看起来慢悠悠的控制回路对执行时间的上界依然有明确要求。你可以设计成 500ms 采样一次但绝不允许出现有时 300ms有时 900ms这种随机波动——因为控制系统在工程上是按最坏情况来分析和整定的。一旦执行时间不确定控制器的稳定裕度就无从谈起。这个确定性执念是整个工业自动化大厦的地基。只有在这个地基上工程师才能放心地把一个回路交给控制器去闭环才能通过仿真、整定、验证去保证系统稳定。实时控制系统的本质不是快而是可证明地及时。这句话值得全文加粗。那么这个可证明地及时Agent 这架构能做到吗答案在下文。3. Agent 的模型内核决定了它天然活在秒级以上的世界3.1 一次推理的时间账不是模型慢是架构慢前面说了工业实时控制的时间尺度是毫秒级到微秒级。那现在看看大模型 Agent 完成一次感知-决策-行动的循环要多久。这里我不用理论值直接说实测。一个中等规模的工业场景假设你用一个部署在边缘服务器上的大模型来做设备状态的实时判断。模型参数量姑且算 7B 级别这已经不算大了。用当前的 AI 加速卡推理一次大概要多少时间如果输入输出都是简短的文本生成 100 个 token 左右实测也要 200ms 到 500ms还得是状态比较好的时候如果这个过程里需要调用工具比如查一个历史数据库、读一段设备日志那还得加上工具执行的时间如果 Agent 还要做多步规划先分析、再决策、再生成指令那整体延迟奔着 2 到 5 秒去了。有人会说那我用更小的模型比如蒸馏过的 1B 模型部署到高性能边缘设备上是不是就能进毫秒级实测下来小模型的延迟能降到 50-100ms 左右看起来挺快了。但请注意这个 50ms 只是模型单次前向推理的裸延迟。如果 Agent 需要拿到结果、解析、再通过 OPC-UA 或者其他协议写入 PLC 寄存器这个链路总延迟至少再加 10-20ms。而且关键是这 50ms 是期望值不是上界。3.2 问题的真正根源LLM 是非确定性系统比延迟更致命的问题是不可预测性。你让同一个大模型在完全相同输入下跑两次得到的结果可能有细微差异。这受采样温度参数的影响也受模型本身的随机性影响。你可以在工程上设置温度为 0 来提高确定性但即便温度是 0由于浮点计算和推理后端的微小差异输出依然不能完全保证逐位一致。而工业实时控制最不能接受的是什么恰恰是不可预测的输出。一个 PID 控制器给同样的输入每次必须给出完全一样的输出。这是闭环稳定性分析的基础。如果你用一个 Agent 去直接替代这个 PID 的角色每次计算得出的控制量都不一样哪怕只是差 1%控制系统也无法通过稳定性验证。更不用说一旦模型推理出现幻觉生成了一个不在预设范围内的控制指令这在工业现场意味着什么——轻则废一批料重则设备损坏甚至人身安全问题。很多宣传话术说我们给 LLM 加了规则约束输出格式是强约束的JSON Schema 验证、代码截断不会产生非法指令。这个说法有一定道理但只解决了格式合法的问题没有解决语义正确的问题。格式合法不等于控制指令合理——同一个合法格式的输出在设备工况 1 下是安全的在设备工况 2 下可能就是灾难性的。这个语义正确性恰恰是统计语言模型在数学上无法保证的。3.3 服务质量相变工业现场不存在偶尔卡一下还有一个被宣传材料刻意回避的问题大模型服务的性能波动。传统控制软件你给它一个固定周期的任务它的执行时间波动通常在微秒级或几毫秒以内。但大模型推理的性能波动是几十毫秒到几百毫秒的级别。GPU 频率调度、显存带宽竞争、并发请求排队——任何一个因素都可能导致单次推理时间突然翻倍。在 IT 场景里这种性能波动最多让响应卡一下用户刷新页面就完了。可在工业实时控制场景里卡一下意味着 PLC 在这一个周期内拿不到新的控制指令那它只能走安全路径——停机保护。那整个产线就会频繁启停。这是任何一个工厂都无法接受的生产状态。所以说Agent 架构的延迟上界是不可控的。实时控制系统的核心要求恰恰是上界可控。这俩从根上就不匹配。4. 三句流行话术是怎么偷换概念的4.1 把大模型部署在 PLC 旁边延迟不就低了吗这是最常见的说法听着似乎很有道理既然网络延迟高那把模型直接装在工控机上离 PLC 只有一条网线的距离延迟自然就下来了。这个说法偷换了一个关键概念——部署位置近不代表执行时间可控。推理的延迟大头在模型计算本身不在网络传输。你就算把 GPU 贴在 PLC 隔壁一次 7B 模型的推理延迟依然要几百毫秒。这个时间不取决于是本地部署还是远程部署取决于模型参数量、计算密度和算子优化程度。就算你硬上小模型把裸推理延迟压到 30ms那也只是快不是确定。控制环路关心的最坏情况延迟不会因为你把盒子搬近了就变小。搬近了只是降低了平均延迟而没有收缩尾延迟的上界。4.2 配合 RAG 和知识库Agent 能做出更聪明的控制决策这句话比上一个更离谱因为它把控制决策和基于知识的推理混为一谈了。RAG 的价值在于为模型提供更好的背景知识让回答更准确、更有依据。这在故障诊断、运维问答、工艺建议等场景里确实有显著价值。但 PID 参数整定、伺服插补、相位补偿这些控制算法需要的不是知识渊博而是数学上的精确计算。你给一个 PID 控制器喂再多的设备手册、工艺文档它该算出的增益还是那组增益不需要引用任何文档。反过来说如果一个人说根据某本手册的知识我把某个控制参数调成了某某值那这个知识根本不经不起闭环系统的严格验证。控制工程的推理链条是数学和物理的不是语义和知识的。RAG 解决的是语义层的问题控制环解决的是数值层的问题。这两者可以协作但把 RAG 描述成让实时控制更智能纯属术语嫁接。4.3 工业 Agent 替代传统控制算法是趋势这句话是最危险的一种话术。因为它把替代说得轻描淡写。传统控制算法PID、MPC、鲁棒控制、自适应控制等最核心的价值不只是算得快而是建立在严密的数学基础上且经过了数十年的工业验证。它们是可分析、可证明、可复现的。你可以用数学方法证明一个 PID 回路在什么条件下稳定可以在设备出厂前通过形式化方法验证一个安全逻辑不会在故障条件下误动作。一个基于大模型的概率推理系统目前没有任何数学工具可以证明它在所有输入条件下的行为边界。你说它是趋势趋势不是这么定义的。趋势是从经验走向可证明而不是从可证明退回经验。5. 那工业 Agent 到底能干什么我的建议是控制之上决策之旁完整否定掉实时控制的工业 Agent这个伪命题之后我想认真聊聊——工业 Agent 真正能发挥价值的地方在哪里。这个问题我在多个实际项目里反复验证过结论比较稳定不要试图让 Agent 进入控制环要让 Agent 站在控制环上方和旁边。5.1 控制环上方全局调度与生产排程层面的优化控制环负责把每一个回路稳定住Agent 负责在更高的维度协调这些回路之间的关系。举例说明。一条有多工序的生产线每个工序都有自己的 PLC 控制系统。正常情况下各工序按预设节拍独立运行。但实际生产中会出现各种异常上游工序设备故障、来料延时、某台设备突然报警停机。这时候需要有人或者系统快速判断当前这个订单是否要改排程哪台设备的产能缺口可以由其他设备补上原料分配比例怎么调整最合理这种决策的特点是时间尺度在分钟级到小时级甚至更长涉及的因素非常复杂需要结合订单信息、设备状态、库存、能耗等大量数据决策结果不直接写入伺服电流环而是更新到 MES 或调度系统的计划表里。这正是 Agent 的舒适区。它有足够的时间去调用工具、查数据、做多步推理也不需要毫秒级的确定性响应。就算偶尔某次决策不是最优解也有充足的时间让人工介入修正。我在一个汽车零部件生产线的数字化项目里尝试过这种架构底层 PLC 控制不变把 MES 层的排程决策逻辑部分替换成 LLM Agent 的调度助手。实测下来人工排程的时间从平均 40 分钟缩短到 10 分钟以内而且应对紧急设备变更时的响应速度明显快了。代价是 Agent 偶尔会给出不够合理的排程建议但因为有预案库兜底人工审核一下消耗的时间远低于从零排一次。5.2 控制环旁边设备状态诊断、预测性维护和知识问答另一个非常适合 Agent 落地的场景是设备运维。工业设备都会产生大量数据振动、温度、电流、压力、运行时长、报警记录、维护日志。传统的做法是运维工程师盯着 SCADA 画面看趋势、查报警、翻手册。这套模式的问题在于严重依赖个人经验和记忆设备种类一多知识就分散在不同人的脑子里难以结构化复用。Agent 在这里的做法是接入设备数据平台遇到异常指标时自动拉取相关历史曲线、查询对应手册的故障章节、参考过往的维修记录然后生成一份诊断建议维修步骤备件需求的报告。运维工程师不需要自己去翻三个系统查数据了。这个场景里Agent 的实时性要求是秒级到分钟级不需要毫秒级。而且关键的是输出结果本身就是给人看的天然可以迭代和验证——工程师发现诊断建议不对可以指出来修正。人作为最終决策者Agent 只是放大人的信息处理带宽。这才能最大程度发挥大模型的长处。5.3 控制环以内的假实时陷阱为什么我不建议妥协有些人不死心那我能不能做个折中Agent 不做最底层的电流环只做 PLC 扫描周期之外的那个层面的调节比如说让 Agent 每 1 秒钟重新计算一次某个温度回路的设定值然后让底层的 PID 去跟这种设定值建议模式在技术上是可以做的。但我要特别提醒一个陷阱这个方案看起来像实时控制但它的价值边界很微妙。因为设定值本身就是工艺工程师精心设计的结果Agent 调整设定值意味着它介入了工艺逻辑。一个工艺设定点改动的背后往往是材料特性、能耗、质量指标的综合权衡如果 Agent 只是基于统计相关性给了一个建议而没有经过严格的工艺验证这个建议出错的代价最终会落在产品质量上。所以我的建议是如果 Agent 给出的建议是给人看的随时可以介入随时可以否决那它就有价值如果 Agent 给出的建议要自动写进控制器的设定值寄存器那就一定会遇到验证和担责的问题。在没有成熟的验证框架之前不要轻易跨过这条线。6. 真要往实时靠只有一条路模型必须不参与实时决策最后说说我对技术演进方向的判断。有些方向有可能让 Agent 更接近实时场景但有一个前提——模型本身不能成为实时决策路径的一部分。一个比较务实的路径是用传统算法或规则引擎作为实时的决策主体大模型在后台批量分析历史数据、离线生成和优化规则库再把这些规则部署到边缘端的轻量执行引擎里。换句话说是用模型的离线智能去持续优化在线规则的库而不是让模型在线去推理。这个思路在工业界有个现成的名字——知识蒸馏但蒸的不是模型权重而是决策行为。举个例子供水管网的压力控制。传统做法是每个泵站本地 PID管网的全局协调靠 SCADA 中心离线算模型。假设你引入 Agent让它每天读一次全天历史数据分析管网压力分布、预测未来几小时的用水需求然后生成一组新的泵站压力设定参数下发给各泵站的 PLC。模型离线算、PLC 在线执行。这种模式里Agent 的推理时间再长都没关系因为真正的实时路径上还是 PLC 和 PID。但系统的整体效果会因为 Agent 每天调教一次而逐步优化。这条路的优势是实时环路的确定性没有被破坏AI 的优化能力又确确实实地进入到了生产控制系统里。我认为这才是工业界和大模型结合的务实方向。那些动不动就说LLM 直接控制机械臂的要么是实验室 Demo 不敢上产线要么是把观众当外行。Demo 和产品之间的鸿沟就是确定性、安全性和可验证性这三条不解决永远只能停留在演示层面。回头看我说实时控制的工业 Agent 现在是伪命题并不是否认 Agent 在工业领域的未来恰恰相反正因为我看好它在非实时层面的价值才不愿意看着这个话题被话术消费。工程师最需要的是清晰的分类法——什么场景能用、什么场景不能用、用了会有什么后果。这比追逐概念本身重要得多。