在 AI 应用开发中如何让模型在关键时刻“刹车”并引入人类的专业判断是提升应用可靠性与专业性的关键。Dify 作为领先的 LLM 应用开发平台其“人工介入”功能正是为此而生。本文将深入解析 Dify 1.15 版本中人工介入功能的完整配置与实战应用从核心概念到代码集成手把手教你构建一个可控、可信的 AI 工作流。本文适合正在使用或计划使用 Dify 构建企业级 AI 应用的开发者、产品经理和技术负责人。通过阅读你将掌握如何配置审批节点、如何通过 API 与人工审核流程交互以及如何将人工介入无缝融入你的业务逻辑最终打造出人机协同的高效应用。1. 人工介入概念、价值与应用场景在完全自动化的 AI 工作流中模型可能会生成不准确、不恰当或不符合业务规则的内容。尤其是在金融风控、内容审核、法律咨询、医疗建议等高风险领域纯粹的 AI 决策存在潜在风险。人工介入顾名思义就是在 AI 工作流的特定环节暂停自动化执行将决策权或审核权交由人类处理。在 Dify 中这通常体现为一个“审批”节点。当工作流执行到该节点时流程会暂停并生成一个待处理的任务等待指定的人员或系统进行审核。审核通过后工作流才会继续执行若驳回则流程可能终止或转向其他分支。核心价值风险控制在关键决策点设置人工审核防止 AI 产生重大错误。质量保证利用人类的专业知识和经验对 AI 的初步结果进行校验和优化。合规性满足某些行业法规要求确保关键流程有“人”的参与和监督。数据标注与迭代人工审核的结果通过/驳回及修改意见可以反哺 AI 模型用于后续的微调和优化。典型应用场景智能客服工单升级当 AI 客服无法解决复杂问题时自动转交人工客服。内容生成与审核AI 生成营销文案、新闻稿后需由编辑审核后才能发布。金融交易审批AI 系统识别出可疑交易模式后提交给风控专员进行最终裁定。代码审查助手AI 生成代码片段后需由资深工程师审核通过才能合并。法律文档初审AI 提取合同关键条款后由律师确认其准确性和完整性。Dify 的工作流引擎将这一能力产品化使得开发者无需从零构建复杂的任务队列和状态管理系统通过可视化配置和简单的 API 调用即可实现。2. 环境准备与版本说明在开始实操前请确保你的环境已就绪。1. Dify 部署与版本部署方式你可以使用 Dify 官方文档 推荐的 Docker Compose 或 Kubernetes 方式进行部署。本文假设你已有一个正在运行的 Dify 实例。核心版本本文功能基于Dify 1.15及以上版本。部分较旧的版本可能功能不全或界面有差异。请通过 Dify 管理后台的“系统状态”或部署时指定的镜像标签确认版本。访问地址确保你能通过浏览器访问 Dify 的控制台通常为http://your-server-ip:3000。2. 账户与权限你需要一个 Dify 账户并拥有创建应用和工作流的权限通常是“所有者”或“编辑者”角色。理解 Dify 中的“团队”和“成员”概念因为人工介入的审批者通常指定为团队内的成员。3. 测试工具准备API 测试工具推荐使用 Postman 或 Insomnia 用于模拟前端调用工作流并处理人工介入任务。命令行工具curl用于快速测试 API。Python 环境可选如果你计划编写后端服务与 Dify 的“人工介入”回调 API 集成需要准备 Python 3.8 环境及requests库。项目结构示意用于后端集成示例dify-human-in-the-loop-demo/ ├── app.py # 主应用模拟业务系统 ├── callback_server.py # 模拟人工审核后台服务 ├── requirements.txt # Python 依赖 └── README.md3. 核心功能与配置拆解Dify 的“人工介入”功能主要通过工作流中的“审批”节点来实现。我们需要深入理解这个节点的配置项。3.1 审批节点详解在工作流编辑器中你可以从节点库中添加“审批”节点。其主要配置区域如下1. 审批人设置这是核心配置决定由谁来进行审核。指定成员从当前团队中选择一个或多个具体成员。任务会出现在他们的“待办”列表中。变量指定更灵活的方式。你可以连接一个上游节点如“知识库检索”或“LLM”节点的输出变量该变量应包含审批人的用户ID或邮箱。这使得审批人可以动态决定例如将技术问题分配给技术负责人将财务问题分配给财务负责人。# 假设上游 LLM 节点根据问题类型输出了一个审批人邮箱 { “reviewer_email”: “tech-leadcompany.com” }角色指定企业版可以指定具有特定“角色”的成员组任务会分配给该角色下的任意成员。2. 审批方式任一审批人通过只要指定的任意一个审批人通过流程即继续。全部审批人通过需要所有指定的审批人都通过流程才能继续。3. 任务标题与描述标题定义待办任务在审批列表中的显示标题。支持使用变量如{{query}}引用用户输入的问题。描述详细说明该任务需要审核的内容、背景或审核要点。同样支持变量可以嵌入上游 AI 生成的完整内容供审核者参考。4. 超时设置为防止任务被无限期挂起可以设置超时时间。超时后任务自动按预设规则通过或驳回处理确保工作流不会阻塞。5. 输出变量审批节点执行后会产生输出变量供下游节点使用。关键变量包括status: 审批结果如approved通过、rejected驳回、pending等待中。reason: 审批人填写的审批意见或理由。approved_by: 审批人的信息。3.2 工作流状态与人工介入生命周期理解整个生命周期有助于调试和集成触发用户通过 WebApp 或 API 触发一个启用了“审批”节点的工作流。执行至审批节点工作流引擎执行到“审批”节点时会暂停当前流程的执行。创建待办任务在 Dify 后台的“待办”模块或通过 API生成一个任务并通知指定的审批人。人工处理审批人在 Dify 控制台查看任务详情包括输入、AI 中间结果等并做出“通过”或“驳回”决定可附上意见。工作流恢复一旦审批完成工作流引擎会立即收到通知并根据审批结果status决定后续路径。你可以通过“条件判断”节点来路由流程。返回最终结果工作流继续执行剩余节点并将最终结果返回给初始的调用者。4. 完整实战构建一个带人工审核的智能内容生成应用让我们构建一个实际的应用一个 AI 文章大纲生成器。AI 先生成大纲然后交由编辑审核审核通过后再让 AI 根据大纲撰写详细文章。4.1 在 Dify 中创建工作流步骤 1创建应用与工作流登录 Dify点击“创建应用”选择“工作流”类型命名为“智能文章创作带审核”。进入工作流编辑器。步骤 2编排工作流节点按顺序拖拽以下节点并连接开始节点接收用户topic文章主题输入。LLM节点命名为“生成大纲”模型选择 GPT-4 或 Claude 等。系统提示词你是一位资深编辑请根据用户提供的主题生成一份详细的文章大纲包括引言、3-5个主要章节及其子要点、结论。连接开始节点的topic变量到用户输入问题。输出变量设为outline。审批节点命名为“编辑审核大纲”审批人指定你团队中的一位成员例如你自己。审批方式任一审批人通过。标题审核文章大纲{{topic}}描述请审核以下由 AI 生成的文章大纲检查其结构是否合理、要点是否全面。\n\n## 生成的大纲\n{{outline}}输出变量保持默认status,reason等。条件判断节点命名为“判断是否通过”条件设置审批节点.status等于approved。这将创建两个分支“是”分支和“否”分支。LLM节点命名为“撰写文章”放在“是”分支系统提示词你是一位专业作家请根据以下审核通过的文章大纲撰写一篇完整、流畅的文章。用户输入问题大纲{{outline}}\n\n请基于此大纲撰写文章。输出变量设为article。答案节点命名为“返回文章”连接“撰写文章”节点将article作为最终输出。答案节点命名为“返回驳回信息”连接“否”分支返回一个固定提示如“大纲未通过审核原因{{审批节点.reason}}。请修改主题或要求后重试。”。最终工作流图应类似开始 - 生成大纲 - 编辑审核大纲 - 判断是否通过 - (是) - 撰写文章 - 返回文章 (否) - 返回驳回信息。步骤 3发布工作流点击右上角“发布”。发布后记下生成的app_id和access_token在应用概览页的 API 访问部分后续 API 调用需要。4.2 通过 API 触发工作流并处理人工介入工作流发布后可以通过 API 调用。当执行到审批节点时流程会暂停。1. 触发工作流模拟用户请求使用curl或 Postman 调用执行 API。curl -X POST \ https://api.dify.ai/v1/workflows/run \ -H “Authorization: Bearer YOUR_ACCESS_TOKEN” \ -H “Content-Type: application/json” \ -d ‘{ “inputs”: { “topic”: “人工智能在医疗诊断中的应用与挑战” }, “response_mode”: “blocking”, // 或 “streaming” “user”: “user_123” // 标识终端用户 }’YOUR_ACCESS_TOKEN替换为你的应用访问令牌。response_mode:blocking为同步阻塞会一直等待直到工作流最终完成包括人工介入时间这可能超时。对于含人工介入的场景更推荐使用streaming流式或通过task_id异步查询。调用后如果使用blocking模式API 会挂起直到审批完成或超时。在 Dify 后台的“待办”列表中你会看到一个新任务。2. 模拟审批人在 Dify 后台处理任务使用被指定为审批人的账户登录 Dify 控制台。点击左侧菜单的“待办”。找到标题为“审核文章大纲人工智能在医疗诊断中的应用与挑战”的任务点击进入。查看“描述”中 AI 生成的大纲。在底部选择“通过”或“驳回”并可以输入审批意见例如“大纲结构良好但请在‘挑战’部分增加数据隐私相关要点。”点击“提交”。3. 获取工作流最终结果审批提交后被挂起的工作流会继续执行。如果你使用streaming模式客户端会收到后续的事件流。你也可以通过“任务ID”来查询最终状态和输出。首先从初始调用的响应中获取task_id如果使用流式它可能在事件中传递。# 查询任务结果 curl -X GET \ “https://api.dify.ai/v1/tasks/{task_id}” \ -H “Authorization: Bearer YOUR_ACCESS_TOKEN” \ -H “Content-Type: application/json”响应会包含任务状态success,failed,pending和最终的outputs。4.3 进阶通过回调 API 与外部系统集成上述流程依赖审批人登录 Dify 后台操作。在企业场景你可能希望将审批任务集成到自有的 OA、钉钉或飞书等系统中。Dify 提供了Webhook支持。原理当工作流在审批节点暂停时Dify 可以向一个你预设的 URLWebhook发送任务创建的通知。你的外部系统接收后可以在自有界面展示任务并处理。处理完成后再调用 Dify 的 API 来提交审批结果。1. 在 Dify 中配置 Webhook企业版功能在工作流的“审批”节点配置中或是在应用设置的“Webhook”部分配置一个用于接收“任务创建”事件的 URL例如https://your-company.com/api/dify/review-task。2. 构建一个简单的回调服务器Python Flask 示例callback_server.pyfrom flask import Flask, request, jsonify import requests app Flask(__name__) # Dify 会向这个端点发送任务创建事件 app.route(‘/api/dify/review-task’, methods[‘POST’]) def handle_review_task(): data request.json event data.get(‘event’) if event ‘workflow.started’: # 工作流开始可以记录日志 pass elif event ‘workflow.node.awaiting’: # 关键事件节点等待即进入人工介入 task_id data.get(‘task_id’) node_id data.get(‘node_id’) workflow_run_id data.get(‘workflow_run_id’) # 提取任务信息 task_info { ‘task_id’: task_id, ‘run_id’: workflow_run_id, ‘node_id’: node_id, ‘title’: data.get(‘data’, {}).get(‘title’), ‘description’: data.get(‘data’, {}).get(‘description’), ‘app_id’: data.get(‘app_id’) } # TODO: 在这里将 task_info 存入你的数据库并推送通知到你的OA系统 print(f“收到审核任务: {task_info}”) # 模拟在外部系统处理完成后调用 Dify API 提交审批结果 # 这里为了演示我们假设自动通过。实际应由人工在外部系统触发。 # submit_review_to_dify(task_id, ‘approved’, ‘外部系统自动通过’) return jsonify({‘status’: ‘success’}), 200 def submit_review_to_dify(task_id, action, reason): “”“调用 Dify API 提交审批结果”“” api_url f“https://api.dify.ai/v1/workflows/tasks/{task_id}/approve” headers { ‘Authorization’: ‘Bearer YOUR_DIFY_APP_ACCESS_TOKEN’, ‘Content-Type’: ‘application/json’ } payload { ‘action’: action, # ‘approve’ 或 ‘reject’ ‘reason’: reason } response requests.post(api_url, jsonpayload, headersheaders) return response.json() if __name__ ‘__main__’: app.run(host‘0.0.0.0’, port5001, debugTrue)3. 外部系统调用 Dify API 提交审批当你的 OA 系统处理完任务后需要调用 Dify 的特定 API 来继续工作流。curl -X POST \ https://api.dify.ai/v1/workflows/tasks/{task_id}/approve \ -H “Authorization: Bearer YOUR_ACCESS_TOKEN” \ -H “Content-Type: application/json” \ -d ‘{ “action”: “approve”, // 或 “reject” “reason”: “内容符合标准同意发布。” }’此调用会直接驱动工作流从审批节点继续执行。5. 常见问题与排查思路在配置和使用人工介入功能时你可能会遇到以下问题问题现象可能原因排查步骤与解决方案工作流一直处于“运行中”不结束。1. 审批节点无人处理且未设置超时。2. 使用了blocking模式调用 API客户端在等待超时。1. 检查 Dify 后台“待办”列表是否有对应任务。2. 为审批节点设置合理的超时时间。3. 调用 API 时使用streaming模式并通过task_id异步查询结果。审批人收不到任务通知。1. 审批人配置错误成员不存在或未激活。2. 通知渠道未配置如邮件、Slack。1. 在审批节点确认指定的成员邮箱或 ID 正确无误。2. 在 Dify 管理后台的“团队设置”中检查并配置邮件/SMTP 或第三方消息集成。Webhook 未触发。1. Webhook URL 配置错误或不可达。2. 网络防火墙或安全组策略阻止。3. 仅企业版支持。1. 使用curl或 Postman 测试你的 Webhook 端点是否正常响应。2. 检查 Dify 服务器到你的回调服务器的网络连通性。3. 确认你的 Dify 版本是企业版。条件判断节点无法正确路由。审批节点的输出变量名引用错误。1. 在工作流编辑器中点击审批节点确认其输出变量名称默认为status,reason。2. 在条件判断节点中使用{审批节点别名.status}的格式进行引用。例如如果审批节点别名为review则条件应为review.status等于approved。API 调用返回“未授权”错误。1. Access Token 错误或已失效。2. API 密钥权限不足。1. 在 Dify 应用概览页重新复制正确的access_token。2. 确认该密钥具有工作流执行的权限。6. 最佳实践与工程建议将人工介入有效融入生产级应用需要考虑更多工程细节。1. 审批人策略设计动态指派尽量使用“变量指定”方式根据工单类型、问题复杂度、值班表等业务逻辑动态计算审批人实现灵活的负载均衡和专业化分工。备选审批人在“指定成员”时可以添加多位并利用“任一审批人通过”规则避免因单人缺席导致流程阻塞。审批链对于重要决策可以串联多个审批节点实现多级审核如初级审核-高级审核。2. 超时与降级策略设置合理超时根据业务紧急程度设置审批超时时间如2小时、24小时。超时后的自动处理规则通过或驳回需与业务方共同确定。降级处理在超时或审批系统异常时可以考虑设计一个降级分支例如将任务转给默认审批人或由另一个 LLM 节点进行二次校验并记录日志保证流程最终完成。3. 上下文信息与审核体验提供充分上下文在审批节点的“描述”中不仅要放 AI 的产出还应尽可能注入初始用户输入、上游处理的关键中间结果、知识库检索片段等帮助审批人快速理解背景做出准确判断。结构化输出让上游 LLM 节点输出结构化的 JSON 数据审批节点的描述模板可以更清晰地展示这些字段提升可读性。4. 安全与权限最小权限原则审批人只能看到完成任务所必需的信息。避免在审批描述中泄露敏感数据。Dify 的工作流变量传递是可控的。审计日志确保 Dify 的审计日志功能开启记录下“谁、在什么时候、通过了/驳回了哪个任务、理由是什么”满足合规要求。5. 性能与可观测性异步处理前端调用工作流时尽量使用异步模式response_mode: streaming或通过task_id轮询避免 HTTP 长连接超时。监控告警监控“待办”任务队列的长度和平均处理时间。如果积压过多或处理时间过长应触发告警通知管理员进行干预。数据闭环将审批结果尤其是驳回理由收集起来作为高质量数据用于后续对提示词Prompt或微调模型的优化持续提升 AI 的首次通过率。6. 集成扩展与 IM 工具深度集成除了使用 Dify 的官方插件如飞书、钉钉可以通过 Webhook 将审批任务直接推送至 IM 群聊或特定人员并允许在聊天窗口中快速审批通过点击按钮回调你的服务。自定义审批面板对于复杂的审批场景如需要查看多个关联系统数据可以利用 Dify 的 API 获取任务详情并嵌入到你自有的业务系统中进行展示和操作提供无缝的用户体验。通过以上实践你可以将 Dify 的人工介入功能从一个简单的“开关”升级为驱动复杂业务人机协同的核心枢纽。记住人工介入的目标不是取代 AI而是让 AI 在确定的边界内更安全、更可靠地发挥价值。