Dify 1.15版本引入的“人工介入”功能，是构建高可靠性、高可控性AI应用流程的关键一步。它不再让AI工作流成为一个完全封闭的“黑盒”，而是允许你在关键节点暂停，由真人进行审核、修改或补充信息，再将结果交还给流程继续执行。这对于内容审核、数据校验、复杂决策等需要人类判断的场景至关重要。简单来说，它让AI从“全自动执行者”变成了“可被监督和修正的智能助手”。

这篇文章将聚焦于Dify 1.15的“人工介入”功能，带你从零开始理解其核心价值，并完成一个完整的实操演练。我们会先快速了解这个功能能做什么、解决什么问题，然后一步步搭建环境、创建工作流、配置人工介入节点，最后通过一个模拟的“内容审核与优化”场景来验证整个流程。无论你是想为你的AI应用增加一层安全阀，还是希望构建人机协作的混合智能流程，这篇文章都能提供直接的落地指导。

1. 核心能力速览

在深入细节之前，我们先通过一个表格快速把握Dify 1.15“人工介入”功能的核心要点：

2. 适用场景与使用边界

“人工介入”功能听起来很强大，但它并非所有工作流的必需品。理解其适用场景和边界，能帮助你更有效地设计流程。

最适合的使用场景：

1. 质量把关与风险控制：这是最核心的应用。例如，一个自动生成营销文案的AI应用，可以在最终发布前插入人工审核节点，确保文案符合品牌调性、无事实错误或敏感信息。这相当于为AI流程安装了一个“紧急制动”和“质量检查站”。
2. 处理AI不擅长的模糊任务：当任务需要基于非结构化信息、个人偏好或复杂伦理进行判断时，AI可能力不从心。例如，“从这封客户投诉邮件中判断客户的情绪等级并选择最合适的处理模板”，AI可以初步分析，但最终分类可以由人工确认。
3. 注入外部知识或实时信息：工作流运行到一半，可能需要查询一个外部数据库或获取一个实时更新的参数（如当前股价、天气），这些信息可以由人工输入，作为后续AI推理的新依据。
4. 复杂任务的人机协同分解：AI可以处理标准化部分，将难以自动化的子任务抛给人类。例如，一个数据分析流程，AI完成数据清洗和初步图表生成，但图表类型的最终选择和重点标注可以由人工决定。

需要谨慎考虑或可能不适用的场景：

1. 追求完全自动化与高频执行：如果你的目标是7x24小时全自动处理海量任务（如日志监控告警），频繁的人工介入会成为瓶颈，降低效率。此时应优先优化AI模型的准确性或设计更鲁棒的自动规则。
2. 流程逻辑极其简单：如果工作流只是一个简单的问答或文本转换，没有关键决策点，增加人工介入只会画蛇添足。
3. 介入点设计不当：如果人工介入的提示不清晰，需要处理的信息过于庞杂，或者等待时间过长，会导致用户体验下降和流程阻塞。设计时需确保介入请求是明确、简洁且必要的。

合规与安全边界提醒：

• 隐私数据：如果人工介入节点需要查看或处理用户个人信息、商业秘密等敏感数据，必须确保操作界面有足够的权限控制和审计日志。
• 责任界定：当AI建议与人工决策结合时，需明确最终输出结果的责任归属。在涉及法律、医疗、金融等严肃领域，人工介入不能完全免除系统设计者的责任。
• 流程超时与异常处理：必须为人工介入节点设置超时机制（如等待24小时无响应则自动跳过或转给其他处理人），并设计异常处理分支，避免整个流程永久挂起。

3. 环境准备与前置条件

要实操Dify的“人工介入”功能，你首先需要一个运行中的Dify环境。以下是部署Dify的通用前置条件，我们将以最常见的Docker部署方式为例。

基础环境要求：

• 操作系统：Linux (Ubuntu 20.04+/CentOS 7+), macOS, 或 Windows 10/11 (需安装WSL2或Docker Desktop)。
• Docker与Docker Compose：这是最推荐的部署方式。确保已安装最新稳定版的Docker Engine和Docker Compose插件。
  • 检查命令：docker --version和docker compose version。
• 硬件资源：
  • CPU：2核以上。
  • 内存：至少4GB，建议8GB以上。
  • 磁盘空间：至少10GB可用空间，用于存放Dify镜像、数据库和日志。
