用 Flue 做 LINE 智慧客服與預約系統 POC：Agent 不取代規則系統，而是用自然語言操作規則系統
Threads 作者以 LINE 智慧客服 + 預約系統 POC 為例，說明為何會偏向使用 Flue：LINE Bot 本質是 webhook、驗證、訊息解析、agent/workflow、工具呼叫與回覆的事件流程；Flue 的 agents、workflows、channels、tools、sandboxes 與可部署 TypeScript harness，適合把 AI agent 放在多通道、流程型、可部署的 POC 裡。文章以瑜伽教室預約為例，拆出 YogaBookingAgent、booking tools、database、booking engine、RAG 與人工客服的責任邊界。
LINE Bot · AI Agent · Booking Workflow
用 Flue 做 LINE 智慧客服與預約系統 POC
Threads 作者 r23456999 分享，如果要做「LINE 智慧客服 + 預約系統」POC，目前會偏向使用 Flue。原因是 LINE Bot 的本質不是單純聊天，而是一條事件處理鏈：使用者訊息進來後，經 webhook、驗證、解析，再進入 agent / workflow、查資料、呼叫工具，最後回覆 LINE。
LINE 智慧客服的基礎流程
作者把 LINE Bot 架構拆成一條非常清楚的 pipeline：
使用者傳訊息
→ LINE webhook
→ 後端驗證
→ 解析訊息
→ agent / workflow
→ 查資料、呼叫工具
→ 回覆 LINE這個觀點重要，因為很多「智慧客服」失敗的原因，是把 AI 當成萬能聊天機器人，而不是把它放進一個具備權限、狀態、規則與例外處理的系統裡。
以瑜伽教室預約系統為例
作者提出最小 POC 可以長這樣：
LINE Bot
→ webhook
→ flue channel / route
→ YogaBookingAgent
→ booking tools
→ database
→ 回覆使用者一開始不需要很多 agent；一個主 agent 就夠，例如 YogaBookingAgent。重點不是炫技地拆多 agent，而是把責任邊界切乾淨。
YogaBookingAgent 應該負責什麼
自然語言理解
理解「我想約這週三晚上的瑜伽」這類非結構化需求，解析日期、時間、課程類型與使用者意圖。
補問缺漏資訊
若使用者沒說清楚日期、課程、老師、會員身分或人數，agent 應主動補問，而不是亂猜。
查詢與推薦
查課表、比對名額，根據需求推薦合適課程。
呼叫工具
確認資訊後呼叫 create_booking、cancel_booking 等 booking tools，讓工具執行真正狀態變更。