Affordable and efficient Sora video watermark removal. Sign up now and get 1 free credits!
A2A Protocol
A2A MCP Integration

Gitリポジトリ:A2A MCP

このリポジトリは、a2a-python SDKを設定・使用してシンプルなサーバーとクライアントを作成し、a2aプロトコルを実装する方法を示しています。エージェントサーバーはmcpによって実装されています。

概要

  • A2A (Agent2Agent): 相互運用可能なAIエージェントを構築するためのプロトコルとSDK。
  • この例: 基本的なA2Aサーバーとクライアントの実行、メッセージ交換、レスポンスの表示方法を示します。

前提条件

  • Python 3.13+
  • uv (高速な依存関係管理と実行のため)
  • OpenRouterのAPIキー (OPENROUTER_API_KEYとして設定)

インストール

  1. リポジトリをクローン:

    git clone https://github.com/sing1ee/a2a-mcp-openrouter
    cd https://github.com/sing1ee/a2a-mcp-openrouter
    
  2. 依存関係をインストール:

    uv venv
    source .venv/bin/activate
    
  3. 環境変数を設定:

    export OPENROUTER_API_KEY=your-openrouter-api-key
    

    または.envファイルを作成:

    OPENROUTER_API_KEY=your-openrouter-api-key
    

    注意: OpenRouter APIキーはhttps://openrouter.ai/から取得できます

例の実行

1. サーバーを開始

uv run --env-file .env a2a-server
  • サーバーはポート9999で開始されます。

エージェントカードの検証:

2. クライアントを実行

新しいターミナルで:

uv venv
source .venv/bin/activate
uv run --env-file .env a2a-client --question "A2Aプロトコルとは何ですか?"
  • クライアントはサーバーに接続してリクエストを送信します。

3. レスポンスを表示

  • クライアントからのレスポンスはresponse.xmlに保存されます。

設定

システムは以下の設定を使用します:

  • モデル: OpenRouter経由のgoogle/gemini-flash-1.5
  • ベースURL: https://openrouter.ai/api/v1

ファイル構造

  • src/a2a_mcp_openrouter/server/: サーバー実装。
  • src/a2a_mcp_openrouter/client/: クライアント実装。
  • response.xml: クライアントからの例レスポンス。

トラブルシューティング

  • 依存関係の不足: uvがインストールされていることを確認してください。
  • APIキーエラー: OPENROUTER_API_KEYが正しく設定されていることを確認してください。
  • ポート競合: ポート9999が空いていることを確認してください。

A2A vs MCP: プロトコルの類似性と統合アプローチ

この実装を通じて、A2A (Agent2Agent)MCP (Model Context Protocol) が驚くべきアーキテクチャの類似性を共有していることを発見しました。両プロトコルは発見、機能交換、実行において類似のパターンに従います。

統合実装パターン

重要な発見: A2AとMCPは両方とも同じ基本的な実装パターンに従います:

  • HTTPベースの通信: 両方ともHTTPを通信に使用(A2AはREST API、MCPはServer-Sent Eventsを使用)
  • プロンプト駆動設計: 両方ともLLMプロンプトに依存して何を呼び出すか、どのように呼び出すかを決定
  • 発見メカニズム: 両方とも利用可能な機能を発見する方法を提供
  • 構造化レスポンス: 両方ともプログラム的に処理できる構造化データを返す

mcp.py実装を見ると:

# HTTP経由のMCPツール発見
async with sse_client(url) as (read, write):
    resources = await session.list_tools()
    
# LLM意思決定のためのプロンプト生成
return template.render(tools=resources.tools)

# HTTP経由のツール呼び出し実行
return await session.call_tool(tool_name, arguments=arguments)

これはA2Aエージェント呼び出しパターンと概念的に同一です - 機能を発見し、LLMを使用して何を呼び出すかを決定し、その後呼び出しを実行します。

ユニバーサルインターフェースとしてのA2A

重要な洞察: A2Aは、呼び出しパターンが本質的に同じであるため、エージェント間通信とツール呼び出しの両方に対する統合インターフェースとして機能できます:

  1. A2A → エージェント: クライアント → HTTP → エージェント → LLMレスポンス
  2. A2A → ツール: クライアント → HTTP → ツールラッパー → MCPツールレスポンス

両パターンは以下を使用:

  • HTTP通信
  • 機能発見
  • LLM駆動の意思決定
  • 構造化リクエスト/レスポンス形式

この統合アプローチの利点

  • 単一インターフェース: クライアントは1つの呼び出しパターンのみを理解すれば良い
  • 相互運用性: 同じワークフロー内でエージェントとツールをシームレスに混在
  • 一貫したアーキテクチャ: 異なる機能タイプ間で同じ実装パターン
  • LLMネイティブ設計: 両方ともインテリジェントな機能選択のためにLLM推論を活用

