Dify 1.15 人工介入功能实战：构建可控AI工作流，实现高质量人机协同

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 “人工介入”功能的核心特性与部署要求让你判断它是否适合你的技术栈和场景。能力项说明核心功能在工作流执行过程中在指定节点暂停等待人工审核、编辑或输入完成后继续自动化流程。开源性质开源 (Apache 2.0 License)由 LangGenius 团队维护。主要价值提升 AI 工作流输出的准确性、合规性和可控性实现高质量的人机协同。部署方式支持 Docker Compose 一键部署、云服务直接使用、以及 Kubernetes 部署。本地测试推荐 Docker。硬件门槛极低。核心服务本身对 GPU 无要求。资源消耗取决于你集成的 AI 模型如本地 Ollama 或云端 API。仅运行 Dify 服务2核4G内存的服务器或本地电脑即可。启动方式通过docker-compose up -d命令一键启动 WebUI 和后台服务。是否支持 API是。提供完整的 RESTful API可用于触发工作流、查询人工介入任务、提交人工处理结果。是否支持批量任务是。可以通过 API 批量发起工作流执行每个实例均可独立触发人工介入。关键新特性1.可配置的介入节点在画布中任意 LLM、代码执行等节点后插入“人工介入”节点。2.丰富的介入类型支持文本编辑、选项选择、文件上传等多种交互方式。3.外部通知集成可配置 Webhook 或与钉钉、飞书、企业微信等通讯工具联动通知审核人。4.任务队列与管理提供统一的人工任务看板方便集中处理待办事项。适合场景1. 内容生成后的编辑与审核文章、营销文案。2. 代码生成后的代码审查与优化。3. 数据提取与分析结果的确认。4. 关键决策点的审批如合同条款、费用报销。5. 需要人类提供额外信息或创意的多步骤流程。2. 适用场景与使用边界“人工介入”功能听起来很强大但它并不是所有工作流的必需品。理解其适用场景和边界能帮助你更有效地利用它。最适合的使用场景质量门控Quality Gate在内容发布、代码合并、报告生成前设置一个必须由人类通过的检查点。例如AI 生成一篇产品介绍后必须由市场专员审核并微调语气后才能发布到官网。复杂决策辅助当工作流需要基于模糊或非结构化信息做出选择时。例如AI 分析客户邮件情绪并生成几种可能的回复草稿由客服代表选择最合适的一条并微调后发送。数据验证与修正AI 从文档中提取的字段如金额、日期、公司名可能存在识别误差人工介入节点可以让人快速核对并修正。创造性补充AI 可以生成大纲、初稿或基础设计但需要人类注入独特的创意、风格或深度见解。例如AI 生成广告标语选项由创意总监选择并优化。需要谨慎使用或不适用的场景完全自动化的高频任务对于每天运行成千上万次、且容错率较高的任务如简单的数据清洗、标签生成加入人工介入会严重拖慢效率得不偿失。实时性要求极高的流程如实时聊天机器人、高频交易系统人工介入的延迟是不可接受的。缺乏明确审核标准如果审核者自己也没有清晰的判断标准那么人工介入就变成了随意的主观修改无法保证输出质量的提升反而可能引入不一致性。合规与安全边界权限控制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.10Docker 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 ar /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-worldGit用于克隆代码仓库可选可直接下载压缩包。sudo apt-get install git3. 硬件与网络CPU 内存建议至少 2 核 CPU4 GB 内存。如果计划在本地同时运行大语言模型如通过 Ollama则需要更多资源。磁盘空间至少 10 GB 可用空间用于存放 Docker 镜像和数据库。网络需要能正常访问互联网以下载 Docker 镜像和可能的模型文件。如果需要连接 OpenAI、Azure OpenAI 等云端 AI 服务需确保网络通畅。4. 端口占用检查Dify 默认会占用几个端口请确保它们未被占用3000前端 Web 界面端口。5001后端 API 服务端口。6379Redis 服务端口内部通信使用。5432PostgreSQL 数据库端口内部使用。 你可以使用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_URLhttp://localhost:5001后端 API 地址本地部署通常不用改。CONSOLE_WEB_URLhttp://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 界面并初始化打开浏览器访问http://localhost:3000。首次访问会进入初始化页面你需要设置管理员账号邮箱和密码。设置完成后登录进入 Dify 控制台。至此一个功能完整的 Dify 1.15 环境就已经准备就绪。接下来我们将进入核心环节——配置一个带有人工介入功能的工作流。5. 功能测试与效果验证构建“智能内容创作与审核”工作流我们将构建一个模拟真实场景的工作流AI 根据主题生成一篇技术博客草稿 - 人工审核并修改 - AI 根据修改意见优化标题和摘要。5.1 创建新应用与工作流登录 Dify 控制台点击左侧导航栏的“应用”然后点击“创建新应用”。选择“工作流”类型命名为“技术博客人工审核流水线”点击创建。进入可视化工作流画布。5.2 拖拽并配置节点我们的工作流将包含以下节点按执行顺序连接开始-LLM生成草稿-人工介入审核草稿-LLM优化标题和摘要-结束。第一步配置 LLM 节点生成草稿从左侧节点库拖拽一个“LLM”节点到画布。点击该节点进行配置模型供应商选择你已配置的模型。例如如果你连接了 OpenAI就选 OpenAI如果本地部署了 Ollama就选 Ollama 并选择具体模型如qwen2.5:7b。如何配置模型在 Dify 控制台“模型供应商”设置中添加你的 API Key 或本地模型地址提示词输入系统指令和用户指令。例如系统指令你是一位专业的 CSDN 技术博客作者擅长撰写详细、结构清晰的教程类文章。用户指令请围绕主题“{{topic}}”撰写一篇约800字的技术博客正文。要求结构包含引言、问题分析、解决方案、操作步骤、总结。语言风格直接、实用避免空话套话。变量在用户指令中我们使用了{{topic}}作为变量。需要在节点的“变量”部分点击“添加变量”设置变量名为topic类型为“输入”这样工作流启动时会要求输入这个值。将“开始”节点连接到这个 LLM 节点的“输入”端口。第二步配置“人工介入”节点核心从左侧节点库拖拽“人工介入”节点到画布放在第一个 LLM 节点之后。点击配置节点名称人工审核博客草稿。指令请仔细审核下方由 AI 生成的博客草稿。你可以直接编辑文本内容修正技术错误、调整语句不通顺之处、优化表达。完成后点击“提交”。变量这里我们需要将上一个 LLM 节点的输出作为人工介入的输入。点击“添加变量”。变量名draft。变量类型选择“节点”。节点选择你刚才配置的第一个 LLM 节点。输出选择该 LLM 节点的输出变量通常是一个包含text字段的对象如{{#llm.text#}}。这里注意Dify 中引用其他节点输出的语法通常是{{#前一个节点ID.输出变量名#}}在界面中可以通过选择器轻松完成无需手动输入复杂语法。人工介入类型选择“文本编辑”。这意味着审核者将在一个富文本编辑器中直接修改内容。指派方式社区版可能简化通常为“工作空间成员”或“通过接口指定”。我们选择“工作空间成员”并在测试时指派给自己当前登录的管理员。将第一个 LLM 节点的“输出”端口连接到“人工介入”节点的“输入”端口。第三步配置第二个 LLM 节点进行优化再拖拽一个“LLM”节点到画布放在人工介入节点之后。点击配置模型供应商可以与第一个相同或不同。提示词系统指令你是一位专业的文案优化助手。用户指令这是经过人工修改后的博客正文{{reviewed_draft}}。请你基于修改后的正文为其生成一个更吸引人的标题不超过20字和一段简洁有力的摘要约150字。请直接以 JSON 格式输出{title: 生成的标题, summary: 生成的摘要}变量添加变量reviewed_draft类型选择“节点”节点选择“人工审核博客草稿”节点输出选择人工修改后的文本如{{#human_intervention.output#}}。将“人工介入”节点的“输出”端口连接到第二个 LLM 节点的“输入”端口。最后将第二个 LLM 节点的“输出”端口连接到“结束”节点。最终画布连接应为开始 - LLM(生成草稿) - 人工介入(审核草稿) - LLM(优化标题摘要) - 结束。5.3 保存并运行测试点击画布右上角的“保存”按钮。点击右上角的“发布”按钮将工作流发布为一个可运行的版本。回到应用概览页点击“聊天”或“工作流运行”标签页取决于版本。在运行界面你会看到需要输入变量topic的输入框。输入一个测试主题例如“在 Kubernetes 中优雅地部署有状态应用”。点击“运行”。此时工作流将开始执行第一个 LLM 节点会根据你的主题生成博客草稿。执行到“人工介入”节点时工作流会暂停。在 Dify 的“人工任务”看板通常位于顶部导航栏的铃铛图标或独立菜单中会出现一条待处理的任务。你作为指派的审核者需要点击进入该任务。你会看到 AI 生成的草稿和一个富文本编辑器。你可以任意修改文本内容。修改完成后点击“提交并继续”。工作流将从暂停处恢复将你修改后的文本传递给第二个 LLM 节点。第二个 LLM 节点会生成优化后的标题和摘要。工作流完成你可以在运行历史中查看完整的输入、人工修改记录以及最终输出。效果验证点人工介入触发确认工作流在第一个 LLM 后成功暂停并在“人工任务”看板生成了任务。编辑功能确认你可以在富文本编辑器中流畅地修改 AI 生成的草稿。流程恢复确认提交人工任务后工作流能正确恢复并将修改后的内容传递给下游节点。最终输出确认第二个 LLM 节点基于修改后的草稿生成了新的标题和摘要而不是原始的草稿。通过这个测试你已经验证了“人工介入”功能的核心流程暂停 - 人工编辑 - 恢复并传递新值。6. 接口 API 与批量任务集成Dify 的强大之处在于其 API 驱动。人工介入工作流不仅可以手动在 Web 界面触发更可以通过 API 集成到你的业务系统中实现自动化流水线中的人机交互。6.1 通过 API 触发工作流首先你需要获取 API Key。在 Dify 控制台进入“设置” - “API 密钥”。创建一个新的密钥并复制保存好只显示一次。假设你的工作流应用 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: fBearer {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, headersheaders, jsonpayload, timeout30) # 设置短超时因为会卡在人工介入 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, indent2, ensure_asciiFalse)) 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_idNone): 获取待处理的人工任务列表 url f{BASE_URL}/workspace/current/tasks headers {Authorization: fBearer {api_key}} params {status: pending} # 筛选状态为“待处理”的任务 if app_id: params[app_id] app_id response requests.get(url, headersheaders, paramsparams) 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: fBearer {api_key}, Content-Type: application/json } payload { outputs: outputs } response requests.post(url, headersheaders, jsonpayload) 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 请求。在 Dify 工作流中配置 Webhook 节点你可以在“人工介入”节点之前或之后添加一个“HTTP 请求”节点向你的通知服务如钉钉机器人、企业微信、Slack发送消息。使用更集成的方式企业版功能或自定义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-12. 工作流执行性能观察无人工介入的纯 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 人工介入功能时你可能会遇到以下问题。这里提供排查思路。问题现象可能原因排查方式解决方案Docker 启动失败端口冲突端口 3000, 5001, 5432, 6379 被其他程序占用。sudo lsof -i :端口号或netstat -tulpn | grep 端口号修改docker-compose.yaml中服务的端口映射如3000:3000改为3001:3000并同步更新.env文件中的CONSOLE_WEB_URL和CONSOLE_API_URL。访问localhost:3000无法连接1. 容器未成功启动。2. 防火墙阻止。3. 在 macOS/Windows 的 Docker Desktop 中localhost 可能不适用。1.docker-compose ps查看状态。2.docker-compose logs查看错误日志。3. 尝试用127.0.0.1或 Docker Desktop 提供的 IP。1. 根据日志解决启动错误常见于数据库初始化失败。2. 关闭防火墙或放行端口。3. 使用docker-machine ip或 Docker Desktop 设置中的地址。工作流在“人工介入”节点不暂停直接跳过1. “人工介入”节点配置错误未正确连接到需要审核的内容变量。2. 节点“指派方式”配置为自动完成或测试模式。1. 检查“人工介入”节点的变量配置确保其输入来自上一个节点的有效输出。2. 检查节点的“指派”设置确保不是“自动完成”或指派给了不存在的用户。1. 重新配置变量连接在画布上确保连线正确。2. 在测试时指派给当前登录的有效用户。在“人工任务”看板找不到待处理任务1. 当前登录的用户不是被指派者。2. 任务已被其他用户领取或完成。3. 工作流执行失败未到达人工介入节点。1. 确认执行工作流时指定的用户API调用中的user参数或默认指派用户。2. 查看“全部任务”或“已完成任务”标签页。3. 检查工作流运行日志看是否有节点报错。1. 使用正确的用户身份登录。2. 以管理员身份查看所有任务。3. 修复工作流中前置节点的错误。API 调用工作流立即超时工作流中包含“人工介入”而 API 调用模式为blocking服务端在等待人工操作导致客户端超时。查看 API 响应状态码和消息。这是预期行为。改用streaming模式或先调用触发 API再通过task_id异步轮询状态和获取结果。人工提交后下游节点未收到修改后的内容“人工介入”节点的输出变量配置错误下游节点引用了错误的变量。检查下游节点如第二个 LLM的输入变量确认它引用的是人工介入节点的输出如{{#human_intervention_node_id.output#}}而不是最初 LLM 的输出。在下游节点的变量配置中重新选择来源节点和输出变量。Dify 服务运行一段时间后变慢或卡死1. 服务器内存不足。2. 数据库连接数耗尽或未优化。3. Redis 内存占用过高。1. 使用docker stats和top命令查看资源使用。2. 检查数据库日志 (docker-compose logs db)。3. 检查 Redis 内存 (docker exec -it dify-redis-1 redis-cli info memory)。1. 增加服务器资源。2. 优化 PostgreSQL 配置或定期清理旧数据。3. 配置 Redis 最大内存限制和淘汰策略。9. 最佳实践与使用建议为了让“人工介入”功能在你的生产环境中稳定、高效地运行遵循以下最佳实践明确介入标准与操作指南在“人工介入”节点的“指令”中清晰、具体地告诉审核者需要做什么。例如“请检查以下代码的安全性漏洞并修正明显的语法错误。”而不是“请审核以下代码”。提供检查清单或样例能大幅提升审核质量和效率。设计原子化的介入任务尽量让一个“人工介入”节点只处理一个明确、小范围的任务。例如一个节点审核事实准确性另一个节点优化文风。避免让一个节点承担过多、过杂的审核工作这会导致效率低下和标准不一。设置任务超时与自动处理对于某些场景如果人工长时间未处理可能需要自动跳过或按默认方案处理。虽然 Dify 原生节点可能不支持但你可以通过在外围系统调用 Dify API 的服务设置超时监控来实现如果任务超时未完成则通过 API 自动提交一个预设的“安全”结果或直接取消该工作流实例。与现有系统深度集成不要将 Dify 的人工任务看板作为唯一处理入口。利用 Dify 的 API将待处理任务同步到你们团队已有的任务管理系统如 Jira, Trello, 飞书任务或聊天工具钉钉、企业微信中让审核者在熟悉的环境里工作。实现权限与审计闭环通过 API 调用中的user字段严格记录工作流发起者。在人工介入节点确保指派给正确的责任人或角色组。所有人工操作提交的内容、操作人、时间都应通过工作流运行日志和人工任务记录功能留存满足合规审计要求。进行充分的测试与演练在上线前用各种边缘案例测试工作流输入空值、输入超长文本、人工拒绝提交、网络中断等。确保整个流程触发-介入-恢复-完成在异常情况下也能有合理的处理逻辑如错误处理节点。监控与优化关注“平均任务处理时间”、“任务积压数量”等指标。如果某个介入节点成为瓶颈分析原因是任务太多、指令不清还是工具不好用并针对性优化。10. 总结Dify 1.15 的“人工介入”功能成功地在自动化 AI 工作流中打开了“一扇门”让人类智慧可以在关键时刻介入引导流程走向更精确、更优质的结果。它不再是简单的审批流而是一个可编辑、可交互的协作节点这大大扩展了 AI 工作流的应用边界。通过本文的实操你应该已经掌握了从部署 Dify、构建含人工介入的工作流到通过 API 集成和外部通知实现自动化人机协同的全过程。这个功能最直接的价值在于它将那些 AI 不擅长或容易出错的“最后一公里”问题交给了人类专家同时保持了整体流程的自动化框架。接下来你可以尝试更复杂的场景比如在一个客户服务流程中AI 自动生成回复人工介入确保语气和策略正确在一个代码生成流程中AI 搭建框架人工介入进行关键逻辑审查和安全检查。Dify 提供的画布和节点能力让你可以像搭积木一样设计这些复杂的人机协作流程。建议你将本文的示例作为起点立即动手搭建一个与你当前工作相关的小型工作流进行测试。从简单的文本审核开始逐步增加复杂度你会更深刻地体会到“人工介入”如何成为你 AI 应用工具箱中一件强大而灵活的武器。 30款热门AI模型一站整合DeepSeek/GLM/Claude 随心用限时 5 折。 点击领海量免费额度