Dify 1.15 人工介入功能实战：构建人机协同的智能客服审核系统-平芜编程栈

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

如果你正在使用 Dify 构建 AI 应用，是否遇到过这样的困境：AI 的回答看似流畅，但在关键业务节点上，却因为缺乏“人”的判断而显得不可靠？比如，一个智能客服在处理退款申请时，无法准确识别用户的情绪和复杂诉求；一个内容审核助手，面对模棱两可的违规内容时，不敢做出最终裁决。你需要的，可能不是更强大的模型，而是一个让“人”在关键时刻介入的机制。

这正是 Dify 1.15 版本中“人工介入”功能要解决的核心问题。它不是一个简单的“审核”开关，而是一个将 AI 的自动化能力与人类的专业判断无缝衔接的工程化方案。很多人以为这只是给流程加个“确认”按钮，但实际上，它真正改变的是 AI 应用的责任边界和可靠性设计。过去，开发者要么全盘信任 AI，要么完全依赖人工，现在，你可以设计一个“AI 为主，人为辅”的混合智能工作流。

本文将深入拆解 Dify 1.15 的“人工介入”功能。我不会只告诉你“有这个功能”，而是会带你理解它背后的设计哲学，并通过一个完整的实战案例，演示如何从零搭建一个带有人工审核的智能客服工单系统。你将学会如何配置触发条件、设计人工审核界面、处理审核结果，并最终让这个流程在你的应用中跑通。无论你是想提升现有应用的可靠性，还是正在规划一个对准确性要求极高的 AI 项目，这篇文章都将提供可直接落地的解决方案。

1. 人工介入：从“全自动”到“人机协同”的关键一跃

在深入代码之前，我们必须先理解“人工介入”为什么重要。这不仅仅是 Dify 的一个新特性，它反映了当前 AI 应用开发的一个普遍性挑战：如何平衡效率与准确性。

一个纯 AI 驱动的应用，在处理标准化、高确定性任务时效率惊人。但当任务涉及主观判断、复杂规则、高风险决策或需要情感共鸣时，AI 的局限性就暴露无遗。例如：

金融风控：AI 可以初步筛选可疑交易，但最终是否拦截，需要风控专员确认。
医疗咨询：AI 可以提供症状分析和就医建议，但诊断必须由医生做出。
内容创作：AI 可以生成初稿，但最终的调性和合规性需要编辑把关。

Dify 的“人工介入”功能，本质上是在工作流中插入了一个“决策点”。在这个节点，流程会暂停，将 AI 的中间结果（或最终结果）提交给指定的人工审核员。审核员可以查看上下文，做出“通过”、“拒绝”或“修改后通过”的决定，这个决定将直接影响工作流的后续分支。

与简单的“后置审核”不同，Dify 的介入是流程内嵌式的。这意味着：

上下文完整：审核员能看到 AI 推理的完整过程，而不仅仅是最终输出。
操作集成：审核动作（通过、拒绝、修改）直接作为工作流的一个节点，触发不同的后续路径。
状态可追溯：整个流程的“自动”与“手动”阶段状态都被完整记录，便于审计和复盘。

理解了它的价值，我们再来看看它的核心构成。一个完整的“人工介入”环节包含三个要素：

触发节点：在工作流的哪个环节触发人工审核？通常是 AI 生成内容之后，但也可以在任何需要判断的节点。
审核任务：具体审核什么内容？提交给审核员的信息界面如何设计？
处理动作：审核员有哪些操作选项？每个操作会如何影响后续流程？

接下来，我们将通过一个实战项目，把这些抽象概念变成具体的配置和代码。

2. 项目实战：构建带人工审核的智能客服工单系统

假设我们要构建一个智能客服系统，用户提交工单后，AI 助手先自动生成初步回复。但对于涉及“投诉”、“退款”、“升级”等关键词的高敏感工单，或者 AI 置信度较低的回复，需要转交人工客服进行最终审核和发送。

项目目标：

用户在前端提交工单问题。
后端工作流调用 LLM 分析问题并生成初步回复。
系统根据预设规则（如包含敏感词或低置信度）判断是否需要人工审核。
若需要，则创建审核任务，通知人工客服。
人工客服在审核界面查看工单详情和 AI 回复，可选择“直接发送”、“修改后发送”或“转交专家”。
审核决定实时更新工单状态，并执行相应操作（如发送消息、修改内容、分配专家）。

3. 环境准备与 Dify 配置

在开始构建工作流之前，确保你的环境已就绪。

3.1 基础环境要求

