前のページでは、1 つのプロセス内でエージェントを作成する方法を示しました。1 つのエージェントが別のエージェントを関数ツールとして呼び出し、フレームワークが残りを処理します。 このパターンは、すべてのエージェントが同じアプリケーションに存在し、同じランタイムを共有し、同じチームによって管理されている場合に適切に機能します。
しかし、現実のエージェント システムでは、多くの場合、境界を越えて通信する必要があります。 Agent-to-Agent (A2A) は、まさにこのために設計された オープン プロトコル です。 エージェントが互いを検出し、メッセージを交換し、HTTP 経由で、任意の境界を越えて、任意の言語またはフレームワークでタスクを調整するための標準的な方法を定義します。 Agent Framework には 組み込みの A2A 統合 が用意されているため、最小限のセットアップで A2A 準拠のエージェントをホストおよび呼び出すことができます。
使用タイミング
エージェントがインプロセスコンポジションで処理できない境界を越える必要がある場合は、A2A を使用します。
- サービスの境界。 旅行予約エージェントはマイクロサービスとして実行され、経費申請エージェントは別のものとして実行されます。 互いをインプロセス関数ツールとして呼び出すことはできません。ネットワーク プロトコルが必要です。
- チームの境界。 パートナー チームは、"コンプライアンス レビュー" エージェントを所有しています。 コード、モデル、またはデプロイにアクセスすることはできません。要求を送信して応答を取得するだけで済みます。
- 組織の境界。 サード パーティのプロバイダーは、特殊なエージェント (ドキュメント処理、法的レビュー、医療トリアージ) を提供します。 構築されているフレームワークや言語に関係なく、それを検出し、何ができるかを理解し、通信するための標準的な方法が必要です。
- 独立した進化。 エージェントは、実装を密に結合することなく、異なるリリース サイクル、異なるチーム、または異なる言語を必要とします。
ヒント
エージェントがすべて同じプロセスに存在し、同じチームによって管理されている場合、 エージェントはツールとしての 方が簡単で、オーバーヘッドが少なくなります。 A2A は、プロセス、サービス、または組織の境界を越えたときに価値を追加します。
考慮事項
| 考慮事項 | 詳細情報 |
|---|---|
| 相互運用性 | A2A はフレームワークに依存しません。 .NET エージェントは、Python エージェント、LangChain エージェント、またはプロトコルを実装する任意のエージェントを呼び出すことができます。 これは A2A の主な値であり、"エージェント通信の HTTP" です。 |
| ネットワークのオーバーヘッド | A2A 呼び出しはすべて HTTP 要求です。 これにより、インプロセス エージェントのツールとしての呼び出しと比較して待機時間が増加します。 パフォーマンスに依存するパスの場合は、エージェントを併置するか、境界が本当に存在する場合にのみ A2A を使用します。 |
| 操作の複雑さ | リモート エージェントは分散サービスです。 ネットワーク障害、タイムアウト、再試行、およびバージョン管理を処理する必要があります。サービス間通信の場合と同じ問題です。 |
| 実行時の検出 | エージェント カードは検出を動的にしますが、見る場所を知る必要があります。 運用環境では、通常、既知のエージェント エンドポイントを構成するか、レジストリを使用します。 |
| 会話の状態 | リモート エージェントは、独自の会話状態 (コンテキスト ID でキー指定) を管理します。 エージェントには、リモート エージェントの内部推論は表示されません。応答のみが表示されます。 リモート エージェントが再起動して状態が失われると、会話コンテキストが失われる可能性があります。 |
次のステップ
エージェントが任意の境界を越えて通信できるようになったので、体験の最後の手順は ワークフロー です。実行順序、状態、回復可能性を完全に制御する必要がある、マルチステップ、マルチエージェント プロセスの明示的なグラフベースのオーケストレーションです。
より深く進む:
- A2A 統合 — A2A エージェントをホストおよび呼び出すための実装ガイド
- ツールとしてのエージェント — よりシンプルなインプロセスコンポジションパターン