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-extractor

4.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"]="部门经理"returnresult

4.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-else

4.4 三个独立结束节点

多 End 的variable必须唯一：result_auto/result_need/result_human，各取本分支输出：

-data:outputs:-type:stringvalue_selector:[lm_approve,text]variable:result_autotitle:结束（自动通过）type:end

5. 运行验证

输入（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 名一致（按名传参）