8D 报告生成 Agent 构建指南 (Dify Workflow版)

annie XIONG
2026-02-11

别焦虑,我们开始分享在工业场景中一系列agent构建指南,今天从8D agent开始~


这是一份构建指南,实践过程中的提示词会更严谨,需要私信我们获取更多信息。


01


系统架构概述


  • 目标:输入非结构化的用户描述或现场照片(手写记录/报错截图),输出符合行业标准(Ford/VDA)的结构化 8D 报告。

  • 适用场景:质量工程师(QE)在车间现场或办公室内,无 MES/QMS 接口权限,仅依靠文档和经验进行故障分析。

  • 核心模式:Workflow (工作流)。相比 Chat 模式,工作流能强制模型按 D0->D8 顺序思考,避免逻辑跳跃。


02


知识库准备 (Context Layer)


Agent 的智能程度取决于“它读过多少历史案例”。由于不接系统,你需要手动导入历史数据。


数据准备建议:

  1. 历史 8D 报告:不要直接上传扫描件 PDF。建议将历史报告清洗为 Excel/CSV,包含列:问题现象、根本原因(D4)、解决措施(D5)。

  2. FMEA / 常见缺陷库:上传产品的失效模式库。

  3. Dify 知识库设置:

  • 索引方式:高质量(High Quality)。

  • 分段设置:建议 Q&A 分段模式(如适用)或自动分段。

  • 检索参数:Top K = 3~5(参考最相关的 3-5 个案例),Score Threshold = 0.5(过滤掉不相关的噪音)。


03


Workflow 编排详解 (Logic Layer)


请在 Dify Workflow 画布中按照以下顺序连接节点。


第一阶段:输入与多模态处理


此阶段负责将所有输入(文字+图片)转化为 LLM 可读的文本上下文。

· 节点 1: 开始 (Start)

变量设置:

  • sys_query (Text, 必填): 用户对问题的文字描述。

  • sys_file (File, 选填, 支持图片): 现场照片、OCR 数据源。

· 节点 2: 条件分支 (Condition Router)

  • 判断逻辑:sys_file is not empty?

  • IF True (有图) -> 流向 节点 3。

  • ELSE False (无图) -> 流向 节点 4

·节点 3: 视觉分析 (LLM - Vision)

  • 模型:GPT-4o / Claude 3.5 Sonnet / Gemini 1.5 Pro (需支持 Vision)。

  • System Prompt:



你是工业数据提取助手。请分析用户上传的图片。

  1. 若是文本/表格/屏幕报错:请精准 OCR 识别所有文字。

  2. 若是实物缺陷图:请描述缺陷的物理特征(位置、形状、颜色、裂纹走向等)。

出:仅输出识别内容,无废话。



· 节点 4: 变量聚合 (Template Transform)

  • 输入变量:sys_query, Node3_output (来自视觉节点的输出,若未运行则为空)。

  • 模板代码:Plaintext(见下图)

  • 输出变量名:full_context (这将是后续所有分析的基础上下文)。

Plaintext

  1. <User_Input>

  2. {{sys_query}}

  3. </User_Input>


  4. <Image_Analysis_Data>

  5. {{Node3_output}}

  6. </Image_Analysis_Data>



第二阶段:RAG 与 逻辑推演 (Core Logic)


严格遵循 8D 流程的逻辑链。

· 节点 5: 知识库检索 (Knowledge Retrieval)

  • Query: full_context

  • 输出变量:context (历史类似案例)。

· 节点 6: D2 问题描述 (LLM Node)

  • 输入: full_context

  • Prompt:



将输入信息转化为 5W2H 格式。明确:Object(对象)、Defect(缺陷描述)、Quantity(涉及数量)。若信息缺失,标记“待确认”。



·节点 7: D3 围堵措施 (LLM Node - ICA)

  • 逻辑纠正:D3 是止血,不是治病。

  • 输入: D2_output, context

  • Prompt:



基于问题,制定临时围堵措施 (ICA)

目标:24小时内阻断缺陷流出到客户。

限制:严禁在此阶段提出修改模具、更改代码等长期措施。

输出包括:

  1. 库存品处理(隔离/重检/报废)。

  2. 在制品(WIP)处理。

  3. 在途/客户端产品处理建议。



· 节点 8: D4 根本原因分析 (LLM Node - RCA)

  • 输入: D2_output, context

  • Prompt:



