文章简介：本文手把手教你在Dify中用工作流搭建一个智能工单审批系统，实现LLM自动判断紧急程度、代码执行节点统一处理结果、HTTP请求集成钉钉/数据库等功能。附完整配置和演示，适合想深入学习Dify工作流的开发者。 标签：Dify、工作流、工单审批、代码执行、LLM
前言
在上一篇文章中，我介绍了如何用Dify搭建一个多分支AI客服系统，实现了意图识别和基础的条件分支处理。
这次我们更进一步，来搭建一个工单审批流，解决更复杂的业务场景：
- 用LLM自动判断工单的紧急程度
- 用代码执行节点统一处理不同分支的结果
- 用HTTP请求集成钉钉Webhook、模拟数据库操作
这篇文章能解决什么问题？
很多企业的工单系统都是这样工作的：
- 用户提交工单 → 客服手动判断紧急程度 → 分配给不同部门
- 问题：效率低、容易遗漏、无法自动化
通过本文，你将学会：
- 如何用LLM自动分析工单内容，判断紧急程度
- 如何用代码执行节点作为分支结果的"汇总器"
- 如何用HTTP请求节点集成外部系统
读完这篇你能得到什么？
- 一个完整可运行的工单审批流Demo
- 理解代码执行节点的使用场景和技巧
- 掌握Dify工作流与外部系统集成的方法
前置知识：需要了解Dify的基本使用，有Dify工作流搭建经验更佳。
一、项目需求
工单审批的痛点
传统工单处理方式存在的问题：
- 人工判断慢：客服需要阅读工单内容，主观判断紧急程度
- 处理标准不一：不同客服对"紧急"的定义不同
- 无法自动化：判断后还需要手动分配、通知
需要实现的功能
本文要搭建一个智能工单审批流，实现以下功能：
- LLM自动判断：用大模型分析工单标题和描述，自动判断紧急程度
- 三级分类：紧急(P0) → 普通(P1) → 低优先级(P2)
- 自动化处理：
- 紧急：发送钉钉Webhook通知，标记高优先级
- 普通：存入数据库，自动回复用户
- 低优先级：记录到周报，排期处理
- 统一结果输出：用代码执行节点汇总各分支结果
预期效果
用户提交工单 → LLM判断紧急程度 →
├── 紧急(P0) → 发送钉钉Webhook → 代码执行汇总 → 输出结果
├── 普通(P1) → 存入数据库 → 代码执行汇总 → 输出结果
└── 低优先级(P2) → 记录周报 → 代码执行汇总 → 输出结果
二、核心概念：代码执行节点
什么是代码执行节点？
代码执行节点是Dify工作流中的一个强大的功能节点，它允许你编写Python代码来处理数据。
什么场景下需要代码执行节点？
- 数据转换：将一种格式转换为另一种格式
- 条件逻辑：比条件分支节点更复杂的判断逻辑
- 计算处理：对数值进行计算、统计
- 结果汇总：将多个分支的结果统一处理（本文案例）
本文的代码执行节点设计
我们用代码执行节点作为"结果汇总器"：
def main(arg1: int, arg2: int, arg3: int):
if arg1 == 200:
return {
"result": '钉钉通知成功',
}
elif arg2 == 200:
return {
"result": '存入数据库成功',
}
else:
return {
"result": '记录到周报成功',
}
设计思路：
- 三个输入参数
arg1、arg2、arg3分别接收三个分支HTTP请求的状态码 - 只有被执行的分支，其HTTP请求状态码才是200
- 根据哪个状态码为200，判断走的是哪个分支
- 返回对应的处理结果
三、环境准备
- Dify版本：1.11.x
- Linux环境：CentOS Stream 9
- Docker版本：29.2.1
- LLM模型: DeepSeek
四、开始搭建
4.1 创建工作流
打开Dify → 创建应用 → 选择「工作流」→ 命名「工单审批流」
4.2 添加用户输入节点
配置以下输入变量：
| 变量名 | 类型 | 说明 |
|---|---|---|
| title | 文本 | 工单标题 |
| description | 文本 | 工单描述 |
4.3 添加LLM节点（紧急程度判断）
模型选择：DeepSeek 或 qwen-max
系统提示词：
你是一个工单审批助手。请分析工单内容，判断其紧急程度：
- 紧急（P0）：系统宕机、数据丢失、安全漏洞、大量用户受影响
- 普通（P1）：功能故障但有workaround、部分用户受影响
- 低优先级（P2）：功能建议、体验优化、个别用户问题
只输出一个词：紧急、普通、或低优先级，不要输出其他内容。
用户提示词：
工单标题：{{ title }}
工单描述：{{ description }}
请判断这个工单的紧急程度。
4.4 添加条件分支节点
配置3个分支条件：
| 分支名称 | 条件表达式 |
|---|---|
| 紧急分支 | {{ output }} == "紧急" |
| 普通分支 | {{ output }} == "普通" |
| 低优先级分支 | {{ output }} == "低优先级" |
4.5 各分支处理
紧急分支（P0）：发送钉钉Webhook
HTTP请求配置：
- URL：
https://httpbin.org/post - 方法：POST
- 请求体：
{
"level": "P0-紧急",
"title": "{{ title }}",
"description": "{{ description }}",
"action": "立即处理"
}
普通分支（P1）：存入数据库
HTTP请求配置：
- URL：
https://httpbin.org/post - 方法：POST
- 请求体：
{
"level": "P1-普通",
"title": "{{ title }}",
"description": "{{ description }}",
"status": "pending"
}
低优先级分支（P2）：记录周报
HTTP请求配置：
- URL：
https://httpbin.org/post - 方法：POST
- 请求体：
{
"level": "P2-低优先级",
"title": "{{ title }}",
"description": "{{ description }}",
"suggestion": "排期处理"
}
4.6 添加代码执行节点（核心！）
这是本文的重点！将三个分支的结果汇总。
输入变量配置：
| 变量名 | 类型 | 说明 |
|---|---|---|
| arg1 | 数字 | 紧急分支HTTP请求状态码 |
| arg2 | 数字 | 普通分支HTTP请求状态码 |
| arg3 | 数字 | 低优先级分支HTTP请求状态码 |
代码：
def main(arg1: int, arg2: int, arg3: int):
if arg1 == 200:
return {
"result": '钉钉通知成功',
}
elif arg2 == 200:
return {
"result": '存入数据库成功',
}
else:
return {
"result": '记录到周报成功',
}
关键点：
- 将三个分支的「HTTP请求」节点的输出（状态码），都连接到这个代码执行节点
- Dify会自动只传递被执行的分支的状态码，未执行的分支变量为空
4.7 添加输出节点
将「代码执行」节点的输出连接到「输出」节点，统一返回处理结果。
五、完整工作流
整体工作流结构：
开始 → 用户输入 → LLM(判断紧急程度) → 条件分支 →
├── 紧急分支 → HTTP请求(钉钉) ─┐
├── 普通分支 → HTTP请求(数据库)─┼→ 代码执行 → 输出节点
└── 低优先级分支 → HTTP请求(周报)─┘
六、测试验证
测试用例
| 紧急程度 | 测试工单示例 | 预期结果 |
|---|---|---|
| 紧急 | 「系统无法登录，所有用户都受影响」 | 钉钉通知成功 |
| 普通 | 「某个功能点击没反应，但其他功能正常」 | 存入数据库成功 |
| 低优先级 | 「希望增加一个主题切换功能」 | 记录到周报成功 |
测试结果
七、与Demo1的区别
| 项目 | Demo1 | Demo2 |
|---|---|---|
| 核心功能 | 意图识别 + 分支处理 | 紧急程度判断 + 分支处理 |
| 分支数量 | 3个（咨询/售后/投诉） | 3个（紧急/普通/低优先级） |
| 应用场景 | 智能客服 | 工单审批 |
| 外部集成 | 知识库 + HTTP请求 | HTTP请求（模拟数据库和钉钉） |
| 新特性 | - | 代码执行节点汇总结果 |
八、总结
通过本文你学到了什么？
- LLM紧急程度判断：用大模型自动分析工单内容，分类为紧急/普通/低优先级
- 代码执行节点：作为分支结果的"汇总器"，实现复杂的数据处理逻辑
- HTTP请求集成：调用外部API实现钉钉通知、数据库操作、周报记录
代码执行节点的使用技巧
- 接收多分支变量：一个代码执行节点可以接收多个分支的数据
- 条件判断：用
if/elif/else判断哪个分支被执行 - 统一输出：将不同分支的处理结果统一为相同的输出格式
