How and when to build multi-agent systems は、前の週の後半に公開された、一見正反対のタイトルを持つ 2 本の記事、すなわち Cognition の マルチエージェントを構築するな と Anthropic の 私たちはマルチエージェントのリサーチシステムをどう構築したか に応答して書かれた LangChain のブログ記事である。著者は、この 2 本には多くの共通点があると論じ、そこからマルチエージェントシステムをどのように、いつ構築すべきかについての 2 つの洞察を引き出す。コンテキストエンジニアリングが極めて重要であること、そして主に「読む」システムのほうが「書く」システムより構築しやすいことである。
記事は続いて、マルチエージェントシステムを構築する場合にも複雑な単一エージェントを構築する場合にも生じるという信頼性とエンジニアリング上の課題、すなわち永続的な実行、デバッグとオブザーバビリティ、そして評価を取り上げ、それぞれを LangChain 自身のツールに結び付ける。そして、万能の答えは存在せず、単一エージェントと複数エージェントの間のスペクトラム上で適切な位置は、解こうとしている問題によって決まると結論づけている。
要点
- 記事は、モデルに対して何を求めているのかというコンテキストを伝えるという課題について、コンテキストエンジニアリング という用語を導入したのは Cognition の記事だとし、Anthropic の記事はその用語を使わずに同じ問題を何か所かで扱っていると読んでいる。
- Cognition の記事からは、マルチエージェントシステムでは各サブエージェントが適切なコンテキストを持つことを保証するのがより難しくなる、という点を引き出している。
- 記事の議論では、読み取りのアクションは書き込みのアクションより本質的に並列化しやすい。並列に書き込むには、エージェント間でコンテキストを伝えることと、それらの出力をマージすることの両方が必要であり、競合する書き込みは競合する読み取りよりはるかに悪い結果を生む。
- その例として Anthropic のリサーチシステムを挙げる。複数のエージェントがリサーチを担当する一方で、最終レポートは単一のメインエージェントが 1 回の呼び出しで書く。さらに、読み取り中心のシステムであっても、依然として注意深いコンテキストエンジニアリングが必要だと付け加えている。
- 永続的な実行、エージェントのデバッグとオブザーバビリティ、エージェントの評価を、Anthropic のユースケースに固有のものではなく長時間稼働エージェント一般の問題として提示し、永続的な実行はエージェントのオーケストレーションフレームワークに組み込まれるべきだと論じている。
- Anthropic の記事から評価に関する 3 つの教訓を取り出している。小さく始めること、それも 20 程度のデータポイントで十分であること、LLM-as-a-Judge によって採点を自動化できること、そして人間によるテストが依然として不可欠であることである。
- 記事自身の推奨は、エージェントフレームワークは開発者が単一エージェントと複数エージェントの間を「どこへでもスライド」できるようにすべきだというもので、LangGraph はそれを独自に重視しているとしている。これは、そのフレームワークを開発する企業に属する著者が、自社製品について行っている主張である。
背景
この記事は、自らの実験の報告ではなく他の 2 社の文章への論評であり、その根拠の大部分は Anthropic と Cognition の記事からの引用である。記事は LangGraph と LangSmith の開発元の視点から書かれており、取り上げるエンジニアリング上の課題はいずれも、それらの製品がどう対処するかで締めくくられる。記事は LangGraph を、隠れたプロンプトも強制される「認知アーキテクチャ」もなく、LLM に何を渡すかを完全に制御できる低レベルのオーケストレーションフレームワークとして説明し、LangSmith をエージェントのデバッグ、オブザーバビリティ、評価のためのプラットフォームとして説明している。