LangGraph.js：把狀態放進圖裡，而不是放進 prompt 裡
Framework to build resilient language agents as graphs.
秒懂
- 它是什麼？
- LangGraph.js 是一個用 TypeScript 描述有狀態代理的低階編排框架，核心是把流程寫成圖、把狀態交給 checkpoint 管理。它適合需要持久執行與人工介入的長流程，代價是你要自己定義狀態結構與圖的拓撲，換取對流程的控制權。
- 適合誰用？
- 如果你的代理流程會跨越多次呼叫、需要在中途停下來等人確認，或在失敗後從中斷點續跑，LangGraph.js 的狀態圖與 checkpoint 設計正好對應這些需求，值得先用 @langchain/langgraph 搭配 @langchain/core 起一個最小圖驗證。若你的需求只是單次 LLM 呼叫加上幾個工具、沒有跨回合狀態，這層編排只會增加你要維護的節點與邊，改用更高階的 Deep Agents 或直接呼叫模型即可。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是長流程的狀態問題，不是模型能力問題
多數 LLM 應用一開始都是單次呼叫：丟 prompt、拿回文字、結束。一旦流程變成多步驟，例如先檢索、再判斷是否需要追問、追問後再改寫答案，狀態就會散落在呼叫端。開發者通常用一個物件在函式之間傳遞，失敗就從頭再跑一次。LangGraph.js 針對的正是這個斷點：README 將它定位為 low-level orchestration framework for building stateful agents，並把 durable execution、human-in-the-loop、comprehensive memory 列為主要能力。
它服務的對象很明確。需要長時間執行、需要人在中途介入、需要跨 session 記住事情的系統，是這個框架的目標場景。反之，如果你的代理只有一兩步、不需要續跑，這個框架提供的圖與 checkpoint 對你就是多餘的抽象層。README 自己也給了分流建議：想快速建代理的人應該先看 Deep Agents，那是建立在 LangGraph 之上的更高階套件。這句話等於承認 LangGraph 不是入門層，而是需要自行組裝的底層。
狀態圖、節點與 checkpoint 三件事如何串起來
LangGraph 的公開介面借鏡 NetworkX，執行模型則參考 Pregel 與 Apache Beam，這兩點寫在 README 的致謝段落裡。實務上的意義是：你用節點與邊描述流程，執行時由框架決定哪些節點可以並行、狀態如何合併。
狀態是整個設計的中心。節點讀取共享狀態、回傳狀態更新，而不是回傳一個全新的狀態物件。這種增量更新的寫法讓多個節點可以對同一份狀態貢獻內容，也讓框架能在每個步驟後保存快照。持久執行與人工介入都建立在這個快照上：README 描述 durable execution 為 agents that persist through failures and can run for extended periods, automatically resuming from exactly where they left off。人工介入則透過 interrupts 機制，讓你在執行途中檢視並修改狀態。
這裡有個容易被低估的設計含意。狀態的形狀由你定義，代表框架不會幫你決定什麼該存、什麼不該存。狀態設計得不好，checkpoint 就會變成一團難以推理的資料；狀態設計得好，續跑與介入才有意義。這是低階框架把責任交還給使用者的典型代價。
安裝與最小可跑路徑
安裝指令在 README 中寫得很直接：
npm install @langchain/langgraph @langchain/core
兩個套件都要裝，因為核心型別與基礎抽象在 @langchain/core，圖與 checkpoint 相關 API 在 @langchain/langgraph。README 同時說明 LangGraph 可以獨立使用，不一定需要 LangChain 其他部分，這對不想引入整包 LangChain 生態的團隊是個實際的減法。
接下來的工作都在文件站上。README 指向 docs.langchain.com 的 JavaScript 版 LangGraph 路徑，涵蓋 durable execution、interrupts、memory 三個主題頁，API 細節則在 reference.langchain.com 的 JavaScript 參考。要特別留意的是，README 本身沒有給出完整的圖定義範例，也沒有列出 checkpointer 的設定鍵。這代表你無法只看 README 就完成一個可續跑的代理，必須進到文件站。
部署路徑則指向 LangSmith 的 deployments 頁面。README 把 production-ready deployment 列為能力之一，但這條路徑與 LangSmith 綁在一起。若你要自架，文件站是否提供對等說明，從現有材料無法確認。
當流程不需要續跑時，這層編排是負擔
最常見的誤用是把 LangGraph 當成一般的代理框架來寫單步任務。結果是為了跑一次模型呼叫，你得先定義 state、宣告節點、連邊、選 checkpointer，最後執行。這些程式碼不會讓答案變好，只會讓除錯路徑變長。
第二個限制來自狀態的持久化。持久執行與人工介入都預設狀態能被保存與還原，這意味著你需要一個可靠的儲存層。README 沒有描述預設的儲存後端是什麼，也沒有說明在無狀態環境（例如短生命週期的 serverless 函式）中該怎麼處理 checkpoint。這不是文件疏漏的指控，而是採用前必須自己查清的問題：如果每個請求都落在新的執行環境，你的 checkpoint 存在哪裡。
第三個限制是版本節奏。近期 release 顯示 @langchain/react、@langchain/svelte、@langchain/vue 都在 1.0.36-rc.1 這個 release candidate 階段，時間是 2026-09-09。前端綁定套件還在 RC，代表這部分的 API 尚未凍結。核心套件與綁定套件的版本耦合程度，需要你自己在升級時驗證。
與 LangChain 的分工，以及 Deep Agents 這條替代路線
最直接的對照是 LangChain 本身。README 把兩者分得很清楚：LangChain 提供 integrations and composable components，用來簡化 LLM 應用開發；LangGraph 負責 agent orchestration。差別在抽象層次。LangChain 幫你接模型、接向量庫、接工具；LangGraph 幫你決定這些元件在什麼順序、什麼條件下被呼叫，以及呼叫之間狀態怎麼留。你可以只用 LangGraph 不用 LangChain，README 明說可以。
另一條路線是 Deep Agents。它是建立在 LangGraph 之上的更高階套件，README 描述它讓代理能 plan、use subagents、leverage file systems。差別同樣是控制權與便利性的交換：Deep Agents 幫你把規劃與子代理的結構決定好，LangGraph 則把這些決定留給你。如果你的問題是「我想要一個會規劃的代理」，Deep Agents 是更短的路径；如果你的問題是「我的流程有特殊的審核關卡與狀態轉移條件」，LangGraph 才是對的層級。
還有一個不能忽略的替代品是 Python 版的 LangGraph。README 明確指向同名的 Python 函式庫與 Python 文件。若你的團隊主要寫 Python，直接使用 Python 版會比在 TypeScript 中重寫來得自然，兩邊的概念模型一致，但生態與套件不同。
MIT 授權與升級成本的實際考量
LangGraph.js 採 MIT 授權，這對商業使用相對寬鬆，允許修改與再散布，但授權條款不涉及任何形式的保證。這裡不構成法律意見，實際條文仍應由法務確認。真正需要留意的是生態中其他元件的授權與商業條款是否一致，特別是當你把 LangSmith 納入部署與可觀測性時。README 把 LangSmith 描述為用於 agent evals、observability 與 deployments 的產品，這是一項獨立於 MIT 函式庫之外的商業服務。
升級成本主要落在兩處。第一是核心套件與前端綁定套件的版本關係，目前綁定套件處於 1.0.36-rc.1 的 release candidate 階段，RC 意味著 API 仍可能變動，鎖定版本並在升級前讀 release notes 是必要的動作。第二是狀態結構的演進。當你的 state schema 改變，既有的 checkpoint 資料如何處理，取決於你的儲存層設計，框架不會替你遷移。這是低階框架把控制權交出去之後，隨之而來的維運責任。
最後一點關於採用判斷。README 提到 Replit、Uber、LinkedIn、GitLab 等公司在使用，但這些是行銷層面的背書，不是技術保證。真正該驗證的是你自己的流程：寫一個兩節點的圖，接上 checkpointer，故意讓第二個節點拋錯，看它能否從中斷點續跑。這個測試跑得過，再談導入。
編輯結論
如果你的代理流程會跨越多次呼叫、需要在中途停下來等人確認，或在失敗後從中斷點續跑，LangGraph.js 的狀態圖與 checkpoint 設計正好對應這些需求，值得先用 @langchain/langgraph 搭配 @langchain/core 起一個最小圖驗證。若你的需求只是單次 LLM 呼叫加上幾個工具、沒有跨回合狀態，這層編排只會增加你要維護的節點與邊，改用更高階的 Deep Agents 或直接呼叫模型即可。導入前先確認三件事：你的執行環境能否提供持久化的 checkpointer 儲存、LangSmith 是否納入你的可觀測性預算，以及團隊是否接受自行定義 state schema 與 reducer。這三項沒談清楚，圖寫得再漂亮也跑不進生產。
社群筆記