凌晨两点车间主任打电话说三号产线停了。排查到天亮发现是减速机轴承保持架碎了备件没有供应商当天还送不了货——那条产线一天产值几十万就这么干等着。这种场景在制造业待过的人都懂。设备“不坏不修”是事后维修按固定周期换件是定期维护本质上都是在赌概率。真正想要的是预测性维护靠数据把“设备快坏了”这件事提前识别出来在故障发生前安排停机检修。这篇就把我用 OpenClaw 加 DeepSeek 加 Prometheus 从零搭的一套可落地原型讲清楚代码全部可复现。适合正在做设备运维数字化、想引入智能体又不知道怎么串流程的工程师也适合对“大模型怎么落地到工控场景”感兴趣的开发者。整个方案的核心思路很简单传感器数据进 Prometheus模型算异常分数OpenClaw 当大脑做任务编排DeepSeek 负责把技术信号翻译成人话最后自动发告警、生成维护建议。下面按我的实际搭建顺序展开。1. 机制选型拆解为什么是这个三件套1.1 预测性维护要解决的真实痛点先看看传统维护模式的问题在哪。事后维修最大的问题是停机成本不可控。设备坏了才修生产已经停了备件往往也没有维修时间完全取决于故障复杂度和供应链响应速度。定期维护则容易陷入两个极端换早了浪费换晚了照样坏。我见过不少工厂的“计划性保养”其实就是按日历换油、换轴承根本不管设备实际状态成本不低效果肉眼看不出来。预测性维护把问题变成三个环节环节要解决的问题典型手段数据采集设备当前状态能不能被量化振动、温度、电流、转速传感器状态识别异常信号能不能被提前发现时域频域特征、异常检测模型决策闭环发现异常后怎么办告警、诊断报告、维护工单前两个环节业内已经很成熟真正难的是第三个。设备报警了给谁报报什么内容要不要立刻停机还是继续观察这些问题过去只能靠老师傅经验现在正好可以交给智能体去组织信息、调用工具、生成可执行的维护建议。1.2 三件套各自的角色定位OpenClaw、DeepSeek、Prometheus 三个组件一开始看起来不像一个生态里的东西但用顺了会发现它们恰好互补。Prometheus 负责“记”。它天生就是干时序数据监控的采集传感器指标、存指标、算告警规则都顺手。设备振动值、温度、电流这些数据本质上就是时间序列塞进关系型数据库反而别扭Prometheus 这种按时间组织的数据模型天然契合。OpenClaw 负责“编”。它是一个开源智能体编排框架能定义 Agent、配置工具调用、编排多步工作流。简单说它可以在检测到异常后自动完成一串动作查历史指标、调模型算分、组装上下文、呼叫大模型分析、最后把结果发到企业微信或钉钉。如果没有这一层你得自己写一堆胶水代码把各个环节黏起来。DeepSeek 负责“说”。模型算出来一个异常分数0.87这个数字对维修工来说没有意义。DeepSeek 的作用是把“分数0.87振动频谱出现2倍频边带温度上升5度”翻译成“疑似轴承外圈磨损建议停机检查并准备替换件”这才是维修班组能直接拿来做事的信息。用 DeepSeek 主要是推理成本低、响应快中文表达也贴合工厂实际场景。三者的关系可以类比成一个值班团队Prometheus 是仪表盘和记录仪OpenClaw 是值班调度员DeepSeek 是那个能把技术问题讲明白的专家。1.3 为什么不选更常见的组合前期也考虑过其他方案简单说下取舍。第一种是“MQTT规则引擎”。够轻但规则引擎只能覆盖“特征值超限”这种显式逻辑应付不了多参数耦合的早期故障。比如振动值和温度单独看都在正常范围但两者联合趋势异常规则引擎需要人为穷举组合写起来没完没了。第二种是“自研监控模板报告”。监控部分倒是不难但报告一旦要结合上下文动态生成模板就僵了。模板只能把固定字段填进固定文本故障描述稍微复杂一点就不适用而且没法回答维修工的追问。第三种是“全链路大模型处理”。把原始数据直接丢给大模型做判断看着很酷实际不可靠。时序特征的数值精度、告警判定这种逻辑密集型的活儿大模型并不擅长而且成本高。正确做法是大模型只做最后一步语义分析前面交给确定性的算法和规则。2. 整体架构与数据流设计2.1 系统五层架构我在实际项目里按五层来组织系统每层职责单一方便单独替换和测试。第一层是数据采集层。设备侧装传感器常见的有振动加速度传感器、温度探头、电流互感器。现场设备通过 PLC 或工业网关汇聚数据再走 Modbus/TCP 或 OPC UA 到边缘网关。原型阶段没有真实传感器的话可以用脚本模拟波形数据后面细说。第二层是指标存储层。统一走 Prometheus 的指标模型设备标识放在 label 里例如machineCNC_03。推数据用 Pushgateway查询用 PromQL。第三层是特征与模型层。定时任务从 Prometheus 拉原始波形指标计算时域频域特征调用训练好的异常检测模型得到健康分数。这一层输出的是标准化数字不带业务含义。第四层是智能体编排层。OpenClaw 监听模型层的输出达到阈值就触发工作流。工作流内部会先收集上下文再调用 DeepSeek 生成诊断结论最后决定通知级别和内容。第五层是通知与展示层。告警消息走 Alertmanager 分发到企业微信/钉钉/邮件同时把模型分数和事件记录推给 Grafana 做可视化。管理层看趋势维修组收任务各取所需。2.2 数据流转的关键路径最核心的一条链路是这样的传感器采集的振动原始波形经边缘网关汇聚后以 5 秒间隔推送特征值和原始波形摘要到 Prometheus。模型服务每 30 秒拉取最近时间窗口的数据计算特征向量并调用模型得到健康分后写回 Prometheus。OpenClaw 的定时 Job 每 30 秒执行一次检查动作用 PromQL 查模型健康分。当分数低于阈值时工作流开始执行先查最近 1 小时的振动原始值、温度趋势、设备基本信息然后调用 DeepSeek 的 API传入拼接好的诊断上下文让它输出故障类型、置信度、建议动作。最后根据置信度选择告警通道——高置信度直接拉群低置信度只发日报汇总。这条路径里的每一步数据格式我都做了统一特征值用浮点数事件记录用 JSON告警消息用纯文本加 markdown 链接。这样任意一层出现问题排查起来都只影响相邻层不会形成链路雪崩。3. 环境准备与基础配置3.1 组件清单与版本选择先把我实际用的组件和版本列一下你搭的时候可以直接抄。组件版本用途Python3.10数据采集、特征计算、模型推理Prometheus2.45指标存储、告警规则计算Pushgateway1.6接收边缘节点推送的指标Alertmanager0.26告警路由与通知分发Grafana10.x可视化看板OpenClaw最新发布版智能体编排与工作流执行scikit-learn1.3异常检测模型训练FastAPI0.104模型推理服务版本不用太纠结只要 Prometheus 2.x、scikit-learn 1.x 以上就能跑通。但要注意 OpenClaw 的插件 API 不同版本有差异安装后建议先跑一下自带的openclaw doctor检查命令确认基础环境没问题。3.2 安装与初始化安装过程分成四步。第一步创建 Python 虚拟环境并安装依赖mkdir pdm-project cd pdm-project python3 -m venv venv source venv/bin/activate pip install openclaw prometheus-client pushgateway numpy scipy scikit-learn fastapi uvicorn requests第二步下载并启动 Prometheus 与 Pushgateway。我习惯用二进制直接跑方便在车间离线环境部署wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz tar xzf prometheus-2.45.0.linux-amd64.tar.gz cd prometheus-2.45.0.linux-amd64 ./prometheus --config.fileprometheus.ymlPushgateway 是独立进程默认监听 9091 端口。第三步初始化 OpenClaw。首次运行会生成一个配置文件目录里面包含agents/、tools/、flows/三个核心目录。可以用指令快速体验openclaw init --name pd-agent openclaw agent list第四步把 DeepSeek 的 API Key 配置到环境变量避免写死在代码里export DEEPSEEK_API_KEYsk-xxxx export DEEPSEEK_BASE_URLhttps://api.deepseek.com注意在工业现场部署时API Key 不要放到 Prometheus 配置里也不要提交到 git 仓库。建议用独立的密钥管理方案或至少用环境变量注入。3.3 DeepSeek 访问封装DeepSeek 的接口协议是 OpenAI 兼容格式用 requests 就能调。我封装了一个模块统一处理接口调用和异常重试。# deepseek_client.py import os import requests import json def chat(messages, temperature0.2, max_tokens1024): api_key os.environ[DEEPSEEK_API_KEY] resp requests.post( f{os.environ.get(DEEPSEEK_BASE_URL, https://api.deepseek.com)}/chat/completions, headers{Authorization: fBearer {api_key}}, json{ model: deepseek-chat, messages: messages, temperature: temperature, max_tokens: max_tokens, response_format: {type: json_object} }, timeout30 ) resp.raise_for_status() return json.loads(resp.json()[choices][0][message][content])temperature 设在 0.2 而不是更高是因为诊断报告需要确定性不需要创造性。如果输出要直接对接下游系统用response_format强制 JSON 输出能省掉很多解析上的麻烦。4. 数据采集与特征工程实现4.1 传感器数据模拟与采集脚本没有真实设备时用模拟数据先把链路打通这个步骤非常关键。否则等到接线接通再调试排错成本高得多。我写了一个模拟振动传感器的脚本生成两种状态的数据正常状态和轴承内圈磨损退化状态。# simulate_sensor.py import time import numpy as np from prometheus_client import CollectorRegistry, Gauge, push_to_gateway FS 2560 # 采样率 Hz def generate_vibration(faultFalse): t np.arange(FS) / FS # 转频 25Hz正常时以转频能量为主 signal 0.8 * np.sin(2 * np.pi * 25 * t) # 添加随机噪声 signal np.random.normal(0, 0.15, sizet.shape) if fault: # 故障时内圈故障特征频率 118Hz边带调制 signal 2.2 * np.sin(2 * np.pi * 118 * t) * (1 0.6 * np.sin(2 * np.pi * 25 * t)) signal np.random.normal(0, 0.3, sizet.shape) return signal def compute_features(signal): rms np.sqrt(np.mean(signal ** 2)) peak np.max(np.abs(signal)) crest peak / rms if rms 0 else 0 kurt ((signal - np.mean(signal)) ** 4).mean() / ((signal - np.std(signal)) ** 4 1e-8) spec np.abs(np.fft.rfft(signal)) dominant_freq np.fft.rfftfreq(FS, 1.0 / FS)[np.argmax(spec)] return rms, crest, kurt, dominant_freq def main(): registry CollectorRegistry() g_rms Gauge(vibration_rms, 振动均方根, [machine], registryregistry) g_crest Gauge(vibration_crest, 峰值因子, [machine], registryregistry) g_kurt Gauge(vibration_kurtosis, 峭度, [machine], registryregistry) g_freq Gauge(vibration_dominant_freq, 主频, [machine], registryregistry) fault_flag False while True: # 每 60 轮切换一次故障状态模拟退化过程 if int(time.time() / 60) % 5 4: fault_flag True else: fault_flag False signal generate_vibration(faultfault_flag) rms, crest, kurt, freq compute_features(signal) labels {machine: CNC_03} g_rms.labels(**labels).set(rms) g_crest.labels(**labels).set(crest) g_kurt.labels(**labels).set(kurt) g_freq.labels(**labels).set(freq) push_to_gateway(localhost:9091, jobvibration_push, registryregistry) time.sleep(5) if __name__ __main__: main()这里的关键是故障特征频率的设定。轴承内圈故障特征频率不是随便写的它和轴的转频、轴承节径、滚珠数量有关。在模拟阶段用 118Hz 加上边带频率是因为真实轴承故障的振动信号会有明显的调制现象边带间隔等于转频 25Hz。这个细节让后续特征区分度更高模型也更好训练。4.2 特征提取从原始波形到健康指标预测性维护不能直接把原始波形丢给模型得先提炼特征。我常用四个特征组合。均方根值 RMS 反映振动能量大小设备越健康 RMS 稳定在一个基线峰值因子是峰值除以 RMS对早期缺陷敏感因为轴承点蚀会产生冲击但 RMS 还没明显增大峭度对冲击类故障非常敏感正常信号约等于 3故障时可能跳到 5 以上频谱主频则能判断能量是否从转频附近转移到故障特征频率附近。这四个特征在上一节的compute_features函数里已经算出来了。我建议把它们拆开存到 Prometheus 的不同指标中而不是合成一个复合指标这样可以分别设定告警阈值也方便在 Grafana 里做联动分析。比如只看峭度很容易被单次冲击干扰但“峭度升高同时主频跳到 118Hz”就是非常明确的轴承故障信号。4.3 数据上报到 Prometheus很多第一次搞这个的人会问Prometheus 不是拉模式pull吗设备数据怎么进来合适答案是分场景。像 MySQL 或 HTTP 服务这种常驻进程用 exporter 让 Prometheus 主动拉没问题。但车间里的边缘网关、传感器采集器是变化的数据源而且可能随时启停用 Prometheus 的 Pushgateway 推模式更合理。脚本里push_to_gateway就是干这件事。Pushgateway 有个坑后面详说指标不主动清理会一直残留。所以要确保每次推送时带上唯一标识比如machine标签区分设备重启采集脚本时再清理一次旧指标。5. 故障预测模型的训练与验证5.1 无监督异常检测为什么选孤立森林故障样本在真实工况下非常少甚至没有。所以我不选择“用故障数据训练分类器”这条路而是用无监督的孤立森林。孤立森林的核心逻辑是正常数据在特征空间里分布得很密集异常数据“与众不同”用随机超平面去切分异常数据会更快被孤立出来。它的计算成本低高维特征也扛得住很适合设备健康度这种实时性要求高的场景。训练代码非常简单# train_model.py import numpy as np import joblib from sklearn.ensemble import IsolationForest # 假设历史正常数据已经收集好了这里做模拟 normal_features np.random.normal([0.6, 3.1, 3.2, 25.0], [0.05, 0.15, 0.2, 0.5], size(10000, 4)) fault_features np.random.normal([1.8, 4.2, 5.1, 118.0], [0.08, 0.3, 0.4, 2.0], size(200, 4)) X_train normal_features model IsolationForest(n_estimators200, contamination0.02, random_state42) model.fit(X_train) # 保存模型 joblib.dump(model, anomaly_model.joblib)训练数据只用了正常数据这是无监督方案的天然优势——新设备、新产线部署时不需要积累故障案例采集一周正常数据就能出第一版模型。5.2 模型输出怎么映射成健康分孤立森林输出的是 decision_function 分数值越大表示越正常但这个分数业务方看不懂。我把它做了一次映射def health_score(model, features): raw model.decision_function(features.reshape(1, -1))[0] # 线性映射到 0-100分数越低越危险 score 50 50 * (raw / max(abs(raw), 1e-6)) return float(np.clip(score, 0, 100))映射公式不是严格的概率但胜在直观80 以上正常60-80 关注60 以下告警。实际部署时你可以根据自己的数据和现场接受度调整。5.3 模型评估与阈值标定在模拟数据上做了离线验证。用 10000 条正常数据训练再用 200 条故障数据和 2000 条正常数据做测试调节 threshold 观察效果阈值召回率故障检出虚警率正常误报结论0.7598.5%6.2%虚警偏高0.7097.0%3.1%可接受0.6590.5%1.2%漏报偏高0.6082.0%0.4%偏保守现场建议先从“宁可多报不可漏报”开始跑两周收集反馈后再收紧阈值。预测性维护项目死在第一周的通常不是模型不准而是虚警太多导致班组不再信任系统。5.4 模型服务化我把训练好的模型包在一个 FastAPI 服务里方便 OpenClaw 和 Prometheus 定期调用。# model_service.py import joblib import numpy as np from fastapi import FastAPI from pydantic import BaseModel app FastAPI() model joblib.load(anomaly_model.joblib) class Features(BaseModel): rms: float crest: float kurtosis: float dominant_freq: float app.post(/health) def predict(f: Features): arr np.array([f.rms, f.crest, f.kurtosis, f.dominant_freq]) return {health_score: health_score(model, arr)} def health_score(model, features): raw model.decision_function(features.reshape(1, -1))[0] score 50 50 * (raw / max(abs(raw), 1e-6)) return float(np.clip(score, 0, 100))启动服务uvicorn model_service:app --host 0.0.0.0 --port 8000到这里数据链路和模型链路已经通了。接下来是 OpenClaw 和 DeepSeek 重头戏。6. OpenClaw 智能体编排与 DeepSeek 接入6.1 智能体工作流设计OpenClaw 的编排核心是“事件触发 工具调用”。我设计了这样一个工作流正常状态时OpenClaw 作为常驻 Agent 周期查询 Prometheus 中每台设备的健康分。这一步用的是定时触发器周期 30 秒。分数不低于 70 就正常轮询。分数低于 70 后进入诊断流程先调用“查历史指标”工具取得该设备最近 1 小时的 RMS、峭度、主频趋势和温度变化再调用“模型服务”确认一次原始特征是否真的异常避免单点抖动然后聚合上下文组装提示词调用 DeepSeek最后按照置信度决定告警方式。置信度大于 0.8 的立即发企业微信并附带停机建议置信度在 0.5-0.8 的发日志记录并在日报里汇总。# openclaw_flow.yaml triggers: - type: schedule cron: */30 * * * * * steps: - id: query_health tool: prometheus_query params: query: health_score 70 promql: true - id: fetch_context tool: prometheus_query params: query: | {__name__~vibration_rms|vibration_kurtosis|vibration_dominant_freq, machineCNC_03}[:1h] - id: confirm_anomaly tool: http_call params: url: http://localhost:8000/health method: POST - id: diagnose tool: deepseek_chat params: prompt_template: prompts/diagnose.j2 - id: notify tool: wecom_notify params: channel: 设备运维告警群这个设计的核心是OpenClaw 只做流程编排和工具调度不承担模型运算也不承担自然语言生成。它更像是值班长知道什么时候找谁、把什么材料给谁。6.2 提示词模板设计DeepSeek 输出质量很大程度上取决于提示词。我用的诊断模板如下你是设备诊断工程师。请根据以下传感器特征和趋势判断设备是否存在异常并给出维护建议。 设备信息 - 设备编号CNC_03 - 设备类型数控加工中心主轴 - 轴承型号6308假定 当前特征值 - 振动RMS{rms} - 峰值因子{crest} - 峭度{kurt} - 主频{dominant_freq} Hz 历史趋势最近1小时 {rms_trend} {freq_trend} 要求 1. 如果判断为异常给出可能的故障部位和故障类型 2. 给出置信度0到1 3. 给出建议动作立即停机/计划维修/持续观察 4. 以JSON格式输出字段为fault_type, probability, action, reason注意把采集到的数值全部填充到模板里而不是让 DeepSeek 自己去查数据。大模型不擅长精确查询但很擅长在给定数据上做推理归纳分工要明确。6.3 DeepSeek 诊断调用实测前面封装了deepseek_client.chat实际调用的拼接逻辑如下def build_diagnosis(context): prompt DIAGNOSE_TEMPLATE.format(**context) result deepseek_client.chat([ {role: system, content: 你是一名严谨的设备诊断工程师输出必须是有依据的。只能基于给定数据做判断禁止编造数据。}, {role: user, content: prompt} ]) return json.loads(result)在模拟故障场景下真实输出大致是这样{ fault_type: 轴承内圈磨损, probability: 0.87, action: 计划维修, reason: 频谱主频从25Hz跳变到118Hz并伴随25Hz边带调制符合内圈故障特征频率峭度从3.1升高到5.2存在明显冲击脉冲。建议在12小时内安排停机检查并准备6308轴承备件。 }这段输出里最值钱的是“12小时内安排停机检查”和“准备备件”——这已经不是单纯的告警而是可执行的工作指令。现场班组收到后可以直接安排比看一堆曲线快得多。6.4 与 OpenClaw 工具的对接方式OpenClaw 的一个特点是工具按插件机制注册把 DeepSeek 封装成一个 Tool 也非常简单。我在项目里注册了三个 Toolprometheus_query负责执行 PromQL 查询并返回结果。deepseek_chat会调用前一节的 API 封装。wecom_notify走企业微信机器人 Webhook。tools: - name: deepseek_chat entry: tools.deeepseek_chat.call params_schema: tools.deeepseek_chat.parameters - name: prometheus_query entry: tools.prometheus_utils.query params_schema: tools.prometheus_utils.parameters定义好之后工作流节点里就能直接通过tool: deepseek_chat调用。这个封装的好处是后续想换模型只改工具入口不动工作流定义。7. Prometheus 告警联动与可视化7.1 告警规则设计模型分数的告警规则直接写在 Prometheus 配置里由 Prometheus 统一计算和触发。# rules/predictive_maintenance.yml groups: - name: equipment_health rules: - alert: EquipmentHealthCritical expr: health_score 60 for: 1m labels: severity: critical annotations: summary: 设备 {{ $labels.machine }} 健康分过低 description: 当前分数 {{ $value }}请立即检查。 - alert: EquipmentHealthWarning expr: health_score 70 for: 5m labels: severity: warning annotations: summary: 设备 {{ $labels.machine }} 健康分异常 description: 当前分数 {{ $value }}建议安排检查。注意for: 1m和for: 5m。这个参数非常关键它要求指标持续异常一段时间才触发告警。没有这个参数瞬时抖动就会造成大量误报。加了以后告警数量肉眼可见地下降。7.2 Alertmanager 通知路由Prometheus 负责“发现异常”Alertmanager 负责“把异常送对人”。车间场景下我做了两级路由critical 级直接发到当前值班维修组长个人和企业微信告警群warning 级进日报汇总所有告警都落到 Grafana 事件列表做复盘。route: group_by: [machine, alertname] group_wait: 10s group_interval: 5m repeat_interval: 4h routes: - match: severity: critical receiver: wecom-critical - match: severity: warning receiver: daily-report receivers: - name: wecom-critical webhook_configs: - url: https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxxgroup_by: [machine, alertname]能避免同一台设备多个指标同时异常时重复刷屏这一条在告警降噪里面重要性排第一。7.3 Grafana 看板要点可视化我按四块来做设备总览面板一张地图或者列表每台设备一个色块绿黄红三色代表健康状态。振动趋势面板展示 RMS 和峭度的时间曲线叠加健康分曲线。频谱热力图展示主频随时间的变化故障特征频率出现时可以肉眼看到斜线。事件记录表展示所有告警、恢复时间、维护动作形成完整闭环。看板的价值在于让老师傅能“用眼睛验证系统判断”。如果他们看到曲线确实和系统报警吻合信任度会迅速建立。如果系统报警了但曲线看起来正常则需要回去检查特征或修改阈值。8. 常见问题与排查技巧实录8.1 故障现象速查表搭建和运行过程中一定会遇到问题我把最常见的几个整理成表。现象可能原因排查方法解决方案健康分数始终 100特征范围与训练数据不一致打印原始特征值检查采集脚本是否推了低倍率数据告警风暴没有设置for持续时长看 Prometheus 规则是否配置for加for: 1mPushgateway 旧指标残留没有清理已下线设备查看pushgateway页面指标上线时用push_to_gateway前先 deleteDeepSeek 返回乱码返回过长或温度过高检查 max_tokens 和 temperature降到 1024 和 0.2模型误判新设备新设备正常工况不同对比不同设备的特征分布按设备类型分开训练模型Alertmanager 不推送Webhook 地址不可达看 Alertmanager 日志用 curl 手动测试 URL8.2 误报与漏报治理误报比漏报更伤系统因为一旦老师傅觉得“系统天天狼来了”后续真报警也没人重视了。最常见的一个坑是峭度瞬时冲击。有时候加工过程本身会产生冲击比如断续切削峭度会瞬间飙到 6 以上。解决办法是模型输入不做瞬时值而是取 3 分钟滑动平均值再加上确认步骤——OpenClaw 工作流里调用模型服务做二次确认就是针对这个场景。漏报的主要原因是特征覆盖不足。振动特征只能反映旋转类故障润滑不良、温升异常要靠温度特征补充电流异常要靠电流特征。所以第一版模型只用振动特征可以但别指望它覆盖所有故障类型。8.3 存储层深坑Prometheus 数据生命周期Prometheus 默认存储保留期是 15 天这个对预测性维护来说远远不够。设备退化趋势往往要看几个月保留期太短会导致无法分析长期趋势。我在启动参数里显式加了保留期配置./prometheus --storage.tsdb.retention.time180d另一个坑是 Pushgateway 的指标残留问题。设备改造或停机后Pushgateway 里还留着旧的指标数据会导致 Grafana 上出现“幽灵设备”。采集脚本启动时先调 HTTP DELETE 清理对应 job 的旧数据curl -X DELETE http://localhost:9091/metrics/job/vibration_push/instance/localhost8.4 模型漂移与定期重训练设备在长期运行中会磨损正常状态的基线也会缓慢变化。一个模型用半年后可能虚警率明显升高。我的做法是每周自动汇总一周内所有被系统标记为“确认正常”的特征数据维修班组确认后打标签每月末用这些数据增量微调模型。这个流程在原型阶段可以用脚本手动跑但要注意保留原始数据用于回滚。9. 复盘与扩展建议回头梳理这套系统真正的价值点不在单个模型或单个工具而在于把采集、存储、推理、语义分析、通知拉成了一条完整的链。技术选型上也印证了一个观点大模型最适合的不是替代确定性逻辑而是处理那些“老师傅能看出来但说不出来”的信息压缩与转换。有几个经验想重点分享。第一先跑通链路再优化精度。我第一次搭建时模型连 70% 召回率都不到但整个链路是通的可视化能看到每一层的输入输出优化起来非常快。第二告警降噪优先级高于模型精度。告警风暴会让整个系统失去信任宁可先保守、多人工确认。第三通知文案直接决定系统使用率。一个“健康分67”不如一句“建议本周检查主轴轴承备件型号6308”后者才是运维人员真正需要的。后续如果要往生产环境推进可以考虑扩展三个方向接入更多传感器类型比如电流信号和油液分析数据提升故障诊断的覆盖度把 DeepSeek 的诊断结果自动生成维修工单对接现有的 CMMS 系统用历史数据训练 RUL剩余使用寿命回归模型在“要不要修”之外进一步回答“还能撑多久”。如果你正准备做类似的设备预测性维护我的建议是从一台设备开始。选一台故障损失最大、传感器最好装的设备把数据采回来、告警发出去让老师傅看到系统确实能在坏之前“说”出来后面再推广就容易得多。