マルチエージェントのデモは今やどこにでもある。
問題は、それらの多くが現実で痛みを伴う部分の直前で止まってしまうことである: デプロイ形状、サービスの配線、ヘルス、テレメトリ、ランタイム境界、そして分散システムの混沌である。
だからこそ、新しい Aspire + Microsoft Agent Framework サンプルが注目に値する。
いいえ、興味深い部分はスキーリゾートのコンシェルジュシナリオではない。
興味深い部分は、このサンプルが分散エージェントシステムを構築するためのはるかに現実的なパターンを示していることである:
- カスタムホステッドエージェント
- プロンプトエージェント
- 複数のランタイム
- サービス参照
- ライブデータソース
- 可観測性とデプロイ構造
それが本当のストーリーである。
これは「ツールを使うエージェント」以上のものである
サンプルのアーキテクチャは、おなじみのシングルループエージェントモデルを超えている。
以下のものがある:
- 狭い責任を持つ専門エージェント
- それらをオーケストレーションするアドバイザーエージェント
- Foundry 管理リソース
- 同じグラフ内の .NET、Python、Go サービス
- 音声およびチャットのエントリポイント
これは、本格的なエージェントシステムが実際にどのように見えるかにずっと近い。
そしてそこで、Aspire が突然非常に重要になる。
Aspire は人間が通常頭の中に保持する難しい部分をやっている
私が最も気に入っているのは、エージェントロジックですらない。アプリケーショングラフが明示的であるという事実である。
Aspire は以下を記述するために使用されている:
- どのサービスが存在するか
- それらが何に依存しているか
- どのモデルデプロイが必要か
- 各サービスがどのランタイムを使用するか
- どのようなヘルスとデプロイの関係が存在するか
これは重要である。なぜなら、分散エージェントシステムはすぐに混乱するからだ。トポロジが人々の頭の中や無作為なセットアップドキュメントにのみ存在するなら、システムは即座に脆弱になる。
そのトポロジを AppHost に置くことは、再現可能なものへの大きな一歩である。
ツールとしての専門エージェントは依然として注目すべきパターン
このアーキテクチャで私のお気に入りの部分のひとつは、専門エージェントがオーケストレーターの呼び出し可能な能力として表面化される方法である。
そのパターンが理由あって繰り返し現れている。それは以下を提供する:
- 関心事の分離
- より良いドメイン境界
- より明確な可観測性
- すべてを書き換えることなく専門エージェントを簡単に交換可能
.NET チームにとって、これは巨大な全知エージェントを構築し、プロンプト指示が安定を保つことを願うよりもはるかに健全なメンタルモデルである。
私の見解
このサンプルが証明する重要なことは、マルチエージェントアプリが可能であることではない。それはすでにわかっていた。
それは、Microsoft スタックが次の問いに対する一貫した答えを提供し始めていることを証明する:
操作可能であり続けるマルチエージェントシステムをどう構築するか？
グラフには Aspire。ランタイム抽象化には Agent Framework。マネージド AI リソースとホスティングには Foundry。その組み合わせは、実験的ではなく、本物のプラットフォームストーリーのように感じられ始めている。
それが私がここで注目する点である。
元記事: Distributed multi-agent systems with Aspire and Microsoft Agent Framework
