大模型驱动工业设备自主巡检智能体设计与实践

1. 项目目标与需求拆解：先搞明白这个智能体到底要解决什么

1.1 巡检现状：“老师傅现象”背后的三大断点

我在制造行业跑了近十年，和不少设备保全、车间管理的人打过交道。每次聊到“自主巡检”，他们都会先沉默几秒，然后说一句：“设备坏没坏，基本靠老师傅听声音、摸温度。”这句话听着像玩笑，其实就是传统巡检最真实的状态。

传统巡检的流程往往是这样：点检员拿着纸质点检表，按固定路线走一圈，用听音棒、测温枪、震动笔挨个测，凭经验和感官判断设备有没有异常，最后回办公室把数据录入Excel。这套流程有三个致命断点：

第一个断点是数据断裂。巡检记录和故障记录、维修记录、备件更换记录往往分散在不同系统里，点检员看到的问题和维修工单之间没有直接关联，想追溯设备历史状态特别费劲。

第二个断点是响应滞后。一场巡检下来，数据要人工整理、比对趋势、对照阈值，发现苗头到真正触发维护动作，中间可能过了好几天。如果是轴承早期点蚀或者电机绕组绝缘退化这类渐变故障，黄金处理窗口就这么白白浪费了。

第三个断点是经验依赖。老师傅能听出异响、能凭手感判断皮带张力，但同样一条产线，换一个新点检员，可能连续跑了一个月还抓不住关键信号。老师傅退休后，这些经验基本就带走了，企业没有沉淀。

这个项目想做的，不是拿一个监控大屏把数据可视化，而是把这套“眼看、耳听、手摸、脑判”的动作，做成一个能在产线上自主行动的智能体。它既要自动完成路径规划、图像采集、传感器数据融合，还要能输出维护建议、触发工单、记录知识。本质上，它是把一个成熟设备医生的作业流程，固化成一整套人机协作闭环。

1.2 把“自主”落实到三个具体行为

“自主”这个词很容易被滥用。在产品设计阶段，我们把自主拆解成三个必须达成的具体行为，每一个都对应一套技术实现路径：

• 路径自主：智能体不是沿固定路线机械走一圈，而是在每个巡检点根据实时传感器数据和历史状态，动态决定“下一个去哪”。比如某台泵的振动速度有效值连续三次超过预警线，它会自动缩短巡检周期、增加测点密度。

• 任务自主：智能体在发现异常后，不是只拍张照回去，而是自动把检查项扩展。比如红外测温发现电机接线端子温度偏高，它会顺带调整相机焦段，对端子区域做局部放大，并调取最近7天的电流曲线进行关联分析。

• 维护自主：这是最关键的落点。系统不只输出“设备可能有异常”这样的报告，而是直接生成包含故障现象描述、疑似原因分析、建议处理措施、所需备件编码的维护工单草稿，推送到工单系统，由设备工程师确认后转正式工单。

这三个行为一旦跑通，维护工作的重心就从“人找设备”变成了“系统追着问题跑”。设备管理人员的角色也跟着变，不再把时间花在跑腿和数据抄写上，而是花在确认AI的判断、补充专业经验、优化维护策略上。

1.3 为什么选择大模型驱动的智能体方案

这个项目立项时，团队内部有一段讨论：用传统专家系统加上一堆if-else规则，能不能实现自主巡检？技术上完全可以，一些做得好的设备厂商已经在用振动特征库加阈值规则做诊断。但局限也很明显——规则是写死的，现场设备的组合状态千变万化，一条新出现的异常模式可能要触发十几条关联规则，规则维护成本会急剧上升。

大模型的价值不在于它“什么都懂”，而在于它具备三个传统方案不具备的能力：第一，自然语言交互，设备工程师可以直接用口语追问“为什么这台空压机的排气温度比昨天高5度”，而不是去查报表；第二，任务编排能力，它可以像一个项目经理一样，分析目标、拆分步骤、调用不同的感知工具和知识库；第三，经验沉淀能力，历史工单、维修记录、设备手册这些非结构化文档，过去躺在硬盘里没人读，现在可以变成它的领域知识。

