開始正式進入第一個實戰案例：做一支能讓公司同仁用「講白話」的方式請假的 AI 助理，這篇先講「我們到底要蓋什麼」、「為什麼要這樣設計」。

完工後長什麼樣子

在講架構之前，先看一輪實際的對話過程：

整個對話大致會經過三個階段，對應到截圖下面標的「首次提問」、「修改提問」與「表單送出」：

首次提問階段

同仁一開口先隨便打了句「怪怪的」，AI 當然聽不懂，於是很禮貌地回了一段引導文字，附上幾個範例句型（「我要請病假因為要去看醫生」之類），請對方講清楚一點。這一步的重點不是要多聰明，而是要「hold 得住」使用者亂打字的情況，並且用範例把使用者帶回正軌。同仁照著範例重講一次「我要請病假因為要去看醫生」，AI 就抓到重點了，直接產生了一張假單預覽 — 姓名、員編、部門這些個資會自動帶入，假別、時間也先給了一個預設值。

修改提問階段

這裡才是整支助理最有意思的地方：使用者不需要重新講一次完整句子，只要說「代理人改成 XXX，時間改成 12/30 到 12/31」，AI 就知道要在原本的假單上做「局部修改」，重新產生一張更新後的預覽。接著使用者按下確認送出，結果系統回了一句「抱歉，您的假單送出失敗，WF 訊息：(WF) 同時段同日期」— 這是真實系統會發生的情境，因為同一天同時段可能已經有另一筆假單卡著。這時候使用者只講了一句「時間改成 12/31」，AI 就把日期改掉，重新產生預覽，再送一次就成功了，還拿到一組 WF 單號。

表單送出階段

最後同仁還可以附上一張圖片（比如診斷證明或收據），AI 把附件一起打包進假單內容，顯示完整的送出結果：姓名、假別、時間、事由、代理人、還有附件縮圖，一次到位。

看完這輪對話，你應該可以感覺到這支助理有幾個特徵：它看得懂口語、能記住上下文（所以才能「局部修改」而不用整句重講）、會處理失敗重試、也能夾帶附件。這些特徵不是憑空長出來的，而是背後有一套明確的流程設計在撐著，這就是本篇要拆解的東西。

系統架構總覽

先看一下整體的系統架構圖：

這次的技術組合是 Ollama（補註：使用經典的Llama3:8B，表示這 workflow 舊模型也能跑得起來）+ LangGraph + LangChain + Flask，四個角色分工大致是這樣：

• Ollama + Llama 3：地端 LLM，負責所有需要「理解語意」的工作，例如判斷使用者是不是在講請假、把口語轉成結構化資料。因為請假內容牽涉到員工個資，用地端模型跑，資料不會出公司，這也是我們這系列一直強調「地端 AI」的原因。

• LangChain：負責把 LLM 呼叫、Prompt 模板、跟外部 API（員工資料查詢、假單送出）這些零件包裝成好用的元件。

• LangGraph：負責把這些元件串成一個「有狀態、會迴圈」的流程。之後會發現，這支助理的流程裡有好幾個「來回確認」「反覆追問」的迴圈，這正是 LangGraph 的 state 狀態機架構最擅長處理的情境。

• Flask：負責把整個東西包裝成一個 API 服務，讓對前端話框能跟後端溝通。

從上到下拆解六個處理節點：

1. 對話歸類：判斷這句話是不是在講請假，會跟 Llama 3 來回確認「對話類別為請假」，確認不了就會請使用者換個講法（對應到截圖裡的「怪怪的」那個情境）。

2. 請假提問補強：這一步會跟 LLM 要求「產生補強提問」，也就是根據目前收集到的資訊，判斷還缺什麼、該怎麼問使用者才最自然。

3. 假單資料檢查：反覆跟 Llama 3 確認假單的必填欄位是否都齊了，缺資料就往左邊丟出「AI 詢問缺漏資料」，回到對話框跟使用者要資訊。

4. 假單預覽：這一步比較特別，它不只用 LLM，還會呼叫右邊的「公司 EIP 對內 API」去查真實的員工資料（姓名、員編、代理人、到職日、剩餘假），拿到 JSON 格式的資料後，跟 LLM 產生的內容合併，組成一則「AI 發出預覽訊息」丟回對話框給使用者確認。

5. 假單送出：這一步是一般系統功能，不需要 LLM 判斷什麼，就是老老實實呼叫 EIP 的「假單送出 API」。

6. 成功/失敗訊息處理：單純把 API 回應轉成人看得懂的訊息，回給使用者。

架構圖其實也在說明，「智能」跟「可靠」要分開處理：判斷語意、理解使用者意圖這種模糊地帶，交給 LLM 去處理最合適；但真正牽涉到「送出去就是送出去了」的關鍵動作（呼叫內部 API、寫入正式系統），就該用最單純、最可預期的邏輯去做，不要讓 LLM 的不確定性摻進來。

流程設計