Dify 版本：必须为 1.15 或更高版本。你可以在 Dify 管理后台的“系统设置” > “关于”中查看当前版本。
部署方式：无论是 Docker 部署、宝塔面板部署还是源码部署，此功能均可用。
模型配置：确保已至少配置一个可用的文本生成模型（如 GPT-4、DeepSeek、文心一言等），用于 AI 回复生成环节。

3.2 关键概念：工作流与节点Dify 的工作流是一个可视化的编程界面。我们需要用到的核心节点包括：

开始节点：工作流的入口。
LLM 节点：调用大语言模型生成内容。
代码节点：执行 Python 代码，用于实现业务逻辑（如判断是否需要审核）。
人工介入节点（新）：核心节点，用于挂起流程并等待人工操作。
分支节点：根据条件（如审核结果）决定流程走向。
结束节点：工作流的出口。

3.3 创建应用与工作流

登录 Dify 控制台，点击“创建应用”。
选择“工作流”应用类型，命名为“智能客服工单审核系统”。
进入应用后，切换到“工作流”标签页，你将看到一个空白的画布。

4. 核心工作流设计与拆解

我们将工作流分为四个主要阶段：问题接收与 AI 处理 -> 审核判断 -> 人工介入 -> 结果执行。

4.1 第一阶段：问题接收与 AI 初步回复

这个阶段的目标是获取用户输入，并让 AI 生成第一版回复。

配置“开始”节点：
- 从左侧节点库拖入“开始”节点。
- 在“变量”部分，我们需要定义输入参数。点击“添加输入变量”。
- 添加以下变量：
  - user_query: 类型String, 代表用户的工单问题。
  - user_id: 类型String, 代表用户ID。
  - ticket_id: 类型String, 代表工单ID。
- 这些变量将在整个工作流中传递。
添加“LLM”节点：
- 拖入一个“LLM”节点，并将其连接到“开始”节点之后。
- 选择你配置好的语言模型。
- 在“提示词”区域，编写系统指令和用户问题模板。例如：
```
系统指令： 你是一名专业的客服助手。请根据用户的问题，生成一段友好、专业且准确的初步回复。回复应聚焦于解决问题，如果信息不足，应礼貌地请求用户提供更多细节。 用户问题： {{user_query}}
```
- 将节点输出变量命名为ai_preliminary_reply，以便后续节点引用。

4.2 第二阶段：判断是否需要人工审核

这是业务逻辑的核心。我们将使用“代码节点”来实现判断规则。

添加“代码节点”：
- 拖入“代码节点”，连接到“LLM”节点之后。
- 选择语言为Python。
- 在代码编辑器中，编写判断逻辑。这里我们实现一个简单的规则：如果用户问题包含敏感词列表中的词，或者 AI 回复的置信度（这里用一个模拟分数）低于阈值，则触发审核。

# 代码节点：判断是否需要人工审核 def main(user_query: str, ai_preliminary_reply: str) -> dict: """ 根据规则判断是否需要人工审核。 输入: user_query: 用户问题 ai_preliminary_reply: AI初步回复 输出: 包含判断结果的字典 """ # 1. 定义敏感关键词（实际项目中应从数据库或配置中心读取） sensitive_keywords = ["投诉", "举报", "退款", "赔偿", "法律", "起诉", "高管"] # 2. 模拟一个AI回复置信度（实际中可从LLM节点元数据获取，或使用更复杂的评估器） # 这里我们简单地根据回复长度和是否包含“不确定”等词来模拟 confidence_score = 0.8 # 默认置信度 if len(ai_preliminary_reply) < 20 or "不确定" in ai_preliminary_reply or "可能需要" in ai_preliminary_reply: confidence_score = 0.4 # 3. 判断逻辑 need_manual_review = False review_reason = "" # 规则1: 包含敏感词 for keyword in sensitive_keywords: if keyword in user_query: need_manual_review = True review_reason = f"问题包含敏感词 '{keyword}'" break # 规则2: AI置信度过低 if confidence_score < 0.5: need_manual_review = True # 如果已有原因，则追加 review_reason = review_reason + "； " if review_reason else "" review_reason += f"AI回复置信度过低 ({confidence_score})" # 4. 返回结果 return { "need_manual_review": need_manual_review, "review_reason": review_reason, "confidence_score": confidence_score } # 注意：Dify代码节点的输入变量名必须与上游节点的输出变量名匹配。 # 此函数接收的 `user_query` 和 `ai_preliminary_reply` 即来自前面节点的输出。