不过说实话，大模型在工业现场直接输出维护决策，风险是很大的。我们最终采用的不是“全权委托”方案，而是“大模型做协调与起草，规则引擎做安全兜底”的混合架构。这个决策在后来的实践中证明非常关键，因为它保证了系统在极端情况下仍能按保守策略运行，不会因为模型“自由发挥”而误触设备急停。

2. 智能体整体架构设计：像搭积木一样搭一个会思考的巡检机器人

2.1 四层架构：从传感器到工单系统的完整链路

整个智能体系统我用四层架构来组织，每一层职责单一，层与层之间通过标准化的消息接口通信。这样做的好处是，将来不管换检测算法还是换工单系统，都不会导致整条链路重构。

• 环境交互层：负责与物理世界打交道。核心部件是一台巡检机器人底盘（具备自主导航能力），顶部的多光谱相机模组、声学传感器、温湿度传感器都挂在它身上。层内还有一个协议转换模块，通过OPC UA协议从设备PLC里读取实时数据，比如电流、频率、温度、压力。

• 感知层：把传感器原始数据加工成有语义的信息。图像数据走目标检测、语义分割、异常分类模型，声学数据走异常音频识别，振动数据走频谱分析和特征提取。感知层的输出统一封装成“带时间戳、带空间位置、带置信度的结构化事件”。

• 决策层：这是智能体的“大脑”。由大语言模型担任核心协调器，配合一个规则引擎和一个短时记忆库。决策层接收感知层的结构化事件，结合设备台账、历史工单和历史趋势，判断当前设备健康状态，并决定是否需要调整巡检计划、是否生成维护工单。

• 执行层：负责把决策落到具体动作上。包括导航任务下发、相机云台控制、维护工单推送、消息通知触达等。它通过一套REST API和车间MES、EAM系统对接，工单审批状态由执行层持续跟踪。

下面这张表梳理了四层之间的核心模块和关键接口，便于整体把握：

2.2 计划-执行-反思：让智能体按现场节奏闭环

很多项目做出来是“一次性完成巡检，然后结束”，但真正的智能体应该是一个持续运行的循环。我们把决策层的工作节奏设计为计划-执行-反思三步循环。

计划阶段，大模型根据当天生产计划、设备运行时长、上次巡检结果和天气条件，排出一份动态巡检路线表。比如周末设备停机保养时段，巡检重点就从运行参数转移到异物体遗留、线路松动、油液渗漏等静态异常上；生产高峰时段，转速高、负载大，巡检重点就放在轴承温度、振动烈度和电机电流波动上。

执行阶段，感知层跑视觉模型、声学模型、振动特征对比，把发现的异常事件发给决策层。决策层收到事件后，先走规则引擎做一次“安全校验”，比如温度是否超过硬上限、振动是否达到立即停机标准。通过安全校验后，再由大模型对事件做语义解释和关联分析，判断要不要安排复检。

反思阶段是项目里一个不起眼但价值很高的环节。每次巡检任务结束后，系统会把预测结果与后续维护工单的实际维修结果做一次比对，标记出误报、漏报的案例，自动生成“难例集”，这些难例会回流到感知层的训练流程中。这等于给智能体装了一个持续学习的闭环，时间越用越准。

我举个现场场景来说明这个循环的价值：某天上午，系统检测到一台离心泵的轴承箱温度比正常工况高4度，规则引擎判定未超限，但处于“关注”区间。决策层下令对该泵增加一次高频振动检测，感知层用加速度传感器抓取了一段20秒的振动数据，频谱分析显示在2倍转频处出现明显边带成分，这是典型的轴承外圈早期故障特征。系统随即生成维护工单草稿：建议更换轴承并安排三天内窗口检修，同时附上频谱图和温度曲线。整个过程没有人工巡检介入，但证据链完整、可追溯，工程师只需在电脑前确认工单。

