LangGraph：把狀態、流程與人工介入變成可恢復的 AI Agent 圖

LangGraph：把狀態、流程與人工介入變成可恢復的 AI Agent 圖

先講結論：Agent 的難題不是「會不會呼叫模型」

把一個模型包進聊天介面，今天已經不是最難的工程。真正讓 AI Agent 從展示用原型走向可靠產品的，通常是另一組問題：任務跑到一半要不要能恢復？工具失敗後能不能重試？人工審核插入流程時，狀態是否仍然一致？多輪對話與長期記憶要放在哪裡？[3][5][7]

LangGraph 的價值，正好落在這個工程層。它不是另一個模型，也不是把所有事情自動包好的黑盒 Agent builder；官方把它定位成用來建立長時間執行、有狀態 Agent 的低階 orchestration framework。[3] 專案的核心抽象很簡單：把共享狀態放進 graph，讓節點負責處理狀態，讓 edges 決定下一步，最後編譯成可執行的工作流。[3][4]

截至 2026 年 8 月 19 日，GitHub API 顯示 LangGraph 約有 40,005 顆星，主要語言為 Python，且仍在持續更新。[2] 對 AI 工程團隊而言，這不是「又一個聊天機器人範例」，而是一個值得研究的問題：當 Agent 需要可觀測、可暫停、可恢復時，graph 是否比一個超長的 while 迴圈更容易維護？

LangGraph 解決的是哪一層問題？

一個實際的 Agent 通常同時包含幾種不同性質的工作：模型判斷意圖、查詢資料、呼叫外部 API、檢查結果、要求人員批准，以及在失敗後重試。若把這些步驟全部揉成一個函式，程式一開始很快，但很難回答「現在跑到哪裡」與「失敗後從哪裡繼續」。

LangGraph 將這些步驟拆成圖上的節點。每個節點接收目前狀態，回傳要合併回去的更新；邊則描述固定路徑或條件分支。這個模型讓工程師可以把「流程控制」從模型輸出中抽離：模型可以負責提出下一個動作，但真正允許哪些轉移，仍由程式碼決定。[3][4]

這個區分非常重要。Agent 的非決定性來自模型，但產品的可靠性不能全部交給模型。把路由、權限、重試與停止條件明確寫成 graph，才有機會測試，也才有機會在 production 中診斷。[3]

最小模型：State、Node、Edge

先看一個不依賴特定模型供應商的最小工作流。這段程式只示範 LangGraph 的控制面：一個節點修改狀態，另一個節點完成摘要，最後從 START 走到 END。

from typing import TypedDict
from langgraph.graph import StateGraph, START, END

class State(TypedDict):
    question: str
    answer: str


def answer_question(state: State):
    return {"answer": f"收到問題：{state['question']}"}


def summarize(state: State):
    return {"answer": state["answer"] + "（已完成）"}


builder = StateGraph(State)
builder.add_node("answer_question", answer_question)
builder.add_node("summarize", summarize)
builder.add_edge(START, "answer_question")
builder.add_edge("answer_question", "summarize")
builder.add_edge("summarize", END)

graph = builder.compile()
result = graph.invoke({"question": "如何開始？", "answer": ""})
print(result["answer"])

這個範例刻意沒有放入 LLM，因為最值得先理解的是邊界：State 是流程的資料契約，node 是可測試的工作單位，edge 是控制流程。等這三者穩定後，再把模型或工具放進某個 node，比直接從一個「全能 Agent」函式開始更容易定位問題。[3][4]

官方 quickstart 也採用相同方向，先建立訊息狀態，再加入模型節點與工具節點，最後用條件 edge 判斷要繼續呼叫工具，還是結束回覆。[4] 這種設計讓「模型決定是否需要工具」與「程式定義工具迴圈怎麼走」各自有清楚責任。

為什麼狀態圖比 while 迴圈更適合長流程？

while 迴圈並不是錯。對一次性的簡單任務，它可能是最直接的做法。但當流程加入人審、重試、長時間等待、外部副作用與多個分支後，單一迴圈會開始承擔太多責任：保存上下文、判斷當前階段、決定錯誤處理、記錄工具結果，還要想辦法讓下一次執行知道上一次停在哪裡。

Graph 的好處不是「程式碼一定比較少」，而是把流程拆成可命名的狀態轉移。你可以針對每個 node 寫單元測試，針對每條條件 edge 寫路由測試，也可以在觀測資料中回答「哪一個節點耗時最久」或「哪一種輸入最常走到人工審核」。這是架構可見性，而不是語法上的便利。[3]

更重要的是，LangGraph 將 persistence 視為執行模型的一部分。官方的 durable execution 說明指出，搭配 checkpointer 與合適的執行設定後，工作流可以在中斷後從保存的狀態繼續，而不是每次都從頭開始。[5] 對付款前審核、長時間研究、瀏覽器操作或需要等待外部事件的任務，這個差異會直接影響成本與使用者體驗。

三個真正有產品價值的能力

1. Durable execution：失敗不等於重新開始

