1. 工业Agent与实时控制之间的真实距离1.1 一个被反复提起的判断“实时控制的工业Agent现在是伪命题”——这句话我第一次在技术群里看到时心里是认同的但认同得并不轻松。因为它听起来像是一句唱衰的话实际上却是一个工程事实。工业现场对“实时”的定义和互联网圈对“实时”的定义中间隔着一整套物理世界的约束。你在办公室里说“实时”可能指的是接口响应在200毫秒以内而在一台注塑机的控制柜里说“实时”指的是从传感器采样到执行机构动作整个闭环必须在1毫秒甚至更短的时间内完成抖动不能超过几十微秒否则产品就是废品模具就可能损坏。工业Agent这个概念这两年跟着大模型的浪潮被反复包装。很多人想象中的画面是一个AI Agent坐在控制室里看着DCS的画面自主判断工况然后直接下发指令给PLC调整阀门开度、修改PID参数、切换设备运行模式。这个画面很美好但它跳过了太多东西。Agent要“控制”工业设备前提是它能进入实时控制回路而进入实时控制回路意味着它必须满足硬实时的确定性要求。当前绝大多数Agent的运行时架构从根子上就不是为硬实时设计的。1.2 为什么“实时”在工业语境里是另一个物种要理解这个判断得先把“实时”这个词拆开。工业控制里的实时通常分为硬实时和软实时。硬实时指的是错过截止时间就会造成严重后果的场景比如运动控制、安全联锁、高速采样闭环。软实时则是偶尔延迟可以容忍但整体上仍需要稳定响应的场景比如过程控制中的温度调节、液位控制。PLC和DCS之所以能承担实时控制任务不是因为它们算力强而是因为它们的运行时是确定性的。一个西门子S7-200 SMART或者汇川PLC它的扫描周期是固定的输入采样、程序执行、输出刷新按部就班每一轮的时间抖动被控制在极小的范围内。这种确定性是工业控制的地基。而Agent的运行时是什么样的它通常依赖大模型推理、工具调用、上下文管理、外部API通信。一次推理的耗时可能从几百毫秒到几秒不等网络往返的延迟更是不可预测。你让它去控制一个需要10毫秒闭环的回路它连“按时到达”都做不到。这不是Agent不够聪明的问题而是它的时间模型和工业控制的时间模型根本不在一个维度上。用一个不太严谨但很直观的类比PLC像是一台准点发车的公交系统每一站都按时刻表走Agent像是一个随时可能被叫去开会的项目经理你没法要求它每分钟准时出现在同一个位置。1.3 当前工业Agent的真实落点在哪里那工业Agent现在到底能做什么我的观察是它目前真正有价值的落点不在控制回路内部而在控制回路的外围。具体来说是那些对实时性要求不高、但对信息整合和决策辅助要求很高的环节。比如设备故障的根因分析、工艺参数的优化建议、报警信息的聚合与降噪、运维知识的检索与问答、生产报表的自动生成。这些场景的共同特点是时间窗口以分钟甚至小时计Agent有足够的思考时间它的输出是给人看的或者给上层系统做参考的而不是直接写进PLC的输出寄存器。我见过一些项目把Agent接在SCADA或者 historians 之上让它读取历史数据和实时报警然后生成诊断建议。这类项目跑得还不错因为Agent不需要参与闭环它只是一个高级的分析工具。但一旦有人提出“让Agent直接调PID参数”问题就来了。PID参数的调整不是不能自动化但那是自适应控制或者模型预测控制的领域它们有严格的稳定性证明和实时性保障和Agent的推理式决策是两套东西。把Agent硬塞进这个位置就像让一个战略咨询顾问去操作数控机床的手轮不是他不够聪明而是他的反应速度和精度根本不适合这个任务。1.4 伪命题的判断成立但不等于Agent没有未来说“实时控制的工业Agent是伪命题”重点在“实时控制”这个限定词上而不是否定Agent本身。这个判断成立的前提是我们讨论的是硬实时闭环控制。如果放宽到软实时或者放宽到“人在回路的辅助决策”那Agent是有空间的。问题在于市场上很多宣传把这两者混为一谈用“工业Agent”这个模糊的词让人误以为Agent已经可以接管实时控制了。这种误导对一线工程师来说是有害的因为它会让人对技术产生不切实际的期待进而在项目选型时做出错误判断。我写这篇东西的目的不是要唱衰工业Agent而是想把“实时控制”和“Agent”之间的边界说清楚。边界清楚了才知道哪些事现在能做哪些事现在不能做哪些事需要换一种架构去做。下面我会从实时性的技术本质、Agent的运行时特征、工业现场的实际约束、以及当前可行的替代路径几个角度把这个判断拆开来讲。2. 硬实时闭环里Agent的运行时为什么插不进去2.1 从PLC扫描周期看确定性的代价要理解Agent为什么进不了硬实时闭环得先看PLC是怎么保证确定性的。以常见的PLC运行为例它的工作模式是循环扫描读取输入映像区、执行用户程序、刷新输出映像区、处理通信和诊断然后进入下一轮。这个循环的时间就是扫描周期通常在几毫秒到几十毫秒之间。关键在于这个周期是确定的不会因为“今天任务多”就变长也不会因为“网络卡了”就抖动。PLC的运行时是一个封闭的、可预测的系统它的任务调度是静态的优先级是固定的中断响应时间是经过验证的。这种确定性是有代价的。PLC的算力通常很有限内存也不大它不能跑复杂的操作系统不能动态加载未知的代码不能做大规模的数据分析。它的整个设计哲学就是“用受限的能力换取确定的行为”。你让它做逻辑运算、PID调节、顺序控制它很擅长你让它跑一个Transformer模型它根本跑不动。而Agent恰恰需要强大的算力和灵活的运行时这两者和PLC的设计哲学是冲突的。2.2 Agent推理链路里的时间不可控点Agent的典型工作链路包括接收输入、构建提示词、调用大模型推理、解析输出、决定是否调用工具、执行工具调用、整合结果、生成最终响应。这条链路上几乎每一个环节的时间都是不可控的。大模型推理的耗时取决于模型大小、输入长度、输出长度、服务端负载可能从几百毫秒到十几秒不等。工具调用如果涉及外部API还要加上网络往返时间。更麻烦的是Agent可能会进行多轮推理和多次工具调用总耗时是累积的而且没有上界。有人会说可以用小模型、本地部署、流式输出优化延迟。这些手段确实能降低平均延迟但降低不了最坏情况延迟。工业控制关心的恰恰是最坏情况因为一次超时就可能造成事故。你可以让Agent在99%的情况下在500毫秒内响应但剩下1%的情况下它花了3秒这3秒在硬实时场景里就是不可接受的。PLC的扫描周期不会出现“偶尔多花3秒”的情况它的最坏情况是经过验证的。Agent的运行时没有这种保证也不可能有因为大模型的推理过程本质上是数据依赖的输入不同计算量就不同时间就不确定。2.3 通信链路引入的额外抖动即使Agent的推理速度足够快它和PLC之间的通信链路也会引入抖动。工业现场常用的通信协议有Modbus、Profibus、Profinet、EtherCAT等其中EtherCAT和Profinet IRT是支持硬实时的但它们的实时性保障是建立在专用硬件和确定性调度之上的。如果Agent通过普通的以太网TCP连接去读写PLC那这个连接本身就不具备实时性保障。TCP的重传机制、拥塞控制、操作系统的网络栈调度都会引入不可预测的延迟。我做过一个简单的测试在一台普通工控机上通过Modbus TCP每隔10毫秒读取一次PLC的寄存器统计往返时间。平均延迟大概在2到5毫秒但偶尔会出现几十毫秒甚至上百毫秒的尖峰。这些尖峰可能来自操作系统的调度、网络交换机的缓冲、或者PLC通信任务的优先级抢占。对于数据采集来说这些尖峰无所谓但对于闭环控制来说这些尖峰就是灾难。Agent如果要参与控制它的通信链路必须和PLC的实时通信走同一套机制而这意味着Agent必须嵌入到PLC的运行时里或者至少运行在同一个实时域内。这又回到了算力和确定性的矛盾上。2.4 功能安全层面的硬性门槛还有一个容易被忽略的维度功能安全。工业现场有很多场景是涉及安全联锁的比如急停、超压保护、超温保护。这些功能通常由独立的安全PLC或者安全继电器实现遵循IEC 61508或者IEC 62061等标准。安全相关功能的开发、验证、认证有一套严格的流程任何进入安全回路的组件都必须经过认证。一个基于大模型的Agent它的行为是不可完全预测的它的输出是概率性的它无法通过功能安全认证。这不是技术能力的问题而是架构范式的问题。安全回路要求确定性、可验证性、可追溯性而Agent的推理过程是黑箱的、概率的、难以形式化验证的。所以至少在安全相关场景里Agent进入实时控制回路在可预见的未来都是不可能的。3. 工业现场真正需要的“实时”是什么粒度3.1 不同场景的实时性要求差异巨大“实时”不是一个单一的概念不同工业场景对实时性的要求差了好几个数量级。运动控制场景比如六轴机械臂的伺服控制要求的是微秒级到毫秒级的闭环抖动要控制在微秒级。过程控制场景比如温度、压力、流量的PID调节要求的是毫秒级到秒级的闭环抖动容忍度稍大一些。而生产调度、排产优化、设备维护这些场景时间粒度是分钟、小时甚至天。把这三个层次混在一起谈“实时控制”本身就是不严谨的。Agent能发挥作用的地方主要在第三个层次也就是分钟级以上的决策辅助。第二个层次也就是过程控制的PID调节Agent可以参与参数整定的建议但不应该直接参与闭环。第一个层次运动控制Agent基本没有插手的空间。所以当我们说“实时控制的工业Agent是伪命题”时更准确的表述是Agent在硬实时和部分软实时闭环控制中是伪命题但在生产调度和运维决策的实时性场景中它是有真实价值的。3.2 过程控制中Agent的可行切入点过程控制是一个值得细看的中间地带。以温度PID控制为例现场经常遇到的问题是温度波动大、温差难以收敛。传统的做法是人工整定PID参数或者用自适应PID、模糊PID。这些方法都是在控制回路内部做文章。Agent可以做什么它可以读取历史趋势数据分析波动模式然后给出PID参数的调整建议由工程师确认后下发。这个过程中Agent不直接参与闭环它的输出是建议不是控制量。时间窗口是分钟级甚至小时级Agent有足够的时间做分析。这种模式我称之为“离线分析、在线建议”。它的好处是既利用了Agent的数据整合和模式识别能力又避开了实时性和安全性的问题。工程师仍然是决策的主体Agent是辅助工具。这种模式在技术上没有障碍在工程上也可控。我见过一些团队在做类似的事情把Agent接在历史数据库上让它分析温度曲线的波动特征然后推荐PID参数。效果因场景而异但至少方向是合理的。3.3 报警管理是Agent的天然场景报警管理是另一个Agent能发挥作用的领域。工业现场的一个常见痛点是报警泛滥一个扰动可能触发几十上百条报警操作员根本看不过来。传统的报警管理靠报警抑制和报警分组但规则是人工配置的灵活性有限。Agent可以读取报警流结合工艺知识把相关的报警聚合在一起识别出根因报警抑制衍生报警。这个场景对实时性的要求是秒级到分钟级Agent完全能胜任。更重要的是报警管理的输出是给人看的不直接写控制量。即使Agent判断错了操作员还有机会纠正。这种“人在回路”的设计是当前工业Agent最稳妥的落地方式。它不需要功能安全认证不需要硬实时保障只需要在信息层面把事做对。我个人的经验是报警聚合和根因分析这类场景Agent的投入产出比是最高的因为它直接减轻了操作员的认知负担而且效果容易量化。3.4 设备维护与知识检索的实时性要求更低设备维护和知识检索的场景实时性要求更低通常是分钟级到小时级。比如设备出现异常振动操作员想知道可能的原因和处理方法。传统的做法是查手册、问老师傅、翻历史工单。Agent可以把这些信息整合起来给出一个排序后的可能原因列表和处理建议。这个场景对Agent的推理速度几乎没有要求因为它不参与任何闭环只是信息检索和整合。这类场景的价值在于它把分散在手册、工单、专家经验里的知识激活了。工业现场的知识管理一直是个难题老师傅的经验难以沉淀新员工上手慢。Agent可以作为一个知识入口让这些知识更容易被获取。当然前提是知识库要建好数据要清洗干净否则Agent给出的建议就是垃圾进垃圾出。这一点我在后面还会展开讲。4. 把Agent放在控制回路外当前更务实的架构4.1 分层架构Agent层与实时层的隔离既然Agent进不了实时控制回路那务实的做法就是把它放在回路外面通过分层架构把Agent层和实时层隔离开。典型的架构是底层是PLC/DCS负责实时控制和数据采集中间层是SCADA/Historian负责数据汇聚和监控上层是Agent层负责分析、建议、交互。Agent层通过OPC UA或者REST API从中间层获取数据它的输出回到中间层由中间层或者人决定是否下发到底层。这种分层架构的关键是隔离。Agent层的任何故障、延迟、错误都不能影响底层实时控制的运行。Agent层可以重启、可以升级、可以崩溃底层控制不受影响。这种隔离在工程上是必须的因为Agent的运行时不确定性太高不能让它和实时控制共享同一个故障域。我见过一些项目试图把Agent直接部署在PLC旁边的工控机上通过共享内存或者实时以太网和PLC通信这种做法风险很高因为工控机的操作系统不是实时操作系统它的调度抖动会直接影响通信的确定性。4.2 数据流向从实时数据到Agent输入Agent要做出有意义的分析需要高质量的数据输入。工业现场的数据通常分散在PLC、DCS、SCADA、Historian、MES等多个系统里格式不统一时间戳不对齐质量参差不齐。把数据从这些系统里抽出来清洗、对齐、聚合然后喂给Agent这个工作量往往比Agent本身的开发还大。我个人的经验是在一个工业Agent项目里数据工程的投入至少占60%Agent逻辑的开发占20%剩下的20%是测试和调优。数据流向的设计要考虑几个问题采样频率、时间对齐、数据质量标记、历史数据回溯。采样频率要和Agent的分析需求匹配不是越高越好。如果Agent做的是分钟级的趋势分析那秒级采样的数据就足够了没必要把毫秒级的原始数据全传上来。时间对齐是个麻烦事不同系统的时间戳可能有偏差需要做时钟同步或者插值对齐。数据质量标记也很重要传感器故障、通信中断、人工置数这些情况都要标记出来否则Agent会把脏数据当成真实工况来分析。4.3 输出回路建议如何回到控制层Agent的输出回到控制层有几种模式。第一种是纯建议模式Agent生成建议显示在操作员界面上由操作员决定是否采纳。第二种是审批模式Agent生成建议提交给工程师审批审批通过后由系统自动下发。第三种是受限自动模式Agent在预设的安全边界内自动调整某些参数超出边界则转人工。这三种模式的风险依次递增当前最稳妥的是第一种第二种在部分场景可行第三种需要非常谨慎。受限自动模式在什么场景可行我个人的判断是当调整对象是慢过程、有冗余、有回退机制、且调整范围被严格限制时可以考虑。比如某个辅助系统的温度设定值调整范围被限制在正负2度以内调整速率被限制在每分钟0.1度以内而且有独立的超温保护。这种场景下Agent的自动调整即使出错后果也可控。但即便如此也需要大量的测试和验证不能直接上生产。我见过太多项目在实验室里跑得好好的一到现场就出问题因为现场的工况比实验室复杂得多。4.4 人在回路的设计原则人在回路不是一句口号而是一套具体的设计原则。首先Agent的输出必须可解释操作员要知道Agent为什么给出这个建议依据是什么数据用了什么逻辑。如果Agent只给一个结论操作员没法判断对错就不会信任它。其次Agent的置信度要透明哪些建议是高置信度的哪些是低置信度的要区分开。低置信度的建议应该明确标注提醒操作员谨慎对待。第三操作员的反馈要能回流操作员采纳或拒绝建议的行为应该被记录下来用于后续的优化。第四Agent不能阻塞操作如果Agent响应慢或者故障操作员应该能无缝切换到传统操作方式。这些原则听起来简单做起来难。我见过一些项目Agent的界面做得很炫但操作员根本不用因为Agent的建议不靠谱或者操作员不知道该怎么判断。人在回路的设计核心是建立信任而信任来自于透明、一致、可验证的表现。Agent需要在长时间运行中证明自己的可靠性才能逐步获得更多的自主权。5. 那些被忽略的工程细节从数据质量到模型漂移5.1 数据质量是Agent分析的天花板工业数据的一个特点是“脏”。传感器漂移、通信丢包、时间戳错乱、人工置数、量程配置错误这些问题在现场非常普遍。Agent的分析能力再强如果输入数据是脏的输出就是垃圾。我见过一个案例Agent分析温度趋势得出“温度持续上升”的结论但实际上传感器已经故障输出的是固定值。这种错误如果被操作员采纳后果可能很严重。数据质量的治理需要在数据进入Agent之前就做好。具体来说要做几件事第一对每个测点做范围检查超出物理可能范围的数据要标记为无效。第二做变化率检查如果一个温度值在1秒内跳变50度大概率是通信故障或者传感器故障。第三做时间戳校验检测时间戳的跳变和重复。第四做交叉验证用相关测点互相印证比如流量和差压应该有一致的变化趋势。这些检查不复杂但需要在数据管道里固化下来不能靠Agent自己去判断。5.2 模型漂移与工况变化Agent依赖的模型无论是大模型还是传统的机器学习模型都存在漂移问题。工业现场的工况会变化原料会变化设备会老化季节会影响环境温度。模型在训练时的数据分布和运行时的数据分布可能不一致导致性能下降。这个问题在实验室里不容易发现因为实验室的工况是稳定的但现场是变化的。应对模型漂移需要建立监控机制。具体来说要监控Agent输出的分布如果输出的分布和预期偏离太大就要报警。还要监控Agent的准确率如果准确率持续下降就要考虑重新训练或者调整。在工业场景里重新训练模型不是一件容易的事因为标注数据很难获取而且重新训练后的模型需要重新验证。所以更务实的做法是设计一个鲁棒的Agent它对工况变化有一定的适应能力同时把置信度低的情况交给人工处理。5.3 与现有系统的集成成本工业Agent项目的一个隐性成本是集成。现场已经有PLC、DCS、SCADA、MES、ERP等一堆系统Agent要接入这些系统需要处理各种协议、接口、数据格式。OPC UA是当前比较通用的工业通信标准但不同厂商的OPC UA实现有差异有些老设备根本不支持OPC UA只能通过Modbus或者私有协议接入。这些集成工作琐碎但必要而且往往被低估。我个人的经验是在项目初期就要把集成方案定下来不要等到Agent开发完了再考虑怎么接数据。集成方案要考虑几个问题数据源的协议和接口、数据采集的频率和方式、数据存储的位置和格式、数据访问的权限和安全。这些问题如果不在初期解决后期会变成大麻烦。另外集成方案要尽量标准化避免为每个数据源写一套定制代码否则维护成本会很高。5.4 测试与验证的特殊性工业Agent的测试和互联网软件的测试很不一样。互联网软件可以快速迭代出了问题回滚就行。工业Agent的测试需要覆盖各种工况包括正常工况、异常工况、边界工况、故障工况。测试数据要尽可能真实最好用历史数据回放而不是用模拟数据。测试的指标不仅是准确率还包括响应时间、稳定性、鲁棒性。我见过一些团队Agent在测试集上表现很好一到现场就出问题。原因往往是测试数据太干净没有覆盖现场的噪声和异常。所以测试数据要从现场采集要包含各种异常情况。另外测试要分阶段先在离线环境测试再在影子模式测试也就是Agent运行但不输出只记录它的建议和实际操作对比。影子模式运行一段时间确认Agent的建议靠谱了再进入建议模式。这个渐进的过程虽然慢但能避免很多风险。6. 如果非要做实时控制路径可能是什么样的6.1 把Agent拆开推理与执行分离如果非要在实时控制场景里用Agent一个可能的路径是把Agent拆开把推理和执行分离。推理部分放在非实时环境里慢慢想想好了把结果写到一个共享的、确定性的执行环境里。执行环境是实时安全的它只负责按预定义的规则执行不负责推理。比如Agent分析出某个PID参数需要调整它把调整建议写到一个配置表里实时环境读取这个配置表在下一个控制周期生效。这个过程中Agent不直接参与控制它只是修改配置。这种模式的关键是执行环境必须是确定性的它读取配置、验证配置、应用配置的过程必须是可预测的。配置的验证很重要要确保Agent写入的配置在安全范围内不会导致控制失稳。这需要一套独立的验证逻辑不能依赖Agent自己保证。这种模式在技术上可行但适用范围有限只适合那些参数调整不影响安全、且调整频率很低的场景。6.2 实时操作系统与Agent运行时的结合另一个路径是把Agent的运行时移植到实时操作系统上。实时操作系统能提供确定性的调度如果Agent的推理过程能被分解成确定性的步骤理论上可以在实时操作系统上运行。但问题在于大模型的推理过程本身不是确定性的它的计算量取决于输入无法预先确定。所以即使跑在实时操作系统上推理时间仍然不可预测。除非把模型简化到极致比如用查表代替推理用有限状态机代替神经网络但那已经不是Agent了。我个人的判断是实时操作系统和Agent运行时的结合在可预见的未来不会有实质性的突破。因为两者的设计目标根本不同一个是确定性一个是灵活性。强行结合要么牺牲确定性要么牺牲灵活性都不划算。更务实的做法是承认这个边界在边界内做事。6.3 边缘计算与云边协同的局限边缘计算被很多人视为解决实时性问题的方案。把Agent部署在边缘离设备近延迟就低。这个逻辑没错但边缘计算解决的是网络延迟解决不了推理延迟和调度抖动。边缘设备的算力通常有限跑不了大模型只能跑小模型。小模型的推理时间虽然短但仍然是不确定的。而且边缘设备的操作系统通常不是实时操作系统调度抖动仍然存在。云边协同的思路是实时性要求高的部分放在边缘实时性要求低的部分放在云上。这个思路在架构上是合理的但它没有改变Agent不能参与硬实时闭环的事实。边缘部分如果只是做数据采集和简单规则判断那它就不是Agent如果边缘部分要做Agent推理那它仍然面临实时性的问题。所以边缘计算能改善Agent的响应速度但不能让Agent进入硬实时闭环。6.4 一个可能的折中慢回路Agent与快回路PLC的配合一个更现实的折中是慢回路和快回路的配合。快回路由PLC负责保证硬实时慢回路由Agent负责做优化和调整。快回路和慢回路之间通过设定值或者参数来交互。比如PLC负责温度闭环控制Agent负责根据工况调整温度的设定值。设定值的调整是慢过程分钟级甚至小时级Agent有足够的时间思考。PLC拿到新的设定值后在自己的快回路里执行。这种配合模式的关键是慢回路的输出不能破坏快回路的稳定性。Agent调整设定值时要考虑快回路的动态特性不能给出让快回路失稳的设定值。这需要Agent对控制回路有一定的理解或者至少有一个安全边界来限制Agent的输出范围。这种模式在过程控制里是有实际价值的因为它把Agent的优化能力和PLC的实时能力结合起来了各司其职。7. 我在实际项目里踩过的坑和形成的判断7.1 不要被“实时”这个词忽悠我参与过几个工业智能化项目早期也被“实时”这个词忽悠过。有一次客户要求Agent能在1秒内响应报警并给出处理建议。我们当时觉得1秒很宽松应该没问题。结果实测下来Agent从收到报警到给出建议平均耗时3到5秒最坏情况超过10秒。原因是大模型推理的耗时比预期长而且报警数据从PLC到SCADA再到Agent中间经过了好几层转发每一层都有延迟。后来我们把架构改了Agent不直接接报警流而是接SCADA的报警汇总同时把模型换小响应时间才降到2秒左右。但即便如此1秒的硬指标还是没达到。这个经历让我明白工业场景里的“实时”指标一定要问清楚是哪个环节的实时是端到端的实时还是某个环节的实时差别很大。7.2 数据管道比Agent本身更重要另一个深刻的体会是数据管道的重要性被严重低估。我见过太多项目Agent的算法很先进但数据管道一塌糊涂结果Agent的表现惨不忍睹。数据管道的问题包括数据缺失、时间戳不对齐、单位不统一、量程配置错误、采样频率不一致。这些问题在Demo阶段不容易暴露因为Demo用的是清洗过的数据。一到现场数据管道的问题就全出来了。所以我现在做项目第一件事就是把数据管道理清楚确保数据能稳定、准确、及时地送到Agent面前。数据管道没做好Agent就是空中楼阁。7.3 操作员的信任是慢慢建立的操作员对Agent的信任不是靠演示建立的而是靠日复一日的可靠表现建立的。我见过一个项目Agent的建议准确率其实不低但操作员就是不用因为Agent偶尔会给出明显错误的建议操作员被坑过几次后就不信了。后来我们调整了策略让Agent在置信度低的时候明确说“我不确定”而不是硬给一个建议。同时我们把Agent的建议和操作员的实际操作做对比把对比结果展示给操作员看让操作员看到Agent在大多数情况下是对的。这样运行了几个月操作员才慢慢开始采纳Agent的建议。这个过程急不得信任是一点一点积累的。7.4 安全边界必须独立于Agent最后一个体会是关于安全边界的。Agent的输出必须经过独立的安全校验不能依赖Agent自己保证安全。我见过一个设计Agent直接写PLC的寄存器没有独立的安全校验。这个设计让我很不安因为Agent一旦出错或者被恶意输入影响就可能写出危险的值。正确的做法是在Agent和PLC之间加一层安全校验校验逻辑是独立的、确定性的、经过验证的。Agent的输出先经过校验校验通过才下发。校验逻辑要简单、明确比如范围检查、变化率检查、联锁检查。这层校验虽然增加了复杂度但它是安全的底线不能省。7.5 对当前阶段的判断综合这些经验我对当前阶段的判断是工业Agent在实时控制回路内是伪命题在实时控制回路外是有真实价值的。价值的大小取决于场景的选择和工程的质量。场景选对了数据管道做好了安全边界设好了Agent能实实在在地减轻操作员的负担提高分析的效率。场景选错了硬要把Agent塞进实时闭环那项目大概率会失败而且可能带来安全风险。所以与其争论Agent能不能做实时控制不如把精力放在找到Agent能做好、且现场真正需要的场景上。这才是务实的做法。