2.3 与MES和工单系统的接口设计：尊重现场既有流程

工业项目最忌讳上来就推倒重来。现场已经有MES系统在跑生产排程，有EAM系统在管工单和备件库存，智能体如果另起炉灶，业务人员根本不愿意用。

我们的做法是采用事件驱动接入。智能体自身维护一个工单状态机，状态包括：草稿生成、推送确认、待审批、已审批、执行中、完成归档、已驳回。每次状态变迁都会回调MES系统的Webhook接口，同时在数据库中记录一条审计日志。这样企业管理人员既能在智能体的Web界面看到实时动态，也能继续在老系统里做审批，不会产生双轨记录对不上的问题。

权限上专门做了分级：智能体生成的工单草稿，必须由设备工程师手动确认后才算正式工单；只有连续三个巡检周期都确认误报的同类事件，才会被自动降级，改为仅推送提醒不生成工单。这个“人审机”的机制一开始看着有点保守，但在实际试运行阶段替我们挡掉了大量不必要的设备停机争议。

3. 感知层实操：视觉检测模型选型与部署实录

3.1 为什么要用“分割加分类”的双段式管线

巡检中最核心的感知任务，是识别设备的跑冒滴漏、异物遗留、仪表读数异常和结构松动。刚开始做视觉方案时，有人建议直接用YOLO一类目标检测模型做端到端的异常识别，一张图直接框出所有异常区域。

试跑之后我们发现了一个问题：异常种类在产线上是长尾分布。漏油、锈蚀、螺栓松动这些高频问题样本充足，效果还行；但破损的压力表表盘、变形的防护罩支脚、非标的临时接线板这类低频异常，样本根本不够训练。而且目标检测模型的输出是一个大矩形框，很难精确告诉维护人员“到底是法兰面渗漏还是焊缝裂纹渗漏”。

所以我们改用了分割加分类的双段式管线。第一段用轻量级语义分割模型，把图像中的设备主体、管道、法兰、仪表盘、地板区域逐个分割出来。分割的意义在于定位，它把大图切成了一个个语义上独立的ROI区域。第二段再针对每个ROI区域单独跑异常分类模型，判断这个区域是否出现异常以及异常类型。

这套方案有一个实实在在的好处：新增异常类型时，不用重新训练分割模型，只需要给第二段的分类器补充几千张样本就能上线。而且不同区域可以用不同的分类模型，比如仪表盘区域专门用一个针对表盘读数模糊、破损、遮挡训练的模型，法兰区域用另一个针对渗漏训练的模型，故障识别的粒度比端到端一个框精细得多。

3.2 关键参数选择与推理上线：实测下来很稳的一套配置

这里分享一套我们最终上线的配置。视觉推理模型统一导出为ONNX格式，部署在边缘计算盒子上，不依赖云端，满足车间网络不稳定的约束。

图像输入统一缩放为640×640分辨率，这个尺寸是速度和精度的平衡点：再大分辨率对小目标识别有帮助，但推理帧率会从25帧降到12帧左右；再小的话，仪表盘的读数细节会丢失。分割模型采用轻量级骨干网络，推理耗时约28毫秒。分类模型更轻，单ROI推理耗时约8毫秒。整个巡检周期中，机器人在每个点位的停留时间控制在15秒内，足够完成两套检测并回传结果。

下面是一段简化的推理代码，展示了整个管线的数据流：

