LangChain 和 LangGraph 差在哪？用任務風險選對 Agent 架構

LangChain 和 LangGraph 差在哪？用任務風險選對 Agent 架構

LangChain 與 LangGraph 不是互斥產品，而是不同層級的工具。官方目前把 LangChain 定位為可組合的 Agent harness，將模型、工具、提示與 middleware 組成 Agent；LangGraph 則是處理長時間、有狀態流程的低階編排 runtime。選擇標準不是功能多寡，而是你的工作是否需要明確狀態、持久化與人工核准。

文章實體化：LangChain 和 LangGraph 差在哪？用任務風險選對 Agent 架構

本文以「LangChain 和 LangGraph 差在哪？用任務風險選對 Agent 架構」為主線，補回模型／工具、輸入輸出、版本、成本、測試與使用邊界，讓技術名詞回到可執行的工作流程。

• 核心元件：把標題中的模型、工具、格式或協定對應到實際輸入、輸出與依賴。
• 驗證方法：記錄版本、資料、環境、基準、錯誤案例與人工檢查，避免只引用功能宣稱。
• 治理邊界：說明權限、資料保存、成本、失敗回復與何時需要人工介入。

涉及版本、價格或 API 行為時，以文章原始資料與供應商最新文件核對。

先用這張判斷表

• 短任務、少量工具：先用 LangChain 的高階 Agent。
• 長任務、分支與恢復：使用 LangGraph，將狀態與每個節點寫清楚。
• 需要規劃、檔案系統與子代理：評估 Deep Agents；官方將其定位為建立在 LangGraph 上的 harness。
• 需要追蹤、除錯與評估：使用 LangSmith 觀察 trace 和輸出品質。

LangChain：先把 Agent 做小

官方的 create_agent 以模型、工具、提示和 middleware 組成最小可用 harness。適合能在短時間安全重跑的任務，例如文件分類、知識問答或內部查詢。即使是小任務，也應設定工具 allowlist、逾時、最大回合數與結構化錯誤。

LangGraph：把無法重跑的流程顯式化

LangGraph 可以在同一張 graph 混合確定性程式步驟與模型決策，並提供持久化、串流與 human-in-the-loop。當任務跨很久、有分支、失敗後不能從頭重跑，或必須在付款、部署、刪除、對外發送前停下來給人確認時，這種顯式狀態才有價值。

state = {
  task_id: "billing-fix-42",
  stage: "awaiting_approval",
  evidence: ["test-result.json"],
  external_resource_id: null
}

範例是設計建議，不是官方固定 schema。State 只保留下一步真正需要的內容；大型檔案與完整 log 應改存為 artifact，並在 State 記錄版本與位置。

持久化不等於安全重試

LangGraph 的 persistence 能讓工作流從已保存狀態恢復，但外部副作用仍須自己保護。寄信、付款、建立帳號或寫入資料時，要保存外部資源 ID、使用 idempotency key，並在重試前先讀取真實外部狀態。否則，你只是在更可靠地重複錯誤動作。

導入順序

1. 用一個低風險 LangChain Agent 驗證模型、工具與驗收標準。
2. 找出真正需要中斷、分支或恢復的節點。
3. 只將這些節點移進 LangGraph，加入持久化與人工 gate。
4. 測試失敗恢復、重試與重複副作用。
5. 用 trace 與固定案例評估品質、成本與人工修正量。

官方來源

• LangChain overview
• LangGraph overview
• LangGraph persistence