企业官网建设流程全解析

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

如果你正在用 Dify 构建复杂的 AI 工作流，是否遇到过这样的困扰：AI 生成的文本、代码或决策，总感觉差那么一点意思，需要你手动介入修改，但又不想打断整个自动化流程？Dify 1.15 版本带来的“人工介入”功能，就是为了解决这个痛点而生的。这个由 LangGenius 团队开源的 AI 应用开发平台，在最新的 1.15 版本中，将“人机协同”提升到了一个新高度，让你能在工作流的任意节点暂停，由人类进行审核、修改或补充，然后再无缝地交还给 AI 继续执行。

简单来说，Dify 1.15 的“人工介入”功能，让你从一个纯粹的流程“旁观者”或“事后校对者”，变成了流程的“实时参与者”。它不再是简单的“审批通过/拒绝”，而是允许你在流程中直接编辑、修正 AI 的中间产物，确保最终输出的质量完全符合你的预期。这对于内容审核、代码生成、数据分析、合同起草等对准确性要求极高的场景，价值巨大。

这篇文章，我们就来深入实操 Dify 1.15 的“人工介入”功能。我会带你从零开始，部署一个支持此功能的 Dify 环境，然后通过构建一个“智能内容创作与审核”工作流，完整演示如何配置人工介入节点、如何在实际运行中触发人工审核、以及如何与外部系统（如钉钉/飞书）集成实现通知。无论你是想提升现有 AI 应用的输出质量，还是探索更灵活的人机协作模式，这个功能都值得你立刻尝试。

1. 核心能力速览

在深入细节之前，我们先通过一个表格快速了解 Dify 1.15 “人工介入”功能的核心特性与部署要求，让你判断它是否适合你的技术栈和场景。

2. 适用场景与使用边界

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

最适合的使用场景：

1. 质量门控（Quality Gate）：在内容发布、代码合并、报告生成前，设置一个必须由人类通过的检查点。例如，AI 生成一篇产品介绍后，必须由市场专员审核并微调语气后才能发布到官网。
2. 复杂决策辅助：当工作流需要基于模糊或非结构化信息做出选择时。例如，AI 分析客户邮件情绪并生成几种可能的回复草稿，由客服代表选择最合适的一条并微调后发送。
3. 数据验证与修正：AI 从文档中提取的字段（如金额、日期、公司名）可能存在识别误差，人工介入节点可以让人快速核对并修正。
4. 创造性补充：AI 可以生成大纲、初稿或基础设计，但需要人类注入独特的创意、风格或深度见解。例如，AI 生成广告标语选项，由创意总监选择并优化。

需要谨慎使用或不适用的场景：

1. 完全自动化的高频任务：对于每天运行成千上万次、且容错率较高的任务（如简单的数据清洗、标签生成），加入人工介入会严重拖慢效率，得不偿失。
2. 实时性要求极高的流程：如实时聊天机器人、高频交易系统，人工介入的延迟是不可接受的。
3. 缺乏明确审核标准：如果审核者自己也没有清晰的判断标准，那么人工介入就变成了随意的主观修改，无法保证输出质量的提升，反而可能引入不一致性。

合规与安全边界：

• 权限控制：Dify 的企业版提供了更细粒度的权限管理（如设定特定节点只能由特定角色或用户组处理）。社区版需自行通过业务逻辑或外部系统实现权限隔离。
• 数据隐私：人工介入时，审核者会看到工作流的中间数据。务必确保这些数据不包含敏感信息（如个人身份证号、银行账户），或已进行脱敏处理。如果涉及用户隐私数据，需确保审核流程符合相关法律法规。
• 操作审计：所有人工介入的操作（谁、在什么时间、修改了什么）都应被记录和审计。Dify 的工作流运行日志和人工任务记录是重要的审计依据。

3. 环境准备与前置条件

为了完整体验 Dify 1.15 的“人工介入”功能，我们需要搭建一个本地测试环境。以下是详细的准备工作。

1. 操作系统：

• 推荐：Linux (Ubuntu 20.04/22.04 LTS, CentOS 7/8) 或 macOS。
• 支持：Windows 10/11 (需安装 WSL 2 或 Docker Desktop)。本文演示基于Ubuntu 22.04 LTS。

2. 基础软件依赖：

