Dify 1.15 人工介入功能实战:构建可控的混合智能工作流 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度在实际企业级应用开发中将大语言模型LLM的能力无缝集成到业务流程中并确保其输出可控、可靠是一个核心挑战。Dify 作为一个开源的 LLM 应用开发平台其工作流功能允许开发者以可视化方式编排复杂的 AI 任务。然而完全自动化的流程有时无法满足需要人类判断、审核或补充信息的场景。Dify 1.15 版本引入的“人工介入”功能正是为了解决这一痛点它允许工作流在特定节点暂停等待人工输入或审核后再继续执行后续步骤。这极大地扩展了 AI 应用的边界使其能够处理诸如内容审核、数据标注、复杂决策支持等混合智能任务。本文将深入探讨 Dify 1.15 中人工介入功能的实现与实战。我们将从零开始构建一个包含人工审核节点的文本生成工作流涵盖环境准备、工作流设计、节点配置、API 调用以及生产环境下的最佳实践。无论你是希望为 AI 应用增加一层安全护栏还是构建需要人机协作的复杂业务流程本文都将提供一套可复现的完整方案。1. 理解 Dify 工作流与人工介入的核心机制在深入配置之前必须理解 Dify 工作流中人工介入节点的工作原理这决定了后续所有设计和排查的逻辑。1.1 Dify 工作流的基本构成Dify 工作流是一个有向无环图DAG由不同类型的节点通过连线连接而成。每个节点代表一个处理单元例如LLM 节点调用大模型进行文本生成、总结或对话。知识库检索节点从已上传的文档中检索相关信息。代码执行节点运行 Python 脚本处理数据。人工介入节点1.15 新增暂停流程等待外部人工输入。节点之间的连线定义了数据的流向。工作流从开始节点触发数据沿连线传递经过各个节点的处理最终到达结束节点输出结果。1.2 人工介入节点的两种模式与状态机人工介入节点是工作流中的“阻塞点”。它有两种主要模式人工输入工作流运行到此节点时暂停并向外部的调用方如你的业务系统返回一个特定的“任务 ID”和状态。你的前端界面可以提示用户填写表单、选择选项或上传文件。然后你的系统通过 Dify 的 API 提交用户输入工作流才会从此节点继续执行并将人工输入的数据传递给下游节点。人工审核工作流运行到此节点时暂停并将上游节点如 LLM 生成的文本的结果作为待审核内容返回。人工审核通过或拒绝后工作流继续并可能根据审核结果走向不同的分支。该节点的内部状态机是关键等待中Pending节点已触发正在等待人工处理。已通过Approved人工审核通过或输入完成。已拒绝Rejected人工审核拒绝。已跳过Skipped在超时或特定规则下跳过此节点。理解这个状态机对于通过 API 正确操作节点和设计后续流程至关重要。1.3 为什么需要人工介入典型应用场景纯粹自动化的 AI 流程存在局限性质量与安全把控AI 生成的营销文案、客服回复可能需要人工审核后才能发布避免产生不合规或低质量内容。复杂决策AI 可以给出数据分析报告和建议但最终的审批决策如贷款审批、内容推荐权重需要人类确认。数据补充与修正AI 在处理非结构化信息如发票图片识别时可能无法 100% 准确需要人工核对和补全关键字段。流程合规性许多企业流程强制要求关键步骤必须有人类参与。人工介入功能将这些需要人类智慧的场景变成了工作流中一个可编排、可监控的标准环节。2. 环境准备与 Dify 部署为了进行完整的实操我们需要一个可用的 Dify 环境。以下提供两种主流部署方式Docker Compose推荐和本地开发环境。2.1 部署方式选择与系统要求对于学习和生产前期的测试Docker Compose 部署是最简单、最干净的方式它能避免复杂的本地环境依赖问题。最低系统要求操作系统Ubuntu 20.04/CentOS 7/macOS 或 Windows需 Docker DesktopCPU2 核以上内存4 GB 以上运行 LLM 需更多磁盘20 GB 可用空间Docker20.10Docker Compose2.0注意如果你计划在 Windows 11 上本地部署用于开发测试确保已安装 WSL2 和 Docker Desktop并为其分配足够的内存建议 4GB。2.2 使用 Docker Compose 快速部署 Dify这是最推荐的部署方式能一键拉起所有服务。获取部署脚本 在服务器或本地开发机的终端中执行以下命令下载官方部署脚本。# 创建项目目录并进入 mkdir dify cd dify # 下载 docker-compose 配置文件 curl -o docker-compose.yaml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml # 下载环境变量示例文件 curl -o .env.example https://raw.githubusercontent.com/langgenius/dify/main/.env.example配置环境变量 复制环境变量文件并进行关键配置。OPENAI_API_KEY是必填项用于连接 OpenAI 或兼容 API 的模型。cp .env.example .env # 使用 vim 或 nano 编辑 .env 文件 vim .env在.env文件中找到并修改以下关键配置# 设置你的 OpenAI API Key 或其它兼容服务如 Azure OpenAI, Ollama 的 OpenAI 兼容端点的 Key OPENAI_API_KEYsk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 修改 API 地址如果你使用 Azure OpenAI 或本地 Ollama # OPENAI_API_BASEhttps://api.openai.com/v1 # 设置一个安全的随机字符串作为密钥 SECRET_KEYyour-very-secret-key-change-this启动 Dify 服务 使用 Docker Compose 启动所有容器。# 在后台启动服务 docker-compose up -d首次启动会拉取镜像并初始化数据库可能需要几分钟。你可以使用以下命令查看日志确认服务是否正常启动。# 查看所有容器日志 docker-compose logs -f # 或仅查看 web 服务日志 docker-compose logs -f web当看到日志中出现Application startup complete.或类似信息时表示启动成功。访问与初始化 在浏览器中打开http://你的服务器IP:3000本地部署则为http://localhost:3000。 首次访问会进入初始化页面设置管理员账号和密码完成后即可登录 Dify 控制台。2.3 配置模型供应商以 Ollama 本地模型为例如果你希望使用本地模型如通过 Ollama 运行的 Llama 3、Qwen 等来降低成本或保证数据隐私需要进行额外配置。确保 Ollama 已安装并运行 在本地或同一网络下的另一台机器上安装并启动 Ollama并拉取一个模型。# 安装 Ollama (Linux/macOS) curl -fsSL https://ollama.com/install.sh | sh # 启动 Ollama 服务 ollama serve # 拉取一个模型例如 Llama 3.1 8B ollama pull llama3.1:8b在 Dify 中配置模型登录 Dify 控制台进入“设置” - “模型供应商”。点击“添加模型供应商”选择“OpenAI 兼容”。在配置页面中名称填写Ollama-Local。API 密钥可以任意填写如ollama因为本地 Ollama 通常不验证密钥。API 地址填写你的 Ollama 服务的 OpenAI 兼容端点例如http://host.docker.internal:11434/v1注意在 Docker 容器内访问宿主机服务需用host.docker.internalLinux 下可能需要用宿主机 IP。保存后在“模型”标签页点击“新建模型”选择刚才添加的供应商并填写模型名称必须与 Ollama 中的模型名匹配如llama3.1:8b。配置完成后你就可以在工作流中使用这个本地模型了。3. 构建一个带人工审核的新闻稿生成工作流现在我们开始实战。目标是构建一个工作流用户输入一个新闻主题 - LLM 生成新闻稿草稿 - 触发人工审核 - 审核通过后发布模拟审核拒绝则返回修改意见。3.1 创建工作流与应用在 Dify 控制台点击“工作流”-“创建空白工作流”。为工作流命名例如新闻稿生成与审核流程。点击“发布”标签页点击“创建应用”将此工作流发布为一个可调用的应用。记下生成的APP_ID和API_KEY后续 API 调用会用到。3.2 设计工作流节点与连接回到工作流编辑画布从左侧节点库拖拽以下节点到画布并连线开始节点作为流程入口。LLM 节点连接到开始节点。将其重命名为生成新闻稿草稿。人工介入节点连接到 LLM 节点的输出。将其重命名为人工审核新闻稿。条件判断节点连接到人工介入节点的输出。将其重命名为判断审核结果。两个 LLM 节点分别连接到条件判断节点的true和false分支。重命名为生成发布文案和生成修改意见。结束节点分别连接到两个 LLM 节点的输出。最终画布结构应类似于开始 - 生成新闻稿草稿 - 人工审核新闻稿 - 判断审核结果 - (通过)生成发布文案 - 结束和判断审核结果 - (拒绝)生成修改意见 - 结束。3.3 配置关键节点参数节点的配置是工作流逻辑的核心。配置生成新闻稿草稿LLM 节点模型选择你配置好的模型如 GPT-4 或本地 Llama。上下文连接开始节点的query变量。提示词编写一个清晰的系统提示词例如你是一名专业的新闻编辑。请根据用户提供的主题撰写一篇结构完整、语言流畅的新闻稿草稿。新闻稿应包含标题、导语、主体和结语。 主题{{#context#}}变量将输出变量命名为draft_text以便后续节点引用。配置人工审核新闻稿节点这是人工介入功能的核心。节点类型确保选择“人工介入”。模式选择“人工审核”。这意味着上游 LLM 生成的draft_text将作为待审核内容。指令填写给审核人员的指引例如请审核以下新闻稿草稿。检查其事实准确性、语言得体性以及是否符合发布标准。你可以选择“通过”或“拒绝”。输出变量review_result: 用于存储审核结果approved或rejected。review_comment: 用于存储审核人员填写的评论可选。配置判断审核结果条件节点条件设置添加一个条件分支。分支1通过review_result等于approved。分支2拒绝review_result等于rejected。这将根据人工审核的结果决定工作流走向哪个分支。配置分支 LLM 节点生成发布文案节点提示词可以设计为新闻稿已通过审核准备发布。请为其生成一段简短的社交媒体推广文案。新闻稿内容{{draft_text}}。生成修改意见节点提示词可以设计为新闻稿被审核拒绝。审核意见是{{review_comment}}。请根据审核意见生成一份具体、可操作的修改建议指导编辑进行修改。原新闻稿{{draft_text}}。配置完成后点击画布右上角的“保存”。4. 通过 API 触发工作流并处理人工介入工作流设计好后需要通过 API 来触发和驱动。人工介入节点的特殊性在于它会使工作流暂停等待外部系统通过额外的 API 调用来“恢复”它。4.1 获取应用凭证与 API 端点在 Dify 应用发布页面你可以找到以下关键信息APP_IDAPI_KEY可在“权限”中生成和管理API 地址通常为https://your-dify-domain/v1/workflows/run4.2 首次调用触发工作流使用curl或任何 HTTP 客户端如 Postman发起请求。这个调用会启动工作流并一直执行到遇到“人工介入”节点为止。curl --location https://your-dify-domain/v1/workflows/run \ --header Authorization: Bearer your-api-key \ --header Content-Type: application/json \ --data { inputs: { query: 苹果公司发布最新款MacBook Pro }, response_mode: blocking, # 使用阻塞模式等待直到遇到人工介入或结束 user: user-123 # 标识终端用户 }关键参数解释inputs: 对应工作流开始节点的输入变量。这里query是我们在开始节点定义的变量名。response_mode:blocking表示同步等待。当工作流遇到人工介入节点时本次调用会返回并告知你有人工任务需要处理。user: 用于区分不同终端用户便于后续的会话管理和审计。4.3 解析响应获取人工任务信息当工作流在人工介入节点暂停时API 的响应将不同于普通完成。你需要仔细解析响应体。一个典型的、包含待处理人工任务的响应如下{ event: task_start, task_id: task_abc123def456, workflow_run_id: run_xyz789, data: { node_id: human-intervention-node-id, node_type: human-intervention, title: 人工审核新闻稿, description: 请审核以下新闻稿草稿..., variables: { draft_text: 【这里是LLM生成的新闻稿全文...】 }, form_schema: [ { type: select, label: 审核结果, variable: review_result, required: true, options: [ {label: 通过, value: approved}, {label: 拒绝, value: rejected} ] }, { type: textarea, label: 审核意见, variable: review_comment, required: false } ] } }你需要从响应中提取的关键信息task_id: 此人工任务的唯一标识符用于后续提交操作。workflow_run_id: 此次工作流运行的唯一标识符。node_id: 人工介入节点的 ID。variables: 包含了上游节点传递过来的数据如draft_text你的前端界面需要展示这些数据供审核人员参考。form_schema: 定义了需要人工填写或选择的内容的结构。你需要根据这个 schema 在前端渲染出一个表单。4.4 二次调用提交人工处理结果当你的前端系统收集到人工输入例如审核人员点击“通过”并提交了意见后需要调用另一个 API 来提交结果使工作流继续。curl --location --request POST https://your-dify-domain/v1/workflows/tasks/submit \ --header Authorization: Bearer your-api-key \ --header Content-Type: application/json \ --data { task_id: task_abc123def456, inputs: { review_result: approved, review_comment: 内容准确语句通顺可以发布。 } }关键参数解释task_id: 必须与上一步获取的task_id一致。inputs: 提交的数据必须严格匹配form_schema中定义的variable名称。这里review_result和review_comment就是我们在工作流节点中定义的输出变量。提交成功后Dify 后端会唤醒暂停的工作流将inputs中的数据注入到对应节点然后工作流继续执行根据条件判断节点走向“通过”或“拒绝”分支。4.5 获取工作流最终结果提交人工任务后工作流会继续运行直至结束。你可以通过两种方式获取最终结果WebSocket 流式响应在首次调用时使用response_mode: streaming并通过 WebSocket 连接监听事件。当event为workflow_finished时data中包含最终输出。查询运行状态使用workflow_run_id调用状态查询接口。curl --location https://your-dify-domain/v1/workflows/runs/{workflow_run_id} \ --header Authorization: Bearer your-api-key5. 生产环境关键配置、排错与最佳实践将带有人工介入的工作流投入生产需要考虑更多因素。5.1 配置与安全清单配置项学习/测试环境生产环境建议API Key 管理使用默认生成的 Key为不同应用/客户端创建独立的 Key并设置访问频率限制和有效期。定期轮换。数据库使用 Docker Compose 内置的 PostgreSQL考虑使用云托管数据库如 RDS或独立部署的 PostgreSQL并做好备份策略。文件存储使用本地存储或 Docker 卷配置外部对象存储如 S3、MinIO确保文件持久化和可扩展。网络与域名使用 IP:Port 访问配置域名、SSL 证书HTTPS和反向代理如 Nginx。将服务部署在内网通过 API 网关对外暴露。日志与监控查看 Docker 容器日志配置结构化日志JSON 格式并接入 ELK 或 Loki/Grafana。对关键指标API 调用量、工作流执行时长、人工任务积压数进行监控。人工任务超时默认或无限制在人工介入节点设置“任务超时时间”如 24 小时超时后可按预设规则跳过、转交、默认处理继续流程避免流程永久阻塞。5.2 常见问题排查路径人工介入功能涉及前后端和 API 交互以下是常见问题的排查思路。问题现象可能原因检查步骤解决方案工作流无法触发返回401或403API Key 错误或权限不足1. 检查请求头Authorization: Bearer api-key格式是否正确。2. 在 Dify 控制台确认该 API Key 是否启用、是否关联了正确应用。重新生成 API Key 并确保应用已发布。触发工作流后立即返回结束未暂停人工介入节点配置错误或未连接1. 在工作流画布检查人工介入节点是否已正确连接到上游节点。2. 检查节点配置“模式”是否选择正确。重新连接节点连线检查节点输出变量名是否被下游条件节点正确引用。获取到人工任务但提交后工作流不继续task_id错误或提交数据格式不对1. 核对提交 API 使用的task_id是否与接收到的完全一致。2. 检查inputs中的键值对是否与form_schema中的variable名称完全匹配大小写敏感。3. 查看 Dify 服务端日志 (docker-compose logs -f api) 是否有验证错误。确保前端系统正确存储和传递task_id。按照form_schema的结构精确构建提交数据。人工任务在前端显示为“已过期”任务超时检查人工介入节点是否设置了超时时间以及工作流运行是否超过了该时间。1. 对于重要任务设置合理的超时时间如 48 小时。2. 实现通知机制如邮件、钉钉在任务创建时提醒处理人。docker-compose up失败提示端口冲突3000、5001 等端口被占用运行netstat -tulnp | grep :3000查看占用进程。修改docker-compose.yaml文件中的端口映射例如将3000:3000改为8080:3000。工作流运行缓慢或超时模型响应慢或网络问题1. 检查模型供应商如 OpenAI API的状态和响应时间。2. 如果是本地模型Ollama检查服务器资源CPU/内存使用率。1. 为工作流设置全局超时时间。2. 考虑使用响应更快的模型或对耗时长的 LLM 节点进行异步处理优化。5.3 前端集成与用户体验最佳实践人工介入需要与你的业务系统前端深度集成。任务列表与分配构建一个后台任务中心集中展示所有pending状态的人工任务并可以分配给特定人员。上下文展示不仅展示form_schema要求填写的内容还要将variables中的上下文信息如待审核的新闻稿全文清晰地呈现给处理人。操作历史与审计记录每个人工任务由谁、在何时、做了何种操作通过/拒绝及意见。这些信息应能关联到原始的workflow_run_id。超时与升级机制如果一个任务即将超时或已被超时系统应能自动通知上级或备用处理人。保持连接如果使用流式响应 (streaming)前端需要妥善管理 WebSocket 连接在收到task_start事件时更新 UI并在用户提交后继续监听后续的workflow_finished事件。5.4 扩展方向更复杂的流程设计掌握了基础的人工审核后可以设计更复杂的混合智能流程多级审核串联多个人工介入节点实现“编辑初审 - 主编复审 - 法务终审”的流程。动态分支根据人工输入的不同内容如审核意见中提到了“价格错误”通过条件节点跳转到不同的专业处理分支如连接一个知识库查询正确价格。外部工具调用在人工审核通过后自动调用一个“发布文章”的 API 节点将最终文案发布到 CMS 系统。并行处理使用并行分支让多个审核人员同时审核同一份内容然后根据汇总结果如“多数通过”决定流程走向。人工介入功能将 Dify 从一个自动化 AI 工具升级为一个可编排“人机协同”复杂业务流程的强大平台。成功的集成关键在于清晰定义人机职责边界、设计友好的交互界面以及构建鲁棒的异常处理与监控机制。从本文的最小可行案例出发逐步迭代你就能构建出适应复杂业务需求的智能工作流系统。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度