Trae+Dify 一小時制作對話流OA請假智能體，真是太體貼了！ 原創
前幾天《人人都會做智能體》社區的成員提問，OA請假可以用智能體實現嗎？
我第一反應是這種問題有點太簡單了，但是轉念一想，越是這種簡單的任務，反而更有科普價值，因為很多人還沒深入了解過智能體（Agent）到底是什么，我不能先入為主的將其定義為沒有必要的簡單。想了解智能體是什么，可以先看我之前的這篇文章。
【人人都會做智能體】Agent是什么,簡單中等復雜商用的智能體又是什么?
所以今天我們一起來實現一個基于對話流的請假智能體，是一個非常簡單的智能體。最終的實現效果是這樣。
好，下面來一步步拆解這個智能體是怎么做出來的。不過在搭建OA對話流請假智能體，我們先需要自己開發個簡單的OA請假管理系統，因為我們沒有現成的OA系統接口可以用。
這個OA請假管理系統很簡單，有個前臺的請假申請頁面和后臺的審批頁面，然后能提供接口就可以了。
打開國內某知名AI編輯器，新建項目文件夾，在Builder模式里，選擇DeepSeek R1,輸入提示詞，開始制作軟件。下面是第一次生成過程，bug非常多，只能重新優化提示詞，重新開始。
關于提示詞怎么寫，可以看一下我以前的這篇文章。下面的提示詞是我第二次優化的版本，第一次我感覺思路錯了，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接口
輸入優化后的提示詞，開始生成！
軟件構建完成，我們啟動Django查看一下效果。
（1）前臺請假申請頁面
本地訪問地址 http://localhost:8000
（2）后臺審批功能
本地訪問地址：http://localhost:8000/approve/
（3）數據庫增刪改
（4）API接口調用
API這里面還是有坑的，主要是Api請求的數據不規范，需要用Pydantic庫限定一下，我也不想重新生成了，直接使用Chat模式修改。引用api.py文件，并輸入以下結構化提示詞：
1.請對api.py 中add_leave 、check_status兩個接口使用Pydantic重構
2.每個接口必須有默認參數值，并且可以在api/docs頁面直接點擊try it就可以運行。
點擊對api.py文件進行修改保存后，重啟Django（略過后面繼續改Bug的無聊時間）訪問localhost:8000/api/docs 查看效果。
好了，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"
}
]
2.對新增的OA請假接口進行測試。
OK，OA工具已經沒有問題，我們開始基于Dify（0.15版本）創建對話流智能體。對話流智能體的特點就是每次對話就有從開始的節點重新運行工作流，但是會話變量已經發生變化。
智能體的制作步驟主要分為以下7個步驟：
下面我們根據這7個步驟，實現這個智能體。
（1）業務需求分析
整體的業務不復雜，我們用偽代碼的方式將業務邏輯理清楚。
1.用戶在聊天對話說 “自己身體不舒服，幫他請個假”
2.請假助手通過大模型識別到這是個“請假申請”類問題，但是請假具體信息不明確，缺少天數
3.助手于是繼續讓用戶補充信息
4.用戶回答2天
5.助手于是獲得了所有關于請假的信息，于是開始調用OA請假系統的接口
6.助手調用成功，返回給用戶回復“您的請假信息已經提交審批流程，請稍后查詢狀態。具體請假信息如下：XXX”
7.用戶繼續提問“請假通過了嗎”，助手識別為“請假查詢”類問題，于是調用狀態查詢接口，并回復“審批中”
8.管理員如果后臺通過了審批
9.用戶繼續提問“請假通過了嗎”，助手查詢后回復“已通過審批”
（2）工作流設計
我們根據上面梳理的業務邏輯，直接在Dify（0.15版本）上把工作流搭建起來，可以不用填寫參數提示詞等，只需要把工作流串起來。這一步其實應該用思維導圖把工作流畫出來，但是我偷懶了。
（3）提示詞工程設計
這一步驟，需要對工作流中的節點提示詞相關的部分，挨個進行參數的配置以及提示詞的設計。其實都不難，按部就班的操作就可以。Dify內置的提示詞生成功能還不錯。我覺得難點是請求參數的提取以及會話變量的設置。
（4）智能體工具配置
這一步，是需要我們OA系統的請假工具在工作流中使用的前后節點進行參數的配置和測試。類似的操作我在之前的文章《??Dify制作可視化智能體??》這篇文章里面講過。
（5-6）智能體應用構建和測試
這2步我們放在一起講，主要就是調試整個智能體的細節和Bug，主要犯錯的點是會話變量的保存，在請求參數這個地方，除了用戶的詢問，還需要加入會話變量。
（7）智能體應用發布
這一步就更簡單了，一鍵發布到Dify的探索區，或者講智能體內嵌到你的網站、APP或者小程序里面。
好的，以上就是關于Trae+Dify制作對話流OA請假智能體的所有內容，做的相對比較粗糙，還有很多細節優化，比如請假的開始時間和結束時間的格式，審批流通過后的回復消息，也沒有美化。因為時間精力有限，只能到此為止了。
在寫文章的時候，也發現這個智能體細節還是有點多，一篇文章很難面面俱到講清楚，只能把大致思路說一下。后期我將會推出專門講解的視頻來詳細拆解這個智能體。
本文轉載自公眾號九歌AI大模型 作者：九歌AI
原文鏈接：??https://mp.weixin.qq.com/s/-V2yb_Nfhmb9znpTLG8xkw??
