Dify 高级实验（07）：智能审批——如何让机器自动完成流程审批？
Dify 高级实验（07）：智能审批——如何让机器自动完成流程审批？
Dify 实验系列 · 高级 07/10 | 实验编号：DIFY-103-07
1. 实验目的
掌握企业流程自动化的规则路由范式：参数提取器（PE）从自然语言中提取结构化字段 → 代码规则引擎判定 → IF/ELSE 三路分支 → 各分支独立收尾。核心能力：
- 参数提取器：把一段报销申请文本转成金额/类型/部门/事由/员工编号五个字段；
- 规则引擎代码化：金额四档（无效/小额/中额/大额）+ 特殊费用类型规则，全部确定性判断；
- 三路互斥分支：自动通过 / 需审批 / 转人工，每个分支独立 End 节点收尾。
适合：报销/请假/采购审批、工单分级、风控拦截等「规则可描述」的流程场景。前置要求：中级实验 01 参数提取器、16 条件分支。
2. 场景设计
员工提交报销申请（一段自然语言），传统流程「提交 → 领导审批 → 财务审核」慢且标准不统一。本实验让机器秒级判定：
- 金额 < 1000 元 →自动通过；
- 1000-10000 元 →需部门经理审批；
- ≥ 10000 元 →转财务总监（人工）；
- 特殊规则：招待费超 500 元即使小额也需审批。
输入：expense_request（报销申请文本，如「报销 5000 元差旅费，市场部王五 E1001」）。
输出：三条分支各自的收尾结果（通过通知 / 审批通知 / 审批单 + 推送状态）。
3. 节点拓扑
开始（expense_request） → 参数提取器（amount / expense_type / department / reason / employee_id） → Code 审批规则引擎（action: auto_approve / need_approval / human_review / reject） → IF/ELSE 三路分支 ├─ 自动通过 → LLM 生成通过通知 → 结束（result_auto） ├─ 需审批 → Code 模拟通知审批人 → 结束（result_need） └─ 转人工/驳回 → Code 生成审批单 → Code HTTP 通知（模拟）→ 结束（result_human）4. 关键配置
4.1 参数提取器（pe_extract）
注意 PE 的查询字段名是query（与知识库/分类器的query_variable_selector相反），reasoning_mode: function_call，五个参数声明：
-data:instruction:|从以下报销申请内容中提取字段信息。注意： - amount 是报销金额（数字，单位元） - expense_type 是费用类型（差旅/办公/招待/设备，如无法归类填"其他"） - department 是所属部门 - reason 是报销事由（简要概括） - employee_id 是员工编号（如 E1001） - 如果某个字段没有明确信息，填 null 而不是编造parameters:-description:报销金额（元）name:amountrequired:truetype:number-description:费用类型（差旅/办公/招待/设备）name:expense_typerequired:truetype:string# department / reason / employee_id 同理……query:[start,expense_request]reasoning_mode:function_calltitle:参数提取type:parameter-extractor4.2 审批规则引擎（cd_rules）
入参先float()防御转换（PE 提取的 number 到代码节点可能是字符串），输出action供分支路由：
defmain(amount,expense_type,department):amount=float(amount)ifamountelse0result={"amount":amount,"action":"","approver":"","reason":""}ifamount<=0:result["action"]="reject";result["reason"]="金额无效"elifamount<1000:result["action"]="auto_approve";result["reason"]="小额自动通过"elifamount<10000:result["action"]="need_approval";result["approver"]="部门经理";result["reason"]="需部门经理审批"else:result["action"]="human_review";result["approver"]="财务总监";result["reason"]="大额需财务总监审批"# 特殊规则：招待费即使小额也需审批ifexpense_type=="招待"andamount>500:result["action"]="need_approval";result["approver"]="部门经理"returnresult4.3 三路分支（cond_route）
字符串比较用is（不是=/==）；case_human是 OR 条件，同时覆盖human_review与reject；所有被边引用的 case_id 必须在 cases 中定义：
-data:cases:-case_id:case_autoconditions:-comparison_operator:isvalue:auto_approvevariable_selector:[cd_rules,action]logical_operator:and-case_id:case_needconditions:-comparison_operator:isvalue:need_approvalvariable_selector:[cd_rules,action]logical_operator:and-case_id:case_humanconditions:-comparison_operator:isvalue:human_reviewvariable_selector:[cd_rules,action]-comparison_operator:isvalue:rejectvariable_selector:[cd_rules,action]logical_operator:ortitle:审批路由分支type:if-else4.4 三个独立结束节点
多 End 的variable必须唯一：result_auto/result_need/result_human，各取本分支输出：
-data:outputs:-type:stringvalue_selector:[lm_approve,text]variable:result_autotitle:结束（自动通过）type:end5. 运行验证
| 输入（expense_request） | 期望行为 | 实测 |
|---|---|---|
| 报销 500 元交通费，市场部张三 E1001 | action=auto_approve，LLM 生成「已自动通过」通知 | 与预期一致 |
| 报销 5000 元差旅费，销售部李四 E1002 | action=need_approval，通知部门经理审批 | 与预期一致 |
| 报销 50000 元设备采购，技术部王五 E1003 | action=human_review，生成审批单并模拟推送，审批人财务总监 | 与预期一致 |
| 报销 800 元招待客户，市场部赵六 E1004 | 特殊规则生效：action=need_approval（而非自动通过） | 与预期一致 |
6. 采坑点
| 坑 | 现象 | 修复 |
|---|---|---|
多个 End 节点variable重名 | 三个结束节点全叫result时校验脚本查不出（双脚本全绿），运行结果互相覆盖 | 每个 End 用唯一 variable（result_auto/result_need/result_human），validate_dsl.py 已加跨节点检查（dify103_07 实测教训） |
IF/ELSE 字符串比较用=/== | Pydantic 校验报错（字符串只支持is/contains等），旧 DSL 迁移后运行才炸 | 字符串一律is；cases 必须定义所有被边引用的 case_id，否则该分支 UI 无连线（dify02_02 迁移实测） |
| 下游引用 PE 输出用错字段 | 引用pe_extract.text取不到值——校验器对 PE 只认parameters里声明的 name；PE 的text输出也不能作为 end/selector 来源 | 只引用parameters里声明的 name（amount/expense_type/employee_id）；要全量 JSON 用代码节点json.dumps打包（dify08_01 实证） |
| 代码节点入参类型不符 | PE 提取的 number 传进代码是字符串，"12000" > 10000报TypeError: '>' not supported between instances of 'str' and 'int' | 代码内float(amount) if amount else 0防御转换；同时 main() 参数名必须与 variables 的 variable 名一致（按名传参） |
7. 实验文档及源码获取
- 实验文档（完整操作步骤）：DIFY-103-07：智能审批工作流.md
- 源码（可直接导入）：dify103_07_智能审批工作流.yml
文章聚焦核心配置与采坑点；实验的完整分步操作（节点搭建/参数表/调试指引）见实验文档原文。
下一篇：Dify 高级实验（08）：智能告警——如何用 AI 替代固定阈值监控？
💬 你在这个实验的场景里踩过什么坑？欢迎评论区分享你的实战经验。