過去2年間、AIエンジニアリングは単純なシナリオに従ってきました。エージェントにプロンプト、いくつかのツール、そしてメモリレイヤーを与えます。すると、エージェントが会議のスケジュールを立てたり、契約書を要約したり、スクリプトのデバッグを行ったりする様子を眺めるだけでした。その目的のすべては、単一のエージェントをそれ単体で有用にすることにありました。
その目標は変わりました。
現在、業界は単独のエージェントから「エージェント・チーム」へとシフトしています。カスタマーサービスのトリアージ・ボットが返金リクエストを特定し、その案件を決済エージェントにルーティングします。ウェブデータをスクレイピングするリサーチ・エージェントがニッチな情報の欠落に直面し、独自のデータベースを持つスペシャリストにタスクを委任します。出荷を計画している物流エージェントがリアルタイムの運送料の見積もりを必要とし、価格設定エージェントに見積もりを依頼します。
書面上では単純に聞こえますが、実際には脆弱です。
新たな課題は相互運用性(interoperability)です。チームは異なるフレームワークでエージェントを構築します。ベンダーごとに異なるインターフェースを持つエージェントが提供されます。ある企業が別の企業と連携する必要があるとき、その溝は広がります。現在、私たちは、有能なワーカーが揃っているものの、共通言語を持たない状況に直面しています。エージェントはディレクトリから他のエージェントを検索することができません。同僚が何をしているのかという説明を読むこともできません。そして、データの漏洩、コンテキストの喪失、あるいは重複実行のリスクを冒さずに、機密性の高い業務を引き継ぐこともできません。
これこそが、A2Aが解決するために構築された問題です。A2Aは、エージェントに発見、委任、および安全なコラボレーションのための共通プロトコルを提供します。
単一エージェントからエージェントのサイロ化へ
エージェント・フレームワークの第一波は、システムの境界をエージェントの境界として扱っていました。推論ループを構築し、ツールベルトを与え、ワークフローを自力で考え抜けることを期待する、というものです。エージェントが単一のコードベース、単一のクラウドアカウント、あるいは単一のベンダープラットフォーム内に留まっている限り、それは十分に機能しました。
実際のビジネスはモノリス(monoliths)の中では動きません。返金リクエストはCRMから始まり、Pythonで書かれた内部の決済サービスへと渡り、サードパーティがホストする不正チェックで終了するかもしれません。これらの各サービスをエージェントとしてモデル化すると、異なるスタックで構築されたエージェント同士は、ネイティブには理解し合えないことにすぐに気づきます。独自のフレームワークで構築されたエンタープライズ・エージェントは、その能力を外部の世界に公開することはありません。
標準がなければ、あらゆる統合がカスタムプロジェクトになってしまいます。エンジニアは使い捨てのグルーコード(glue code)を書くことになります。情報の受け渡しにおいてコンテキストが失われます。ハンドオフ(引き継ぎ)がその都度個別対応(bespoke)になるため、セキュリティポリシーも一貫性を欠くようになります。
Agent Cards:公開履歴書
A2Aは、エージェントが自分は何者であり、何ができるかを公表するための手段としてAgent Cardsを導入します。
Agent Cardをマシンリーダブルな履歴書と考えてください。エージェントは、自身のドメイン、必要な入力、期待される出力、および受け入れ可能な業務に関する制約を記述したカードを公開します。例えば、決済エージェントであれば、「注文IDと理由コードが提供された場合に、一定金額以下の返金リクエストを処理し、確認番号またはエラーを返す」と宣言するかもしれません。データスペシャリストであれば、「特定のサイズまでの構造化ファイルを受け入れ、予測可能な時間枠内でクレンジング済みの時系列データを返す」と述べるかもしれません。
業務を委任する前に、依頼側のエージェントはカードを読み取ります。これにより、対象のエージェントにその業務を実行する能力があるかどうかを理解できます。ペイロードに必要な形式を把握できます。同期的なレスポンスを期待すべきか、あるいは後で完了する非同期タスクとして扱うべきかも判断できます。
これにより、推測の必要がなくなります。考えられるすべてのパートナーに対して統合をハードコーディングする代わりに、エージェントは利用可能な機能をブラウズし、適切なチームメイトを動的に選択できるようになります。
Tasks:単なるAPIコールではなく、構造化された業務
エージェントは人間のようにチャットする必要はありません。業務をクリーンに引き継ぐ必要があります。A2Aはこのやり取りをTaskとしてモデル化します。
Taskは単なる...以上のものです
