FA 一键诊断 — Dify 编排功能设计 v3.0

前置阅读：
FA 一键诊断总体设计
FA 一键诊断知识库元数据标签体系设计
类别 & 标签管理后台 PRD

版本记录：
v1.0 (2026-06-17)：初稿
v2.0 (2026-06-22)：新增 device_id 输入 + N4c device_id 解析节点；N5 拆为 N5a IOT 注入 + N5b Asset 历史数据注入；N6 Prompt 增加资产历史上下文
v2.1 (2026-06-23)：System 自定义化改造：N1 扩展返回 systems+components；N2 Prompt system {% for %} 动态渲染；新增 N1c Code Node safety_tip 提取；N7 Prompt 安全提示改为数据驱动
v2.2 (2026-07-02)：命名重构。文档内概念名更新：System→类别(Category)，Component→标签(Tag)。Dify 变量名同步更新。
v3.0 (2026-09-17)：按生产实现对齐（现状 + 待开发）。① N2 打标输入面扩展为「分类树 + 资产摘要 + 近 N 天告警 + 故障描述」，并规划追加设备实时 IOT；② N1c 数据驱动安全提示下线（废弃设计）；③ N3 置信度分支当前未实现，检索合并为单路；④ N4 Metadata Filter 设计保留、标注待开发实现；⑤ N7 报告 Prompt 反向回填（新增「告警」「需现场核实」章节 + 工况表规则 + 归因铁律）；⑥ N8 引用口径改为「正文引用才算证据」。

1. Workflow 总览

图中 N3（置信度分支）当前未实现，检索合并为 N4 单路；宽窄双路检索为预留设计，详见 §2.4 / §2.5。

1.1 节点清单

序号	链路	名称	说明	状态
N0	—	接收参数	接收工单描述 + 可选 asset_id + 可选 device_id	—
N1	分类	拉取分类树	从管理后台获取当前项目可选的类别/标签候选（含分类指引 aiGuidance）	—
N2	分类	故障分类（打标）	LLM 综合分类树 + 资产摘要 + 近 N 天告警 + 故障描述，输出类别/标签/现象/置信度	—
N3	分类	置信度判定	置信度 ≥ 阈值走精确检索，< 阈值走宽检索	未实现（预留）
N4	分类	知识库检索	按类别 + 标签做 Metadata Filter 精准检索（Top-5，阈值 0.3）	Metadata Filter 待开发
N5	数据	设备 ID 解析	根据 asset_id 查对应 device_id（有 device_id 则直接用），统一 IOT 查询入口	—
N6	数据	多维数据注入	有 device_id 则拉 IOT 实时值+告警；有 asset_id 则拉历史报修/巡检/保养/零件；打标侧注入资产摘要+告警	打标注入 IOT 待开发
N7	生成	生成诊断报告	LLM 综合工单描述 + 分类标签 + 知识库 + IOT + 资产历史，输出排障建议	—
N8	输出	返回结果	返回分类标签 + 诊断报告 + 引用来源 + 数据可用性标记	—

1.2 输入变量

变量	来源	必填	说明
`work_order_description`	工单系统传入	✅	工单故障描述原文
`asset_id`	工单系统传入	—	关联的资产 ID，有则查资产历史数据 + 解析 device_id
`device_id`	工单系统传入	—	关联的设备 ID（报警转工单场景直接携带），有则查 IOT
`current_work_order_id`	工单系统传入	✅	当前发起诊断的工单 ID，N5b 据此排除历史数据中的自身，防止自引用
`low_confidence_threshold`	工作流变量，默认 0.5	✅	低置信度阈值，可在 Dify 面板调参

各类历史数据的时间范围和条数上限在 Dify 工作流变量面板中按类型独立配置（见 §2.1），不通过工单系统入参控制。

2. 节点详细设计

2.1 N0 — Start 与工作流变量

接收工单系统传入四个核心字段：work_order_description（必填）、asset_id（可选）、device_id（可选）、current_work_order_id（必填）。

asset_id vs device_id 的关系：工单系统只需传入有的字段。人工报修工单通常只有 asset_id（如 AST-2023-0042），报警转工单可能直接带 device_id（如 DEV-AHU-020）。一键诊断内部通过 N5 节点 统一处理映射关系。

各类历史数据的时间范围和条数上限在 Dify Workflow 的「变量」面板中按类型独立配置：

