A2A MCP Integration

Git Repo：A2A MCP

Dieses Repository zeigt, wie Sie das a2a-python SDK einrichten und verwenden, um einen einfachen Server und Client zu erstellen, der das a2a-Protokoll implementiert, wobei der Agent-Server durch MCP implementiert wird.

Überblick

• A2A (Agent2Agent): Ein Protokoll und SDK zum Erstellen interoperabler KI-Agenten.
• Dieses Beispiel: Zeigt, wie Sie einen grundlegenden A2A-Server und -Client ausführen, Nachrichten austauschen und die Antwort anzeigen.

Voraussetzungen

• Python 3.13+
• uv (für schnelle Abhängigkeitsverwaltung und Ausführung)
• Ein API-Schlüssel für OpenRouter (als OPENROUTER_API_KEY festgelegt)

Installation

1. Repository klonen:

   git clone https://github.com/sing1ee/a2a-mcp-openrouter
   cd https://github.com/sing1ee/a2a-mcp-openrouter
   

2. Abhängigkeiten installieren:

   uv venv
   source .venv/bin/activate
   

3. Umgebungsvariablen setzen:

   export OPENROUTER_API_KEY=your-openrouter-api-key
   

   Oder erstellen Sie eine .env-Datei mit:

   OPENROUTER_API_KEY=your-openrouter-api-key
   

   Hinweis: Sie können Ihren OpenRouter API-Schlüssel von https://openrouter.ai/ erhalten

Beispiel ausführen

1. Server starten

uv run --env-file .env a2a-server

• Der Server wird auf Port 9999 gestartet.

Agent-Karte validieren:

• a2a protocol validator
• Anleitung: Wie Sie Ihre Agent-Karte validieren

2. Client ausführen

In einem neuen Terminal:

uv venv
source .venv/bin/activate
uv run --env-file .env a2a-client --question "Was ist das A2A-Protokoll?"

• Der Client wird sich mit dem Server verbinden und eine Anfrage senden.

3. Antwort anzeigen

• Die Antwort vom Client wird in response.xml gespeichert.

Konfiguration

Das System verwendet die folgende Konfiguration:

• Modell: google/gemini-flash-1.5 über OpenRouter
• Basis-URL: https://openrouter.ai/api/v1

Dateistruktur

• src/a2a_mcp_openrouter/server/: Server-Implementierung.
• src/a2a_mcp_openrouter/client/: Client-Implementierung.
• response.xml: Beispielantwort vom Client.

Fehlerbehebung

• Fehlende Abhängigkeiten: Stellen Sie sicher, dass Sie uv installiert haben.
• API-Schlüssel-Fehler: Stellen Sie sicher, dass OPENROUTER_API_KEY korrekt gesetzt ist.
• Port-Konflikte: Stellen Sie sicher, dass Port 9999 frei ist.

A2A vs MCP: Protokoll-Ähnlichkeiten und einheitlicher Ansatz

Durch diese Implementierung haben wir entdeckt, dass A2A (Agent2Agent) und MCP (Model Context Protocol) bemerkenswerte architektonische Ähnlichkeiten aufweisen. Beide Protokolle folgen einem ähnlichen Muster für Erkennung, Fähigkeitenaustausch und Ausführung.

Einheitliches Implementierungsmuster

Wichtige Entdeckung: Sowohl A2A als auch MCP folgen demselben zugrundeliegenden Implementierungsmuster:

• HTTP-basierte Kommunikation: Beide verwenden HTTP für die Kommunikation (A2A verwendet REST-APIs, MCP verwendet Server-Sent Events)
• Prompt-gesteuertes Design: Beide verlassen sich auf LLM-Prompts, um zu entscheiden, was aufgerufen werden soll und wie es aufgerufen werden soll
• Erkennungsmechanismus: Beide bieten Möglichkeiten, verfügbare Fähigkeiten zu entdecken
• Strukturierte Antworten: Beide geben strukturierte Daten zurück, die programmatisch verarbeitet werden können

Bei der Betrachtung der mcp.py-Implementierung können wir sehen:

# MCP-Tool-Erkennung über HTTP
async with sse_client(url) as (read, write):
    resources = await session.list_tools()
    
# Prompt für LLM-Entscheidungsfindung generieren
return template.render(tools=resources.tools)

# Tool-Aufruf über HTTP ausführen
return await session.call_tool(tool_name, arguments=arguments)

Dies ist konzeptionell identisch mit dem A2A-Agent-Aufrufmuster - Fähigkeiten entdecken, LLM verwenden, um zu entscheiden, was aufgerufen werden soll, dann den Aufruf ausführen.

A2A als universelle Schnittstelle

Wichtige Erkenntnis: A2A kann als einheitliche Schnittstelle sowohl für Agent-zu-Agent-Kommunikation als auch für Tool-Aufrufe dienen, da die Aufrufmuster im Wesentlichen gleich sind:

1. A2A → Agent: Client → HTTP → Agent → LLM-Antwort
2. A2A → Tool: Client → HTTP → Tool-Wrapper → MCP-Tool-Antwort