进行根本原因分析 (RCA)。

  1. 逃逸点 (Escape Point):为什么现有的探测手段(如AOI、终检)没有拦截住缺陷?

  2. 产生点 (Root Cause):使用 5Why 分析法,至少追问 3 层,直到找到物理参数或管理流程的缺失。

  3. 参考知识库中的历史案例,判断是否为旧疾复发。



· 节点 9: D5 长期对策 (LLM Node - PCA)

  • 逻辑纠正:D5 是消除 D4 找到的根因。

  • 输入: D4_output

  • Prompt:



针对 D4 的根因,制定永久纠正措施 (PCA)。

要求:

  1. undefined.技术层面:优先采用防错设计 (Poka-Yoke)、硬件变更、参数固化。

  2. undefined.避免“加强员工培训”、“加强处罚”等低效的人治措施。




· 节点 10: D6 效果验证 (LLM Node - Verification)

  • 逻辑纠正:D6 是验证 D5 措施是否有效。

  • 输入: D5_output

  • Prompt:



制定 D6 验证计划。

注意:这不是让你实施措施,而是让你证明措施有效。

输出内容:

  1. 验证方法(如:小批量试产 500pcs)。

  2. 关键指标监控(如:Cpk > 1.33, 良率提升至 99.9%)。

  3. 负面影响评估(Side Effect):确认修改不会导致其他新问题。



·节点 11: D7 预防与体系闭环 (LLM Node - Prevention)

  • 逻辑纠正:D7 是文件化和横向展开。

  • 输入: D5_output, D6_output

  • Prompt:



假设 D6 验证通过,制定 D7 预防措施。

  1. 文件更新清单:明确需更新 PFMEA, Control Plan (CP), SOP, 作业指导书。

  2. 横向展开 (Look Across):该问题是否适用于厂内其他类似生产线?列出排查计划。




第三阶段:输出与定制化

· 节点 12: 报告生成 (LLM Node - Formatting)

输入: 所有 D2 - D7 的输出变量。

Prompt:



你是专业的质量报告生成器。请将收集到的信息整合成一份 Markdown 格式的 8D 报告。

格式模板:

8D Quality Improvement Report

D0: Basic Info

...

D2: Problem Description (5W2H)

{{D2_output}}

D3: Interim Containment Actions (ICA)

{{D3_output}}

D4: Root Cause Analysis (RCA)

{{D4_output}}

D5: Permanent Corrective Actions (PCA)

{{D5_output}}

D6: Verification of PCA

{{D6_output}}

D7: Prevention & System Closure

{{D7_output}}

D8: Team Recognition

(Draft a concise recognition statement for the team)



· 节点 13: 结束 (End)

  • 输出最终的 Markdown 文本或 JSON 结构。


04


给用户的定制化建议


为了满足“定制化报告”的需求,你可以在 Workflow 外部或最后一步进行调整:


1.JSON 模式:

如果你需要将报告推送到企业微信或飞书,建议将 节点 12 的输出格式改为 JSON:

JSON

  1. {

  2.   "title": "8D Report - {{sys_query}}",

  3.   "sections": {

  4.     "d2": "...",

  5.     "d3": "...",

  6.     "d4": "..."

  7.   }

  8. }



这样前端应用可以根据 JSON 里的字段,渲染成公司特定的 PDF 模板样式。


2.人机交互 (Human-in-the-loop):

Dify 的 Workflow 允许“人工确认”节点。你可以在 D4 (根因分析) 之后插入一个人工确认步骤,让工程师审核 LLM 分析的根因是否靠谱。如果不靠谱,人工修改后,再让 LLM 继续生成 D5-D8。


05


测试与调优


构建完成后,请按以下 Case 进行测试:

  1. 纯文本测试:比如输入“电池外观划痕”,检查 D3 是否建议了隔离库存,D4 是否分析了运输或抓手问题。

  2. 图片测试:上传一张手写的生产日报表(字迹潦草),检查 Node 3 是否准确识别了数据,并将其纳入了后续分析。

  3. 逻辑测试:仔细检查输出报告中,D3(临时)和 D5(长期)的内容是否有重叠或搞反,如果有,需加强 Prompt 中的“Negative Constraint(负向约束)”。

扫描二维码 获取更多

阅读64
分享