变量	默认值	说明
`LOW_CONFIDENCE_THRESHOLD`	`0.5`	低置信度阈值，`confidence < 此值` 时触发宽检索，并通过 `is_low_confidence` 告知前端
`REPAIR_DAYS`	`365`	报修记录回溯天数
`REPAIR_TOP_K`	`5`	报修记录最多取多少条
`MAINTENANCE_DAYS`	`730`	保养记录回溯天数（保养周期较长，默认 2 年）
`MAINTENANCE_TOP_K`	`5`	保养记录最多取多少条
`INSPECTION_DAYS`	`365`	巡检记录回溯天数
`INSPECTION_TOP_K`	`5`	巡检记录最多取多少条
`PARTS_DAYS`	`365`	零配件更换记录回溯天数
`PARTS_TOP_K`	`5`	零配件更换记录最多取多少条
`NO_CITATION_HINT`	`"暂无可参考的知识库文档，诊断建议由 AI 基于通用常识生成。"`	知识库检索无结果时，返回给前端的话术

2.2 N1 — HTTP Request：拉取分类标签（Categories + Tags）

配置项	值
方法	GET
URL	`{{MANAGEMENT_API}}/api/v1/diagnosis/classification-labels`
超时	5s
输出变量	`category_list`（JSON array）+ `tag_list`（JSON array）

v3.0 变更：原 v2.0 的 GET /api/v1/diagnosis/components endpoint 已废弃，统一合并为分类标签组合接口。v4.0 命名重构：返回字段从 systems/components 改为 categories/tags。

响应示例：

json

{
  "categories": [
    {"id": 1, "name": "建筑结构", "description": "建筑物本体结构相关设备，含门窗、幕墙、电梯井道等"},
    {"id": 2, "name": "电气", "description": "供配电系统设备，含变压器、配电柜、UPS、继电器等"},
    {"id": 3, "name": "弱电智能化", "description": "弱电与智能化系统设备，含安防监控、门禁、传感器、会议系统等"}
  ],
  "tags": [
    {"category_id": 2, "category": "电气", "tag": "UPS", "description": "不间断电源，含蓄电池组，常见品牌科士达/山特/施耐德"},
    {"category_id": 2, "category": "电气", "tag": "继电器", "description": "电磁/固态继电器，控制回路通断"},
    ...
  ]
}

category_list 和 tag_list 将在 N2 打标 Prompt 中作为变量注入。

2.3 N2 — LLM：打标

配置项	值
模型	Qwen3-14B-awq（生产现网模型）
上下文	分类树 + 资产摘要 + 近 N 天告警 + 故障描述
Temperature	0.2（需稳定输出）
输出格式	JSON

v3.0 变更（输入面扩展）：打标不再只看工单描述。除分类候选外，额外注入 资产摘要（资产档案：名称/编码/类型/位置 + 关联设备 + 数据缺口）与 近 N 天告警（最多 5 条），使分类判断可借助资产与告警信息。
[待开发] 规划进一步注入 设备实时 IOT 信号（物模型属性实时值），使打标在设备工况可见的前提下完成分类。

Prompt（system / user 两段）：

# system
你是设施运维 FA 故障分类助手。据分类树与故障描述选出 systemName（大类 name）、componentName（小类 name），并归纳 faultSymptom（短现象名，如「制冷不足」）。
- systemName/componentName 必须与分类树原文一致；无法判断则填 "" 且 confidence=low。
- faultSymptom 自由文本，非树节点；无法归纳填 ""。
- 只输出一行 JSON，勿代码块、勿解释、勿思考过程：
{"systemName":"","componentName":"","faultSymptom":"","confidence":"high|medium|low","reasoning":""}

# user
## 诊断分类树
{{category_tree_text}}

## 资产摘要
{{asset_summary}}

## 故障描述
{{effective_fault_description}}

输出变量：systemName（类别）、componentName（标签）、faultSymptom（故障现象）、confidence（high / medium / low）、reasoning（打标理由）

2.4 N3 — IF/ELSE：置信度分支（未实现 · 预留）

现状：置信度分支 当前未实现——打标后不区分 confidence 高低，所有工单统一进入同一条检索路径（N4）。打标输出的 confidence 仅作为元信息透传，不参与分流。
预留设计：后续若低置信工单的检索质量需要单独兜底，可启用本分支——高/中置信走 精确检索（类别 + 标签双条件，Top-5），低置信走 宽检索（仅类别单条件 + 排除保修卡/合格证，Top-3）。阈值由工作流变量 LOW_CONFIDENCE_THRESHOLD（默认 0.5）控制，无需改代码。

