AI Agent 课程文档

切换日光/暗黑模式

008. Dify 工作流接入报销审批 ​

学习目标 ​

这一节把 Dify 工作流真正接入到报销审批系统里。

学完后，你应该能理解：

  • 为什么审批规则不适合全部写死在代码里；
  • Dify 工作流的输入参数和输出结果怎么理解；
  • 职位等级和报销金额如何决定审批是否结束；
  • 后端为什么通过 API 调用 Dify 工作流；
  • .env 里为什么要配置 Dify 访问地址和密钥；
  • 小额报销和大额报销的审批路径有什么区别；
  • Dify 插件、API Key、iframe 嵌入分别解决什么问题；
  • Dify 和 LangGraph 在 AI 报销系统里的职责边界。

为什么审批流不直接写死？ ​

报销审批流程经常会变化。

例如：

  • 小额报销只需要直属主管审批；
  • 大额报销需要继续往上审批；
  • 不同公司、部门、职位的审批规则不同；
  • 财务或管理层可能需要看到流程图；
  • 后续可能需要调整金额阈值或审批层级。

如果全部写死在后端代码里，每次规则变化都要改代码、发版、验证。

Dify 工作流提供了一个可视化流程入口，可以把“什么时候审批结束”这类判断从业务代码里抽出来，让流程更容易查看、调整和验证。

工作流可以类比函数 ​

Dify 工作流可以先类比成一个函数。

函数有入参，也有返回值。工作流也是一样。

当前报销审批工作流的核心入参有两个：

参数含义
approve_pos_level当前审批人的职位等级
amount当前报销金额

工作流执行后会返回一个结果，用来表示审批是否结束。

可以先这样理解：

txt
输入：职位等级 + 报销金额
输出：是否结束审批

职位等级怎么来？ ​

用户表里保存的是用户所属职位的编码。

职位名称、职位等级等信息在职位表里。

所以如果想知道某个用户的职位等级，需要把用户表和职位表关联起来查询。

例如：

  • 张明是总经理；
  • 李强是技术经理；
  • 王强是前端主管；
  • 张三是普通员工。

职位等级的数字越小，职位越高。

例如：

职位等级含义
总经理最顶层，上面没有更高审批人
技术经理高于主管
前端主管高于普通员工
普通员工发起审批的人

当前审批走到哪个人，就把这个人的职位等级传给工作流。

用金额控制审批是否继续 ​

工作流会根据报销金额和职位等级做判断。

例如当前审批人是主管，规则可以理解成：

报销金额结果
小于 1000主管审批后结束
大于等于 1000主管审批后继续往上

工作流返回 Y，表示审批结束。

工作流返回 N，表示审批还要继续。

真实业务会更复杂，但核心思想一样：把业务规则变成流程判断。

发布工作流 API ​

Dify 工作流发布后，可以暴露成 API 给外部系统调用。

调用时需要准备：

  • 工作流 API 地址；
  • API Key；
  • 请求方式；
  • 请求 Body；
  • 输入参数；
  • 是否流式返回。

当前审批判断不是生成长文本，也不需要流式输出，所以调用时可以关闭流式模式。

请求体里要传入工作流需要的两个参数：

json
{
  "inputs": {
    "approve_pos_level": 2,
    "amount": 999
  },
  "response_mode": "blocking",
  "user": "user-id"
}

授权方式和模型平台 API Key 类似，都需要在请求头里带上密钥。

先用调试工具验证 API ​

在后端接入前，先用 API 调试工具直接调用 Dify 工作流。

验证思路是：

  • 传入职位等级 2；
  • 金额传 999；
  • 结果应表示审批结束；
  • 金额改成 1001；
  • 结果应表示继续审批。

这一步的目的不是为了替代后端，而是先确认 Dify API 本身能正常工作。

如果调试工具能调用成功，后端用同样的地址、密钥和参数格式去调用，就有了基础保障。

后端配置 Dify 地址和密钥 ​

后端需要在 .env 里配置 Dify 相关信息。

常见配置包括：

  • Dify API 基础地址；
  • 工作流 API 路径；
  • API Key；
  • 是否使用本机地址；
  • 超时时间。

生产服务器上的 .env 不会提交到 Git 仓库，所以需要手动到服务器上修改。

修改后要重新发布或重启后端服务，让新配置生效。

后端如何调用审批工作流？ ​

后端不是把 Dify 页面嵌进系统来完成审批判断，而是通过 API 调用 Dify 工作流。

可以这样理解完整链路：

  1. 用户发起报销申请；
  2. 后端创建审批单；
  3. 当前审批人点击通过；
  4. 后端读取当前审批人职位等级和报销金额；
  5. 后端调用 Dify 工作流；
  6. Dify 返回审批是否结束；
  7. 后端根据结果创建报销单，或继续流转给上级审批。

Dify 负责流程判断，后端负责业务数据和审批状态。

小额报销审批路径 ​

小额报销示例：

txt
张三发起 699 元酒店预订报销

流程可以理解成：

  1. 张三提交申请；
  2. 审批单流转给王强；
  3. 王强是张三的直属主管；
  4. 王强审批通过；
  5. 后端调用 Dify 工作流；
  6. 工作流判断金额小于阈值；
  7. 审批结束；
  8. 系统自动创建报销单。

小额报销不需要继续流转到更高层级。

大额报销审批路径 ​

