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 fAI回复置信度过低 ({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(fAI初版回复{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, jsondata) 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 能力的边界并通过优雅的工程化设计将人的智慧引入了自动化流程的闭环。通过本文的实战演练你应该已经掌握了从场景分析、工作流设计、节点配置到调试部署的全过程。接下来你可以在你的项目中尝试引入这个模式先从一两个高风险或高价值的场景开始观察其对用户体验和运营效率的实际影响再逐步推广。记住最好的“人机协同”不是让人成为机器的监工而是让机器成为人的放大器。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度