Trae+Dify 1小时制作对话流OA请假智能体

大家好，我是九歌AI。

前几天《人人都会做智能体》社区的成员提问，OA请假可以用智能体实现吗？

图片展示的是一个名为“人人都会做智能体①群”的聊天界面。群内成员“一个有温度的昵称”提问，智能体输入我想请假几号到几号因为什么事，自动填写好请假申请单。接着，群内成员“这些单据助手需要怎么处理才能变成系统需要的结构化数据”进行回复，群主“这个其实很简单”并附上音乐符号。该图片与上下文紧密相关，是成员提问及群主回复的截图，引出接下来基于对话流的请假智能体制作的内容。

我第一反应是这种问题有点太简单了，但是转念一想，越是这种简单的任务，反而更有科普价值，因为很多人还没深入了解过智能体（Agent）到底是什么，我不能先入为主的将其定义为没有必要的简单。想了解智能体是什么，可以先看我之前的这篇文章。

【人人都会做智能体】Agent是什么,简单中等复杂商用的智能体又是什么?

所以今天我们一起来实现一个基于对话流的请假智能体，是一个非常简单的智能体。最终的实现效果是这样。

图片展示的是国内某知名AI编辑器中OA请假智能体的界面。界面上方显示“OA请假智能体”及“New conversation”选项，下方有“Talk to Bot”按钮。该图片位于介绍搭建OA对话流请假智能体前，先需开发简单OA请假管理系统的背景中，用于说明在该AI编辑器中开始制作软件的操作界面，为后续优化提示词、重新开始制作软件做铺垫。

好，下面来一步步拆解这个智能体是怎么做出来的。不过在搭建OA对话流请假智能体，我们先需要自己开发个简单的OA请假管理系统，因为我们没有现成的OA系统接口可以用。

这个OA请假管理系统很简单，有个前台的请假申请页面和后台的审批页面，然后能提供接口就可以了。

打开国内某知名AI编辑器，新建项目文件夹，在Builder模式里，选择DeepSeek R1,输入提示词，开始制作软件。下面是第一次生成过程，bug非常多，只能重新优化提示词，重新开始。

图片展示了使用国内某知名AI编辑器制作OA请假智能体的代码界面。左侧是index.html文件代码，包含HTML和JavaScript部分，如计算请假小时、提交请假、更新请假状态等方法。右侧是Builder模式下的Chat界面，显示了openapi.yaml文件内容，其中包含API接口定义，如请假申请、请假审批等。该图片与上下文紧密相关，直观呈现了制作过程中的代码与API接口情况，辅助说明了如何在AI编辑器中进行相关操作。

关于提示词怎么写，可以看一下我以前的这篇文章。下面的提示词是我第二次优化的版本，第一次我感觉思路错了，AI编辑器在跑偏的路上越跑越远，我直接删除了整个项目文件夹，优化了下面的提示词，重新生成。

智能体应用开发提示词模板技巧大全

帮我生成一个非常简单的OA请假系统，只有两个页面，前端请假页面为一个表单，包含请假类型、开始结束时间，请假时长，请假事由，备注等项，后台页面是一个审批页面，能够展示请假待审批列表，可以点击通过或者拒绝。请使用最简单的Djanog+ninja实现，数据存储使用Sqlite,网页简单美化即可，最后ninja能生成2个请假的API接口，一个是新增请假数据，另一个是查询请假状态，符合openjson格式。请安装以下过程生成

在当前文件夹下使用venv 生成新的Python环境

安装django ninja 等必须的库

创建django新的项目和新的应用-OA请假

创建OA请假的前端页面和后端视图等代码

使用sqlite存储数据

使用ninja创建请假的2个接口，并配置好urls.py

启动django ，使其能直接访问请假界面，输入管理员路径，可以查看和审批请假记录

访问/docs 能测试api接口

输入优化后的提示词，开始生成！