配置输出：
- 将代码节点的输出变量命名为review_judgment。

4.3 第三阶段：人工介入节点配置

这是本次介绍的重点。如果need_manual_review为True，流程将进入人工审核环节。

添加“分支”节点：
- 在“代码节点”后添加一个“分支”节点。
- 配置分支条件：{{review_judgment.need_manual_review}} equals true。
- 这个节点将根据判断结果，将流程导向“需要审核”或“直接发送”两个分支。
配置“人工介入”节点（在“需要审核”分支）：
- 从节点库中找到“人工介入”节点（可能显示为“人工审核”或类似名称），拖入“需要审核”分支。
- 关键配置项：
  - 任务标题：定义审核任务的标题，例如审核工单 #{{ticket_id}} 的AI回复。可以使用变量。
  - 任务描述：更详细地说明审核任务，例如用户问题涉及敏感内容或AI置信度不足，请审核AI生成的回复并决定后续操作。原因：{{review_judgment.review_reason}}。
  - 待审核内容：这里需要构建一个对象，包含审核员需要看到的所有信息。通常以 JSON 格式呈现。例如：
```
{ “工单ID”: “{{ticket_id}}”, “用户ID”: “{{user_id}}”, “用户原始问题”: “{{user_query}}”, “AI初步回复”: “{{ai_preliminary_reply}}”, “触发审核原因”: “{{review_judgment.review_reason}}” }
```
  - 操作选项：定义审核员可以执行的操作。Dify 1.15 支持自定义操作。我们定义三个：
    - approve：通过，直接发送AI回复。
    - modify_and_approve：修改后发送。需要提供一个文本输入框让审核员编辑回复。
    - reject_and_escalate：拒绝并转交专家。需要提供一个输入框填写转交说明。
  - 指派方式：可以选择“指定成员”（输入具体用户邮箱）或“变量指定”。为了灵活性，我们通常使用“变量指定”，例如{{assigned_agent_email}}。这个变量可以在工作流开始时从数据库查询，或由上一个节点生成。
- 输出变量：配置该节点的输出，例如manual_review_result，它将包含审核员的选择 (action) 和可能的修改内容 (modified_content) 或说明 (note)。

4.4 第四阶段：处理审核结果并执行

人工审核完成后，工作流继续。我们需要根据不同的action执行不同操作。

添加后续“分支”节点：
- 在“人工介入”节点后，添加一个新的“分支”节点。
- 配置分支条件为{{manual_review_result.action}}等于approve、modify_and_approve、reject_and_escalate。
配置各分支操作：
- approve分支：连接一个“代码节点”或“HTTP 请求节点”，执行发送消息的操作，内容为原始的ai_preliminary_reply。
- modify_and_approve分支：同样连接执行发送操作的节点，但发送的内容是manual_review_result.modified_content。
- reject_and_escalate分支：连接一个“代码节点”，执行将工单状态更新为“已转交”，并通知专家团队的操作。内容可以包含manual_review_result.note。
“直接发送”分支处理：
- 回到第一个分支节点的“False”分支（即不需要审核），直接连接发送消息的节点，发送ai_preliminary_reply。
结束与日志：
- 所有分支最终都应汇聚到“结束”节点。
- 建议在关键节点后添加“日志”节点，记录流程状态，便于调试和监控。

5. 完整工作流示例与代码集成

将上述所有节点连接起来，你的工作流视觉上应该类似一个流程图。以下是关键节点的代码补充。

5.1 发送消息的代码节点示例（approve分支后）

# 代码节点：发送客服消息 def main(ticket_id: str, user_id: str, final_reply: str, channel: str = "web") -> dict: """ 模拟向用户发送最终回复。 实际项目中，这里应调用你的消息推送API（如WebSocket、短信、邮件接口）。 """ # 模拟发送逻辑 print(f"[发送消息] 工单 {ticket_id}， 用户 {user_id}， 渠道 {channel}") print(f"消息内容：{final_reply}") # 模拟更新数据库 # update_ticket_status(ticket_id, "replied", final_reply) # 这里可以集成真实的发送服务，例如： # import requests # response = requests.post('https://your-message-api/send', json={ # 'ticket_id': ticket_id, # 'content': final_reply # }) return { "status": "success", "message": f"消息已通过 {channel} 渠道发送", "sent_content": final_reply }

5.2 转交专家的代码节点示例（reject_and_escalate分支后）

