五個 Lang，各自佔一個位置

LangChain、LangGraph、LangSmith、Langfuse、LangFlow。名字都以 Lang 開頭，常被放在一起比較，但其中兩個是你 npm install 進專案的函式庫，另外三個是要另外部署或註冊的服務。先分清形態，選擇就簡單了。

先分清形態

把五個東西放進同一張比較表之前，得先承認它們不是同一種東西。函式庫是你 import 進來、跟你的程式碼一起部署的；服務是獨立跑的行程，你的程式碼只是把資料送過去。這個差別決定了誰要顧維運、誰要付費、資料會流到哪裡。

TypeScript 專案要特別注意：LangFlow 的後端是 Python（FastAPI），沒有 npm 套件。對 TS 專案來說它純粹是一個外部服務，你透過它產出的 REST／MCP 端點去呼叫，不會出現在你的 package.json 裡。這其實正好印證了上面的分類邏輯。

「不適用」不是不能自架，而是它們本來就沒有獨立的服務端可架——那是你 app 的一部分。

堆疊關係

真正在生產環境跑起來時，這五個工具不是平行的選項，而是疊在一起的層。下圖把它們的堆疊關係與 trace一次請求從進到出的完整執行紀錄：檢索了哪些文件、送出的 prompt、tool 呼叫、延遲與成本。 資料流畫出來——實線是函式庫、虛線是獨立部署的服務。

LangChain

函式庫 應用開發層

開源框架，提供把 LLM 接上外部資料、API 與工具的預建元件。不用自己處理各家模型的介面差異、向量庫的檢索邏輯、工具呼叫的解析。

需要注意的是它的定位已經變了。LangChain 與 LangGraph 都在 2025 年 10 月 22 日推出 1.0，架構重新定調：LangGraph 成為底層 runtime，LangChain 變成上層有主見的高階 API。核心入口是 createAgent，舊的 LCEL chain 與 @langchain/langgraph/prebuilt 的 createReactAgent 已被棄用。

「LangChain 做 chain、LangGraph 做 agent」這個 1.0 之前的心智模型已經不成立了。現在是同一套東西的兩個高度。

官方承諾 2.0 之前不會有破壞性變更，所以現在是相對安穩的進場時機。

npm install langchain @langchain/core @langchain/langgraph zod
npm install @langchain/anthropic   # 或其他 provider

import { createAgent, tool } from "langchain";
import * as z from "zod";
​
const getWeather = tool(
  (input) => `${input.city} 現在是晴天`,
  {
    name: "get_weather",
    description: "查詢指定城市的天氣",
    schema: z.object({ city: z.string() }),
  }
);
​
const agent = createAgent({
  model: "claude-sonnet-4-6",
  tools: [getWeather],
});
​
const result = await agent.invoke({
  messages: [{ role: "user", content: "高雄天氣如何？" }],
});

TS 這邊 v1 遷移有兩件事值得記：舊的抽象（LLMChain、initializeAgentExecutorWithOptions 之類）搬到了 @langchain/classic，還有新增的 ContentBlock 型別讓多模態輸入能正確推導型別。小到中型專案的遷移大約是幾小時的工。

LangGraph

函式庫 編排 / 執行層

以圖為架構：節點是函式，邊是轉移，runtime 維護跨節點的 state，條件邊依 state 分支。它解決的是 chain 結構做不到的事——循環、重試、條件路由、多 agent 協作、人工審核中斷。

最有說服力的採用理由是可靠度的數學。十個 tool call、每步 85% 成功率，全程走完的機率只有約 20%（0.85^10）。換更強的模型不會修好網路逾時，只有 checkpoint把執行進度存檔，失敗後可從中斷處 resume，而不是整條流程重跑。 與 resume 可以。

人工介入的模式也換了：現在是 interrupt() 搭配 Command（帶 resume）恢復執行，通常包在 human-in-the-loop middleware 裡，而非舊的 interruptBefore 編譯旗標。TS 版本從 @langchain/langgraph 匯入，命名是 camelCase，其餘概念與 Python 版一致。

Langfuse

服務 可觀測 / 評估層 MIT · 可自架

