LangChain 的 jQuery 時刻：當模型供應商吃掉中間層
一、引子：一個似曾相識的場景
想像一個場景：你的團隊花了三個月，用 LangChain 搭建了一套 RAG 系統。裡面有 ConversationBufferMemory 管記憶、有 DocumentLoader 處理文件、有 OutputParser 解析結構化回應、有自訂的快取層管理 token 成本。系統運作良好，程式碼大約兩千行。
然後某天早上，你打開 Anthropic 的更新日誌，發現他們新增了一個 API 參數。
你盯著那個參數看了五分鐘，然後回頭看自己的程式碼。你意識到，那兩千行裡面有一千五百行，做的事情跟這個參數一模一樣。
這不是假設。這正在發生。
2024 年底，Anthropic 推出了 server-side tools——內建的程式碼執行、網頁搜尋、檔案處理。2025 年初，Memory tool 上線，跨對話的持久化記憶變成一個 API 參數。年中，MCP Connector 讓你從 Messages API 直接連接遠端工具伺服器，不再需要自己搭建客戶端編排層。到了 2025 下半年，Compaction 和 Context Editing 把上下文管理也收進了平台。
每一次更新，中介層框架的「存在理由」就少一塊。
如果你經歷過 2015 年前後的前端開發，這個劇本你一定不陌生。當年有個叫 jQuery 的函式庫，佔據了網路上 70% 的網站。然後瀏覽器把它的核心功能一個一個實作了。
LangChain 正在經歷它的 jQuery 時刻。
二、jQuery 的前車之鑑
要理解 LangChain 現在的處境，我們得先回顧 jQuery 的故事。不是因為歷史有趣（雖然確實有趣），而是因為這個模式正在精確地重演。
jQuery 做對了什麼
2006 年 jQuery 發布時，瀏覽器是一片荒野。Internet Explorer 6、7、8 各有各的 DOM API。要寫一段跨瀏覽器的事件處理，你得寫三套分支邏輯。AJAX 請求？每個瀏覽器的 XMLHttpRequest 實作都不一樣。動畫？別想了，CSS 連 transition 都沒有。
jQuery 的價值是真實的：它把一個碎片化、不一致、令人痛苦的平台，包裝成一套優雅、一致的 API。$('.class') 比 document.getElementsByClassName('class') 好寫。$.ajax() 比手動建立 XMLHttpRequest 物件好用。$.animate() 在 CSS 動畫不存在的年代是唯一選擇。
瀏覽器學會了
問題是，瀏覽器廠商也在看。他們看到了開發者用 jQuery 做什麼，然後把這些功能直接做進了平台：
| jQuery 功能 | 瀏覽器原生替代 | LangChain 功能 | Anthropic 原生替代 |
|---|---|---|---|
$.ajax() | fetch() | Tool 編排 | Server-side tools + MCP Connector |
$.animate() | CSS transitions / Web Animations API | 記憶管理 | Memory tool（跨對話持久化） |
$(selector) | querySelectorAll() | Prompt 模板 | System prompt + Structured outputs |
$.Deferred | Promise | Callback chains | Streaming + Fine-grained tool streaming |
$.each() | Array.forEach() / for...of | Document loaders | Files API + Web Fetch |
這張表的模式很清楚：左邊兩欄是已經發生的歷史，右邊兩欄是正在發生的現實。
90% 時刻
jQuery 並不是因為它「不好」而被淘汰的。它被淘汰是因為它太好了——它向瀏覽器展示了開發者需要什麼，然後瀏覽器把這些需求直接實作了。
我把這個轉折點稱為「90% 時刻」：當平台原生支援了你使用某個函式庫 90% 的理由時，剩下的 10% 不足以證明這個依賴的合理性。
jQuery 的 90% 時刻大約發生在 2018 年前後。fetch() 取代了 $.ajax()，querySelectorAll 取代了 $()，CSS transitions 取代了 $.animate()，Promise 取代了 $.Deferred。到了這個時點，新專案已經沒有理由引入 jQuery。
LangChain 正在逼近它的 90% 時刻。而且速度比 jQuery 快得多——因為 AI 產業的疊代速度遠超瀏覽器標準委員會。
三、證據盤點：Anthropic API 的能力膨脹
讓我們系統性地看看 Anthropic 在過去一年半裡，究竟吃掉了中介層的哪些領地。我把這些能力分成四類。
3.1 伺服器端工具（Server-side Tools）
這是最直觀的一類。以前你需要自己搭建沙箱環境跑程式碼、自己包裝網頁爬蟲、自己管理檔案上傳——現在這些都是一個 tool 參數。
- Code Execution：平台提供的沙箱環境，不需要自己維護執行容器
- Web Search：即時網路搜尋，結果直接注入對話
- Web Fetch：完整的網頁內容擷取，包括 PDF
- Memory：跨對話的持久化記憶，這一項就直接取代了 LangChain 的整個 Memory 模組
來看一個具體的 before/after：
Before（LangChain 記憶管理）：
from langchain.memory import ConversationBufferMemory
from langchain.chains import ConversationChain
memory = ConversationBufferMemory()
chain = ConversationChain(llm=llm, memory=memory)
# 需要額外處理：持久化、跨 session、清理策略...After（Anthropic 原生）：
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
tools=[{"type": "memory", "memory_id": "my-session"}],
messages=[{"role": "user", "content": "Remember this for next time..."}]
)一個 tool 參數取代了一整個模組。
3.2 工具基礎設施（Tool Infrastructure）——真正的殺手
如果說 server-side tools 是搶了中介層的具體功能，那工具基礎設施就是在搶中介層的存在意義。
- MCP Connector：從 Messages API 直接連接遠端 MCP 伺服器。這消除了「需要一個客戶端編排層來管理工具連線」這個需求——而這正是 LangChain 的核心價值主張之一
- Tool Search：動態發現和載入工具，支援透過正規表達式搜尋上千個工具。你不再需要預先定義所有可用工具
- Agent Skills：預建和自訂技能包，漸進式揭露複雜功能
- Programmatic Tool Calling：在程式碼執行容器內呼叫工具
- Fine-grained Tool Streaming：串流工具參數，不需要等待完整 JSON 驗證
3.3 上下文管理（Context Management）——靜悄悄的革命
上下文管理是 LLM 應用的核心挑戰之一，也是中介層框架投入大量精力的領域。Anthropic 正在把這整塊搬進平台：
- Compaction：伺服器端自動摘要長對話，不需要你自己寫截斷邏輯
- Context Editing：可配置的自動上下文管理策略
- Automatic Prompt Caching：單一 API 參數，5 分鐘和 1 小時兩個層級
- Token Counting：發送前的 token 估算
3.4 檔案與結構化輸出
- Files API：上傳一次，多次引用
- Structured Outputs：JSON Schema 強制驗證
- Citations：回應錨定到來源文件
- Batch Processing：非同步批次處理，成本降低 50%
全景對照
把這些整理成一張中介層職責對照表：
| 中介層職責 | 以前（LangChain 等） | 現在（Anthropic 原生） |
|---|---|---|
| 工具編排 | Chain/Graph 定義、Tool adapters | MCP Connector、Agent Skills、Tool Search |
| 記憶管理 | VectorStore + Retrieval chains | Memory tool（伺服器端、跨對話） |
| 上下文管理 | 手動截斷、摘要 chains | Compaction、Context Editing、Prompt Caching |
| 文件處理 | Document loaders、Text splitters | Files API、Web Fetch、PDF 支援 |
| 輸出解析 | Output parsers、Structured output chains | Structured Outputs（JSON Schema） |
| 網路搜尋 | 自訂 tool wrappers | Web Search（伺服器端） |
| 程式碼執行 | 自建沙箱 | Code Execution（伺服器端） |
| 串流處理 | 自訂 stream handlers | Fine-grained tool streaming |
| 快取 | 自建快取層 | Automatic Prompt Caching |
九項職責，九項都有了原生替代方案。
這不是巧合。模型供應商正在系統性地把「智慧」從框架層搬到 API 層。以前你需要一個框架來做上下文管理、工具路由、記憶——現在這些都變成了一個 API 參數。
四、三層模型：誰在被吃？
為了更清楚地理解這場賽局，讓我們把 AI 應用的技術棧分成三層：
┌─────────────────────────────────────────────┐
│ Layer 3: Application Layer │
│ 垂直 AI Agents（法律、醫療、金融、編程） │
│ 面向使用者的產品 │
├─────────────────────────────────────────────┤
│ Layer 2: Orchestration Layer │
│ LangChain, LlamaIndex, CrewAI, AutoGen │
│ 工具編排、記憶管理、Chain 組合 │
├─────────────────────────────────────────────┤
│ Layer 1: Infrastructure Layer │
│ Anthropic, OpenAI, Google │
│ 模型 + 原生 API 能力 │
└─────────────────────────────────────────────┘
Layer 1：基礎設施層——向上侵蝕
模型供應商正在積極地向上擴張。每一個新的 API 功能，就是 Layer 2 的一塊領土被吸收。經濟動機很明確：捕獲更多價值鏈、降低使用者流向競爭對手的可能性。
這個邏輯跟 AWS 一模一樣。AWS 會把基礎設施做得盡可能好，然後等待垂直玩家在上面建構應用。模型供應商的策略完全相同：讓你的 AI 應用盡可能依賴我的原生能力，這樣你就不容易切換到其他模型。
Layer 2：編排層——上下夾擊
編排層正在從下方被擠壓。每一次平台更新，其價值主張就窄一圈。
但 Layer 2 還有一些可防禦的領地：
- 多模型編排：如果你的場景真正需要在 Claude、GPT、Gemini 之間動態切換（例如用 Claude 做推理、用 GPT 做分類、用本地模型做簡單任務），中介層還有價值。但現實是，模型的差異化越來越大（Claude 的 extended thinking、GPT 的 function calling 語法、Gemini 的 grounding），「統一抽象」反而會遮蔽每個模型的獨特能力
- 複雜工作流組合：超出單一 API 呼叫能力範圍的複雜條件分支、Map-Reduce 並行、多源等待——這是 LangGraph 的真正定位
- 可觀測性工具：Anthropic 目前還沒有提供完整的 tracing / observability 平台，LangSmith 在這裡仍有商業空間。但 Braintrust、Weave、Phoenix 等第三方工具也在搶這塊市場
Layer 3：應用層——取決於你的價值在哪
應用層的命運完全取決於一個問題：你的價值是在編排本身，還是在領域專業性？
如果你的 Agent 本質上是「幫你呼叫 API」的 wrapper，那你就在 Layer 2，而且你正在被壓縮。
如果你的 Agent 的核心價值在於深度的領域知識、獨佔的數據、嚴格的合規要求、複雜的工作流——那你在 Layer 3，而且你有護城河。
關鍵區分：在基礎設施層（工具呼叫、記憶管理、上下文優化）競爭，你會輸——那是模型供應商的地盤。在編排層（通用 Agent 框架）競爭，空間正在收縮。在應用層帶著至少兩個以上防禦因子競爭——仍然有巨大的機會。
五、LangChain 的困境與出路
了解了三層模型之後，讓我們具體看看 LangChain 生態系的現狀。
已被吸收：優勢已失
- Tool Use 抽象：以前需要 LangChain 統一不同模型的工具呼叫格式，現在每個 API 都原生支援，MCP 更在標準化格式
- RAG 管線：Anthropic 原生的 Citations + Search Results + Web Search 組合，讓簡單的 RAG 不再需要框架
- 快取 / 上下文管理：以前是框架層的責任，現在 Compaction 和 Automatic Caching 在 API 層解決
- 記憶：LangChain 的各種 Memory 類（ConversationBufferMemory 等）被 Anthropic 原生 Memory tool 直接取代
正在壓縮：價值遞減但仍有空間
- 多模型抽象層：曾經是 LangChain 最大的賣點。但模型差異化持續加大（Claude 的 extended thinking、GPT 的 function calling 語法、Gemini 的 grounding），「統一抽象」反而會隱藏各模型的獨特能力。越來越多團隊選擇直接使用原生 SDK
- 可觀測性（LangSmith）：Anthropic 尚未提供完整的 tracing / observability 平台，這是 LangSmith 仍有商業價值的地方。但第三方工具也在搶佔這塊市場
仍有價值：LangGraph 的真正護城河
LangGraph 是 LangChain 團隊最重要的戰略押注，而且這個押注有道理：
- 圖狀態機編排：複雜的條件分支、Map-Reduce 並行、多源等待——這些 Anthropic API 不直接提供
- 持久化執行（Durable Execution）：Checkpoint + Time-Travel Debugging，適合跨天/跨週的長工作流
- 模型無關：對於真正需要在多個 LLM 之間切換的場景，LangGraph 提供了統一的編排介面
但即使是 LangGraph，適用場景也在收窄。隨著模型能力持續提升，越來越多「看似需要圖編排」的任務，其實一個足夠聰明的模型加上原生工具就能處理。關於 LangGraph 的架構細節，可以參考我之前的深度解析文章。
總結評估
LangChain（chain / pipeline 抽象）→ 價值大幅下降，趨近 commodity
LangGraph（圖編排引擎） → 仍有獨特價值，但適用場景收窄
LangSmith（可觀測性平台） → 短期商業價值存在，但競爭加劇
LangChain 團隊顯然意識到了這個趨勢。從他們的產品策略可以看到明確的重心轉移：從通用 chain 抽象轉向 LangGraph 的圖編排 + LangSmith 的可觀測性。這是正確的方向，但時間窗口正在關閉。
六、垂直 AI Agent 的防禦性評估框架
理解了中介層被壓縮的大趨勢後，真正重要的問題是：如果你正在建構一個垂直 AI Agent，你怎麼評估自己會不會被平台吃掉？
我提出一個四因子評估框架：
防禦性分數 = 領域知識深度 (D) x 數據獨佔性 (E) x 合規門檻 (C) x 工作流複雜度 (W)
用乘法而非加法，是因為任何一個因子趨近於零，都會讓你容易被模型供應商吸收。四個因子都高，才是真正可防禦的垂直 Agent。
因子一：領域知識深度（Domain Knowledge Depth, D）
Agent 內嵌的領域專業知識有多深？
- Low (1)：通用任務，不需要專業知識。例如「幫我摘要這份文件」——任何通用模型都做得到
- Medium (2-3)：產業相關但資訊公開可得。例如基於公開法規的合規檢查
- High (4-5)：深度專業知識、專有方法論。例如理解特定司法管轄區判例法的法律合約分析
關鍵問題：一個通用模型加上好的 prompt，能不能複製你的效果？
因子二：數據獨佔性（Data Exclusivity, E）
Agent 是否能存取通用模型無法取得的專有數據？
- Low (1)：只使用公開數據
- Medium (2-3)：有一些專有數據，但可替代
- High (4-5)：獨特的數據集，且具備數據飛輪效應（越用越有價值）
關鍵問題：你的數據護城河是在擴大還是縮小？
因子三：合規門檻（Compliance Barriers, C）
是否有監管、法律或認證要求？
- Low (1)：無監管要求
- Medium (2-3)：產業標準、基本合規
- High (4-5)：嚴格的監管框架、專業認證。例如 HIPAA（醫療）、SOX / SEC（金融）、FedRAMP（政府）
關鍵問題：模型供應商是否需要取得這些認證才能直接競爭？
因子四：工作流複雜度（Workflow Complexity, W）
涉及多少步驟、系統和人類接觸點？
- Low (1)：等同於單次 API 呼叫。例如簡單的 Q&A Bot
- Medium (2-3)：多步驟、2-3 個系統整合
- High (4-5)：深度系統整合、Human-in-the-loop。例如跨多個遺留系統的保險理賠處理流程
關鍵問題：這能被簡化為一次 API 呼叫嗎？
評分矩陣
| 因子 | Low (1) | Medium (2-3) | High (4-5) |
|---|---|---|---|
| 領域知識 (D) | 通用任務、無專業知識 | 產業相關、公開可得 | 深度專業、專有方法論 |
| 數據獨佔 (E) | 僅公開數據 | 部分專有、可替代 | 獨特數據集、數據飛輪 |
| 合規門檻 (C) | 無監管要求 | 產業標準、基本合規 | 嚴格監管、專業認證 |
| 工作流複雜度 (W) | 單次 API 呼叫 | 多步驟、少量整合 | 深度整合、人機協作 |
解讀指南
- 分數 4-8：高風險。你的核心價值在模型供應商可以輕鬆複製的層面上。考慮轉型或加深護城河
- 分數 9-15：中等風險。專注於強化你最強的那個因子。一個因子到 5 分可以彌補其他因子的不足
- 分數 16-25：強防禦性。模型供應商需要變成該領域的專家才能競爭。這是你想要的位置
超越分數：三道額外的護城河
除了四因子本身，還有三個不在公式裡但同樣重要的防禦維度：
評估能力（Evaluation）：模型供應商能告訴你「我輸出了這段文字」，但不能告訴你「這個醫療建議是否安全」。領域特定的品質評估本身就是價值。
領域護欄（Domain Guardrails）：不是通用的安全過濾器，而是產業特定的約束。例如金融 Agent 不能給出具體投資建議、醫療 Agent 必須附帶免責聲明。
責任承擔（Liability）：模型供應商的服務條款明確免除對輸出的責任。願意在特定領域承擔一定程度責任的垂直 Agent 公司（例如「我們保證合約審查覆蓋率達到 X%」）——這本身就是商業價值。
七、案例分析：誰會被吃，誰還有機會
讓我們用這個框架來評估五個垂直領域。
7.1 編程 Agent（Coding Agents）
| 因子 | 分數 | 理由 |
|---|---|---|
| 領域知識 (D) | 2 | 通用程式設計知識，模型本身已經很擅長 |
| 數據獨佔 (E) | 2 | 程式碼庫存取是暫時的，不構成持久護城河 |
| 合規門檻 (C) | 1 | 幾乎無監管要求 |
| 工作流複雜度 (W) | 3 | 多檔案編輯、測試、部署有一定複雜度 |
總分：12。中等偏低風險。
現實印證了這個評估：模型供應商已經在直接競爭。Claude Code、GitHub Copilot、Cursor——基礎設施層的玩家正在直接提供編程 Agent。
剩餘機會：深度整合特定企業的開發工作流（遺留系統遷移、特定框架的最佳實踐）、企業內部程式碼庫的持續學習。但窗口正在關閉。
7.2 法律文件分析
| 因子 | 分數 | 理由 |
|---|---|---|
| 領域知識 (D) | 5 | 司法管轄區特定法律、判例法解讀 |
| 數據獨佔 (E) | 4 | 判例法資料庫、事務所先例、合約範本庫 |
| 合規門檻 (C) | 4 | 律師公會規範、資料處理要求 |
| 工作流複雜度 (W) | 4 | 多步驟審查、人類核准、版本追蹤 |
總分：320（5x4x4x4）。強防禦性。
模型供應商不太可能直接追求這個市場。他們不會去取得律師公會認證、不會建構判例法資料庫、不會承擔法律建議的責任。
7.3 客服 Agent
| 因子 | 分數 | 理由 |
|---|---|---|
| 領域知識 (D) | 2 | 產品知識，但不深 |
| 數據獨佔 (E) | 3 | 公司知識庫有一定價值 |
| 合規門檻 (C) | 1 | 基本無監管要求 |
| 工作流複雜度 (W) | 2 | 相對簡單的對話流程 |
總分：12。中等偏低風險。
模型供應商的 Memory + Tools 能力已經可以覆蓋大部分客服場景。通用的客服 Agent 正在被吸收。
剩餘機會：深度整合企業 CRM、工單系統、內部知識庫的客服 Agent 仍有空間，但核心競爭力在於系統整合能力而非 AI 能力本身。
7.4 醫療診斷輔助
| 因子 | 分數 | 理由 |
|---|---|---|
| 領域知識 (D) | 5 | 臨床指引、藥物交互作用、診斷路徑 |
| 數據獨佔 (E) | 4 | 病歷資料、臨床數據庫（HIPAA 保護） |
| 合規門檻 (C) | 5 | FDA、HIPAA、醫療器材認證 |
| 工作流複雜度 (W) | 4 | 多步驟診斷、多科會診、人類醫師確認 |
總分：400（5x4x5x4）。極強防禦性。
合規門檻是這裡最大的護城河。模型供應商要進入這個領域，需要通過 FDA 認證、符合 HIPAA 規範、取得醫療器材許可。這不是技術問題，是監管問題。
7.5 金融交易 Agent
| 因子 | 分數 | 理由 |
|---|---|---|
| 領域知識 (D) | 4 | 交易策略、風險模型、市場微結構 |
| 數據獨佔 (E) | 5 | 專有市場數據、另類數據、Alpha 信號 |
| 合規門檻 (C) | 4 | SEC、FINRA 監管 |
| 工作流複雜度 (W) | 3 | 交易執行、風控、回測有一定複雜度 |
總分：240（4x5x4x3）。強防禦性。
數據獨佔性是這裡的主要護城河。專有市場數據、另類數據源、多年累積的 Alpha 信號——這些不是模型供應商能輕易取得的。
彙總比較
| 垂直領域 | D | E | C | W | 總分 | 防禦性 |
|---|---|---|---|---|---|---|
| 編程 Agent | 2 | 2 | 1 | 3 | 12 | 低 |
| 法律文件分析 | 5 | 4 | 4 | 4 | 320 | 強 |
| 客服 Agent | 2 | 3 | 1 | 2 | 12 | 低 |
| 醫療診斷輔助 | 5 | 4 | 5 | 4 | 400 | 極強 |
| 金融交易 Agent | 4 | 5 | 4 | 3 | 240 | 強 |
模式很清楚：所有價值都在模型供應商可以輕鬆複製的層面上的 Agent（編程、客服），防禦性低。價值建構在領域深度、數據獨佔、合規壁壘上的 Agent（法律、醫療、金融），防禦性強。
另外值得一提的是半導體 EDA 驗證 Agent——四個因子全部偏高，是最難被取代的類型。
八、結論：在平台化浪潮中找到你的位置
讓我們回到開頭的場景。那個發現自己兩千行程式碼可以被一個 API 參數取代的開發者，他並不是做錯了什麼。他在 LangChain 是最佳選擇的時候選擇了 LangChain，就像 2010 年的前端工程師選擇 jQuery 一樣。
問題不在於過去的選擇，而在於未來的策略。
核心命題
不要對抗平台吸收，要在平台到不了的地方建構。
模型供應商會持續把中介層的能力吸收進平台。這是必然的經濟趨勢，不是可以對抗的力量。jQuery 沒有打敗過 querySelectorAll，LangChain 的 ConversationBufferMemory 也不會打敗 Anthropic 的原生 Memory tool。
四個方向
如果你正在建構 AI 應用，問自己這四個問題：
- 領域知識深度：我的 Agent 是否內嵌了通用模型無法輕易複製的專業知識？
- 數據獨佔性：我是否擁有或能存取模型供應商無法取得的數據？而且這個護城河是在擴大嗎？
- 合規門檻：我的領域是否有模型供應商不願意（或不能）通過的監管門檻？
- 工作流複雜度：我的使用場景是否真正需要跨多個系統、涉及人類判斷的複雜工作流？
如果四個答案都是「否」，你的 Agent 大概率會在下一次平台更新時變得多餘。
如果至少兩個答案是「是」，你有護城河。去加深它。
寫在最後
LangChain 的 jQuery 時刻不是一個悲劇。就像 jQuery 教會了瀏覽器開發者需要什麼，LangChain 教會了模型供應商開發者需要什麼。中介層的消亡，恰恰是它的成功證明。
真正的機會不在中間層。它在平台能力的邊界之外——在那些需要深度領域知識、獨佔數據、嚴格合規、複雜工作流的地方。
那裡，才是護城河。