# 代码节点：工单升级转交 def main(ticket_id: str, user_query: str, ai_reply: str, review_note: str, expert_team: str = "高级客服组") -> dict: """ 将工单转交给专家团队，并通知相关成员。 """ # 1. 模拟更新工单状态和分配信息 print(f"[工单升级] 工单 {ticket_id} 已转交至 {expert_team}") print(f"用户问题：{user_query}") print(f"AI初版回复：{ai_reply}") print(f"审核员备注：{review_note}") # 2. 模拟发送通知（如邮件、钉钉、飞书群消息） # 这里以打印日志代替实际通知 notification_message = f"有新的工单需要专家处理！\n工单ID：{ticket_id}\n问题摘要：{user_query[:100]}...\n转交原因：{review_note}" print(f"[系统通知] 发送给 {expert_team}: {notification_message}") # 实际集成示例（飞书机器人）： # webhook_url = "https://open.feishu.cn/open-apis/bot/v2/hook/xxx" # data = {"msg_type": "text", "content": {"text": notification_message}} # requests.post(webhook_url, json=data) return { "status": "escalated", "assigned_team": expert_team, "ticket_id": ticket_id }

6. 运行、测试与效果验证

工作流配置完成后，如何测试这个复杂的、带有人工中断的流程？

6.1 在工作流编辑器内调试

点击画布右上角的“调试”按钮。

在调试面板的“输入变量”中，填写测试数据：

{ “user_query”: “我要投诉你们的产品质量有问题，要求退款并赔偿！”, “user_id”: “test_user_001”, “ticket_id”: “TICKET-2024-001” }

点击“运行”。工作流将逐步执行。
当执行到“人工介入”节点时，流程会暂停。此时，你需要模拟人工审核操作。
在 Dify 的“工作流运行历史”或“人工任务”界面（具体位置取决于 Dify 版本的后台设计），你应该能找到待处理的任务。
点击该任务，选择操作（如modify_and_approve），并修改回复内容，然后提交。
提交后，返回调试面板，点击“继续”，工作流将从人工介入节点之后继续执行，并走向你选择的分支。
观察最终输出和日志，验证流程是否符合预期。

6.2 通过 API 触发并处理人工任务在生产环境中，工作流通常通过 API 触发，人工任务也需要通过 API 或专门的管理界面处理。

触发工作流：调用 Dify 的应用发布接口。

curl -X POST https://your-dify-domain/v1/workflows/run \ -H "Authorization: Bearer your-api-key" \ -H "Content-Type: application/json" \ -d '{ “inputs”: { “user_query”: “产品无法使用，急需解决”, “user_id”: “user_123”, “ticket_id”: “T-1001” } }'

响应中会包含本次执行的workflow_run_id。

查询人工任务：当工作流进入人工介入节点后，可以通过 Dify API 查询待处理的人工任务。
```
curl -X GET https://your-dify-domain/v1/workflows/tasks/pending \ -H "Authorization: Bearer your-api-key"
```

处理人工任务：审核员在管理界面操作，或通过 API 提交处理结果。

curl -X POST https://your-dify-domain/v1/workflows/tasks/{task_id}/complete \ -H "Authorization: Bearer your-api-key" \ -H "Content-Type: application/json" \ -d '{ “action”: “modify_and_approve”, “inputs”: { “modified_content”: “尊敬的客户，您好。我们非常重视您的反馈...（修改后的内容）” } }'

监听结果：你的业务系统可以通过 Webhook 或轮询 Dify 的“运行历史”API，获取工作流的最终执行结果，从而更新工单状态或执行后续业务逻辑。

7. 常见问题与排查思路

在集成“人工介入”功能时，你可能会遇到以下典型问题：

