ENGINEERING CASE STUDY · AGENT PLATFORM
工程案例
用單一 LINE 入口承接多種 AI 任務，再以語意路由與模組化工作流分派到 19 個可獨立維護的子流程。
問題與限制
問題
RAG、事實查證、新聞、圖像和網頁任務若全部塞在同一 Bot 流程，會快速形成高耦合、難觀測、難測試的巨大工作流。
限制
- 使用者只看到一個 LINE 對話入口，系統必須自行判斷任務類型。
- 19 個子流程使用不同 API、資料源與回傳格式，不能互相拖累。
- 新能力需要能獨立新增、替換與停用，不改動 LINE 主流程。
- 所有結果最終都要符合 LINE 訊息限制與一致的回覆格式。
架構與技術決策
系統流程
- 01 對話入口 LINE Webhook · message context
- 02 意圖路由 Gemini intent analysis · task contract
- 03 主工作流 n8n orchestration · error boundary · dispatch
- 04 19 個能力模組 RAG · FACT · NEWS · IMAGE · WEB · data tools
- 05 回覆正規化 result adapter · message formatting · LINE Reply API
技術選型
n8n
讓路由、外部 API、錯誤分支與資料轉換保持可視化，也方便把能力拆成可替換子流程。
Gemini intent routing
相較關鍵字規則，更能處理自然語言中混合或不完整的任務描述。
主流程 + 子流程
主流程只負責入口、路由與回覆契約，能力模組可獨立開發與維護。
LINE Messaging API
以真實對話通路驗證 Agent 平台，而不是只停留在後台流程 Demo。
我的具體責任
- 01
設計主流程、意圖分類、子流程 dispatch 與統一回覆 contract。
- 02
整合 RAG、事實查證、新聞、圖片、爬蟲與資料查詢等 19 個模組。
- 03
處理 LINE Webhook、訊息格式、API token 與各服務錯誤邊界。
- 04
整理可公開匯入的 n8n workflow 與分層教學文件。
評測方式與成果
以能力矩陣逐項驗證路由是否進入正確子流程，並檢查每個模組在成功、空結果與外部 API 失敗時，都能回到符合 LINE 限制的統一回覆契約。
失敗與修正
- 失敗現象
- 早期能力直接串在同一工作流，新增節點後理解與除錯成本快速上升。
- 修正方式
- 把入口、意圖路由與能力執行拆成主流程和獨立子流程。
- 工程教訓
- Agent 平台的擴展性來自模組邊界，不是節點數量。
- 失敗現象
- 只使用關鍵字分流時，複合問句與模糊描述容易走錯能力。
- 修正方式
- 使用 Gemini 產生受限意圖結果，再由 n8n 做確定性 dispatch。
- 工程教訓
- 模型適合處理語意，工作流適合執行受控決策。
- 失敗現象
- 不同模組各自回傳文字、圖片或錯誤，LINE 端處理分支持續膨脹。
- 修正方式
- 加入 result adapter 與統一回覆 contract。
- 工程教訓
- 工具可以異質，但平台邊界必須一致。
證據與延伸資料
Deep dive · 深入實作
技術實作細節
接續案例摘要，深入查看工作流、實作決策、架構圖與專案產出。Context（情境）
LINE 作為企業對外或內部溝通管道時，使用者會提出技術問題、新聞查詢、圖片生成等多元需求。情境需要單一入口接收訊息後，依內容類型自動分流至對應能力（RAG、事實查證、新聞、圖像、爬蟲等），並將回覆格式化送回 LINE。
Challenge（痛點）
- 若每種需求各建一個 Bot，維護與體驗分散；若單一流程處理所有類型，邏輯龐大難以擴充。
- 需以 AI 辨識意圖並路由至正確子流程，且回覆需符合 LINE 顯示（長文分段最多 5 則等）。
Solution（架構＋做法）
提供一個智慧化 LINE 自動回覆機器人：使用者傳送訊息後，由 Google Gemini 分析內容類型，並模組化路由到對應的子流程處理，涵蓋技術文件摘要、事實查證、RAG 知識檢索、新聞與股票、圖像生成、網頁爬取等，最後將回覆格式化並送回 LINE（支援長文自動分段，最多 5 則）。
架構概覽
主流程 [MAIN] LINE CHATBOT：接收 LINE Webhook → 呼叫 Gemini 分析訊息 → 依內容類型路由至子流程 → 彙整 AI 回應 → 分段發送回 LINE。
19 個子流程模組 分為：
- AI 代理類：1399 RAG、MCP RAG、RAG Pipeline、ITR、FACT、CB、DR
- 資訊處理類：NEWS、News Agent Scrape、STOCK
- 圖像處理類：IMAGE Generator、Food Image、Image Editing、Image Module
- 網頁處理類：WEB、LINE CHATBOT Crawl
- 工具支援類：SUBS Module、Database Query Tool、FACT linebot 流程
LINE Webhook → [MAIN] LINE CHATBOT (Gemini 意圖分析) → 路由 dispatch
├── RAG (知識庫檢索)
├── FACT (事實查證)
├── NEWS / STOCK (即時資訊)
├── IMAGE (圖像生成與編輯)
└── WEB / CRAWL (網頁萃取)
→ Result Adapter 正規化 → 長文分段 (≤ 5 則) → LINE Reply API代表路徑分析：技術文件查詢 (RAG)
以使用者詢問「這份技術文件如何部署？」為例：
- Webhook 接收：主流程接收 LINE POST 請求並抽取使用者文字與
replyToken。 - 意圖判斷：Gemini 分析文字語意，判定為
TECH/RAG類別，回傳標準化 dispatch payload。 - 子流程執行：觸發
1399 RAG子流程，向後端知識庫發送查詢並等待結果。 - 結果轉接與分段：透過
Result Adapter將回傳文字格式化為繁體中文、500 字以內摘要，若文字過長自動切分為最多 5 則 LINE 訊息 Bubble，送出回覆。
異常處理邊界與個人職責
- 已實作之防護：
- 外部 API 呼叫逾時保護與降級文字回覆。
- LINE Webhook Token 一次性校驗，避免重複處理。
- 憑證管理：API tokens 全數移出程式碼並以環境變數注入。
- 待正式環境補足項目：
- 跨模組分散式 Tracing（目前依賴 n8n 內建 Execution log）。
- 自動重試指數退避（Exponential Backoff）與熔斷器。
- 人工客服接手流程（Human-in-the-loop fallback）。
- 職責邊界：本人負責 n8n 工作流拓撲架構、意圖分流契約設計、子流程模組拆分與 LINE Messaging API 介面串接；所整合之 Google Gemini、Jina 等模型能力屬於第三方 API，非本人研發。
若後續導入獨立於工作流程的 distributed tracing，仍需以權限隔離、寫入者身分、留存與失敗行為定義誰能修改稽核證據；LLM Agent 執行軌跡竄改研究提供了判讀這項信任邊界的具體實驗脈絡。
工作流示意（可搭配 n8n 課程流程圖）
以下為 n8n 工作流層級概念示意；實際主流程與子流程圖可於 GitHub 展示站 查看。
n8n 工作流 Level 1
n8n 工作流 Level 2 範例 1
n8n 工作流 Level 2 範例 2
技術棧與亮點
- n8n — 可視化工作流設計與執行
- Google Gemini — 訊息分析與回應生成
- LINE Messaging API — Webhook 接收與回覆
- RAG / MCP RAG / FACT — 知識檢索與事實查證
- 模組化 — 每項功能獨立子流程，易維護與擴充
- GitHub Pages — 工作流說明與流程圖展示站：poirotw66.github.io/n8n_workflow
Impact（架構成果與限制）
- 拓撲成果：1 主流程（LINE Webhook → Gemini 意圖分析 → 路由）+ 19 個子流程，將不同功能的開發與故障隔離，避免單一流程節點膨脹。
- 統一交付契約：單一 LINE 對話窗口即可支援多種異質任務，透過 Result Adapter 維持一致的終端呈現。
- 限制說明：本專案為工作流架構與分流能力展示，未具備正式生產環境之高併發監控與 SLA 紀錄，不宣稱營運穩定性保證。
Extension（可延伸方向）
- 新增更多子流程（如訂單查詢、表單填寫、預約排程），持續擴充能力邊界。
- 將主流程意圖分析改為可訓練或可設定的規則，降低對單一模型的依賴。
- 串接內部 API 或 CRM，從對話到業務動作一站完成。
相關連結
- Repository：github.com/poirotw66/n8n_workflow
- 展示網站（流程圖與說明）：poirotw66.github.io/n8n_workflow