Beide Muster verwenden:

• HTTP-Kommunikation
• Fähigkeitenerkennung
• LLM-gesteuerte Entscheidungsfindung
• Strukturiertes Anfrage-/Antwortformat

Vorteile dieses einheitlichen Ansatzes

• Einheitliche Schnittstelle: Clients müssen nur ein Aufrufmuster verstehen
• Interoperabilität: Agenten und Tools nahtlos im selben Workflow mischen
• Konsistente Architektur: Gleiches Implementierungsmuster für verschiedene Fähigkeitstypen
• LLM-natives Design: Beide nutzen LLM-Reasoning für intelligente Fähigkeitsauswahl

Dies zeigt, dass A2A und MCP keine konkurrierenden Protokolle sind, sondern komplementäre Muster, die unter einem einheitlichen Schnittstellenparadigma vereint werden können.

Systemarchitektur und Ablauf

Unten ist ein detailliertes Sequenzdiagramm, das den vollständigen Ablauf des A2A-Protokolls von der Client-Eingabe bis zur endgültigen Antwort zeigt:

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: Eingabefrage: "Was ist das A2A-Protokoll?"
    
    Note over Client: Agent mit agent_urls initialisieren
    Client->>Server: GET /agent-card - Verfügbare Agenten entdecken
    Server-->>Client: AgentCard mit Fähigkeiten zurückgeben
    
    Note over Client: Agent-Prompt-Template rendern
    Client->>LLM_Client: Entscheidungsprompt mit Frage und verfügbaren Agenten senden
    LLM_Client-->>Client: JSON mit ausgewählten Agenten zurückgeben
    
    loop Für jeden ausgewählten Agent
        Client->>Server: POST /send-message-streaming
        
        Server->>AgentExecutor: execute(context, event_queue)
        AgentExecutor->>Agent: stream(query)
        
        Agent->>MCP: Verfügbare Tools abrufen
        MCP-->>Agent: Tool-Definitionen zurückgeben
        
        Note over Agent: Tool-Prompt-Template rendern
        Agent->>LLM_Server: Entscheidungsprompt mit Frage und Tools senden
        LLM_Server-->>Agent: JSON mit ausgewählten Tools zurückgeben
        
        loop Für jedes ausgewählte Tool (max Iterationen)
            Agent->>MCP: Tool mit Argumenten aufrufen
            MCP-->>Agent: Tool-Ergebnis zurückgeben
            
            Note over Agent: called_tools-Historie aktualisieren
            Agent->>LLM_Server: Aktualisierten Prompt mit Tool-Ergebnissen senden
            LLM_Server-->>Agent: Nächste Tools oder endgültige Antwort zurückgeben
            
            alt Weitere Tools benötigt
                Note over Agent: Zur nächsten Iteration fortfahren
            else Aufgabe abgeschlossen
                Note over Agent: Aufgabe abgeschlossen
            end
        end
        
        Agent-->>AgentExecutor: Streaming-Events ausgeben
        AgentExecutor-->>Server: Events an event_queue weiterleiten
        Server-->>Client: Antwort-Chunks über HTTP streamen
        
        Client->>Client: Antwort aus Response-Tags extrahieren
        Note over Client: Zu agent_answers-Liste hinzufügen
    end
    
    alt Finale Synthese benötigt
        Client->>LLM_Client: Synthese-Prompt mit allen Antworten senden
        LLM_Client-->>Client: Finale synthetisierte Antwort zurückgeben
    else Keine Synthese benötigt
        Note over Client: Vorhandene Antworten verwenden
    end
    
    Client-->>User: Finale Antwort mit Agent-Ausgaben streamen

Hauptmerkmale

• Agent-Erkennung: Automatische Erkennung verfügbarer Agenten über das A2A-Protokoll
• LLM-gesteuerte Auswahl: Intelligente Agent- und Tool-Auswahl mit LLM-Reasoning
• MCP-Integration: Nahtlose Integration mit MCP-Tools für Wissensabruf
• Streaming-Pipeline: Echtzeit-Streaming-Antworten durch die gesamte Pipeline
• Iterative Verarbeitung: Multi-Iterations-Tool-Aufrufe mit erhaltenem Kontext

Ablaufbeschreibung

Das System folgt diesen Hauptphasen:

Client-Phase: Benutzer gibt Frage ein → Client entdeckt Agenten → LLM wählt relevante Agenten aus

Server-Phase: Server empfängt Anfrage → Agent entdeckt Tools → LLM wählt Tools aus → Tools werden iterativ ausgeführt

Antwort-Phase: Ergebnisse werden durch die Pipeline zurückgestreamt → Client synthetisiert finale Antwort → Benutzer erhält Antwort

Diese Architektur demonstriert die Macht des A2A-Protokolls beim Erstellen interoperabler KI-Agenten, die sich gegenseitig entdecken und zusammenarbeiten können, während sie MCP-Tools für den Zugriff auf externe Wissensquellen nutzen.