去年我帮一家东莞电子厂装过设备预测维护系统。振动传感器、温度传感器都部署好了，后台也能收到告警了——然后问题来了：告警到了，但没人去修。

不是工人偷懒。问题是流程断的：传感器告警发到运维组长的手机上，组长对讲机喊人，维修工可能在车间另一头干活没听到，或者听到了手头正忙着，等干完活再去看，早忘了具体是哪台设备。一个月下来，漏掉的维修工单有将近20单。

这篇文章记录的是第二期：在已有的传感器告警系统基础上，加了一个AI Agent来管理维修工单的完整流转——自动建单、按技能分配、备件预留、超时升级、完工闭环。

效果？告警响应时间从平均45分钟降到约8分钟，月均漏修工单从20单降到2单以下。

一、现场情况摸底

这家电子厂主营手机充电器PCB板组装，8条SMT线+后段组包装线，总共40多台主要设备。第一期我们已经装好了振动、温度传感器，部署了边缘AI网关做异常检测，问题是"发现异常→找人修"这一环完全靠人工接力。

具体看看当时的流程：

这个流程跑了一段时间后，暴露了几个问题：

老板的原话是："传感器花了那么多钱，数据也能看了，但设备该坏还是坏——因为没人去修。告警响了和没响有什么区别？"

二、方案设计

目标很清楚：让告警到维修的流程自动化，不需要人工中转。

我们从三个方向切入设计：

2.1 工单引擎——AI Agent替代人工分配

核心是一个基于规则的AI Agent，部署在边缘AI网关的容器里。它的工作流程：

2.2 备件联动——自动查询库存

根据设备类型和故障特征，Agent自动查询备件库存系统，判断该设备常用的备件是否有货。如果有，自动预留；如果库存不足，在工单里标注"需提前采购"。

2.3 闭环与数据沉淀

维修工在手机上确认"已修复"后，Agent自动记录：

这些数据进入设备健康档案——以后维保计划不再是"凭经验觉得该换了"，而是"这台轴承已经修了3次，平均寿命周期约4个月，下次换油在7月中旬"。

设计原则：尽量在不增加维修工操作步骤的前提下，把信息流转自动化。他们只需要在手机上点"收到"和"修好了"两个按钮。

三、实施过程

第一周：数据摸底和规则制定

这个阶段花的时间比预想的多很多。原因是：

这里踩了一个坑：我们一开始想用AI模型自动判断工单优先级（把历史告警和维修记录作为训练数据）。但做了两天发现，历史记录里很多信息是缺失的——谁修的、修了多久、换的什么零件，纸质单子上经常没写全。最后决定先用规则引擎，等积累3-6个月的结构化数据后再考虑上模型。

第二周：Agent开发和内部测试

Agent的核心逻辑其实不复杂，就是一个有限状态机：

状态流转：
告警接收 → 等级判定 → 技能匹配 → 工单分配 → 响应确认
  → [超时未响应] → 升级给主管 → 主管重分配
  → [已响应] → 进行中 → 维修完成确认 → 备件核销 → 闭环归档

真正的难点在对接：

第三周：灰度上线和调优

先在三台关键设备上试跑。运维组长和两个维修工参与测试。

上线第一天就出问题了：Agent把一条黄色告警（轻微振动升高）判定为"观察"级别，没有分配维修工。但这条告警其实是主轴轴承早期磨损的信号——如果不及时处理，两周内可能发展成故障。运维组长发现后要求调整规则，把所有带"轴承"关键词的告警至少升级到"普通工单"级别。

后来陆续调整了几个规则：

规则引擎就是这样——上线后至少需要2-3周的"磨合期"，根据现场反馈不断微调。没有任何一套规则在第一天就是完美的。

第四周：全量上线

覆盖全部40多台设备，所有维修工（6人）和运维组长参与。上线前一天做了半天培训，主要教维修工怎么在手机上接收和处理工单。

有意思的是，年龄大的维修工（45岁以上）对新系统有些抵触，觉得"手机点来点去不如对讲机喊一嗓子快"。我们做了一些调整：

四、实际效果

系统跑了3个月后，几个关键数据：

告警响应时间：平均45分钟 → 约8分钟
从告警触发到维修工确认接收。改善的原因很简单——不用等人中转，工单直接在手机上弹出提醒。
月均漏修工单：约20单 → 2单以下
漏掉的工单主要是夜班期间的低优先级告警，以及部分设备偶尔产生的误报。后者通过优化阈值解决了。
维修记录电子化率：从0% → 100%
以前靠纸笔记录，经常丢、字迹潦草看不懂、或者根本没记。现在每次维修都有电子记录，包括故障现象、维修方法、更换零件、耗时。这些数据直接喂给了设备维保计划的决策。
非计划停机：减少约一半
因为漏修少了、响应快了，很多小问题在变成大故障之前就被处理了。设备OEE（整体设备效率）有一定提升，但具体数字受产线换型影响，波动较大，没有给出精确数值。

