マルチエージェントの波の中で比較的古い部類に入るプロジェクトで、大手ソフトウェア企業の研究所で生まれ、「一群のエージェントが互いに話し、仕事が終わるまで続ける」という枠組みを最初に舞台に載せた一つでもある。ただし現状には先に書くべき前提がある。すでに保守モードに入り、新機能は受け付けず、コミュニティ管理に移っている。だからこのレビューは二つに分かれる。何であり、どう使うのか。そして今それを選ぶべきか。

四つのピースを深さで分ける

公式ドキュメントはプロジェクトを四つに切り、それぞれに入口を用意する。Studio はウェブ画面で、コードを書かずにエージェントの雛形を組める。パッケージ一つ、コマンド一本、ポートと作業ディレクトリを指定すれば動く。対話層の上に立ち、新しい利用者の最初の一歩と位置づけられつつ、アイデアの検証向きで本番までは距離があると添えられている。対話層はコードを書く層で、会話を中心にした単一エージェントと複数エージェントのアプリケーションが対象、Python 3.10 以上が必要で、例は十数行。アシスタントのエージェントを作り、モデルのクライアントを渡し、タスクを一本走らせて結果を出力する。中核はさらに下にあり、イベント駆動のプログラミングフレームワークで、業務プロセス内の決定論的な流れ、マルチエージェント協調の研究、言語をまたぐ分散エージェントに向く。拡張は外の世界をつなぎ込む。モデルコンテキストプロトコルのサーバー向け部品、アシスタントのインターフェース向けエージェント、モデルが生成したコードをコンテナ内で実行する実行器、分散エージェント向けのランタイムだ。

会話からグループチャットへ

対話層のドキュメントの背骨は、モデル、メッセージ、エージェント、チーム、人の介入、終了条件、状態管理と続く。この順序自体が意思表示だ。しばらく走り続ける協調作業を前提にしているから、終了条件と状態管理が付録ではなく独立した章になる。一段上がると、編成の型がいくつも用意されている。セレクター型のグループチャットは、集中してカスタマイズできるセレクターが次に話す相手を決め、共有された文脈で調整する。群れ型はその決定を下に渡し、局所的なツール選択でエージェント同士が直接引き継ぐ。グラフ型のワークフローは有向グラフで流れを組み、境界がはっきりした場面に向く。周囲にはメモリと検索による補強、ログ、部品のシリアライズ、追跡と可観測性といった実務の装備が並び、対話層と拡張で組んだ公式の例示チームもある。ウェブ閲覧、コード実行、ファイル処理のような組み合わせ作業を想定している。手軽さを取るなら画面で雛形を作り、細部を取るなら中核まで降りてイベントループを自分で書く。

保守モードの話のほうが、機能より先に効く

リポジトリ冒頭の告知は端的だ。本プロジェクトは保守モードに入り、新機能も改善も受け付けず、コミュニティ管理に移った。新しい利用者は指定の後継プロジェクトから始めるべきで、既存利用者には移行ガイドがある。同じ告知は、後継が企業向けの後継者であり、本番運用可能な版として安定したインターフェースと長期サポートの約束を備え、単一アシスタントからエージェント群までを対象に、企業向けの編成、複数のモデル事業者、二つの新しいエージェントプロトコルによる実行環境間の相互運用を提供すると説明する。貢献の指針も同じ方向に狭まった。受け付けるのは不具合修正、セキュリティパッチ、文書の改善だけで、機能開発は後継へ誘導される。

三層の構造自体は今も明快だ。中核がメッセージ配送、イベント駆動エージェント、ローカルと分散のランタイムを担い、Python と C# の二言語を支える。対話層はその上に、単純だが主張のあるインターフェースを置き、二者間の対話やグループチャットといった定番の形を覆う。拡張はモデルのクライアントやコード実行などを供給する。道具立てはコード不要の画面とベンチマーク群。ライセンスは二本立てで、コードは MIT、ドキュメントはクリエイティブ・コモンズの表示ライセンス。リポジトリの数字は約 61k スター、9.2k フォーク、98 リリース、556 人のコントリビューター、4.3K プロジェクトでの利用で、主な言語は Python、ほかに C# と TypeScript。

誰がまだ使うべきか

三種類は引き続き恩恵を受ける。既存プロジェクトを持つチーム。コードが動きモデルを調整している現場では、保守モードでも不具合修正とセキュリティパッチは続くので、移行は新規リリースに追われず自分のペースで組める。マルチエージェント協調の作りを研究したい開発者。三つの型はそれぞれ明確な取捨があり、ベンチマーク群と合わせれば対照実験の材料になる。ドキュメントも例もそのまま残っている。そしてアイデアを素早く試したい人。画面は導入すればドラッグ操作で済み、ゼロから編成を組むよりはるかに楽だ。

逆に、二つの状況では後継を直接見るべきだ。新規の本番システム、とくに長期サポートの約束が要る場面。もう機能は足さないと明言されている以上、凍結した枠組みに新しい設計を載せると、以後はコミュニティ頼みになる。そして企業向けの編成、複数のモデル事業者の切り替え、実行環境をまたぐ相互運用が要るチーム。これらは公式に後継側へ置かれた。要するに、いま残っているのは使い勝手のよい既存資産と教材であって、未来に向けた出発点ではない。

フレームワーク選びで機能一覧は入場券にすぎない。本当の分かれ目は、三年後もそのサポート範囲の中にいるかどうかだ。