🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度

这次我们来看 Dify 1.15 版本中一个非常关键的功能：人工介入。对于任何将 AI 应用投入实际生产或严肃业务流程的团队来说，如何确保 AI 输出的质量、可控性和合规性，是一个绕不开的挑战。Dify 1.15 引入的“人工介入”机制，正是为了解决这个问题。它不是一个简单的“审核”按钮，而是一套完整的、可嵌入到自动化流程中的人机协作框架。

简单来说，这个功能允许你在 AI 应用的工作流中，设置一个或多个“检查点”。当流程运行到这些检查点时，系统会自动暂停，将当前的任务状态、AI 的中间输出或最终结果，推送给指定的人工审核员。审核员可以查看、修改、批准或驳回，处理完成后，流程才会继续向下执行。这确保了关键环节的输出质量，同时又不完全打断自动化流程的效率。

本文将带你快速上手 Dify 1.15 的“人工介入”功能。我们会重点关注它的核心能力、部署门槛、具体配置步骤，并通过一个实际的文本生成与审核场景，演示如何从零搭建一个带有人工审核环节的 AI 工作流。无论你是想为客服机器人增加一道质量防线，还是为内容生成流程加入合规检查，这篇文章都能提供清晰的路径。

1. 核心能力速览

在深入细节之前，我们先通过一个表格快速了解 Dify 1.15 “人工介入”功能的核心规格和适用性。

2. 适用场景与使用边界

“人工介入”功能的核心价值在于将人的判断力无缝嵌入到 AI 自动化流程中。它特别适合以下几类场景：

1. 内容安全与合规审核：AI 生成的营销文案、新闻稿、社交媒体内容，在发布前需要经过人工对事实准确性、品牌调性、法律法规符合性进行最终把关。
2. 关键业务决策辅助：例如，由 AI 初步生成的合同条款、投资分析报告、风险评估摘要，必须由专业法务或分析师进行复核确认。
3. 高质量客服与问答：对于复杂或敏感的客户问题，AI 提供的初步答案可以先由人工坐席审核修改，再发送给客户，确保服务质量和专业性。
4. 创意内容生产流程：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核 CPU，4GB 内存。实际需求取决于你使用的 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.example

3.3 配置关键环境变量编辑.env文件，配置数据库、Redis 以及最重要的——模型供应商。

# 编辑 .env 文件 nano .env

你需要关注并修改以下部分（以使用 OpenAI 为例）：

# 数据库配置 DB_PASSWORD=your_secure_db_password # Redis 配置 REDIS_PASSWORD=your_secure_redis_password # OpenAI 配置 (如果你使用 OpenAI) OPENAI_API_KEY=sk-your-openai-api-key-here # 或者使用 Azure OpenAI # AZURE_OPENAI_API_KEY=your-azure-key # AZURE_OPENAI_ENDPOINT=https://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 api

4.3 访问 Web 界面服务启动成功后，在浏览器中访问http://你的服务器IP:3000。首次访问需要创建管理员账户。按照界面指引完成初始化设置，即可进入 Dify 主控台。

至此，一个包含完整人工介入功能的 Dify 1.15 平台就准备就绪了。

5. 功能测试与效果验证：构建一个带人工审核的文案生成工作流

现在，我们通过一个实际的例子来验证“人工介入”功能。场景是：构建一个“社交媒体文案生成器”，AI 根据用户输入的产品描述生成文案，但发布前必须经过市场部同事的人工审核。

5.1 创建应用与工作流

1. 在 Dify 控制台，点击“创建应用”，选择“工作流”类型，命名为“社交媒体文案生成与审核”。
2. 进入工作流画布编辑器。

5.2 编排工作流节点我们将依次添加以下节点：

• 开始：接收用户输入。
• LLM：调用大模型生成文案。
• 人工介入：暂停流程，等待审核。
• 条件判断：根据审核结果决定流程走向。
• 结束：输出最终结果。

具体操作如下：

1. 设置开始节点：从左侧拖入“开始”节点。在右侧面板，添加一个输入变量，例如product_desc（产品描述），类型为字符串。
2. 添加 LLM 节点：
   • 拖入一个“LLM”节点，并将其连接到“开始”节点之后。
   • 在节点配置中，选择你已配置好的模型（如 gpt-4o-mini）。
   • 在“提示词”区域，编写类似以下的指令：

     你是一名专业的社交媒体文案写手。请根据以下产品描述，生成一段吸引人的、适合在推特上发布的文案（不超过280字符）。 产品描述：{{product_desc}} 生成的文案：

   • 在“变量”部分，将输出变量名设置为draft_copy（草稿文案）。