import cv2 import numpy as np import onnxruntime as ort # 加载分割模型与分类模型 seg_session = ort.InferenceSession("seg_model.onnx") cls_session = ort.InferenceSession("cls_model.onnx") def preprocess(image): img = cv2.resize(image, (640, 640)) img = img[:, :, ::-1] # BGR转RGB img = img.astype(np.float32) / 255.0 img = np.expand_dims(img, axis=0) return img def get_roi_boxes(binary_mask, min_area=800): contours, _ = cv2.findContours(binary_mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) boxes = [] for cnt in contours: area = cv2.contourArea(cnt) if area < min_area: continue x, y, w, h = cv2.boundingRect(cnt) boxes.append((x, y, w, h)) return boxes def infer(image_path): img = cv2.imread(image_path) input_tensor = preprocess(img) seg_out = np.squeeze(seg_session.run(None, {"input": input_tensor})[0]) # seg_out形状为(640, 640)，分类别掩码，这里取“设备本体”通道 mask = (seg_out > 0.5).astype(np.uint8) boxes = get_roi_boxes(mask) results = [] for (x, y, w, h) in boxes: roi = img[y:y+h, x:x+w] roi_resized = cv2.resize(roi, (224, 224)) roi_tensor = preprocess(roi_resized) cls_out = cls_session.run(None, {"input": roi_tensor})[0] cls_id = int(np.argmax(cls_out)) score = float(np.max(cls_out)) if score >= 0.6: results.append({"bbox": [x, y, w, h], "class_id": cls_id, "score": score}) return results

代码里有两个容易被忽略的经验点。第一，ROI的最小面积阈值要设成800像素，太小会把远处无关的背景噪声也框进来，后期误报率会高得让人头疼。第二，分类置信度阈值取0.6，不是越高越好。试过把阈值提到0.8，误报是少了，但很多真异常也被压掉了，每天漏检率明显上升。0.6这个值是在误报和漏检之间折中出来的，不同车间可以根据自己的容错偏好微调。

相机安装位置也是个大坑。最早我们把相机装在机器人云台的正上方固定高度，结果发现机器人靠近高大的罐体时，由于视角遮挡，底部法兰区域完全拍不到。后来把相机模组改成了可独立俯仰控制的云台，在巡检编排过程中根据设备高度动态调整俯仰角。这个改造看起来很小，对异常检出率的提升却是决定性的。

3.3 数据闭环：让模型记住现场难例

模型上线只是开始，真正让感知越用越准的，是数据闭环。我们的设计思路是：推理结果中置信度在0.4至0.6之间（即分类置信度阈值附近的样本）会自动被标记为“待人工复核”，连同原图、热力图标、检测框一起生成复核任务，推送到Web端。设备工程师在复核时只需要点“确认异常”或“误报”，这些带标签的样本就会自动进入难例集，每周汇入训练数据池。

这个机制在实践中非常有价值。最初一个月，系统每天会产生大量复核任务，工程师有点抵触，觉得增加了工作负担。但坚持几周后，模型漏检率从最初的点检路线覆盖不足阶段一路下降到稳定水平，复核任务量也从每天上百条骤降到不到十条。工程师尝到了甜头，后来甚至会主动补充标注他们认为系统可能漏掉的细节场景。

4. 决策层实操：健康评估、故障诊断和维护工单生成

4.1 温升、振动、油液三项指标如何融合成健康分

健康评估是决策层的核心任务。我们采用一套可解释的评分机制，而不是直接把数据丢给大模型“黑箱输出”。目前覆盖了三个核心维度：温升、振动和油液状态。

温升评估采用相对阈值法，不看绝对温度，看的是设备在当前负载下相对历史平均温度的偏移量。某台电机今天40度，昨天42度，这并不代表异常；但如果它在相同负载下比历史同工况平均温度高了8度以上，系统会判定为“关注”。因为绝对温度受季节、负载影响太大，用相对偏移更抗干扰。

振动评估参照ISO 10816标准，以振动速度有效值为基础分级。标准里不同功率等级的设备对应不同的A、B、C、D评估区，我们把这套分级转成了规则：处于A区为健康，B区为关注，C区为预警，D区为立即报警。规则引擎这边会直接拦截D区事件，不允许模型把它误判成低风险。

