如果今天要設計一個同時支援售前與售後的電商 AI 客服，你會怎麼設計？

這是前一陣子準備外商 System Design 面試時剛好遇到一題，這題很適合拿來當作練習並且理解 Baseline 的概念。

因為看到「電商 AI 客服」，很容易立刻想到 RAG、Tool、Workflow、Agent，然後開始把熟悉的 Component 往架構圖裡放。但更好的順序，是先確認核心任務最低限度需要哪些能力，再隨著 Requirement 增加，辨識目前的 Baseline 到底缺了什麼。

先把最小任務跑起來

假設第一階段只需要處理最基本的商品問答，例如：

「跑步鞋跟休閒鞋有什麼差別？」

那第一版架構其實可以非常簡單：User → Application → LLM → Response
這就是 Baseline。

它還不知道公司的內部資料，也不能查訂單或幫使用者執行操作，但這些都不是目前核心任務需要的能力。
Baseline 不是簡化版 Production Architecture，而是一個 Architecture Reasoning 的起點：

先確認現在完成任務需要什麼，再看新的 Requirement 帶來哪一種 Capability Gap。

同樣是客服問題，背後需要的能力其實不同

當電商客服開始變得更真實，使用者可能會問：

• 「你們現在的退貨規則是什麼？」
• 「這雙鞋還有沒有庫存？」
• 「我昨天的訂單出貨了嗎？」
• 「幫我取消這筆訂單。」

表面上都是自然語言問題，但從 System Design 的角度，它們其實是不同類型的 Requirement。

這裡真正重要的不是立刻決定 RAG 要怎麼做，而是先把需求分對類。

Knowledge、State、Action 不應該混在一起

例如退換貨政策屬於 Knowledge。它可能存在 FAQ、規章或產品文件裡，內容也會持續更新，因此後續自然會進入 Retrieval / RAG 類的設計。

但「我的訂單現在在哪裡」就不是 Knowledge，而是 State。

訂單可能幾秒鐘前才完成付款，也可能剛剛才出貨。這類資訊真正的 Source of Truth 應該是 Order System，而不是模型權重或知識庫。

同樣地：

退換貨政策 → Knowledge
即時庫存 → State
訂單狀態 → State
取消訂單 → Action

所以比起一開始問「這份資料要不要放進 RAG」，更重要的是先確認：

這份資訊真正的 Source of Truth 在哪裡？

而當需求從「查詢訂單」變成「取消訂單」時，又跨過另一條重要邊界。

前者只是 Read State，後者已經開始產生 Action。

這時候 AI 不再只是回答問題，而是真的會改變外部系統狀態。後續才需要進一步處理 Business Service、權限、確認與交易控制等問題。

這裡有一個我很喜歡的設計原則：

讓 LLM 處理模糊性，讓 Business System 處理確定性。

例如使用者到底想取消哪一筆訂單，可以交給 LLM 理解；但這張訂單按照公司規則到底能不能取消，應該交給 Order Service 的 Business Rules 判斷。

流程變複雜，不代表立刻需要 Agent

再把需求往前推一步。

使用者說：

「這雙鞋尺寸太小，我想換大一號，如果沒有貨就退掉。」

這時候流程可能需要先確認退換貨資格、查庫存，再根據結果選擇換貨或退款。
雖然流程開始分岔，但如果所有可能路徑都能事先定義，它仍然比較接近 Workflow / Orchestration。

只有當問題變成：

「這筆訂單出了問題，幫我找一個最適合的解決方式。」

系統才可能需要根據當下情況自行決定先查物流、庫存、付款狀態，還是補問使用者更多資訊。
這時候才逐漸進入 Dynamic Decision / Agent 的範圍。

因此可以先簡單區分：

路徑可以事先定義 → Workflow
下一步需要根據環境動態決定，而且無法完整預先枚舉 (你如果畫不出流程圖的話) → Agent

Day 4 到這裡只需要先把需求歸類，至於 Workflow 怎麼設計、Agent Loop 怎麼運作，後面再展開。

Baseline 的價值，是讓 Architecture 有因果關係

回頭看整個電商客服案例，其實可以整理成一條很清楚的演進：

Minimum Baseline → Requirement → Capability Gap → Architecture Direction

例如：

Knowledge → Retrieval / RAG 類
State → API / Tool 類
Action → Business Service 類
Process → Workflow 類
Dynamic Decision → Agent 類

這裡刻意寫成「類能力」，因為現在還不是要直接把 RAG、Tool 或 Agent 的內部架構設計完。

Day 4 真正要做的是前一層：

從最小 Baseline 出發，辨識新的 Requirement 讓系統缺了哪一種能力。

後面的每一個 Component，才會有清楚的存在理由。

所以 Baseline 不是在追求架構越少越好，而是在建立一個基準，讓每一次 Architecture Evolution 都能說清楚：

上一版到底缺了什麼能力。

先把 Baseline 畫對，後面的 Component 才知道為什麼要出現。

AI 你怎麼看?