LangChain 於二零二六年十月二十二日發布 langchain-core 1.7.0，把工具呼叫參數由重複快照改為增量切片。官方量測顯示，六萬四千字元的工具呼叫在十六字元分塊下，事件資料量由約 128.8 MB 降至 0.5 MB，並同時修復非同步串流時工具收到空參數的缺陷。
LangChain core 1.7.0 是什麼？
langchain-core 是 LangChain 的基礎套件，定義訊息格式、工具呼叫介面與串流事件協定。1.7.0 於十月二十二日發布，改動工具呼叫參數串流方式。
LangChain 儲存庫由 LangChain 團隊於二零二二年十月建立，主要語言為 Python，採 MIT 授權，目前定位為代理工程平台。專案採多套件單一儲存庫結構，langchain-core 是最底層的套件，負責訊息物件、語言模型介面、工具抽象與事件串流協定；上層的 langchain 套件與各家模型供應商的整合套件都依賴它。
版本編號因此分成兩條線。langchain 本身的最新版本為 1.4.7，而 langchain-core 在同期推進至 1.7.0。這種分線發布讓底層協定可以獨立演進，代價是升級時必須同時確認兩者的相容範圍。此次 1.7.0 的改動落在事件協定層，屬於需要協調升級的變更。
儲存庫的主題標籤涵蓋 agents、langgraph、rag、multiagent 與 open-source，說明其生態已從單純的鏈式呼叫擴展到多代理編排。langchain-core 的事件串流正是 LangGraph 與 LangGraph Server 的資料通道，任何格式調整都會沿著這條通道傳導到上層應用。
工具呼叫串流的資料量問題有多嚴重？
舊版每個事件都附帶目前為止的完整參數，資料量隨參數長度呈平方成長。六萬四千字元在十六字元分塊下達 128.8 MB，同內容以純文字串流僅 0.42 MB。
問題由社群於二零二六年十月二日提交，編號 40998。報告指出 v3 串流協定對不同內容型別的處理並不對稱：文字、推理與資料區塊會轉成只攜帶新增片段的 delta 事件，工具呼叫區塊卻轉成附帶累積快照的事件，每個事件都重送一次從頭到當下的參數。
數學結果相當直接。若工具呼叫的參數有 n 個字元，以每塊 c 個字元串流，事件數量約為 n 除以 c，而第 k 個事件攜帶 k 塊內容，累計字元數約為 n 平方除以兩倍 c。報告給出的量測涵蓋四個規模：一千字元時工具呼叫事件為 0.04 MB、純文字為 0.01 MB；四千字元為 0.55 MB 對 0.03 MB；一萬六千字元為 8.21 MB 對 0.11 MB；六萬四千字元為 128.82 MB 對 0.42 MB。
影響不限於網路頻寬。LangGraph Server 在讀取下一個事件之前，必須先把目前事件序列化並發布到串流儲存與 SSE 連線，圖的下一步要等當前步驟的事件全部被消費才會開始。工具呼叫越大，模型呼叫結束之後下一個節點的空等越久，串流儲存與用戶端解析的負擔也同步放大。對以寫檔、產生程式碼為主要動作的代理而言，這條路徑正好是最常走的一條。
1.7.0 如何改動串流事件格式？
協定新增 tool-call-delta 事件，只攜帶新增的參數片段。呼叫的 id 與 name 移到起始事件，extras 與遲到的識別資訊移到結束事件。
改動分三層完成。第一層在協定定義，代理協定儲存庫的拉取請求 102 於十月二十日合併，把 ToolCallDelta 加入內容區塊 delta 的聯合型別，每個 delta 只附加新的參數片段，同時保留舊有替換語意與工具中繼資料。對應的 langchain-protocol 0.0.20 同日上架 PyPI。
第二層在消費端。langchain 儲存庫的拉取請求 41246 於十月二十一日合併，改動 828 行、刪除 51 行，讓串流消費端同時接受新舊兩種形式。串流驗證器兩種都檢查，PII 中介層改用既有的回看緩衝處理工具呼叫參數。
第三層在生產端。拉取請求 41257 於十月二十二日合併，改動 426 行、刪除 78 行，涉及五個檔案，讓聊天模型的事件橋接器真正發出新事件。這次同時修掉一個潛伏缺陷：舊實作讓 PII 中介層就地改寫橋接器自己持有的參數副本，在非同步串流下工具實際收到空物件；改版後每個 delta 都是獨立物件，該路徑不再共用可變狀態。
這次改動會影響哪些現有程式碼？
直接讀取 block-delta 中間參數的程式碼需改讀 tool-call-delta；若選擇保留快照語意，可將 langchain-core 固定於 1.7 以下。
官方版本說明把影響範圍寫得具體。若程式碼直接讀取原始串流事件，並在串流中途從 block-delta 取得參數，必須改讀 tool-call-delta。高階介面則不受影響：工具呼叫的取值方法與最終輸出維持原狀，最終訊息內容與合併結果亦不變。若團隊選擇保留快照行為，做法是把 langchain-core 固定在 1.7 以下。
自 1.6.13 起，迭代聊天模型串流的工具呼叫所取得的是每次新增的參數片段，而非累積結果。這項語意調整對需要在串流過程中即時顯示參數生成進度的前端影響最大，過去可以直接覆蓋顯示最新快照，現在需要自行拼接。
值得注意的是此改動的作者標記。拉取請求 41257 與 41246 均在說明中註明以 Claude Code 實作，代理協定的拉取請求 102 則標記由 LangChain 自家的 Open SWE 代理產生，使用 gpt-6.1-sol 模型。框架層的協定修正由代理工具完成，本身就是這條工具呼叫路徑的一次實測。
LangChain 的數據表現如何？
星標 148,322、分支 24,894、註冊貢獻者 467 位，最近七日提交 332 次，授權為 MIT，主要語言為 Python，儲存庫註冊二十個主題標籤。
專案自二零二二年十月建立，四年累積十四萬八千餘顆星標，分支接近二萬五千。註冊貢獻者四百六十七位，最近七日提交三百三十二次，平均每日約四十七次，開發節奏在版本發布前後明顯加快。
發布節奏值得留意。langchain-core 在一週內推出多個版本：1.6.11 於十月十五日、1.6.12 於十月十六日、1.6.13 於十月二十一日、1.7.0 於十月二十二日。這種密度說明底層套件採用持續交付模式，修補與功能並行推進。對依賴此套件的企業而言，固定版本範圍並定期檢視變更記錄，比被動接受最新版更實際。
升級到 1.7.0 的建議順序是什麼？
先升級 JavaScript 用戶端，再升級 Python 用戶端的 langchain-core，最後在伺服器端同時升級兩個套件，並確認協定版本已達 0.0.20。
官方在版本說明中給出明確順序。第一步升級 JavaScript 軟體開發套件與其繫結，第二步升級所有 Python 用戶端的 langchain-core，第三步才在伺服器端同時升級 langchain 與 langchain-core。這個順序確保消費端先能解析新事件，生產端才開始送出。
前置條件也寫得清楚。拉取請求 41246 原本以草稿狀態停留，直到 langchain-protocol 0.0.20 進入 PyPI、鎖定檔更新完成才合併。自架 LangGraph Server 的團隊因此需要先確認環境中的協定套件版本，否則可能出現伺服器送出新事件、用戶端仍按舊格式解析的錯配。
對自行開發事件消費者的團隊，建議在升級前補一層容錯。做法是在事件處理常式中同時辨識兩種事件型別，遇到未知型別時記錄而非直接拋出例外，並在升級窗口內對照同一段工具呼叫在新舊版本的輸出總量，用實際數字確認降幅符合預期。
出處連結有哪些？
原始碼與版本說明位於 GitHub 的 langchain-ai/langchain 儲存庫，問題 40998 與拉取請求 41246、41257 提供量測數據與實作細節。
專案位址為 https://github.com/langchain-ai/langchain，langchain-core 1.7.0 的版本頁面附有完整變更清單與升級注意事項。問題 40998 內含可重現的測試程式，會依序輸出四個規模的文字與工具呼叫事件資料量，是理解此次改動最直接的依據。協定層的定義位於 langchain-ai/agent-protocol 儲存庫，拉取請求 102 說明 ToolCallDelta 的欄位與相容策略。
總結：LangChain core 1.7.0 適合哪些團隊？
以大型工具呼叫或自行架設 LangGraph Server 的團隊受益最明顯；只做簡單文字串流的應用可暫時留在 1.6.x，等生態套件全面跟進再升級。
此次改動修正的是一個與規模直接相關的效率缺陷。平方成長的資料量在小型工具呼叫下並不明顯，一旦代理開始透過工具寫入檔案或產生整份程式碼，成本立刻以十倍計放大。1.7.0 把這條路徑拉回線性，同時順手修掉非同步串流下工具收到空參數的缺陷，後者對生產環境的價值甚至高於頻寬節省。
升級判斷可以落在一個條件上：應用是否直接讀取原始串流事件。完全依賴高階介面的專案，升級風險極低，只需確認相依套件版本一致；自行實作事件橋接、追蹤或中介層的專案，則必須安排一次對照測試，確認新事件型別在整條鏈路上被正確解析。無論屬於哪一類，此次改動都提供了一個具體例子，說明串流協定的設計細節如何直接決定代理系統在高負載下的實際表現。
