案例研究：AI 客服即時回覆訂單詢問
這個案例跟《門市缺貨 → 跨店調撥》是同一個零售 Demo 專案，但用的是 Flow Agent 而不是 Managed Agent，示範一種更輕量的用法：客戶在電商網站的客服對話窗即時詢問訂單狀態，由 AI 直接查真實資料回覆，不用等真人客服上線。
情境
客戶在零售電商網站瀏覽商品時，在畫面右側的客服對話窗打了一句：
我想查我的訂單
過去這類問題要等真人客服上線才會被回覆，客戶往往等到隔天才收到回音。
這個案例讓 AI 客服代理即時接手：客戶送出訊息後，電商網站立刻把訊息寫進客服後台的對話紀錄並回應客戶（不用等 AI 處理完），同時在背景把這句話連同一組限時、限範圍的存取憑證轉發給 Flow Agent。Agent 用這組憑證即時查詢客戶的真實訂單資料，幾秒內生成回覆、寫回同一則對話。真人客服隨時可以在同一串對話插話接手，不會跟 AI 的回覆衝突。
Flow Agent：客服代理
專案的 Flow Agent 列表裡只有一個客服代理，對應到一個叫 wf-customer-service 的 Workflow。
打開它會看到一個 4 個節點組成的視覺化流程：
- Entry：工作流程的起點。
- Init：初始化 context。
- Agent：客服代理主回應（LLM stream），是實際呼叫模型生成回覆的節點，成功後接到 Listen，失敗則接到 Error。
- Listen：等待客戶輸入，收到下一句話後回到 Agent 繼續對話。
- Error：推送錯誤訊息（LLM 呼叫失敗時的備援節點）。
Agent 節點的 Prompt：先判斷身份，再決定能不能查
點開 Agent 節點是一個 Stream LLM Completion Message 處理節點，Prompt 用 {{#if prevPayload.user}} 判斷這位客戶是否已登入會員：
- 已登入：Prompt 會帶入這位客戶的會員編號，並指示需要查詢這位客戶的訂單時，要依 customer-service-api 技能說明的方式呼叫 API 取得真實資料，不可以憑空回答或編造訂單內容。
- 未登入（訪客）：Prompt 明講不能查詢任何個人訂單資料，客戶問訂單狀態時要告知需要先登入會員才能查詢，不可以嘗試用其他方式猜測。
Prompt 裡還有一段 <api_access>，說明呼叫電商網站 API 所需的連線資訊由平台在每一輪對話注入，Agent 只能直接使用注入的值，不能自己猜網址或改寫網域，避免 Agent 把查詢範圍擴大到這位客戶以外的資料。
這個案例跟前一個案例的設計差異
跟《門市缺貨 → 跨店調撥》案例裡的 Managed Agent 相比，這個客服代理刻意選了不一樣的路線：
- 前一個案例用 Managed Agent 掛載 Semantic Model 做查詢，這個案例的 Agent 節點沒有掛 Semantic Model，而是在 Prompt 裡指示呼叫電商網站自己的 API 取得訂單資料。訂單資料本來就在資料庫裡，理論上也可以走 Semantic Model 查詢，但客服對話窗這種場景要確保只能查詢當下這位已登入客戶自己的訂單。如果讓 LLM 自己決定要查哪個會員編號，就有被說服去查別人資料的風險，因此改用平台每輪對話注入的短效存取憑證直接呼叫 API，查詢範圍在憑證層級就被鎖死，不是靠 Prompt 約束。
- 這個案例目前只有讀取（查客戶自己的訂單），沒有掛任何會寫入資料的 Automation Tool，所以不需要治理閘門；如果之後要讓這個 Agent 代客戶操作（例如建立退換貨申請），必須另外設計一個需要人核可的寫入工具，不能讓 Agent 直接呼叫外部系統做有實際影響的動作。