问题现象	可能原因	排查方式	解决方案
工作流在“人工介入”节点后不继续执行	1. 人工任务未被处理。 2. 处理任务的 API 调用失败或超时。 3. 工作流执行超时被系统终止。	1. 检查 Dify 后台的“人工任务”列表，确认任务状态是否为“待处理”。 2. 查看 Dify 服务日志，确认是否有处理任务的 API 调用记录或错误。 3. 检查工作流运行历史，看状态是否为“超时”。	1. 确保有正确的权限和流程去处理人工任务（如通知到人）。 2. 检查调用处理任务 API 的认证和参数是否正确。 3. 在 Dify 系统设置中适当增加工作流执行超时时间。
审核员界面看不到完整的上下文信息	“人工介入”节点的“待审核内容”配置不正确，变量未解析或格式混乱。	在调试模式下运行到该节点，查看该节点的输出预览，确认`variables`对象的结构和内容。	确保“待审核内容”是一个有效的 JSON 字符串，并且使用的变量名与上游节点输出变量名完全一致。使用`{{variable_name}}`语法。
分支节点无法正确判断审核结果	1. “人工介入”节点的输出变量名配置错误。 2. 分支条件中引用的变量路径错误。	1. 检查“人工介入”节点的输出变量设置。 2. 在分支节点的条件编辑器中，使用变量选择器查看可用的变量树，确保路径正确，例如`{{manual_review_result.action}}`。	1. 为“人工介入”节点设置一个清晰的输出变量名，如`review_output`。 2. 在条件中精确引用变量属性。Dify 的变量系统是链式的，需确保每一级都存在。
通过 API 触发后，不知道如何关联业务数据（如工单ID）	工作流运行 ID (`workflow_run_id`) 与业务 ID 的映射关系丢失。	在调用 Dify API 触发工作流时，将业务 ID（如`ticket_id`）作为`inputs`的一部分传入。在工作流内部，该 ID 会随着流程传递。	建议在触发工作流后，将返回的`workflow_run_id`与你业务数据库中的记录（如工单）关联起来。这样，当通过 Webhook 或查询 API 收到结果时，可以找到对应的业务记录进行更新。
“代码节点”中的 Python 代码执行报错	1. 代码语法错误。 2. 引用了不存在的变量。 3. 使用了未授权的库。	1. 仔细阅读 Dify 调试面板中“代码节点”的错误信息。 2. 检查函数输入参数名是否与上游变量名匹配。 3. 确认代码是否在安全的沙箱环境中运行，某些系统库可能被禁用。	1. 先在本地或简单的 Python 环境中测试代码逻辑。 2. 确保`def main(**kwargs):`中的参数名与节点输入配置的变量名一致。 3. 避免使用`os`,`sys`等可能受限的模块进行危险操作。

8. 最佳实践与工程建议

将“人工介入”功能投入生产环境，需要考虑更多工程和协作细节。

审核界面友好性：
- 结构化展示：在“待审核内容”中，尽量使用清晰的 JSON 结构或 HTML 片段（如果支持），将用户信息、AI 回复、历史对话、相关数据（如订单信息）分块展示，方便审核员快速抓取重点。
- 操作指引明确：在“任务描述”中，明确告诉审核员每个操作选项的具体含义和后续影响，减少误操作。
任务分配与通知机制：
- 动态指派：不要硬编码审核员邮箱。可以通过“代码节点”在运行时根据工单类型、技能组、负载均衡策略动态计算assigned_agent_email。
- 多渠道通知：集成外部通知系统（如钉钉、飞书、企业微信、邮件），当有新的审核任务时，主动提醒审核员，避免任务被遗忘。Dify 的“HTTP 请求”节点可以用于调用通知 webhook。
超时与降级策略：
- 设置任务超时：为“人工介入”节点设置一个合理的超时时间（如30分钟）。如果超时无人处理，工作流应能自动执行一个降级策略（例如，转给备用客服，或发送一条“正在加急处理”的自动回复）。
- 实现降级分支：在“人工介入”节点后，除了基于操作的分支，再添加一个基于“超时”条件的分支，连接到降级处理逻辑。
审计与追溯：
- 完整记录：Dify 会记录工作流的完整执行过程和变量快照。确保这些日志被妥善保存，并与你的业务审计系统对接。
- 操作日志：在“人工介入”节点的后续处理代码中，记录下审核员的操作（谁、在何时、做了何决定、修改了什么），这对于质量分析和责任界定至关重要。
性能与扩展性：
- 批量处理考虑：对于可能产生大量人工任务的场景（如内容批量审核），考虑设计队列和批量处理界面，避免审核员面对海量的单条任务。
- 工作流复杂度：虽然 Dify 工作流很强大，但过度复杂的工作流会影响可维护性和执行性能。如果逻辑极其复杂，考虑将部分逻辑封装成外部 API 服务，在工作流中用“HTTP 请求”节点调用。

Dify 1.15 的“人工介入”功能，为 AI 应用从“玩具”走向“生产工具”补上了关键一环。它承认了当前 AI 能力的边界，并通过优雅的工程化设计，将人的智慧引入了自动化流程的闭环。通过本文的实战演练，你应该已经掌握了从场景分析、工作流设计、节点配置到调试部署的全过程。接下来，你可以在你的项目中尝试引入这个模式，先从一两个高风险或高价值的场景开始，观察其对用户体验和运营效率的实际影响，再逐步推广。记住，最好的“人机协同”不是让人成为机器的监工，而是让机器成为人的放大器。