大额报销示例：

txt
张三发起 1999 元酒店预订报销

流程可以理解成：

  1. 张三提交申请；
  2. 审批单先流转给王强；
  3. 王强审批通过；
  4. 后端调用 Dify 工作流；
  5. 工作流判断金额超过阈值；
  6. 审批继续往上；
  7. 审批单流转给李强；
  8. 李强可以继续通过或拒绝。

如果李强拒绝，申请会被驳回，不会自动创建最终报销单。

这说明 Dify 工作流影响的是“审批是否继续”，最终业务状态仍由后端控制。

审批记录怎么看？ ​

审批系统需要能看到当前审批走到了哪一步。

例如大额报销里，可以看到：

  • 第一轮由王强审批；
  • 王强审批通过；
  • 当前轮到李强审批；
  • 如果李强拒绝，申请状态变成驳回；
  • 被驳回后不会生成正式报销单。

审批记录很重要。真实企业系统里，审批不是只看最终状态，还要能追踪每一步是谁处理的、什么时候处理的、处理结果是什么。

Dify 在这里不是直接体现 AI 能力 ​

当前 Dify 的角色更像低代码工作流平台。

它负责：

  • 可视化编排流程；
  • 接收参数；
  • 判断审批是否结束；
  • 把结果返回给后端。

这一步没有直接体现大模型生成能力。

AI 能力主要体现在报销单审核里，例如：

  • 自动解析报销内容；
  • 根据报销规则检查是否合规；
  • 找出不符合规则的费用项；
  • 对不合规申请自动驳回；
  • 从一段自然语言里生成报销单；
  • 识别发票图片里的金额、类型、信息。

Dify 和 AI 审核可以同时存在，但它们承担的角色不同。

LangGraph 和 Dify 的职责边界 ​

AI 报销系统里同时会出现 LangGraph 和 Dify。

不要把它们混成一个东西。

工具当前角色
LangGraph处理 AI 报销审核、规则拆解、报销信息处理等代码级工作流
Dify作为低代码工作流平台，控制审批是否结束

LangGraph 更偏代码内的 Agent / 工作流控制。

Dify 更偏可视化流程编排和外部工作流调用。

在当前系统里，后端可以同时调用它们：一个处理 AI 审核，一个处理审批流转判断。

Dify 插件和 API Key ​

Dify 插件可以理解成工具。

有些插件可以直接用，有些插件需要配置 API Key。

例如：

  • Google Search 插件可能需要密钥；
  • 模型供应商插件需要模型平台 Key；
  • 后续自己开发的 Dify 插件也需要授权机制。

这和前面申请阿里云百炼、火山引擎 API Key 的逻辑类似：

txt
谁调用服务，谁就要提供凭证

后续开发 Dify 插件时，还会涉及 API Key 如何设计、保存、校验和使用。

Dify 应用能不能嵌入系统？ ​

Dify 的集成方式不止一种。

工作流适合通过 API 调用。

如果是 Chatflow 或 Agent 类型应用，可以发布后生成 iframe 代码，嵌入到自己的前端页面里。

两种方式的区别：

集成方式适合场景
API 调用后端控制业务流程，拿结果后继续处理业务
iframe 嵌入把 Dify 对话应用直接嵌入网页，让用户直接使用

审批工作流当前选择 API 调用，因为后端需要根据结果更新审批状态和报销单数据。

AI 生成报销单 ​

报销单不一定只能手动填写。

系统可以提供一段自然语言输入，让 AI 从文本里生成报销单。

例如输入一大段说明，里面包含两条报销信息：

  • 某次出差报销；
  • 某次培训报销。

AI 可以把这些信息拆出来，生成结构化报销单。用户再检查、修改、提交。

这类能力体现的是 AI 对自然语言的结构化处理。

AI 识别发票 ​

发票图片可以交给多模态模型识别。

系统上传发票后，AI 可以从图片中提取：

  • 金额；
  • 发票类型；
  • 开票信息；
  • 费用项目；
  • 其他票据字段。

识别结果不一定永远准确，所以仍然需要用户确认和系统校验。

这也是为什么 AI 不是简单替代业务系统，而是嵌入到业务流程里，提高录入和审核效率。

前端表格封装的关系 ​

报销系统里会出现很多表格。

表格不仅要展示数据，还可能支持：

  • 行内编辑；
  • 表单编辑；
  • 删除；
  • 批量编辑；
  • 从图片或文本中提取数据后填入表格。

这些表格底层都是数组数据驱动。后续前端会继续封装通用表格能力，让不同页面复用同一套交互模式。

对 JS 开发者来说，这部分会更接近熟悉的前端工程内容，但难度不会低，因为它涉及组件抽象、状态同步和业务表单联动。

实战环境部署收尾 ​

到这里，第一个实战项目的环境部署基本完成。

已经完成的核心环境包括：

  • 云服务器；
  • 宝塔面板；
  • MariaDB / MySQL；
  • PostgreSQL；
  • Milvus；
  • Redis；
  • Dify；
  • 后端服务；
  • 前端静态资源；
  • Nginx 反向代理；
  • HTTPS；
  • Dify 工作流接入；
  • 报销审批流程验证。

后面进入课程安排的其他部分时，会继续拆解每个项目的特色功能、技术难点，以及这些内容如何整理到简历和面试表达里。

AI Agent 课程学习文档。

Copyright © 2026