★ FEATURED ARTICLE 刷行业资讯的时候我频繁看到“实时控制的工业Agent”这个说法。一边是大模型Agent的能力红得发紫一边是工业自动化的“实时控制”四个字自带光环两者拼在一起听起来就像给工厂装上了钢铁侠的贾维斯。我在控制系统和大模型落地两头都长期折腾过每次看到这种提法都要在心里嘀咕一句大家嘴里的“实时控制”跟PLC工程师脑子里的“实时控制”大概率不是一个东西。所以这篇东西先把我的结论摆出来以当前大语言模型LLM为核心的工业Agent想在产线级实时闭环控制里直接当执行者既不经济、也不安全、更不现实。这不是说Agent在工业里没用而是说“实时控制”这个帽子扣错了。这篇文章适合正在做工业数字化转型、大模型落地的工程师和产品经理看也适合被领导布置了“研究一下工业Agent”任务的朋友。我会把概念边界、技术原理、落地位置和踩坑实录一次讲清楚尽量少说黑话。1. “实时控制的工业Agent”这个概念是怎么火起来的1.1 三条技术线在同一个路口汇合这个伪命题不是凭空冒出来的是好几股技术趋势撞在一起撞出了一个看起来很合理的幻象。第一股线是大模型Agent的成熟。2023年以后以LLM为核心的Agent从“只会聊天”进化到“会调工具、会规划任务、会读文档”Function Calling、RAG、多智能体协作这些组件逐渐变得稳定。做工业的人一看既然Agent能调用API、能读数据、能写SQL那让它去读DCS的数据、去改PID的设定值似乎也就是多接几个接口的事。第二股线是OT与IT的融合。工业互联网、边缘计算、设备上云这些项目搞了快十年OPC-UA、MQTT、Modbus TCP这些协议把越来越多的设备数据送到了数据平台和云端。数据打通了大家自然会想能不能在上面跑一个更聪明的“大脑”第三股线是老师傅经验的流失。产线调试、异常处理、工艺参数调整这些活儿极度依赖人的经验而经验丰富的老工程师正在退休。企业焦虑之下会把“把老师傅装进系统里”当成一个刚需而Agent看起来正好是那个能把经验变成对话和行动的容器。这三股力量叠加让“用大模型控制产线”成为一个非常性感的故事。但性感归性感拆开看全是问题。1.2 “实时控制”这个词被悄悄换了个定义问题首先出在“实时控制”这四个字上。在工业自动化领域“实时控制”是有严格量级含义的。普通PLC的扫描周期通常是10毫秒到100毫秒运动控制器的插补周期是1毫秒甚至更低DCS的控制回路典型周期也在百毫秒量级。所谓实时是指系统必须在确定的时间窗口内完成采样、计算、输出错过一个周期就是事故。化工装置的压力联锁、电机的位置闭环这些场景对“晚10毫秒”都是零容忍的。但宣传里的“实时控制”完全是另一个画风。很多演示视频展示的所谓实时不过是Agent在几秒钟内给出了建议或者通过流式输出让你感觉它在“即时对话”。对做控制的人来说这就好比把“能在一分钟内报出菜价”的大堂经理说成“能每秒调整餐厅空调温度”的楼宇自控系统——听着都是“及时”量级差了十万八千里。这种偷换概念是整个伪命题的根源。大家不在同一套定义下讨论问题于是甲方觉得“已经能实时控制了”乙方觉得“我只承诺了辅助建议”做安全评审的人则一脸茫然。2. 延迟、不确定性与安全实时控制给Agent立了三堵墙2.1 延迟这一关当前架构就迈不过去很多人觉得延迟是个单纯“优化一下就能解决”的问题实际情况远没有那么简单。我按最常见的落地链路算一笔账。假设Agent要完成“读取当前温度→判断偏差→计算新的设定值→把设定值写回控制器”这个动作。一次完整调用的链路大概是用户/触发器唤醒模型模型理解任务并发起工具调用工具请求通过工业网关去读实时数据库或DCS点位数据回来后交给大模型进行推理生成输出再把输出通过网关写入控制器。这里面仅大模型单次推理在中等规模的模型上就普遍需要500毫秒到2秒。加上工具调用解析、网络往返、数据查询整条链路的端到端延迟很容易做到3到8秒如果遇到排队或者上下文过长十几秒也是常事。而一个典型的温度控制回路其控制周期是500毫秒流量控制是100毫秒伺服运动控制是1毫秒。让一个平均延迟几秒的Agent去插入到这些回路里这不是“快一点就行”的问题而是整个时间尺度就不匹配。用一句行话说Agent的时代常数比被控对象的时代常数大好几个数量级反馈回路根本稳定不了。就好比让一个反应时间2秒的人类去接时速200公里的发球理论上不是不可能但身体结构就不支持这个玩法。2.2 不确定性与不可证明性控制系统最不能忍的毛病延迟只是最表面的问题更深层的问题出在确定性上。传统实时控制系统能稳定运行几十年靠的是确定性同样的输入在同样的条件下永远产生同样的输出。PID控制器的代码是确定性的联锁逻辑是确定性的整个控制器的行为可以被证明。即便外部扰动千变万化工程师也能依据数学模型分析稳定性能给出“在什么条件下系统一定收敛”的结论。大模型在这件事上是完全的反面。它的推理本质是从概率分布里采样哪怕用固定的温度参数输入里一个标点符号的变化、上下文里多了一句无关的对话都可能让输出结果改变。你无法从数学上证明一个Agent在任意扰动下不会给出一个荒谬的控制量。工业现场最怕的不是“能力不够”而是“偶尔抽风”。一台设备可以接受性能差一点但绝不可能接受“大多数时候正常、偶发一次越限”。这个偶发在实时控制里就是安全事故。更麻烦的是控制系统的安全认证体系——比如IEC 61508里讲的功能安全SIL等级——要求控制逻辑是可验证、可追溯、可测试的。你把一个不可证明的LLM放进控制回路里整个系统的失效率模型都没法建立SIL认证直接无从谈起。这不是“多写点测试”能解决的是方法论层面的不兼容。2.3 安全责任边界出了事算谁的实时控制还有一个经常被忽略的问题责任归属。传统控制系统的逻辑是人写的代码可审查行为可预测出问题可以由工程师定位、修改、验证。Agent系统则是一个“半自主”的决策体如果它在某个异常工况下自行修改了工艺参数导致设备联锁甚至停产这个责任怎么划分是模型厂商的责任是配置人员的责任还是操作员没能拦住它的责任目前没有任何成熟的法律和行业规范来回答这个问题。我在和一些工厂的安全部门聊的时候他们普遍的第一反应不是“这技术行不行”而是“这东西如果被恶意攻击怎么办”“如果它自己改了设定值怎么办”“怎么证明它在任何情况下都不会绕过安全联锁”。这些问题目前在技术层面都拿不出让人放心的答案。2.4 一张表看清“实时控制要求”和“大模型现状”的差距关键维度实时控制系统的要求当前LLM Agent的现状响应延迟毫秒级1-100ms秒级常为500ms-10s时间确定性硬实时周期抖动可测无法保证受排队和负载影响行为确定性相同输入相同输出可复现概率生成输出不稳定可证明性稳定性、收敛性有数学证明黑盒无法形式化验证安全认证SIL等功能安全体系可认证尚无成熟认证路径故障责任逻辑可追溯责任清晰模型决策难以举证与追责这张表看完你就会明白这不是“大模型再努力一把就能补上”的差距而是底层范式根本不在一个频道上。3. 那工业Agent现在到底能干什么3.1 能落地的所有不直接闭环的辅助智能泼完冷水我反而要说Agent在工业领域不仅有用而且潜力很大只是用错了地方。目前真正能稳定落地的场景清一色都是“辅助人做决策”而不是“替代系统做执行”。知识检索与运维问答是最好落地的方向。把设备手册、历史维修记录、工艺操作规程、故障代码表灌进知识库工人遇到报警时直接问“F123报警是什么含义、上次是怎么处理的”Agent能给出比翻手册快得多的答案。这不是控制是知识管理安全风险低效果明显。报警分析与根因辅助也很有价值。把DCS或SCADA的历史报警序列、工艺数据喂给大模型让它总结“最近的报警集中在哪个区域、哪个参数频繁越限、可能的关联原因有哪些”可以显著缩短老师傅排查问题的时间。注意Agent给的是假设和方向最终的判断和操作仍然由人来完成。还有排产优化建议、工艺参数解释、PLC代码辅助生成、质检误判复核这些场景本质上都是“慢决策”或“人机交互”。它们共同的特点是出错可以被人工拦截不需要毫秒级响应不直接触碰执行机构。3.2 不能做的直接写设定值、改联锁、在线调参反过来给我再多预算我也不会做下面这类事让Agent直接修改PID回路的设定值让它去改写联锁逻辑让它在工况波动时在线调整阀门开度或者让它直接触发安全停机的恢复流程。这些动作的共同点是毫秒级闭环、高安全风险、输出必须绝对确定。Agent在这三个条件里一个都不满足。我见过一个典型的把“辅助”包装成“控制”的Demo界面上有一个大模型对话框操作员输入“把反应釜温度控制在80度”Agent回答“好的”然后真的去改写了温度控制回路的设定值。诚然设定值确实变了看起来很智能但一旦外部扰动来了回路振荡了系统并没有因为“这是Agent控制的”而多一层保护。本质上它只是把操作员本来要点的那个按钮换成了一段不可靠的代码来点。那不是控制能力那是风险转移。3.3 区分“伪命题”和“真命题”的一条标尺讨论到这里我觉得有必要给“实时控制的工业Agent”下一个精确的判词。伪命题的部分是宣称用LLM做核心决策器去替代或插入实时闭环控制回路中的采样、计算、输出环节在毫秒到百毫秒级别直接响应外部扰动。这个从现在到可预见的未来都行不通。真命题的部分是用Agent去辅助控制回路之上、时间尺度在分钟、小时甚至天级别的优化与调度决策。比如设备健康状态评估、批次生产参数推荐、工艺优化建议、操作规程生成。这些场景对秒级延迟完全无感对“偶尔不准确”也有人工兜底。所以问题的关键不是“Agent能不能进工业”而是“Agent站在什么位置”。站在数据与人的中间它是利器站在控制器和执行机构的中间它是隐患。把这句话背下来你就能识别市面上80%的伪需求。4. 如果非要往“准实时”靠有哪些折衷可走4.1 把Agent放在慢回路上而不是快回路上控制系统的经典分层里本身就分快回路和慢回路。底层是PID、顺序控制、联锁保护这类快回路秒级甚至毫秒级动作上层是优化控制、调度排产、批次管理这类慢回路分钟级到小时级调整。Agent如果能做位置一定是慢回路。比如一个批次的反应过程有120分钟Agent可以在每个执行阶段结束后读取实际过程数据对比工艺曲线给出下一个阶段的参数建议。这个建议由操作员审核后执行或者经过规则引擎校验后自动下发。在这种时间尺度下Agent的几秒延迟根本不算事它的推理能力反而能派上用场。这个方案的核心逻辑是把大模型的“智能”用在它擅长的地方把传统控制系统的“确定性”用在它擅长的地方。各干各的事而不是让大模型去干传统控制的活。4.2 给Agent加一道“规则校验网关”如果企业觉得“建议→人工确认”还是太慢想提高自动化程度我强烈建议在Agent和控制器之间加一层硬性的规则校验服务。这层服务不用大模型用传统代码实现职责只有一个对Agent输出的所有操作指令做合法性检查。检查项目包括数值是否在工艺允许范围内变化速率是否超过限制当前设备状态是否允许该操作操作是否违反互锁条件。任何一条不满足指令直接拦截并记录日志。我给出一个非常简单的校验逻辑示意方便理解这个思想def validate_setpoint_change(device_id, target_sp, current_sp): limits get_limits(device_id) # 从配置中心读取安全边界 max_rate get_max_change_rate(device_id) if target_sp limits.min or target_sp limits.max: return False, 设定值超出工艺安全范围 if abs(target_sp - current_sp) max_rate: return False, 设定值变化速率超过限制 if is_interlocked(device_id): # 检查互锁状态 return False, 当前设备处于互锁保护状态禁止写值 return True, 允许执行别看这个函数简单它是Agent能往闭环方向多走一步的唯一保障。没有这层保障Agent的输出再聪明也不能被信任。它的本质是把“可能性”翻译成“约束”把大模型的自由裁量权关进笼子里。4.3 小模型干快活大模型当翻译另一个经常被人忽略的方向是“把实时任务留给专用小模型”。很多“实时智能”任务根本不需要大语言模型。比如振动信号的异常检测、视觉质检的缺陷定位、时间序列的超早期预警这些任务用传统机器学习或小模型就能做到毫秒级推理。大模型真正的价值是把检测结果翻译成人类能理解的描述结合上下文给建议。典型的混合架构是边缘侧部署一个轻量级时序模型实时计算设备健康分数一旦发现异常立即输出数值告警并触发快回路保护同时把异常数据和上下文发给云端的大模型Agent由Agent生成一份“可能原因分析和处理建议”发给值班工程师。这样实时部分由确定性的小模型扛住智能部分由大模型负责两边都在自己的舒适区。这种架构现在已经有不少成熟案例它比“一步到位用Agent控制设备”靠谱得多。4.4 先做“人机协同建议闭环”这是当下最稳的边界如果企业一定要上Agent我最推荐的不是自动化而是“半自动化”。具体做法是Agent跑在实时数据之上持续监控工艺参数和状态发现偏差时主动生成控制建议通过大屏或移动端推送给操作员操作员在确认建议并点击“执行”后系统才把指令下发到控制器。整个过程有完整的操作日志Agent建议了什么、操作员什么时候确认的、最终执行了哪个值全部留痕。这套方案的价值在于既享受了Agent的智能辅助又把最终决策权留给了有资质、有责任的人。从安全合规的角度看这是目前唯一站得住脚的形态。很多工厂实际跑下来也发现操作员很欢迎这种模式——它不抢话不越权只在旁边提建议像一个随时待命的助手。我个人的经验是在没有SIL认证路径、没有成熟监管框架之前人机协同就是工业Agent不可逾越的红线。凡是敢吹“完全自主实时控制”的供应商你让他现场把安全责任写到合同里他大概率会开始改口。5. 现场踩坑记录几个我不想隐瞒的翻车现场5.1 一个调温Demo的翻车全程前两年我参与过一个“Agent智能控温”的PoC项目目标是让Agent根据工艺要求自动调整反应釜温度设定值。前期做得很顺模型在历史数据上表现得很好演示环境里也能稳稳把温度控制在目标值附近。但一上到真实生产线问题立刻暴露。真实工况下夹套蒸汽压力会波动、进料温度会波动、搅拌速率会变化。传统PID通过高频反馈一直在对抗这些扰动而Agent只有在工艺参数偏离到一定程度后才会被触发模型一推理就是好几秒等它给出新的设定值扰动已经演变成了超调。结果就是画面很搞笑PID本来把温度控制得挺好Agent一插手反而把曲线弄得乱七八糟。这个项目的教训让我想明白一件事很多做AI的人把“设定值控制”当成“温度控制”殊不知真正的控制是底层的PID闭环在每一毫秒的对抗扰动中完成的。Agent以为自己在控制其实它只是在给一个已经工作得很好的系统添乱。5.2 Token延迟和成本带来的“体感暴击”还有一个我觉得做技术的人容易忽略的问题就算技术上能通人也不一定能用。我们在一个工厂试点“报警根因分析Agent”时原本规划得很好DCS报警后Agent自动拉取上下文生成分析报告。但现场网络是工业环网跨网段去调数采接口经常不稳定模型服务部署在数据中心一次完整分析要跑5到10秒。值班电工反馈说等Agent的分析出来他的应急操作早就做完了他还要额外花时间读报告反而是负担。更现实的是成本。大模型的调用成本在线下试点里可能不算什么但如果一个工厂一天产生数千条报警每条报警都要让Agent去分析Token消耗瞬间就变成一笔不可忽视的开支。你不得不开始思考这个钱花下去到底换回了多少可量化的收益所以我现在的判断标准很朴素一个Agent功能如果不能让现场的人“省力”或者“省心”它再智能也是摆设。先解决“有没有人愿意用”再谈“技术高不高级”。5.3 OT数据权限和安全策略的现实铁壁还有一个所有想接工业数据的人都会撞上的墙——安全审批。想要让Agent实时读取DCS的工艺数据通常要通过OPC-UA或专门的数采网关这需要开放生产网到管理网的数据通路。而很多工厂的安全策略是生产网严密隔离跨网通信要过防火墙、经过审批、做安全评估。我和不少甲方聊过即便技术方案完全可行安全部门也会反问一旦Agent所在的服务被攻破攻击者能通过这个链路打到DCS吗这个问题在传统架构里可以通过单向网闸、白名单机制缓解但Agent系统要频繁双向交互天然跟“单向隔离”冲突。最后的结果往往是项目在技术演示阶段很顺利一到安全评审阶段就卡壳然后被无限期搁置。我提醒所有做工业Agent的朋友项目启动前先花两周把安全边界这事谈清楚别等技术都做完了才发现数据通路根本批不下来那就要返工了。5.4 关于SIL认证别被话术带偏最后再说一个容易被话术忽悠的点。我见过一些厂商宣传自己的AI控制系统“符合SIL认证要求”听上去很唬人。但真去研究你会发现SIL认证针对的是确定性的功能安全逻辑比如一个安全PLC里面的急停回路、联锁逻辑。它的认证过程要基于失效率、诊断覆盖率这些可量化的指标。你拿一个概率模型去参与认证连“失效率”怎么定义都说不清楚更别提认证了。目前行业里确实有在讨论AI与功能安全的交集但相关标准还在摇篮期没有任何一家厂商能够拿出“LLM控制回路”的完整认证案例。如果有人跟你说他的Agent已经拿到了SIL认证你可以直接请他出示认证证书和适用范围多半会看到证书上的范围根本不包括大模型决策部分。这件事给我的启发是别把宣传当现实也别把Demo当产品。工业采购是要签安全责任协议的不是看发布会。6. 最后分享一点我的个人判断踩了这么多坑之后我对工业Agent的态度反而越来越清晰我不反对Agent进工业我反对的是把Agent包装成“实时控制大脑”。未来我觉得真正能走通的路是“大模型做人机界面小模型和传统控制做执行规则引擎做安全边界”。大模型负责理解、解释、建议让操作员知道发生了什么、应该怎么办传统PLC/PID负责在毫秒级快速、确定性地执行规则网关负责拦住所有越界行为。如果你正在做一个工业Agent项目我给你的建议很简单先明确你要解决的是“决策辅助问题”还是“实时控制问题”。如果是前者现在就可以开工如果是后者换个思路吧别在这个伪命题上继续烧钱了。我一直觉得工业现场是一个不允许说谎的地方设备不会因为PPT好看就听话。做技术的人要有勇气把那些听起来很美、实际上站不住脚的概念拆穿。让Agent说话让PLC干活这才是现阶段最务实、最负责任的做法。
阅读完成 · 觉得有帮助？