条件（预留）	表达式	后续节点
高/中置信	`confidence >= {{LOW_CONFIDENCE_THRESHOLD}}`	精确检索（Top-5）
低置信	`confidence < {{LOW_CONFIDENCE_THRESHOLD}}`	宽检索（Top-3）

2.5 N4 — Knowledge Retrieval：知识库检索

现状：单路检索（原 N4a/N4b 已合并），且 Metadata Filter 尚未启用（metadata_filtering_mode: disabled）——打标结果仅拼入检索 query 文本，未作为过滤条件，检索退化为纯混合检索 + rerank。
[待开发] 开发侧将启用 Metadata Filter：以打标输出的类别/标签作为过滤条件，对文档做精准约束。下述配置为启用后的目标态。

检索配置：

配置项	值
知识库	FA 诊断知识库
检索模式	混合检索（向量 + 关键词）+ rerank 精排
Top-K	5
相似度阈值	0.3

Metadata Filter（目标态 / 待开发）：

json

{
  "operator": "and",
  "conditions": [
    {"field": "category", "operator": "eq", "value": "{{category}}"},
    {"field": "tag", "operator": "eq", "value": "{{tag}}"}
  ]
}

宽检索（预留，随 §2.4 N3 分支一并启用）：低置信工单仅按 category 单条件过滤 + doc_nature not_in ["保修卡","合格证"]，Top-3，阈值 0.2。

输出变量：rag_context（检索结果数组），每个 chunk 含 document_title, content, score

2.6 N5 — HTTP Request：device_id 解析

用途：统一处理 asset_id → device_id 的映射关系，确保后续 IOT 数据拉取有统一的 device_id 入口。

配置项	值
方法	GET
URL	`{{ASSET_API}}/api/v1/assets/{{asset_id}}/device`
超时	3s
条件执行	仅 `device_id` 为空且 `asset_id` 不为空时执行
失败处理	静默跳过，不阻断流程
输出变量	`resolved_device_id`（string 或 null）

内部逻辑：

N4c 执行后更新 device_id:
  输入 device_id     → 直接用，跳过 N4c
  无 device_id + 有 asset_id → 调接口查 asset.device_id 映射
     ├── 有映射 → device_id = 映射值
     └── 无映射 → device_id = null（该资产无物联接入）
  无 device_id + 无 asset_id → device_id = null

时序说明：N4c（设备 ID 解析）与 N1→N2（分类检索链路）是两条独立并行的分支，从 Start 后同时执行。分类链路负责打标和知识库检索，数据链路负责拉取 IOT + 资产历史，最终在 N6 汇合——互不依赖，并行不悖。

2.7 N6 — HTTP Request：多维数据上下文注入

N5a — IOT 数据注入（device_id 驱动）

配置项	值
方法	GET
URL	`{{IOT_API}}/api/v1/devices/{{device_id}}/diagnosis-context`
超时	3s
条件执行	`device_id` 不为空时执行
失败处理	静默跳过，不阻断流程
输出变量	`iot_data`（null 或 JSON 对象）

响应示例：

json

{
  "device_id": "DEV-AHU-001",
  "snapshot_time": "2026-06-18T14:21:00+08:00",
  "properties": [
    {"name": "回风温度", "value": 30.5, "unit": "°C", "range": null},
    {"name": "回风温度设定", "value": 24.0, "unit": "°C", "range": null},
    {"name": "送风温度", "value": 22.3, "unit": "°C", "range": "14~18"},
    {"name": "送风温度设定", "value": 18.0, "unit": "°C", "range": null},
    {"name": "运行模式", "value": "制冷", "unit": null, "range": null},
    {"name": "风机运行状态", "value": "运行", "unit": null, "range": null},
    {"name": "风机变频器频率反馈", "value": 45.0, "unit": "Hz", "range": "20~50"},
    {"name": "冷水阀阀位反馈", "value": 18.5, "unit": "%", "range": "60~80"},
    {"name": "新风温度", "value": 36.2, "unit": "°C", "range": null},
    {"name": "新风阀阀位反馈", "value": 25.0, "unit": "%", "range": null},
    {"name": "初效滤网报警", "value": "正常", "unit": null, "range": null},
    {"name": "中效滤网报警", "value": "正常", "unit": null, "range": null}
  ],
  "alarms": [
    {"description": "无告警记录（近30天）", "level": null, "time": null}
  ]
}