3. 添加人工介入节点（核心）：
   • 拖入“人工介入”节点，连接到 LLM 节点之后。
   • 配置介入信息：
     • 标题：设置为“文案审核：{{product_desc}}”，这样审核员一眼就知道任务内容。
     • 描述：可以写“请审核并修改以下由 AI 生成的社交媒体文案。”
     • 变量分配：这里是我们需要审核的内容。点击“添加变量”，选择上一步 LLM 节点的输出draft_copy。这意味着审核员将看到并可以修改这个草稿文案。
   • 配置操作按钮：默认有“通过”和“拒绝”。我们可以保留，也可以自定义。例如，可以添加一个“修改后通过”的按钮。
   • 配置指派：可以选择“仅应用创建者”或“指定成员”。在团队协作中，你可以指定“市场部”角色的成员。这里为了测试，可以先选“仅应用创建者”。
   • 超时设置：可以设置任务等待审核的最长时间，超时后可按预设规则（如自动通过或拒绝）处理。

5.3 添加条件分支与结束节点

1. 添加条件判断节点：拖入“条件判断”节点，连接到“人工介入”节点之后。这个节点会根据人工介入的结果决定流程走向。
2. 配置条件分支：
   • 在条件判断节点的配置中，添加分支。
   • 第一个分支，条件设置为人工介入节点状态等于通过。这意味着如果审核员点击了“通过”。
   • 第二个分支，条件设置为人工介入节点状态等于拒绝。 （如果添加了“修改后通过”，也需要相应配置）
3. 添加结束节点：
   • 拖入两个“结束”节点。
   • 将第一个结束节点连接到“通过”分支，将其命名为“审核通过”。在这个结束节点的“答案”区域，可以输出最终文案。这里应该输出被审核员确认或修改后的文案。我们需要引用人工介入节点处理后的变量。假设人工介入节点输出的变量名是reviewed_copy，则答案可以设置为{{reviewed_copy}}。
   • 将第二个结束节点连接到“拒绝”分支，将其命名为“审核拒绝”。在答案区域可以设置一个固定回复，如“文案未通过审核，请重新输入需求或联系市场部。”
4. 连接人工介入到条件判断：关键一步！选中“人工介入”节点，你会看到其输出中有一个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": f"Bearer {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, headers=headers, json=payload, timeout=120) result = response.json() print(“同步响应:”, json.dumps(result, indent=2, ensure_ascii=False)) # 如果工作流因人工介入而暂停，同步响应会返回一个 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）。

1. 在 Dify 应用配置中设置 Webhook：在应用设置里，配置一个用于接收事件通知的 Webhook URL（例如https://your-server.com/dify-callback）。
2. 以异步模式触发工作流：调用 API 时，使用“response_mode”: “streaming”或直接使用异步任务接口，立即获得一个task_id。
3. 监听 Webhook 事件：你的服务器需要监听 Dify 发送的 Webhook 事件。当工作流到达人工介入节点时，Dify 会向你的 Webhook 发送一个事件，事件类型可能是workflow.started，workflow.node.人工介入节点ID.pending等。
4. 轮询任务状态（备选）：如果没有配置 Webhook，你可以用task_id定期轮询 Dify 的GET /v1/tasks/{task_id}接口，检查任务状态是否为completed、failed或pending。
5. 人工操作后流程继续：审核员在 Dify Web 界面完成操作（通过/拒绝）后，工作流会自动继续执行，直至结束。Dify 会发送workflow.completed或workflow.failed的 Webhook 事件到你的服务器，其中包含最终输出结果。

6.3 批量任务处理对于批量处理大量需要人工审核的任务，建议的架构是：

1. 你的业务系统将待处理任务放入一个队列（如 Redis List, RabbitMQ）。
2. 一个 Worker 进程从队列中取出任务，调用 Dify API 触发工作流，并记录task_id与业务任务的关联关系。
3. Worker 或另一个服务监听 Dify 的 Webhook。
4. 当收到workflow.completed事件时，根据task_id找到对应的业务任务，将最终结果（审核后的文案）写回业务数据库，并标记该业务任务为完成。
5. 如果收到workflow.failed或审核被拒绝，则根据策略进行重试或标记为失败。

这种设计实现了松耦合，能稳定处理高并发的人工审核流水线。

7. 资源占用与性能观察

“人工介入”功能本身作为一个逻辑控制节点，几乎不消耗额外的 CPU、GPU 或内存资源。其性能影响主要体现在工作流执行的整体延迟上。

