網路上存在兩個 LangChain。一個是官方文件版：每一篇教學都預設你已經選定它了。另一個是社群批評版：那裡把「抽象洩漏」當成某種人格特質來嘲笑。這份指南的核心主張：LangChain 不是「用或不用」的選擇題——它是有條件的，而條件是三個訊號，不是一種感覺。
兩邊錯在同樣的地方：他們把框架選擇當成忠誠度考驗，而不是一個有成本函數的工程決策。
把誠實的立場說清楚：多數專案應該從 raw SDK 開始，而其中一部分專案，在三個訊號出現之後應該採用 LangChain——更精確地說，是 LangGraph。這份指南會說明這三個訊號、讓框架決策保持可逆的遷移路徑，以及兩派陣營各自搞錯的反方論點。這是我們在犯下兩種錯誤——太早採用、太晚採用——之前，希望有人寫給我們的框架選擇指南。
為什麼「用或不用」是錯誤的問題
重點：框架論戰本質上是「複雜度稅」之爭——而這筆稅只有越過某個門檻才值得繳，行銷從來不提那個門檻。
2026 年的證據異常具體。LangChain 1.0 的重寫，用一個更乾淨的核心回應了多年來「它太臃腫」的抱怨——而複雜度稅的判決依然適用於那些拿框架去解決它解決不了的問題的團隊。另一方面，那些「設定勝過框架程式碼」的遷移故事，記錄的是反方向：團隊在發現自己的真實架構其實是「設定加一個迴圈」之後，離開框架。
兩個方向背後是同一個模式：**框架只有在你的系統真的需要它所提供的東西時，才值得繳那筆稅——學習曲線、抽象層間接、升級耦合。**兩步驟的 tool-calling 迴圈不需要圖形 runtime。十步驟、帶重試、checkpoint 與人類核准的有狀態工作流程，才真正需要。錯誤不在於選了哪一邊，而在於還沒弄清楚你的系統站在哪一邊就做了決定。
這代表什麼：三個值得採用框架的訊號
重點：狀態、分支、協作——三項中出現任何一項，就值得評估；出現兩項，就值得採用；而沒有一項是「demo 看起來很酷」。
**訊號一——必須存活下來的狀態。**你的工作流程有需要持久化與復原的狀態：被打斷的任務從中斷處接續、多輪 session 在當機後存活、人類核准中斷某個 run 之後再把它接回來。這是圖形 runtime 的核心強項——LangGraph 的 checkpointer 模型就是為此而生的——也是手刻迴圈處理得最差的訊號。
**訊號二——分支的複雜度。**超過一定數量的條件路徑、動態重新規劃、依賴中間結果的迴圈。當控制流程不再能當成線性腳本來閱讀時，宣告式圖形就是「工作流程就是程式碼」與「工作流程只是被寫在程式碼裡」之間的差別。
**訊號三——團隊協作。**多位工程師維護同一個代理、需要共享的抽象層、有版本的工作流程、以及可觀測性掛鉤。框架的慣例會變成團隊之間的契約——這是實打實的好處，但只有當團隊真的存在時才算數。
「還不到時候」的清單，也一樣直接說清楚：單一的 tool 迴圈、還在驗證階段的原型、以及任何框架學習曲線超過剩餘專案預算的系統。這些都屬於 raw SDK 的領地——本系列的代理架構指南展示了在需要任何框架之前，一條裸迴圈能走多遠。
啟示：一條與框架無關的遷移路徑
重點：可逆的路徑是「raw SDK 先行、訊號其次、框架最後」——再加上一層讓一切保持可替換的統一模型層。
避免兩種錯誤的正式環境順序：
- **從 raw SDK 開始。**tool-calling 迴圈大概 50 行；multi-model 架構模式讓它從第一天起就與供應商無關。多數原型永遠不會長超過這個規模——而真的長超過的那些，現在有了一個可以遷移的可用基準，而不是一次重寫。
- **留意訊號。**狀態、分支、協作——三項中出現任兩項，框架稅就值得繳了。正是在這個時點，LangGraph 的生態系（checkpointing、tracing、部署工具）開始回報當初的學習曲線。
- **遷移工作流程，不要遷移模型。**框架包住的是編排；模型層留在你的統一 endpoint後面，搭配自訂路由與模型目錄——於是框架決策與供應商決策保持獨立，任何一邊都可以變動而不強迫另一邊跟著動。LangChain SDK 整合直接接進這一層。
- **留好退路。**你採用的每個框架抽象層，都必須是可以替換的：替換工作流程圖形沒問題，但你的資料契約、你的模型路由不能跟著綁死。那些把框架當成編排工具、而不是當成身分認同的團隊，才能在下一波遷移——不管是我們的還是任何人的——中存活下來。
快速上手讓中立的基準在幾分鐘內跑起來；接下來要怎麼走，由訊號決定。
採用前的十項檢查清單——在對任何框架做出承諾之前先跑一遍：
- 工作流程需要能撐過當機或重啟的狀態嗎？
- 控制流程中有超過五條條件路徑嗎？
- 這個代理會由一位以上的工程師維護嗎？
- 框架的抽象層能在不需要繞路技巧的情況下表達這個工作流程嗎？
- 團隊願意現在就付學習曲線的代價，而不是等到 deadline 前才付嗎？
- checkpoint 與 tracing 的需求有文件記錄嗎？
- 工作流程可以不依賴框架獨立測試嗎？
- 模型層在可替換的 endpoint 後面嗎（而不是綁在框架上的 Key）？
- 如果框架不再值回票價，有文件化的退場路徑嗎？
- 在這種複雜度下，raw SDK 版本仍然可以維護嗎？
五個以上「是」，就值得採用；不到五個，代表框架稅繳得太早。
LangChain 在抽象層光譜上的位置：
| 抽象層 | 主導什麼 | 與 LangChain 的重疊 |
|---|---|---|
| Raw SDK（OpenAI／Anthropic clients） | 那一次 API 呼叫 | 所有東西都包在它之上的基礎層 |
| LangChain / LangGraph | 編排：狀態、圖形、工具 | 本指南的主題 |
| Vercel AI SDK | UI 到模型的管線、串流掛鉤 | 極少——互補 |
| Pydantic AI | 型別化的 tool schema 與輸出模型 | 部分——兩者都做 tooling |
| LlamaIndex | 檢索與文件管線 | 部分——RAG 相關處高度重疊 |
讓它們不互相衝突的規則是：每個抽象層靠「主導一個層」來證明自己的位置——一旦有兩個抽象層聲稱主導同一層，其中一個就是多餘的。
反方論點：文件派與批評派各自錯在哪
重點：兩派陣營都在各說各話——文件派預設你已採用，批評派批評的是 2023 年的版本，而正式環境的真相在中間。
**官方文件派錯在哪。**文件回答的是「怎麼做」，從來不回答「該不該」。每一篇 LangChain 教學都是寫給已經做了決定的人看的——這正是它不斷被拿來解決它解決不了的問題的原因：複雜度稅的判決，與其說是對框架的批評，不如說是一道文件上的缺口。
**批評派錯在哪。**多數「抽象洩漏」的經典論述，是針對 1.0 之前的技術堆疊寫的。2026 年的框架是另一種生物：重寫整合了核心、LangGraph 把編排從「什麼都塞」的大雜燴裡分出來，而「LangChain 太臃腫」現在是一句沒有 2026 年數據支撐、卻被不斷回收的 2023 年老梗。要批評就批評目前的版本，不然就別批評。
**綜合結論。**框架是一個帶有成本函數的工具——訊號顯示系統需要它時就繳稅，不需要時就跳過，並讓決策保持可逆。這不是妥協；這是文件派與批評派都無法反駁的唯一立場。
常見問題
2026 年 LangChain 死了嗎？
沒有——1.0 的重寫重置了核心，而 LangGraph 是生態系中最活躍的正式環境代理 runtime 之一。真正死掉的是「預設就採用」的時代：框架自己的動能，現在來自這份指南裡的訊號，而不是來自教學文章。
LangChain 1.0 值得遷移過去嗎？
只有當訊號出現時才值得——也就是有狀態、分支或協作的需求。為了「跟上時代」而遷移一套能跑的 raw-SDK 系統，只會付出遷移成本與複雜度稅，卻拿不到好處。用訊號來評估，別用 release notes。
raw SDK 什麼時候開始不夠用？
當狀態需要存活、當分支不再容易閱讀、或當團隊成長到超過一位工程師。三個訊號中出現任兩個，框架稅就值得繳；在那之前，裸迴圈建起來更快、除錯更快、也更好懂。
使用 LangChain 會把我鎖住嗎？
在編排層，會——這就是採用的意義。在模型層，不會：把模型放在帶有自訂路由的統一 endpoint 後面，供應商變更就停留在設定的層級。你避得開的那種鎖定，才是真正重要的那種，而這份指南一直為你留著這扇門。
總結
LangChain 是有條件的決策，不是忠誠度考驗：先從 raw SDK 開始，留意三個訊號——狀態、分支、協作——當其中兩個出現時，再採用框架（具體來說是 LangGraph）。把模型層放在統一 endpoint 後面，讓框架決策停留在編排層，退路保持開放。文件告訴你怎麼做；批評者告訴你別做；這份指南告訴你何時該做——而這才是唯一重要的問題。
在對框架做出承諾之前，先測試這三個訊號。取得你的 TokSpan API Key——$5 免費額度，正好當作基準——然後打造那條替你做出決定的 raw-SDK 迴圈。