形態上它是一組後端服務（含資料庫），你的應用透過 SDK 或 OpenTelemetry 把 trace 送過去。要嘛用他們的雲端，要嘛用 Docker／Helm 自己架一份——MIT 授權，自架沒有授權費。

TS 專案接法是裝 JS/TS SDK，用 callback handler 掛進 LangChain 執行流程；它同時支援 OpenTelemetry，所以就算之後換掉框架，儀器化的部分不用重寫。

使用者不會說「prompt 的 context 不足」。他們只會說「它給我錯的答案」。剩下的得靠 trace 自己查。

LangSmith

服務 可觀測 / 評估層 閉源 · 託管

功能定位跟 Langfuse 高度重疊：追蹤、評估、prompt 管理、資料集。差別在商業模式與生態綁定。

它是閉源的託管服務，Developer 方案免費（單一 seat、額度有限），付費方案按 seat 加 trace 用量計費。自架只開放給 Enterprise 方案，且部分功能在自架版本不提供。

選它的理由通常是深度整合：LangGraph Studio 的視覺化逐步除錯、託管的 agent 部署，這些跟 LangChain 官方工具鏈咬得比較緊。它本身是框架無關的（用 traceable 包裝任何程式碼都能送 trace），但最順的路徑仍然是 LangChain 與 LangGraph。

那到底選哪個

判斷點通常不是功能，是這兩件事：資料能不能離開你的機房，以及團隊會長到多大。

• 醫療、金融業無法把病患或財務資料送到第三方 → Langfuse 可完全自架；LangSmith 的自架門檻在 Enterprise
• Langfuse 的線上確定性評估仍在 roadmap 上而非正式版，LangSmith 這塊目前較完整
• LangSmith 按 seat 計費，人一多成本線性成長；Langfuse 不按 seat 計費

兩邊的官方比較文都存在，但都由當事人撰寫，看的時候記得打折。

LangFlow

自架應用 視覺化建構層 MIT

低程式碼的視覺化建構器：React Flow 的拖拉前端加上 FastAPI 後端，每一個流程都能直接對外變成 REST API、MCP server 或相容 OpenAI 的端點。元件本身是可編輯的 Python，所以不是只能點按——卡住的地方可以掉下去寫程式碼。

它的形態最特別：這是一個你要跑起來的網頁應用，不是你 import 的套件。透過 PyPI、Docker、Helm 或桌面版安裝。

身世也繞了一圈。Langflow 2024 年被 DataStax 收購，DataStax 又在 2025 年 5 月 28 日被 IBM 併購完成，因此現在屬於 IBM，但仍維持 MIT 開源。

適合的情境是讓非工程背景的成員也能參與組裝流程，或是快速試不同的 RAG 拓撲。不適合的情境是把它當成生產環境的執行引擎——真的要上線，多數團隊還是會把流程搬回程式碼。

什麼時候用哪個

下面把六種常見情境收成一張互動選型卡——多數時候答案是「組合」，不是二選一。

建議的採用順序

1. 01

   先用 createAgent 做出可跑的版本

   不要一開始就手刻 graph，多數需求高階 API 就滿足了。想更快看到形狀，可以先在 LangFlow 上拖一版當草稿。

2. 02

   第一天就接上 Langfuse 或 LangSmith

   不是等出問題才裝——出問題時你需要的是「當時」的紀錄，那時候補裝已經來不及。

3. 03

   真的需要循環、分支、人工介入時，再往下掉到 StateGraph

   高階 API 撐不住的那一刻你會很清楚，在那之前不必付這個複雜度的代價。

回到開頭那句：這些不是選擇題。實務上的答案是「用 LangChain 寫、跑在 LangGraph 上、把 trace 送進 Langfuse 或 LangSmith」，LangFlow 則是視團隊組成決定要不要加的一層。分不清楚的時候，先問它是函式庫還是服務，答案通常就出來了。

延伸閱讀

• Langfuse — LangChain & LangGraph 整合文件
• Langfuse — 加入 ClickHouse 的公告
• ClickHouse — 收購 Langfuse 說明
• LangChain — LangSmith 與 Langfuse 對照（官方立場，請斟酌）
• DataStax — 託管版 Langflow 棄用公告
• IBM — 收購 DataStax 新聞稿

內容整理於 2026 年 7 月 · 版本、方案與價格隨時異動，請以各官方文件為準