これは、A2AとMCPが競合するプロトコルではなく、単一のインターフェースパラダイムの下で統合できる補完的なパターンであることを示しています。

システムアーキテクチャとフロー

以下は、クライアント入力から最終レスポンスまでのA2Aプロトコルの完全なフローを示す詳細なシーケンス図です:

sequenceDiagram
    participant User
    participant Client as A2A Client
    participant LLM_Client as OpenRouter LLM (Client)
    participant Server as A2A Server
    participant AgentExecutor as Agent Executor
    participant Agent as Server Agent
    participant LLM_Server as OpenRouter LLM (Server)
    participant MCP as MCP Tool

    User->>Client: 質問を入力: "A2Aプロトコルとは何ですか?"
    
    Note over Client: agent_urlsでエージェントを初期化
    Client->>Server: GET /agent-card - 利用可能なエージェントを発見
    Server-->>Client: 機能を持つAgentCardを返す
    
    Note over Client: エージェントプロンプトテンプレートをレンダリング
    Client->>LLM_Client: 質問と利用可能なエージェントで決定プロンプトを送信
    LLM_Client-->>Client: 選択されたエージェントでJSONを返す
    
    loop 選択された各エージェントに対して
        Client->>Server: POST /send-message-streaming
        
        Server->>AgentExecutor: execute(context, event_queue)
        AgentExecutor->>Agent: stream(query)
        
        Agent->>MCP: 利用可能なツールを取得
        MCP-->>Agent: ツール定義を返す
        
        Note over Agent: ツールプロンプトテンプレートをレンダリング
        Agent->>LLM_Server: 質問とツールで決定プロンプトを送信
        LLM_Server-->>Agent: 選択されたツールでJSONを返す
        
        loop 選択された各ツール(最大反復)
            Agent->>MCP: 引数でツールを呼び出し
            MCP-->>Agent: ツール結果を返す
            
            Note over Agent: called_tools履歴を更新
            Agent->>LLM_Server: ツール結果で更新されたプロンプトを送信
            LLM_Server-->>Agent: 次のツールまたは最終回答を返す
            
            alt より多くのツールが必要
                Note over Agent: 次の反復に続行
            else タスク完了
                Note over Agent: タスク完了
            end
        end
        
        Agent-->>AgentExecutor: ストリーミングイベントを生成
        AgentExecutor-->>Server: event_queueにイベントを転送
        Server-->>Client: HTTP経由でレスポンスチャンクをストリーミング
        
        Client->>Client: レスポンスタグから回答を抽出
        Note over Client: agent_answersリストに追加
    end
    
    alt 最終統合が必要
        Client->>LLM_Client: すべての回答で統合プロンプトを送信
        LLM_Client-->>Client: 最終統合回答を返す
    else 統合不要
        Note over Client: 既存の回答を使用
    end
    
    Client-->>User: エージェント出力で最終レスポンスをストリーミング

主要機能

  • エージェント発見: A2Aプロトコル経由での利用可能なエージェントの自動発見
  • LLM駆動選択: LLM推論を使用したインテリジェントなエージェントとツール選択
  • MCP統合: 知識検索のためのMCPツールとのシームレスな統合
  • ストリーミングパイプライン: パイプライン全体を通じたリアルタイムストリーミングレスポンス
  • 反復処理: コンテキストを維持した複数反復ツール呼び出し

フロー説明

システムは以下の主要フェーズに従います:

クライアントフェーズ: ユーザーが質問を入力 → クライアントがエージェントを発見 → LLMが関連エージェントを選択

サーバーフェーズ: サーバーがリクエストを受信 → エージェントがツールを発見 → LLMがツールを選択 → ツールが反復的に実行

レスポンスフェーズ: 結果がパイプラインを通じてストリームバック → クライアントが最終回答を統合 → ユーザーがレスポンスを受信

このアーキテクチャは、相互に発見し協力できる相互運用可能なAIエージェントを作成するA2Aプロトコルの力を実証し、外部知識ソースにアクセスするためのMCPツールを活用しています。

Related Articles

Explore more content related to this topic

AgentMaster Multi-Agent Conversational Framework - Multimodal Information Retrieval System Based on A2A and MCP Protocols

AgentMaster is a next-generation multi-agent conversational framework jointly developed by Stanford University and George Mason University, pioneering the integration of A2A and MCP protocols in a single system. It supports multimodal inputs including text, images, and audio, automatically decomposes complex tasks through coordinator agents, and implements various functions such as SQL queries, information retrieval, and image analysis with excellent performance and user-friendliness.

MCP
Read article