油液状态评估相对复杂，不是每个点位都有在线油液传感器，很多设备只能靠定期取样。智能体在巡检计划里会自动安排“油液取样提醒”，并在油液实验室数据回传后，把黏度、酸值、水分、铁磁颗粒浓度等指标纳入评分。

三项指标的融合公式是：

健康分 = 70 - 温升扣分 - 振动扣分 - 油液扣分

满分为70分是刻意设计的，扣分项明细都会显示在评估报告里，方便维护人员定位到具体异常维度。比如一台齿轮箱最终的评分是48分，报告会清楚列出来：温升项扣8分，振动项扣10分，油液项扣4分。维护人员一眼就能看出最需要关注的环节，完全不用猜。

这里有一个重要的设计决策：为什么健康评估不用纯大模型来判断？因为大模型的输出概率不具备稳定可复现性，今天同样的输入可能得到48分，明天可能变成52分。评分结果要作为工单审批的依据，必须稳定、可解释、可审计。所以评分逻辑全部走规则引擎，大模型只负责给评分结果配“人话解读”。

4.2 维护工单自动生成：从自然语言草稿到结构化字段

大模型在这个环节发挥的价值最直观。当感知层和规则引擎共同确认一个设备处于“预警”或“报警”状态后，大模型会负责起草维护工单。这不仅是写一段“设备有异常”的简单描述，而是要生成一张结构完整、可直接执行的工单：

工单草稿生成后，系统不会直接推送，而是先自动检查一个容易出问题的地方：备件编码是否存在、工单内容是否包含至少一项“故障现象描述”。如果校验失败，工单会卡在“草稿”状态并通知维护管理员处理，而不是带着错误数据往下走。

4.3 大模型的知识增强：用检索增强生成压住幻觉

工厂里的设备手册动辄几百页，历史维修工单分布在各个系统里，过去想查一台老设备的维修记录，得先问老师傅“这设备什么时候修的，换过什么件”。我们把这块做成了大模型的知识底座，用检索增强生成（RAG）来提升故障诊断的准确率。

操作路径是这样的：先把设备手册、历史维修工单、故障案例库、备件手册统一做清洗、分块、向量化入库。大模型在处理一个诊断请求时，先根据设备编码和异常症状检索最相关的知识片段，再把检索结果作为上下文，要求大模型在引用时标注来源文档编号。

这个方案最大收益是大幅降低了“一本正经胡说八道”的情况。试运行初期，在没有检索增强的时候，大模型回答“这台设备是否需要立即停机”这类问题时，偶尔会给出不合逻辑的建议。加了知识库引用机制后，所有回答都附带来源文档，维护人员可以一键跳转核实，信任度完全不一样了。

5. 部署实录、常见问题排查与避坑经验

5.1 边缘部署架构与断网降级策略

整个系统在车间内的部署形态是一个“边缘盒子加服务器”的组合。视觉推理模型跑在现场的边缘计算盒子上，盒子的算力配置是8核CPU加一块入门级GPU，内存16GB，实测能稳定跑完整套分割加分类流程。决策层的大模型部署在厂区机房的服务器上，通过内网访问，不依赖外网。

断网降级是制造业现场不得不面对的问题。车间网络偶尔抖动是常态，甚至有几次交换机故障导致长时间断网。我们的处理策略是在边缘盒子本地维护一个任务队列：断网期间，感知层的检测结果先写入本地SQLite数据库，巡检机器人继续按计划执行巡检任务，决策层的评估延迟到网络恢复后再补做。维护工单也会在网络恢复后自动补推，不会因为网络抖动就漏掉一次巡检任务。

这个策略在试运行阶段经历过一次真实考验：某个周末夜间，车间网络因交换机重启中断了约45分钟，系统在这期间自动完成了9个巡检点位的图像采集和异常分类，其中发现了一个液压站油管渗漏事件。网络恢复后，系统立即推送了工单草稿，第二天早班的设备工程师确认了故障并安排处理。如果没有本地任务队列，这个渗漏可能会被掩盖到周一白班才被发现。

