scenario s5 / 短期 · 生产研发侧
设备运维诊断 Agent
问什么坏了、怎么修、要什么备件、谁来修——报警到工单的闭环助手
数据可得性
中高
所需数据是否已在手、能否直接用于建模
工程难度
低
从可行性验证到稳定上线的工程风险
实时性要求
中
需要秒级响应，还是天级出报告
评级为面向学习者的教学性判断，用于横向比较场景特点，不构成采购或投资建议。
涉及工序 / 6 道 · 高亮项点击可跳章节
业务痛点，讲人话
凌晨两点，某台设备报警。值班人员要在几分钟内回答四个问题：
什么坏了？怎么修？要什么备件？谁来修？
这些答案理论上都在系统里——报警日志、历史检修工单、备件台账、电气图纸、厂商手册。实际上它们分散在五六个系统、若干个共享盘、以及几位老师傅的脑子里。
于是现实往往是：先翻手册，翻不到就打电话找人，找不到人就凭经验试。
三个具体痛点：
- 告警风暴——一个根本故障会触发几十条关联报警，真正的根因藏在下面
- 部落知识没写进文档——"这个报警可以忽略""这台泵的振动一到某个值就该换轴承了"，只在老师傅嘴里
- 历史工单是死数据——积累了几万条，但只能按关键词模糊搜，用不起来
数据长什么样
data shape / 本场景吃哪几类数据
技术报告、专利、论文、操作规程、设备手册、检修工单、报警日志
瓶颈：非结构化、密级混杂、时效性标注缺失（哪版规程还有效？）
各工序工艺参数、L1/L2 控制信号、设备状态、振动与电流、能源计量读数
瓶颈：跨工序时空对齐；数据往往在客户/产线侧，取数是授权问题而非技术问题
样例结构 / 教学示意，非真实产线数据
# 历史工单：最好的训练语料（教学示意）
work_order:
id: "WO-2024-XXXX"
equipment: "2# 连铸机 结晶器振动装置"
reported_at: "2024-XX-XX 02:14"
symptom: "振动频率波动，偏差超过设定值"
alarms: # ★ 告警风暴：一个根因触发多条
- {code: "CC2-VIB-H", ts: "02:14:03"}
- {code: "CC2-SERVO-DEV", ts: "02:14:05"}
- {code: "CC2-HYD-P-LOW", ts: "02:14:02"} # 时间最早 → 疑似根因
diagnosis: "液压站蓄能器压力不足，导致伺服响应滞后"
action: "补充蓄能器氮气压力至规定值"
parts: [{code: "ACC-N2-KIT", qty: 1}]
duration_min: 45
by: "…"
#
# 一条工单 = 现象 + 告警序列 + 诊断 + 处置 + 备件 + 耗时
# 几万条这样的记录，就是一个完整的 case 库注意 alarms 里的时间戳：最早触发的往往指向根因。这类时序规则应该在检索之前先跑，用确定性方法收窄范围。
设计要点
ai engineer's view
报警日志 ≈ 生产环境 error log
同样有告警风暴、根因藏在三层调用之下、以及「这个报警可以忽略」的部落知识没进文档。处理思路也类似：先按时间序列收敛到根因候选，再做检索。
历史工单 ≈ incident ticket 库
现象、诊断、处置、备件、耗时——一个完整的 case 库。这是这个场景最有价值的语料，比设备手册更贴近实战。
手册是规范，工单是实践
两者都要检索，但权重不同：手册说明「应该怎么做」，工单记录「实际上人们怎么做」。冲突时要标出来，而不是选一个。
先做时序收敛，再做检索。 告警风暴场景下，直接把几十条报警丢给 RAG 会检索出一堆噪声。应该先用规则按时间戳和因果关系收敛到少数根因候选，再针对候选做检索。
给回答加上置信度与来源。 深夜值班的人需要知道"这是手册里明确写的"还是"这是从三条相似工单里归纳的"。这两者的可信度完全不同，必须区分呈现。
时效性标注。 设备改造过、规程改版过，旧工单的处置方法可能已经不适用。每个 chunk 要带有效期或版本信息，检索时先过滤再排序。
必懂概念 / 6 张
ai engineer's view / 换成你熟悉的说法
报警日志 ≈ 生产环境的 error log
同样有告警风暴、同样有根因藏在三层调用之下、同样有「这个报警可以忽略」的部落知识没写进文档。
检修工单 ≈ incident ticket
历史工单是最好的训练语料：现象、诊断、处置、备件、耗时，一个完整的 case 库。
技术零风险的第一枪
纯知识型 Agent，不接触控制回路，最适合作为组织内建立使用习惯与信心的首个项目。
延伸学习
相关场景