規模化 AI Agent 交付的「最後一哩路」：從 Demo 到生產環境的工程化陷阱

在 AI Lab 的日常交付中，我們經常遇到一個尷尬的現象：一個 Agent 在 Notebook 或 Playground 裡表現近乎完美，但一旦部署到生產環境，其可靠性會迅速下降。這種從「Demo 驚豔」到「生產崩潰」的落差，本質上是 AI 邏輯與工程穩健性之間的斷層。

本文基於近期幾個 Agent 交付專案的復盤，探討在將 LLM 應用規模化時，最容易被忽視的三個工程陷阱及其應對方案。

陷阱一：過度依賴 Prompt 的「脆弱平衡」

很多開發者習慣於透過不斷增加 Prompt 的長度和複雜度來修復 Bug。例如，當 Agent 在某個環節出錯時，會在 System Prompt 中加入一條：「請記住，在處理 X 情況時絕對不能做 Y」。

這種做法在短期內有效，但會導致兩個嚴重問題：
1. 注意力稀釋：隨著指令增加，LLM 對核心任務的遵循能力反而下降（Lost in the Middle）。
2. 回歸風險：修復 A Bug 的指令可能會意外觸發 B Bug。

工程化方案：邏輯解耦與狀態機控制
不要試圖用一個巨大的 Prompt 解決所有問題。我們將複雜的 Agent 工作流拆解為多個微小的、職責單一的子任務（Sub-tasks），並引入一個輕量級的狀態機（State Machine）來控制跳轉。
- 原子化 Prompt：每個子任務只負責一件事情（如：僅負責提取實體，或僅負責格式轉換）。
- 硬編碼校驗：在 LLM 輸出後，立即使用 Pydantic 或 JSON Schema 進行強類型校驗。如果校驗失敗，直接觸發重試或回滾到上一個穩定狀態，而不是指望 LLM「下次能寫對」。

陷阱二：忽略了上下文視窗的「熵增」過程

在長對話或複雜任務中，上下文視窗會迅速填滿。簡單的「截斷最近 N 條記錄」往往會導致 Agent 丟失關鍵的任務目標或使用者偏好。

工程化方案：分層記憶管理 (Layered Memory)
我們採用了一種分層儲存機制來替代簡單的滑動視窗：
1. 核心指令層 (Core)：始終置頂的 System Prompt 和當前任務的目標（Goal）。
2. 摘要層 (Summary)：利用 LLM 定期對歷史對話進行壓縮摘要，將 10 輪對話濃縮為一段關鍵事實描述。
3. 檢索層 (RAG)：將非即時相關的歷史資訊存入向量資料庫，僅在需要時透過語意檢索召回。

透過這種方式，Agent 在處理第 50 輪對話時，依然能清晰地記得第 1 輪使用者提出的核心約束條件。

陷阱三：缺乏可觀測性的「黑盒除錯」

當使用者回饋「Agent 回答得不對」時，如果你的日誌裡只有 User: xxx 和 Assistant: xxx，你將陷入無盡的猜測中。

工程化方案：全鏈路 Trace 與評估集 (Eval Set)
建立一套完整的可觀測性體系是規模化的前提：
- 中間步驟可見化：記錄 Agent 的思考鏈（Chain-of-Thought）、呼叫的 Tool 名稱及參數、以及 Tool 回傳的原始結果。
- 黃金資料集 (Golden Dataset)：針對每個核心場景建構一組 $\text{Input} \rightarrow \text{Expected Output}$ 的測試集。每次修改 Prompt 或模型版本後，自動執行全量回歸測試，計算準確率波動。
- 負樣本庫：專門收集導致 Agent「幻覺」或崩潰的邊界案例（Edge Cases），將其轉化為測試用例。

總結

AI Agent 的交付不是一次性的「寫好 Prompt」，而是一個持續的工程迭代過程。真正的可靠性來自於對 LLM 不確定性的承認 $\rightarrow$ 將不確定性限制在最小單元 $\rightarrow$ 用確定性的工程手段進行包裹和校驗。

從 Demo 到生產的距離，就是從「它能跑通」到「它不能出錯」的距離。