首屏结论：制造业客诉 8D 可以用 Agent 提效，但目标不能是“自动写一份漂亮报告”。真正的闭环是：把投诉绑定到客户、订单、产品、批次和检验标准，先控制受影响范围，再推进原因确认、纠正措施、横向展开和下一批验证；只有 QMS、WMS、MES、ERP 与客户处理状态都回读一致，才算完成。单件、低风险、原因已知的问题不必硬套 8D。
先判断：这次客诉是否应该启动 8D
企业应先用确定性分级规则判断流程，不让模型凭语气决定严重性。可把以下表直接作为启动门槛：
| 判断项 | 走普通客诉工单 | 启动 8D / CAPA |
|---|---|---|
| 影响范围 | 单件、可立即更换 | 批次、多个订单或流向不清 |
| 是否复发 | 首次且原因明确 | 同类问题重复发生 |
| 风险等级 | 不涉及关键质量特性 | 涉及安全、法规或客户关键要求 |
| 处置复杂度 | 标准退换货即可 | 需要隔离、返工、让步或横向展开 |
| 客户要求 | 未要求正式整改 | 合同或客户明确要求 8D |
这张表属于质量制度，字段、阈值和审批人要由企业自己定义并版本化。Agent 可以读取规则并执行分流，但不能自行修改规则。
一条可执行的 8D 链需要哪些业务对象
客诉不是一段聊天记录，而应有唯一案件号，并关联客户、销售订单、产品型号、成品与原料批次、生产工单、检验记录、出货流向、NCR/CAPA、处置单和客户确认。没有这些对象，所谓“追溯”最终仍会退回微信群里问人。
事实源通常分散在：
- CRM 或客服系统：客户原话、投诉时间、数量、现场照片和回复版本；
- ERP、MES：订单、工单、BOM/工艺版本和生产批次；
- QMS：原始检验结果、标准版本、NCR、复检与放行决定；
- WMS、TMS：库存、预留、在途、出货批次与客户流向；
- 文档与审批系统：8D 版本、责任人、处置批准和客户书面同意。
可先阅读工厂上了 ERP/MES，AI 还能再做什么，再结合AI Agent 项目验收的 7 个检查点理解“接数据”和“闭环验收”的区别。
Agent 负责追证据，人负责作质量决定
收到客诉后，Agent 先去重同一事件，检查型号、批次、数量、标准版本是否完整；再按确定性关系查询同批库存、在制、已发货和可能受影响对象，形成“确定影响、可能影响、证据不足”三组清单。质量负责人确认范围后，系统才把批准的暂缓状态写入 QMS、WMS、MES 或 ERP。
8D 推进中，Agent 适合做五件事：追缺失证据；检查每个措施是否有责任人、期限和验收条件；保存报告与客户回复的每个版本；识别相同工艺、模具、物料或供应商上的横向展开对象；等待下一可比批次到来并创建验证任务。
根因、严重性、责任归属、报废、让步、召回和最终放行必须由有权人员确认。Agent 可以把“加强培训”这种空泛措施标为证据不足，却不能替质量工程师发明根因。
8D 的关闭门槛：不是报告发出，而是四处状态一致
建议把关闭条件固定成一张验收卡：
| 关闭门槛 | 必须回读的证据 |
|---|---|
| 受影响范围已受控 | 库存、在制、在途与客户流向数量可核 |
| 临时处置已执行 | 返工、退货、报废或让步单有真实终态 |
| 永久措施已落地 | 工艺、文件、设备参数或供应商措施写入权威系统 |
| 效果验证已通过 | 下一可比批次或约定观察窗的检验结果通过 |
| 客户处理已完成 | 对外版本经审核，客户确认或合同约定状态已记录 |
任何一项不可回读，案件就保持“待验证”或“人工接管”；验证失败则重开原案件，不能新建一张单把历史切断。写入成功后还要再次读取源系统，避免接口返回成功、实际状态却没变。
从一个真实客诉开始，不先做全厂大平台
首个试点只需选一类高频客诉，接最少必要系统：CRM/客诉入口、QMS、批次流向和审批。先用历史案件验证对象关联与分级规则，再跑一条新客诉到下一批效果验证。验收重点是影响范围是否可核、人审是否守住、动作是否写回、终态是否能独立回读，而不是 8D 文案写得像不像专家。
想把这条链接入生产与质量体系，可从制造业解决方案和生产岗位 Agent 场景继续拆场景；完整实施路径可参考企业 AI 落地五项工程。
