LangChain チームによるこの記事は、LangChain 1.0 の新しいエージェント抽象化である エージェントミドルウェア を発表し、それがなぜ必要だったのかを論じている。記事の診断はこうである。中核となるエージェント抽象化、つまりモデル、プロンプト、ツールのリストを、モデルが停止を決めるまでツールを呼び出し続けるループで実行するというものは、動かすのは簡単だが、本番環境に耐える柔軟性を持たせるのは難しい。そして、その上に構築された数百もの エージェントフレームワーク は、初期の LangChain のエージェントが抱えていたのと同じ弱点、すなわち コンテキストエンジニアリング に対する制御の不足を共有しており、そのためユースケースが自明でなくなると、開発者は抽象化を離れて独自のコードへ移ってしまう。
記事は続いて、エージェントにパラメーターを追加することでこの問題を解決しようとした 2 年間の試みを振り返り、そのアプローチがなぜスケールしなくなったのかを説明したうえで、その代わりとしてミドルウェアを提示している。ミドルウェアは Python と JavaScript 向けの LangChain 1.0 アルファ版で利用できる。
要点
- フレームワーク上に構築したエージェントの信頼性を高めるのがなぜ難しいのかという問いに対する記事の答えは、コンテキストエンジニアリングである。モデルに何が入るかが何が出てくるかを決めるので、信頼性を得るにはモデルへの入力を完全に制御する必要がある。
- 記事によれば、複雑さが増すにつれて開発者が変えたくなるものは 3 つある。メッセージだけにとどまらないエージェントの状態、モデルに入るものの正確な中身、そして実行されるステップの順序である。
- LangChain のこれまでの対応は、エージェントのパラメーターを次々に追加することだった。ランタイム設定、カスタム状態スキーマ、プロンプトを返す関数、メッセージリスト全体を返す関数、モデル呼び出し前のフック（長い会話の要約などを可能にする）、モデル呼び出し後のフック（ヒューマン・イン・ザ・ループやガードレールを可能にする）、そして呼び出しごとにモデルを選ぶ関数である。
- このアプローチは、互いに依存し合う多数のパラメーターを生み、それらは調整するのも、組み合わせるのも、既製のバリエーションとして提供するのも難しかったと説明されている。
- ミドルウェアは、モデルノードとツールノードから成る中核のループを維持しつつ、ミドルウェアが
before_model、after_model、modify_model_requestの各フックに加えて、カスタム状態スキーマやツールを指定できるようにする。 - 複数のミドルウェアは Web サーバーのミドルウェアと同じように動作する。モデル呼び出しに向かう際には順番に、戻る際には逆順に実行される。
- LangChain は、既製のミドルウェアを提供し、コミュニティ製ミドルウェアの一覧を管理すると述べており、これを開発者が LangGraph のエージェントに差し込めるよう求めていたノードのコレクションだと説明している。
- チームは、ミドルウェアで同社の個別の LangGraph エージェントアーキテクチャ、すなわち supervisor、swarm、bigtool、deepagents、reflection を再現できることを検証したと報告しており、ミドルウェアがそれらを統一すると見込んでいる。
- アルファ版には、LangChain の社内エージェントですでに使われている 3 つの実装が同梱された。ヒューマン・イン・ザ・ループ（
after_modelによる）、要約（before_modelによる）、Anthropic のプロンプトキャッシュ（modify_model_requestによる）である。
背景
この記事は、ベンダーが自社フレームワークの機能を 1.0 アルファの期間中に発表したものである。ミドルウェアによって LangChain のエージェント抽象化が利用可能なものの中で最も柔軟で組み合わせやすいものになるという主張はベンダー自身の評価であり、評価結果は何も報告されていない。記事はミドルウェアを LangChain 1.0 における最大の新要素と呼び、フィードバックを求めている。