• 网络：能够访问Docker Hub拉取镜像。如果需要使用OpenAI、Anthropic等在线模型，需确保网络能访问其API。

关键概念准备：在开始前，请确保你理解Dify中的几个核心概念，这对后续配置工作流至关重要：

1. 模型供应商（Model Provider）：你需要至少配置一个可用的LLM。可以是云服务（如OpenAI GPT-4， Anthropic Claude），也可以是本地部署的模型（通过Ollama、LocalAI等接入）。
2. 应用（Application）：在Dify中创建的AI服务单元，可以是聊天助手、工作流等。
3. 工作流（Workflow）：通过拖拽节点构建的可视化AI处理流水线。
4. 变量（Variable）：在工作流中传递数据的载体，可以在节点间引用和赋值。

本次实操的假设环境：为了演示的通用性，我们假设你已经通过Docker成功部署了Dify，并且已经配置好了一个可用的模型供应商（例如OpenAI GPT-3.5-Turbo或通过Ollama连接的本地模型如Qwen2.5-7B）。我们将专注于“人工介入”功能本身在工作流中的配置和使用。

4. 安装部署与启动方式

如果你还没有Dify环境，请按照以下步骤通过Docker Compose快速搭建一个。这是官方推荐且最不易出错的方式。

步骤一：获取部署文件在你的服务器或本地电脑上，创建一个专用目录（如dify），并进入该目录。

mkdir dify && cd dify

从Dify的GitHub仓库下载最新的docker-compose.yaml配置文件。你可以使用curl或wget命令。

# 使用 curl curl -O https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml # 或者使用 wget wget https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml

步骤二：启动Dify服务在包含docker-compose.yaml文件的目录下，执行以下命令启动所有服务（包括Web前端、后端API、数据库等）。

docker compose up -d

这个命令会在后台拉取所需的Docker镜像并启动容器。首次执行可能需要几分钟时间下载镜像。

步骤三：检查服务状态与访问使用以下命令查看容器是否正常运行：

docker compose ps

你应该看到dify-api和dify-web等容器的状态为Up。启动完成后，在浏览器中访问http://你的服务器IP:3000（如果在本机，则是http://localhost:3000）。

首次访问会进入初始化页面，你需要：

1. 设置管理员账号和密码。
2. 进入后台，在“设置” -> “模型供应商”中，添加并配置你的LLM。例如，添加OpenAI供应商，并填入你的API密钥；或者添加Ollama，配置本地模型地址（如http://host.docker.internal:11434如果Ollama运行在宿主机）。

步骤四：验证基础功能创建一个简单的“对话型”应用，输入测试问题，看是否能正常收到AI回复。这确保了你的Dify基础和LLM连接是正常的，为后续构建复杂工作流扫清障碍。

至此，你的Dify平台已经就绪。接下来，我们将进入核心环节——创建带有人工介入功能的工作流。

5. 功能测试与效果验证：构建一个内容审核工作流

我们将构建一个模拟的“博客文章草稿生成与审核”工作流。流程如下：用户输入一个主题 -> AI生成一篇博客草稿 -> 触发人工介入进行审核 -> 人工可以选择“通过”、“驳回”或“修改” -> 根据人工选择，流程走向不同分支（如直接发布、重新生成或进入编辑状态）。

5.1 创建新工作流应用

1. 登录Dify，点击顶部导航栏的“创建应用”。
2. 选择“工作流”类型，为应用命名，例如“博客助手-带人工审核”。
3. 点击进入新创建的应用，你会看到空白的画布。

5.2 拖拽并配置节点

我们将依次添加以下节点并连线：

• 开始节点：接收用户输入的主题。
• LLM节点：根据主题生成博客草稿。
• 人工介入节点：展示草稿，等待人工审核。
• 条件判断节点：根据人工选择的结果判断流程走向。
• LLM节点（重生成）：如果被驳回，则根据反馈重新生成。
• 代码节点/文本输出节点：模拟“发布”或“输出最终稿”动作。

具体配置步骤：

第一步：设置开始节点和变量

1. 从左侧节点库拖拽“开始”节点到画布。
2. 在开始节点的配置面板，我们定义一个用户输入变量。点击“变量”选项卡，添加一个变量。
   • 变量名：topic
   • 类型：Text
   • 描述：博客主题
   • 必填：勾选
3. 这样，工作流启动时就会要求用户输入topic。

第二步：配置LLM生成节点

