30款热门AI模型一站整合DeepSeek/GLM/Claude 随心用限时 5 折。 点击领海量免费额度在构建基于大语言模型的智能应用时一个常见的挑战是如何在自动化流程中引入可控的人工干预点。Dify 作为一个领先的 Agentic Workflow Builder其工作流引擎提供了强大的可视化编排能力而“人工介入”功能则是确保流程可控、结果可靠的关键机制。尤其在处理敏感业务、内容审核、复杂决策或需要最终确认的场景时让人类在关键时刻介入流程可以极大地提升应用的实用性和安全性。本文将深入探讨 Dify 1.15 版本中“人工介入”功能的设计理念、配置方法、实际应用案例以及在生产环境中部署的注意事项帮助你构建出既智能又可控的 AI 应用。1. 理解 Dify 工作流与人工介入的核心价值Dify 的核心优势在于将复杂的 AI 应用开发流程如 RAG检索增强生成、Agent智能体策略、工具调用等通过可视化的拖拽方式组合成工作流。然而纯粹的自动化流程在面对以下场景时可能力有不逮内容安全与合规审核AI 生成的营销文案、客服回复、新闻摘要等在发布前可能需要人工确认其合规性和准确性。关键业务决策例如一个自动化的贷款审批工作流在模型给出初步建议后需要信贷专员进行最终审批。复杂问题处理当 AI 在处理用户复杂请求时遇到不确定性或需要更多上下文信息时可以暂停流程并转交人工处理。结果质量把关在创意生成、代码编写等场景AI 的产出需要经过人工的润色和优化才能达到最佳效果。“人工介入”节点正是为解决这些问题而生。它允许你在工作流的任意环节设置一个“暂停点”将流程的控制权暂时交给指定的人员或团队。待人工完成审核、修改或决策后流程再根据人工输入的结果继续向下执行。这个机制将 AI 的自动化能力与人类的判断力、创造力相结合实现了“人机协同”。对于企业级应用而言这不仅降低了 AI 误操作的风险也使得 AI 能够处理更复杂、责任更重大的任务。2. 环境准备与 Dify 部署在开始配置人工介入工作流之前你需要一个可运行的 Dify 环境。Dify 支持多种部署方式这里我们以最通用的 Docker Compose 部署为例介绍从零开始的部署步骤。2.1 系统与环境要求确保你的服务器或本地开发机满足以下最低要求操作系统Linux (Ubuntu 20.04/CentOS 7), macOS, 或 Windows 10/11 (通过 WSL2 或 Docker Desktop)。Docker版本 20.10.0 或更高。Docker Compose版本 1.29.0 或更高。硬件建议至少 4GB 内存20GB 磁盘空间。如果计划运行本地大模型如通过 Ollama则需要更高的配置。网络能够访问 Docker Hub 和 GitHub 以下载镜像和代码。2.2 通过 Docker Compose 快速部署 Dify这是官方推荐且最稳定的部署方式适合大多数学习和生产场景。获取部署脚本 打开终端执行以下命令下载最新版本的部署脚本。# 创建并进入一个工作目录 mkdir dify cd dify # 下载 docker-compose.yaml 配置文件 curl -o docker-compose.yaml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml # 下载环境变量配置文件 curl -o .env https://raw.githubusercontent.com/langgenius/dify/main/docker/.env.example配置环境变量 编辑.env文件这是 Dify 服务配置的核心。你需要重点关注以下几个关键配置# 使用你喜欢的文本编辑器如 vim 或 nano vim .envSECRET_KEY用于加密的密钥务必修改为一个强随机字符串。CONSOLE_API_URLDify 控制台的后端 API 地址。本地部署通常为http://你的服务器IP:5001。CONSOLE_WEB_URLDify 控制台的前端访问地址。本地部署通常为http://你的服务器IP:3000。DB_PASSWORDPostgreSQL 数据库密码建议修改。REDIS_PASSWORDRedis 密码建议修改。对于首次本地测试你可以暂时使用默认配置但生产环境必须修改所有密码和密钥。启动 Dify 服务 在包含docker-compose.yaml和.env文件的目录下运行以下命令docker-compose up -d这个命令会拉取所需的 Docker 镜像包括前端、后端、数据库、Redis 等并在后台启动所有服务。验证部署 等待几分钟让服务完全启动后你可以通过以下方式验证检查容器状态运行docker-compose ps所有服务状态应为Up。访问 Web 控制台在浏览器中打开http://localhost:3000如果部署在远程服务器则替换为服务器 IP。初始设置首次访问会引导你创建管理员账号并完成初始配置。2.3 配置 LLM 模型提供商Dify 本身不提供大模型需要你配置一个或多个 LLM 提供商。这是工作流能够运行的前提。登录 Dify 控制台进入“设置” - “模型供应商”。添加提供商点击“添加模型供应商”选择你使用的服务如 OpenAI、Azure OpenAI、Anthropic、Ollama本地模型等。填写 API 密钥和端点对于 OpenAI/Azure你需要填入API Key和Base URL如果是 Azure还需填写API Version。对于本地部署的 OllamaBase URL通常为http://host.docker.internal:11434/v1Docker 容器内访问宿主机 Ollama 的方式API Key可以填写任意非空字符串如ollama。配置模型在供应商下添加你计划使用的具体模型如gpt-4o-mini,claude-3-5-sonnet,llama3.2等并为其命名。完成以上步骤你的 Dify 平台就具备了运行 AI 工作流的基础能力。3. 构建一个带有人工介入节点的完整工作流我们将创建一个简单的“内容生成与审核”工作流来演示人工介入功能。这个工作流的逻辑是用户输入一个主题 - AI 生成一篇博客草稿 - 转交人工审核 - 人工可以“通过”、“驳回”或“修改”内容 - 根据人工决策流程走向不同的分支。3.1 创建工作流与应用在 Dify 控制台点击“创建工作流”。为工作流命名例如博客生成与人工审核流程。系统会进入可视化的工作流画布编辑器。3.2 编排工作流节点我们将从左到右依次添加和连接节点。开始节点画布起始的“开始”节点代表用户输入。我们配置一个字符串变量topic作为输入。LLM 节点从左侧节点库拖拽一个“LLM”节点到画布连接到“开始”节点之后。模型选择你之前配置好的模型如gpt-4o-mini。提示词编写一个生成博客草稿的提示词。例如请根据用户提供的主题撰写一篇约500字的博客文章草稿。 主题{{topic}} 要求结构清晰包含引言、主体和结论。上下文变量确保topic变量被正确引入。输出变量将 LLM 的回复赋值给一个新变量如draft_content。人工介入节点这是核心节点。从节点库拖拽“人工介入”节点连接到 LLM 节点之后。节点配置指令清晰告诉审核人员需要做什么。例如“请审核以下 AI 生成的博客草稿。你可以选择‘通过’、‘驳回’或直接修改文本内容后提交。”变量分配将需要人工审核或修改的内容传递进来。这里我们选择draft_content变量。输出变量定义人工操作后的结果变量。通常你需要两个reviewed_content存储人工最终提交的文本内容可能是原稿也可能是修改后的。review_action存储人工选择的操作类型如approve,reject,modify。这个需要在指令中明确告知审核者如何选择。审批人配置方式可以选择“团队成员”需在 Dify 团队管理中添加成员或“变量”通过工作流运行时动态指定用户ID。对于演示我们可以先选择“团队成员”并指定自己。通知可以配置邮件或 Slack 通知当任务到达时提醒审批人。条件判断节点拖拽一个“条件判断”节点连接到人工介入节点之后。我们将根据review_action的值来决定流程走向。配置条件分支例如分支1如果review_action等于approve则执行“发布”分支。分支2如果review_action等于reject则执行“重写”分支。分支3如果review_action等于modify则执行“存档修改版”分支。分支处理节点发布分支可以连接一个“知识库”节点将reviewed_content存入知识库或连接一个“HTTP 请求”节点调用发布 API。重写分支可以连接回一个新的 LLM 节点指令为“根据审核意见被驳回重新生成一篇博客”然后可以再次进入人工介入或直接结束。存档分支连接一个“代码”节点或 HTTP 请求将reviewed_content保存到特定系统。结束节点为每个分支连接一个“结束”节点。至此一个包含人工决策环节的完整工作流就设计完成了。你的画布应该类似于开始 - LLM生成 - 人工介入 - 条件判断 - (多个分支) - 结束。3.3 调试与运行工作流点击画布右上角的“调试”按钮。在调试面板输入topic的值例如“人工智能在医疗诊断中的应用”。点击“运行”。工作流会执行到“人工介入”节点后暂停。此时你需要切换到“工作流运行历史”或审批人收到的通知链接中找到待处理的任务。在任务界面你可以看到 AI 生成的草稿并可以选择“通过”、“驳回”或在文本框中直接修改内容后提交。提交后返回调试面板点击“继续”工作流会根据你的选择沿着相应的分支执行完毕。通过调试你可以验证整个逻辑是否符合预期。4. 人工介入节点的关键配置与高级用法详解仅仅能暂停和继续是不够的。Dify 的人工介入节点提供了丰富的配置选项以适应复杂的业务场景。4.1 审批人配置策略配置方式适用场景配置要点注意事项指定团队成员固定审批人或小组流程责任明确。在 Dify 团队设置中添加成员后在此直接选择。审批人必须在 Dify 系统中拥有账户。人员变动时需要更新工作流配置。通过变量指定动态审批人如根据工单类型分配给不同部门主管。上游节点输出一个user_id变量在此选择该变量。需要确保上游输出的user_id与 Dify 系统中的用户ID匹配。角色组分配给一个角色组内的任意成员。需结合企业版或自定义开发实现。社区版可能不支持需检查版本功能。4.2 指令与表单设计人工介入节点的“指令”和变量配置本质上是为审批人设计一个表单。指令清晰必须明确告知审批人需要做什么决策、有哪些选项、修改内容的范围是什么。变量类型文本输入用于让审批人修改内容。配置时需传入初始文本变量。单选/下拉选择用于让审批人做出决策如通过/驳回。这通常通过配置不同的输出变量来实现如上文中的review_action。输出映射审批人提交后他修改的文本或选择的值需要被映射到指定的输出变量中供下游节点使用。务必确保变量名前后一致。4.3 超时与自动处理策略对于生产环境必须考虑审批人未及时处理的情况。任务超时可以在节点高级设置中配置超时时间例如24小时。超时策略超时后可以自动执行预设操作如“自动通过”、“自动驳回”或“转交他人”。这需要结合“变量”和“条件判断”来实现更复杂的逻辑例如超时后发送提醒并转给二级审批人。4.4 与外部系统集成人工介入不一定要在 Dify 内部完成。可以通过 Webhook 将审批任务发送到外部系统如 JIRA, OA 系统待外部系统处理完毕后再通过 Dify API 回调继续工作流。在人工介入节点可以配置“Webhook”通知将任务信息发送到外部系统。外部系统处理完成后调用 Dify 提供的工作流运行事件 API传入任务 ID 和审批结果。Dify 接收到回调后唤醒暂停的工作流并继续执行。这种方式实现了审批流程与企业现有系统的无缝融合。5. 生产环境部署与运维实践将带有人工介入的工作流投入生产需要考虑稳定性、安全性和可观测性。5.1 安全与权限管理API 密钥管理切勿在.env文件或前端代码中硬编码 LLM API Key。生产环境应使用安全的密钥管理服务如 Vault或利用 Docker 的 secret 管理功能。数据库安全修改默认的 PostgreSQL 和 Redis 密码并为数据库服务配置不对外网暴露的访问策略。网络隔离将 Dify 的服务部署在内网通过反向代理如 Nginx提供对外访问并配置 HTTPS、防火墙规则和访问控制列表ACL。用户权限利用 Dify 的团队和角色功能严格控制谁可以创建、编辑、发布工作流以及谁可以被指定为审批人。5.2 监控与日志服务健康监控监控 Docker 容器状态、服务端口、CPU/内存使用率。工作流运行监控在 Dify 控制台的“日志与审计”中密切关注工作流的运行历史、成功/失败率、以及人工介入节点的平均处理时长。应用日志收集配置 Docker 的日志驱动将dify-api和dify-web等容器的日志收集到 ELKElasticsearch, Logstash, Kibana或 Loki 等集中日志平台便于排查问题。5.3 性能与高可用资源规划根据预估的并发工作流数量和 LLM 调用频率为服务器分配足够的 CPU、内存和磁盘 I/O。特别是向量数据库如果使用非常消耗内存。数据库与 Redis考虑将 PostgreSQL 和 Redis 部署为高可用集群避免单点故障。水平扩展Dify 的后端服务dify-api理论上可以进行水平扩展但需要注意会话Session和 WebSocket 连接的状态管理问题可能需要配置共享的 Redis 作为会话存储。5.4 版本管理与回滚工作流版本化Dify 本身支持工作流版本的发布与回滚。在重大修改前先发布一个新版本进行测试而不是直接修改已上线的生产版本。基础设施即代码将docker-compose.yaml和.env文件纳入 Git 版本控制任何配置变更都应通过代码提交和审核流程。备份策略定期备份 PostgreSQL 数据库。Dify 的所有核心数据应用、工作流配置、知识库文档、对话历史都存储在数据库中。6. 常见问题排查清单在实际使用中你可能会遇到以下问题。这里提供系统的排查思路。问题现象可能原因检查步骤解决方案工作流在人工介入节点后不暂停1. 节点配置错误未成功连接。2. 调试模式可能跳过人工节点。3. 审批人配置为空或无效。1. 检查画布上节点连线是否牢固。2. 确认是在“发布”的应用中运行而非“调试”。3. 检查人工介入节点的“审批人”是否已正确配置。1. 重新连接节点。2. 发布应用后通过API或Web界面测试。3. 填写有效的审批人。审批人收不到任务通知1. 通知渠道未配置或配置错误。2. 邮件/SMTP服务未正确设置。3. 用户通知设置被关闭。1. 检查人工介入节点的“通知”配置。2. 检查Dify后台设置中的邮件/Slack集成配置。3. 查看相应用户的个人设置。1. 正确配置通知。2. 在“设置-邮件”中配置正确的SMTP信息。3. 提醒用户开启通知。人工提交后工作流不继续1. 回调失败外部审批时。2. 工作流运行实例已超时或被清理。3. 输出变量映射错误下游节点无法获取数据。1. 查看Dify API日志检查回调请求。2. 检查“运行历史”中该实例的状态。3. 调试下游节点检查输入变量是否存在。1. 确保回调URL正确且外部系统能访问Dify API。2. 增加工作流运行超时时间。3. 核对人工介入节点的输出变量名。“人工介入”节点在画布中找不到1. Dify 版本过低。2. 节点库被过滤或隐藏。1. 查看Dify控制台底部版本号。2. 检查节点库搜索框或分类筛选。1. 升级 Dify 到 1.15 或更高版本。2. 在节点库的“高级”或“工具”分类中查找。审批页面无法加载或报错1. 前端静态资源加载问题。2. 对应的运行历史记录不存在或已失效。3. 用户权限不足。1. 检查浏览器控制台网络报错。2. 确认任务链接中的运行ID是否有效。3. 确认当前登录用户是否为指定审批人。1. 清理浏览器缓存或尝试无痕模式。2. 从“运行历史”中重新进入任务。3. 使用正确的审批人账号登录。7. 最佳实践与扩展方向为了最大化“人工介入”节点的价值避免常见陷阱请遵循以下实践建议。7.1 设计阶段的最佳实践明确介入点并非所有环节都需要人工介入。只在关键决策点、高风险操作点或质量瓶颈点设置。过多的介入会降低自动化效率。设计友好的审批界面通过清晰的“指令”和结构化的变量让审批人快速理解任务减少认知负担。可以提供预设的审批意见选项。设置超时与升级策略为人工任务设定合理的截止时间并规划超时后的自动处理流程或转交他人的规则确保流程不会无限期阻塞。闭环反馈考虑将人工的修改或驳回意见作为反馈数据回流到上游的 AI 模型或提示词优化中实现系统的持续改进。7.2 开发与测试实践版本控制工作流利用 Dify 的版本管理任何对生产工作流的修改都应先创建新版本进行充分测试。模拟人工审批在测试阶段可以创建一个测试用户账号来模拟完整的审批流程确保所有分支逻辑都能正确执行。压力测试模拟高并发场景下大量工作流同时进入人工介入节点时系统的稳定性和任务列表的可用性。7.3 扩展方向与 MCP (Model Context Protocol) 集成Dify 支持 MCP 协议这意味着你可以将人工介入任务派发到任何兼容 MCP 的外部工具或系统中进行处理极大地扩展了集成可能性。构建复杂的审批链通过多个“人工介入”节点和“条件判断”节点可以构建多级审批流程如员工提交 - 经理审批 - 总监审批。数据统计与优化定期分析人工介入节点的数据哪些环节驳回率高平均处理时长是多少这些数据是优化 AI 提示词、调整工作流逻辑乃至培训 AI 模型的宝贵依据。人工介入功能将 Dify 从一个纯自动化的 AI 工作流工具升级为一个支持人机协同的智能业务系统。它填补了 AI 能力与复杂现实业务需求之间的最后一道鸿沟。通过精心设计介入点、配置清晰的审批逻辑并建立可靠的运维体系你可以构建出既高效又安全、既智能又可控的企业级 AI 应用真正让 AI 技术为业务创造可衡量、可管理的价值。 30款热门AI模型一站整合DeepSeek/GLM/Claude 随心用限时 5 折。 点击领海量免费额度