图片展示的是Trae+Dify生成代码界面。左侧为代码编辑区域，显示Python代码，有“venv”和“django”等关键词。右侧是生成代码的界面，当前处于“Builder”模式，提示“代码的生成是“预测的代码”，AI 将帮你解决”。下方有“Trae+Dify”生成的Python代码，包括django ninja的安装、创建新的Django项目和应用、创建前端页面和后端视图等代码，还提示使用sqlite存储数据、使用ninja创建请假接口并配置urls.py等。该图片与文档中生成代码流程上下文对应，展示了生成代码的具体内容。

软件构建完成，我们启动Django查看一下效果。

（1）前台请假申请页面

本地访问地址 http://localhost:8000

图片展示的是Django项目中前台请假申请页面。页面上方显示“请假申请表”标题。申请人、请假类型、开始时间、结束时间、请假事由、备注等字段依次排列，其中请假类型下拉框已选“病假”，开始时间和结束时间输入框显示“yyyy/mm/dd/----”，请假事由和备注输入框为空。页面底部有一个蓝色的“提交申请”按钮。该图片与文档中“前台请假申请页面”的描述对应，直观呈现了请假申请表的界面样式。

（2）后台审批功能

本地访问地址：http://localhost:8000/approve/

图片展示的是Django OA请假系统后台审批功能的页面。页面标题为“待审批列表”，列出了两条请假记录，申请人分别为“九驭AI”和“九驭AI大模型”，请假类型分别是年假和病假，开始时间分别为2025年11月12日12:12 p.m.和2025年11月11日1:01 a.m.，请假时长均为24.0小时。每条记录右侧有“通过”和“拒绝”两个操作按钮。该图片与文档中介绍Django OA请假系统后台审批功能的内容相关，直观呈现了审批页面样式及数据展示情况。

（3）数据库增删改

图片展示了Django项目中OA请假系统相关文件及数据库界面。左侧是项目文件结构，包含admin.py、api.py等文件。中间是数据库界面，显示了auth_group、auth_user等表，其中“leave_request”表有id、applicant、leave_type等字段。右侧是SQLite Viewer界面，呈现了“leave_request”表数据，如id、applicant、leave_type、start_time等信息。该图片与上下文介绍的Django项目中OA请假系统开发内容相关，直观呈现了系统部分代码及数据库数据情况。

（4）API接口调用

$图片展示了Django项目中NinjaAPI的API文档界面。上方显示版本为1.0.0，OAS为3.1。下方有“default”分类，包含“POST /api/add_leave Add Leave”和“GET /api/check_status/{request_id} Check Status”两个API接口，分别对应请假申请和查看请假状态功能。该图与文档中“API接口调用”内容相关，直观呈现了项目中API接口的定义和操作方式。$

API这里面还是有坑的，主要是Api请求的数据不规范，需要用Pydantic库限定一下，我也不想重新生成了，直接使用Chat模式修改。引用api.py文件，并输入以下结构化提示词：

1.请对api.py 中add_leave 、check_status两个接口使用Pydantic重构 2.每个接口必须有默认参数值，并且可以在api/docs页面直接点击try it就可以运行。

图片展示了OA系统请假API代码。左侧是项目文件结构，中间是views.py和api.py代码，右侧是Chat界面。api.py中定义了NinjaAPI实例，add_leave接口接收request和payload，创建LeaveRequest对象并返回id和status；check_status接口接收request_id，返回status、reviewer和created_at。代码中还定义了LeaveRequest和LeaveStatusResponse类。该图片与文档中对接Dify自定义工具的步骤相关，展示了对接所需的API代码部分。

点击对api.py文件进行修改保存后，重启Django（略过后面继续改Bug的无聊时间）访问localhost:8000/api/docs 查看效果。

图片展示的是Dify中OA请假智能体的待审批列表界面。界面上方标题为“待审批列表”，下方有“申请人”“请假类型”“开始时间”“请假时长”“操作”等列标题。当前列表为空，仅在底部有“公众号#九歌AI大模型”的水印。该图片与文档中将OA请假的api对接到Dify作为自定义工具的上下文相关，展示了对接后的界面效果。