• 流程延迟：主要增加的是“等待时间”，即从流程暂停到审核员操作之间的间隔。这属于业务逻辑延迟，而非计算资源消耗。
• 数据库与存储：每个暂停的审核任务，其上下文信息（输入、变量、节点状态）会保存在 Dify 的数据库中。如果同时有大量任务处于等待审核状态，会增加数据库的存储压力和查询负载。需要根据业务量规划数据库性能。
• 网络开销：如果审核员通过公网访问 Dify 界面，传输的上下文数据（尤其是包含长文本或文件时）会产生网络流量。
• 观察方法：
  • Dify 仪表盘：Dify 企业版通常提供监控仪表盘。社区版可以通过查看容器日志 (docker-compose logs -f api) 来观察工作流执行和任务状态转换的日志。
  • 数据库监控：监控 PostgreSQL 容器的 CPU、内存和连接数。可以使用docker stats命令。
  • 应用性能：工作流的执行时间（不包括人工等待时间）主要取决于其中 LLM 或其他计算节点的性能。这部分需要监控你所使用的模型服务（如 OpenAI API 的延迟、本地模型的 GPU 利用率）。

优化建议：

• 对于非关键或低风险环节，可以设置审核超时，并选择“超时自动通过”，避免流程无限期阻塞。
• 合理设计审核任务分配，避免单个审核员任务过载。
• 定期归档或清理已完成的历史审核任务数据，以控制数据库增长。

8. 常见问题与排查方法

在配置和使用人工介入功能时，你可能会遇到以下问题：

9. 最佳实践与使用建议

为了在生产环境中稳定、高效地使用人工介入功能，遵循以下最佳实践：

1. 最小化审核上下文：在人工介入节点中，只分配必须由人工查看和修改的变量。避免将整个工作流的所有中间数据都塞进去，这能提升审核界面加载速度，并减少信息干扰，让审核员聚焦关键点。
2. 设计清晰的审核指令：充分利用人工介入节点的“标题”和“描述”字段，为审核员提供明确的背景信息和操作指引。例如，“请检查以下客服回复中是否包含了产品退货政策链接”。
3. 设置合理的超时与自动处理：为审核任务设置超时时间（如24小时），并配置超时后的默认操作（如“自动通过”或“自动拒绝”）。这能防止流程因审核员疏忽而永久阻塞，同时超时操作的选择应符合业务风险承受度。
4. 实现审核负载均衡：不要将所有任务都指派给一个人。利用“角色指派”或基于变量的动态指派逻辑，将任务均匀分配给一个团队。Dify 企业版的工作队列功能对此有更好支持。
5. 将人工介入与版本控制结合：Dify 的工作流支持版本管理。当你对包含人工介入的工作流进行修改并发布新版本时，旧版本上已暂停的审核任务不会受到影响。这保证了流程变更的平滑性。
6. 建立审核 SOP 与培训：人工介入的有效性很大程度上取决于审核员。为不同类型的审核任务建立标准操作程序，并对审核员进行培训，确保审核标准一致。
7. 监控与优化：定期分析审核任务的耗时、通过/拒绝比例、常见修改点。这些数据可以帮助你优化 AI 提示词，减少不必要的审核，或者调整介入点，将审核资源集中在最有效的环节。
8. 安全与合规前置：确保审核员拥有访问审核内容所必需的数据权限。如果审核内容涉及用户隐私数据，需确保整个流程符合数据安全法规。考虑对审核操作本身进行日志记录，以满足审计要求。

10. 总结与下一步

Dify 1.15 的“人工介入”功能，成功地将人的判断力变成了 AI 自动化流程中的一个可编程、可配置的节点。它打破了“全自动”与“全手动”之间的壁垒，为构建可靠、可控、合规的 AI 应用提供了核心支撑。

最值得尝试的起点，就是像本文演示的那样，为一个现有的文本生成类应用（如文案、摘要、翻译）增加一道人工质检工序。你会立即感受到它对输出质量的提升效果，以及整个流程可控性的增强。

最容易踩的坑主要集中在流程设计和API集成上。务必在画布中仔细检查节点连线与变量传递，并通过“调试”功能预先跑通。在集成时，果断选择“异步 API + Webhook”的模式，这是处理人工延迟的标准做法。

下一步，你可以探索更复杂的模式：

• 多级审核：串联多个人工介入节点，实现“初审-复审”流程。
• 动态指派：根据工单类型、内容关键词等变量，将任务自动分配给不同的专家团队。
• 与外部系统深度集成：当审核通过后，自动将结果发布到 CMS、客服系统或企业微信。
• 数据反馈闭环：收集人工修改的内容，将其作为高质量数据，用于后续的模型微调或提示词优化，让 AI 越来越“懂”你的要求。

将这个功能融入你的 AI 应用蓝图，你构建的将不再是简单的对话机器人，而是一个真正意义上的、人机协同的智能业务系统。

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度