“实时控制的工业 Agent”这句话我最近两年在技术交流里听得耳朵起茧。说句得罪人的话绝大多数把 Agent 和实时控制绑在一起讲的方案要么停在 PPT 上要么只跑在实验里录好的视频中。我不是反对 Agent 进工业我是反对把“实时控制”这顶帽子扣在一个本质上讲概率、讲长程规划的模型头上。今天这篇文章就把话拆开讲清楚——为什么它是伪命题以及如果团队非要做边界该划在哪里。1. 先把两个词摆到台面上一个讲确定性一个讲概率性1.1 实时控制到底“实时”在哪很多写技术方案的朋友对“实时”的理解就是“反应快”。控制工程师嘴里的实时完全是另一回事实时 在规定的时限内完成规定的动作且时限必须可证明、可复现。PLC 的循环扫描周期是个典型指标基础逻辑控制在 5~50 毫秒跑完一圈运动控制更是按 125 微秒到 2 毫秒算轴周期EtherCAT 这类硬实时总线的同步抖动能压到亚微秒级。在这个尺度上系统关心的不是“快”而是“每个周期都准点”。更准确地说实时系统有硬实时和软实时之分。安全回路、伺服闭环、张力控制这些硬实时任务要的是最坏情况执行时间WCET可控。你把一段代码丢进去必须能证明它在任何分支、任何负载下都不会超过 deadline。这也是为什么工业界至今还在用状态机、梯形图、结构化文本这些“老古董”——它们逻辑是有限的、分支是穷举的、执行时间是能算清楚的。工程上可以允许系统偶尔慢一点但慢得有界这就是僵化的好处。1.2 工业 Agent 的本质是长程推理与自主规划Agent 是什么拆开看就是大模型或视觉模型做大脑加上记忆模块、工具调用和规划循环。它的工作方式是 ReAct 式的思考think、行动act、观察observe再思考一圈下来调用一次模型推理再调用一次外部工具再等结果回来后做下一轮判断。麻烦就麻烦在这个“再思考”上。一次模型推理的端到端时延小模型也要几百毫秒大模型几秒到十几秒很正常。而且这个数值高度不稳定GPU 排队、缓存命中率、上下文长度变化都会让 P50 和 P99 之间拉开几十倍的差距。更重要的是Agent 的输出是概率采样出来的同样的输入十次推理可能有十种语气也可能有十种参数建议模型的“幻觉”问题更让它天生不适合做那种“错一次就要出事故”的决策。一侧是毫秒级、可证明、确定性的控制回路另一侧是秒级、不可证明、概率性的推理回路。这两个东西从底层范式上就是拧着的。你可以让 Agent 跑在实时系统旁边当参谋但要说让它的输出直接参与实时控制闭环光时间尺度这一关就过不去。2. 时间尺度差三个数量级为什么 Agent 进不了控制回路2.1 控制周期和推理时延的残酷对比我们把数字老老实实摆出来大家心里就有数了。我整理过一张对比表做控制的朋友看一眼就明白差距有多大环节典型周期/时延实时性要求伺服电流环62.5~125 微秒硬实时抖动微秒级伺服速度/位置环250 微秒~2 毫秒硬实时周期严格PLC 逻辑扫描5~100 毫秒硬实时或软实时超时报警工业视觉触发10~50 毫秒事件触发有界时延错过即废帧LLM 单次推理300 毫秒~数秒无界波动排队时更糟Agent 完整 ReAct 循环数秒~数十秒取决于工具链和模型调用次数从控制周期到 Agent 决策差了 2 到 4 个数量级。控制理论里有个经验法则闭环带宽通常不超过采样频率的十分之一。如果采样周期是 1 毫秒闭环带宽还能到 100 赫兹左右如果你把“采样”换成 Agent 那 1 秒一次的决策闭环带宽直接掉到 0.1 赫兹以下。拿这个去跑伺服跟随或者张力控制相当于让一个反应弧三秒的人去接高速飞来的球动作还没做完误差早就累积爆了。2.2 时延抖动比时延本身更致命比“慢”更可怕的是“没准头”。控制系统最怕的不是固定延迟——固定延迟可以通过预估补偿掉真正让控制工程师头疼的是时延抖动。你设计一个补偿器假设信号 100 毫秒到达结果它这次 80 毫秒到、下次 300 毫秒到、再下次排队排了 2 秒才回你的相位裕度就被这份不确定性吃光了系统接着就开始振荡。LLM 的时延分布天然就是抖动的。请求多了排队排队就要等上下文长了首 token 延迟变高模型版本更新了行为还跟着变。我亲眼见过一个把大模型接到 PLC 仿真器上的项目模型那个 JSON 返回值偶尔 0.5 秒回来偶尔 3 秒才回仿真曲线直接抖成一团锯齿最后他们没法收场只能在 PPT 里把曲线截掉了。你说这不是模型能力问题是工程问题对但问题恰恰在于你没法用工程手段把一个无界抖动变成有界抖动除非重新设计推理栈而那已经不是今天大多数 Agent 框架在做的事。3. 概率输出过不了安全关SIL、功能安全和“可证明的确定性”3.1 安全标准不认“大概率正确”工业场景里有一类代码叫功能安全相关代码。安全 PLC 要过 SIL 认证、运动安全要过 PL 等级核心就一句话你必须在数学上证明危险失效概率低到可接受。拿 SIL 3 举例要求每小时危险失效概率低于 1E-7 到 1E-8而且这个数字要有依据、有模型、有验证记录。大模型怎么证明模型是几亿个参数的非线性函数输入空间近乎无穷失效模式无法穷举。哪怕你实测十万次只错一次安全认证机构也不会认这个“统计结果”——他们要求的是可复现、可审计、可形式化验证的失效模型。你说我在前面加一个规则校验层让 Agent 的输出只当参考那实时控制回路里真正干活的不还是那层规则吗Agent 参与了个寂寞。控制回路的安全设计逻辑也不一样。安全 PLC 的冗余架构比如 1oo2、2oo3看似在“做加法”本质是在做“失效可预测”急停回路、安全门锁、双通道检测设计目标不是算得快而是坏也要坏得明明白白。大模型的失效是模糊的、上下文相关的、甚至带创造性的——它可能编造一个不存在的工艺参数还可能一本正经地解释编造的理由。这种东西放进实时控制链路上连事故复盘都没法做你分不清是模型幻觉、是数据污染、还是训练集里本来就有错误。3.2 确定性红线和现场操作权的博弈工业现场有一条默认红线最终决策权永远在人手里任何自动化系统都只能建议不能替人做安全攸关的最终裁决。这不是技术保守背后是责任边界。工艺事故追责追的是设计方、集成方、操作员Agent 本身既没有法人资格也负不了法律责任。你把产线安全交给一个概率模型这正是现在所有做实时控制 Agent 的团队最避而不谈的一点。我见过不少方案写“Agent 自动调整 PID 参数”听起来很智能。但你现场问一句调完之后稳定性谁负责超调了造成废品谁担再问一句模型有没有可能在一个边界工况下输出一个积分饱和式的参数组合对方基本就开始含糊了。这不能怪做 AI 的同事他们没在车间待过不知道一个参数给下去几百万的设备可能就废了。控制系统可以自治但不能“自动背锅”这是工业运行的基本伦理。4. 那 Agent 在工业里就彻底没用了吗别把概念绑在“实时”上4.1 Agent 真正能落地的位置在实时控制之外把话说死之前先给 Agent 平个反。工业现场一大堆痛点根本不需要毫秒级响应它们需要的恰恰是“在几分钟到几小时内做靠谱的推理和规划”。设备健康管理、根因分析、工艺参数优化、报警风暴抑制、维修工单生成、MES 问答这些场景都是 Agent 的舒适区。拿报警风暴举个实在例子化工厂一个扰动下来DCS 上一分钟可能涌出几百条报警操作员根本看不过来。传统的报警管理只能按优先级排序但 Agent 可以把几百条报警串联成一条“事件链”——温度升高、压力波动、阀门开度变化、几分钟前某个泵的异常振动它用自然语言生成一份通俗易懂的根因报告中间再调用历史数据库去对比类似工况。这套东西哪怕响应要 30 秒也比操作员自己翻历史曲线快得多而且它不改任何过程参数只输出一份报告安全边界非常清晰。再讲一个我真实参与过的配方调优项目。工艺员原来每天要靠经验微调添加剂比例周期是小时级。我们做了一个建议系统Agent 读取过去 30 天的质量数据和工艺参数每 15 分钟给出一次“建议配方微调方案”但必须由工艺员在界面上确认之后才下发到 DCS。一开始工艺员也抵触觉得机器指手画脚跑了两个月后发现建议有道理慢慢就当半个技术顾问用了。这个项目从头到尾没碰过实时控制但车间实实在在觉得“AI 有用”。4.2 建议权和控制权分离是当前最靠谱的落地路线我愿意给出一个非常明确的分层判断自控工程师看了就懂怎么配套层级典型响应要求允许 Agent 介入方式现场设备层传感器、伺服、阀门微秒~毫秒级硬实时禁止直连只读镜像数据控制层PLC、DCS、安全系统毫秒~百毫秒级原则上禁止直写仅允许可审计的“经人确认的参数下发”执行层MES、SCADA 调度秒~分钟级允许生成工单、建议排序、人审后执行决策层工艺优化、设备健康、报表分析分钟~小时级Agent 主场可以全自主分析与报告生成在这个分层里Agent 的道儿很清晰要么做“只读建议”要么做“人机协同闭环”唯独不应该去做“直连控制器”。哪怕未来模型推理速度再快一个量级我也坚持这个判断控制律的确定性和可证明性是一个远比“智能”更刚性的需求Agent 可以做实时控制系统的“外脑”而不是“脊神经”。4.3 未来什么条件下才可能碰实时我不会把话说死我们可以推演一下假如某一天模型推理时延能做到确定性——比如通过专用硬件把每一次推理的耗时约束在一个窄区间内而且形式化验证工具能证明模型在安全攸关的输出范围内不会越界那么 Agent 参与部分非安全关键控制回路比如不需要 SIL 认证的温度优化回路是有可能的。但即便如此架构上大概率也不是 Agent 直接输出控制量而是 Agent 给出“控制模式切换/参数档位选择”由底层传统的实时控制器去执行。这种“AI 上层决策、传统控制底层执行”的混合架构是我目前能想象到的最合理演进路径。注意到那个时候媒体口中的“实时控制 Agent”其实是一个“实时控制系统的 AI 辅助调度员”跟现在标题上那个唬人的概念根本不是一回事。5. 实操建议如果团队非要试“Agent 控制”怎么做好边界5.1 我踩过的坑三个真实案例第一个坑是大模型接 PLC 仿真器做闭环。我们当时天真地以为 20 毫秒触发一次模型就算慢也总能在一个周期内算完。结果模型加上 JSON 解析最快的也要 700 毫秒慢的时候直接卡到 4 秒。我们用缓存兜底但缓存命中率不稳定仿真曲线上全是锯齿伺服模型被 PD 参数整得嗡嗡响。后来我们彻底放弃闭环方向改成“离线调参建议 人工导入”。第二个坑是多模态读表。车间有位同事提出用视觉大模型识别现场仪表读数给调度系统提供数据。模型在空闲时识别很快但一到白天产线高负载、GPU 排队严重读数结果能滞后 3 秒以上。而那个仪表量测的温度本身变化很快等结果出来再去调整策略早就过冲了。不是说识别不准是“过了保质期的准确数据比没有数据更危险”。控制系统吃进一个旧值等于把过去的噪声当成现在的真值累积误差非常大。第三个坑也是我最想提醒大家的Agent 生成工艺建议时的幻觉。当时我们让 Agent 读物料主数据然后基于对话生成推荐配方结果它在一本正经的推论里编了一个不存在的物料编码还带着非常像样的技术参数。幸好我们当时只是内部演示没有真正下发。这事之后我们立了几条死规矩Agent 不允许生成主数据只允许查询已存在的数据任何建议必须带可追溯的数据源引用建议的物料编码必须做数据库存在性校验校验不过直接废弃整条建议。这三条规矩我建议所有做工业 Agent 的团队直接抄走。5.2 团队落地边界清单可直接抄作业如果你现在接手一个“工业 Agent”项目下面这条清单是我反复吃亏后总结出来的直接照着落实就行明确“只读不写”原则Agent 的数据输入全部来自 OPC UA 订阅或 MQTT 镜像点禁止直接访问 PLC 存储区写操作一律通过上层 MES/DCS 的人工审批接口。网络隔离部署AI 服务放在 DMZ 区通过工控防火墙白名单访问指定服务端口禁止 AI 服务直接扫描或连接控制器网段。建议超时失效任何 Agent 给出的建议必须带时间戳和有效期超过 5 分钟可按场景调整自动作废防止“过期建议”在人工确认时被误执行。日志全量审计Agent 的每次输入、输出、引用来源、人工确认记录全部落库出问题能复盘这也是功能安全的基本素养。人机回环兜底默认模式下建议只展示不自动执行如果确实要半自动必须采用“按下保持”机制人松手即停把最终动作权永远握在操作员手里。5.3 架构建议和验收指标架构上我的建议非常朴素把实时控制层封装成“服务”Agent 只调服务不碰点位。控制层的每个写操作接口都要做身份认证、参数范围校验、变化速率限制Agent 通过服务接口提交建议服务层校验通过后再进入“待确认队列”。这套东西技术上没有任何魔法但锚定了责任边界。验收千万不要只看演示那一下午。我建议用 6 周跑批指标建议采纳率、建议误报率、人工否决率、Agent 参与后的事故/停机次数变化以及“建议导致误操作”的归零目标。如果这五个指标里有一个不达标说明这台 Agent 还没有资格进车间。一套写进合同里的验收标准比一百页“智能化转型蓝图”有用。6. 一点真心话我见过太多“总部 AI 转型 KPI”压到车间结果车间悄悄把 Agent 下线、只在汇报前开机的案例。背后的道理其实很简单工业现场最值钱的不是“智能”是“确定”。工艺员可以接受一个模型偶尔给错建议但不能接受控制器偶尔抽风操作员可以跟 Agent 聊上十分钟问一个复杂工况但不能接受急停回路被一条概率输出绕过。所以“实时控制的工业 Agent 是伪命题”我说的不是 Agent 不行而是“绑定实时”这件事不行。Agent 进工业的正确姿势永远是当那个“在旁边把话说清楚、把建议做扎实、把风险标明白”的参谋。让它在分钟级、小时级的决策层去发光发热把微秒级、毫秒级的控制权交还给那些哪怕“笨”但可靠的控制器。这是我的真心建议。 
长河君 · 2026/10/17 5:11:29 · 阅读 1.2k 实时控制的工业Agent为何是伪命题？边界在哪里？
“实时控制的工业 Agent”这句话我最近两年在技术交流里听得耳朵起茧。说句得罪人的话绝大多数把 Agent 和实时控制绑在一起讲的方案要么停在 PPT 上要么只跑在实验里录好的视频中。我不是反对 Agent 进工业我是反对把“实时控制”这顶帽子扣在一个本质上讲概率、讲长程规划的模型头上。今天这篇文章就把话拆开讲清楚——为什么它是伪命题以及如果团队非要做边界该划在哪里。1. 先把两个词摆到台面上一个讲确定性一个讲概率性1.1 实时控制到底“实时”在哪很多写技术方案的朋友对“实时”的理解就是“反应快”。控制工程师嘴里的实时完全是另一回事实时 在规定的时限内完成规定的动作且时限必须可证明、可复现。PLC 的循环扫描周期是个典型指标基础逻辑控制在 5~50 毫秒跑完一圈运动控制更是按 125 微秒到 2 毫秒算轴周期EtherCAT 这类硬实时总线的同步抖动能压到亚微秒级。在这个尺度上系统关心的不是“快”而是“每个周期都准点”。更准确地说实时系统有硬实时和软实时之分。安全回路、伺服闭环、张力控制这些硬实时任务要的是最坏情况执行时间WCET可控。你把一段代码丢进去必须能证明它在任何分支、任何负载下都不会超过 deadline。这也是为什么工业界至今还在用状态机、梯形图、结构化文本这些“老古董”——它们逻辑是有限的、分支是穷举的、执行时间是能算清楚的。工程上可以允许系统偶尔慢一点但慢得有界这就是僵化的好处。1.2 工业 Agent 的本质是长程推理与自主规划Agent 是什么拆开看就是大模型或视觉模型做大脑加上记忆模块、工具调用和规划循环。它的工作方式是 ReAct 式的思考think、行动act、观察observe再思考一圈下来调用一次模型推理再调用一次外部工具再等结果回来后做下一轮判断。麻烦就麻烦在这个“再思考”上。一次模型推理的端到端时延小模型也要几百毫秒大模型几秒到十几秒很正常。而且这个数值高度不稳定GPU 排队、缓存命中率、上下文长度变化都会让 P50 和 P99 之间拉开几十倍的差距。更重要的是Agent 的输出是概率采样出来的同样的输入十次推理可能有十种语气也可能有十种参数建议模型的“幻觉”问题更让它天生不适合做那种“错一次就要出事故”的决策。一侧是毫秒级、可证明、确定性的控制回路另一侧是秒级、不可证明、概率性的推理回路。这两个东西从底层范式上就是拧着的。你可以让 Agent 跑在实时系统旁边当参谋但要说让它的输出直接参与实时控制闭环光时间尺度这一关就过不去。2. 时间尺度差三个数量级为什么 Agent 进不了控制回路2.1 控制周期和推理时延的残酷对比我们把数字老老实实摆出来大家心里就有数了。我整理过一张对比表做控制的朋友看一眼就明白差距有多大环节典型周期/时延实时性要求伺服电流环62.5~125 微秒硬实时抖动微秒级伺服速度/位置环250 微秒~2 毫秒硬实时周期严格PLC 逻辑扫描5~100 毫秒硬实时或软实时超时报警工业视觉触发10~50 毫秒事件触发有界时延错过即废帧LLM 单次推理300 毫秒~数秒无界波动排队时更糟Agent 完整 ReAct 循环数秒~数十秒取决于工具链和模型调用次数从控制周期到 Agent 决策差了 2 到 4 个数量级。控制理论里有个经验法则闭环带宽通常不超过采样频率的十分之一。如果采样周期是 1 毫秒闭环带宽还能到 100 赫兹左右如果你把“采样”换成 Agent 那 1 秒一次的决策闭环带宽直接掉到 0.1 赫兹以下。拿这个去跑伺服跟随或者张力控制相当于让一个反应弧三秒的人去接高速飞来的球动作还没做完误差早就累积爆了。2.2 时延抖动比时延本身更致命比“慢”更可怕的是“没准头”。控制系统最怕的不是固定延迟——固定延迟可以通过预估补偿掉真正让控制工程师头疼的是时延抖动。你设计一个补偿器假设信号 100 毫秒到达结果它这次 80 毫秒到、下次 300 毫秒到、再下次排队排了 2 秒才回你的相位裕度就被这份不确定性吃光了系统接着就开始振荡。LLM 的时延分布天然就是抖动的。请求多了排队排队就要等上下文长了首 token 延迟变高模型版本更新了行为还跟着变。我亲眼见过一个把大模型接到 PLC 仿真器上的项目模型那个 JSON 返回值偶尔 0.5 秒回来偶尔 3 秒才回仿真曲线直接抖成一团锯齿最后他们没法收场只能在 PPT 里把曲线截掉了。你说这不是模型能力问题是工程问题对但问题恰恰在于你没法用工程手段把一个无界抖动变成有界抖动除非重新设计推理栈而那已经不是今天大多数 Agent 框架在做的事。3. 概率输出过不了安全关SIL、功能安全和“可证明的确定性”3.1 安全标准不认“大概率正确”工业场景里有一类代码叫功能安全相关代码。安全 PLC 要过 SIL 认证、运动安全要过 PL 等级核心就一句话你必须在数学上证明危险失效概率低到可接受。拿 SIL 3 举例要求每小时危险失效概率低于 1E-7 到 1E-8而且这个数字要有依据、有模型、有验证记录。大模型怎么证明模型是几亿个参数的非线性函数输入空间近乎无穷失效模式无法穷举。哪怕你实测十万次只错一次安全认证机构也不会认这个“统计结果”——他们要求的是可复现、可审计、可形式化验证的失效模型。你说我在前面加一个规则校验层让 Agent 的输出只当参考那实时控制回路里真正干活的不还是那层规则吗Agent 参与了个寂寞。控制回路的安全设计逻辑也不一样。安全 PLC 的冗余架构比如 1oo2、2oo3看似在“做加法”本质是在做“失效可预测”急停回路、安全门锁、双通道检测设计目标不是算得快而是坏也要坏得明明白白。大模型的失效是模糊的、上下文相关的、甚至带创造性的——它可能编造一个不存在的工艺参数还可能一本正经地解释编造的理由。这种东西放进实时控制链路上连事故复盘都没法做你分不清是模型幻觉、是数据污染、还是训练集里本来就有错误。3.2 确定性红线和现场操作权的博弈工业现场有一条默认红线最终决策权永远在人手里任何自动化系统都只能建议不能替人做安全攸关的最终裁决。这不是技术保守背后是责任边界。工艺事故追责追的是设计方、集成方、操作员Agent 本身既没有法人资格也负不了法律责任。你把产线安全交给一个概率模型这正是现在所有做实时控制 Agent 的团队最避而不谈的一点。我见过不少方案写“Agent 自动调整 PID 参数”听起来很智能。但你现场问一句调完之后稳定性谁负责超调了造成废品谁担再问一句模型有没有可能在一个边界工况下输出一个积分饱和式的参数组合对方基本就开始含糊了。这不能怪做 AI 的同事他们没在车间待过不知道一个参数给下去几百万的设备可能就废了。控制系统可以自治但不能“自动背锅”这是工业运行的基本伦理。4. 那 Agent 在工业里就彻底没用了吗别把概念绑在“实时”上4.1 Agent 真正能落地的位置在实时控制之外把话说死之前先给 Agent 平个反。工业现场一大堆痛点根本不需要毫秒级响应它们需要的恰恰是“在几分钟到几小时内做靠谱的推理和规划”。设备健康管理、根因分析、工艺参数优化、报警风暴抑制、维修工单生成、MES 问答这些场景都是 Agent 的舒适区。拿报警风暴举个实在例子化工厂一个扰动下来DCS 上一分钟可能涌出几百条报警操作员根本看不过来。传统的报警管理只能按优先级排序但 Agent 可以把几百条报警串联成一条“事件链”——温度升高、压力波动、阀门开度变化、几分钟前某个泵的异常振动它用自然语言生成一份通俗易懂的根因报告中间再调用历史数据库去对比类似工况。这套东西哪怕响应要 30 秒也比操作员自己翻历史曲线快得多而且它不改任何过程参数只输出一份报告安全边界非常清晰。再讲一个我真实参与过的配方调优项目。工艺员原来每天要靠经验微调添加剂比例周期是小时级。我们做了一个建议系统Agent 读取过去 30 天的质量数据和工艺参数每 15 分钟给出一次“建议配方微调方案”但必须由工艺员在界面上确认之后才下发到 DCS。一开始工艺员也抵触觉得机器指手画脚跑了两个月后发现建议有道理慢慢就当半个技术顾问用了。这个项目从头到尾没碰过实时控制但车间实实在在觉得“AI 有用”。4.2 建议权和控制权分离是当前最靠谱的落地路线我愿意给出一个非常明确的分层判断自控工程师看了就懂怎么配套层级典型响应要求允许 Agent 介入方式现场设备层传感器、伺服、阀门微秒~毫秒级硬实时禁止直连只读镜像数据控制层PLC、DCS、安全系统毫秒~百毫秒级原则上禁止直写仅允许可审计的“经人确认的参数下发”执行层MES、SCADA 调度秒~分钟级允许生成工单、建议排序、人审后执行决策层工艺优化、设备健康、报表分析分钟~小时级Agent 主场可以全自主分析与报告生成在这个分层里Agent 的道儿很清晰要么做“只读建议”要么做“人机协同闭环”唯独不应该去做“直连控制器”。哪怕未来模型推理速度再快一个量级我也坚持这个判断控制律的确定性和可证明性是一个远比“智能”更刚性的需求Agent 可以做实时控制系统的“外脑”而不是“脊神经”。4.3 未来什么条件下才可能碰实时我不会把话说死我们可以推演一下假如某一天模型推理时延能做到确定性——比如通过专用硬件把每一次推理的耗时约束在一个窄区间内而且形式化验证工具能证明模型在安全攸关的输出范围内不会越界那么 Agent 参与部分非安全关键控制回路比如不需要 SIL 认证的温度优化回路是有可能的。但即便如此架构上大概率也不是 Agent 直接输出控制量而是 Agent 给出“控制模式切换/参数档位选择”由底层传统的实时控制器去执行。这种“AI 上层决策、传统控制底层执行”的混合架构是我目前能想象到的最合理演进路径。注意到那个时候媒体口中的“实时控制 Agent”其实是一个“实时控制系统的 AI 辅助调度员”跟现在标题上那个唬人的概念根本不是一回事。5. 实操建议如果团队非要试“Agent 控制”怎么做好边界5.1 我踩过的坑三个真实案例第一个坑是大模型接 PLC 仿真器做闭环。我们当时天真地以为 20 毫秒触发一次模型就算慢也总能在一个周期内算完。结果模型加上 JSON 解析最快的也要 700 毫秒慢的时候直接卡到 4 秒。我们用缓存兜底但缓存命中率不稳定仿真曲线上全是锯齿伺服模型被 PD 参数整得嗡嗡响。后来我们彻底放弃闭环方向改成“离线调参建议 人工导入”。第二个坑是多模态读表。车间有位同事提出用视觉大模型识别现场仪表读数给调度系统提供数据。模型在空闲时识别很快但一到白天产线高负载、GPU 排队严重读数结果能滞后 3 秒以上。而那个仪表量测的温度本身变化很快等结果出来再去调整策略早就过冲了。不是说识别不准是“过了保质期的准确数据比没有数据更危险”。控制系统吃进一个旧值等于把过去的噪声当成现在的真值累积误差非常大。第三个坑也是我最想提醒大家的Agent 生成工艺建议时的幻觉。当时我们让 Agent 读物料主数据然后基于对话生成推荐配方结果它在一本正经的推论里编了一个不存在的物料编码还带着非常像样的技术参数。幸好我们当时只是内部演示没有真正下发。这事之后我们立了几条死规矩Agent 不允许生成主数据只允许查询已存在的数据任何建议必须带可追溯的数据源引用建议的物料编码必须做数据库存在性校验校验不过直接废弃整条建议。这三条规矩我建议所有做工业 Agent 的团队直接抄走。5.2 团队落地边界清单可直接抄作业如果你现在接手一个“工业 Agent”项目下面这条清单是我反复吃亏后总结出来的直接照着落实就行明确“只读不写”原则Agent 的数据输入全部来自 OPC UA 订阅或 MQTT 镜像点禁止直接访问 PLC 存储区写操作一律通过上层 MES/DCS 的人工审批接口。网络隔离部署AI 服务放在 DMZ 区通过工控防火墙白名单访问指定服务端口禁止 AI 服务直接扫描或连接控制器网段。建议超时失效任何 Agent 给出的建议必须带时间戳和有效期超过 5 分钟可按场景调整自动作废防止“过期建议”在人工确认时被误执行。日志全量审计Agent 的每次输入、输出、引用来源、人工确认记录全部落库出问题能复盘这也是功能安全的基本素养。人机回环兜底默认模式下建议只展示不自动执行如果确实要半自动必须采用“按下保持”机制人松手即停把最终动作权永远握在操作员手里。5.3 架构建议和验收指标架构上我的建议非常朴素把实时控制层封装成“服务”Agent 只调服务不碰点位。控制层的每个写操作接口都要做身份认证、参数范围校验、变化速率限制Agent 通过服务接口提交建议服务层校验通过后再进入“待确认队列”。这套东西技术上没有任何魔法但锚定了责任边界。验收千万不要只看演示那一下午。我建议用 6 周跑批指标建议采纳率、建议误报率、人工否决率、Agent 参与后的事故/停机次数变化以及“建议导致误操作”的归零目标。如果这五个指标里有一个不达标说明这台 Agent 还没有资格进车间。一套写进合同里的验收标准比一百页“智能化转型蓝图”有用。6. 一点真心话我见过太多“总部 AI 转型 KPI”压到车间结果车间悄悄把 Agent 下线、只在汇报前开机的案例。背后的道理其实很简单工业现场最值钱的不是“智能”是“确定”。工艺员可以接受一个模型偶尔给错建议但不能接受控制器偶尔抽风操作员可以跟 Agent 聊上十分钟问一个复杂工况但不能接受急停回路被一条概率输出绕过。所以“实时控制的工业 Agent 是伪命题”我说的不是 Agent 不行而是“绑定实时”这件事不行。Agent 进工业的正确姿势永远是当那个“在旁边把话说清楚、把建议做扎实、把风险标明白”的参谋。让它在分钟级、小时级的决策层去发光发热把微秒级、毫秒级的控制权交还给那些哪怕“笨”但可靠的控制器。这是我的真心建议。