properties 包含物模型实时值，alarms 为告警记录。两者均可能为空。

N5b — Asset 历史数据注入（asset_id 驱动）

配置项	值
方法	GET
URL	`{{ASSET_API}}/api/v1/assets/{{asset_id}}/diagnosis-context?repair_days={{REPAIR_DAYS}}&repair_top_k={{REPAIR_TOP_K}}&maintenance_days={{MAINTENANCE_DAYS}}&maintenance_top_k={{MAINTENANCE_TOP_K}}&inspection_days={{INSPECTION_DAYS}}&inspection_top_k={{INSPECTION_TOP_K}}&parts_days={{PARTS_DAYS}}&parts_top_k={{PARTS_TOP_K}}&exclude_order={{current_work_order_id}}`
超时	3s
条件执行	`asset_id` 不为空时执行
失败处理	静默跳过，不阻断流程
输出变量	`asset_history`（null 或 JSON 对象）

后端过滤规则：所有工单仅取 status = "已完成"；repair_orders 额外排除 id == exclude_order；maintenance_records / inspection_records 仅取"已保养"/"已巡检"状态；时间范围和条数由各类型的独立参数控制（repair_days / maintenance_days / inspection_days / parts_days 等）。

响应示例：

json

{
  "asset_id": "AST-2026-0608-007",
  "device_id": "DEV-AHU-001",

  // 历史报修工单（动态表单，fields 由工作流引擎配置，非结构化 items）
  "repair_orders": [
    {
      "id": "WO-2025-0115-003",
      "time": "2025-01-15",
      "description": "冷水阀执行器更换",
      "fields": [
        {"name": "资产名称", "value": "空调机组AHU-001"},
        {"name": "专业类型", "value": "综合维修"},
        {"name": "是否紧急", "value": "一般"}
      ]
    }
  ],

  // 历史保养记录（仅已保养，含保养项明细，排除 保养标准·数据类型=图片 ）
  "maintenance_records": [
    {
      "time": "2026-03-10",
      "conclusion": "正常",
      "items": [
        {"name": "清洗滤网", "value": "正常"},
        {"name": "风机皮带", "value": "正常"},
        {"name": "冷水阀执行器", "value": "正常"}
      ]
    }
  ],

  // 历史巡检记录（仅已巡检，含巡检项明细，排除 巡检标准·数据类型=图片）
  "inspection_records": [
    {
      "time": "2026-06-22 15:25:39",
      "conclusion": "正常",
      "items": [
        {"name": "文本输入项", "method": "检查方法说明…", "value": "xxx"},
        {"name": "选项", "value": "对"},
        {"name": "数值（必填）", "value": "100"}
      ]
    },
    {
      "time": "2026-06-05",
      "conclusion": "正常",
      "items": []
    }
  ],

  // 零配件更换记录
  "parts_replacements": [
    {"time": "2025-01-15", "part_name": "冷水阀执行器（TAC原厂）", "part_type": "办公用品类", "quantity": 1}
  ]
}

字段	来源（资产详情页 Tab）	说明
`repair_orders`	Tab 4 — 报修	该资产历史报修工单，动态表单字段见 §2.7.2
`maintenance_records`	Tab 6 — 保养	仅取"已保养"记录，含各保养项详情（详见 §2.7.1）
`inspection_records`	Tab 5 — 巡检	仅取"已巡检"记录，含各巡检项详情（详见 §2.7.1）
`parts_replacements`	Tab 8 — 零配件更换	该资产历史零件更换记录（仅保留 part_name/part_type/quantity，去掉更换人）

2.7.1 界面参照

类型	工单详情	点/字段详情
巡检
保养
报修		—
零配件		—

2.7.2 筛选与裁剪规则

所有 N5b 返回的数据受以下参数控制，Dify 工作流变量和工单系统入参均可覆盖：

维度	规则
状态筛选	仅取 `status = "已完成"`（报修）/ `"已巡检"`（巡检）/ `"已保养"`（保养）
时间范围	各类型独立配置：`REPAIR_DAYS`（报修）、`MAINTENANCE_DAYS`（保养）、`INSPECTION_DAYS`（巡检）、`PARTS_DAYS`（零配件）
条数上限	各类型独立配置：`REPAIR_TOP_K`（报修）、`MAINTENANCE_TOP_K`（保养）、`INSPECTION_TOP_K`（巡检）、`PARTS_TOP_K`（零配件）
排除当前单	`repair_orders` 排除 `id == current_work_order_id`

