避坑指南：在生產環境部署 LLM Agent 時的「狀態漂移」與一致性陷阱

在 AI Lab 的實際交付過程中，我們經常遇到一個極具欺騙性的問題：Agent 在開發環境（Dev）表現完美，但在生產環境（Prod）運行一段時間後，邏輯開始出現不可預知的「漂移」。

很多團隊將其歸結為模型隨機性（Temperature），但經過深度覆盤，我們發現核心問題在於「狀態管理」的工程缺陷。

1. 什麼是狀態漂移？

在複雜的 Agent 工作流中，Agent 需要維護一個上下文狀態（State）。當這個狀態在分散式環境下傳遞，或者在長對話中被不斷壓縮/總結時，會產生兩種漂移：
- 語義漂移：Agent 在第 10 輪對話時，忘記了第 1 輪設定的嚴格約束。
- 結構漂移：Agent 輸出的 JSON 格式在壓力測試下偶爾遺漏關鍵字欄位，導致下游解析崩潰。

2. 實戰教訓：從「全量記憶」到「結構化快照」

早期的方案是簡單地將所有歷史記錄（Chat History）餵給模型。結果是：隨著 Token 增加，模型對指令的遵循度呈線性下降。

優化方案：引入 State Snapshot（狀態快照）機制。
我們將 Agent 的狀態分為三層：
- Core Identity (不變)：系統級 Prompt，強制鎖定角色和禁忌。
- Session Context (動態)：當前任務的關鍵變數（如 user_id, current_step, goal），以結構化 JSON 形式儲存在 Redis 中，每輪迭代強制刷新。
- Working Memory (臨時)：最近 3-5 輪的原始對話。

透過這種方式，即使對話很長，Agent 在每一輪開始前都會重新讀取一次「結構化快照」，確保其目標沒有偏移。

3. 工程實踐：防禦性輸出驗證 (Guardrails)

不要信任 LLM 的 JSON 輸出。在生產環境中，我們實施了「驗證-重試」循環：
1. Schema 強校驗：使用 Pydantic 定義嚴格的輸出模型。
2. 自修復機制：如果校驗失敗，將錯誤訊息（例如 Missing field 'action_id'）直接回饋給模型進行一次快速修正（Fast-Retry），而不是直接報錯給使用者。
3. 確定性路由：對於關鍵的分支判斷（如：是否需要呼叫支付介面），不再依賴 LLM 的自然語言描述，而是要求其輸出特定的列舉值（Enum），並在程式碼層做硬映射。

4. 給工程團隊的建議

如果你正在建構一個面向使用者的 Agent 產品，請記住：LLM 是不穩定的元件，而工程架構必須是穩定的。

• 不要試圖用 Prompt 解決所有邏輯問題 $\rightarrow$ 用程式碼定義工作流（DAG），用 LLM 完成節點內的內容生成。
• 監控不僅僅是 Token 數 $\rightarrow$ 建立「意圖達成率」和「格式錯誤率」的監控指標。
• 版本控制不僅是程式碼 $\rightarrow$ Prompt 的微小變動可能導致整個 Pipeline 的崩潰，必須像管理程式碼一樣管理 Prompt 版本。

文字煉金的本質不是追求完美的咒語，而是建構一套能夠容忍不完美輸出的工業級流水線。