好了，OA系统开发完毕，我们先将OA请假的api对接到Dify中作为自定义工具。

1.在Dify中新增自定义工具，访问ip:8000/api/docs/openapi.json，将json数据粘贴到dify中，需要自己添加servers变量。这里面的IP一定要用dify能访问到的ip。

 "servers": [
    {
      "url": "http://172.25.16.1:8000",
      "description": "Development server"
    }
  ]

图片展示了NinjaAPI的Add Leave接口信息。上方显示版本为4.0.0，GAS为1.1，还有公众号相关标识。下方是default接口，为POST类型，路径为/api/add_leave。Request body为必填，类型为application/json，示例内容包含申请人姓名、请假类型、开始时间、结束时间、部门、备注等字段。该图与上下文关系紧密，是基于Dify创建对话流智能体步骤中对新增OA请假接口进行测试时所涉及的接口信息展示。

2.对新增的OA请假接口进行测试。

图片展示的是对新增的OA请假接口“leave_api_add_leave”的测试界面。界面中显示了鉴权方法为“无”，参数和值部分列出了“applicant”为九歌、“leave_type”为病假、“start_time”为2025 - 03 - 16T21:42:07.594445、“end_time”为2025 - 03 - 17T21:42:07.594445、“reason”为身体病了、“remarks”为空。下方有“测试”按钮，测试结果区域提示“测试结果将显示在这里”。该图片与文档中对新增OA请假接口进行测试的内容相关，展示了测试的具体参数设置界面。

OK，OA工具已经没有问题，我们开始基于Dify**（0.15版本）**创建对话流智能体。对话流智能体的特点就是每次对话就有从开始的节点重新运行工作流，但是会话变量已经发生变化。

图片展示了Dify平台创建空白应用的界面。左侧为应用类型选择区域，有聊天助手、Agent、文本生成应用、Chatflow、工作流等选项，其中Chatflow被选中。右侧是Chatflow的介绍，说明其基于工作流编程，适用于多轮对话场景，具备记忆功能。下方有应用名称及图标填写区域，以及“创建”按钮。该图片与上下文紧密相关，是基于Dify创建对话流智能体操作流程中业务需求分析步骤的展示，直观呈现了创建应用的界面和选项。

智能体的制作步骤主要分为以下7个步骤：

图片展示了智能体实训教学任务架构，分为7个步骤。步骤1为业务需求分析，步骤2是智能体工作流设计，步骤3为提示词工程设计，步骤4是智能体工具配置，步骤5是智能体应用构建，步骤6是智能体测试调优，步骤7是智能体发布。各步骤以不同颜色线条标识，箭头指向右侧，直观呈现了智能体制作的流程顺序。该图与上下文紧密相关，是对智能体制作步骤的总结，为后续制作智能体提供清晰的步骤指引。

下面我们根据这7个步骤，实现这个智能体。

（1）业务需求分析

整体的业务不复杂，我们用伪代码的方式将业务逻辑理清楚。

1.用户在聊天对话说 “自己身体不舒服，帮他请个假” 2.请假助手通过大模型识别到这是个“请假申请”类问题，但是请假具体信息不明确，缺少天数 3.助手于是继续让用户补充信息 4.用户回答2天 5.助手于是获得了所有关于请假的信息，于是开始调用OA请假系统的接口 6.助手调用成功，返回给用户回复“您的请假信息已经提交审批流程，请稍后查询状态。具体请假信息如下：XXX” 7.用户继续提问“请假通过了吗”，助手识别为“请假查询”类问题，于是调用状态查询接口，并回复“审批中” 8.管理员如果后台通过了审批 9.用户继续提问“请假通过了吗”，助手查询后回复“已通过审批”

（2）工作流设计

我们根据上面梳理的业务逻辑，直接在Dify（0.15版本）上把工作流搭建起来，可以不用填写参数提示词等，只需要把工作流串起来。这一步其实应该用思维导图把工作流画出来，但是我偷懒了。

