LLM ベースのマルチエージェント（LMA）システムとは、相互作用するエージェントが大規模言語モデルによって駆動されるマルチエージェントシステムである。一般にマルチエージェントシステムとは、相互作用する複数の知的エージェントから構成される計算フレームワークであり、それらのエージェントが協調して、単一のエージェントの能力を超える複雑な問題を解いたり目標を達成したりする。エージェントは通信し、調整し、知識を共有し、多くの場合、タスクの異なる部分にそれぞれの専門性を発揮する。ソフトウェアエンジニアリングのための LLM ベースのマルチエージェントシステム：文献レビュー、ビジョン、そして今後の道筋 は、LMA システムを二つの主要な構成要素、すなわちオーケストレーション基盤と、それが調整する LLM ベースのエージェントから成るものと定義している。この定式化では、各エージェントはグラフのノードとして表すことができ、そのエッジはエージェント間の相互作用である。
用法
オーケストレーション基盤は、相互作用と情報の流れを管理する中核的なインフラである。同論文はこれを三つの軸で特徴づけている。調整モデルは、エージェントがどのように相互作用するかを定めるもので、協調型、競争型、階層型、またはそれらの混合がある。通信メカニズムは、情報がどのように流れるかを定めるもので、チャネルは集中型（中央のエージェントが通信を仲介する）、分散型（エージェント同士が直接通信する）、階層型（情報が権限の層を通って流れる）のいずれかの形で組織される。ソフトウェアエンジニアリングの文脈では、やり取りされるデータにはコード片、コミットメッセージ、フォーラムの投稿、バグ報告、脆弱性報告などが含まれうる。計画と学習のスタイルは、タスクがどのように割り当てられ調整されるかを決めるもので、その戦略には Centralized Planning, Decentralized Execution（集中型計画・分散型実行）や Decentralized Planning, Decentralized Execution（分散型計画・分散型実行）がある。
エージェント自体は、あらかじめ定義されている場合も LLM によって動的に生成される場合もあり、また同質的（同一の機能を持つ）な場合も異質的（多様な機能と専門性を持つ）な場合もある。
同論文がこの形態をとる動機として挙げるのは、現実世界の問題は複数の領域にまたがるため、単一の LLM ベースのエージェントでは限界に突き当たるという点である。複数の専門化されたエージェントが連携して働くことで、自律的な問題解決が可能になり、意思決定における相互検証によって頑健性が高まり、エージェントを追加しタスクを再配分することで複雑なシステムへとスケールできる、と論じられている。同論文はまた、この仕組みを Mixture of Experts（専門家の混合）のパラダイムと対比している。後者では、専門化された構成要素がゲーティング機構によって動的に活性化されるが、構成要素同士が通信することはない。
コード生成のための LLM ベースのマルチエージェントシステム：マルチボーカル文献レビュー は、同じ主題にアーキテクチャの側ではなく証拠の側からアプローチしており、とくにコード生成に関する学術文献とグレー文献の研究 114 件をレビューしている。同レビューによれば、こうしたシステムを採用する理由として述べられたものは九つのカテゴリーに分かれ、その筆頭は性能の向上（114 件中 12 件、10.5%）と、より小さな協調的サブタスクへの分解による複雑なタスクへの対処（9 件、7.9%）である。著者らはこの分布を、マルチエージェントアーキテクチャが主として精度、効率、ワークフロー調整のための技術的な仕組みとして位置づけられていることの表れと読んでおり、適応性や自律的な実行が挙げられることはより少なく、中心的なものではなくまだ現れつつある段階だとしている。
同じレビューは、何がうまくいかないかも記録している。最大の課題カテゴリーは正確性と信頼性で、26 件（22.81%）の研究が報告しており、その筆頭はハルシネーション、低い精度、オーケストレーションの失敗である。オーケストレーションの失敗に対する解決策として報告されているのは、無制限の自然言語によるやり取りを、明確に定義された機械可読なメッセージ形式に置き換える、構造化されたスキーマベースの通信プロトコルと、衝突や終わらない相互作用を防ぐために個々のファイル、サービス、プロセスへの責任を明示的に割り当てることである。そのほかの課題カテゴリーは、セキュリティとプライバシーのリスク、計算資源とリソースの制約、コンテキストとメモリの制限、ベンチマークの課題、検証の課題、プロンプト設計の課題である。
こうしたシステムを駆動するモデルについて、同レビューはコーパス全体で 83 件の LLM 利用例を数えており、うち 57 件がクローズドソース、26 件がオープンソースで、OpenAI の GPT シリーズが 43 件を占め、オープンソースでは Meta の Llama が 17 件で最も多い。同レビューは、プロプライエタリなプラットフォームへの依存がデータのプライバシー、セキュリティ、依存性に関する懸念を生みうる一方、オープンソースの代替手段はデプロイの制御、コスト効率、データプライバシーの向上をもたらすと指摘している。
三つ目の情報源は、同じ主題にアーキテクチャや証拠としてではなく、運用のハンドブックとしてアプローチしている。Jimmy Song のオンラインハンドブック『智能体构建指南』のある章は、こうしたシステムを構築する際の実践的な中身として扱う四つの関心事を挙げており、その一貫した警告は過剰設計に対するものである。フレームワークは仕組みを提供するが、調整のオーバーヘッドが専門化による利得を打ち消すことがあり、タスクが逐次的で密結合である場合や、プロンプトエンジニアリングを改善したよく設計された単一のエージェントで足りる場合には、複雑なフレームワークは不要なコストでしかない、というのである。
役割の分離。 同章が挙げる役割は、Planner（タスクを分解し戦略を定める）、Worker（サブタスクを実行し、ドメインの専門家であることもある）、Reviewer（結果を確認し改善する）、Orchestrator（作業を割り振り最終決定を下す）であり、責任が重ならないように境界が引かれる。同章は、CrewAI がこれをエージェントごとの role と goal 属性として設定に持っていること、また LangGraph の Supervisor パターンが、リクエストをサブエージェントへルーティングするエージェントとして Orchestrator を実現していることを指摘している。
合意と調停。 エージェント間で意見が分かれた場合について、同章は三つの戦略を挙げている。一つは多数決または順位付け投票で、AutoGen の討論の構成がその例である。そこでは解答者エージェントが複数のラウンドにわたって議論し、最終ラウンドを集約者が多数決で決着させる。二つ目は複数のモデルにまたがる確信度加重投票で、同章はこれを ReConcile フレームワークによるものとしている。三つ目は信頼値によるルーティングで、エージェントの重みを過去の実績に基づいて調整し、より信頼できるエージェントの意見がより大きな影響力を持つようにする。
トレーシング。 同章の推奨は、フレームワークがすでに永続化している状態（LangGraph のグラフ状態、CrewAI の Flow States）に加えて、エージェントの相互作用ごとに一意のトレース ID を付与し、ログと呼び出しのコンテキストを結びつけることである。同章は各フレームワーク独自のオブザーバビリティ機能（CrewAI の Tracing & Observability、LangGraph の LangSmith 連携）に触れ、各エージェントの意思決定の詳細を一つのログに出力するためにコールバックを使うことを提案している。
封じ込め。 マルチエージェントの実行は過剰な呼び出しとコストを生むため、同章は、エージェント単位またはワークフロー単位のトークンと呼び出しの割り当て上限、閾値を超えたら終了または縮退させる予算監視、リトライ回数の上限とサーキットブレーカー、そして入力のフィルタリングを挙げている。最後のものについては、オープンソースのフレームワークではユーザーが自分で実装しなければならないと指摘している。
同章はまた、比較した六つのフレームワークのいずれも解決していないとする限界を述べている。エージェント間の効率的なコンテキストの受け渡しである。利用できるアプローチは、すべてを共有する（遅く高価になる）か、要約を共有する（詳細が失われる）かのどちらかであり、選択的で意味に基づく受け渡しこそがマルチエージェントシステムの経済性を決めるものだとして、チームはフレームワークがこの問題を解決しないことを承知のうえでフレームワークを選ぶべきだと論じている。過剰設計についての警告も同じ方向を向いている。調整のオーバーヘッドは専門化による利得を打ち消しうるし、現在のモデルの限界を補うために加えた構造は、より優れたモデルが登場したときに取り除けるように作るべきだ、というのである。これらは同章では立場として述べられているものであり、その裏づけとなる測定は何も示されていない。