在前面的幾天中，我們從 Prompt、Context、Structured Output 一路走到 Tool Calling。此時你可能已經可以用簡單的 while 迴圈寫出一個基本的自主 Agent：模型思考 ➔ 呼叫工具 ➔ 取得結果 ➔ 再次思考。

然而，當你嘗試將這種簡單架構推進到企業級真實業務時，很快會遇到難以跨越的瓶頸：

• 多步驟長程任務中，如何確保流程不脫軌？
• 當模型遇到不確定的決策時，如何暫停流程並引入人工審批（Human-in-the-Loop）？
• 如果執行到第 5 步時網路斷線，如何實現時間旅行（Time Travel）與斷點續傳？
• 傳統的線性鏈（Linear Chains，如早期的 LangChain LCEL）天生不支援「循環（Cycles）」與「回溯（Backtracking）」。

為了徹底解決複雜 Agent 系統的控制力問題，LangChain 團隊推出了專門針對 Agent 的編排框架——LangGraph。

今天我們就來拆解：甚麼是 LangGraph？它的底層「圖（Graph）」模型是如何運作的？它又憑什麼成為現代生產級 Agent 的標準架構？

一、LangGraph 的核心本質：將 Agent 建模為「狀態機（State Machine）」

在傳統的軟體工程中，處理高複雜度、長週期的業務流程（如訂單狀態變更、審批工作流），最穩固的模式就是有限狀態機（Finite State Machine, FSM）。

LangGraph 的核心思想就是：

將 LLM 的決策流、工具調用與外部互動，全部抽象為一個具備「全域狀態（Global State）」的「有向圖（Directed Graph）」。

       ┌───────────────┐
       │   __start__   │
       └───────┬───────┘
               │
               ▼
       ┌───────────────┐
       │  agent (LLM)  │ ◄─────────────┐
       └───────┬───────┘               │
               │ (條件邊判斷)           │
        [需要使用工具？]                │ (循環執行)
        ├── 是 ──> ┌───────────────┐   │
        │          │  tools (Node) │ ──┘
        │          └───────────────┘
        └── 否 ──> ┌───────────────┐
                   │    __end__    │
                   └───────────────┘

這意味著 Agent 不再是黑盒子般的隨機漫遊，而是每一步都發生在明確定義的節點（Node）與邊（Edge）之上，具備極高的可觀察性（Observability）與確定性控制力。

二、LangGraph 的三大核心支柱

要理解 LangGraph 的架構，只需要掌握三個核心概念：

1. State（全域狀態）

• 角色：圖的「單一事實來源（Single Source of Truth）」。
• 運作機制：定義整個工作流共享的資料結構（通常使用 Python TypedDict 或 Pydantic）。圖中的每一個節點在執行時都會接收當前的 State，並回傳需要更新的欄位。

2. Nodes（節點）

• 角色：具體的「工作單元（Units of Work）」。
• 運作機制：本質上就是標準的 Python 函數（或 Runnable）。每個節點負責執行特定任務（例如：呼叫 LLM 進行意圖分析、執行 SQL 查詢、格式化輸出等）。

3. Edges（邊）

• 角色：決定「資料與控制權的流向」。
• 兩種類型：
  • 普通邊（Normal Edges）：確定性的下一步。例如 A 節點執行完必必定前往 B 節點（add_edge("node_a", "node_b")）。
  • 條件邊（Conditional Edges）：依據當前 State 的內容動態計算下一步。例如 LLM 若輸出工具調用則轉跳至 tools 節點，若無則轉跳至 END（add_conditional_edges(...)）。

三、為什麼 LangGraph 是生產級 Agent 的必備利器？

相較於傳統的 Agent 腳本或線性鏈，LangGraph 提供了四大關鍵能力：

1. 支援循環（First-class Support for Cycles）

真實世界的問題很少能一條線走到底。Agent 往往需要「嘗試 ➔ 檢查結果 ➔ 發現錯誤 ➔ 重新修正 ➔ 再嘗試」。LangGraph 原生支援循環與條件跳轉，這是傳統 DAG（有向無環圖）工作流框架（如 Airflow）難以自然實現的。

2. 內建持久化與檢查點（Persistence & Checkpointing）

LangGraph 內建 Checkpointer 機制（如 SQLite、Postgres、Redis）。每當一個節點執行完畢，系統會自動將當前 State 快照寫入儲存庫。

• 斷點續傳：伺服器重啟或網路中斷時，可從最後一個成功節點無縫復原。
• 多輪對話持久化：直接天然支援多 Session 的對話狀態儲存。

3. 人機協同（Human-in-the-Loop）

在進行敏感操作（如匯款、發送郵件、修改資料庫）前，LangGraph 支援設定 interrupt_before 或 interrupt_after。工作流會自動在指定節點前暫停掛起，等待人工在管理後台點擊審批或修改 State 後，再繼續向下執行。

4. 時間旅行（Time Travel / Rewind）

由於所有歷史 State 都有 Checkpoint，開發者可以任意「回滾（Fork/Rewind）」到先前的任一步驟，手動修正錯誤的上下文或狀態，再讓 Agent 從該點重新分支執行。

四、傳統鏈路 (Chains) vs. 傳統 Agent 迴圈 vs. LangGraph

小結與下集預告

LangGraph 將生成式 AI 的「隨機推論」與傳統軟體架構的「確定性狀態控制」完美融合。它不再把 Agent 當成不受控的魔法，而是將其規範在清晰、可觀測、可干預的狀態圖網絡中。

理解了 LangGraph 的圖模型架構後，在實務中我們該如何動手搭建第一個 Graph？如何定義 State、綁定 Node 與設定條件分支？

明天 【Day 11】怎麼應用 LangGraph，我們將進入實戰篇，透過 Python 程式碼從零構建一個具備條件路由、工具循環調用與持久化儲存的標準 LangGraph 狀態機！