别焦虑,我们开始分享在工业场景中一系列agent构建指南,今天从8D agent开始~
这是一份构建指南,实践过程中的提示词会更严谨,需要私信我们获取更多信息。
01
系统架构概述
目标:输入非结构化的用户描述或现场照片(手写记录/报错截图),输出符合行业标准(Ford/VDA)的结构化 8D 报告。
适用场景:质量工程师(QE)在车间现场或办公室内,无 MES/QMS 接口权限,仅依靠文档和经验进行故障分析。
核心模式:Workflow (工作流)。相比 Chat 模式,工作流能强制模型按 D0->D8 顺序思考,避免逻辑跳跃。
02
知识库准备 (Context Layer)
Agent 的智能程度取决于“它读过多少历史案例”。由于不接系统,你需要手动导入历史数据。
数据准备建议:
历史 8D 报告:不要直接上传扫描件 PDF。建议将历史报告清洗为 Excel/CSV,包含列:问题现象、根本原因(D4)、解决措施(D5)。
FMEA / 常见缺陷库:上传产品的失效模式库。
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:
你是工业数据提取助手。请分析用户上传的图片。
若是文本/表格/屏幕报错:请精准 OCR 识别所有文字。
若是实物缺陷图:请描述缺陷的物理特征(位置、形状、颜色、裂纹走向等)。
输出:仅输出识别内容,无废话。
· 节点 4: 变量聚合 (Template Transform)
输入变量:sys_query, Node3_output (来自视觉节点的输出,若未运行则为空)。
模板代码:Plaintext(见下图)
输出变量名:full_context (这将是后续所有分析的基础上下文)。
Plaintext
<User_Input>
{{sys_query}}
</User_Input>
<Image_Analysis_Data>
{{Node3_output}}
</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小时内阻断缺陷流出到客户。
限制:严禁在此阶段提出修改模具、更改代码等长期措施。
输出包括:
库存品处理(隔离/重检/报废)。
在制品(WIP)处理。
在途/客户端产品处理建议。
· 节点 8: D4 根本原因分析 (LLM Node - RCA)
输入: D2_output, context
Prompt:
进行根本原因分析 (RCA)。
逃逸点 (Escape Point):为什么现有的探测手段(如AOI、终检)没有拦截住缺陷?
产生点 (Root Cause):使用 5Why 分析法,至少追问 3 层,直到找到物理参数或管理流程的缺失。
参考知识库中的历史案例,判断是否为旧疾复发。
· 节点 9: D5 长期对策 (LLM Node - PCA)
逻辑纠正:D5 是消除 D4 找到的根因。
输入: D4_output
Prompt:
针对 D4 的根因,制定永久纠正措施 (PCA)。
要求:
undefined.技术层面:优先采用防错设计 (Poka-Yoke)、硬件变更、参数固化。
undefined.避免“加强员工培训”、“加强处罚”等低效的人治措施。
· 节点 10: D6 效果验证 (LLM Node - Verification)
逻辑纠正:D6 是验证 D5 措施是否有效。
输入: D5_output
Prompt:
制定 D6 验证计划。
注意:这不是让你实施措施,而是让你证明措施有效。
输出内容:
验证方法(如:小批量试产 500pcs)。
关键指标监控(如:Cpk > 1.33, 良率提升至 99.9%)。
负面影响评估(Side Effect):确认修改不会导致其他新问题。
·节点 11: D7 预防与体系闭环 (LLM Node - Prevention)
逻辑纠正:D7 是文件化和横向展开。
输入: D5_output, D6_output
Prompt:
假设 D6 验证通过,制定 D7 预防措施。
文件更新清单:明确需更新 PFMEA, Control Plan (CP), SOP, 作业指导书。
横向展开 (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
{
"title": "8D Report - {{sys_query}}",
"sections": {
"d2": "...",
"d3": "...",
"d4": "..."
}
}
这样前端应用可以根据 JSON 里的字段,渲染成公司特定的 PDF 模板样式。
2.人机交互 (Human-in-the-loop):
Dify 的 Workflow 允许“人工确认”节点。你可以在 D4 (根因分析) 之后插入一个人工确认步骤,让工程师审核 LLM 分析的根因是否靠谱。如果不靠谱,人工修改后,再让 LLM 继续生成 D5-D8。
05
测试与调优
构建完成后,请按以下 Case 进行测试:
纯文本测试:比如输入“电池外观划痕”,检查 D3 是否建议了隔离库存,D4 是否分析了运输或抓手问题。
图片测试:上传一张手写的生产日报表(字迹潦草),检查 Node 3 是否准确识别了数据,并将其纳入了后续分析。
逻辑测试:仔细检查输出报告中,D3(临时)和 D5(长期)的内容是否有重叠或搞反,如果有,需加强 Prompt 中的“Negative Constraint(负向约束)”。

扫描二维码 获取更多