第一階段：首次提問過濾檢查

使用者一開口，不會馬上進到「幫你排假」的複雜邏輯，而是先經過一道很輕量的過濾檢查：這句話看起來像不像是在講請假？

為什麼要多這一階段，而不是直接把每句話都丟給後面一整套複雜的解析流程？因為使用者打字很自由，什麼都可能講，如果每一句話（包含亂打的「怪怪的」）都要走完整套 JSON 產生、資料檢驗的重邏輯，一來浪費運算資源，二來很容易讓後面的節點收到根本不完整、無意義的輸入，反而更難處理。所以先用一道便宜的關卡把「看起來完全不相關」的輸入擋下來，沒通過就「反覆提示」— 用範例句子引導使用者，而不是丟一句冷冰冰的「我聽不懂」。這一關的設計精神其實很像寫程式時的輸入驗證：先擋掉明顯不合法的情況，後面的邏輯才不用一直防禦性判斷。

第二階段：修改提問迴圈 — 整支助理最核心的部分

現在才真正進入請假資訊的處理迴圈，這裡有四個子步驟：

• 提問內容正規化：把使用者口語化的句子（「我要請病假因為要去看醫生」）轉換成比較統一的語意表示，方便後面程式邏輯處理。

• JSON 產生器：把正規化後的內容，轉成結構化的 JSON — 假別、開始時間、結束時間、代理人、事由等等，這才是後端系統真正看得懂、能拿去比對跟送出的格式。

• 資料檢驗：檢查這份 JSON 缺不缺欄位、格式對不對、日期邏輯合不合理（比如結束時間有沒有比開始時間早）。

• 預覽產生：把驗證過的資料組成一份人看得懂的假單預覽，回給使用者確認。

這四步中間有一條「反覆追問」的迴圈線，從資料檢驗一路繞回提問內容正規化。回想一下截圖裡的情境：使用者看到預覽後，只講了一句「代理人改成 XXX，時間改成 12/30 到 12/31」，系統並沒有要求使用者把整句話重講一次，而是直接在既有的 JSON 上做局部更新，再重新跑一次驗證跟預覽產生。

這種「局部修改、不用重來」的體驗，技術上依賴的就是這個迴圈設計：整個對話狀態（目前已經收集到的假單 JSON）會被保留下來，每次使用者新增一句話，都是拿新的資訊去「更新」既有狀態，而不是從零開始重新解析一整句話。這也正是為什麼後面實作會選 LangGraph — 它的 state graph 天生就是為了處理「某個節點執行完，依條件決定要往下走還是繞回前面某個節點，而且狀態要一路帶著走」這種情境而設計的，跟這裡的「反覆追問」迴圈可以說是天作之合。

另外還出現了一個很寫實的情境：使用者確認送出後，系統回覆「送出失敗，WF 訊息：同時段同日期」。這其實是預覽產生之後、真正呼叫 EIP 送出之前（或送出當下）才會發現的衝突，流程設計上並沒有因為失敗就把使用者打回第一關重新來過，而是讓使用者可以直接針對失敗原因說「時間改成 12/31」，一樣走回這個修改迴圈，局部調整後重新產生預覽再送一次。失敗不等於重來，這是設計這種多輪對話流程時很重要的一個原則 — 要盡量讓使用者用最小的修正動作，回到可以繼續的狀態，而不是逼對方從頭講一次。

第三階段：表單送出

當預覽產生、使用者按下確認送出之後，才真正進入表單送出階段，這裡做三件事：

1. 員工資料反查：跟公司 EIP 系統要真正的員工資料（姓名、員編、部門、代理人、剩餘假這些），確保假單上寫的是正確、即時的資訊，而不是完全依賴 LLM 生成或使用者自己講的內容。

2. EIP API 呼叫：把組好的假單資料真的送進公司內部的請假系統，這一步才是「真正生效」的動作。

3. 回應使用者：把 EIP 回傳的結果（成功並附上 WF 單號，或失敗附上原因）轉成使用者看得懂的訊息，回到對話框。

這三個動作跟前面「修改提問迴圈」比起來，少了很多來回討論的空間，因為走到這一步，資料理論上已經確認過、驗證過了，剩下的就是老老實實地跟 EIP 系統對話、確認結果。這也呼應到前面架構圖裡看到的分色邏輯：越靠近「真正寫入正式系統」的動作，越應該用確定性高、可預測的邏輯去執行，而不是繼續讓 AI 自由發揮。

小結

這篇沒有寫半行程式碼，只把整支請假 AI 助理的流程講清楚：

• 用首次提問過濾檢查擋掉明顯無關的輸入，並用範例句子引導使用者

• 用一個可以反覆追問、局部修改的迴圈，把使用者口語內容一步步轉成結構化假單，並優雅地處理送出失敗這種真實世界會發生的狀況

• 最後才進入表單送出，而且刻意把「跟正式系統對話」這件事，設計成不依賴 LLM 判斷的一般系統功能。