这次我们来看 Dify 工作流中的三个核心控制节点分类、条件与介入。对于想要构建复杂、智能且可控的 AI 应用流程的开发者来说理解并熟练运用这三个节点是从“简单串联”迈向“逻辑编排”的关键一步。它们能让你的应用根据输入内容动态选择路径、在特定情况下触发人工审核从而实现更精细的业务流程控制。本文将聚焦于 Dify 工作流画布中的分类节点Classification、条件节点Condition和介入节点Human-in-the-loop。我们会直接切入主题讲解每个节点的功能定位、配置方法、适用场景并通过一个综合案例演示如何将它们组合起来构建一个能自动分流、条件判断并支持人工审核的智能客服工单处理流程。无论你是想实现内容自动分类路由还是为 AI 生成结果加上一道安全阀这篇文章都能提供清晰的实操指南。1. 核心能力速览在深入细节之前我们先通过一个表格快速了解这三个节点的核心特性与能力边界。节点名称核心功能输入要求输出/动作典型应用场景分类节点根据预定义类别对输入文本进行多选一的路由。一段需要被分类的文本如用户问题、文章内容。将流程导向对应的下一个节点分支。客服问题分流、工单类型识别、内容主题分类、意图识别。条件节点基于逻辑表达式IF-ELSE判断决定流程走向。布尔值True/False或可评估为布尔值的表达式。根据条件真假选择“是”或“否”分支执行。权限检查、内容过滤、阈值判断、流程开关。介入节点在流程中插入人工审核或操作环节。需要人工处理的信息如文本、选项。暂停自动化流程等待人工审批或输入后继续。敏感内容审核、关键决策确认、结果修正、复杂任务分派。关键理解分类 vs 条件分类是“多选一”基于模型或规则将输入映射到有限的几个类别条件是“二选一”基于一个明确的逻辑判断。分类节点内部通常也依赖一个分类模型或规则集。介入的价值它确保了 AI 应用在完全自动化与完全人工之间取得平衡在风险可控的前提下提升效率是构建可靠生产级应用的重要组件。2. 适用场景与使用边界在开始配置之前明确什么情况下该用哪个节点能避免设计出臃肿或脆弱的工作流。2.1 分类节点的适用场景分类节点最适合处理非此即彼或明确归入某类的场景。它的目标是做路由而不是生成内容。客服机器人首问分流用户输入“我要退款”、“产品怎么用”、“投诉客服态度”系统能自动识别为“售后”、“使用指导”、“投诉”等类别并路由给不同的知识库或处理流程。内容审核前置分类将用户生成的文本、图片描述自动分类为“正常”、“广告”、“涉政”、“辱骂”等不同类别的后续处理策略不同如直接通过、进入审核池、直接拒绝。工单系统自动派单根据用户提交的工单描述自动识别为“技术故障”、“财务问题”、“功能建议”等并分配给相应的部门队列。使用边界分类的类别需要预先定义好且相对稳定。对于模糊的、类别众多如成千上万种商品或需要连续值输出的情况分类节点可能不适用可能需要结合嵌入模型和向量检索。2.2 条件节点的适用场景条件节点是工作流中的“逻辑开关”用于执行业务规则判断。权限与配额检查判断用户剩余调用次数是否大于0或用户角色是否为“管理员”。内容安全过滤检查AI生成的文本中是否包含某些敏感关键词或情感极性是否为极端负面。流程控制根据时间是否工作日、输入内容长度是否超过阈值或上游节点的输出状态是否成功来决定下一步走向。A/B测试分流随机数大于0.5走A模型分支否则走B模型分支。使用边界条件判断需要是明确的、可量化的。过于复杂、依赖多个变量且关系模糊的逻辑可能会使条件表达式难以维护此时考虑拆解或多个条件节点组合或在上游节点中处理复杂逻辑。2.3 介入节点的适用场景介入节点是连接自动化与人工的桥梁核心价值在于风险控制和关键质量控制。敏感信息发布前审核AI生成的新闻稿、营销文案在发布前需经人工确认。高风险操作确认如执行删除数据、发送重要通知、进行支付等操作前的二次确认。AI不确定时的提权当AI对自身生成的答案置信度较低时自动转交人工处理。复杂问题升级自动客服无法解决的问题自动创建工单并指派给人工客服。使用边界介入会中断流程的自动化引入延迟和人力成本。应仅用于真正必要的关键环节避免滥用导致流程效率下降。需要明确设置超时和处理人指派规则。3. 环境准备与前置条件要实践本文内容你需要一个可用的 Dify 环境。以下是两种主要方式的准备清单3.1 云服务版零部署这是最快上手的方式适合学习和原型验证。访问官网访问 Dify 官方网站。注册账号使用邮箱或第三方服务如 GitHub注册一个新账号。创建应用登录后在控制台点击“创建新应用”选择“工作流”类型。环境就绪完成上述步骤后你就拥有了一个完整的、带图形化工作流编辑器的环境无需关心服务器、依赖或模型部署。3.2 本地/私有化部署版适合对数据隐私、定制化有更高要求或需要集成内部系统的团队。硬件与系统操作系统Linux (Ubuntu 20.04/22.04 推荐), macOS, 或 Windows (WSL2 推荐)。CPU/RAM建议 4 核 CPU8 GB 以上内存。磁盘空间至少 10 GB 可用空间用于存放 Docker 镜像和数据库。软件依赖Docker Docker Compose这是官方推荐的部署方式。确保已安装最新稳定版。Git用于克隆代码仓库。网络与端口确保主机的80、443如果配置SSL、3000默认前端端口、5001默认后端端口等端口未被占用或准备在部署时修改。可选模型服务如果你计划使用本地模型如用于分类的开源模型需要额外准备相应的模型推理环境如 Ollama、OpenAI-compatible API 等并在 Dify 中配置为模型供应商。4. 安装部署与启动方式本节以最通用的Docker Compose 部署为例展示如何快速搭建本地 Dify 环境。4.1 一键部署Docker Compose这是官方主推的部署方式能一次性启动所有必需服务前端、后端、数据库等。# 1. 克隆仓库使用国内镜像或官方仓库 git clone https://github.com/langgenius/dify.git cd dify # 2. 复制环境变量配置文件 cp .env.example .env # 你可以编辑 .env 文件修改数据库密码、密钥、端口等配置。 # 3. 启动所有服务 docker-compose up -d执行以上命令后Docker 会自动拉取镜像并启动容器。你可以通过以下命令查看日志和状态# 查看启动日志 docker-compose logs -f # 查看容器状态 docker-compose ps4.2 访问与初始化访问 Web UI在浏览器中打开http://你的服务器IP:3000。如果在本机部署通常是http://localhost:3000。初始化管理员首次访问会进入初始化页面设置管理员账号和密码。配置模型供应商进入后台后点击“模型供应商”添加你计划使用的 AI 模型服务。例如OpenAI填入你的 API Key 和 Base URL。本地模型如果你部署了 Ollama可以添加类型为“OpenAI-compatible”的供应商地址为http://host.docker.internal:11434注意在 Docker 容器内访问宿主机服务需特殊配置或使用宿主机真实IP。创建工作流应用初始化完成后即可进入“应用”页面开始创建本文重点探讨的工作流。5. 功能测试与效果验证构建智能客服工单流程我们将通过一个完整的案例——“智能客服工单自动分类与处理流程”来串联演示分类、条件和介入节点的使用。场景描述用户提交一段工单描述系统需要1) 自动分类2) 根据类别和内容风险决定处理路径3) 高风险工单需人工审核。5.1 步骤一创建工作流并设置输入在 Disy 应用页面点击“创建新应用”选择“工作流”命名为“智能客服工单处理器”。从左侧节点库拖入一个“开始”节点。配置“开始”节点添加一个名为user_query的字符串类型变量作为用户输入的工单描述。5.2 步骤二配置分类节点拖入一个“分类”节点并将其连接到“开始”节点之后。配置分类节点分类变量选择上一步定义的{{user_query}}。分类选项这里我们定义三个工单类型。点击“添加选项”依次输入选项1售后问题值可设为after_sales选项2技术咨询值可设为tech_support选项3投诉建议值可设为complaint分类模型选择你已配置好的一个文本分类模型。例如可以使用 OpenAI 的gpt-3.5-turbo并在“提示词”区域编写清晰的分类指令。请将用户的工单描述严格分类到以下类别之一 - 售后问题涉及退款、退货、换货、订单查询、物流跟踪等问题。 - 技术咨询涉及产品如何使用、功能故障、报错信息、安装配置等问题。 - 投诉建议涉及对服务、产品、人员的不满投诉或功能改进建议。 用户描述{{user_query}} 只输出类别名称不要输出任何其他解释。测试分类功能点击工作流画布上方的“运行此工作流”在右侧调试面板的user_query中输入测试文本如“我的订单还没收到已经一周了请帮我查一下物流”。点击运行观察分类节点的输出是否正确地指向了“售后问题”分支。5.3 步骤三配置条件节点进行风险过滤假设我们规定所有“投诉建议”类工单以及描述中包含“紧急”、“立刻”、“马上”等关键词的工单都需要进行风险标记。在“分类节点”的每个输出分支后分别连接一个“条件”节点。这里以“投诉建议”分支为例。配置条件节点条件表达式我们需要设置一个复合条件。点击“添加条件”。条件1category “complaint”分类本身就是投诉建议条件2contains(user_query, “紧急”) or contains(user_query, “立刻”) or contains(user_query, “马上”)描述包含紧急词汇设置逻辑关系为“或”即满足任一条件即视为高风险。分支配置条件节点会自动生成“是”和“否”两个分支。“是”分支代表高风险将流向“介入节点”“否”分支代表低风险可以流向自动处理节点如知识库问答或模板回复。5.4 步骤四配置介入节点等待人工处理对于高风险工单我们引入人工审核环节。从“条件节点”的“是”分支连接一个“介入”节点。配置介入节点指派给可以选择“工作空间成员”或“特定成员”。学习时可以选择自己。介入内容这里需要组织好呈现给审核人的信息。可以使用变量插值。工单待审核 - 用户描述{{user_query}} - 自动分类{{category}} - 风险标记原因{{#if category “complaint”}}属于投诉类工单{{/if}} {{#if contains(user_query, “紧急”)}}包含紧急词汇{{/if}} - 建议操作[请审核人员选择] 1. 转交高级客服处理 2. 直接回复安抚模板 3. 标记为无效工单超时设置建议设置一个超时时间如1小时超时后可按预设规则自动处理如转交他人或按默认路径继续。配置人工操作后的分支介入节点通常有多个输出分支对应人工选择的不同操作。你需要根据“建议操作”的内容为介入节点配置相应的输出分支例如“转交处理”、“安抚回复”、“关闭工单”并连接后续的处理节点。5.5 步骤五配置自动回复节点低风险路径对于低风险工单条件节点的“否”分支我们可以连接一个“LLM”节点或“知识库检索”节点来自动生成回复。连接一个“LLM”节点到条件节点的“否”分支。配置该节点使用合适的模型和提示词基于user_query和category生成专业、友好的回复。最后可以将“LLM回复节点”和“人工处理分支”都连接到一个“结束”节点以整合最终输出。5.6 完整流程测试保存工作流。在调试面板进行多轮测试测试用例1“电脑蓝屏了错误代码0x000001怎么办”预期分类为“技术咨询”不含紧急词走低风险路径触发LLM自动生成技术建议回复。测试用例2“我要投诉你们客服态度极差立刻给我回电”预期分类为“投诉建议”且包含“立刻”触发高风险条件流程暂停在“介入”节点等待人工审核。测试用例3“请问这个商品有保修吗”预期分类为“售后问题”不含紧急词走低风险路径触发LLM或知识库检索自动回复。通过观察每个节点的执行状态和变量的变化你可以验证整个工作流的逻辑是否符合设计预期。6. 接口 API 与批量任务构建好的工作流不仅可以在 Dify 的 Web 界面中调试更重要的是可以通过 API 集成到你的业务系统中并处理批量任务。6.1 通过 API 调用工作流启用 API在 Dify 应用概览页面找到“访问 API”区域点击“启用”并复制你的 API Key。获取接口地址在“访问 API”区域你也能看到该应用的Endpoint URL。调用示例import requests import json # 配置参数 api_key “你的-API-KEY” endpoint “你的-应用-Endpoint-URL” url f“{endpoint}/workflows/run” # 请求头 headers { “Authorization”: f“Bearer {api_key}”, “Content-Type”: “application/json” } # 请求体对应工作流的输入变量 payload { “inputs”: { “user_query”: “我的订单物流状态一直不更新请紧急处理” # 对应我们定义的变量 }, “response_mode”: “blocking”, # 同步等待结果 “user”: “user_123” # 可选标识终端用户 } # 发送请求 response requests.post(url, headersheaders, jsonpayload, timeout120) result response.json() # 处理响应 if response.status_code 200: print(“工作流执行成功”) # 最终输出通常在 result[‘data’][‘outputs’] 中 print(json.dumps(result, indent2, ensure_asciiFalse)) else: print(f“请求失败: {response.status_code}”) print(response.text)当工作流中包含“介入”节点时在“blocking”模式下API 调用会一直等待直到人工操作完成或超时。对于长时间任务可以考虑使用“streaming”模式或通过回调来获取结果。6.2 批量任务处理Dify 工作流本身主要设计用于实时请求。对于批量文件处理通常有两种模式外部批量调用在你的业务代码中读取批量数据如 CSV 文件循环调用上述 API并处理每个请求的响应。需要做好错误重试和速率限制。import pandas as pd df pd.read_csv(‘tickets_batch.csv’) for index, row in df.iterrows(): user_query row[‘description’] payload[‘inputs’][‘user_query’] user_query # ... 调用 API # 保存结果工作流内循环高级通过结合“代码”节点和变量迭代可以在一个工作流执行实例内处理一组数据。但这更复杂需要编写 Python 代码来管理循环逻辑适用于数据关联性强的批量处理。7. 资源占用与性能观察Dify 工作流的性能主要取决于其背后连接的模型服务如 OpenAI API、本地大模型以及工作流本身的复杂度。无状态服务Dify 后端主要负责流程编排和状态管理本身资源消耗不高。资源压力主要在模型推理侧。分类节点性能如果使用云端 API如 OpenAI延迟和成本与 API 调用相关。如果使用本地小模型如通过 Ollama 运行的nomic-embed-text或llama3做零样本分类则消耗本地 GPU/CPU 资源。一个轻量级文本分类任务在 CPU 上也可能在秒级完成。条件节点性能纯逻辑判断性能开销可忽略不计。介入节点性能此节点本身不消耗计算资源但会引入不确定的人工等待时间是流程中的“时间瓶颈”。观察方法Dify 日志在应用运行日志中可以查看每个节点的开始、结束时间和状态。模型服务监控如果你使用本地模型需通过nvidia-smiGPU或系统监控工具观察模型推理时的资源占用。API 响应时间通过调用 API 并记录响应时间来评估端到端的流程性能。优化建议分类模型选择对于简单、固定的分类规则可以尝试用“代码”节点结合关键词匹配或正则表达式来实现成本更低、速度更快。条件表达式优化避免在条件表达式中进行复杂的字符串处理或调用外部函数尽量使用上游节点处理好的变量进行简单比较。介入超时策略为介入节点设置合理的超时时间并规划超时后的自动降级处理路径避免流程无限期挂起。8. 常见问题与排查方法问题现象可能原因排查方式解决方案分类节点总是输出同一类别或错误类别1. 提示词指令不清晰。2. 使用的模型不擅长分类任务。3. 分类选项定义有歧义或重叠。1. 检查分类节点的提示词确保指令明确要求“只输出类别名称”。2. 在调试面板用多种样例测试。3. 查看模型返回的原始内容如果支持。1. 优化提示词提供更清晰的类别定义和例子。2. 更换或微调更擅长分类的模型。3. 调整分类选项使其互斥且覆盖全面。条件节点判断不符合预期1. 条件表达式语法错误。2. 引用的变量名错误或变量值为空。3. 变量类型不匹配如字符串与数字比较。1. 检查条件表达式确认使用了正确的变量和操作符,!,,,contains等。2. 在调试面板运行查看传入条件节点的上游变量值是否正确。1. 修正表达式语法。2. 确保上游节点正确输出了所需变量。3. 使用toNumber(),toString()等函数进行类型转换。介入节点无人处理流程卡住1. 未正确指派处理人。2. 处理人未收到通知或未操作。3. 未设置超时或超时后无自动处理路径。1. 检查介入节点的“指派给”配置。2. 查看 Dify 的通知设置如邮件、Slack 集成是否生效。3. 检查介入节点的超时设置和超时后分支。1. 确认指派成员有效。2. 配置并测试通知渠道。3. 务必设置超时并连接超时后的自动处理节点。通过 API 调用工作流失败1. API Key 错误或未启用。2. Endpoint URL 错误。3. 请求体格式错误或输入变量名不匹配。4. 模型服务不可用或超时。1. 检查应用设置中的 API 配置。2. 使用curl或 Postman 测试基础连接。3. 对比 API 文档检查inputs结构。4. 查看 Dify 后端日志和模型服务状态。1. 重新生成并复制正确的 API Key。2. 确认完整的 Endpoint URL。3. 确保inputs中的键名与工作流“开始”节点定义的变量名完全一致。4. 检查模型供应商配置和网络连通性。工作流运行速度慢1. 使用的云端模型 API 延迟高。2. 本地模型推理资源不足。3. 工作流中存在串行的长耗时节点。1. 测试单个模型 API 的响应时间。2. 监控服务器资源使用情况CPU/GPU/内存。3. 分析工作流日志找出耗时最长的节点。1. 考虑更换响应更快的模型或供应商。2. 升级服务器配置或优化本地模型参数如降低max_tokens。3. 审查流程设计看能否将不依赖的节点并行化需 Dify 支持。9. 最佳实践与使用建议始于简单迭代复杂不要试图一次性设计出完美的工作流。先构建一个最小可行流程MVP只包含核心的分类、处理和输出。运行测试无误后再逐步加入条件判断、人工介入、错误处理等分支。变量命名清晰使用snake_case或camelCase为变量命名如user_input_text、classified_category、risk_level避免使用a,b,temp等无意义名称便于在条件表达式和后续节点中引用。善用“知识库”节点替代复杂分类对于类别极多、边界模糊的分类需求如将用户问题对应到海量产品手册的某个章节使用“知识库检索”节点可能比“分类”节点更有效、更灵活。为“介入”设计明确的SOP人工介入环节必须有清晰的标准操作流程。在介入节点的描述中明确告诉审核人需要检查什么、有哪些可选项、每个选项意味着什么后续操作。这能减少误操作提高处理效率。全面的错误处理在工作流的关键节点尤其是调用外部 API、模型服务后添加“条件”节点检查执行状态。如果失败可以路由到重试逻辑、降级处理如使用备用模型或错误报告节点。版本管理与测试Dify 支持发布新版本。在修改生产环境使用的工作流前先创建一个新版本进行充分测试。利用调试面板的“历史运行”功能回放和对比不同版本的执行结果。合规与安全当工作流处理用户数据时确保符合数据隐私法规。如果涉及内容生成通过“条件”节点和“介入”节点设置必要的安全过滤和人工审核避免产生有害或不合规内容。10. 总结与下一步通过本文的拆解你应该已经掌握了 Dify 工作流中分类、条件、介入这三个核心控制节点的精髓。它们不仅仅是三个孤立的工具更是构建具备决策能力和人机协作能力的智能应用的基础模块。最值得尝试的起点从一个具体的、简单的业务场景开始比如“用户反馈情绪判断正面/负面/中性与路由”。用分类节点判断情绪用条件节点将负面反馈路由到介入节点等待人工处理正面和中性反馈则自动回复感谢。这个流程能让你快速体验从自动化到人机协同的完整闭环。最容易踩的坑一是变量传递务必确认上游节点的输出变量名能被下游节点正确引用二是条件逻辑复杂的and/or组合容易出错建议先用简单的条件测试再逐步组合三是介入超时忘记设置超时会导致流程永远挂起。下一步的探索方向结合“代码”节点当内置节点无法满足复杂的数据处理或业务逻辑时可以插入“代码”节点支持 Python实现更灵活的操作如调用内部 API、进行复杂计算、处理结构化数据等。实现动态循环探索如何使用变量和代码节点让工作流能够处理一个列表中的数据实现批量作业的流程化。集成外部工具利用 Dify 的“工具”功能将工作流与数据库、CRM、邮件系统、第三方 API 等连接起来让 AI 流程真正融入你的业务系统。掌握这些节点的组合使用你将能设计出适应复杂业务逻辑、稳健且高效的 AI 智能体流程大幅提升应用的实用价值和可靠性。建议将本文作为手边参考在搭建实际工作流时反复查阅实践。