LangChainコミュニティがツールミドルウェアの型不具合を報告、カスタムcontextがPylanceで非互換と判定される可能性

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を定義する。次に、handlerを直接呼び出す関数を@wrap_tool_call(state_schema=State)でラップする。これをcontext_schema=AgentContextを指定したcreate_agentに渡すと、型チェッカーは一致するオーバーロードがないと報告する。エラーメッセージによれば、ContextTは不変の型パラメーターであり、NoneをAgentContextの代わりにはできない。報告者によると、AgentMiddleware[State, AgentContext]を明示的に宣言するクラス形式に変更すると型チェックを通過するが、適用範囲全体については上流での確認が必要だ。再現例と代替記法

公式APIの契約は、この仕組みに関する分析を裏付けている。create_agentのcontext_schemaとミドルウェアはContextTを共有しており、両者の型は一致している必要がある。一方、デコレーターが公開する引数にはstate_schemaが含まれるが、対応するcontext_schemaはない。ツールのインターセプト機能は、ツール応答の再試行、監視、変更に利用できる。そのため、型の受け渡しに関する問題は、これらのロジックを再利用可能なミドルウェアとしてまとめる開発フローに影響する可能性がある。Agent API、デコレーターAPI

厳格な型チェックを採用しているチームでは、この種の互換性エラーがエディターでのチェックや継続的インテグレーションを妨げる可能性がある。これは報告内容から推測されるエンジニアリング上の影響だ。現時点の報告には、ツールの実行そのものが失敗した例も、実行時にユーザー識別データが失われたことを示す証拠もない。エンジニアはまず、自身のバージョンでクラス形式の記法を検証し、型診断と実行結果をそれぞれ確認できる。今後は、上流でデコレーターのジェネリック型の受け渡しが補われるか、また同期・非同期のツールインターセプト経路の両方が検証されるかに注目したい。