• Docker 与 Docker Compose：这是最推荐、最简便的部署方式。
  • Docker Engine 版本 >= 20.10
  • Docker Compose 版本 >= 1.28.0
  • 安装命令参考（Ubuntu）：

    # 卸载旧版本 sudo apt-get remove docker docker-engine docker.io containerd runc # 设置仓库 sudo apt-get update sudo apt-get install ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg echo \ "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 安装 Docker sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 验证安装 sudo docker run hello-world

• Git：用于克隆代码仓库（可选，可直接下载压缩包）。

  sudo apt-get install git

3. 硬件与网络：

• CPU & 内存：建议至少 2 核 CPU，4 GB 内存。如果计划在本地同时运行大语言模型（如通过 Ollama），则需要更多资源。
• 磁盘空间：至少 10 GB 可用空间，用于存放 Docker 镜像和数据库。
• 网络：需要能正常访问互联网，以下载 Docker 镜像和可能的模型文件。如果需要连接 OpenAI、Azure OpenAI 等云端 AI 服务，需确保网络通畅。

4. 端口占用检查：Dify 默认会占用几个端口，请确保它们未被占用：

• 3000：前端 Web 界面端口。
• 5001：后端 API 服务端口。
• 6379：Redis 服务端口（内部通信使用）。
• 5432：PostgreSQL 数据库端口（内部使用）。 你可以使用sudo lsof -i :<端口号>或netstat -tulpn | grep <端口号>来检查。

4. 安装部署与启动方式

我们将使用 Docker Compose 进行部署，这是官方推荐且最不容易出错的方式。

步骤 1：获取部署文件打开终端，选择一个你喜欢的目录，克隆 Dify 的 GitHub 仓库（或下载最新发布版）。

# 克隆仓库（包含最新代码，包括1.15版本特性） git clone https://github.com/langgenius/dify.git cd dify # 切换到稳定版本分支，例如 1.15.x，请查看仓库的 Releases 页面确认最新稳定版分支名 # git checkout stable/1.15

步骤 2：配置环境变量Dify 的 Docker 部署主要依靠docker-compose.yaml和.env文件。.env文件通常已存在，我们可能需要根据情况调整。

# 查看并编辑环境变量文件 cp .env.example .env nano .env # 或使用 vim、cat 等编辑器

关键配置项（对于基础体验，大部分可保持默认）：

• CONSOLE_API_URL=http://localhost:5001：后端 API 地址，本地部署通常不用改。
• CONSOLE_WEB_URL=http://localhost:3000：前端访问地址，本地部署通常不用改。
• SECRET_KEY：一个用于加密的随机字符串，建议生成一个复杂的。可以使用openssl rand -base64 32命令生成。
• DB_PASSWORD和REDIS_PASSWORD：数据库和 Redis 的密码，建议修改为强密码。

步骤 3：启动 Dify 服务在dify项目根目录下，执行一条命令即可启动所有服务。

# 使用 docker-compose 启动所有服务（-d 表示后台运行） sudo docker-compose up -d

首次运行会从 Docker Hub 拉取多个镜像（dify-api, dify-web, postgres, redis 等），耗时取决于你的网络速度，请耐心等待。

步骤 4：验证服务状态使用以下命令检查容器是否全部正常运行：

sudo docker-compose ps

你应该看到所有服务（api, web, db, redis）的状态都是Up。也可以查看日志确认无报错：

# 查看所有服务的日志 sudo docker-compose logs -f # 或仅查看某个服务，如 api sudo docker-compose logs -f api

步骤 5：访问 Web 界面并初始化

1. 打开浏览器，访问http://localhost:3000。
2. 首次访问会进入初始化页面，你需要设置管理员账号（邮箱和密码）。
3. 设置完成后，登录进入 Dify 控制台。

至此，一个功能完整的 Dify 1.15 环境就已经准备就绪。接下来，我们将进入核心环节——配置一个带有人工介入功能的工作流。

5. 功能测试与效果验证：构建“智能内容创作与审核”工作流

我们将构建一个模拟真实场景的工作流：AI 根据主题生成一篇技术博客草稿 -> 人工审核并修改 -> AI 根据修改意见优化标题和摘要。

5.1 创建新应用与工作流

1. 登录 Dify 控制台，点击左侧导航栏的“应用”，然后点击“创建新应用”。
2. 选择“工作流”类型，命名为“技术博客人工审核流水线”，点击创建。
3. 进入可视化工作流画布。