2.8 N7 — LLM：生成诊断报告（SSE 流式）

配置项	值
模型	DeepSeek-V3 / Qwen-Max
上下文	N2 + N4 + N5a + N5b 输出
Temperature	0.3
最大 Token	4096
输出方式	SSE 流式（`response_mode: streaming`）

System Prompt：

{# FA_一键诊断_生成报告_Prompt #}

你是设施运维 FA 一键诊断专家。综合台账、物联、历史（巡检/保养/报修/更换）、告警与知识库，输出中文 Markdown 诊断正文（勿 JSON、勿全文代码围栏、勿思考过程）。
结构须按下列顺序（无内容则省略该节；勿重复分类面包屑）。二级标题只用 ##。

## 故障概述
1～3 句：现象 + 与工况表、主因一致的关键信号解读。

## 工况与指标
表：指标 | 当前值 | 期望值 | 状态。只留 5～8 行能支撑主因的测点。
- 当前值只来自 JSON/摘要；无任何遥测才可省略或一行「无数据」。
- 设定只写在「期望值」列（如「25.0°C（设定）」），禁止「xxx设定」单独占行；仅同名成对（回风温度↔回风温度设定，送风温度↔送风温度设定）。
- 明显不合理的设定忽略（室内湿度设定低于30%或高于80%；回风/房间类设定低于16℃或高于32℃）。referenceRange 是量程不是期望 →「—」。
- 微小偏差不入表（相对设定：温度绝对偏差小于1℃、湿度/百分比小于2%）。
- 原因/步骤点到的测点必须入表；未入表禁止当证据。
- 状态：有可靠设定 → 偏差±N / 偏高 / 偏低 / 正常；枚举故障/停机 →「异常」或写读数语义；无对照 →「无法判定」（禁止凭经验写正常/偏低）。
- 偏差 = 当前 − 期望；「高于/低于」与符号一致。

## 告警
仅当确有告警记录时写；无则整节省略，禁止「无告警记录」占位。
表：时间 | 级别 | 内容。最多 5 行，按时间新→旧；时间与级别照抄输入摘要（已是可读格式），内容写告警名称/现象，设备名若概述已出现可省略。

## 可能原因
2～4 条，按 高→中→中低→低 排序。证据用自然语言（测点名 + 当前值/枚举态 + 为何解释现象），句末 [C:N]；禁止「证据回指上表信号」套话。
格式示例：
1. **风机故障** 高
风机运行状态为「停机」、故障状态为「故障」，送风无法有效送达室内，与房间不冷现象一致 [C:1]。
2. **初效滤网堵塞** 中
初效滤网报警为「报警」，风量可能受限，房间降温困难 [C:1]。
- 无设定的阀位/频率：表内「无法判定」；证据用相对表述，禁止「低于/高于正常范围/正常开度」。
- 「报警正常 / 未见报警」不能当堵塞或故障的主证据。

## 排查步骤
3～5 步，易→难，可现场执行；[C:N]。

## 安全提示
放在排查步骤之后。用 > 引用块写作业风险；无专项则一句通用电气/压力提醒。

## 需现场核实
仅补未覆盖短项；重复则省略。

归因铁律（违反则整份不合格）：
1) 风机故障或停机 → 高置信第一，须入表；概述须写送风/风量中断，禁止「制冷能力不足/制冷效果不佳/冷量不足」；次因禁止主推冷水阀（最多低优先级存疑）。
2) 送风已明显偏低（相对回风低很多，或十几℃及以下）且风机在转 → 冷量到位，主因走风阀/滤网/风量，禁止写「制冷能力不足」。
3) 冷水阀约≥60% 且送风已不热 → 禁止「冷水阀开度不足」作中高因。
4) 送风明显偏高（接近/高于回风，或远高于送风设定）且风机正常 → 可主推冷量/冷水阀/盘管。
5) 概述、表、原因、步骤同一套数字与结论；禁止引用未入表设定。

禁则：勿输出内部字段名；勿粘贴 Hub 报错；勿文末列引用来源；[C:N] 须为检索真实 id。
文末固定一行：本建议仅供参考，如有疑难请升级处理。

