大多數人把 AI Agent 當成「會呼叫工具的 ChatBot」，
以為加幾個 function call 就完成了；
真正的 Agent 工程需要持久記憶、確定性狀態機、可觀測的思考迴圈，
差距不在 LLM，在你能不能讓它在第 20 步還知道自己在做什麼。
面試情境：
你是某電商平台的 AI 基礎設施 Lead。PM 要求將現有的「單次 GPT 呼叫客服」升級為「可自主完成退款、查單、更換地址」的 Agent，日均對話量 80K，P99 回應時間需在 8 秒以內。請問你如何設計 Agent 迴圈、記憶系統與上下文管理策略，並說明在 MVP 和 Scale 兩個階段的架構差異？
一、核心問題：什麼是真正的 AI Agent
單次 LLM 呼叫（stateless call）與真正的 Agent之間有一道本質的鴻溝。
前者每次呼叫都是白紙一張，不知道剛才做了什麼，也不知道任務完成到哪裡；後者具備三個關鍵能力：
- 自主決策迴圈：在沒有人類介入的情況下，重複「感知→思考→行動→觀察」直到任務完成或確認無法完成。
- 跨步驟記憶：第 15 個步驟還能記得第 1 個步驟收集的用戶資料，不會重複詢問相同問題。
- 工具組合能力：可以依情境選擇不同工具，並根據工具回傳結果調整下一步計畫。
為什麼這很難？
LLM 本身是無狀態的（stateless）。每次 API 呼叫都是獨立的 HTTP 請求，沒有跨請求的記憶。Agent 框架必須在應用層解決：
- 上下文視窗有限：GPT-4o 128K tokens，換算約 96K 中文字。長任務無法全塞。
- 幻覺累積問題：步驟越多，錯誤累積越嚴重，必須設計檢查點。
- 成本爆炸：每步驟都傳完整歷史，128K token × $5/1M input = 每步 $0.64，100 步任務 = $64/次。
- 確定性需求：「取消訂單」這種有副作用的操作不能讓 LLM 隨機決定，必須用狀態機控制。
正確的 Agent 工程不是「把更多東西塞進 prompt」，而是設計一個可靠的資訊流系統，讓 LLM 在每個決策點都能拿到恰好足夠的上下文。
二、三個演進階段（POC → MVP → Scale）
╔══════════════════════════════════════╗
║ Phase 1：POC（< 1K 日均對話） ║
╚══════════════════════════════════════╝
目標：證明 Agent 能完成任務，快速驗證工具整合。
┌─────────────────────────────────────────────────────────────┐
│ POC Agent 架構 │
│ │
│ 用戶輸入 │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────┐ │
│ │ Single LLM Call (ReAct prompt) │ │
│ │ - 完整歷史直接傳入 │ │
│ │ - Tool defs 內嵌 system prompt │ │
│ └──────────────┬───────────────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ Tool Executor │ (Python dict dispatch) │
│ └────────┬────────┘ │
│ │ 結果 │
│ └──────────── 回填 messages list │
│ │
│ 記憶：in-memory list（重啟即失） │
│ 成本：~$0.02/對話，無限制 │
│ 缺點：超過 40 步必 OOM 或 exceed context │
└─────────────────────────────────────────────────────────────┘
新增元件：LLM API client、基本 tool dispatcher、messages list
可接受的妥協：記憶不持久、無錯誤恢復、無成本控制
適用場景：內部 demo、技術可行性驗證
╔══════════════════════════════════════╗
║ Phase 2：MVP（1K–20K 日均對話） ║
╚══════════════════════════════════════╝
目標：可上線、可監控、成本可預測。
┌──────────────────────────────────────────────────────────────────┐
│ MVP Agent 架構 │
│ │
│ 用戶輸入 │
│ │ │
│ ▼ │
│ ┌────────────────┐ ┌──────────────────────────────────────┐ │
│ │ Session Store │ │ Agent Orchestrator │ │
│ │ (Redis TTL 2h) │◀───│ - Context Window Manager │ │
│ └────────────────┘ │ - Step counter (max 25) │ │
│ │ - Cost accumulator │ │
│ └──────────────┬───────────────────────┘ │
│ │ │
│ ┌─────────────▼──────────────┐ │
│ │ LLM Gateway │ │
│ │ - Sliding window (8K) │ │
│ │ - Summary injection │ │
│ └─────────────┬──────────────┘ │
│ │ │
│ ┌──────────────────────────▼──────────────────┐ │
│ │ Tool Registry │ │
│ │ refund_api │ order_lookup │ address_update │ │
│ └──────────────────────────┬──────────────────┘ │
│ │ │
│ 持久記憶：PostgreSQL（情節記憶） │
│ 成本：~$0.08/對話，硬上限 $0.50/session │
│ 監控：LangSmith traces │
└──────────────────────────────────────────────────────────────────┘
新增元件：Redis session store、Context Window Manager、Tool Registry、PostgreSQL 情節記憶、成本上限
解決問題：記憶持久化、成本失控、基本可觀測性
仍有問題：單點 Orchestrator、無水平擴展、記憶壓縮策略簡陋
╔══════════════════════════════════════╗
║ Phase 3：Scale（20K–200K 日均） ║
╚══════════════════════════════════════╝
目標：高可用、水平擴展、記憶系統完整。
┌────────────────────────────────────────────────────────────────────────┐
│ Scale Agent 架構 │
│ │
│ ┌──────────────┐ ┌──────────────────────────────────────────────┐ │
│ │ API Gateway │──▶│ Agent Router (stateless) │ │
│ │ + Auth JWT │ │ - session_id → shard mapping │ │
│ └──────────────┘ └───────────────┬──────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────▼──────────────────────────┐ │
│ │ Agent Worker Pool (×N) │ │
│ │ Worker 1 │ Worker 2 │ Worker 3 │ ... │ Worker N │ │
│ └─────────────────────────┬──────────────────────────┘ │
│ │ │
│ ┌───────────────────────────────▼──────────────────────────────┐ │
│ │ Memory System │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │ │
│ │ │ Sensory │ │ Working │ │ Episodic │ │ Semantic │ │ │
│ │ │(in-proc) │ │ (Redis) │ │(Postgres)│ │(pgvector) │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └────────────┘ │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────────────────▼──────────────────────────────┐ │
│ │ Tool Execution Layer │ │
│ │ Sync tools ─── async tools ─── long-running tasks (Celery) │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ 可觀測性：OpenTelemetry traces → Jaeger；Prometheus metrics │
│ 成本：~$0.12/對話；P99 回應 < 6s；可用性 99.5% │
└────────────────────────────────────────────────────────────────────────┘
新增元件：Agent Router、Worker Pool、完整四層記憶系統、Celery 長任務、OpenTelemetry
解決問題：水平擴展、記憶系統完整性、長任務非同步執行
成本/複雜度：月雲端費用約 $3,000–$8,000；需要 3–5 名工程師維護
三、Agent 迴圈：Perceive → Think → Act → Observe
AI Agent 的核心是一個無限迴圈，每次迭代稱為一個「step」。
┌─────────────────────────────────────────────────────────────────┐
│ Agent 主迴圈 │
│ │
│ ┌─────────────┐ │
│ │ START │ │
│ │ task init │ │
│ └──────┬──────┘ │
│ │ │
│ ┌──────────────▼──────────────┐ │
│ │ PERCEIVE（感知） │ │
│ │ - 讀取用戶輸入 │ │
│ │ - 載入工作記憶 │ │
│ │ - 查詢情節/語意記憶 │ │
│ └──────────────┬──────────────┘ │
│ │ │
│ ┌──────────────▼──────────────┐ │
│ │ THINK（思考） │ │
│ │ - LLM 呼叫（含工具定義） │ │
│ │ - 解析 reasoning chain │ │
│ │ - 決定 next action │ │
│ └──────────────┬──────────────┘ │
│ │ │
│ ┌──────────────▼──────────────┐ │
│ │ ACT（行動） │ │
│ │ - 執行 tool call │ │
│ │ - 驗證參數（schema check） │ │
│ │ - 紀錄 action log │ │
│ └──────────────┬──────────────┘ │
│ │ │
│ ┌──────────────▼──────────────┐ │
│ │ OBSERVE（觀察） │ │
│ │ - 解析工具回傳結果 │ │
│ │ - 更新工作記憶 │ │
│ │ - 評估任務是否完成 │ │
│ └──────────────┬──────────────┘ │
│ │ │
│ ┌────────────▼────────────┐ │
│ │ 任務完成？/ 超步驟？ │ │
│ │ / 遇到無法恢復的錯誤？ │ │
│ └────┬──────────────┬─────┘ │
│ │ YES │ NO │
│ ▼ └──────────────────┐ │
│ ┌─────────┐ │ │
│ │ END │ 回到 PERCEIVE │ │
│ └─────────┘ │ │
│ ▼ │
└────────────────────────────────────────────────────────────────┘
關鍵設計決策
步驟上限（max_steps）：必須設定，否則單次任務可能無限迴圈消耗資源。POC 設 10，MVP 設 25，Scale 依任務類型設 15–50。
步驟超時（step_timeout）：每個 LLM 呼叫設 30s 超時，每個工具呼叫設 10s 超時。P99 超時觸發後應記錄中間狀態，允許用戶繼續。
狀態機整合：ACT 步驟不直接由 LLM 決定「要不要執行退款」，而是 LLM 提出意圖，狀態機驗證當前狀態允許該轉換後才實際執行。詳見第七節。
四、ReAct 框架：交錯推理與行動
ReAct（Reasoning + Acting）是目前最廣泛使用的 Agent 框架。核心思想是讓 LLM 在每個步驟先產出「思考」（Thought），再決定「行動」（Action），收到觀察結果（Observation）後繼續。
┌──────────────────────────────────────────────────────────────────┐
│ ReAct 流程圖 │
│ │
│ User: "幫我退訂單 #A123，原因是商品損壞" │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Step 1 │ │
│ │ Thought: 我需要先查訂單 #A123 的狀態，確認是否可退款 │ │
│ │ Action: order_lookup(order_id="A123") │ │
│ │ Observation: {status: "delivered", amount: 299, ...} │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Step 2 │ │
│ │ Thought: 訂單已送達，符合退款條件（14天內）。 │ │
│ │ 需確認用戶退款帳戶 │ │
│ │ Action: get_user_payment_info(user_id="U456") │ │
│ │ Observation: {method: "credit_card", last4: "1234"} │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Step 3 │ │
│ │ Thought: 資料齊全，執行退款。金額 $299 退回信用卡末4碼 │ │
│ │ 1234。需要用戶確認。 │ │
│ │ Action: request_user_confirmation( │ │
│ │ message="確認退款 $299 至信用卡 ****1234？") │ │
│ │ Observation: {confirmed: true} │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Step 4 │ │
│ │ Thought: 用戶確認。執行退款 API。 │ │
│ │ Action: process_refund(order_id="A123", amount=299, │ │
│ │ reason="damaged_goods") │ │
│ │ Observation: {refund_id: "R789", eta: "3-5 days"} │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Final Answer: 退款已成功申請（單號 R789），3-5 個工作天內 │
│ 退回您的信用卡 ****1234。 │
└──────────────────────────────────────────────────────────────────┘
Reflexion 擴展
Reflexion 在 ReAct 基礎上增加「反思」步驟：任務失敗後，Agent 生成一段自我批評（self-reflection），存入情節記憶，下次執行相似任務時注入 context，避免重複同樣錯誤。
實測數據：在 HotpotQA 任務上，ReAct 成功率約 58%，加入 Reflexion 後提升至 71%（+13pp），代價是每次失敗多消耗約 800 tokens 的反思生成。
五、記憶四層架構：感官 / 工作 / 情節 / 語意
人類記憶的分層模型被直接應用於 Agent 設計。
┌──────────────────────────────────────────────────────────────────────┐
│ 四層記憶架構 │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Layer 1：感官記憶（Sensory Memory） │ │
│ │ 壽命 < 1s ｜ 容量：當前 token buffer ｜ 存儲：in-process │ │
│ │ 內容：原始輸入（用戶訊息、工具 raw output） │ │
│ │ 用途：尚未處理的即時資料 │ │
│ └──────────────────────────┬──────────────────────────────────┘ │
│ │ 重要資訊提取 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Layer 2：工作記憶（Working Memory） │ │
│ │ 壽命：session 期間 ｜ 容量：~8K tokens ｜ 存儲：Redis │ │
│ │ 內容：當前任務狀態、最近 N 步歷史、活躍工具結果 │ │
│ │ 用途：每次 LLM 呼叫都注入這層 │ │
│ │ TTL：2 小時（用戶閒置超過 2h 清除） │ │
│ └──────────────────────────┬──────────────────────────────────┘ │
│ │ 完成的任務/重要事件 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Layer 3：情節記憶（Episodic Memory） │ │
│ │ 壽命：永久 ｜ 容量：無限 ｜ 存儲：PostgreSQL │ │
│ │ 內容：過去對話摘要、任務結果、錯誤反思 │ │
│ │ 用途：跨 session 連續性；「上次你說…」 │ │
│ │ 查詢：by user_id + timestamp range │ │
│ └──────────────────────────┬──────────────────────────────────┘ │
│ │ 知識蒸餾 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Layer 4：語意記憶（Semantic Memory） │ │
│ │ 壽命：永久 ｜ 容量：無限 ｜ 存儲：pgvector / Pinecone │ │
│ │ 內容：用戶偏好、領域知識、FAQ 嵌入向量 │ │
│ │ 用途：RAG 檢索；相似情境參考 │ │
│ │ 查詢：cosine similarity top-K（K=5 實測最佳） │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 每次 LLM 呼叫的上下文組成： │
│ [System Prompt] + [語意記憶 top-3] + [情節摘要] + [工作記憶] │
│ 約 2K + 1.5K + 500 + 8K = 12K total │
└──────────────────────────────────────────────────────────────────────┘
各層實作要點
工作記憶（Redis）：
- Key 格式：
agent:session:{session_id}:working_memory - Value：JSON 序列化的 messages list + task_state
- TTL：7200 秒
- 超出 8K tokens 時觸發「滑動視窗」策略（詳見第六節）
情節記憶（PostgreSQL）：
1CREATE TABLE episode_memory (
2 id BIGSERIAL PRIMARY KEY,
3 user_id TEXT NOT NULL,
4 session_id TEXT NOT NULL,
5 summary TEXT, -- LLM 生成的對話摘要
6 outcome TEXT, -- success / failure / partial
7 key_facts JSONB, -- 結構化提取的重要資訊
8 created_at TIMESTAMPTZ DEFAULT NOW(),
9 INDEX (user_id, created_at DESC)
10);
語意記憶（pgvector）：
- 使用
text-embedding-3-small（1536 dims）嵌入 - 每個知識片段 < 512 tokens
- 查詢時用
<=>cosine distance，閾值 < 0.3 才注入
六、上下文視窗管理：摘要 / 壓縮 / 選擇性遺忘
上下文視窗是 Agent 最稀缺的資源。以 GPT-4o 128K token 為例，input 費用 $5/1M tokens，若每步驟都傳滿，25 步任務的 input 成本 = 25 × 128K × $5/1M = $16/次，完全不可行。
三種壓縮策略
策略一：滑動視窗（Sliding Window）
保留最近 N 條訊息，丟棄更早的。簡單有效，但會遺失早期重要資訊。
適用：任務步驟少（< 10）、早期資訊不重要的場景。
N = 6（3 組 thought/action/observation）是實測甜蜜點。
策略二：遞進摘要（Progressive Summarization）
每隔 K 步，呼叫 LLM 將「最舊的 K 步」壓縮為一段摘要，摘要替換原始訊息。
壓縮比：8K tokens → 500 tokens（約 16:1）。
代價：每次摘要多消耗一次 LLM 呼叫（約 $0.002/次）。
適用：長任務（10–30 步）、需要保留歷史摘要。
策略三：選擇性保留（Selective Retention）
由 LLM 標記每條訊息的「重要度分數」（0–1.0），低於 0.4 的訊息在視窗壓縮時優先丟棄。
高重要度標記的訊息類型：用戶明確說出的需求、工具回傳的關鍵 ID（訂單號/退款單號）、用戶確認的決策。
代價：需要額外標記步驟，或在 Observation 處理時即時評分。
實際上下文預算配置（MVP 設定）
| 區塊 | Token 預算 | 來源 |
|---|---|---|
| System prompt + tools | 2,000 | 靜態 |
| 語意記憶 RAG | 1,500 | 動態檢索 |
| 情節摘要 | 500 | 上次對話壓縮 |
| 工作記憶（滑動視窗） | 6,000 | 最近 6 步 |
| 輸出預留 | 2,000 | max_tokens |
| 總計 | 12,000 | — |
在 GPT-4o 的 128K 視窗內，這個配置有 10 倍的安全餘量，且成本每步僅 $0.06，25 步任務 = $1.50/次，可接受。
七、Agent 狀態機：確定性控制 vs LLM 決策的邊界
最常見的 Agent 設計錯誤：把所有決策都交給 LLM，包括「現在應不應該執行退款」這種有不可逆副作用的操作。
正確做法是用確定性狀態機控制業務流程，LLM 只負責「資訊蒐集」和「意圖提取」，狀態轉換由狀態機驗證。
┌─────────────────────────────────────────────────────────────────────┐
│ 退款 Agent 狀態機 │
│ │
│ INITIAL ──[用戶提出退款請求]──▶ GATHERING_INFO │
│ │ │
│ [所有必要資訊齊全] │
│ │ │
│ ▼ │
│ VALIDATING │
│ │ │ │
│ [驗證通過] │ │ [驗證失敗] │
│ ▼ ▼ │
│ AWAITING_ REJECTED │
│ CONFIRM (final) │
│ │ │
│ [用戶確認] │ [用戶取消] │
│ ▼ ▼ │
│ PROCESSING CANCELLED │
│ │ (final) │
│ [API 成功] │ [API 失敗] │
│ ▼ ▼ │
│ COMPLETED FAILED │
│ (final) (final) │
│ │
│ LLM 可執行的轉換：INITIAL→GATHERING、GATHERING→GATHERING（資訊收集）│
│ LLM 不可直接觸發的轉換：VALIDATING→PROCESSING（必須由系統驗證） │
│ AWAITING→PROCESSING（必須有明確用戶確認） │
└─────────────────────────────────────────────────────────────────────┘
邊界原則
| 決策類型 | 由誰決定 | 理由 |
|---|---|---|
| 下一步要問什麼問題 | LLM | 語言理解任務 |
| 如何組織回答 | LLM | 生成任務 |
| 是否滿足退款條件 | 規則引擎 | 確定性邏輯 |
| 是否執行退款 API | 狀態機 + 用戶確認 | 不可逆副作用 |
| 工具呼叫的參數值 | LLM | 語意提取任務 |
| 工具呼叫是否允許 | 權限系統 | 安全邊界 |
八、為什麼選 X 不選 Y
決策 1：工作記憶存儲
選擇 選 Redis 的理由 不選的理由
─────────────────────────────────────────────────────────────
Redis < 1ms 讀寫；原生 TTL； Memcached：無持久化，
vs Cluster 模式；支援 HASH/LIST 資料結構少
PostgreSQL structure Postgres：連接開銷 5ms+，
vs session 數萬時連接池壓力大
In-memory TTL 自動清理；多 Worker 共享 In-memory：Worker 重啟失憶，
dict 同一 session 狀態 無法水平擴展
Flip condition：若日均 session < 100，in-memory dict 足夠；Redis 的必要性從 1K sessions/day 開始顯現。
決策 2：語意記憶向量資料庫
選擇 選 pgvector 的理由 不選的理由
──────────────────────────────────────────────────────────────
pgvector 與 PostgreSQL 同一資料庫； Pinecone：額外 $70/月起，
vs SQL + 向量混合查詢； 需要同步兩個資料庫
Pinecone 開源，無額外費用 Weaviate：運維複雜，
vs 自建需要 4GB RAM
Weaviate 延遲 5–15ms（100K vectors 以內）； FAISS：純 library，
vs HNSW 索引 無 server，無法水平擴展
FAISS
Flip condition：向量數 > 10M 或需要 < 5ms P99 查詢延遲時，考慮 Pinecone 或 Qdrant。
決策 3：Agent 框架
選擇 選自建輕量框架的理由 不選的理由
──────────────────────────────────────────────────────────────
自建 完整控制；無黑箱； LangChain：抽象層太厚，
vs 易於 debug；記憶系統可自訂 debug 困難，版本升級常 breaking
LangChain 核心代碼 < 500 行 LlamaIndex：偏向 RAG，
vs Agent loop 不完整
LlamaIndex 適合生產環境的自定義需求 AutoGen：multi-agent 場景才
vs 有優勢，單 agent 過重
AutoGen
Flip condition：需要快速 POC（< 1 週）且不在乎 debug 成本時，LangChain 可接受。多 Agent 協作場景考慮 AutoGen 或 CrewAI。
決策 4：ReAct vs Plan-and-Execute
選擇 選 ReAct 的理由 不選的理由
──────────────────────────────────────────────────────────────
ReAct 動態調整；每步根據觀察重新決策； Plan-and-Execute：
vs 適合不確定性高的任務； 預設計畫在中途失效時
Plan-and- 延遲低（不需先生成完整計畫） 難以動態調整；需要
Execute 額外的 re-planning 機制
實測：5 步以內任務 ReAct vs P&E P&E 在 > 10 步、結構
完成率相同（~82%），延遲 ReAct 低 明確的任務上完成率更高
30–40% （84% vs 79%）
Flip condition：任務步驟 > 10 且流程高度結構化（如：固定的 SOP）時，Plan-and-Execute 更可預測。
決策 5：記憶壓縮策略
選擇 選遞進摘要的理由 不選的理由
──────────────────────────────────────────────────────────────
遞進摘要 保留語意資訊； 滑動視窗：丟失早期
vs 壓縮比高（16:1）； 重要資訊；< 10 步
滑動視窗 長任務（> 10 步）適用 任務可用
vs 選擇性保留：需要額外
選擇性保留 每次壓縮只多花 $0.002； LLM 呼叫打分，延遲
延遲影響 < 500ms 增加 800ms+
Flip condition：任務 < 8 步時，滑動視窗（保留最近 6 步）成本最低，無需摘要。
決策 6：用戶確認機制
選擇 選「明確確認 + 狀態機鎖定」的理由 不選的理由
──────────────────────────────────────────────────────────────
明確確認 不可逆操作（退款/刪除/下單） 隱式確認（LLM 判斷）：
+ 狀態機 必須有用戶明確輸入； 幻覺風險；用戶說
vs 狀態機確保同一 session 不可 "好的隨便" 被誤判為
隱式確認 重複觸發同一退款 確認；無稽核日誌
Flip condition：對於可逆操作（查詢、摘要、推薦），不需要確認步驟，加確認反而降低 UX 流暢度。
九、系統效應：無記憶 vs 完整記憶系統
以電商客服 Agent 為基準，日均 80K 對話，每對話平均 4.2 步。
| 指標 | 無記憶（單次呼叫） | 完整記憶系統（四層架構） | 改善幅度 |
|---|---|---|---|
| 任務完成率 | 43% | 79% | +36pp |
| 需要人工接管率 | 57% | 21% | -36pp |
| 平均對話輪次 | 7.8 輪（重複問題多） | 4.2 輪 | -46% |
| 用戶重複提供資訊次數 | 2.3 次/對話 | 0.1 次/對話 | -96% |
| P99 回應延遲 | 3.2s | 5.8s（多了記憶查詢） | -2.6s |
| P50 回應延遲 | 1.8s | 2.4s | -0.6s |
| 每次對話成本 | $0.03 | $0.12 | +$0.09 |
| 月基礎設施成本 | $200 | $3,200 | +$3,000 |
| 用戶滿意度（CSAT） | 3.1 / 5 | 4.2 / 5 | +35% |
| 退款錯誤率 | 2.1% | 0.08% | -96% |
成本效益分析
月額外基礎設施成本：$3,000
每避免一次人工接管節省：~$2.5（人工客服成本）
月減少人工接管次數：80K × 0.36 = 28,800 次
月節省人工成本：28,800 × $2.5 = $72,000
ROI = ($72,000 - $3,000) / $3,000 = 2,300%
即使把 LLM API 成本算進去（月 $0.09 × 80K × 30 = $216,000），整體客服成本相比純人工方案（80K × 30 × $2.5 = $6M）仍降低 64%。
十、面試答題要點
「設計退款 Agent 的核心挑戰不是讓 LLM 更聰明，而是建立三個基礎：一個有狀態的記憶系統、一個確定性的狀態機、以及一個可觀測的思考迴圈。MVP 階段我會用 Redis 存工作記憶（TTL 2h，8K tokens 滑動視窗）、PostgreSQL 存情節記憶，讓 Agent 跨 session 記住用戶身份；狀態機確保退款操作只在 VALIDATING→AWAITING_CONFIRM→PROCESSING 的路徑上執行，LLM 幻覺無法繞過確認步驟。到 Scale 階段（20K+ 日均），再加入 pgvector 語意記憶、Worker Pool 水平擴展、OpenTelemetry traces，把 P99 控制在 6s 內。整體而言，有記憶的 Agent 比無記憶版本任務完成率從 43% 提升至 79%，退款錯誤率從 2.1% 降至 0.08%，ROI 超過 2,000%。」
十一、系列導航
本文是 AI 工程從零開始 系列 Phase 14 Part 1。
← Phase 13 Part 2：RAG 進階優化與生產部署
→ Phase 14 Part 2：Multi-Agent 協作與 Tool Use 進階設計
系列索引：AI 工程從零開始 — 完整系列
