用 Dify 将人工排障 SOP 转成可执行工作流，让客服与一线运营更快获得有证据的诊断和回复
随着公司核心业务发展，相关设备、算法场景和告警量持续增长，服务无响应、告警延迟、误报和退订失败等问题不断增加。所有 AI 相关问题均会以工单形式流入部门。
由于原有客服体系的专业能力有限，无法独立完成 AI 相关业务的排障处理。客服或一线运营收集客户反馈后，需要逐级联系专业运营、算法、研发和运维。问题信息经常不完整，排查人员还需要在多个业务系统中反复查询，许多常见故障最终仍被转派给研发。这导致 AI 业务部门投入大量人力进行重复性排障支撑，每个 Sprint 都需要消耗近 2–3 人的全职投入。
为释放排障资源并形成标准化的 AI 排障 SOP，项目使用 Dify Workflow 串联现有排障知识、业务接口和运营工单体系，让前线更快获得有事实依据的诊断和规范回复。
完成核心问题分类、知识整理、业务接口接入与主要排障流程。
覆盖业务产品、Dify 应用、接口研发、测试和平台支持。
补充故障类型、优化知识命中和调整自动化边界。
包含内部 Qwen 32B、Dify、平台服务和相关算力资源。
主要完成原有系统接口适配，以及工单系统增加 Agent 处理状态与相关流程。
项目并非只靠减少外包岗位覆盖平台成本。核心价值是让业务规模继续增长时，客服、运营和研发投入不再同步线性扩张；同时改善投诉、工单时效、前线回复质量和知识沉淀。约 6 万元/月的运行投入换取的是规模承载能力和组织效率，而不仅是单一人力替代。
按照架构中的处理顺序，说明每一层接收什么、如何处理、调用哪些能力，以及交付什么结果。
业务入口、处理状态载体与最终结果出口
客服或一线运营提交 AI 相关工单，包含客户、设备、算法场景、问题时间和影响范围等已知信息。
创建问题记录，维护待补充、排查中、执行中、已恢复和转人工等状态。
通过现有 API 将工单内容传给 Dify，并接收信息补充要求、Agent 处理状态和最终结果。
向客服和一线运营展示处理进度，并沉淀根因、处理动作、复查结果与客户回复。
工单调用失败时保留原始内容和错误信息，不影响人工继续接手处理。
Dify 总控工作流，负责将自然语言问题转换为可执行任务
接收工单描述、已有结构化字段和历史处理信息。
识别问题意图和故障类型，提取客户、设备、算法、时间与影响范围，判断信息是否完整。
QwenVL 32B 完成语义理解和参数提取，Dify 条件分支根据问题类型路由到对应排障流程。
生成标准化问题对象，包含问题类型、关键参数、排障流程和当前处理状态。
缺少必要字段时明确生成补充清单并回写工单；无法识别或置信度过低时转人工。
按照 SOP 调用知识与业务事实，形成可追溯的根因定位
接收已完成问题分类和信息补充的标准化问题对象。
根据问题类型生成排查计划，按顺序查询集群、设备、抽帧、算法任务、消息和配置状态。
RAG 检索 SOP、错误码、业务规则和历史案例；Function Call 获取当前业务系统返回的真实状态。
输出根因、关键证据、置信度和建议处理方向，每项结论都能回溯至知识或接口结果。
证据不足、接口异常或返回结果相互冲突时，不输出确定根因，携带已有记录转人工。
把已确认的问题定位转换为参数完整、边界明确的执行任务
仅接收排查 Agent 已给出明确定位、关键证据和建议处理方向的问题。
补齐执行对象、命令、参数和前置条件，判断动作风险级别，并校验必填参数。
QwenVL 32B 辅助参数补齐，Function Call 执行低风险动作或调用现有接口创建运营工单。
低风险操作保留执行前后值与返回结果；高风险工单携带根因、证据、命令和参数。
参数不完整、执行失败或超过重试次数时终止自动处理，保留执行记录并转专业运营。
事件结束后独立扫描执行中工单，判断业务是否真正恢复
定时扫描内部工单系统中标记为“执行中”的工单，不依赖前一次 Dify 事件持续运行。
查询工单处理结果，并再次检查集群、设备、任务、算法和消息等关键业务指标。
Function Call 查询工单与业务状态，QwenVL 32B 整理复查证据并生成内部结论和客户回复。
已恢复则回写标记和最终回复；仍在执行则等待下一次扫描；未恢复则直接转人工介入。
工单结果和业务状态冲突、查询异常或超过处理时限时，保留复查记录并转人工。
客服和一线运营是系统使用者，但不是高风险操作审批人。Dify 不承担专业运维权限：重启、SQL 和高风险配置修改进入原运营系统，由专业运营人员在既有权限和审计机制下确认并执行。
相对下降约 60%，前线能够更快获得可解释的处理进展和回复。
信息补全、常见查询和证据整理在进入专业运营前已经完成。
常见问题由标准工作流处理，研发集中解决未知和复杂问题。
自动查询和标准回复降低了基础运营岗位投入。
该节省不单独作为覆盖全部平台运行成本的依据。