User Prompt：

## 故障描述
{{effective_fault_description}}

## 问题归类（勿写入正文）
{{problem_classification_path}}｜{{system_name}} / {{component_name}} / {{fault_symptom}}｜置信度 {{tag_confidence}}
{{tag_reasoning}}

## 上下文（勿写入正文）
context_mode={{context_mode}}；repair_case={{repair_case}}；repair_object={{repair_object}}

## 资产摘要
{{asset_summary}}

## 资产/信号 JSON
{{asset_context_json}}

## 知识检索（[C:N] 对应条目 id）RAG={{kb_hit_count}} Web={{web_hit_count}} enabled={{web_search_enabled}}
{{kb_context}}

## Hub 告警（勿写入正文）
{{hub_errors}}
{{kb_error}}

v3.0 回填说明：本 Prompt 取自生产实现（质量高于原 PRD 草案，反向回填）。相对原草案，新增 「告警」「需现场核实」 两个章节，并引入 「工况与指标」表格规则 与 归因铁律 5 条。

前端不做结构化拆分——LLM 输出的 Markdown 通过 SSE text_chunk 事件流式推送，前端逐字渲染。

SSE 事件流：

事件	触发时机	数据
`workflow_started`	工作流开始	`task_id`, `diagnosis_id`
`text_chunk`	LLM 逐段生成	`{"text": "## 可能原因\n1. ..."}`
`node_finished` (N7)	LLM 生成完毕	`{"outputs": {"diagnosis_report": "..."}}`
`workflow_finished`	工作流结束	完整 JSON（含 classification + references）

前端收到 workflow_finished 后渲染引用来源栏。

2.9 N8 — End：输出

N7 流式结束后，workflow_finished 携带完整结构化数据。references 基于知识库检索结果，但以「正文实际引用」为准：先剔除正文中未落在真实检索结果内的 [C:N]（防幻觉引用），再只保留正文引用到的条目——正文引用才算证据。（原草案为「检索即证据、不做过滤」，v3.0 按生产实现修订。）

输出格式：

json

{
  "diagnosis_id": "diag_20260617_001",
  "classification": {
    "category": "弱电智能化",
    "tag": "闸机",
    "symptom": "无法升降",
    "confidence": 0.9,
    "is_low_confidence": false
  },
  "references": [
    {
      "document_title": "广宁闸机V6使用手册",
      "source_file_url": "oss://kb-fa/门禁道闸/GNG闸机V6.pdf"
    }
  ],
  "citation_hint": null,
  "has_knowledge_match": true,
  "has_iot_data": false,
  "has_asset_history": true
}

字段	说明
`citation_hint`	引用为空时的话术，由 Dify 工作流变量控制。有引用时为 `null`，前端渲染正常引用栏；无引用时为预设话术，前端直接展示

citation_hint 在 Dify 工作流变量中通过 NO_CITATION_HINT 配置，默认值："暂无可参考的文档，诊断建议由 AI 基于通用常识生成。"

3. 异常处理

场景	处理
HTTP N1 超时/失败	tag_list 回退到内置默认列表（硬编码兜底）
LLM N2 超时	返回 `{error: "打标服务暂不可用"}`
LLM N2 输出非 JSON	正则提取 + 重试 1 次；仍失败则返回 `confidence: 0`
知识库检索无结果	N6 走 LLM 常识兜底，`references` 为空数组
HTTP N4c 超时/失败	`device_id = null`，静默跳过，后续 IOT 数据不可用
HTTP N5a 超时/失败	`iot_data = null`，静默跳过
HTTP N5b 超时/失败	`asset_history = null`，静默跳过
LLM N6 超时	返回 `{error: "诊断服务暂不可用，请稍后重试"}`

4. API 调用（SSE 流式）

Dify Workflow 对外暴露流式 API，供工单系统「一键诊断」按钮调用：

POST /v1/workflows/run
Content-Type: application/json

{
  "inputs": {
    "work_order_description": "G馆1楼入口闸机翼臂无法升降",
    "asset_id": "AST-2024-0882",
    "device_id": null
  },
  "response_mode": "streaming",
  "user": "operator_zhang"
}

使用 streaming 模式，前端通过 EventSource 接收 SSE 事件流。诊断报告逐字渲染，引用来源在流结束后一次性展示。

文档版本：v3.0最后更新：2026-09-17作者：强哥

