Dify 1.15 人工介入功能实战：构建可控AI工作流，实现人机协同

如果你正在用 Dify 构建一个智能客服或内容生成应用是否遇到过这样的场景AI 助手给出的回答看似正确但细节上总有那么一点“不对劲”比如它可能把产品价格报错或者引用了一个过时的政策条款。你明知道正确答案却只能眼睁睁看着错误的回答被发送给用户然后手忙脚乱地去后台修改知识库祈祷下次别再出错。这不是知识库的问题也不是模型不够聪明。问题的核心在于传统的 AI 应用流程是“设定即输出”一旦工作流跑起来就像一列没有刹车的火车你无法在关键时刻伸手干预确保结果万无一失。对于金融、法律、医疗或任何对准确性有苛刻要求的场景这种“黑盒”式的自动化是致命的。Dify 1.15 版本推出的“人工介入Human-in-the-Loop”功能正是为了解决这个痛点。它不是一个简单的“审核”按钮而是一套将人类判断无缝嵌入 AI 自动化流程的工程机制。本文将带你深入实操拆解 Dify 1.15 中人工介入的核心原理、三种典型使用模式并通过一个从零搭建的“智能报价审批”工作流展示如何在实际业务中落地这一关键能力。读完本文你将能清晰地回答我的业务场景是否需要人工介入应该选择“审批”、“修订”还是“自定义”模式以及如何设计一个既安全又高效的人机协作流程。1. 人工介入从“全自动”到“受控智能”的关键一跃在深入配置之前我们必须先理解“人工介入”在 Dify 乃至整个 AI 应用工程化中的定位。它远不止是一个功能开关。1.1 它解决了什么问题传统 AI 应用开发面临一个两难困境追求全自动化就要承担输出不可控的风险追求绝对准确又不得不退回纯人工操作失去了 AI 的效率优势。人工介入的核心价值是在“效率”和“准确性”之间建立一个可调节的平衡点。它允许你在关键决策节点如最终答复、数据写入、外部调用前按下暂停键引入人类的判断力。1.2 为什么是 Dify 1.15在 Dify 早期版本中要实现类似效果开发者可能需要借助复杂的 API 回调、自定义代码节点或外挂审批系统流程割裂维护成本高。Dify 1.15 将人工介入作为一等公民内置到可视化工作流引擎中这意味着配置化无需编码通过拖拽和配置即可实现。流程内嵌介入点成为工作流的一个标准节点状态管理、变量传递全部由平台接管。体验统一为介入者如运营、审核员提供了友好的 Web 界面来处理待办任务。1.3 适合谁对内容准确性要求高的场景法律文书生成、医疗报告摘要、新闻稿发布。涉及关键业务操作的场景订单创建、价格审批、客户数据更新。需要合规性审查的场景金融产品推荐、广告内容审核。作为 AI 输出的“安全护栏”在将 AI 生成的内容发送给最终用户或写入数据库前进行最终确认。接下来我们将从概念到实操一步步构建一个带有人工介入的完整工作流。2. 核心概念与三种介入模式详解在 Dify 工作流中人工介入通过一个独立的“人工介入”节点来实现。该节点有三种运行模式对应不同的人机协作深度。2.1 模式一审批模式这是最简单直接的模式。工作流运行到此节点时暂停向指定的处理人或用户组发送一个审批请求。处理人只能选择“通过”或“拒绝”无法修改内容。类比公司OA系统中的请假审批。适用场景AI生成的结论性内容发布前终审、是否执行某项高风险操作如发送邮件、调用付费API。输出变量status(approved/rejected),approved_by,approved_at等。2.2 模式二修订模式在此模式下处理人不仅可以审批还可以直接修改 AI 生成的中间内容。类比Word文档的审阅模式上级可以直接修改下属起草的文案。适用场景文案优化、报告润色、代码片段修正。AI负责起草人类负责优化和定稿。输出变量除了审批信息最重要的是modified_content即处理人修订后的内容这个变量会流入工作流后续节点。2.3 模式三自定义模式这是最灵活的模式。你可以自定义一个表单让处理人填写多个字段。这相当于为人工处理环节创建了一个微型的“数据录入工单”。类比JIRA或飞书的多维表格针对一个任务需要填写多项信息。适用场景复杂决策。例如AI分析客户需求后生成一个初步方案但需要销售经理确认最终折扣、合同类型和备注信息。输出变量你自定义的每个表单字段都会成为一个输出变量。理解这三种模式的区别是正确设计工作流的基础。选择哪种模式取决于你的业务是需要一个“开关”一个“编辑器”还是一个“数据收集器”。3. 环境准备与项目初始化在开始构建工作流前请确保你的 Dify 环境已就绪。3.1 环境要求Dify 版本必须为 1.15 或更高版本。你可以在 Dify 后台的“系统设置” - “关于”中查看版本号。部署方式无论是 Docker 部署、宝塔面板部署还是源码部署只要版本达标即可。网络热词中提到的“dify本地部署”、“docker安装dify”等问题在部署阶段已解决。模型配置确保已正确配置至少一个 LLM 模型提供者如 OpenAI GPT, Anthropic Claude或国内的通义千问、DeepSeek等。这是工作流中“LLM”节点运行的前提。浏览器建议使用 Chrome 或 Edge 最新版以获得最佳的可视化工作流编辑体验。3.2 创建新应用登录 Dify 控制台。点击“创建新应用”选择“工作流”类型。为应用命名例如“智能报价审批助手”。点击进入应用你会看到空白的画布这就是我们的工作流编辑器。准备工作完成接下来进入核心环节。4. 实战构建“智能报价审批”工作流我们将模拟一个电商客服场景用户询问商品价格AI 根据知识库生成报价但在最终回复用户前需要销售主管对特定高价值商品或特殊折扣进行人工审批。4.1 工作流整体设计我们的工作流将包含以下节点并按此顺序连接开始节点接收用户问题。知识库检索节点从商品知识库中查找信息。LLM 节点根据检索结果组织生成初步报价回复。条件判断节点判断此报价是否需要人工审批例如总价超过10000元或商品为特定品类。人工介入节点审批模式如果需要审批则在此暂停等待主管处理。后续处理节点根据审批结果要么发送 AI 报价要么发送审批后的定制回复。4.2 分步配置与代码示例步骤1设置开始节点与变量开始节点定义了工作流的输入。我们假设输入是用户的问题user_query。 在画布上点击开始节点在右侧面板的“变量”部分添加一个字符串变量变量名: user_query 变量类型: String 描述: 用户输入的问题这样后续节点都可以引用{{user_query}}这个变量。步骤2配置知识库检索节点从左侧节点库拖拽“知识库检索”节点到画布并将其连接到开始节点。在右侧面板选择你已创建好的商品知识库例如包含商品名称、价格、规格、折扣政策等。在“查询变量”中填入{{user_query}}。设置“召回数量”和“相似度阈值”根据你的知识库质量调整。例如召回数量: 3 相似度阈值: 0.7此节点会输出一个变量如knowledge_retrieval_result包含了检索到的文本片段。步骤3配置 LLM 节点生成初步回复拖拽“LLM”节点连接到知识库检索节点。在“上下文”中引入{{knowledge_retrieval_result}}作为系统或用户上下文的一部分。编写提示词Prompt。这是核心示例你是一名专业的电商客服助手。请根据以下商品信息回答用户关于价格和购买的问题。 【商品信息】 {{knowledge_retrieval_result}} 【用户问题】 {{user_query}} 请生成一段友好、专业的回复明确告知用户商品价格、是否有库存、以及当前可用的优惠。如果信息不足请引导用户提供更具体的商品名称。选择你配置好的模型如gpt-4o-mini。此节点的输出变量我们命名为ai_raw_response。至此一个标准的 AI 问答流程已经完成。但它是“黑盒”的接下来我们引入控制逻辑。步骤4配置条件判断节点我们需要一个规则来决定何时触发人工审批。这里使用“条件判断”节点。拖拽“条件判断”节点连接到 LLM 节点。我们将设计一个简单的规则如果 AI 回复中提取出的价格数字大于 10000则需审批。这需要一点技巧因为ai_raw_response是文本。我们可以利用 LLM 节点先做一个“信息提取”。在 LLM 节点和条件判断节点之间插入一个新的 LLM 节点命名为“提取金额”。给这个节点的提示词是请从以下客服回复中提取出提到的所有金额数字人民币元。如果没有提到具体金额则输出0。只输出数字不要任何其他文字。 回复内容 {{ai_raw_response}}将此节点的输出变量命名为extracted_price类型应为Number在高级设置中指定。现在配置条件判断节点。添加一个条件分支条件名称: 需要高价审批 条件规则: extracted_price 10000根据条件配置两条输出边一条为“真”需要审批连接至人工介入节点一条为“假”无需审批可以直接连接至最终回复节点。步骤5核心配置 - 人工介入节点审批模式从节点库拖拽“人工介入”节点到“需要高价审批”的分支上。模式选择在右侧面板选择“审批”。配置处理人这是关键。你有多种方式指定谁来处理指定用户输入在 Dify 系统中注册的用户邮箱。变量指定更动态的方式。例如你可以创建一个“销售主管邮箱”变量从数据库或上游节点传入。这里我们演示静态配置adminyourcompany.com。用户组如果你在 Dify 中创建了用户组如“sales_managers”可以直接指定组名。配置指令与内容指令填写给处理人的说明如“请审核以下针对高价值商品的报价回复确认价格和优惠信息准确无误。”内容这里填写需要审批的具体内容。我们将 AI 生成的原始回复和提取的价格都放进去方便审批人决策。可以使用多行文本原始AI回复 {{ai_raw_response}} 提取到的金额{{extracted_price}} 元超时设置建议设置一个超时时间如2小时如果审批人未处理工作流可以按超时策略继续或终止执行避免流程卡死。输出变量映射审批完成后该节点会输出一系列变量。最重要的是status。我们需要在后续节点中根据status是approved还是rejected来决定如何回复用户。步骤6配置审批后的流程分支人工介入节点之后工作流应根据审批结果走不同的分支。拖拽一个“条件判断”节点连接到人工介入节点。设置条件人工介入节点输出.status ‘approved’。“真”分支已批准可以直接使用最初的ai_raw_response回复用户。“假”分支被拒绝或超时我们需要一个备选方案。可以连接一个新的“LLM”节点提示词为“销售主管拒绝了自动报价方案。请生成一段委婉的回复告知用户需要专人联系并请用户留下联系方式。” 也可以直接用一个“文本”节点输出固定话术。步骤7配置最终回复节点无论走哪个分支最后都应汇聚到一个“回答”节点在 Dify 工作流中可能是“文本”节点或专门用于对话的“回复”节点。拖拽“文本”节点将“无需审批”分支和“审批通过”分支连接到此节点。在“文本”内容中使用变量选择器来引用不同分支产生的回复内容。这需要你为每个分支的回复设置好输出变量。同样将“审批拒绝”分支连接到一个不同的“文本”节点输出替代回复。至此一个完整的、带有人工审批环节的智能报价工作流就设计完成了。点击画布右上角的“保存”然后可以进入测试环节。5. 运行测试与效果验证5.1 在工作室中测试在应用页面的右上角点击“发布”按钮下的“测试”选项。在测试聊天窗中输入一个会触发高价审批的查询例如“请问你们顶配的游戏笔记本多少钱”工作流会开始运行。当执行到人工介入节点时你会看到流程状态显示“等待中”。切换视角此时你需要以审批人我们之前设置的adminyourcompany.com的身份登录 Dify 系统或打开新的无痕窗口登录。审批人会在 Dify 首页或“待办”列表中看到一个待处理任务。点击进入可以看到我们配置的指令和待审内容。审批人点击“批准”或“拒绝”。选择“批准”并确认。切换回测试窗口稍等片刻你会发现之前暂停的工作流自动继续并输出了最终的回复结果。5.2 验证关键点流程暂停与恢复确认在审批人操作前测试窗口的请求一直处于“思考中”或“等待”状态。变量传递确认最终回复的内容确实是最初 AI 生成的内容证明ai_raw_response这个变量在人工介入节点前后得到了保持。分支逻辑分别测试“价格低于10000”和“价格高于10000且被拒绝”的情况验证不同分支的输出是否符合预期。通过这个测试你就能直观地感受到人工介入如何像一个“安全阀”一样嵌入到自动化的 AI 流程中。6. 深入修订模式与自定义模式的应用场景审批模式适合“是非决策”但很多场景需要人提供更多输入。让我们快速看下另外两种模式如何配置。6.1 修订模式实战片段假设在内容创作场景AI 生成初稿编辑需要润色。在人工介入节点选择“修订”模式。“内容”字段填入{{ai_draft}}。处理人打开任务后会看到一个可编辑的文本框里面是 AI 生成的初稿。他可以直接修改文本。工作流继续后后续节点引用的不再是ai_draft而是人工介入节点输出的modified_content。配置示例节点输出变量映射# 在人工介入修订节点的后续节点中这样引用被修改后的内容 最终稿件: {{人工介入节点输出.modified_content}}6.2 自定义模式实战片段假设在客户服务中AI 初步判断客户问题为“投诉”需要客服主管填写处理优先级和指定负责人。在人工介入节点选择“自定义”模式。点击“添加表单字段”设计表单字段1priority类型“单选”选项“高/中/低”。字段2assignee类型“文本”描述“指定处理客服”。字段3notes类型“长文本”描述“补充说明”。处理人填写表单并提交。后续节点可以引用{{人工介入节点输出.priority}}、{{人工介入节点输出.assignee}}等变量用于生成工单、发送通知等。7. 常见问题与排查思路在部署和使用人工介入功能时你可能会遇到以下问题问题现象可能原因排查方式解决方案工作流在人工介入节点卡住一直“等待中”。1. 指定的处理人邮箱在 Dify 系统中不存在或未激活。2. 处理人没有登录 Dify 系统查看待办。3. 网络问题导致通知未发出。1. 检查“人工介入”节点配置的处理人信息是否正确。2. 以处理人身份登录查看“待办”列表。3. 查看 Dify 服务日志确认任务创建和通知是否成功。1. 确保处理人是 Dify 的有效用户。2. 提醒处理人及时处理待办。3. 检查消息通知如邮件、钉钉/飞书集成配置。处理人操作后工作流没有自动继续。1. 工作流引擎的异步任务处理出现延迟或错误。2. 节点之间的连接线在视觉上连接但逻辑上未正确关联变量。1. 刷新测试页面或查看工作流的“运行历史”详情观察节点状态。2. 检查人工介入节点之后的“条件判断”节点其条件表达式是否正确引用了status变量如{{node_id.status}} ‘approved’。1. 稍作等待或重新触发一次测试。2. 在条件判断节点的表达式中使用变量选择器重新选择status变量确保引用路径正确。审批人看不到待处理任务。1. 用户权限问题该用户不属于应用的可访问者。2. 任务被其他人处理或已超时关闭。1. 在 Dify 的“团队管理”中确认该用户是否有此应用的访问权限。2. 检查人工介入节点的“超时”设置是否因超时而自动流转。1. 在应用编辑页面的“发布”-“权限”设置中添加该用户或所在用户组。2. 适当延长超时时间或检查超时后的默认行为是否符合预期。修订模式下modified_content变量为空。处理人可能直接点击了“通过”或“拒绝”而没有修改内容。查看该次运行的历史记录确认处理人的操作类型和输入内容。在给处理人的“指令”中明确要求“请直接在上方文本框中修改后提交”。或者将模式改为“审批”如果需要修改内容则设计更复杂的自定义表单。部署后外部用户无法触发人工介入。通过API调用的工作流其“人工介入”任务的通知和处理界面需要对“外部用户”开放这涉及更复杂的身份验证和会话管理。确认你的应用是“对话型应用”还是通过API调用的“工作流”。后者需要额外的机制如回调URL、WebSocket将待办任务集成到你自己的业务系统中。对于API调用场景Dify 的人工介入节点会返回一个task_id。你需要自行开发一个处理页面并调用 Dify 的 API 来查询任务状态和提交处理结果。这是企业级集成的关键点。8. 最佳实践与工程化建议将人工介入用于生产环境需要考虑更多工程细节8.1 权限与安全最小权限原则只将审批权限授予必要的人员。在 Dify 中利用好“团队”和“角色”功能。操作审计重要的人工介入操作谁、何时、批准/拒绝、修改内容应留有日志。Dify 的工作流运行历史是一个起点但对于合规要求高的场景可能需要将日志同步到你的中央日志系统。8.2 流程设计设置超时与兜底策略永远要设置合理的超时时间如4小时、24小时并配置超时后的默认行为例如“自动批准”或“转交他人”防止流程阻塞。明确审批标准在“指令”中尽可能清晰地写明审批需要关注的重点如“检查价格是否低于成本价”、“确认法律条款引用无误”减少审批人的主观判断负担。分支流程简洁人工介入后工作流分支不宜过于复杂。尽量让“批准”和“拒绝”后的逻辑清晰明了。8.3 性能与用户体验异步处理人工介入是耗时操作确保你的工作流整体是异步的不会阻塞主请求线程。通知集成将 Dify 的待办任务通过 Webhook 集成到团队常用的通讯工具如钉钉、飞书、企业微信提高处理及时性。移动端适配考虑审批人可能在移动端操作确保你的处理界面简洁易用。8.4 与现有系统集成对于成熟的企业往往不希望审批人频繁切换系统。这时你可以使用 Dify 的 API在人工介入节点触发时在你自己的业务系统如 CRM、OA中创建一条审批工单。在你自己的系统中完成审批流程。审批完成后通过 Dify API 回调告知 Dify 工作流审批结果和必要的数据。Dify 工作流根据回调数据继续执行。 这种方式实现了“能力在 Dify界面在业务系统”的深度集成。Dify 1.15 的人工介入功能标志着低代码 AI 应用开发从“玩具”走向“工具”的关键一步。它承认了当前 AI 技术的不完美并通过优雅的工程化设计将人类的智慧作为关键组件纳入自动化流程。这不仅仅是增加了一个“审核”按钮而是提供了一套方法论让你能够根据业务风险的高低灵活地设计人机协作的边界。对于开发者而言这意味着你可以更自信地将 AI 应用部署到关键业务流中因为你知道在最后一道防线上有一个可控的“开关”。对于业务负责人而言这意味着在享受 AI 带来的效率提升的同时仍然牢牢掌握着关键决策的质量。下一步你可以尝试将人工介入与 Dify 的其他高级功能结合例如在知识库检索结果置信度低时触发人工复核或者在多次用户追问后触发人工客服接管。通过精心设计的人机协作点你将能构建出既智能又可靠的下一代应用。