5.2 我踩过的几个坑：误报、漏检、光照突变

第一个坑是误报率初期高得离谱。上线第一周，系统每天上报的“疑似渗漏”事件超过50条，车间都被烦透了。排查发现，问题出在夜间车间的自动照明切换。凌晨时段照明灯从高亮度切换到低亮度时，地面反光产生了很多类渗漏纹理，把分割模型骗了。解决办法是在图像预处理里加了一层曝光补偿，并且把“多帧确认”逻辑加上：单张图片检出异常不算，必须同一ROI区域连续两帧以上检出同类型异常才触发上报。加了这两道保险后，误报率直接降到了原来的十分之一。

第二个坑是低频异常样本太少，分类器死活学不会。裂开的仪表盘玻璃、断了一根的防护网、变形的设备铭牌支架——这些异常类型在工厂里确实存在，但出现频次太低，训练样本常年不够。后来我们调整了策略，不再追求把所有异常类型都识别出来，而是先保证最常见的五类（渗漏、锈蚀、异物体遗留、螺栓松动、仪表异常）识别准确，低频异常统一归入“其他异常”类别，依靠人工复核确认。这是一次务实的取舍，把有限的标注人力集中在了价值最高的事情上。

第三个坑是巡检机器人绕路导致任务超时。机器人导航系统在最开始使用的是预先录制路线的方案，一旦现场堆放了临时物料，路线就堵死了，任务卡在那里超时。后来换成视觉加激光雷达融合的动态规划，机器人现场重新规划路径的能力大幅提升。这个改造带来的侧收益是：巡检路线不再固定模板化，不同班次的巡检覆盖重点可以随生产状态动态调整，和决策层的“计划”阶段配合更顺畅。

5.3 常见问题速查表：先收藏再调试

这里整理了一份问题排查表，按我自己的排障优先级排列：

我特别想强调第一条。误报是智能巡检项目推进过程中最能瓦解信任的问题。一旦车间觉得系统整天虚惊一场，后续所有报警消息都会被习惯性忽略，这个智能体就废了。所以在任何优化工作之前，先投入精力把误报率压到最低，这是系统存活的生命线。

5.4 后续可以往哪些方向扩展

目前这套系统的巡检对象是车间内固定位置的设备，后续可以扩展的方向还有不少。

一个是把设备工艺参数纳入健康评估。现在主要依赖图像、振动和温度信号，但很多设备故障的早期信号藏在电流谐波、压力波动、流量曲线里。这些数据PLC里都有，只是没有进入评估模型。把工艺参数接入后，健康评估的响应速度还可以再提前一步。

另一个是结合数字孪生做维护预案演练。现在系统只能生成工单、安排维护，但维护过程本身的质量风险没有覆盖。如果能把关键设备的拆装步骤、扭矩参数、作业空间约束建模成数字孪生场景，智能体在生成工单的同时，还能给维护人员提供一套可视化作业指引，降低误操作概率。

还有一个值得关注的点是多机协同。现在是一台巡检机器人覆盖一个车间，将来如果多台机器人协同覆盖整个厂区，任务调度复杂度会跨数量级上升，这会催生出一个“机群管理”层面新的智能体需求。

我个人的体会是，自主巡检和维护智能体这类项目，能不能从Demo走向长期稳定运行，关键的不是模型多强、算力多猛，而是三个很基础的事情做得怎么样：误报率有没有压到车间能接受的水平，输出信息维护人员能不能看得懂、信得过，以及整个系统有没有把现场老师傅的经验真正沉淀下来变成团队的资产。我们在项目里收获最大的，不是模型精度数字变好看，而是老师傅从质疑系统，到后来主动提出某某点位也应该加进巡检清单。这个过程让我意识到，所谓智能体落地，本质上是一场人与系统的信任共建——系统负责不知疲倦地盯住每一处细节，而人的判断和经验，永远是这个闭环里最后一道防线。