30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度这次我们来看 Dify 1.15 版本中一个非常关键的功能人工介入。对于任何将 AI 应用投入实际生产或严肃业务流程的团队来说如何确保 AI 输出的质量、可控性和合规性是一个绕不开的挑战。Dify 1.15 引入的“人工介入”机制正是为了解决这个问题。它不是一个简单的“审核”按钮而是一套完整的、可嵌入到自动化流程中的人机协作框架。简单来说这个功能允许你在 AI 应用的工作流中设置一个或多个“检查点”。当流程运行到这些检查点时系统会自动暂停将当前的任务状态、AI 的中间输出或最终结果推送给指定的人工审核员。审核员可以查看、修改、批准或驳回处理完成后流程才会继续向下执行。这确保了关键环节的输出质量同时又不完全打断自动化流程的效率。本文将带你快速上手 Dify 1.15 的“人工介入”功能。我们会重点关注它的核心能力、部署门槛、具体配置步骤并通过一个实际的文本生成与审核场景演示如何从零搭建一个带有人工审核环节的 AI 工作流。无论你是想为客服机器人增加一道质量防线还是为内容生成流程加入合规检查这篇文章都能提供清晰的路径。1. 核心能力速览在深入细节之前我们先通过一个表格快速了解 Dify 1.15 “人工介入”功能的核心规格和适用性。能力项说明功能定位在 Dify 工作流中插入人工审核节点实现人机协同的自动化流程。触发方式支持基于节点输出内容、变量条件等多种方式触发人工介入。审核界面提供专用的 Web 审核面板审核员可查看上下文、修改内容、添加批注。操作动作审核员可执行“通过”、“拒绝”、“修改后通过”等操作。流程控制审核结果决定工作流后续分支继续执行、跳转到指定节点或终止。通知机制支持通过系统内部通知或 Webhook 等方式通知审核员。权限与分配可指定特定成员、角色或通过变量动态分配审核任务。部署方式与 Dify 平台部署方式一致支持 Docker 一键部署、源码部署等。硬件门槛主要取决于 Dify 本身及背后连接的模型服务如 OpenAI API, 本地模型。人工介入功能本身资源消耗极低。适合场景内容安全审核、金融/法律文本生成校对、客服答案质量把控、创意内容最终审定等需要人工确认的 AI 应用场景。2. 适用场景与使用边界“人工介入”功能的核心价值在于将人的判断力无缝嵌入到 AI 自动化流程中。它特别适合以下几类场景内容安全与合规审核AI 生成的营销文案、新闻稿、社交媒体内容在发布前需要经过人工对事实准确性、品牌调性、法律法规符合性进行最终把关。关键业务决策辅助例如由 AI 初步生成的合同条款、投资分析报告、风险评估摘要必须由专业法务或分析师进行复核确认。高质量客服与问答对于复杂或敏感的客户问题AI 提供的初步答案可以先由人工坐席审核修改再发送给客户确保服务质量和专业性。创意内容生产流程AI 生成的广告创意、设计文案、视频脚本等需要创意总监进行最终的艺术性和效果审定。使用边界与注意事项非实时同步人工介入会引入异步等待时间不适合对实时性要求极高的对话场景如秒级响应的聊天。审核负载管理需要合理设计介入点和分配策略避免审核任务堆积成为流程瓶颈。责任界定当人工修改了 AI 输出后最终结果的责任应由“审核通过”的操作者承担。需要在业务流程中明确此规则。隐私与数据安全审核界面会展示流程中的全部上下文信息包括可能的用户输入。需确保审核员有相应的数据访问权限并遵守相关数据安全规定。3. 环境准备与前置条件要使用 Dify 1.15 的人工介入功能你首先需要一个正常运行的 Dify 服务。以下是部署和准备的核心要点。3.1 Dify 平台部署Dify 提供了多种部署方式对于大多数用户推荐使用 Docker Compose 进行一键部署最为方便。操作系统Linux (Ubuntu 20.04/CentOS 7), macOS, 或 Windows (通过 WSL2)。依赖Docker 20.10 和 Docker Compose 2.0。硬件最低 2核 CPU4GB 内存。实际需求取决于你使用的 AI 模型如果使用本地模型则对 GPU 有要求。人工介入功能本身不消耗额外计算资源。网络服务器需要能访问你计划使用的模型 API如 OpenAI, Anthropic 或你自建的本地模型服务。3.2 获取部署文件访问 Dify 的 GitHub 仓库 Release 页面下载最新版本确保 1.15的docker-compose.yaml文件。# 创建一个工作目录并进入 mkdir dify cd dify # 下载 docker-compose 文件 (请替换为最新的版本链接) wget -O docker-compose.yaml https://github.com/langgenius/dify/releases/download/v1.15.0/docker-compose.yaml # 下载环境变量配置文件 wget -O .env https://github.com/langgenius/dify/releases/download/v1.15.0/.env.example3.3 配置关键环境变量编辑.env文件配置数据库、Redis 以及最重要的——模型供应商。# 编辑 .env 文件 nano .env你需要关注并修改以下部分以使用 OpenAI 为例# 数据库配置 DB_PASSWORDyour_secure_db_password # Redis 配置 REDIS_PASSWORDyour_secure_redis_password # OpenAI 配置 (如果你使用 OpenAI) OPENAI_API_KEYsk-your-openai-api-key-here # 或者使用 Azure OpenAI # AZURE_OPENAI_API_KEYyour-azure-key # AZURE_OPENAI_ENDPOINThttps://your-resource.openai.azure.com/如果你计划主要使用本地模型如通过 Ollama、vLLM 或 Transformers 部署则需要额外配置MODEL_PROVIDER等参数并确保 Dify 网络能访问到你的模型服务端点。4. 安装部署与启动方式配置完成后启动服务非常简单。4.1 一键启动服务在包含docker-compose.yaml和.env文件的目录下执行# 启动所有服务 docker-compose up -d这个命令会在后台启动 Dify 所需的所有容器Web 前端、后端 API、数据库、Redis 等。首次启动会拉取镜像并初始化数据库可能需要几分钟。4.2 检查服务状态启动后可以使用以下命令查看容器运行状态docker-compose ps你应该看到所有服务的状态都是 “Up”。也可以通过日志观察启动过程# 查看所有服务的日志 docker-compose logs -f # 仅查看后端服务的日志 docker-compose logs -f api4.3 访问 Web 界面服务启动成功后在浏览器中访问http://你的服务器IP:3000。首次访问需要创建管理员账户。按照界面指引完成初始化设置即可进入 Dify 主控台。至此一个包含完整人工介入功能的 Dify 1.15 平台就准备就绪了。5. 功能测试与效果验证构建一个带人工审核的文案生成工作流现在我们通过一个实际的例子来验证“人工介入”功能。场景是构建一个“社交媒体文案生成器”AI 根据用户输入的产品描述生成文案但发布前必须经过市场部同事的人工审核。5.1 创建应用与工作流在 Dify 控制台点击“创建应用”选择“工作流”类型命名为“社交媒体文案生成与审核”。进入工作流画布编辑器。5.2 编排工作流节点我们将依次添加以下节点开始接收用户输入。LLM调用大模型生成文案。人工介入暂停流程等待审核。条件判断根据审核结果决定流程走向。结束输出最终结果。具体操作如下设置开始节点从左侧拖入“开始”节点。在右侧面板添加一个输入变量例如product_desc产品描述类型为字符串。添加 LLM 节点拖入一个“LLM”节点并将其连接到“开始”节点之后。在节点配置中选择你已配置好的模型如 gpt-4o-mini。在“提示词”区域编写类似以下的指令你是一名专业的社交媒体文案写手。请根据以下产品描述生成一段吸引人的、适合在推特上发布的文案不超过280字符。 产品描述{{product_desc}} 生成的文案在“变量”部分将输出变量名设置为draft_copy草稿文案。添加人工介入节点核心拖入“人工介入”节点连接到 LLM 节点之后。配置介入信息标题设置为“文案审核{{product_desc}}”这样审核员一眼就知道任务内容。描述可以写“请审核并修改以下由 AI 生成的社交媒体文案。”变量分配这里是我们需要审核的内容。点击“添加变量”选择上一步 LLM 节点的输出draft_copy。这意味着审核员将看到并可以修改这个草稿文案。配置操作按钮默认有“通过”和“拒绝”。我们可以保留也可以自定义。例如可以添加一个“修改后通过”的按钮。配置指派可以选择“仅应用创建者”或“指定成员”。在团队协作中你可以指定“市场部”角色的成员。这里为了测试可以先选“仅应用创建者”。超时设置可以设置任务等待审核的最长时间超时后可按预设规则如自动通过或拒绝处理。5.3 添加条件分支与结束节点添加条件判断节点拖入“条件判断”节点连接到“人工介入”节点之后。这个节点会根据人工介入的结果决定流程走向。配置条件分支在条件判断节点的配置中添加分支。第一个分支条件设置为人工介入节点状态等于通过。这意味着如果审核员点击了“通过”。第二个分支条件设置为人工介入节点状态等于拒绝。 如果添加了“修改后通过”也需要相应配置添加结束节点拖入两个“结束”节点。将第一个结束节点连接到“通过”分支将其命名为“审核通过”。在这个结束节点的“答案”区域可以输出最终文案。这里应该输出被审核员确认或修改后的文案。我们需要引用人工介入节点处理后的变量。假设人工介入节点输出的变量名是reviewed_copy则答案可以设置为{{reviewed_copy}}。将第二个结束节点连接到“拒绝”分支将其命名为“审核拒绝”。在答案区域可以设置一个固定回复如“文案未通过审核请重新输入需求或联系市场部。”连接人工介入到条件判断关键一步选中“人工介入”节点你会看到其输出中有一个status变量。确保在连接时这个状态变量能传递到条件判断节点。最终你的工作流应该看起来像一个有分支的管道开始 - LLM - 人工介入 - 条件判断 - (通过/拒绝) - 不同的结束节点。5.4 保存并发布工作流点击右上角“发布”按钮为工作流创建一个版本。发布后你可以获得一个公开的访问链接或 API 端点。6. 接口 API 与批量任务Dify 不仅提供 Web 界面所有功能都可通过 API 驱动这对于集成到现有系统或处理批量任务至关重要。6.1 通过 API 触发工作流发布应用后在应用概览页面找到“访问 API”部分你会看到API 地址和API 密钥。以下是一个使用 Pythonrequests库触发我们刚刚创建的文案审核工作流的示例import requests import json import time # 配置参数 api_url https://your-dify-domain/v1/workflows/run api_key app-你的API密钥 workflow_id 你的工作流ID # 构建请求头 headers { Authorization: fBearer {api_key}, Content-Type: application/json } # 构建请求体 payload { inputs: { “product_desc”: “一款全新的降噪耳机续航50小时支持空间音频。” }, “response_mode”: “blocking”, # 同步等待结果对于有人工介入的通常用异步 # “response_mode”: “streaming”, # 流式响应 “user”: “test_user_001” # 标识终端用户 } # 发送请求同步模式适用于快速完成的流程 response requests.post(api_url, headersheaders, jsonpayload, timeout120) result response.json() print(“同步响应:”, json.dumps(result, indent2, ensure_asciiFalse)) # 如果工作流因人工介入而暂停同步响应会返回一个 task_id 和状态为 “pending” if result.get(“status”) “pending”: task_id result.get(“task_id”) print(f“工作流已暂停等待人工介入。任务ID: {task_id}”) # 此时你需要轮询任务状态或者等待 Webhook 回调推荐6.2 处理异步任务与人工介入对于包含人工介入的工作流使用“response_mode”: “blocking”并设置超时可能不实用因为不知道审核要等多久。更好的方式是使用异步回调Webhook。在 Dify 应用配置中设置 Webhook在应用设置里配置一个用于接收事件通知的 Webhook URL例如https://your-server.com/dify-callback。以异步模式触发工作流调用 API 时使用“response_mode”: “streaming”或直接使用异步任务接口立即获得一个task_id。监听 Webhook 事件你的服务器需要监听 Dify 发送的 Webhook 事件。当工作流到达人工介入节点时Dify 会向你的 Webhook 发送一个事件事件类型可能是workflow.startedworkflow.node.人工介入节点ID.pending等。轮询任务状态备选如果没有配置 Webhook你可以用task_id定期轮询 Dify 的GET /v1/tasks/{task_id}接口检查任务状态是否为completed、failed或pending。人工操作后流程继续审核员在 Dify Web 界面完成操作通过/拒绝后工作流会自动继续执行直至结束。Dify 会发送workflow.completed或workflow.failed的 Webhook 事件到你的服务器其中包含最终输出结果。6.3 批量任务处理对于批量处理大量需要人工审核的任务建议的架构是你的业务系统将待处理任务放入一个队列如 Redis List, RabbitMQ。一个 Worker 进程从队列中取出任务调用 Dify API 触发工作流并记录task_id与业务任务的关联关系。Worker 或另一个服务监听 Dify 的 Webhook。当收到workflow.completed事件时根据task_id找到对应的业务任务将最终结果审核后的文案写回业务数据库并标记该业务任务为完成。如果收到workflow.failed或审核被拒绝则根据策略进行重试或标记为失败。这种设计实现了松耦合能稳定处理高并发的人工审核流水线。7. 资源占用与性能观察“人工介入”功能本身作为一个逻辑控制节点几乎不消耗额外的 CPU、GPU 或内存资源。其性能影响主要体现在工作流执行的整体延迟上。流程延迟主要增加的是“等待时间”即从流程暂停到审核员操作之间的间隔。这属于业务逻辑延迟而非计算资源消耗。数据库与存储每个暂停的审核任务其上下文信息输入、变量、节点状态会保存在 Dify 的数据库中。如果同时有大量任务处于等待审核状态会增加数据库的存储压力和查询负载。需要根据业务量规划数据库性能。网络开销如果审核员通过公网访问 Dify 界面传输的上下文数据尤其是包含长文本或文件时会产生网络流量。观察方法Dify 仪表盘Dify 企业版通常提供监控仪表盘。社区版可以通过查看容器日志 (docker-compose logs -f api) 来观察工作流执行和任务状态转换的日志。数据库监控监控 PostgreSQL 容器的 CPU、内存和连接数。可以使用docker stats命令。应用性能工作流的执行时间不包括人工等待时间主要取决于其中 LLM 或其他计算节点的性能。这部分需要监控你所使用的模型服务如 OpenAI API 的延迟、本地模型的 GPU 利用率。优化建议对于非关键或低风险环节可以设置审核超时并选择“超时自动通过”避免流程无限期阻塞。合理设计审核任务分配避免单个审核员任务过载。定期归档或清理已完成的历史审核任务数据以控制数据库增长。8. 常见问题与排查方法在配置和使用人工介入功能时你可能会遇到以下问题问题现象可能原因排查方式解决方案工作流在人工介入节点后没有暂停直接跳过1. 人工介入节点未正确配置“变量分配”。2. 工作流在“调试”模式而非“发布”模式下运行。3. 节点连线或变量传递错误。1. 检查人工介入节点的配置确保至少分配了一个需要审核的变量。2. 确认你是在运行已发布的版本。3. 在工作流画布中使用“调试”功能单步运行查看每个节点的输入/输出。1. 重新配置变量分配。2. 发布工作流后使用应用访问链接或 API 进行测试。3. 检查节点之间的连接线确保上游节点的输出变量名在下游节点中被正确引用。审核员收不到任务通知1. 通知方式未配置或配置错误。2. 审核员不在指定的指派范围内。3. 系统通知功能未启用。1. 检查 Dify 控制台的通知设置如邮件、Slack、Webhook 集成。2. 确认审核任务指派给了正确的用户或角色。3. 检查审核员账户的“待办任务”列表。1. 正确配置系统通知或第三方集成。2. 调整人工介入节点的“指派”配置。3. 告知审核员定期登录 Dify 查看“工作流待办”任务。API 调用后无法获取最终结果1. 使用了同步阻塞调用但人工介入导致超时。2. Webhook 未正确配置或接收服务器有故障。3. 未正确处理异步任务 ID (task_id)。1. 查看 API 响应如果状态是pending说明流程已暂停。2. 检查 Dify 日志看 Webhook 事件是否成功发送。3. 检查你的回调服务器日志确认收到了workflow.completed事件。1.改用异步模式使用streaming模式或异步任务接口配合 Webhook 或任务状态轮询。2.修复 Webhook确保回调 URL 可公开访问并能正确处理 POST 请求。3.实现状态轮询如果不用 Webhook需定期调用GET /v1/tasks/{task_id}查询结果。审核界面加载慢或内容显示不全1. 分配的审核变量内容非常大如长文档、大图片 Base64。2. 服务器网络或资源瓶颈。1. 检查人工介入节点分配的变量内容大小。2. 通过浏览器开发者工具查看网络请求耗时。1.优化内容避免将过大的原始数据如图片直接作为审核变量。可以考虑传递文件 URL 或摘要。2.升级服务检查服务器资源考虑提升配置或优化数据库查询。条件判断节点无法正确识别审核状态1. 条件判断的条件设置错误。2. 人工介入节点的输出状态变量名引用错误。1. 仔细检查条件判断节点的条件逻辑。2. 在调试模式下查看人工介入节点的输出确认其状态变量的准确名称通常是status。1. 重新配置条件应类似人工介入节点状态等于通过。2. 在条件判断节点中确保从变量选择器里选择人工介入节点输出的status变量而不是手动输入。9. 最佳实践与使用建议为了在生产环境中稳定、高效地使用人工介入功能遵循以下最佳实践最小化审核上下文在人工介入节点中只分配必须由人工查看和修改的变量。避免将整个工作流的所有中间数据都塞进去这能提升审核界面加载速度并减少信息干扰让审核员聚焦关键点。设计清晰的审核指令充分利用人工介入节点的“标题”和“描述”字段为审核员提供明确的背景信息和操作指引。例如“请检查以下客服回复中是否包含了产品退货政策链接”。设置合理的超时与自动处理为审核任务设置超时时间如24小时并配置超时后的默认操作如“自动通过”或“自动拒绝”。这能防止流程因审核员疏忽而永久阻塞同时超时操作的选择应符合业务风险承受度。实现审核负载均衡不要将所有任务都指派给一个人。利用“角色指派”或基于变量的动态指派逻辑将任务均匀分配给一个团队。Dify 企业版的工作队列功能对此有更好支持。将人工介入与版本控制结合Dify 的工作流支持版本管理。当你对包含人工介入的工作流进行修改并发布新版本时旧版本上已暂停的审核任务不会受到影响。这保证了流程变更的平滑性。建立审核 SOP 与培训人工介入的有效性很大程度上取决于审核员。为不同类型的审核任务建立标准操作程序并对审核员进行培训确保审核标准一致。监控与优化定期分析审核任务的耗时、通过/拒绝比例、常见修改点。这些数据可以帮助你优化 AI 提示词减少不必要的审核或者调整介入点将审核资源集中在最有效的环节。安全与合规前置确保审核员拥有访问审核内容所必需的数据权限。如果审核内容涉及用户隐私数据需确保整个流程符合数据安全法规。考虑对审核操作本身进行日志记录以满足审计要求。10. 总结与下一步Dify 1.15 的“人工介入”功能成功地将人的判断力变成了 AI 自动化流程中的一个可编程、可配置的节点。它打破了“全自动”与“全手动”之间的壁垒为构建可靠、可控、合规的 AI 应用提供了核心支撑。最值得尝试的起点就是像本文演示的那样为一个现有的文本生成类应用如文案、摘要、翻译增加一道人工质检工序。你会立即感受到它对输出质量的提升效果以及整个流程可控性的增强。最容易踩的坑主要集中在流程设计和API集成上。务必在画布中仔细检查节点连线与变量传递并通过“调试”功能预先跑通。在集成时果断选择“异步 API Webhook”的模式这是处理人工延迟的标准做法。下一步你可以探索更复杂的模式多级审核串联多个人工介入节点实现“初审-复审”流程。动态指派根据工单类型、内容关键词等变量将任务自动分配给不同的专家团队。与外部系统深度集成当审核通过后自动将结果发布到 CMS、客服系统或企业微信。数据反馈闭环收集人工修改的内容将其作为高质量数据用于后续的模型微调或提示词优化让 AI 越来越“懂”你的要求。将这个功能融入你的 AI 应用蓝图你构建的将不再是简单的对话机器人而是一个真正意义上的、人机协同的智能业务系统。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度
Dify 1.15 人工介入功能详解：构建可控AI工作流的人机协同框架
发布时间：2026/7/5 11:08:38
30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度这次我们来看 Dify 1.15 版本中一个非常关键的功能人工介入。对于任何将 AI 应用投入实际生产或严肃业务流程的团队来说如何确保 AI 输出的质量、可控性和合规性是一个绕不开的挑战。Dify 1.15 引入的“人工介入”机制正是为了解决这个问题。它不是一个简单的“审核”按钮而是一套完整的、可嵌入到自动化流程中的人机协作框架。简单来说这个功能允许你在 AI 应用的工作流中设置一个或多个“检查点”。当流程运行到这些检查点时系统会自动暂停将当前的任务状态、AI 的中间输出或最终结果推送给指定的人工审核员。审核员可以查看、修改、批准或驳回处理完成后流程才会继续向下执行。这确保了关键环节的输出质量同时又不完全打断自动化流程的效率。本文将带你快速上手 Dify 1.15 的“人工介入”功能。我们会重点关注它的核心能力、部署门槛、具体配置步骤并通过一个实际的文本生成与审核场景演示如何从零搭建一个带有人工审核环节的 AI 工作流。无论你是想为客服机器人增加一道质量防线还是为内容生成流程加入合规检查这篇文章都能提供清晰的路径。1. 核心能力速览在深入细节之前我们先通过一个表格快速了解 Dify 1.15 “人工介入”功能的核心规格和适用性。能力项说明功能定位在 Dify 工作流中插入人工审核节点实现人机协同的自动化流程。触发方式支持基于节点输出内容、变量条件等多种方式触发人工介入。审核界面提供专用的 Web 审核面板审核员可查看上下文、修改内容、添加批注。操作动作审核员可执行“通过”、“拒绝”、“修改后通过”等操作。流程控制审核结果决定工作流后续分支继续执行、跳转到指定节点或终止。通知机制支持通过系统内部通知或 Webhook 等方式通知审核员。权限与分配可指定特定成员、角色或通过变量动态分配审核任务。部署方式与 Dify 平台部署方式一致支持 Docker 一键部署、源码部署等。硬件门槛主要取决于 Dify 本身及背后连接的模型服务如 OpenAI API, 本地模型。人工介入功能本身资源消耗极低。适合场景内容安全审核、金融/法律文本生成校对、客服答案质量把控、创意内容最终审定等需要人工确认的 AI 应用场景。2. 适用场景与使用边界“人工介入”功能的核心价值在于将人的判断力无缝嵌入到 AI 自动化流程中。它特别适合以下几类场景内容安全与合规审核AI 生成的营销文案、新闻稿、社交媒体内容在发布前需要经过人工对事实准确性、品牌调性、法律法规符合性进行最终把关。关键业务决策辅助例如由 AI 初步生成的合同条款、投资分析报告、风险评估摘要必须由专业法务或分析师进行复核确认。高质量客服与问答对于复杂或敏感的客户问题AI 提供的初步答案可以先由人工坐席审核修改再发送给客户确保服务质量和专业性。创意内容生产流程AI 生成的广告创意、设计文案、视频脚本等需要创意总监进行最终的艺术性和效果审定。使用边界与注意事项非实时同步人工介入会引入异步等待时间不适合对实时性要求极高的对话场景如秒级响应的聊天。审核负载管理需要合理设计介入点和分配策略避免审核任务堆积成为流程瓶颈。责任界定当人工修改了 AI 输出后最终结果的责任应由“审核通过”的操作者承担。需要在业务流程中明确此规则。隐私与数据安全审核界面会展示流程中的全部上下文信息包括可能的用户输入。需确保审核员有相应的数据访问权限并遵守相关数据安全规定。3. 环境准备与前置条件要使用 Dify 1.15 的人工介入功能你首先需要一个正常运行的 Dify 服务。以下是部署和准备的核心要点。3.1 Dify 平台部署Dify 提供了多种部署方式对于大多数用户推荐使用 Docker Compose 进行一键部署最为方便。操作系统Linux (Ubuntu 20.04/CentOS 7), macOS, 或 Windows (通过 WSL2)。依赖Docker 20.10 和 Docker Compose 2.0。硬件最低 2核 CPU4GB 内存。实际需求取决于你使用的 AI 模型如果使用本地模型则对 GPU 有要求。人工介入功能本身不消耗额外计算资源。网络服务器需要能访问你计划使用的模型 API如 OpenAI, Anthropic 或你自建的本地模型服务。3.2 获取部署文件访问 Dify 的 GitHub 仓库 Release 页面下载最新版本确保 1.15的docker-compose.yaml文件。# 创建一个工作目录并进入 mkdir dify cd dify # 下载 docker-compose 文件 (请替换为最新的版本链接) wget -O docker-compose.yaml https://github.com/langgenius/dify/releases/download/v1.15.0/docker-compose.yaml # 下载环境变量配置文件 wget -O .env https://github.com/langgenius/dify/releases/download/v1.15.0/.env.example3.3 配置关键环境变量编辑.env文件配置数据库、Redis 以及最重要的——模型供应商。# 编辑 .env 文件 nano .env你需要关注并修改以下部分以使用 OpenAI 为例# 数据库配置 DB_PASSWORDyour_secure_db_password # Redis 配置 REDIS_PASSWORDyour_secure_redis_password # OpenAI 配置 (如果你使用 OpenAI) OPENAI_API_KEYsk-your-openai-api-key-here # 或者使用 Azure OpenAI # AZURE_OPENAI_API_KEYyour-azure-key # AZURE_OPENAI_ENDPOINThttps://your-resource.openai.azure.com/如果你计划主要使用本地模型如通过 Ollama、vLLM 或 Transformers 部署则需要额外配置MODEL_PROVIDER等参数并确保 Dify 网络能访问到你的模型服务端点。4. 安装部署与启动方式配置完成后启动服务非常简单。4.1 一键启动服务在包含docker-compose.yaml和.env文件的目录下执行# 启动所有服务 docker-compose up -d这个命令会在后台启动 Dify 所需的所有容器Web 前端、后端 API、数据库、Redis 等。首次启动会拉取镜像并初始化数据库可能需要几分钟。4.2 检查服务状态启动后可以使用以下命令查看容器运行状态docker-compose ps你应该看到所有服务的状态都是 “Up”。也可以通过日志观察启动过程# 查看所有服务的日志 docker-compose logs -f # 仅查看后端服务的日志 docker-compose logs -f api4.3 访问 Web 界面服务启动成功后在浏览器中访问http://你的服务器IP:3000。首次访问需要创建管理员账户。按照界面指引完成初始化设置即可进入 Dify 主控台。至此一个包含完整人工介入功能的 Dify 1.15 平台就准备就绪了。5. 功能测试与效果验证构建一个带人工审核的文案生成工作流现在我们通过一个实际的例子来验证“人工介入”功能。场景是构建一个“社交媒体文案生成器”AI 根据用户输入的产品描述生成文案但发布前必须经过市场部同事的人工审核。5.1 创建应用与工作流在 Dify 控制台点击“创建应用”选择“工作流”类型命名为“社交媒体文案生成与审核”。进入工作流画布编辑器。5.2 编排工作流节点我们将依次添加以下节点开始接收用户输入。LLM调用大模型生成文案。人工介入暂停流程等待审核。条件判断根据审核结果决定流程走向。结束输出最终结果。具体操作如下设置开始节点从左侧拖入“开始”节点。在右侧面板添加一个输入变量例如product_desc产品描述类型为字符串。添加 LLM 节点拖入一个“LLM”节点并将其连接到“开始”节点之后。在节点配置中选择你已配置好的模型如 gpt-4o-mini。在“提示词”区域编写类似以下的指令你是一名专业的社交媒体文案写手。请根据以下产品描述生成一段吸引人的、适合在推特上发布的文案不超过280字符。 产品描述{{product_desc}} 生成的文案在“变量”部分将输出变量名设置为draft_copy草稿文案。添加人工介入节点核心拖入“人工介入”节点连接到 LLM 节点之后。配置介入信息标题设置为“文案审核{{product_desc}}”这样审核员一眼就知道任务内容。描述可以写“请审核并修改以下由 AI 生成的社交媒体文案。”变量分配这里是我们需要审核的内容。点击“添加变量”选择上一步 LLM 节点的输出draft_copy。这意味着审核员将看到并可以修改这个草稿文案。配置操作按钮默认有“通过”和“拒绝”。我们可以保留也可以自定义。例如可以添加一个“修改后通过”的按钮。配置指派可以选择“仅应用创建者”或“指定成员”。在团队协作中你可以指定“市场部”角色的成员。这里为了测试可以先选“仅应用创建者”。超时设置可以设置任务等待审核的最长时间超时后可按预设规则如自动通过或拒绝处理。5.3 添加条件分支与结束节点添加条件判断节点拖入“条件判断”节点连接到“人工介入”节点之后。这个节点会根据人工介入的结果决定流程走向。配置条件分支在条件判断节点的配置中添加分支。第一个分支条件设置为人工介入节点状态等于通过。这意味着如果审核员点击了“通过”。第二个分支条件设置为人工介入节点状态等于拒绝。 如果添加了“修改后通过”也需要相应配置添加结束节点拖入两个“结束”节点。将第一个结束节点连接到“通过”分支将其命名为“审核通过”。在这个结束节点的“答案”区域可以输出最终文案。这里应该输出被审核员确认或修改后的文案。我们需要引用人工介入节点处理后的变量。假设人工介入节点输出的变量名是reviewed_copy则答案可以设置为{{reviewed_copy}}。将第二个结束节点连接到“拒绝”分支将其命名为“审核拒绝”。在答案区域可以设置一个固定回复如“文案未通过审核请重新输入需求或联系市场部。”连接人工介入到条件判断关键一步选中“人工介入”节点你会看到其输出中有一个status变量。确保在连接时这个状态变量能传递到条件判断节点。最终你的工作流应该看起来像一个有分支的管道开始 - LLM - 人工介入 - 条件判断 - (通过/拒绝) - 不同的结束节点。5.4 保存并发布工作流点击右上角“发布”按钮为工作流创建一个版本。发布后你可以获得一个公开的访问链接或 API 端点。6. 接口 API 与批量任务Dify 不仅提供 Web 界面所有功能都可通过 API 驱动这对于集成到现有系统或处理批量任务至关重要。6.1 通过 API 触发工作流发布应用后在应用概览页面找到“访问 API”部分你会看到API 地址和API 密钥。以下是一个使用 Pythonrequests库触发我们刚刚创建的文案审核工作流的示例import requests import json import time # 配置参数 api_url https://your-dify-domain/v1/workflows/run api_key app-你的API密钥 workflow_id 你的工作流ID # 构建请求头 headers { Authorization: fBearer {api_key}, Content-Type: application/json } # 构建请求体 payload { inputs: { “product_desc”: “一款全新的降噪耳机续航50小时支持空间音频。” }, “response_mode”: “blocking”, # 同步等待结果对于有人工介入的通常用异步 # “response_mode”: “streaming”, # 流式响应 “user”: “test_user_001” # 标识终端用户 } # 发送请求同步模式适用于快速完成的流程 response requests.post(api_url, headersheaders, jsonpayload, timeout120) result response.json() print(“同步响应:”, json.dumps(result, indent2, ensure_asciiFalse)) # 如果工作流因人工介入而暂停同步响应会返回一个 task_id 和状态为 “pending” if result.get(“status”) “pending”: task_id result.get(“task_id”) print(f“工作流已暂停等待人工介入。任务ID: {task_id}”) # 此时你需要轮询任务状态或者等待 Webhook 回调推荐6.2 处理异步任务与人工介入对于包含人工介入的工作流使用“response_mode”: “blocking”并设置超时可能不实用因为不知道审核要等多久。更好的方式是使用异步回调Webhook。在 Dify 应用配置中设置 Webhook在应用设置里配置一个用于接收事件通知的 Webhook URL例如https://your-server.com/dify-callback。以异步模式触发工作流调用 API 时使用“response_mode”: “streaming”或直接使用异步任务接口立即获得一个task_id。监听 Webhook 事件你的服务器需要监听 Dify 发送的 Webhook 事件。当工作流到达人工介入节点时Dify 会向你的 Webhook 发送一个事件事件类型可能是workflow.startedworkflow.node.人工介入节点ID.pending等。轮询任务状态备选如果没有配置 Webhook你可以用task_id定期轮询 Dify 的GET /v1/tasks/{task_id}接口检查任务状态是否为completed、failed或pending。人工操作后流程继续审核员在 Dify Web 界面完成操作通过/拒绝后工作流会自动继续执行直至结束。Dify 会发送workflow.completed或workflow.failed的 Webhook 事件到你的服务器其中包含最终输出结果。6.3 批量任务处理对于批量处理大量需要人工审核的任务建议的架构是你的业务系统将待处理任务放入一个队列如 Redis List, RabbitMQ。一个 Worker 进程从队列中取出任务调用 Dify API 触发工作流并记录task_id与业务任务的关联关系。Worker 或另一个服务监听 Dify 的 Webhook。当收到workflow.completed事件时根据task_id找到对应的业务任务将最终结果审核后的文案写回业务数据库并标记该业务任务为完成。如果收到workflow.failed或审核被拒绝则根据策略进行重试或标记为失败。这种设计实现了松耦合能稳定处理高并发的人工审核流水线。7. 资源占用与性能观察“人工介入”功能本身作为一个逻辑控制节点几乎不消耗额外的 CPU、GPU 或内存资源。其性能影响主要体现在工作流执行的整体延迟上。流程延迟主要增加的是“等待时间”即从流程暂停到审核员操作之间的间隔。这属于业务逻辑延迟而非计算资源消耗。数据库与存储每个暂停的审核任务其上下文信息输入、变量、节点状态会保存在 Dify 的数据库中。如果同时有大量任务处于等待审核状态会增加数据库的存储压力和查询负载。需要根据业务量规划数据库性能。网络开销如果审核员通过公网访问 Dify 界面传输的上下文数据尤其是包含长文本或文件时会产生网络流量。观察方法Dify 仪表盘Dify 企业版通常提供监控仪表盘。社区版可以通过查看容器日志 (docker-compose logs -f api) 来观察工作流执行和任务状态转换的日志。数据库监控监控 PostgreSQL 容器的 CPU、内存和连接数。可以使用docker stats命令。应用性能工作流的执行时间不包括人工等待时间主要取决于其中 LLM 或其他计算节点的性能。这部分需要监控你所使用的模型服务如 OpenAI API 的延迟、本地模型的 GPU 利用率。优化建议对于非关键或低风险环节可以设置审核超时并选择“超时自动通过”避免流程无限期阻塞。合理设计审核任务分配避免单个审核员任务过载。定期归档或清理已完成的历史审核任务数据以控制数据库增长。8. 常见问题与排查方法在配置和使用人工介入功能时你可能会遇到以下问题问题现象可能原因排查方式解决方案工作流在人工介入节点后没有暂停直接跳过1. 人工介入节点未正确配置“变量分配”。2. 工作流在“调试”模式而非“发布”模式下运行。3. 节点连线或变量传递错误。1. 检查人工介入节点的配置确保至少分配了一个需要审核的变量。2. 确认你是在运行已发布的版本。3. 在工作流画布中使用“调试”功能单步运行查看每个节点的输入/输出。1. 重新配置变量分配。2. 发布工作流后使用应用访问链接或 API 进行测试。3. 检查节点之间的连接线确保上游节点的输出变量名在下游节点中被正确引用。审核员收不到任务通知1. 通知方式未配置或配置错误。2. 审核员不在指定的指派范围内。3. 系统通知功能未启用。1. 检查 Dify 控制台的通知设置如邮件、Slack、Webhook 集成。2. 确认审核任务指派给了正确的用户或角色。3. 检查审核员账户的“待办任务”列表。1. 正确配置系统通知或第三方集成。2. 调整人工介入节点的“指派”配置。3. 告知审核员定期登录 Dify 查看“工作流待办”任务。API 调用后无法获取最终结果1. 使用了同步阻塞调用但人工介入导致超时。2. Webhook 未正确配置或接收服务器有故障。3. 未正确处理异步任务 ID (task_id)。1. 查看 API 响应如果状态是pending说明流程已暂停。2. 检查 Dify 日志看 Webhook 事件是否成功发送。3. 检查你的回调服务器日志确认收到了workflow.completed事件。1.改用异步模式使用streaming模式或异步任务接口配合 Webhook 或任务状态轮询。2.修复 Webhook确保回调 URL 可公开访问并能正确处理 POST 请求。3.实现状态轮询如果不用 Webhook需定期调用GET /v1/tasks/{task_id}查询结果。审核界面加载慢或内容显示不全1. 分配的审核变量内容非常大如长文档、大图片 Base64。2. 服务器网络或资源瓶颈。1. 检查人工介入节点分配的变量内容大小。2. 通过浏览器开发者工具查看网络请求耗时。1.优化内容避免将过大的原始数据如图片直接作为审核变量。可以考虑传递文件 URL 或摘要。2.升级服务检查服务器资源考虑提升配置或优化数据库查询。条件判断节点无法正确识别审核状态1. 条件判断的条件设置错误。2. 人工介入节点的输出状态变量名引用错误。1. 仔细检查条件判断节点的条件逻辑。2. 在调试模式下查看人工介入节点的输出确认其状态变量的准确名称通常是status。1. 重新配置条件应类似人工介入节点状态等于通过。2. 在条件判断节点中确保从变量选择器里选择人工介入节点输出的status变量而不是手动输入。9. 最佳实践与使用建议为了在生产环境中稳定、高效地使用人工介入功能遵循以下最佳实践最小化审核上下文在人工介入节点中只分配必须由人工查看和修改的变量。避免将整个工作流的所有中间数据都塞进去这能提升审核界面加载速度并减少信息干扰让审核员聚焦关键点。设计清晰的审核指令充分利用人工介入节点的“标题”和“描述”字段为审核员提供明确的背景信息和操作指引。例如“请检查以下客服回复中是否包含了产品退货政策链接”。设置合理的超时与自动处理为审核任务设置超时时间如24小时并配置超时后的默认操作如“自动通过”或“自动拒绝”。这能防止流程因审核员疏忽而永久阻塞同时超时操作的选择应符合业务风险承受度。实现审核负载均衡不要将所有任务都指派给一个人。利用“角色指派”或基于变量的动态指派逻辑将任务均匀分配给一个团队。Dify 企业版的工作队列功能对此有更好支持。将人工介入与版本控制结合Dify 的工作流支持版本管理。当你对包含人工介入的工作流进行修改并发布新版本时旧版本上已暂停的审核任务不会受到影响。这保证了流程变更的平滑性。建立审核 SOP 与培训人工介入的有效性很大程度上取决于审核员。为不同类型的审核任务建立标准操作程序并对审核员进行培训确保审核标准一致。监控与优化定期分析审核任务的耗时、通过/拒绝比例、常见修改点。这些数据可以帮助你优化 AI 提示词减少不必要的审核或者调整介入点将审核资源集中在最有效的环节。安全与合规前置确保审核员拥有访问审核内容所必需的数据权限。如果审核内容涉及用户隐私数据需确保整个流程符合数据安全法规。考虑对审核操作本身进行日志记录以满足审计要求。10. 总结与下一步Dify 1.15 的“人工介入”功能成功地将人的判断力变成了 AI 自动化流程中的一个可编程、可配置的节点。它打破了“全自动”与“全手动”之间的壁垒为构建可靠、可控、合规的 AI 应用提供了核心支撑。最值得尝试的起点就是像本文演示的那样为一个现有的文本生成类应用如文案、摘要、翻译增加一道人工质检工序。你会立即感受到它对输出质量的提升效果以及整个流程可控性的增强。最容易踩的坑主要集中在流程设计和API集成上。务必在画布中仔细检查节点连线与变量传递并通过“调试”功能预先跑通。在集成时果断选择“异步 API Webhook”的模式这是处理人工延迟的标准做法。下一步你可以探索更复杂的模式多级审核串联多个人工介入节点实现“初审-复审”流程。动态指派根据工单类型、内容关键词等变量将任务自动分配给不同的专家团队。与外部系统深度集成当审核通过后自动将结果发布到 CMS、客服系统或企业微信。数据反馈闭环收集人工修改的内容将其作为高质量数据用于后续的模型微调或提示词优化让 AI 越来越“懂”你的要求。将这个功能融入你的 AI 应用蓝图你构建的将不再是简单的对话机器人而是一个真正意义上的、人机协同的智能业务系统。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度