5.2 拖拽并配置节点

我们的工作流将包含以下节点，按执行顺序连接：开始->LLM（生成草稿）->人工介入（审核草稿）->LLM（优化标题和摘要）->结束。

第一步：配置 LLM 节点生成草稿

1. 从左侧节点库拖拽一个“LLM”节点到画布。
2. 点击该节点进行配置：
   • 模型供应商：选择你已配置的模型。例如，如果你连接了 OpenAI，就选 OpenAI；如果本地部署了 Ollama，就选 Ollama 并选择具体模型（如qwen2.5:7b）。（如何配置模型？在 Dify 控制台“模型供应商”设置中添加你的 API Key 或本地模型地址）
   • 提示词：输入系统指令和用户指令。例如：
     • 系统指令：你是一位专业的 CSDN 技术博客作者，擅长撰写详细、结构清晰的教程类文章。
     • 用户指令：请围绕主题“{{topic}}”，撰写一篇约800字的技术博客正文。要求结构包含：引言、问题分析、解决方案、操作步骤、总结。语言风格直接、实用，避免空话套话。
   • 变量：在用户指令中，我们使用了{{topic}}作为变量。需要在节点的“变量”部分，点击“添加变量”，设置变量名为topic，类型为“输入”，这样工作流启动时会要求输入这个值。
3. 将“开始”节点连接到这个 LLM 节点的“输入”端口。

第二步：配置“人工介入”节点（核心）