版本记录

版本	日期	变更
v1.0	2026-06-17	初稿
v2.0	2026-06-22	新增 device_id 输入 + N4c device_id 解析节点；N5 拆为 N5a IOT 注入 + N5b Asset 历史数据注入；N6 Prompt 增加资产历史上下文
v2.2	2026-07-02	命名重构：文档内概念名更新 System→Category, Component→Tag，Dify 变量名同步更新
v2.1	2026-06-23	System 自定义化改造：N1 API 扩展为 `classification-labels` 返回 categories+tags；N2 Prompt category 候选值改为 `{% for %}` 动态渲染；新增 N1c Code Node 提取 safety_tip；N7 Prompt 安全提示改为 `{{category_safety_tip}}` 数据驱动
v3.0	2026-09-17	按生产实现对齐（现状 + 待开发）：N2 打标输入面扩展为「分类树 + 资产摘要 + 近 N 天告警 + 故障描述」（并规划追加设备实时 IOT）；N1c 数据驱动安全提示下线；N3 置信度分支标注未实现、检索合并为单路；N4 Metadata Filter 标注待开发；N7 报告 Prompt 反向回填（告警/需现场核实章节 + 归因铁律）；N8 引用口径改为「正文引用才算证据」

第三方日历集成

访客预约

01-设计

02-知识库

设计方案

语料

03-场景与数据

01-调研

FA 一键诊断 — Dify 编排功能设计 v3.0

1. Workflow 总览

1.1 节点清单

1.2 输入变量

2. 节点详细设计

2.1 N0 — Start 与工作流变量

2.2 N1 — HTTP Request：拉取分类标签（Categories + Tags）

2.3 N2 — LLM：打标

2.4 N3 — IF/ELSE：置信度分支（未实现 · 预留）

2.5 N4 — Knowledge Retrieval：知识库检索

2.6 N5 — HTTP Request：device_id 解析

2.7 N6 — HTTP Request：多维数据上下文注入

N5a — IOT 数据注入（device_id 驱动）

N5b — Asset 历史数据注入（asset_id 驱动）

2.7.1 界面参照

2.7.2 筛选与裁剪规则

2.8 N7 — LLM：生成诊断报告（SSE 流式）

2.9 N8 — End：输出

3. 异常处理

4. API 调用（SSE 流式）

版本记录

设计方案

语料

FA 一键诊断 — Dify 编排功能设计 v3.0 ​

1. Workflow 总览 ​

1.1 节点清单 ​

1.2 输入变量 ​

2. 节点详细设计 ​

2.1 N0 — Start 与工作流变量 ​

2.2 N1 — HTTP Request：拉取分类标签（Categories + Tags） ​

2.3 N2 — LLM：打标 ​

2.4 N3 — IF/ELSE：置信度分支（未实现 · 预留） ​

2.5 N4 — Knowledge Retrieval：知识库检索 ​

2.6 N5 — HTTP Request：device_id 解析 ​

2.7 N6 — HTTP Request：多维数据上下文注入 ​

N5a — IOT 数据注入（device_id 驱动） ​

N5b — Asset 历史数据注入（asset_id 驱动） ​

2.7.1 界面参照 ​

2.7.2 筛选与裁剪规则 ​

2.8 N7 — LLM：生成诊断报告（SSE 流式） ​

2.9 N8 — End：输出 ​

3. 异常处理 ​

4. API 调用（SSE 流式） ​

版本记录 ​

FA 一键诊断 — Dify 编排功能设计 v3.0

1. Workflow 总览

1.1 节点清单

1.2 输入变量

2. 节点详细设计

2.1 N0 — Start 与工作流变量

2.2 N1 — HTTP Request：拉取分类标签（Categories + Tags）

2.3 N2 — LLM：打标

2.4 N3 — IF/ELSE：置信度分支（未实现 · 预留）

2.5 N4 — Knowledge Retrieval：知识库检索

2.6 N5 — HTTP Request：device_id 解析

2.7 N6 — HTTP Request：多维数据上下文注入

N5a — IOT 数据注入（device_id 驱动）

N5b — Asset 历史数据注入（asset_id 驱动）

2.7.1 界面参照

2.7.2 筛选与裁剪规则

2.8 N7 — LLM：生成诊断报告（SSE 流式）

2.9 N8 — End：输出

3. 异常处理

4. API 调用（SSE 流式）

版本记录