01agent 什麼都回答，還是先做分流？
先分流：每一則進來的訊息都先分類意圖——可由知識回答、需要帳戶資料，或該立刻交給真人（動怒的客戶、法律威脅、流失風險）。
免費完整指南
AI 客服 Agent
為一個 SaaS 產品設計一套 AI 客服 agent。涵蓋意圖路由、知識檢索、帳戶安全的工具操作、對話記憶、以信心度為基礎的真人升級、支援工單交接、評測套件、隱私控管，以及營運監控。
00
練習檢查點
面試節奏保持精簡,讓頁面能把注意力花在真正的設計決策上。
- 01釐清範圍
- 02需求 + 規模
- 03API + 資料模型
- 04畫出架構
- 05深入探討
- 06取捨決策
01
形塑設計的需求
不要只是陳述需求,要主動問出來。每張卡把設計限制和一句你可以在畫架構前說出口的釐清問句配成一組。
功能需求
02agent 實際上可以對帳戶「做」什麼？
只用帶型別輸入的核准工具——查狀態、改設定、發一筆有上限的退款。有風險或不可逆的操作需要明確確認或交給真人。
03什麼時候必須由真人接手，他們會收到什麼？
遇到低信心、反覆失敗、或客戶主動要求時，就交給真人接手。他會拿到一份交接包：對話內容、檢索到的來源、嘗試過的動作，還有 agent 自己的不確定性。絕不從零開始。
04agent 記得先前的輪次——還有先前的對話嗎？
在同一段對話裡，它永遠記得——就算是很長的一串也一樣。跨對話時，它只保留帳戶事實，絕不留先前的聊天內容，並遵守保留政策。
05單一語言還是多語言？
這條管線能處理任何語言，但評估不行。golden set 要為每個語系各自建立，因為答案品質不會從一種語言帶到另一種語言。
06客戶能在任何時候要求真人嗎？
永遠都要。「找真人」在每一步都只差一個回合。把這個出口藏起來，會灌大 deflection 指標（從沒轉到真人的對話占比），卻同時摧毀信任。
範圍外語音管道與即時語音 · 訓練自訂的基礎模型 · 銷售與行銷對話（只做客服）
非功能需求
01最糟的失效模式是什麼——慢，還是錯？
錯：一條捏造的政策或一筆未授權的退款，代價都比任何延遲更高。紮實、引用來源與操作把關，都優先於流暢度。
02agent 回答時能看到哪些資料？
只給這位客戶能看到的東西。知識存取以每租戶、每方案為範圍。內部 runbook 與其他租戶的資料，絕不能出現在答案裡。
03回答要讓人感覺多快？
答案必須在約 2 秒內開始出現、遠低於 30 秒內完成——而且在每日約 1 萬次對話的量下也要撐住這個標準。
04出事的時候，我們能重建原因嗎？
可以：每一輪都留追蹤軌跡——查詢、檢索到的區塊與分數、prompt、帶輸入／輸出的工具呼叫，以及升級決策。失敗會回放進評測集。
05我們怎麼知道 agent 正在變差？
每次更動模型或 prompt，品質都要拿一組固定的參考客服對話來檢查。沒有量過的東西不出貨。光看 deflection 率不等於品質。
持續追問 —— 面試是一場對話
真實面試探得比一份整齊清單深得多。這些範圍問句,區分出真正拷問問題的人和只是背誦的人。
- 升級的契約是什麼——交接後真人必須多快回應？
- 對話日誌的資料保留與 PII 規則是什麼？
- 每次對話有成本上限嗎——到哪個點 agent 反而比它取代的真人更貴？
- 我們該預期對抗性使用者嗎——蓄意誘騙 agent 退款或洩漏資料的人？
- 客服量有沒有季節性或發布日的暴衝需要我們吸收？
02
逼出架構決策的數字
把每個估算都當成一種壓力,用來合理化一個元件:快取、佇列、分片、副本、worker pool 或退路。
擋單經濟學
每日 1 萬次對話（面試官給定），agent 完全解決約 60%，一張真人工單平均約 15 分鐘10K × 60% = 每日 6,000 次解決；6,000 × 約 15 分鐘 = 90,000 分鐘 ≈ 每日 1,500 個 agent 工時；以 8 小時一班計 ≈ 吸收掉約 190 個客服席位
商業效益的成敗取決於解決「品質」——這正是評測套件是需求、而非附屬工具的原因。
每輪的脈絡預算
約 8K tokens：system + 政策（2K）+ 檢索區塊（4K）+ 對話視窗（2K）2K + 4K + 2K = 每輪 8K tokens——檢索區塊就佔了整個預算的一半，所以那 4K tokens 必須承載答案
檢索精準度才是真正的品質槓桿——把視窗開大只是加成本，不是解法。
延遲拆解
p95 目標：檢索 300 ms + rerank 200 ms + 第一個 token 1.5 s≈ 2 秒到第一個串流 token
每一階段有自己的預算與監控——「AI 很慢」不是一個診斷。
評測套件成本
每次發布 500 個 golden 對話 × 3 個受評變體500 × 3 = 每次發布 1,500 次受評執行——平行跑只需幾分鐘牆鐘時間，外加幾美元的評審模型 tokens
持續評測的成本，比一張被搞砸的企業工單還低。
升級負載
1 萬次對話中約 40% 升級每日 4,000 次路由給真人，並「附上」交接封包
交接品質決定真人是否信任 agent——一份糟糕的封包會讓他們的工作量翻倍。
決策範例
數字
每天一萬段對話，agent 完整解決其中六成。整個價值都押在這些解決是「對的」上。一條瞎編的退款政策，就抹掉一個月省下來的錢。
我的選擇
我會把 agent 做成一條有關卡的管線：先分類意圖，用客戶自己的權限去檢索，只在有引用時才回答。每個副作用都藏在有型別、列在允許清單上的工具後面，風險分級在模型之外強制執行。信心值把守每一步：低於門檻，客戶就拿到真人加一份交接包——對話內容、來源、嘗試過的動作，還有 agent 的不確定性。每個回合都可追蹤、可重播，失敗會餵進一組 golden eval set，用評分表加兩兩比較來評判，並由真人校準。
避免
我不會做的事：把一條資料庫連線和一句「請樂於助人」的 system prompt 丟給模型。自由形式的存取，就是 agent 退款退錯客戶的原因。我也不會只用 deflection 率來衡量品質——一個滿懷信心、卻用錯誤答案打發客戶的 agent，分數漂亮，卻在摧毀信任。而且精確比對測試沒辦法評判客服對話：「有沒有正確解決」是一種偏好判斷，這正是為什麼 eval set 要連同評分表，把好的「和」壞的參考輸出都存下來。
何時改變
如果產品走向多區域、還帶資料落地規範，檢索索引與對話紀錄就必須按區域分片。eval 套件這時要多出每語系的 golden set，因為品質沒辦法跨語言搬移。
03
架構路徑
先看一張完整的圖,再把每條路徑各自畫成一張圖 —— 寫入路徑與讀取路徑承載不同流量,合理化不同的元件。
完整全貌
總覽 —— 每個元件
模型做的每一件事都要過一道關卡：檢索限定在權限範圍內，操作走工具閘道，信心度過低就帶著完整交接封包退場給真人。追蹤軌跡記錄每一跳。
路徑 1
回答路徑——分類、檢索、紮根、回應
意圖分類跑在任何生成之前。檢索把客戶的權限帶進索引查詢裡。答案要嘛引用來源，要嘛就不出貨。
路徑 2
操作路徑——風險層級後的型別化工具
模型提議，閘道裁決。低層級直接執行，中層級請客戶確認，高層級需要真人——而且每一次呼叫都落進追蹤軌跡。
04
API 與資料模型
在最佳化之前,先讓契約可被檢視:端點、實體、擁有權、重試與狀態。
POST/support/messages
請求{ conversation_id?, text }
回應200 串流回答並附引用來源 · 或 { escalated: true, ticket_id }
客戶身分來自 session——agent 的權限就是客戶的權限，絕不更廣。
POST/support/{conversation_id}/escalate
回應201 { ticket_id } 並附上交接封包
在信心度過低、反覆失敗，或客戶明確要求時觸發——升級是一項功能，不是失敗。
POSTinternal: tools.execute(tool, input, risk_tier)
回應result · blocked（需確認）· denied（政策）
從模型輸出到真正副作用的唯一路徑：帶型別的輸入、允許清單內的工具、在模型之外強制執行的風險層級。
核心實體
Conversationconversation_id (PK) · customer_id · channel · state: active/escalated/resolved
Turnturn_id (PK) · conversation_id · role · content · trace_ref
trace_ref 連到可完整回放的追蹤軌跡：檢索、prompt、工具呼叫、決策。
ToolActionaction_id (PK) · conversation_id · tool · input · result · risk_tier · confirmed_by
有風險的層級會記錄由誰確認——agent、客戶，或一位真人客服。
HandoffPacketconversation_id · summary · retrieved_sources · attempted_actions · uncertainty_notes
真人在升級時收到的東西——這決定了是接手還是重來。
05
深入方向
在面試最後三分之一挑一條路線。每條路線給你主題、它該回答的面試官問題,以及要避免的失敗模式。
agent 承諾了一筆不該給的退款
問
在「模型想退 $500」和錢真的動起來之間，有哪些層層防線？
回答
由 gateway 決定，不是模型。退款工具吃的是有型別、有硬上限的輸入，風險分級放在模型之外的 tool gateway 裡。$500 在自動執行的門檻之上，所以錢只有在客戶確認或真人核准後才會動。就算是被擋下來的嘗試，也會留在 trace 裡。
避免
把 system prompt 當成控制——政策活在工具閘道裡，在模型之外。
租戶資料留在家裡
問
兩家公司都用這個產品。走一遍檢索：某個問題最佳匹配的區塊剛好屬於「另一個」租戶。
回答
把 tenant ID 放進索引查詢裡。這樣別的租戶的 chunk 根本不會成為檢索候選——它在排序之前就被排除了，不是排序後才撈出來。別改用事後過濾結果那套。那邊漏檢查一次，競爭對手的文件就跑進 prompt 裡了。
避免
對檢索到的區塊做事後過濾——權限過濾必須在索引查詢本身之內。
交接的那一刻
問
對話中途信心度掉下來。真人客服究竟看到什麼，客戶的流程又會怎樣？
回答
真人打開的是一份交接包，不是一張空白畫面。裡面有完整對話、頂端有滾動摘要、agent 檢索過的來源、它試過的每個動作，還有它自己的不確定性註記。客戶留在同一個對話裡，只會看到有個真人加入。他們永遠不用重講一遍。
避免
只帶一份逐字稿就升級——來源、已嘗試操作與不確定性註記，才是讓真人免於重來的東西。
它是不是變差了？
問
一次 prompt 微調上線。你怎麼知道客服品質沒有悄悄回退——在客戶告訴你之前？
回答
每次發布都重放一組固定的黃金對話。一個評審模型照著評分準則（rubric）幫每個回答打分，並拿新版本和舊版本比較，真人則定期重新校準它。完全比對沒辦法評文章，而 deflection rate 會獎勵那些自信滿滿的錯誤答案。rubric 加上成對比較，能在客戶之前先抓到退化。
避免
拿精確比對測試或擋單率當指標——客服答案需要評分準則加兩兩比對評審，並由真人校準。
誰看了什麼
問
客戶對 agent 上個月做的某個操作提出爭議。重建這段對話：存了什麼、存多久、誰可以讀？
回答
每一輪都被 trace 下來——查詢、檢索到的 chunk 和分數、prompt、帶輸入與輸出的工具呼叫，還有升級的決策。所以有爭議的動作可以原封不動地重放出來。這些 log 只保留到保存期限為止，PII 也會遮蔽掉。讀取它們這件事本身，就是一個需要權限、會被稽核的動作。
避免
把原始對話帶著 PII 永久存放——保留與遮蔽是需求，不是事後清理。
準備好練習了嗎?
把 AI 客服 Agent 大聲講一遍,讓 AI 為你的說明評分。