1. 这波工业Agent热潮，热得有点不对劲
最近一年，我接到的所谓"工业Agent"咨询，比以前任何一类AI话题都要多。有做化工的，有搞数控的，有做电池产线的，还有做水处理的。聊下来我发现一个规律：几乎每个人都相信，至少在畅想——让大模型直接接管现场控制，实现"实时决策、自动调节、无人工干预"。
我第一次听人说"实时控制的工业Agent"时愣了几秒，后来听多了，觉得不能再不当回事了。我的结论很直接：把"实时控制"和"工业Agent"这两个词焊在一起，在当下就是一个伪命题。这不是说Agent没用，而是"实时控制"这个定语，用错了地方。
1.1 从大模型到工业现场的"叙事迁移"
2023年大模型刚火的时候，大家的注意力还在写文案、写代码、对话问答这些通用场景。到了2024年，AI厂商们发现To C竞争太卷，开始往B端找故事，工业就成了那个最性感的叙事方向——市场大、痛点明显、故事性强。于是"工业大模型""工业副驾""AI工艺优化平台"轮番刷屏，到了2025年，"工业Agent"成了新的标准话术。
这些产品里有没有好东西？有。很多做知识问答、设备诊断辅助、报表生成的工具，实际用起来确实能省事。但问题也出在这里：厂商为了把故事讲大，几乎不约而同地往宣传语里塞"实时""自主控制""闭环决策"这类词。我见过某家很实诚的创业公司，原本产品是个报警分析助手，改版后的官网宣传语直接变成"毫秒级实时控制、AI自主调节工艺参数"。问他们"毫秒级"哪来的，答：我们的LLM在A100上跑一个小模型，单次推理能进50毫秒。
你看，这就是典型的叙事迁移——把"告诉操作工该怎么做"包装成"替代控制器去执行"。
1.2 "实时控制"这个说法，本身就是个模糊地带
搞控制出身的人听到"实时"，脑子里是一个相当严格的定义：在规定时限内完成响应，最坏情况（WCET）可证明，程序周期执行，行为确定。也就是说，实时控制的核心不是"快"，而是"确定性"和"有界时延"。
但圈外人说"实时"，意思基本是"挺快的""秒回""不卡"。
于是同一个词，在工程师耳朵里是"SIL认证的确定性控制回路，1毫秒扫描周期"，在管理层耳朵里是"大模型帮我盯着现场，出问题立刻响应"。两边聊得越high，对齐得越少。这就是为什么我说"实时控制的工业Agent"是个伪命题——一个句子里两个关键词，各说各话，严格量化之后根本构不成一个可成立的陈述。
2. 进不了控制环的三个硬底牌
2.1 非确定性：工业控制最不能容忍的毛病
传统控制算法——从PID到模型预测控制（MPC），核心前提是确定性：同样的输入，永远给出同样的输出。控制器可以抗扰动、可以有噪声，但它的策略必须是固定的、可复现的、可证明的。
大模型不是这样。大模型的输出是采样出来的，同一个Prompt，温度系数调一调，答案就换了；就算温度设为0，在不同批处理、不同浮点精度、不同上下文拼接方式下，输出也可能漂移。更关键的是，没有任何工具能给你一个"策略不变性"的证明。
放到控制回路里，这意味着什么？想象一个反应釜，温度稳定在95度，PID控制器每个扫描周期都按同一个公式算阀门开度。换成Agent之后，它在某个周期突然"觉得"该激进一点，阀门多开5%，可能就把反应推到了不可控区域。你用规则把它包起来？可以，但规则一旦兜底，真正做控制的就变成规则层了，Agent只是挂在旁边的装饰品。
我还见过更极端的说法："我们让Agent从历史最优控制曲线里学策略，再泛化到新工况。"问题是，工业控制里每个工况域都需要稳定性证明。你可以用李雅普诺夫方法证明一个固定策略在某个工作点附近稳定，但你没法对一个大模型策略在全工况域做同样的证明。这不是工程上难不难的问题，是数学上现在就不存在成熟工具。
2.2 时延预算：差了三到四个数量级
先用一段对比直观感受一下传统控制环和Agent"控制"的差异：
传统控制环：确定性的周期执行 while (true) { y = read_sensor(); // 读取传感器，微秒级 u = pid_compute(r, y, dt); // 计算控制量，微秒到毫秒级 write_actuator(u); // 输出执行，微秒级 sleep_until_cycle_end(); // 硬实时调度，周期固定 }Agent"控制"：概率性的请求-响应 while (true) { state = gather_context(); // 拼装上下文，可能要查历史数据、调工具 action = llm_chat(state); // 等模型输出，时延不可控 execute(action); // 执行模型"认为"正确的动作 }再看工业现场真实的时延梯度：
| 控制层级 | 典型周期 | 典型系统 |
|---|---|---|
| 伺服电流环 | 125µs - 250µs | 伺服驱动器电流环 |
| 伺服速度环 | 0.5 - 1ms | 伺服驱动器 |
| 运动控制插补 | 1 - 8ms | CNC、机器人控制器 |
| PLC循环扫描 | 1 - 50ms | S7-1500、TwinCAT |
| 过程DCS | 50 - 500ms | 艾默生、霍尼韦尔DCS |
| SCADA/MES | 秒级到分钟级 | 上位监控、生产执行 |
| 优化调度/APO | 分钟到天 | APS、先进计划排产 |
而Agent背后的LLM推理时延，实测大概是这样的量级：
| 模型规模 | 运行硬件 | 单次推理参考时延 |
|---|---|---|
| 0.5B int8蒸馏小模型 | Jetson Orin / 工控GPU | 10 - 30ms |
| 7B FP16 | A100/H100 | 0.2 - 1.5秒（含数十token生成） |
| 7B int8 | 工业平板CPU | 3 - 10秒 |
| 70B以上 | GPU集群 | 10秒以上 |
这还没算上RAG检索、工具调用、安全规则拦截这些Agent标配组件的叠加。控制工程师设计系统时看的是最坏情况执行时间，不是平均值。LLM的时延分布有长尾——上下文一长、并发一高、兜底规则一多，99.9分位的时延会比你测的平均值难看得多。拿这个去做1kHz的伺服控制？差了约一万倍。去做50ms的PLC扫描？依然差几十倍。
2.3 功能安全：认证体系没给概率模型留座位
就算你哪天把推理压到1毫秒内，还有一座绕不过去的山：功能安全认证。
工业控制中涉及安全的部分，要过IEC 61508（E/E/PE安全相关系统的功能安全）、IEC 61511（过程工业）、ISO 13849（机械安全）、IEC 62061（机械控制系统安全）这一整套体系。SIL3等级的回路，要求每小时失效概率低到10的负7、负8次方量级，还要求"有效使用"的历史证明——这个概念在工程界叫proven-in-use，通常需要数十万小时的无危险失效现场运行记录。
大模型拿什么去证明？拿互联网上训练出来的知识吗？拿几天Demo数据吗？认证机构现在连"如何审计一个神经网络策略的鲁棒性"都没有共识，更别提给LLM出认证规定了。再往实际了说，任何依赖云端API、依赖大模型推理服务的方案，都过不了功能安全里"安全功能不得受通信干扰"的基本隔离要求。没有哪个厂长敢让安全联锁回路挂在一个随时可能版本波动的云服务上。
所以结论很残酷：哪怕技术上跑得够快，你也没法证明它安全，没法通过认证，就没法真正投用到控制回路。方案PPT写得再漂亮，到了验收和安评环节，一样被打回来。
3. 工业现场的"实时"是分层的，Agent该待在哪一层
3.1 从电流环到排产：一张表看清梯度
工业里"实时"的颗粒度差别极大。很多人混淆，是因为他们以为现场所有控制都差不多快。实际上一个工厂里从最底层到最上层，时延要求差了七八个数量级。
| 层级 | 周期/响应 | 谁在执行 | 智能缺失度 |
|---|---|---|---|
| 执行机构与电流环 | 微秒-毫秒 | 伺服驱动器、变频器 | 低，已高度成熟 |
| 设备控制环 | 1-50ms | PLC、运动控制器 | 低 |
| 过程控制层 | 50-500ms | DCS、APC | 中，MPC解决得不错 |
| 监控与操作层 | 秒级-分种 | SCADA人机界面、操作员 | 高，操作员负荷重 |
| 调度与优化层 | 分钟-小时 | MES、APS、计划员 | 高 |
| 经营决策层 | 小时-天 | ERP、工艺工程师 | 高 |
这张表的信息量很大。你看，真正需要"毫秒级实时控制"的底层，恰恰是几十年工程实践已经打磨到位的领域。PID、伺服控制、机器人运动学——这些是确定性系统能解决得很好的问题，工程师对它们的信任度极高。你让一个概率模型插进来，不是补短板，是制造风险。
3.2 真正缺"智能"的是慢速层，不是快速层
我在工厂里跑现场的感受是：底层控制基本不缺智能，缺智能的全是慢速层。
报警洪水，一天几千条，操作员根本没时间看——这是典型的秒级到分钟级问题；设备出异常，老师傅休假了就没人能诊断——这是分钟级到小时级问题；排产变动频繁，计划员每天手工调整几十个工单——这是小时级问题。这些环节的痛点，比"让控制器更聪明"痛得多，而且Agent是真能帮上忙的。
所以我把话说得直接一点：工业现场不缺"会控制"的AI，缺的是"会分析和提醒"的AI。Agent的价值在于处理那些人类来不及看、看了也记不住的海量上下文，而不是去抢PID的活。
4. 我实测过的Agent场景：哪些能落地，哪些是演示
4.1 报警洪水分析与异常诊断：真能省事
去年我帮一家化工企业搭过一个报警辅助分析Agent。现场DCS一天产生两三千条报警，操作员交接班光梳理报警就花40分钟。我们的做法是把DCS报警历史、工艺手册、历史检修记录做了向量化入库，让Agent在交接班前自动生成一份"今日报警摘要"，按设备维度聚类，标出异常频次上升的部件，再关联上一次类似报警的处置记录。
实测结果：报警梳理时间从40分钟压到5到10分钟，而且有一周提前三天发现了某个泵的振动异常趋势——因为Agent把三个不同系统的报警记录关联起来，找到了人眼看不到的相关性。
为什么这个场景能成？因为它不在控制回路上，人在回路里，答错了也不会炸设备，最坏情况就是报告质量差一点。这是Agent天然的安全地带。
4.2 让Agent直接去动PID：我劝你连Demo都不要做
有家供应商找我评估"用LLM自动调整换热器的PID参数"，声称实验室里节能15%。我去看了他们的实验：给Agent塞入历史温度、流量、阀位数据，它输出一组新PID参数，然后脚本把参数写进DCS的PID模块。
在仿真环境里确实好看，温度曲线平滑，能耗下降了。但拿到真实生产线上，一周有5天需要工程师手动切回来——Agent给出的参数在某个工况附近效果不错，换一条负荷曲线就震荡，震荡几次就触发联锁。更讽刺的是，所谓15%节能，其实有相当一部分是Agent偷偷把设定值移到了工艺允许边界上，短期看是节能，长期看是让设备一直顶着红线跑，一次扰动就可能跳车。
我后来跟他们的技术负责人聊，根因其实很简单：Agent没有对象模型，没有在线辨识，它对"阀位和温度的因果关系"一无所知，只是在高维文本空间里做模式匹配。控制的核心是反馈和对象模型，这两样东西大模型一个都没有。
4.3 用三句话区分真需求和伪命题
经过这些事，我自己总结了一套判别标准，分享给在评估工业Agent的朋友：
- 它会不会在没有人类确认的情况下，改变执行机构的输出？如果会——当下就是伪命题。
- 它的"实时"有没有量化的时限指标、有没有SIL等级、有没有可走的认证路径？如果没有——就是营销话术。
- 它是在做决策建议，还是在做执行器控制？做建议——是真的；做执行——先别信。
5. 如果非要让Agent进控制，什么样的架构可能成立
5.1 分层架构：内环刚性、外环柔性
被问得多了，我也会给出一个我认为真正可行的架构，总结成三句话：内环不变、中间环限量、外环放开。
内环，还是传统的PLC和伺服，做毫秒级甚至微秒级的确定性控制，保持认证状态不动。中间环，可以让Agent当"设定值管理器"，每隔若干分钟根据工艺目标、能耗约束、设备健康度，给出一个推荐的设定值或参数组。但这些建议必须过两道闸：一道是约束和稳定裕度校验，一道是人工确认。外环，就是Agent做主场的诊断、排产、报警摘要、操作指导、交接班报告——放开做，在线上的错误都有人的环节兜底。
这种架构下，经典控制器负责"稳"和"快"，Agent负责"优"和"省"。有人说这叫"人机协同智能调控"，我觉得更准确的说法是：Agent是参谋，不是扳道岔的人。
5.2 什么条件下"实时控制Agent"才不是伪命题
我也跟不少做技术预研的朋友聊过这个问题——这个命题有没有翻盘的一天？有，但条件非常硬：
- 硬件上，需要毫秒级推理且最坏执行时间可证明的专用推理芯片，配合实时操作系统，现在的主流GPU和通用OS都做不到。
- 行为上，需要对大模型策略提供稳定性与收敛性的形式化证明。目前连数学工具都还不存在，这是最硬的一条。
- 标准上，需要认证机构给出可执行的神经网络控制策略验证与审计规程，不是一句"AI赋能"就能绕过的。
- 应用边界上，Agent只能在预设工况包络内做有限动作，包络之外必须自动交回经典控制器，不允许它有"自由发挥"空间。
这四条里任何一条都够一个团队啃五年。所以我的判断是："实时控制的工业Agent"现在是伪命题，不等于它永远是伪命题。但在可预见的未来，它更可能的形态是"Agent辅助的控制系统"，而不是"Agent本身成为控制器"。
说句实在话，做工业Agent的朋友也不用沮丧。你们手里的报警分析、故障诊断、排产优化、工艺建议，哪一个不是真需求？把"实时控制"这四个字从包装上去掉，反而更容易让客户信任。我见过太多项目死在了过度承诺上——验收时对着PPT上的"实时控制"较真，产品再好的本事也说不出口了。老老实实讲清楚自己能做什么、不能做什么，这本身就是工业工程师最基本的素养。
