GitHub Repo
LangChain 社群回報工具中介層型別缺陷,自訂 context 可能遭 Pylance 判為不相容
10 月 5 日的 LangChain 1.4.3 社群案例指出,使用工具中介層裝飾器時,自訂 context 型別可能未被正確推導。案例目前顯示靜態型別檢查失敗,尚無證據證明執行期間的 context 資料遺失。

LangChain 社群於 10 月 5 日新增問題回報,指出 @wrap_tool_call 與自訂 context_schema 組合時,Pylance 可能將中介層的 context 型別推導為 None,進而判定它與代理所要求的型別不相容。回報環境包含 LangChain 1.4.3、langchain-core 1.6.6 與 Windows,並附有最小範例;查核時問題仍開啟,頁面未列出關聯修補。社群回報
範例先定義帶有重試欄位的代理 state,以及含 user_id 的 AgentContext,再以 @wrap_tool_call(state_schema=State) 包裝一個直接呼叫 handler 的函式。將它交給指定 context_schema=AgentContext 的 create_agent 後,檢查器回報沒有符合的多載。錯誤訊息指出,ContextT 是不變型別參數,因此 None 無法替代 AgentContext。作者表示,改用明確宣告 AgentMiddleware[State, AgentContext] 的類別寫法可通過檢查,但仍需上游確認完整適用範圍。重現與替代寫法
官方 API 契約支持這項機制分析:create_agent 的 context_schema 與 middleware 共用 ContextT,兩者必須保持一致;裝飾器公開參數則包含 state_schema,沒有對應的 context_schema。工具攔截介面可用來重試、監控或修改工具回應,因此型別傳遞問題會影響將這些邏輯封裝成可重用中介層的開發流程。代理 API、裝飾器 API
對採用嚴格型別檢查的團隊而言,這類不相容診斷可能阻礙編輯器檢查或持續整合;這是依據案例推導的工程影響。目前回報未展示實際工具執行失敗,也未證明使用者識別資料在執行時消失。工程師可先在自身版本驗證類別式寫法,並分別檢查型別診斷與執行結果。後續應觀察上游是否補齊裝飾器的泛型傳遞,以及同步、非同步工具攔截路徑是否都有驗證。