別把「Agent 編排」當成萬靈丹：AI 工程化中狀態機與確定性路徑的回歸

在 AI Lab 的交付現場，最常見的一個誤區是：試圖用一個極其複雜的 Agent 編排框架（比如 LangGraph、CrewAI 或 AutoGPT 的變體）去解決所有業務邏輯。

很多團隊在專案初期會陷入一種「智慧崇拜」：他們設計一個擁有 10 個 Tool 的 Agent，給它一個寬泛的 System Prompt，然後期待它能透過自我反思（Self-Reflection）和動態規劃（Dynamic Planning）自動完成一個複雜的 B 端業務流程。

結果通常是：在 Demo 階段表現驚豔，但在生產環境（Production）中成了噩夢。

幻覺的代價：不可預測的執行路徑

當我們將業務邏輯交給 Agent 的「自主決策」時，我們實際上是在用機率分佈替代確定性邏輯。

在一個典型的企業級交付場景中——例如「自動化財務報表審計」——如果 Agent 在第三步決定跳過某個校驗環節，或者在第五步因為一次微小的 Token 波動而進入無窮迴圈，這種失敗是不可接受的。

在 AI Lab 的實際工程實踐中，我們發現：越是核心的業務鏈路，越需要回歸到「狀態機（State Machine）」而非「純 Agent」。

從「自主編排」到「受控流轉」

真正的 AI 工程化不是讓模型決定「怎麼走」，而是由工程師定義好「路怎麼走」，讓模型在每個節點上決定「填什麼」。

我們推崇的模式是 Deterministic Workflow + LLM Nodes：

1. 顯式狀態定義：將業務流程拆解為有限的狀態機（FSM）。例如：輸入解析 $\rightarrow$ 合規校驗 $\rightarrow$ 資料提取 $\rightarrow$ 結果彙整。
2. 強型別介面約束：每個節點之間傳遞的是結構化資料（JSON Schema），而不是一段隨意的對話文字。
3. 區域智慧，全域確定：LLM 只負責節點內部的非結構化 $\rightarrow$ 結構化轉換。例如，在合規校驗節點中，LLM 的任務是判斷文字是否違規並輸出 {"is_compliant": boolean, "reason": string}，而不是決定下一步該去哪個節點。
4. 異常分支硬編碼：如果 LLM 輸出不符合 Schema 或判定為失敗，直接觸發預設的 Error Handler 或人工介入（HITL），而不是讓 Agent 「嘗試重新思考」。

實戰教訓：為什麼不能依賴 Self-Correction？

很多框架宣傳的「自我修正」機制在複雜場景下往往會導致「幻覺疊加」。當模型第一次輸出錯誤時，它在第二次嘗試修正時可能會為了迎合預期的格式而編造事實。

我們在一次交付中發現，強制要求模型進行三次 Self-Correction 的鏈路，其最終準確率反而比單次輸出 + 硬性規則過濾低了 12%。因為模型在修正過程中遺失了原始上下文中的關鍵細節。

給 AI 工程團隊的建議

如果你正在建構一個面向生產環境的 AI 應用，請嘗試以下檢查清單：

• [ ] 路徑可見性：我能否在不執行程式的情況下，畫出所有可能的執行路徑圖？
• [ ] 狀態可追溯：如果系統在第 N 步出錯，我能否瞬間定位到是哪個節點的輸入/輸出導致了偏差？
• [ ] 邊界硬約束：關鍵的業務邏輯是否被寫在了 Python 程式碼裡，而不是寫在了 System Prompt 裡？
• [ ] 降級方案：當 LLM 回應超時或格式崩潰時，系統是否有非 AI 的備援邏輯？

AI 的價值在於處理模糊性（Ambiguity），而工程化的價值在於消除模糊性。不要試圖用一個更強大的模型來掩蓋架構上的不確定性。最好的 AI 系統應該是：骨架是剛性的狀態機，肌肉是靈活的大模型。