FA 一键诊断 — 知识库自动沉淀 Agent 设计 v2.0
前置阅读：
- FA 一键诊断 总体设计 §2.2 数据存储、§8.1 动态知识库
- FA 一键诊断 知识库元数据标签体系设计
版本记录：
- v1.0 (2026-06-17)：初稿（逐工单案例沉淀）
- v2.0 (2026-06-17)：重构为按分类聚合方案沉淀；仅 Dify 定时任务触发；去掉手动触发；日报列为规划不落地
1. 产品定位
不是逐条工单存档，而是按故障分类聚合处理方案。
同一故障类型（如「弱电智能化 > 闸机 > 无法升降」）可能对应多条工单、多种处理方案。沉淀 Agent 定期拉取闭环工单，按 system + component + symptom 归类，LLM 聚合出该故障的常见处理方案，以一份知识库文档的形式维护。
核心价值：新工单诊断时，LLM 检索到的不是碎片化工单记录，而是「这类故障通常怎么修」的结构化经验。
上线时机：P2 运营阶段，前提条件满足后通过 Dify 定时工作流开启。
2. 触发机制
通过 Dify Workflow 的定时触发（Cron Job），每周执行一次（如每周一凌晨 02:00）。
Dify 定时工作流（Cron: 0 2 * * 1）
→ 拉取上周闭环工单
→ 按分类聚合 → LLM 生成方案文档
→ Upsert 至 FA 诊断知识库MVP 不提供手动触发和管理后台入口。后续若需要补跑历史数据，通过 Dify 手动执行该工作流即可。
3. 处理流水线
4. Locate 目标工单
工作流引擎不区分工单类型，需要通过「流程实例中是否包含一键诊断组件」来定位。
定位逻辑：
1. 查询工作流引擎：
→ 拉取指定时间范围内已闭环的流程实例
→ 筛选包含「一键诊断」节点的流程
2. 获取诊断记录：
→ diagnosis_records WHERE work_order_id IN (上述流程ID)
→ 取每次诊断的 classification 和 confidence
3. 过滤：
→ confidence >= LOW_CONFIDENCE_THRESHOLD (排除分类不确定的)
→ 处理方式非空且字数 >= 10具体查询 API 依赖工作流引擎的开放能力，需与工单产品经理确认。
5. 按分类聚合
5.1 分组键
GROUP BY system, component, symptom同一组内所有工单共享一套分类标签。标签来自一键诊断时已打好的 classification 记录——不用重新打标。
5.2 聚合 Prompt
{# FA_沉淀Agent_方案聚合_Prompt #}
你是一个设备运维知识整理专家。以下是同一故障类型的多条闭环工单，请将其中的处理方案聚合为一份知识文档。
## 故障分类
{{system}} > {{component}} > {{symptom}}
## 工单记录（共 {{count}} 条）
{% for wo in workorders %}
---
### 工单 {{loop.index}}
- 故障描述：{{wo.description}}
- 处理方案：{{wo.resolution}}
- 处理人：{{wo.handler}}
- 结单时间：{{wo.closed_at}}
{% endfor %}
## 输出要求
将以上工单中的处理方案去重、归类、合并，输出一份知识文档：
1. **故障概述**：用 1-2 句话概括这类故障的典型表现
2. **常见原因**：归纳工单中提及的根因，按频次排序
3. **处理方案**：对每条处理方案去重合并，保留可操作的关键步骤和数据（如参数值、阈值）。同一思路的方案合并为一条，附出现次数
## 输出格式
### 故障概述
...
### 常见原因
1. ...（N 次）
2. ...（N 次）
### 处理方案
#### 方案一：...（N 次）
1. ...
2. ...
#### 方案二：...（N 次）
1. ...5.3 知识库文档
标题：故障处理方案：[component]-[symptom]
正文示例：
# 故障处理方案：闸机-无法升降
## 故障概述
闸机翼臂无法正常升降，导致人员无法通行。多发于使用频繁的出入口。
## 常见原因
1. 伺服电机驱动器参数漂移，过载保护触发（6 次）
2. 红外对射感应器被灰尘遮挡或偏移（3 次）
3. 供电电压不稳，驱动器进入欠压保护（1 次）
## 处理方案
### 方案一：断电复位 + 参数校准（6 次）
1. 断开闸机电源，等待 30 秒后重新上电
2. 进入驱动器设置菜单，执行位置参数校准
3. 测试升降 3 次确认正常
### 方案二：清理红外感应器（3 次）
1. 用无尘布擦拭红外对射感应器表面
2. 确认感应器对齐指示灯常亮
3. 若偏移，松开固定螺丝重新对准后锁紧元数据：
{
"document_title": "故障处理方案：闸机-无法升降",
"system": "弱电智能化",
"component": "闸机",
"doc_nature": "故障处理方案",
"keywords": ["闸机", "无法升降", "伺服电机", "过载", "参数校准", "红外感应器"],
"access_roles": ["超级管理员", "物业经理", "运维工程师"],
"retention_policy": "active"
}5.4 Upsert 策略
同一 system + component 组合的知识库文档采用覆盖更新：
- 查询知识库：是否存在
document_title = "故障处理方案：[component]-[symptom]"的文档 - 若存在 → 删除旧文档，上传新文档（Dify 不支持原地更新）
- 若不存在 → 直接上传
分组粒度用
component + symptom而非system + component + symptom，因为同组件不同症状通常对应不同处理方案。
6. 上线条件
| 条件 | 说明 |
|---|---|
| 工作流引擎支持按节点类型查询流程实例 | 需确认 API 能力 |
| 闭环工单的处理方式字段已填写 | 当前缺失，需改造结单流程 |
| 自动打标准确率 ≥ 85% | 通过 Golden Set 评测 |
| 累计沉淀分组数 ≥ 10 | 避免知识库过于稀疏 |
7. 后续规划（不落地）
| 规划项 | 说明 |
|---|---|
| 日报 | 沉淀完成后推送到管理群：本次新增/更新 N 组，涉及 M 条工单 |
| 人工审核 | 知识库文档标注「AI 生成」标签，管理员可编辑修正 |
| 自动归档 | 连续 90 天无新工单的故障分组自动标记 archived |
8. 已知待解决问题
以下问题当前方案未覆盖，记录于此，后续闭环设计时解决。
8.1 增量沉淀而非全量替换
当前方案是「拉上周工单 → 按分组覆盖更新」。实际是错的——应该是在已有知识库条目的基础上融合新工单。例如「故障处理方案：闸机-无法升降」已存在于知识库，本周新增 3 条同类工单时，不能直接覆盖旧文档（会丢失历史方案），而是需要读取旧文档 → 合并新工单 → 输出新版本。
涉及：知识库条目的版本管理、旧文档内容解析、增量合并 Prompt 设计。
8.2 Symptom 聚类不精准
symptom 由 LLM 打标产生，非受控词汇。「无法升降」「翼臂不动」「闸机卡住」语义相同但文本不同，简单字符串 GROUP BY 会把它们拆成三个分组。
涉及：symptom 归一化（是否需要 symptom 候选列表？是否用 LLM 做跨周 symptom 合并？）、分组粒度的工程化控制、是否需要人工确认新的 symptom 变体。
8.3 知识库条目工程化
沉淀的知识库条目不仅仅是 Markdown 文本，需要携带结构化元数据支撑后续增量合并：
{
"document_title": "故障处理方案：闸机-无法升降",
"doc_nature": "故障处理方案",
"source_work_order_ids": ["WO-2026-0892", "WO-2026-0915", "WO-2026-1033"],
"total_occurrences": 12,
"last_updated": "2026-06-23",
"symptom_variants": ["无法升降", "翼臂不动", "闸机卡住"]
}涉及：Dify 自定义 metadata 字段扩展、source_work_order_ids 的 JSON 序列化存储、total_occurrences 的原子递增。
8.4 方案分组何时拆分
同一 component + symptom 下，当处理方案差异过大（如"断电复位"vs"更换驱动板"），是否需要拆分成多个知识条目？拆分阈值如何定义？
文档版本：v2.0创建日期：2026-06-17最后更新：2026-06-17作者：孙强