1. 从左侧节点库拖拽“人工介入”节点到画布，放在第一个 LLM 节点之后。
2. 点击配置：
   • 节点名称：人工审核博客草稿。
   • 指令：请仔细审核下方由 AI 生成的博客草稿。你可以直接编辑文本内容，修正技术错误、调整语句不通顺之处、优化表达。完成后点击“提交”。
   • 变量：这里我们需要将上一个 LLM 节点的输出作为人工介入的输入。点击“添加变量”。
     • 变量名：draft。
     • 变量类型：选择“节点”。
     • 节点：选择你刚才配置的第一个 LLM 节点。
     • 输出：选择该 LLM 节点的输出变量（通常是一个包含text字段的对象，如{{#llm.text#}}）。这里注意：Dify 中引用其他节点输出的语法通常是{{#前一个节点ID.输出变量名#}}，在界面中可以通过选择器轻松完成，无需手动输入复杂语法。
   • 人工介入类型：选择“文本编辑”。这意味着审核者将在一个富文本编辑器中直接修改内容。
   • 指派方式（社区版可能简化）：通常为“工作空间成员”或“通过接口指定”。我们选择“工作空间成员”，并在测试时指派给自己（当前登录的管理员）。
3. 将第一个 LLM 节点的“输出”端口连接到“人工介入”节点的“输入”端口。

第三步：配置第二个 LLM 节点进行优化

1. 再拖拽一个“LLM”节点到画布，放在人工介入节点之后。
2. 点击配置：
   • 模型供应商：可以与第一个相同或不同。
   • 提示词：
     • 系统指令：你是一位专业的文案优化助手。
     • 用户指令：这是经过人工修改后的博客正文：{{reviewed_draft}}。请你基于修改后的正文，为其生成一个更吸引人的标题（不超过20字）和一段简洁有力的摘要（约150字）。请直接以 JSON 格式输出：{"title": "生成的标题", "summary": "生成的摘要"}
   • 变量：添加变量reviewed_draft，类型选择“节点”，节点选择“人工审核博客草稿”节点，输出选择人工修改后的文本（如{{#human_intervention.output#}}）。
3. 将“人工介入”节点的“输出”端口连接到第二个 LLM 节点的“输入”端口。
4. 最后，将第二个 LLM 节点的“输出”端口连接到“结束”节点。

最终画布连接应为：开始 -> LLM(生成草稿) -> 人工介入(审核草稿) -> LLM(优化标题摘要) -> 结束。

5.3 保存并运行测试

1. 点击画布右上角的“保存”按钮。
2. 点击右上角的“发布”按钮，将工作流发布为一个可运行的版本。
3. 回到应用概览页，点击“聊天”或“工作流运行”标签页（取决于版本）。
4. 在运行界面，你会看到需要输入变量topic的输入框。输入一个测试主题，例如：“在 Kubernetes 中优雅地部署有状态应用”。
5. 点击“运行”。

此时，工作流将开始执行：

1. 第一个 LLM 节点会根据你的主题生成博客草稿。
2. 执行到“人工介入”节点时，工作流会暂停。在 Dify 的“人工任务”看板（通常位于顶部导航栏的铃铛图标或独立菜单中），会出现一条待处理的任务。
3. 你作为指派的审核者，需要点击进入该任务。你会看到 AI 生成的草稿和一个富文本编辑器。你可以任意修改文本内容。
4. 修改完成后，点击“提交并继续”。
5. 工作流将从暂停处恢复，将你修改后的文本传递给第二个 LLM 节点。
6. 第二个 LLM 节点会生成优化后的标题和摘要。
7. 工作流完成，你可以在运行历史中查看完整的输入、人工修改记录以及最终输出。

效果验证点：

• 人工介入触发：确认工作流在第一个 LLM 后成功暂停，并在“人工任务”看板生成了任务。
• 编辑功能：确认你可以在富文本编辑器中流畅地修改 AI 生成的草稿。
• 流程恢复：确认提交人工任务后，工作流能正确恢复，并将修改后的内容传递给下游节点。
• 最终输出：确认第二个 LLM 节点基于修改后的草稿生成了新的标题和摘要，而不是原始的草稿。

通过这个测试，你已经验证了“人工介入”功能的核心流程：暂停 -> 人工编辑 -> 恢复并传递新值。

6. 接口 API 与批量任务集成

Dify 的强大之处在于其 API 驱动。人工介入工作流不仅可以手动在 Web 界面触发，更可以通过 API 集成到你的业务系统中，实现自动化流水线中的人机交互。

6.1 通过 API 触发工作流

首先，你需要获取 API Key。

1. 在 Dify 控制台，进入“设置” -> “API 密钥”。
2. 创建一个新的密钥，并复制保存好（只显示一次）。

假设你的工作流应用 ID 是app-xxxxxx，你可以使用以下 Python 脚本触发它：

import requests import json import time # 配置信息 API_KEY = "your-dify-api-key-here" # 替换为你的 API Key APP_ID = "app-xxxxxx" # 替换为你的应用 ID BASE_URL = "http://localhost:5001/v1" # 如果你的 Dify 部署在其他地址，请修改 # 触发工作流执行的端点 url = f"{BASE_URL}/workflows/run" headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } # 请求体，包含输入变量 payload = { "inputs": { "topic": "使用 Docker 快速搭建 PostgreSQL 测试环境" # 对应工作流中的 topic 变量 }, "response_mode": "blocking", # 阻塞模式，等待工作流最终完成（如果含人工介入，会超时） # "response_mode": "streaming", # 流式模式，适合前端实时显示 "user": "test_user_001" # 标识发起请求的用户，可用于追踪 } try: response = requests.post(url, headers=headers, json=payload, timeout=30) # 设置短超时，因为会卡在人工介入 print(f"状态码: {response.status_code}") if response.status_code == 200: result = response.json() print("工作流触发成功！") print(f"执行ID: {result.get('task_id')}") print(f"事件ID: {result.get('event_id')}") # 如果工作流中有“人工介入”，此时响应可能只包含直到介入点的输出，或者直接返回“等待人工介入”的状态。 # 具体返回结构需查看 Dify API 文档。 print("响应内容:", json.dumps(result, indent=2, ensure_ascii=False)) else: print(f"请求失败: {response.text}") except requests.exceptions.Timeout: print("请求超时。这很可能是因为工作流在‘人工介入’节点暂停了。这是预期行为。") # 超时后，你需要去查询人工任务或通过异步方式获取结果。 except Exception as e: print(f"发生错误: {e}")

重要提示：当工作流包含“人工介入”节点时，使用blocking模式的 API 调用很可能会因为等待人工操作而超时。因此，生产环境更推荐使用异步回调（webhook）或轮询任务状态的方式。

6.2 查询与处理人工任务

当工作流因人工介入暂停后，你需要通过 API 来获取待处理的任务列表，并允许用户（或你的系统）处理它们。

1. 查询待处理的人工任务：

def list_pending_human_tasks(api_key, app_id=None): """获取待处理的人工任务列表""" url = f"{BASE_URL}/workspace/current/tasks" headers = {"Authorization": f"Bearer {api_key}"} params = {"status": "pending"} # 筛选状态为“待处理”的任务 if app_id: params["app_id"] = app_id response = requests.get(url, headers=headers, params=params) if response.status_code == 200: tasks = response.json().get('data', []) return tasks else: print(f"获取任务列表失败: {response.text}") return [] # 使用示例 pending_tasks = list_pending_human_tasks(API_KEY, APP_ID) for task in pending_tasks: print(f"任务ID: {task['id']}") print(f"来自应用: {task['app_name']}") print(f"工作流执行ID: {task['workflow_run_id']}") print(f"节点ID: {task['node_id']}") print(f"创建时间: {task['created_at']}") print("-" * 30)

2. 处理（完成）一个人工任务：获取到任务 ID (task_id) 后，你可以构建一个前端界面让用户处理，或者通过 API 模拟处理（需知道处理结果）。

def complete_human_task(api_key, task_id, outputs): """ 完成一个人工介入任务 :param outputs: 一个字典，包含人工处理后的输出。 对于“文本编辑”类型，可能是 {"text": "用户修改后的内容"}。 具体格式取决于人工介入节点的配置。 """ url = f"{BASE_URL}/workspace/current/tasks/{task_id}/complete" headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } payload = { "outputs": outputs } response = requests.post(url, headers=headers, json=payload) if response.status_code == 200: print(f"任务 {task_id} 处理成功！") return True else: print(f"处理任务失败: {response.text}") return False # 使用示例：假设我们获取到第一个待处理任务，并模拟用户修改了文本 if pending_tasks: sample_task_id = pending_tasks[0]['id'] # 假设人工介入节点配置的输出变量是 `text` modified_content = "这是经过人工审核和优化后的博客正文内容..." success = complete_human_task(API_KEY, sample_task_id, {"text": modified_content})

6.3 配置 Webhook 实现外部通知

为了让审核者及时知道有任务需要处理，可以配置 Webhook。当工作流到达人工介入节点时，Dify 会向一个你指定的 URL 发送 POST 请求。

1. 在 Dify 工作流中配置 Webhook 节点：你可以在“人工介入”节点之前或之后添加一个“HTTP 请求”节点，向你的通知服务（如钉钉机器人、企业微信、Slack）发送消息。
2. 使用更集成的方式（企业版功能或自定义）：Dify 企业版可能提供更直接的通知集成。社区版可以通过在“人工介入”节点的“指令”中说明，或者通过上述 API 轮询+外部通知服务的方式实现。

一个简单的思路是：写一个常驻的守护进程，定期调用list_pending_human_tasksAPI，当发现新任务时，调用钉钉/飞书等机器人的 API 发送通知。

批量任务处理：结合上述 API，你可以轻松实现批量处理。用一个脚本读取一个主题列表，循环调用触发工作流的 API。每个工作流实例都会独立运行，并在需要时创建独立的人工任务。你的人工任务列表 API 会看到来自不同执行实例的多个任务，可以批量处理。

7. 资源占用与性能观察

Dify 服务本身资源消耗不高，性能瓶颈主要出现在集成的 AI 模型推理上。

1. Dify 核心服务资源占用：在运行了 PostgreSQL、Redis、API 服务和 Web 服务的标准 Docker Compose 部署下，内存占用通常在 1GB 到 2GB 之间，CPU 使用率较低。你可以通过以下命令观察：

# 查看所有容器资源使用情况 sudo docker stats # 查看具体某个容器的资源使用详情 sudo docker stats dify-api-1 dify-web-1

2. 工作流执行性能观察：

• 无人工介入的纯 AI 工作流：性能取决于 LLM 节点的响应速度。如果使用云端 API（如 GPT-4），则受网络和 API 速率限制影响。如果使用本地模型（如通过 Ollama），则受本地 GPU/CPU 算力限制。
• 含人工介入的工作流：执行时间会无限期延长，直到人工任务被完成。这是设计如此，不是性能问题。你需要关注的是：
  • 任务堆积：通过人工任务看板或 API 监控待处理任务数量，避免积压。
  • 上下文保持：Dify 会保持工作流暂停时的状态（在内存或数据库中），对于长时间暂停的任务，需确保系统有足够资源维持这些状态。通常这不是问题。

3. 降低资源消耗与优化建议：

• 使用轻量级数据库：对于超大规模使用，可以考虑将 PostgreSQL 替换为更高效的配置，或使用外部托管数据库。
• 优化 LLM 调用：
  • 对于非关键路径，使用更小、更快的模型。
  • 设置合理的 API 超时和重试策略。
  • 利用 Dify 的“变量”和“知识库”功能，减少不必要的提示词长度。
• 人工介入的异步化：如前所述，使用异步 API 调用 (response_mode: “streaming”) 和 Webhook 回调，避免前端 HTTP 请求长时间挂起。
• 定期清理：定期清理旧的工作流执行记录和日志，以减轻数据库压力（Dify 可能提供相关设置或脚本）。

8. 常见问题与排查方法

在部署和使用 Dify 1.15 人工介入功能时，你可能会遇到以下问题。这里提供排查思路。

9. 最佳实践与使用建议

为了让“人工介入”功能在你的生产环境中稳定、高效地运行，遵循以下最佳实践：

1. 明确介入标准与操作指南：在“人工介入”节点的“指令”中，清晰、具体地告诉审核者需要做什么。例如：“请检查以下代码的安全性漏洞，并修正明显的语法错误。”而不是“请审核以下代码”。提供检查清单或样例，能大幅提升审核质量和效率。
2. 设计原子化的介入任务：尽量让一个“人工介入”节点只处理一个明确、小范围的任务。例如，一个节点审核事实准确性，另一个节点优化文风。避免让一个节点承担过多、过杂的审核工作，这会导致效率低下和标准不一。
3. 设置任务超时与自动处理：对于某些场景，如果人工长时间未处理，可能需要自动跳过或按默认方案处理。虽然 Dify 原生节点可能不支持，但你可以通过在外围系统（调用 Dify API 的服务）设置超时监控来实现：如果任务超时未完成，则通过 API 自动提交一个预设的“安全”结果或直接取消该工作流实例。
4. 与现有系统深度集成：不要将 Dify 的人工任务看板作为唯一处理入口。利用 Dify 的 API，将待处理任务同步到你们团队已有的任务管理系统（如 Jira, Trello, 飞书任务）或聊天工具（钉钉、企业微信）中，让审核者在熟悉的环境里工作。
5. 实现权限与审计闭环：通过 API 调用中的user字段，严格记录工作流发起者。在人工介入节点，确保指派给正确的责任人（或角色组）。所有人工操作（提交的内容、操作人、时间）都应通过工作流运行日志和人工任务记录功能留存，满足合规审计要求。
6. 进行充分的测试与演练：在上线前，用各种边缘案例测试工作流：输入空值、输入超长文本、人工拒绝提交、网络中断等。确保整个流程（触发->介入->恢复->完成）在异常情况下也能有合理的处理逻辑（如错误处理节点）。
7. 监控与优化：关注“平均任务处理时间”、“任务积压数量”等指标。如果某个介入节点成为瓶颈，分析原因是任务太多、指令不清还是工具不好用，并针对性优化。

10. 总结

Dify 1.15 的“人工介入”功能，成功地在自动化 AI 工作流中打开了“一扇门”，让人类智慧可以在关键时刻介入，引导流程走向更精确、更优质的结果。它不再是简单的审批流，而是一个可编辑、可交互的协作节点，这大大扩展了 AI 工作流的应用边界。

通过本文的实操，你应该已经掌握了从部署 Dify、构建含人工介入的工作流，到通过 API 集成和外部通知实现自动化人机协同的全过程。这个功能最直接的价值在于，它将那些 AI 不擅长或容易出错的“最后一公里”问题，交给了人类专家，同时保持了整体流程的自动化框架。

接下来，你可以尝试更复杂的场景：比如在一个客户服务流程中，AI 自动生成回复，人工介入确保语气和策略正确；在一个代码生成流程中，AI 搭建框架，人工介入进行关键逻辑审查和安全检查。Dify 提供的画布和节点能力，让你可以像搭积木一样设计这些复杂的人机协作流程。

建议你将本文的示例作为起点，立即动手搭建一个与你当前工作相关的小型工作流进行测试。从简单的文本审核开始，逐步增加复杂度，你会更深刻地体会到“人工介入”如何成为你 AI 应用工具箱中一件强大而灵活的武器。

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