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

在 AI Lab 的日常交付中，我們經常遇到一個現象：一個 Agent 在 Notebook 或簡單的 Gradio Demo 中表現驚豔，但一旦進入生產環境，其可靠性會迅速下降。這種從「實驗室 Demo」到「生產級產品」的落差，正是 AI 工程化的「最後一哩路」。

本文基於近期多個企業級 Agent 交付專案的實作經驗，探討在規模化部署時必須面對的三個核心工程陷阱及其解決方案。

陷阱一：對 LLM 「確定性」的幻覺

很多開發者習慣於透過精心設計的 Prompt 來控制輸出。但在生產環境下，即使是同一個模型版本，由於取樣隨機性（Temperature > 0）或底層基礎設施的微小波動，輸出格式仍會出現偏差。

實作教訓：
在一個自動化報表 Agent 專案中，我們最初依賴 LLM 直接輸出 JSON。結果在處理長文本時，LLM 偶爾會在 JSON 前後加上 ` ` `json ` 標籤，或者在某些欄位中遺漏引號，導致下游解析器直接崩潰。

工程化方案：
1. 強 Schema 約束：放棄純文字 Prompt 約束，全面轉向 JSON Mode 或 Function Calling。
2. 魯棒性解析層：在解析 JSON 前，使用正規表示式剔除 Markdown 程式碼塊標籤；若解析失敗，立即觸發一次輕量級的「格式修復」重試（Retry with correction prompt）。
3. 確定性驗證：引入 Pydantic 等函式庫進行執行階段類型校驗。只有通過 Schema 驗證的資料才能進入業務流程。

陷阱二：忽略了「狀態機」的複雜性

簡單的 Chatbot 是無狀態的（或僅依賴簡單的歷史記錄），但複雜的 Agent 通常涉及多步規劃（Planning）和工具呼叫（Tool Use）。當步驟增加到 5 步以上時，線性對話流會變得極其脆弱。

實作教訓：
在構建一個涉及「查詢-分析-繪圖-總結」的分析 Agent 時，如果使用者在第三步突然要求「修改第二步的查詢條件」，傳統的線性 Memory 會導致 Agent 在上下文視窗中迷失，產生嚴重的邏輯迴圈。

工程化方案：
1. 顯式狀態管理：將 Agent 的執行過程建模為有限狀態機（FSM）。每一步執行結果不僅存入 Memory，還要更新一個結構化的 `State` 物件（例如：`current_step: "analysis", \query_params: {...}`）。
2. 檢查點機制 (Checkpointing)：為關鍵步驟建立快照。當使用者要求回溯或修改時，Agent 可以直接跳轉回特定的狀態節點重新執行，而不是嘗試在對話歷史中透過自然語言地「說服」自己回去。

陷阱三：效能與成本的非線性增長

在 Demo 階段，為了追求效果，開發者傾向於使用最強的模型（如 GPT-4o 或 Claude 3.5 Sonnet）並填充巨大的 Context Window。但在日請求量達到萬級時，延遲和成本將成為致命傷。

實作教訓：
一個法律文件審核 Agent 在測試時表現完美，但上線後發現平均回應時間超過 30 秒，且 Token 消耗極快。原因是它每次呼叫都攜帶了全量文件作為上下文。

工程化方案：
1. 模型分級路由 (Model Routing)：並非所有步驟都需要最強模型。將任務拆分為「意圖識別 $\rightarrow$ 資訊檢索 $\rightarrow$ 精細生成」。意圖識別可用輕量級模型（如 GPT-4o-mini），僅在最終生成階段呼叫旗艦模型。
2. 動態上下文壓縮：不再簡單地傳遞 `last_n_messages`，而是引入摘要機制（Summarization）或基於語義的相關性檢索（RAG for Memory），僅保留與當前任務最相關的片段。
3. 非同步批次處理與串流輸出：對於耗時較長的 Planning 步驟，採用非同步佇列處理並即時推送中間狀態給使用者（例如：「正在檢索資料庫...」、「正在分析趨勢...」），以降低使用者的感知延遲。

總結

AI Agent 的交付不是關於如何寫出更好的 Prompt，而是關於如何構建一套能夠容忍 LLM 不確定性的工程系統。真正的生產級 Agent = $\text{LLM} + \text{強類型校驗} + \text{顯式狀態機} + \text{分級路由}$。當我們停止把 LLM 當作一個「全能神」，而將其視為一個「機率性的計算單元」時，工程化的真正優化才開始。