別把「Agent 編排」當成簡單的流程圖：AI Lab 交付中的狀態機陷阱與解法

在 AI Lab 的實際交付過程中，很多團隊在構建 Agent 時，最習慣的思維方式是「流程圖（Flowchart）」。他們會定義一個清晰的步驟 A $\rightarrow$ 步驟 B $\rightarrow$ 步驟 C，認為只要 Prompt 寫得足夠好，Agent 就能像執行腳本一樣順暢地走完整個鏈路。

但在處理複雜的工程化任務（例如：自動化程式碼審計、多步資料清洗或跨系統調度）時，這種「線性編排」很快就會崩潰。

線性編排的「脆弱性」

線性編排的核心假設是：每一步的輸出都是確定且正確的。然而，LLM 的本質是機率性的。在實際運行中，你會發現以下三種情況頻繁發生：

1. 邏輯回溯（Loopback）：Agent 在步驟 C 發現步驟 A 的輸入有誤，需要跳回 A 重新執行。
2. 條件分支爆炸（Branching Explosion）：為了覆蓋所有異常情況，流程圖會變得像蜘蛛網一樣複雜，維護成本極高。
3. 狀態遺失（State Loss）：在長鏈路中，Agent 容易忘記初始目標或遺失關鍵的中間變數。

當我們試圖用 if-else 或簡單的 DAG（有向無環圖）去修補這些問題時，我們實際上是在用傳統的確定性程式設計去對抗 LLM 的不確定性，這會導致程式碼庫迅速腐化。

從「流程圖」轉向「狀態機」

在 AI Lab 的工程實踐中，我們建議將 Agent 的核心邏輯從「流程驅動」轉向「狀態驅動」。

1. 定義明確的狀態空間 (State Space)

不要定義「第一步做什麼」，而要定義「當前處於什麼狀態」。例如：
- IDLE: 等待指令
- ANALYZING: 分析需求並拆解任務
- EXECUTING: 呼叫工具執行具體子任務
- VERIFYING: 對結果進行自我審計
- RECOVERING: 處理錯誤並嘗試修復

2. 基於狀態的轉移矩陣 (Transition Matrix)

每一個狀態只關心兩件事：觸發條件和目標狀態。
- 如果處於 VERIFYING 狀態且審計失敗 $\rightarrow$ 轉移到 RECOVERING 或回溯到 EXECUTING。
- 如果處於 EXECUTING 狀態且工具報錯 $\rightarrow$ 直接進入 RECOVERING。

這種模式將複雜的線性鏈路解構成了多個獨立的狀態節點。無論 LLM 在哪一步出錯，它只需要根據當前狀態尋找正確的轉移路徑，而不是在一個巨大的流程圖中迷路。

工程落地建議：解耦「決策」與「執行」

為了讓狀態機真正跑通，我們需要在架構上做一次徹底的解耦：

• 決策層 (The Planner)：由 LLM 擔任。它不負責寫程式碼或呼叫 API，只負責觀察當前狀態 $\text{S}n$ 和環境反饋 $\text{O}_n$，然後輸出下一個目標狀態 $\text{S}$。
• 執行層 (The Executor)：由確定性的 Python 程式碼擔任。它接收到 $\text{S}_{n+1}$ 指令後，執行預定義的工具集（Toolsets），並將結果返回給決策層。

這樣做的好處是： 你可以透過修改決策層的 Prompt 來優化 Agent 的邏輯靈活性，而無需改動底層的執行程式碼；同時，你可以透過日誌輕鬆追蹤 Agent 在哪個狀態之間發生了死循環（Infinite Loop），從而精準地進行針對性調優。

總結

AI Agent 的工程化不是要把 LLM 「馴化」成一個死板的腳本執行器，而是要為它的不確定性建構一套魯棒的容錯機制。放棄對完美線性流程的執念，擁抱基於狀態機的異步編排，才是 AI Lab 從 Demo 走向生產環境的關鍵一步。