長流程最怕「前面已經做完的副作用被重複做一次」。例如，Agent 已經建立工單，接著在通知階段逾時；如果重新執行沒有清楚的 checkpoint 與冪等設計，就可能建立第二張工單。

LangGraph 的 persistence 與 durable execution 讓流程可以保存執行狀態，並在適當的 checkpoint 後恢復。[5] 但這不是自動替你解決所有一致性問題：具有外部副作用的 node 仍然要設計成可重試、可去重或具備明確的交易邊界。正確的心法是把「可恢復」當成系統設計，而不是把它當成某個 API 開關。

2. Interrupts：把人工介入變成流程節點

Human-in-the-loop 常被做成散落在服務外的 callback：某個 API 回傳待審核，另一個服務再想辦法接回來。這種方式很快能跑，但狀態與權限容易失去同一個上下文。

LangGraph 提供 interrupts，讓 graph 可以在特定位置暫停，等待外部輸入，再從中斷點繼續。[6] 實務上可以用於高風險工具呼叫、內容發布前審核、敏感資料存取或需要補充欄位的表單流程。工程團隊仍須自行處理身份驗證、權限與輸入驗證；LangGraph 負責的是把「暫停—等待—恢復」納入同一個執行模型，而不是取代產品的治理層。

3. Memory：把短期上下文與長期資料分開

對話記憶不應該只有一個無限增長的 message list。LangGraph 的 memory 文件區分了 thread 內的短期記憶，以及可跨 thread 使用的長期記憶；前者支援對話或單次任務的持續狀態，後者則適合保存使用者偏好等跨工作流資料。[7]

這個區分會影響資料生命週期與隱私設計。短期狀態可以跟著執行緒清理，長期資料則需要明確的 schema、保留期限、刪除機制與存取控制。把兩者混在一起，往往會讓 prompt 越來越長，也讓刪除個人資料變得困難。[7]

一個較接近 production 的拆法

如果要把客服 Agent 或內部研究 Agent 做成可維護服務，我會先把 graph 分成四種節點：

1. 輸入與規則節點：整理請求、檢查權限與建立 correlation id。這裡不要讓模型自行決定是否可以跳過安全檢查。
2. 推理節點：呼叫模型，把問題轉成結構化意圖或下一個候選動作。輸出要有 schema，並保留原始回應供除錯。
3. 工具節點：執行搜尋、資料庫查詢或外部 API。每個工具都要有 timeout、重試上限、冪等策略與錯誤分類。
4. 審核與收尾節點：遇到高風險動作就 interrupt，完成後再寫入結果、更新狀態並產生可追蹤的回覆。

接著再用條件 edge 表達「查不到資料時改走澄清」、「工具失敗時最多重試兩次」、「風險分數超過門檻時要求人工批准」。這些規則不應只存在 system prompt 裡，因為 prompt 不是可靠的權限邊界，也不適合單獨承擔流程保證。

LangGraph 不適合什麼？

第一，如果你的需求只是一次模型呼叫加上一個固定的 API，直接使用 provider SDK 或普通服務函式會更簡單。第二，如果團隊還沒有明確的狀態契約、錯誤分類與測試策略，先導入 graph 可能只是把混亂搬到更多節點。第三，LangGraph 是 orchestration 層，不會替你選模型、建立資料治理政策，也不會自動讓不可靠的工具變可靠。

它最適合的訊號是：流程已經出現多個狀態與分支；任務可能跨越多次請求；需要暫停等待人或外部事件；失敗後必須從中途恢復；團隊希望把 Agent 的行為拆成可測試、可觀測的工作單位。若只是為了追逐「Agent framework」標籤而導入，反而可能增加認知負擔。

AI Chain 的實作判斷

LangGraph 值得關注，不是因為 graph 這個概念新，而是它把 Agent 最容易被忽略的工程問題放到第一級：狀態如何保存、流程如何轉移、何時可以暫停、怎麼在中斷後繼續。官方文件同時把 durable execution、interrupts、memory 與 streaming 等能力列為 LangGraph 的核心使用面向。[3][5][6]

我的建議是不要先從「我要做一個很聰明的 Agent」開始，而是先畫出一個可以被測試的狀態圖：輸入是什麼、每個 node 保證什麼、哪一些 edge 可以走、什麼情況必須停下來。等這張圖能被人讀懂，再把模型放進需要推理的節點。

這種做法不會消除模型的不確定性，但會把不確定性關在可觀測的邊界內。對要進入真實業務的 AI 系統來說，這通常比再增加一個 prompt 更有價值。

參考來源

本文依據 LangGraph 官方 GitHub repository、GitHub API metadata，以及 LangChain 官方文件整理；文中引用編號對應下列來源。[1][2][3]

Sources

[1] https://github.com/langchain-ai/langgraph

[2] https://api.github.com/repos/langchain-ai/langgraph

[3] https://docs.langchain.com/oss/python/langgraph/overview

[4] https://docs.langchain.com/oss/python/langgraph/quickstart

[5] https://docs.langchain.com/oss/python/langgraph/durable-execution

[6] https://docs.langchain.com/oss/python/langgraph/interrupts

[7] https://docs.langchain.com/oss/python/langgraph/memory