標題：從「能跑通」到「工業級」：AI Agent 交付中的魯棒性陷阱與工程實踐

在 AI Lab 的交付過程中，最危險的階段就是「Demo 成功」後的那兩週。

很多團隊在交付 AI Agent 時，習慣於在理想環境下透過幾個精心設計的 Test Cases 證明其能力。然而，一旦進入真實生產環境，面對非結構化的使用者輸入、不穩定的 API 回應以及複雜的長鏈路依賴，原本「聰明」的 Agent 往往會迅速崩潰。

本文分享我們在將一個企業級知識庫 Agent 從原型推向生產環境時，踩過的三個坑以及相應的工程化解決方案。

1. 「幻覺」的工程化截斷：從 Prompt 到驗證層

早期的方案是不斷優化 System Prompt，告訴模型「如果你不知道，請回答不知道」。但這在實際操作中極其不穩定。

實踐方案：引入【驗證-修正】閉環（Verification Loop）。
我們不再信任模型的一次性輸出，而是將輸出結果交給一個輕量級的驗證器（Verifier）。
- 結構化校驗：強制要求模型輸出 JSON，並使用 Pydantic 進行 Schema 校驗。如果校驗失敗，直接觸發一次帶有錯誤訊息的重試（Retry），而不是將錯誤拋給使用者。
- 引用溯源校驗：對於 RAG 場景，驗證器會檢查模型生成的答案中是否包含真實的文件片段 ID。如果答案中出現了文件中不存在的關鍵字或事實，該條回覆會被標記為「低置信度」，觸發二次檢索或引導使用者重新提問。

2. 處理「長尾」異常：狀態機的回归

Agent 的核心是規劃（Planning），但純 LLM 的規劃在複雜鏈路中容易產生「邏輯漂移」。例如，在執行 A -> B -> C 的步驟時，模型可能會在 B 步驟陷入死迴圈或跳過 C 直接宣佈完成。

實踐方案：用狀態機（State Machine）約束 LLM 的自由度。
我們將 Agent 的行為定義為一組有限的狀態轉移圖（DAG）。LLM 不再決定「下一步做什麼」，而是決定「當前狀態下採取哪個動作」。
- 確定性路徑：關鍵業務節點（如支付、權限校驗）由硬編碼的狀態機控制。
- 機率性填充：僅在內容生成、意圖識別等環節給予 LLM 自由度。
這種「骨架確定，血肉靈活」的架構，將系統崩潰率降低了 60% 以上。

3. API 不穩定性與 Token 成本的平衡

在生產環境中，API 超時和 Rate Limit 是常態。簡單的 try-except 無法解決大規模併發下的雪崩效應。

實踐方案：多級降級策略（Degradation Strategy）。
- 模型分級：主鏈路使用 GPT-4o 等高效能模型；當偵測到高延遲或達到配額上限時，自動切換至 GPT-4o-mini 或本地部署的 Llama-3 等輕量級模型處理簡單任務。
- 快取語義層：引入向量資料庫快取常見問題的答案（Semantic Cache）。如果新請求與快取請求的餘弦相似度 > 0.95，直接回傳快取結果，無需呼叫 LLM。這不僅降低了成本，還將首字回應時間（TTFT）從秒級降低到了毫秒級。

總結

AI Agent 的交付不是一次關於「智能」的競賽，而是一次關於「確定性」的工程實踐。真正的工業級交付應該是：用最先進的模型提供能力上限，用最嚴苛的工程手段守住能力下限。

不要試圖透過增加 Prompt 的長度來解決穩定性問題，要透過建構一套能夠容錯、可觀測、可回滾的工程體系來承載智能。