五、遇到的问题和解决办法

问题1：维修工不点"完成"

系统上线头两周，大约30%的工单在维修完成后没有在手机上确认"已完成"。后台显示"进行中"状态的工单越积越多。

解决：加了两个机制——(1) 每天上午9点给每个维修工推送"待关闭工单清单"；(2) 工单超过4小时未关闭的，自动推送给组长提醒。两周后"完成"确认率升到了95%以上。

问题2：备件预留超时的坑

Agent在分配工单时会自动预留备件。但有些工单分配后维修工迟迟没去领料（比如等配件到货或者在处理更紧急的故障），导致备件被锁定但没人用，真正需要的人反而领不到。

解决：加了一个"预留超时释放"逻辑——备件预留后2小时未领料自动释放，维修工领料时需要重新确认需求。

问题3：同一个设备一天告警多次，产生重复工单

某些传感器不太稳定，一天内反复进入/退出告警状态，产生了大量重复工单。维修工一早上收到5条同一台设备的工单，体验很不好。

解决：加了一个"消抖"逻辑——同一设备同一类型的告警，30分钟内不再产生新工单，只更新已有工单的"最新告警时间"。另外把部分不稳定的传感器更换了批次，也从源头减少了误报。

问题4：交接班的信息断层

白班维修工手上还有3个工单没处理完就下班了，夜班同事不知道这些工单的存在。等到第二天发现，设备已经带病运行了一整夜。

解决：在Agent里加了交接班自动汇总功能——每天17:00自动生成"未完成工单清单"，推送给白班组长和夜班组长的企业微信。夜班组长一上班就知道哪些工单需要优先处理。

六、我的思考

做完这个项目，有几个体会比较深：

"告警到维修"这一段是整个IoT链条上的薄弱环节。很多工厂花了几十万上传感器、买网关、搭平台，数据大屏做得漂漂亮亮，但实际问题没解决——因为没有人去推动"看到数据之后做什么"。告警来了，谁去修？修了之后怎么确认修好了？这些听起来简单的问题，实际做起来比装传感器复杂得多。

业务流程自动化比技术本身更难。写Agent的代码用了不到一周，但梳理设备-技能映射、备件关联、告警等级定标这些业务规则，花了近两周。技术实现不是瓶颈，搞清楚"业务到底应该怎么跑"才是。

一线的接受度决定项目成败。我们花了大量时间跟维修工磨合：他们习惯了对讲机、习惯了纸质记录，让他们用手机接单一开始是有抵触的。后来我们发现，只要让他们觉得这个系统是"帮他们省事"而非"监视他们"，接受度马上就不一样了。比如自动记录维修耗时——如果我们用来考核维修工效率，他们一定会抵触；但我们用来优化维保计划、减少突发抢修，他们就很配合。

数据闭环的价值被低估了。3个月的维修记录，我们从中发现了几条有价值的规律：某台贴片机每年4月前后故障率明显升高（跟回南天湿度相关）、某个型号的电机平均运行约6000小时需要更换轴承、两位维修工处理特定类型的故障耗时明显比其他人短。这些以前都是"老师傅的经验"，现在变成了可以复用的数据资产。

七、给你的建议

  1. 先把手动流程走通再自动化。不要一上来就搞AI Agent。先搞清楚维修工单现在是怎么流转的、卡在哪、谁做什么，然后用纸笔记下来。自动化只是把理顺了的流程跑得更快。
  2. 规则引擎比AI模型更实用（起步阶段）。我们一开始想上模型自动分派工单，但历史数据质量太差。规则引擎虽然"笨"，但它可解释、可调整——维修组长能理解"为什么这个工单分给了小王而不是老李"。等数据积累够了再上模型不迟。
  3. 给一线操作的人留"不走系统"的选项。有些紧急情况（比如设备冒烟了），维修工不可能先点手机确认再跑去修。我们后来加了一个"事后补单"功能——紧急情况可以先修，修完再在系统里补上记录。
  4. 关注交接班这个薄弱环节。设备停机最常发生在交接班前后——白班的人走了，夜班的人还没完全进入状态。交接班的信息传递不能依赖口头交代。
  5. 对讲机不是所有场景的对手。在很多嘈杂的工厂车间里，对讲机经常听不清。用手机推送+语音播报，可读性比音频好得多。