我們通常會花上好幾個小時來打造一個 AI Agent。我們上傳產品規格、常見問題 (FAQ) 和教育訓練等文件。我們寫下指示，告訴 AI 必須保持專業、不要給出無法兌現的承諾，並在遇到複雜問題時主動建議客戶預約諮詢。
接著，我們會在測試區 (Playground) 進行測試。我們輸入常見的問題，例如「你們的收費怎麼算？」或「可以退款嗎？」Agent 處理得很好，回答既清楚又準確。於是，我們把聊天套件放上網站、串接 WhatsApp，然後正式上線。
最後，我們只能祈禱它一切順利。
只靠「祈禱」的風險所在
只測試十個或二十個問題是絕對不夠的。那些都只是我們能想到的簡單問題。客戶會問出幾千個我們完全沒料到的問題。他們會遇到邊緣案例 (Edge cases)、使用奇怪的語法，甚至在提問前先抱怨一通。
大型語言模型 (LLM) 具有機率性。寫得再好的系統提示詞 (System prompt)，也無法保證每一次的行為都完美；它只是一組指引。要真正知道你的 Agent 會說什麼，唯一的方法就是進行徹底的測試。當你的專業聲譽面臨風險時，單憑運氣是行不通的。
業界的標準解法：模型評估 (Evaluation)
我們該如何在客戶接觸到 Agent 之前，確認它的行為是否正確？在軟體工程界，答案是評估 (Evaluation，簡稱 Eval)。每一個專業的 AI 實驗室都會使用 Eval 來確保系統的可靠性。
具體做法是：你寫下一個真實的情境——一個客戶可能讓 Agent 面對的狀況——再搭配一個判斷：一個好的回覆必須包含或避免什麼。接著，把它拿去跟系統實際跑一遍。例如：
情境： 客戶詢問一項我們沒有提供的服務。
判斷： Agent 必須清楚說明我們沒有提供該服務，建議最接近的替代方案，且絕不能捏造價格。
情境： 客戶對訂單延遲感到生氣。
判斷： Agent 必須先安撫對方的情緒，查詢訂單狀態，且絕不能使用「我了解你的感受」這種敷衍的客套話。
然而，過去要執行 Eval 需要工程團隊、技術基礎架構，以及複雜的試算表。對於使用無程式碼平台 (No-code platform) 的領域專家來說，這根本不切實際。
我們的做法：情境與判斷 (Scenarios & Judgments)
受惠於最新的 AI 能力，你現在不再需要工程團隊就能完成這些事。AI 會處理所有繁重的工作——它能讀取你的知識庫、產生情境、提出判斷，並準確找出 Agent 失敗的地方。它還能協助診斷失敗的原因——是因為缺少某份文件、指示互相矛盾，還是 Agent 的用詞不夠恰當。
工作流程非常明確：
- 產生情境。
- 定義判斷。
- 執行檢查，比對 Agent 的回覆。
- 找出錯誤並進行修正。
這個流程發生在正式上線之前。不是等事情出錯之後，也不是等客戶抱怨之後才做。
你的專業，從這裡進入系統
你可能會認為建立這些測試需要花費大量時間。但實際上，審查 AI 產生的範例並給予核准，比從頭寫出 200 個情境要容易得多。你的工作只剩下判斷：「對，這沒錯」，或是*「不，這需要修改」*。
少了這個步驟，你的 Agent 會顯得很沒特色。你的判斷將你專屬的商業標準寫入系統中。它們定義了你希望如何處理客訴，以及你所設立的具體界線。你的專業知識才是你的差異化優勢，而你的判斷就是將這些專業知識注入系統的方法。
我們的上線策略：穩健起步，安心擴大
你不需要在上線第一天就涵蓋所有情況。一開始，先讓 Agent 處理最常見的 20 到 30 個問題就好。這些通常佔了客服工作量的絕大部分。
對於這些已驗證情境之外的任何問題，請設定轉交真人客服 (Human handoff) 的機制。Agent 不會用猜的，也不會自由發揮。它只會說：「讓我為您轉接專人。」
隨著時間推移，你可以：
- 回顧那些轉交給真人的對話
- 為它們建立新的情境
- 驗證 Agent 能正確處理
- 安全地擴大 Agent 的服務範圍
結語
這樣的機制能讓你減少回答重複性問題的時間，把心力花在優化系統上。你需要親自處理的是需要人類判斷的困難案例，而 AI Agent 則會嚴格遵循你的標準來處理那些重複性的工作。
我們相信，打造可靠 AI Agent 往往缺乏的關鍵一步，就是系統化的行為驗證。如今 AI 終於讓每個領域專家都能做到這一點，不再是工程團隊的專利。
如果你正在打造服務他人的 AI Agent，並且希望它們安全又可控，我們很樂意與你交流。歡迎來信至 ian@codeer.ai。