Dify 工作流实战用 Workflow 编排一个可控的 AI 自动化处理流程公众号码海寻道在前面的文章中我们已经介绍了 Dify 的平台能力、应用类型选择以及如何用知识库搭建 RAG 问答应用。如果说 RAG 解决的是“让模型基于企业知识回答问题”那么 Workflow 解决的就是另一个更工程化的问题如何把大模型能力放进一个可控、可观测、可复用的自动化流程里很多 AI 应用并不是简单问答而是由多个步骤组成。例如先接收一段文本再判断类型然后提取关键信息接着生成摘要最后输出结构化结果。如果全部依赖一次 Prompt流程会越来越难维护。Dify Workflow 的价值就在于用可视化节点把 AI 任务拆成多个明确步骤让每一步的输入、输出、条件和异常都更加清晰。这篇文章就以一个“用户反馈自动分析流程”为例讲清楚如何使用 Dify Workflow 编排一个可控的 AI 自动化处理流程。1. 为什么需要 Workflow在大模型应用早期很多需求都可以用一个 Prompt 快速完成。例如请总结下面这段用户反馈并判断它属于功能建议、Bug 反馈还是投诉。这种方式适合原型验证但当业务要求变复杂后单 Prompt 会暴露出很多问题•流程不清晰所有逻辑都写在一段提示词里后期难以维护。•中间结果不可见不知道模型在哪一步判断错了。•异常不好处理输入为空、内容无关、分类失败时缺少兜底路径。•输出不稳定模型可能没有严格按照预期格式返回。•难以复用某个步骤无法单独复用到其他流程中。Workflow 的核心思路是把复杂任务拆成多个节点每个节点只负责一件相对明确的事情。例如输入用户反馈 → 判断是否有效反馈 → 提取关键信息 → 分类反馈类型 → 判断优先级 → 生成处理建议 → 输出结构化结果这样一来流程更容易调试也更适合接入生产系统。2. Workflow 与 Chatflow 的区别在 Dify 中Workflow 和 Chatflow 都属于可视化编排能力但它们的侧重点不同。能力ChatflowWorkflow主要场景多轮对话单轮自动化流程是否强调会话记忆是否通常一次执行完成用户交互多轮输入与引导一次输入或系统调用流程目标管理对话路径管理任务处理链路典型用途分支客服、问诊、交互式表单报告生成、数据分析、批处理、后端 AI 流水线简单来说需要和用户来回对话用 Chatflow。 需要把一个任务自动处理完用 Workflow。如果你的应用更像“用户问一句系统内部跑一套处理流程然后返回结果”通常更适合 Workflow。3. 本文实战目标我们要设计一个“用户反馈自动分析流程”。输入是一段用户反馈文本例如最近更新后导出报表经常失败页面提示网络异常但我换了网络也不行。这个问题影响月底汇总希望尽快修复。Workflow 需要输出• 反馈摘要。• 反馈类型。• 影响程度。• 优先级。• 建议处理部门。• 建议回复话术。• 结构化 JSON 结果。这个场景很适合 Workflow因为它有明确的处理步骤而且结果通常要进入后续系统例如工单系统、客服系统或运营后台。4. 整体流程设计可以把流程设计为以下节点Start 开始节点 → 输入校验节点 → LLM 信息提取节点 → LLM 分类节点 → IF/ELSE 优先级判断节点 → LLM 回复建议节点 → 模板整理节点 → End 结束节点每个节点的职责如下节点作用Start接收用户反馈文本输入校验判断输入是否为空或无意义信息提取提取产品、问题、影响范围、用户诉求分类节点判断反馈属于 Bug、功能建议、投诉或咨询优先级判断根据影响程度判断 P0/P1/P2/P3回复建议生成客服或运营可用的回复话术模板整理统一输出格式End返回最终结果Workflow 的关键不是把节点堆得越多越好而是让每个节点承担清晰职责。5. 第一步创建 Workflow 应用进入 Dify 后可以新建一个 Workflow 类型应用。建议命名为用户反馈自动分析 Workflow命名最好体现业务对象和流程目标而不是只叫“测试工作流”。后续应用多了之后清晰命名会非常重要。创建后首先关注三个部分•输入变量流程需要接收哪些数据。•节点编排每一步如何处理。•输出结果最终给调用方返回什么。6. 第二步设计 Start 输入变量Start 节点负责接收流程输入。对于本文示例可以设计以下变量变量名类型说明feedback_textString用户反馈原文user_typeString用户类型例如免费用户、付费用户、企业客户product_moduleString反馈所属模块可选source_channelString来源渠道例如客服、表单、社群最核心的是feedback_text。其他字段可以帮助模型更准确判断优先级和处理建议。例如企业客户反馈的问题可能需要比普通用户反馈更高优先级。输入设计要遵循一个原则后续节点需要用到的信息尽量在 Start 节点明确接收不要让模型凭空猜。7. 第三步输入校验节点很多自动化流程忽略输入校验直接把原始内容交给大模型。这样容易产生无意义输出。输入校验可以处理以下情况• 内容为空。• 文本过短。• 明显不是用户反馈。• 包含无关内容。• 缺少可分析信息。如果 Dify Workflow 中使用条件判断节点可以设计类似规则如果 feedback_text 为空或长度小于 10 返回“反馈内容过短无法分析”。 否则 进入信息提取节点。输入校验的价值是把明显无效的请求挡在前面避免浪费模型调用成本。8. 第四步信息提取节点信息提取节点可以使用 LLM 节点完成。这个节点的目标不是生成完整回答而是从反馈中提取结构化信息。Prompt 可以这样设计你是一个用户反馈分析助手。 请从用户反馈中提取关键信息并严格按照 JSON 格式输出。 需要提取的字段 - summary一句话总结反馈内容 - product_module涉及的产品模块如果无法判断则输出 unknown - problem_description具体问题描述 - user_impact对用户造成的影响 - user_expectation用户希望得到的结果 用户反馈 {{feedback_text}}期望输出示例{ summary: 用户反馈报表导出经常失败影响月底汇总, product_module: 报表导出, problem_description: 导出报表时提示网络异常切换网络后仍无法解决, user_impact: 影响月底数据汇总工作, user_expectation: 希望尽快修复导出失败问题 }这里建议强制模型输出 JSON因为后续节点可以基于字段继续判断而不是从一段自然语言中再次解析。9. 第五步反馈分类节点分类节点同样可以使用 LLM 节点也可以结合规则判断。常见反馈类型包括• Bug 反馈。• 功能建议。• 使用咨询。• 体验投诉。• 账号或权限问题。• 其他。Prompt 示例请根据用户反馈内容判断反馈类型。 可选类型 - bug功能异常或错误 - feature_request希望增加或改进功能 - consultation使用咨询 - complaint负面体验或投诉 - account_permission账号、登录、权限相关问题 - other无法归类 请只输出 JSON { category: 类型编码, reason: 分类原因 } 用户反馈 {{feedback_text}} 已提取信息 {{extracted_info}}对于生产流程分类结果最好使用固定枚举值方便后续系统处理。不要让模型自由输出“这个问题看起来像是比较严重的导出异常”这种无法稳定解析的句子。10. 第六步优先级判断节点优先级判断可以由规则和模型共同完成。例如可以先定义一套优先级规则优先级判断标准P0大面积不可用、核心链路中断、数据安全问题P1重要功能不可用影响付费客户或关键业务P2局部功能异常有临时替代方案P3体验问题、轻微建议、低频问题可以让 LLM 根据规则输出建议优先级你是一个产品支持优先级判断助手。 请根据反馈内容、用户类型和影响范围判断优先级。 优先级规则 P0大面积不可用、核心链路中断、数据安全问题 P1重要功能不可用影响付费客户或关键业务 P2局部功能异常有临时替代方案 P3体验问题、轻微建议、低频问题 请只输出 JSON { priority: P0/P1/P2/P3, reason: 判断原因 } 用户类型{{user_type}} 反馈内容{{feedback_text}} 提取信息{{extracted_info}} 分类结果{{category_result}}如果 Dify Workflow 支持 IF/ELSE 分支可以在优先级之后加入条件判断如果 priority 为 P0 或 P1 进入高优先级处理路径。 否则 进入普通处理路径。这样可以把关键问题和普通问题分流。11. 第七步回复建议节点自动化流程不仅要分析问题还可以生成客服或运营人员可直接使用的回复建议。Prompt 可以这样写你是一个专业客服支持助手。 请根据用户反馈和分析结果生成一段回复建议。 要求 1. 语气礼貌、专业。 2. 不承诺无法确认的修复时间。 3. 如果是高优先级问题说明会尽快同步技术团队排查。 4. 如果信息不足引导用户补充必要信息。 5. 字数控制在 120 字以内。 用户反馈{{feedback_text}} 分类结果{{category_result}} 优先级{{priority_result}} 提取信息{{extracted_info}}示例输出您好已收到您关于报表导出失败的反馈。该问题可能影响月底数据汇总我们会尽快同步技术团队排查。为便于定位请补充导出时间、报表类型以及是否所有报表均失败。感谢您的反馈。这个节点的输出可以给客服人员参考而不是直接自动发送。生产环境中是否自动发送要看业务风险。12. 第八步统一输出结构Workflow 最终输出建议使用结构化格式方便被外部系统调用。例如{ summary: 用户反馈报表导出经常失败影响月底汇总, category: bug, priority: P1, product_module: 报表导出, user_impact: 影响月底数据汇总工作, suggested_owner: 技术支持/产品研发团队, reply_suggestion: 您好已收到您关于报表导出失败的反馈……, need_human_review: true }这里有一个关键字段need_human_review。对于高优先级问题、敏感问题或模型不确定的问题建议进入人工审核而不是完全自动处理。结构化输出的好处是• 后端系统容易解析。• 可以直接生成工单。• 可以用于数据统计。• 可以作为后续流程的输入。• 更容易做自动化测试。13. 第九步加入异常兜底可靠的 Workflow 不能只考虑正常路径还要考虑异常路径。常见异常包括• 用户输入为空。• 模型输出不是合法 JSON。• 分类结果不在枚举范围内。• 优先级判断缺失。• 外部工具或 API 调用失败。• 知识库检索无结果。可以设计兜底策略异常情况处理方式输入为空直接返回输入无效JSON 解析失败要求模型重试或进入人工处理分类未知标记为 other并进入人工审核高风险内容设置 need_human_review 为 true工具调用失败返回错误状态并记录日志自动化不是不需要人工而是把人工放在最需要判断的节点上。14. 第十步测试 WorkflowWorkflow 搭建完成后需要准备测试用例。建议覆盖以下输入14.1 正常 Bug 反馈导出报表一直失败提示网络异常影响月底汇总。期望结果category bug priority P1 或 P2 need_human_review true14.2 功能建议希望报表支持按部门批量导出现在只能一个个导出效率比较低。期望结果category feature_request priority P3 或 P214.3 使用咨询请问在哪里可以修改账号绑定的手机号期望结果category consultation 或 account_permission priority P314.4 无效输入你好期望结果返回输入信息不足提示补充具体反馈。14.5 敏感或高风险问题我们公司的所有客户数据都看不到了后台页面一直报错。期望结果priority P0 或 P1 need_human_review true测试时不要只看最终回答还要检查每个节点的中间输出。Workflow 的优势就在于可以定位到底是哪一步出了问题。15. 第十一步发布为 APIWorkflow 很适合作为后端 AI 流水线使用。当流程稳定后可以通过 API 方式被外部系统调用例如用户反馈表单 → 后端服务 → Dify Workflow API → 返回分析结果 → 创建工单或写入数据库API 集成时建议关注• 鉴权 Token 不要暴露在前端。• 请求参数要在业务后端先校验。• 记录请求 ID方便追踪日志。• 对失败响应做重试或降级处理。• 高优先级结果不要直接自动执行高风险动作。在生产环境中Dify Workflow 更适合作为 AI 能力编排层而不是替代全部业务系统。16. Workflow 设计原则结合上面的实战案例可以总结几条设计原则。16.1 一个节点只做一类事情不要把信息提取、分类、优先级判断和回复生成全部塞进一个 LLM 节点。节点职责越清晰越容易调试和复用。16.2 中间结果尽量结构化后续节点需要消费的内容尽量使用 JSON 或固定字段。自然语言适合给人看结构化数据适合给系统用。16.3 关键判断要有规则不要把所有判断都交给模型。优先级、权限、风险等级这类关键逻辑应该有明确规则模型只是在规则范围内辅助判断。16.4 高风险动作要人工确认涉及资金、权限、删除、通知客户、修改业务数据等操作时不建议让 AI 自动执行。应该设置人工审核节点或业务系统确认。16.5 先跑通小流程再扩展复杂度不要一开始就设计十几个节点。建议先跑通最小闭环再逐步增加分支、工具和异常处理。17. Workflow 适合哪些场景Dify Workflow 适合以下类型的任务• 文档摘要生成。• 用户反馈分析。• 工单自动分类。• 数据清洗与标签生成。• 简历筛选与候选人摘要。• 舆情分析与风险分级。• 定时报告生成。• 业务表单智能审核。• RAG 检索后的结构化回答生成。这些场景都有一个共同特点流程相对明确输入输出可以定义结果需要被系统或人继续处理。如果任务需要持续多轮交流更适合 Chatflow。如果任务需要模型自主探索和调用工具更适合 Agent。18. 总结Dify Workflow 的核心价值是把大模型从“单次问答能力”变成“可编排的流程节点”。通过 Workflow我们可以把复杂任务拆成多个清晰步骤并在每一步设计输入、输出、规则、分支和异常处理。对于企业级 AI 应用来说可控性往往比炫技更重要。一个好的 Workflow 不一定节点很多但一定要满足三个要求流程清晰 输出稳定 异常可控。当你需要把 AI 能力接入业务系统、自动化任务或后台流程时Workflow 往往是比普通聊天助手和 Agent 更稳妥的选择。这也是 Dify 从“快速搭应用”走向“工程化落地”的关键能力之一。
Dify 工作流实战：用 Workflow 编排一个可控的 AI 自动化处理流程
Dify 工作流实战用 Workflow 编排一个可控的 AI 自动化处理流程公众号码海寻道在前面的文章中我们已经介绍了 Dify 的平台能力、应用类型选择以及如何用知识库搭建 RAG 问答应用。如果说 RAG 解决的是“让模型基于企业知识回答问题”那么 Workflow 解决的就是另一个更工程化的问题如何把大模型能力放进一个可控、可观测、可复用的自动化流程里很多 AI 应用并不是简单问答而是由多个步骤组成。例如先接收一段文本再判断类型然后提取关键信息接着生成摘要最后输出结构化结果。如果全部依赖一次 Prompt流程会越来越难维护。Dify Workflow 的价值就在于用可视化节点把 AI 任务拆成多个明确步骤让每一步的输入、输出、条件和异常都更加清晰。这篇文章就以一个“用户反馈自动分析流程”为例讲清楚如何使用 Dify Workflow 编排一个可控的 AI 自动化处理流程。1. 为什么需要 Workflow在大模型应用早期很多需求都可以用一个 Prompt 快速完成。例如请总结下面这段用户反馈并判断它属于功能建议、Bug 反馈还是投诉。这种方式适合原型验证但当业务要求变复杂后单 Prompt 会暴露出很多问题•流程不清晰所有逻辑都写在一段提示词里后期难以维护。•中间结果不可见不知道模型在哪一步判断错了。•异常不好处理输入为空、内容无关、分类失败时缺少兜底路径。•输出不稳定模型可能没有严格按照预期格式返回。•难以复用某个步骤无法单独复用到其他流程中。Workflow 的核心思路是把复杂任务拆成多个节点每个节点只负责一件相对明确的事情。例如输入用户反馈 → 判断是否有效反馈 → 提取关键信息 → 分类反馈类型 → 判断优先级 → 生成处理建议 → 输出结构化结果这样一来流程更容易调试也更适合接入生产系统。2. Workflow 与 Chatflow 的区别在 Dify 中Workflow 和 Chatflow 都属于可视化编排能力但它们的侧重点不同。能力ChatflowWorkflow主要场景多轮对话单轮自动化流程是否强调会话记忆是否通常一次执行完成用户交互多轮输入与引导一次输入或系统调用流程目标管理对话路径管理任务处理链路典型用途分支客服、问诊、交互式表单报告生成、数据分析、批处理、后端 AI 流水线简单来说需要和用户来回对话用 Chatflow。 需要把一个任务自动处理完用 Workflow。如果你的应用更像“用户问一句系统内部跑一套处理流程然后返回结果”通常更适合 Workflow。3. 本文实战目标我们要设计一个“用户反馈自动分析流程”。输入是一段用户反馈文本例如最近更新后导出报表经常失败页面提示网络异常但我换了网络也不行。这个问题影响月底汇总希望尽快修复。Workflow 需要输出• 反馈摘要。• 反馈类型。• 影响程度。• 优先级。• 建议处理部门。• 建议回复话术。• 结构化 JSON 结果。这个场景很适合 Workflow因为它有明确的处理步骤而且结果通常要进入后续系统例如工单系统、客服系统或运营后台。4. 整体流程设计可以把流程设计为以下节点Start 开始节点 → 输入校验节点 → LLM 信息提取节点 → LLM 分类节点 → IF/ELSE 优先级判断节点 → LLM 回复建议节点 → 模板整理节点 → End 结束节点每个节点的职责如下节点作用Start接收用户反馈文本输入校验判断输入是否为空或无意义信息提取提取产品、问题、影响范围、用户诉求分类节点判断反馈属于 Bug、功能建议、投诉或咨询优先级判断根据影响程度判断 P0/P1/P2/P3回复建议生成客服或运营可用的回复话术模板整理统一输出格式End返回最终结果Workflow 的关键不是把节点堆得越多越好而是让每个节点承担清晰职责。5. 第一步创建 Workflow 应用进入 Dify 后可以新建一个 Workflow 类型应用。建议命名为用户反馈自动分析 Workflow命名最好体现业务对象和流程目标而不是只叫“测试工作流”。后续应用多了之后清晰命名会非常重要。创建后首先关注三个部分•输入变量流程需要接收哪些数据。•节点编排每一步如何处理。•输出结果最终给调用方返回什么。6. 第二步设计 Start 输入变量Start 节点负责接收流程输入。对于本文示例可以设计以下变量变量名类型说明feedback_textString用户反馈原文user_typeString用户类型例如免费用户、付费用户、企业客户product_moduleString反馈所属模块可选source_channelString来源渠道例如客服、表单、社群最核心的是feedback_text。其他字段可以帮助模型更准确判断优先级和处理建议。例如企业客户反馈的问题可能需要比普通用户反馈更高优先级。输入设计要遵循一个原则后续节点需要用到的信息尽量在 Start 节点明确接收不要让模型凭空猜。7. 第三步输入校验节点很多自动化流程忽略输入校验直接把原始内容交给大模型。这样容易产生无意义输出。输入校验可以处理以下情况• 内容为空。• 文本过短。• 明显不是用户反馈。• 包含无关内容。• 缺少可分析信息。如果 Dify Workflow 中使用条件判断节点可以设计类似规则如果 feedback_text 为空或长度小于 10 返回“反馈内容过短无法分析”。 否则 进入信息提取节点。输入校验的价值是把明显无效的请求挡在前面避免浪费模型调用成本。8. 第四步信息提取节点信息提取节点可以使用 LLM 节点完成。这个节点的目标不是生成完整回答而是从反馈中提取结构化信息。Prompt 可以这样设计你是一个用户反馈分析助手。 请从用户反馈中提取关键信息并严格按照 JSON 格式输出。 需要提取的字段 - summary一句话总结反馈内容 - product_module涉及的产品模块如果无法判断则输出 unknown - problem_description具体问题描述 - user_impact对用户造成的影响 - user_expectation用户希望得到的结果 用户反馈 {{feedback_text}}期望输出示例{ summary: 用户反馈报表导出经常失败影响月底汇总, product_module: 报表导出, problem_description: 导出报表时提示网络异常切换网络后仍无法解决, user_impact: 影响月底数据汇总工作, user_expectation: 希望尽快修复导出失败问题 }这里建议强制模型输出 JSON因为后续节点可以基于字段继续判断而不是从一段自然语言中再次解析。9. 第五步反馈分类节点分类节点同样可以使用 LLM 节点也可以结合规则判断。常见反馈类型包括• Bug 反馈。• 功能建议。• 使用咨询。• 体验投诉。• 账号或权限问题。• 其他。Prompt 示例请根据用户反馈内容判断反馈类型。 可选类型 - bug功能异常或错误 - feature_request希望增加或改进功能 - consultation使用咨询 - complaint负面体验或投诉 - account_permission账号、登录、权限相关问题 - other无法归类 请只输出 JSON { category: 类型编码, reason: 分类原因 } 用户反馈 {{feedback_text}} 已提取信息 {{extracted_info}}对于生产流程分类结果最好使用固定枚举值方便后续系统处理。不要让模型自由输出“这个问题看起来像是比较严重的导出异常”这种无法稳定解析的句子。10. 第六步优先级判断节点优先级判断可以由规则和模型共同完成。例如可以先定义一套优先级规则优先级判断标准P0大面积不可用、核心链路中断、数据安全问题P1重要功能不可用影响付费客户或关键业务P2局部功能异常有临时替代方案P3体验问题、轻微建议、低频问题可以让 LLM 根据规则输出建议优先级你是一个产品支持优先级判断助手。 请根据反馈内容、用户类型和影响范围判断优先级。 优先级规则 P0大面积不可用、核心链路中断、数据安全问题 P1重要功能不可用影响付费客户或关键业务 P2局部功能异常有临时替代方案 P3体验问题、轻微建议、低频问题 请只输出 JSON { priority: P0/P1/P2/P3, reason: 判断原因 } 用户类型{{user_type}} 反馈内容{{feedback_text}} 提取信息{{extracted_info}} 分类结果{{category_result}}如果 Dify Workflow 支持 IF/ELSE 分支可以在优先级之后加入条件判断如果 priority 为 P0 或 P1 进入高优先级处理路径。 否则 进入普通处理路径。这样可以把关键问题和普通问题分流。11. 第七步回复建议节点自动化流程不仅要分析问题还可以生成客服或运营人员可直接使用的回复建议。Prompt 可以这样写你是一个专业客服支持助手。 请根据用户反馈和分析结果生成一段回复建议。 要求 1. 语气礼貌、专业。 2. 不承诺无法确认的修复时间。 3. 如果是高优先级问题说明会尽快同步技术团队排查。 4. 如果信息不足引导用户补充必要信息。 5. 字数控制在 120 字以内。 用户反馈{{feedback_text}} 分类结果{{category_result}} 优先级{{priority_result}} 提取信息{{extracted_info}}示例输出您好已收到您关于报表导出失败的反馈。该问题可能影响月底数据汇总我们会尽快同步技术团队排查。为便于定位请补充导出时间、报表类型以及是否所有报表均失败。感谢您的反馈。这个节点的输出可以给客服人员参考而不是直接自动发送。生产环境中是否自动发送要看业务风险。12. 第八步统一输出结构Workflow 最终输出建议使用结构化格式方便被外部系统调用。例如{ summary: 用户反馈报表导出经常失败影响月底汇总, category: bug, priority: P1, product_module: 报表导出, user_impact: 影响月底数据汇总工作, suggested_owner: 技术支持/产品研发团队, reply_suggestion: 您好已收到您关于报表导出失败的反馈……, need_human_review: true }这里有一个关键字段need_human_review。对于高优先级问题、敏感问题或模型不确定的问题建议进入人工审核而不是完全自动处理。结构化输出的好处是• 后端系统容易解析。• 可以直接生成工单。• 可以用于数据统计。• 可以作为后续流程的输入。• 更容易做自动化测试。13. 第九步加入异常兜底可靠的 Workflow 不能只考虑正常路径还要考虑异常路径。常见异常包括• 用户输入为空。• 模型输出不是合法 JSON。• 分类结果不在枚举范围内。• 优先级判断缺失。• 外部工具或 API 调用失败。• 知识库检索无结果。可以设计兜底策略异常情况处理方式输入为空直接返回输入无效JSON 解析失败要求模型重试或进入人工处理分类未知标记为 other并进入人工审核高风险内容设置 need_human_review 为 true工具调用失败返回错误状态并记录日志自动化不是不需要人工而是把人工放在最需要判断的节点上。14. 第十步测试 WorkflowWorkflow 搭建完成后需要准备测试用例。建议覆盖以下输入14.1 正常 Bug 反馈导出报表一直失败提示网络异常影响月底汇总。期望结果category bug priority P1 或 P2 need_human_review true14.2 功能建议希望报表支持按部门批量导出现在只能一个个导出效率比较低。期望结果category feature_request priority P3 或 P214.3 使用咨询请问在哪里可以修改账号绑定的手机号期望结果category consultation 或 account_permission priority P314.4 无效输入你好期望结果返回输入信息不足提示补充具体反馈。14.5 敏感或高风险问题我们公司的所有客户数据都看不到了后台页面一直报错。期望结果priority P0 或 P1 need_human_review true测试时不要只看最终回答还要检查每个节点的中间输出。Workflow 的优势就在于可以定位到底是哪一步出了问题。15. 第十一步发布为 APIWorkflow 很适合作为后端 AI 流水线使用。当流程稳定后可以通过 API 方式被外部系统调用例如用户反馈表单 → 后端服务 → Dify Workflow API → 返回分析结果 → 创建工单或写入数据库API 集成时建议关注• 鉴权 Token 不要暴露在前端。• 请求参数要在业务后端先校验。• 记录请求 ID方便追踪日志。• 对失败响应做重试或降级处理。• 高优先级结果不要直接自动执行高风险动作。在生产环境中Dify Workflow 更适合作为 AI 能力编排层而不是替代全部业务系统。16. Workflow 设计原则结合上面的实战案例可以总结几条设计原则。16.1 一个节点只做一类事情不要把信息提取、分类、优先级判断和回复生成全部塞进一个 LLM 节点。节点职责越清晰越容易调试和复用。16.2 中间结果尽量结构化后续节点需要消费的内容尽量使用 JSON 或固定字段。自然语言适合给人看结构化数据适合给系统用。16.3 关键判断要有规则不要把所有判断都交给模型。优先级、权限、风险等级这类关键逻辑应该有明确规则模型只是在规则范围内辅助判断。16.4 高风险动作要人工确认涉及资金、权限、删除、通知客户、修改业务数据等操作时不建议让 AI 自动执行。应该设置人工审核节点或业务系统确认。16.5 先跑通小流程再扩展复杂度不要一开始就设计十几个节点。建议先跑通最小闭环再逐步增加分支、工具和异常处理。17. Workflow 适合哪些场景Dify Workflow 适合以下类型的任务• 文档摘要生成。• 用户反馈分析。• 工单自动分类。• 数据清洗与标签生成。• 简历筛选与候选人摘要。• 舆情分析与风险分级。• 定时报告生成。• 业务表单智能审核。• RAG 检索后的结构化回答生成。这些场景都有一个共同特点流程相对明确输入输出可以定义结果需要被系统或人继续处理。如果任务需要持续多轮交流更适合 Chatflow。如果任务需要模型自主探索和调用工具更适合 Agent。18. 总结Dify Workflow 的核心价值是把大模型从“单次问答能力”变成“可编排的流程节点”。通过 Workflow我们可以把复杂任务拆成多个清晰步骤并在每一步设计输入、输出、规则、分支和异常处理。对于企业级 AI 应用来说可控性往往比炫技更重要。一个好的 Workflow 不一定节点很多但一定要满足三个要求流程清晰 输出稳定 异常可控。当你需要把 AI 能力接入业务系统、自动化任务或后台流程时Workflow 往往是比普通聊天助手和 Agent 更稳妥的选择。这也是 Dify 从“快速搭应用”走向“工程化落地”的关键能力之一。
