從 Prompt Chaining 到狀態機：為什麼 Agent Workflow 需要真正的工程化思維

當前的 AI Agent 開發，許多團隊仍停留在線性的 prompt chaining 思維，這種作法雖然快速，卻犧牲了系統的穩定性與可控性。我認為，真正能產品化的 Agent workflow，不應只是一連串的 API 呼叫，而必須被設計成一個可工程化的狀態機（State Machine）。透過明確定義狀態、轉移條件與驗證節點，我們才能將難以預測的 AI 鏈條，轉化為一個可觀測、可除錯、且具備容錯能力的穩健系統。這不僅是技術選擇，更是思維模式的轉變，決定了我們是在打造一個脆弱的腳本，還是一個強韌的系統。

為什麼簡單的 Prompt Chaining 不再足夠？

在 AI 應用的初期，我們習慣將任務拆解成一系列線性的提示（prompt），形成一個鏈條（chain）。例如，先讓一個 LLM 摘要文章，再讓另一個 LLM 根據摘要產生社群貼文。這種方法在處理簡單、確定性的流程時很有效。然而，當我們試圖建構更複雜、需要與外部工具互動、甚至能自主決策的 Agent 時，prompt chaining 的脆弱性便暴露無遺。

線性的鏈條缺乏彈性。只要中間一個環節出錯，例如工具 API 回傳非預期的格式，或 LLM 的回應偏離軌道，整個流程就會中斷。它也難以處理需要迴圈（loop）、條件分支（branching）或使用者介入的複雜情境。開發者往往需要用大量的膠水程式碼（glue code）來處理這些例外，使得系統變得難以維護與擴展。

更關鍵的是，這種模式本質上是「無狀態」的，每一次執行都是一次性的，難以追蹤、除錯或從中斷點恢復。這在要求高可靠性的生產環境中，無疑是致命的缺陷。

為什麼將 Agent Workflow 顯式化為狀態機是關鍵？

解決這個問題的根本方法，是借鏡傳統軟體工程中早已成熟的有限狀態機（Finite State Machine, FSM）概念。一個 Agent 的工作流程，本質上就是在不同狀態之間根據特定條件進行轉移的過程。將這個過程顯式地模型化，我們就能獲得前所未有的控制力與可觀測性。

一個狀態機驅動的 Agent workflow 通常包含以下核心元素：

• 狀態（State）：一個共享的資料結構，代表了 Agent 在任何時間點的完整上下文。這可能包含使用者的輸入、歷史對話、工具的輸出、以及中間的思考過程。
• 節點（Nodes）：執行動​​作的單位。每個節點都是一個可被呼叫的函式或物件，例如一次 LLM 呼叫、一個工具的執行，或一段業務邏輯。每個節點的任務是接收當前狀態，執行運算，並更新狀態。
• 邊（Edges）：定義了節點之間的轉移路徑。在最簡單的情況下，一個節點完成後會直接進入下一個節點。更強大的是「條件邊」（Conditional Edges），它能根據當前狀態的內容，動態決定下一步該走向哪個節點，從而實現複雜的分支與迴圈邏輯。

這種設計將「做什麼」（節點）與「下一步去哪裡」（邊）徹底分離。整個 Agent 的運行軌跡變成一張清晰的圖（Graph），每個狀態的變化都有跡可循，大幅降低了除錯的難度。

我們需要從「串接提示」的工匠思維，轉向「設計系統」的工程思維。Agent 的可靠性，源自於其底層結構的確定性。

LangGraph 如何將理論化為實踐？

理論很美好，但工具的實現更為關鍵。LangGraph 就是將狀態機概念引入 LLM Agent 開發的代表性框架。它雖然是 LangChain 生態系的一部分，但其核心思想完全不同。它不再隱藏控制流程，而是提供一個名為 StateGraph 的類別，讓開發者用 Python 程式碼明確地定義狀態圖的每一個節點與邊。

以一個需要呼叫外部工具來查詢天氣的 Agent 為例。傳統的 ReAct Agent 可能會陷入不穩定的思考迴圈，但在 LangGraph 中，我們可以定義一個清晰的流程：

1. 起始節點：接收使用者問題，呼叫 LLM 判斷是否需要使用工具。
2. 條件邊：檢查 LLM 的輸出。如果包含 tool_calls，則轉移到「工具執行節點」；如果沒有，則直接轉移到「最終回應節點」。
3. 工具執行節點：執行天氣查詢 API，並將結果更新回狀態中。完成後，再回到起始節點，讓 LLM 根據新資訊生成答案。
4. 最終回應節點：將 LLM 生成的最終答案回傳給使用者，流程結束。

這個結構不僅清晰，更帶來了實質的工程效益。例如，根據日本開發者 Megumi Asayi 的實踐，在 langgraph>=1.0.0 的版本中，可以輕易實現至少 3 種強大的錯誤恢復模式。我們還能利用 Checkpointer 機制，例如 Postgres Checkpointer，將 Agent 的每一步狀態持久化到資料庫。這意味著，即使程式崩潰或需要數小時才能完成的長任務，也能從上一個成功的狀態安全地恢復，而不是從頭來過。

搭配 LangSmith 這類可觀測性平台，開發者可以視覺化地追蹤每一次執行的完整狀態圖，清楚看到 Agent 在哪個節點、基於什麼條件做出了轉移決策，以及每個節點的成本與延遲。這種透明度是傳統 prompt chaining 方法無法比擬的，也是將 AI Agent 從實驗性玩具推向企業級應用的關鍵一步。

狀態機思維：從實驗到產品的關鍵轉變

總結來說，將 Agent workflow 視為狀態機，不僅僅是一種技術上的升級，它更代表了一種思維上的成熟。它迫使我們思考邊界條件、錯誤處理與系統的可恢復性。當我們不再滿足於「它有時能成功」，而是追求「它可預期地成功」時，我們才算真正開始進行 AI 系統的工程化。

延伸閱讀

• AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (關於多 Agent 協作框架的學術論文)
• LangGraph 官方文件
• A-Z of Computer Science: State Machines (狀態機基礎概念)

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。