图片展示了请假智能体的工作流设计。从开始节点出发，依次经过请假申请提交、请假申请已提交、请假申请已通过、请假申请已拒绝等节点，每个节点包含具体操作及参数。如请假申请提交节点有“open_api_add_leave”操作，参数包括“leave_type”等；请假申请已通过节点有“leave_api_check_status”操作，参数有“leave_id”等。该图与上下文紧密相关，直观呈现了请假智能体业务逻辑的工作流程。

（3）提示词工程设计

这一步骤，需要对工作流中的节点提示词相关的部分，挨个进行参数的配置以及提示词的设计。其实都不难，按部就班的操作就可以。Dify内置的提示词生成功能还不错。我觉得难点是请求参数的提取以及会话变量的设置。

图片展示了Dify平台中制作请假智能体的工作流设计界面。左侧工作流图中，从“请假参数提取”节点开始，依次经过“会话请求保存”“关联请假信息”“请假审批参数提取”“判断流程ID是否为空”等节点，最后有“直接返回4”和“判断流程ID是否为空”的分支。右侧为“请假参数提取”节点的参数设置界面，显示了提取参数如申请人姓名、请假类型、开始时间、结束时间、请假理由等，还标注了参数类型、必填与否等信息。该图与上下文介绍的智能体工具配置步骤相关，直观呈现了工作流设计内容。

（4）智能体工具配置

这一步，是需要我们OA系统的请假工具在工作流中使用的前后节点进行参数的配置和测试。类似的操作我在之前的文章《Dify制作可视化智能体》这篇文章里面讲过。

图片展示了Dify平台中OA请假智能体的工作流设计界面。左侧是工作流整体结构，包含多个节点，如“判断请假信息是否完整”“请假审批”等。右侧是“判断请假信息是否完整”节点的详细设置界面，有IF和ELSE分支，分别设置请假参数是否为空的条件，如applicant、leave_type、start_time等。该图片与文档中“（5-6）智能体应用构建和测试”部分相关，直观呈现了工作流设计与节点设置情况。

（5-6）智能体应用构建和测试

这2步我们放在一起讲，主要就是调试整个智能体的细节和Bug，主要犯错的点是会话变量的保存，在请求参数这个地方，除了用户的询问，还需要加入会话变量。

图片展示的是Dify平台中“请假参数提取”环节的设置界面。界面中说明从用户对话中提取请假所需信息，包括请假结束时间、请假理由、备注等。关键部分是红色框内的指令，要求从用户提问开始，使用sys.query指令和历史记录中相关变量，如chat_result、chat_remark等，整理出请假所需变量值，未提取到则赋值为空。该图片与文档中制作对话流OA请假智能体的调试细节内容相关，是智能体调试时会话变量提取的步骤说明。

（7）智能体应用发布

这一步就更简单了，一键发布到Dify的探索区，或者讲智能体内嵌到你的网站、APP或者小程序里面。

图片展示了使用Trae+Dify制作的对话流OA请假智能体的对话示例。用户询问“身体不舒服”，智能体回复请假详情，包括请假人、类型、开始结束时间、请假理由等信息。用户回复“明天开始2天”，智能体确认提交成功，显示提交信息及审批状态。用户再次询问“审批结果怎么样了”，智能体回复请假审批结果为领导审批中，需耐心等待。该图直观呈现了智能体请假申请及审批流程。

好的，以上就是关于Trae+Dify制作对话流OA请假智能体的所有内容，做的相对比较粗糙，还有很多细节优化，比如请假的开始时间和结束时间的格式，审批流通过后的回复消息，也没有美化。因为时间精力有限，只能到此为止了。

在写文章的时候，也发现这个智能体细节还是有点多，一篇文章很难面面俱到讲清楚，只能把大致思路说一下。后期我将会推出专门讲解的视频来详细拆解这个智能体。