1. 拖拽一个“LLM”节点到画布，将其连接到“开始”节点之后。
2. 在LLM节点配置中：
   • 选择模型供应商和模型（如 gpt-3.5-turbo）。
   • 系统提示词：你是一位专业的科技博客作者。请根据用户提供的主题，撰写一篇结构清晰、内容详实的博客文章草稿。文章应包含引言、主体内容和结论。
   • 上下文变量：在提示词中，通过{{#context.topic#}}引用上一步的用户输入。
   • 输出变量名：设置为draft。这个变量将保存AI生成的草稿文本。

第三步：核心——配置人工介入节点

1. 拖拽“工具”分类下的“人工介入”节点到画布，连接到LLM节点之后。
2. 这是最关键的一步。在该节点的配置面板中：
   • 标题：审核博客草稿
   • 描述：请审阅AI生成的博客草稿，并做出决定。
   • 输入表单配置：这里我们设计一个表单，让审核者操作。
     • 点击“添加表单字段”。
     • 字段类型：选择Textarea。标签设为“草稿内容”。变量名设为review_draft。在“默认值”中，填入{{draft}}。这样就把上一步生成的草稿自动填充到待审核区域了。勾选“只读”，因为审核者通常不应直接在此修改长文本。
     • 再次点击“添加表单字段”。
     • 字段类型：选择Select。标签设为“审核决定”。变量名设为review_decision。选项添加三项：通过、驳回、需修改。这是审核者的决策输入。
     • 第三次点击“添加表单字段”。
     • 字段类型：选择Textarea。标签设为“修改意见或反馈（选填）”。变量名设为review_feedback。必填：不勾选。当选择“驳回”或“需修改”时，审核者可在此填写具体意见。
   • 超时设置：建议设置一个超时时间（如30分钟），并选择超时后的处理方式（如“继续并使用默认值”），避免流程永久卡住。

第四步：配置条件判断节点

1. 拖拽“逻辑”分类下的“IF/ELSE”节点到画布，连接到人工介入节点之后。
2. 在条件节点配置中，我们需要根据review_decision的值来分支。
   • 点击“添加条件分支”。
   • 条件1：review_decision等于通过。当审核者选择“通过”时，走这个分支。
   • 条件2：review_decision等于驳回。当审核者选择“驳回”时，走这个分支。
   • 条件3：review_decision等于需修改。当审核者选择“需修改”时，走这个分支。
   • （可选）可以添加一个“否则”分支来处理未匹配的情况。

第五步：配置不同分支的处理

• “通过”分支：直接连接到一个“结束”节点或一个“文本输出”节点，将draft作为最终结果输出。
• “驳回”分支：
  1. 连接一个新的“LLM”节点。
  2. 配置其系统提示词为：用户对之前生成的博客草稿不满意并驳回了它。驳回意见是：{{review_feedback}}。请根据原始主题“{{topic}}”和驳回意见，重新生成一篇全新的、更好的博客草稿。
  3. 输出变量名可设为revised_draft。
  4. 将此LLM节点连接回人工介入节点之前（或者连接到一个新的、简化的人工介入节点进行二次确认），或者直接连接到最终的输出节点。为了简化，我们可以让它直接输出。
• “需修改”分支：
  1. 连接另一个“LLM”节点。
  2. 配置其系统提示词为：这是一篇博客草稿：{{draft}}。审核者提出了修改意见：{{review_feedback}}。请根据这些意见，在原稿基础上进行修改和完善，输出修改后的版本。
  3. 输出变量名设为modified_draft。
  4. 同样，将其连接到输出节点。

第六步：设置输出与结束为每个最终分支连接一个“结束”节点，并在结束节点的配置中，选择要返回给用户的结果变量（如draft,revised_draft,modified_draft）。

5.3 运行测试与效果验证

1. 保存工作流：点击画布右上角的“保存”。
2. 发布应用：点击“发布”，创建一个版本。
3. 进入聊天界面测试：在应用概览页点击“体验地址”或“访问应用”。
4. 模拟流程：
   • 第一步：在聊天框输入主题，如“人工智能在医疗诊断中的应用”。
   • 第二步：AI会生成草稿，然后流程自动暂停。聊天界面会变成一个表单，显示“审核博客草稿”的标题，里面包含了只读的草稿内容、一个下拉选择框（审核决定）和一个文本框（修改意见）。
   • 第三步：你作为“人工”，选择“需修改”，并在意见框输入“请增加一些具体的落地案例。”
   • 第四步：点击“提交”。工作流继续，LLM根据你的意见修改草稿。
   • 第五步：最终，聊天界面会输出修改后的博客内容。

成功标准：

• 工作流能顺利从开始执行到人工介入节点并正确暂停。
• 前端能正确渲染出配置的表单，且预填了草稿内容。
• 人工提交后，工作流能根据选择走向正确的分支（通过、驳回、修改）。
• 最终输出的内容符合分支逻辑（例如，选择“修改”后，输出的内容确实包含了关于“案例”的补充）。

6. 接口API与批量任务

“人工介入”功能不仅可以通过Web界面交互，也完全支持通过API集成到你的自有系统或自动化脚本中，这对于构建企业级应用至关重要。

6.1 人工介入节点的API交互流程

当工作流运行到人工介入节点时，对于API调用者来说，流程会“暂停”并返回一个特殊状态。你需要通过额外的API调用来“推进”它。

典型调用序列：

1. 发起工作流执行：使用常规的“发送消息”API接口启动工作流。

   curl -X POST https://your-dify-domain/v1/workflows/run \ -H "Authorization: Bearer your-api-key" \ -H "Content-Type: application/json" \ -d '{ "inputs": {"topic": "人工智能在医疗诊断中的应用"}, "response_mode": "blocking", // 或 streaming "user": "user-123" }'

2. 处理“等待中”响应：如果响应中返回的status是waiting_for_response或类似状态，并且包含一个task_id和node_id，说明流程在人工介入节点暂停了。
3. 获取待办任务列表：系统可能需要提供一个接口来查询所有等待人工处理的任务。Dify可能会提供这样的接口，或者你需要根据返回的task_id和node_id来构造后续操作。
4. 提交人工响应：调用特定接口，提交人工处理的结果。

   curl -X POST https://your-dify-domain/v1/workflows/tasks/{task_id}/respond \ -H "Authorization: Bearer your-api-key" \ -H "Content-Type: application/json" \ -d '{ "node_id": "human_node_1", "response": { "review_decision": "需修改", "review_feedback": "请增加一些具体的落地案例。" } }'

5. 继续工作流：提交响应后，工作流会自动从该节点继续执行，直至结束。你可以通过轮询或Webhook来获取最终结果。

注意：具体的API端点、参数和响应格式请务必查阅你所使用的Dify版本的官方API文档。上述代码仅为示意流程。

6.2 批量任务处理考量

对于需要人工介入的批量任务（如批量审核1000篇文章），设计时需注意：

• 任务队列：需要外部系统（如Celery、RabbitMQ）或数据库来管理任务队列，记录每个任务的状态（待处理、处理中、已完成、已超时）。
• 任务分配：设计机制将等待人工介入的任务分配给合适的处理人员（如通过一个独立的任务管理后台）。
• 超时与重试：为每个任务设置合理的超时时间。超时后，可将任务重新放入队列或转给其他处理人，也可以配置默认操作（如自动“通过”或“驳回”）。
• 上下文存储：在等待人工介入期间，工作流的完整上下文（包括之前的变量）需要被持久化存储，以便恢复。Dify的工作流引擎通常会处理这一点。

7. 资源占用与性能观察

“人工介入”功能本身几乎不消耗额外的计算资源，其性能影响主要来自两方面：工作流引擎的状态保持和人工响应等待时间。

资源占用分析：

1. 内存与CPU：当一个工作流实例在人工介入节点暂停时，Dify后端需要将该实例的上下文（变量、状态）保存在内存或数据库中。对于大量并发暂停的实例，这会增加内存或数据库的压力。但通常这部分开销远小于LLM推理本身。
2. 数据库连接：如果使用数据库持久化工作流状态，频繁的“暂停-恢复”操作会增加数据库的读写负载。
3. 网络与前端：无额外影响。

性能观察要点：

• 工作流状态持久化：检查Dify的日志和数据库监控，确保在人工介入期间没有因状态保存失败而导致的工作流丢失。
• API响应延迟：在人工提交响应后，工作流恢复执行到返回最终结果的时间，应与普通工作流执行时间相近。如果明显变长，需检查队列或资源瓶颈。
• 会话超时：关注前端会话是否会在人工思考期间超时。需要确保Dify的会话管理机制与人工介入的超时设置协调，避免用户填写到一半时页面失效。

优化建议：

• 合理设置超时时间：根据业务场景设置人工介入节点的超时时间，避免资源被无限期占用。
• 异步处理：对于非实时性要求高的场景，可以考虑使用异步API调用模式（response_mode: streaming或回调），让系统在人工完成后通知用户，而不是同步阻塞等待。
• 状态存储后端：如果部署规模大，确保为Dify配置性能良好的数据库（如PostgreSQL）并做好优化。

8. 常见问题与排查方法

在配置和使用“人工介入”功能时，你可能会遇到以下典型问题。

9. 最佳实践与使用建议

为了让“人工介入”功能在真实项目中稳定、高效地运行，遵循以下最佳实践至关重要。

1. 介入点设计要精准且必要：

   • 黄金法则：只在真正需要人类智慧、判断或责任承担的地方插入人工节点。避免过度使用导致流程繁琐。
   • 明确提示：在人工介入节点的“描述”和表单“标签”中，用清晰、无歧义的语言告诉操作者需要做什么、提供什么信息、依据什么标准做判断。

2. 表单设计追求用户体验：

   • 简化输入：尽量使用下拉选择（Select）、单选按钮（Radio）、开关（Switch）代替开放的文本输入，减少操作负担和错误。
   • 提供上下文：利用“只读”的文本字段或富文本展示，将AI生成的内容、之前步骤的关键信息清晰地呈现给审核者，辅助其决策。
   • 设置合理默认值：对于非关键选项，可以预设一个安全或常见的默认值，加速处理。

3. 变量命名与数据流管理：

   • 命名规范：为工作流中的所有变量建立清晰的命名规范（如input_xxx,ai_xxx,human_xxx,output_xxx），并在节点配置中保持一致。
   • 数据预览：在构建复杂工作流时，善用Dify的“调试”功能，运行到每一步查看变量的实际值，确保数据在人工介入前后正确传递。

4. 异常处理与流程健壮性：

   • 设置超时：务必为每个人工介入节点设置超时，并规划超时后的流程（继续、终止或转交）。
   • 设计回退分支：在条件判断节点，除了计划内的分支，始终考虑“其他”或“异常”情况，并连接到相应的处理逻辑（如记录日志、发送通知、跳转到人工客服入口）。

5. 安全与权限隔离：

   • 权限控制：如果不同的人工介入任务涉及不同密级的数据，确保你的Dify用户权限体系或集成的外部系统能实现任务与操作者的精确匹配。
   • 审计日志：确保所有人工介入的操作（谁、在何时、对哪个任务、做出了什么决定）都被完整记录，满足合规和复盘需求。

6. 性能与可扩展性规划：

   • 评估负载：预估人工介入任务的平均处理时间和峰值并发量，确保你的任务分配系统和人员配置能承受。
   • 考虑异步：对于耗时较长的人工任务，采用异步工作流调用和回调通知机制，避免阻塞前端请求。

10. 总结与下一步

Dify 1.15的“人工介入”功能，成功地将人的判断力无缝嵌入到自动化AI流程中，实现了从“全自动”到“人机协同”的关键跨越。通过本次实操，你应该已经掌握了从零构建一个带有人工审核环节工作流的全流程：环境部署、节点拖拽、变量传递、条件分支以及最终的测试验证。

这个功能最值得尝试的点在于，它用极低的代码成本，解决了AI应用落地中最令人头疼的“可控性”和“可靠性”问题。你最先应该验证的，就是将它应用到你当前项目中那个最需要“把关”的环节。

最容易踩的坑主要集中在变量传递的准确性和条件分支的逻辑严密性上。务必在构建工作流时，多用调试模式逐步运行，检查每一个节点的输入输出是否符合预期。

接下来，你可以探索更高级的用法：

• 多级审核：串联多个人工介入节点，实现“初审-复审”的流程。
• 动态指派：结合外部系统，根据任务内容或负载，将人工介入任务动态分配给不同的处理人或小组。
• 与知识库结合：在人工介入节点，为审核者提供来自知识库的参考文档或标准条款，辅助其决策。
• 复杂表单与文件上传：探索人工介入节点是否支持更复杂的表单组件，如图片上传、表格填写等，以处理更丰富的交互场景。

将“人工介入”作为你AI工作流中的战略控制点，不仅能提升输出质量，更能构建出更负责任、更可信赖的AI应用。建议收藏本文，在设计和调试你的第一个人机协同流程时，随时回头查阅各个配置细节和排错指南。