1. 工业智能体为什么要“拆场景”而不是“造万能”1.1 从“一任务一智能体”这个提法说起“一任务一智能体”被写进官方报告这件事在工业圈子里引起的讨论比很多人想象的要大。过去两年大家聊智能体习惯性地往“通用”“全能”“一个大脑管所有”的方向靠仿佛只要模型足够大、上下文足够长就能把工厂里所有事都包圆。但真正下过车间、跟过产线的人心里都清楚工业现场最不缺的就是“意外”最怕的就是“一个东西管所有”。“一任务一智能体”本质上是一种工程化的克制。它承认了一个现实在工业环境里任务的边界、输入的格式、输出的验收标准、异常的处理路径全都是高度确定的。与其让一个庞然大物去猜不如把每个确定的任务交给一个专门的智能体去盯。这就像工厂里不会让一个工人同时干焊接、质检和物流而是每个工位有每个工位的职责和操作规范。我最早接触这个思路是在一个设备巡检的场景里。当时团队尝试用一个通用智能体去处理“读仪表、判断异常、生成工单、通知责任人”这一整条链路结果发现光是“读仪表”这一件事不同表盘的反光、角度、污渍就够喝一壶的更别说后面还要对接不同的工单系统和通知渠道。后来拆成四个独立智能体每个只负责一件事反而整体跑通了。这个经历让我彻底理解了“拆场景”的价值。1.2 工业场景的确定性决定了智能体的边界工业互联网和消费互联网有一个根本区别消费互联网容忍模糊工业互联网追求确定。你给朋友推荐一首歌推错了顶多被吐槽但你在产线上判断一个轴承是否合格判错了就是批量报废。这种确定性要求直接决定了工业智能体不能走“大而全”的路子。具体来说工业场景的确定性体现在三个层面。第一是输入确定性传感器的读数、PLC的状态、MES的工单格式和协议都是提前定义好的不需要智能体去“理解”太多。第二是输出确定性一个质检智能体的输出就是“合格/不合格/待定”外加置信度和依据不需要它写一篇小作文。第三是流程确定性什么条件下触发什么动作在工业里往往是写进SOP的智能体的角色是执行和判断而不是发明流程。正因为这三层确定性把一个复杂流程拆成多个单一任务智能体反而比一个大智能体更容易验证、更容易维护、更容易追责。你可以单独测试“读表智能体”的准确率单独优化“判断智能体”的阈值单独替换“通知智能体”的渠道而不用担心牵一发动全身。1.3 拆场景带来的三个直接收益第一个收益是可验证性。单一任务智能体的输入输出边界清晰你可以用历史数据回放来验证它的准确率。比如一个“焊缝缺陷识别智能体”你可以拿过去半年的焊缝图像做回归测试算出它的漏检率和误检率。但如果你用一个通用智能体去干这件事你很难说清楚到底是“看”错了还是“判断”错了。第二个收益是可替换性。工业现场的硬件和软件迭代周期很长但AI模型迭代很快。拆成单一任务后你可以只替换“识别”那一段的模型而不动后面的工单逻辑。这在实操中非常关键因为很多时候你只是想升级一下视觉模型不想把整个系统推倒重来。第三个收益是可解释性。当产线上出现一个误判你需要快速定位是哪个环节出了问题。单一任务智能体的日志是干净的输入是什么、输出是什么、中间用了什么规则一目了然。而通用智能体的日志往往是一大坨推理过程排查起来非常痛苦。注意拆场景不等于拆得越细越好。拆分的粒度应该以“一个智能体能独立完成一个可验收的任务”为标准拆得太细会导致智能体之间通信开销过大反而降低整体效率。2. 工业Agent的核心技术点与场景拆解方法2.1 工业Agent和通用Agent的本质差异很多人把工业Agent理解成“通用Agent加个工业知识库”这个理解偏差很大。工业Agent和通用Agent在架构上的差异比很多人想象的要深。通用Agent的核心能力是“理解和生成”工业Agent的核心能力是“感知和决策”。前者追求的是语言上的流畅和合理后者追求的是行为上的准确和可追溯。具体到技术栈工业Agent通常需要以下几层能力。最底层是协议适配层负责对接Modbus、OPC UA、MQTT等工业协议把物理世界的数据变成智能体能理解的格式。往上是感知层包括视觉识别、时序异常检测、语音指令解析等。再往上是决策层根据感知结果和预设规则做出判断。最上面是执行层把决策结果转化成工单、指令或通知。通用Agent往往只有决策层和执行层感知层和协议适配层是缺失的。这就是为什么很多通用Agent在工业现场“水土不服”——它根本拿不到干净的数据也发不出正确的指令。2.2 场景拆解的四个维度拆场景不是拍脑袋我总结了一套四个维度的拆解方法在实际项目中反复用过比较靠谱。第一个维度是数据源。如果一个任务需要同时处理视觉数据、时序数据和文本数据那它大概率应该拆成多个智能体。因为不同数据源的处理链路差异很大混在一起会让模型很难收敛。比如“设备故障诊断”这个任务如果既要看振动波形又要看维修记录还要看操作日志那就应该拆成“波形分析智能体”“记录检索智能体”和“综合判断智能体”。第二个维度是决策频率。高频决策和低频决策应该分开。比如“实时控制”可能需要毫秒级响应“生成日报”可能一天一次。把这两种任务放在一个智能体里会导致资源分配非常尴尬。第三个维度是验收标准。如果一个任务的验收标准是“准确率大于99%”另一个是“响应时间小于100毫秒”那它们应该拆开。因为这两个标准对应的技术方案完全不同一个可能需要大模型一个可能只需要规则引擎。第四个维度是责任归属。在工业环境里出了问题要能找到责任人。如果一个智能体同时管“质检”和“排产”出了问题是质检的锅还是排产的锅拆开之后责任清晰追责容易。2.3 拆解后的智能体如何协同拆开之后智能体之间需要协同。这里有两种主流模式。一种是编排式由一个编排器Orchestrator按照预设流程调用各个智能体。这种模式适合流程固定的场景比如“巡检-判断-工单-通知”这条链路。另一种是协商式多个智能体通过消息传递来协商出一个结果。这种模式适合流程不固定、需要动态决策的场景比如“多设备协同调度”。在工业场景里编排式是主流。因为工业流程本身就是高度结构化的用编排器来管理反而更可控。编排器的实现可以用LangGraph这类框架也可以用简单的状态机。关键是要把每个智能体的输入输出定义清楚让编排器知道什么时候调用谁、传什么参数、拿什么结果。提示编排器的日志一定要单独存一份而且要包含每个智能体的调用时间、输入输出和耗时。这是后期排查问题的命根子。3. 从零搭建一个工业场景智能体的实操过程3.1 场景选择与任务定义假设我们要做一个“电机轴承异常检测”的场景。这个场景在工业里非常典型几乎每个工厂都有电机电机坏了往往就是轴承先出问题。传统做法是靠老师傅听声音或者定期拆检成本高且不及时。用智能体来做可以做到实时监测和早期预警。任务定义要非常具体输入是电机轴承的振动信号采样频率是10kHz每次采集1秒的数据输出是“正常/异常”的判断外加异常类型内圈故障/外圈故障/滚动体故障和置信度。验收标准是异常检出率大于95%误报率小于5%。这个任务看起来简单但拆开来看其实包含了好几个子任务数据采集、信号预处理、特征提取、故障分类、结果上报。按照“一任务一智能体”的思路我们可以把它拆成三个智能体采集智能体负责从传感器拿数据并做初步清洗诊断智能体负责特征提取和分类上报智能体负责把结果写到MES并通知相关人员。3.2 数据采集与预处理智能体的实现采集智能体的核心工作是把原始振动信号变成干净的、可用的数据。这里有几个坑要注意。第一个坑是采样同步如果多个传感器不同步后面的特征提取会出问题。第二个坑是工频干扰电机本身的50Hz工频会淹没很多故障特征需要做陷波滤波。第三个坑是数据缺失工业现场网络抖动是常态要有重传和补采机制。具体实现上可以用Python写一个采集服务通过OPC UA或Modbus从PLC拿数据然后用NumPy做滤波和归一化。代码大概长这样import numpy as np from scipy import signal def preprocess_vibration(raw_signal, fs10000, notch_freq50): # 陷波滤波去除工频干扰 b, a signal.iirnotch(notch_freq, Q30, fsfs) filtered signal.filtfilt(b, a, raw_signal) # 归一化 normalized (filtered - np.mean(filtered)) / (np.std(filtered) 1e-8) return normalized这个智能体的输出是一段干净的时序数据直接传给诊断智能体。注意这里不要做太多处理特征提取留给下一个智能体保持职责单一。3.3 诊断智能体的模型选型与训练诊断智能体是整个链路的核心。模型选型上我试过三种方案传统机器学习SVM、随机森林、一维卷积神经网络1D-CNN、以及基于Transformer的时序模型。实测下来1D-CNN在轴承故障诊断这个任务上性价比最高训练快、推理快、准确率也够。特征提取方面不要只给模型原始波形要加上时域和频域特征。时域特征包括均方根、峰值、峭度、裕度等频域特征包括包络谱的峰值频率。这些特征对轴承故障非常敏感能显著提升小样本下的准确率。训练数据方面公开数据集可以用凯斯西储大学CWRU的轴承数据集做预训练然后用自己工厂的数据做微调。这里有个经验微调时学习率要调小否则容易把预训练学到的通用特征覆盖掉。我一般用1e-4到1e-5之间的学习率训练轮数控制在20轮以内。模型训练好之后导出成ONNX格式方便在不同平台上部署。推理时诊断智能体接收采集智能体传来的数据输出故障类型和置信度。如果置信度低于阈值就标记为“待人工确认”而不是强行给一个结论。3.4 上报智能体与工单系统的对接上报智能体看起来简单其实最容易出问题。因为它要对接的是工厂里各种老旧的系统接口五花八门。我遇到过用SOAP的、用FTP传文件的、甚至还有用串口的。所以上报智能体的设计原则是适配器模式把不同系统的对接逻辑封装成独立的适配器智能体本身只负责决定“报什么”和“报给谁”。具体流程是诊断智能体输出异常结果后上报智能体先查一张配置表看这个设备对应哪个责任人、哪个工单系统。然后调用对应的适配器把异常信息写进去。如果写入失败要有重试机制重试三次还失败就降级到邮件或短信通知。这里有个细节工单内容要包含诊断依据。不要只写“轴承异常”要写“包络谱在120Hz处出现峰值判断为外圈故障置信度92%”。这样维修人员拿到工单后能直接定位问题而不是重新拆一遍。4. 工业智能体落地中的常见问题与排查技巧4.1 模型在实验室好用、到现场就拉胯这是最经典的问题。实验室数据干净、工况单一现场数据噪声大、工况多变。我踩过的坑包括传感器松动导致信号漂移、电机负载变化导致特征频率偏移、环境温度变化导致传感器灵敏度下降。排查思路是先看数据、再看模型。把现场数据和实验室数据放在一起对比看分布差异有多大。如果差异主要在噪声水平那就加强预处理如果差异在特征频率那就做工况归一化如果差异在数据缺失那就补采集逻辑。一个实用的技巧是在线监控输入分布。在诊断智能体前面加一个“数据质量检查”模块实时计算输入数据的均值、方差、峭度等统计量如果偏离训练集分布太多就触发告警而不是硬着头皮推理。4.2 智能体之间通信延迟导致整体响应慢拆成多个智能体后通信开销是绕不开的。我见过一个项目三个智能体串行调用每个耗时200毫秒加起来就600毫秒对于实时控制来说太慢了。解决办法有两个。一是并行化如果两个智能体之间没有依赖关系就并行调用。比如“读振动数据”和“读温度数据”可以同时进行。二是边缘部署把延迟敏感的智能体部署在边缘设备上减少网络传输时间。实测下来边缘部署能把整体延迟从600毫秒降到150毫秒以内。还有一个技巧是批处理。如果多个设备的数据可以一起处理就攒一批再调用摊薄通信开销。但批处理会引入等待时间要根据场景权衡。4.3 智能体版本升级导致下游系统崩溃工业系统最怕的就是“升级一个、崩一片”。智能体升级时如果输出格式变了下游的工单系统、报表系统可能直接报错。我的做法是接口版本化。每个智能体的输入输出都带一个版本号升级时先发新版本让下游系统并行运行一段时间确认没问题后再切流量。同时智能体的输出要向后兼容新增字段可以但不能删字段或改字段类型。另外升级前一定要做回归测试。用历史数据回放对比新旧版本的输出差异。如果差异超过阈值就要分析原因确认是改进还是退化。4.4 常见问题速查表问题现象可能原因排查方法解决措施诊断准确率骤降传感器故障或松动检查传感器安装和信号质量重新安装或更换传感器推理延迟突然增大边缘设备资源被占用查看CPU/内存/GPU使用率限制其他进程或升级硬件工单重复生成上报智能体重试逻辑有bug检查重试条件和幂等性加入去重键和幂等控制智能体之间数据不一致时钟不同步检查各节点NTP状态统一时钟源模型输出置信度普遍偏低输入分布偏移对比训练集和现场数据分布重新训练或做域适应注意工业现场的“重启大法”往往不管用因为问题可能出在数据源头。遇到异常先查数据再查模型最后查代码。5. 工业智能体的未来演进与个人实践体会5.1 从“一任务一智能体”到“智能体流水线”“一任务一智能体”是起点不是终点。当工厂里有了几十个甚至上百个单一任务智能体之后如何管理它们、如何让它们协同就成了新问题。我判断接下来的趋势是智能体流水线就像工厂里的流水线一样每个智能体是一个工位物料数据在工位之间流动每个工位只做自己那道工序。这种流水线模式的好处是可编排、可监控、可优化。你可以看到每个工位的吞吐量、良品率、等待时间然后针对性地优化瓶颈工位。这比一个大智能体黑盒要好得多。要实现流水线需要一套智能体注册与发现机制让每个智能体知道上下游是谁还需要一套数据契约定义工位之间传递的数据格式最后需要一套监控告警系统实时看每个工位的状态。5.2 数字孪生在智能体协同中的角色数字孪生和工业智能体是天然搭配。数字孪生提供的是一个可试错的虚拟环境智能体可以在里面反复训练和验证而不用担心影响真实产线。我做过一个项目把诊断智能体先在数字孪生里跑了三个月的历史数据回放确认准确率达标后才上真实产线上线后一次故障都没误报。数字孪生的三层架构物理层、模型层、应用层和智能体的分层架构可以对应起来。物理层对应数据采集智能体模型层对应诊断和预测智能体应用层对应上报和决策智能体。这种对应关系让整个系统的设计变得非常清晰。5.3 我在实际项目中的几点体会第一不要追求一步到位。我见过太多项目想一开始就搭一个大而全的系统结果半年过去了还在调数据接口。正确的做法是先做一个最小的单一任务智能体跑通闭环然后再复制扩展。第二数据质量比模型重要。在工业场景里一个干净的数据源加上一个简单的模型往往比一个脏数据源加上一个复杂模型效果好。所以前期一定要花时间把数据采集和预处理做扎实。第三人机协同比全自动更现实。工业现场对误判的容忍度很低所以智能体的定位应该是“辅助人”而不是“替代人”。高置信度的结果自动处理低置信度的结果转人工确认这样既提高了效率又控制了风险。第四日志和可观测性是生命线。智能体上线后你不可能盯着每一帧数据看所以必须有一套完善的日志和监控。我一般会在每个智能体的输入输出、推理耗时、置信度分布上都打点然后用Grafana做看板一旦有异常趋势就能提前发现。第五别忽视组织因素。工业智能体落地最大的阻力往往不是技术而是人。老师傅可能觉得你在挑战他的经验操作工可能觉得你在增加他的工作量。所以项目早期就要让一线人员参与进来让他们觉得这个智能体是来帮他们的而不是来替代他们的。这个方向还在快速演进每隔几个月就有新的框架和工具出来。但底层逻辑是不变的把确定的任务交给确定的智能体让每个智能体只做一件事并把它做好。这个原则我觉得在未来几年都不会过时。
