Intégration A2A MCP

Dépôt Git : A2A MCP

Ce dépôt démontre comment configurer et utiliser le SDK a2a-python pour créer un serveur et un client simples implémentant le protocole a2a, et le serveur d'agent est implémenté par mcp.

Aperçu

A2A (Agent2Agent) : Un protocole et SDK pour construire des agents IA interopérables.
Cet Exemple : Montre comment exécuter un serveur et client A2A de base, échanger des messages et visualiser la réponse.

Prérequis

Python 3.13+
uv (pour la gestion rapide des dépendances et l'exécution)
Une clé API pour OpenRouter (définie comme OPENROUTER_API_KEY)

Installation

Cloner le dépôt :

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

Installer les dépendances :
```
uv venv
source .venv/bin/activate
```
Définir les variables d'environnement :
```
export OPENROUTER_API_KEY=votre-clé-api-openrouter
```
Ou créer un fichier .env avec :
```
OPENROUTER_API_KEY=votre-clé-api-openrouter
```
Note : Vous pouvez obtenir votre clé API OpenRouter depuis https://openrouter.ai/

Exécution de l'Exemple

1. Démarrer le Serveur

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

Le serveur démarrera sur le port 9999.

valider la carte d'agent :

2. Exécuter le Client

Dans un nouveau terminal :

uv venv
source .venv/bin/activate
uv run --env-file .env a2a-client --question "Qu'est-ce que le protocole A2A ?"

Le client se connectera au serveur et enverra une requête.

3. Visualiser la Réponse

La réponse du client sera sauvegardée dans response.xml.

Configuration

Le système utilise la configuration suivante :

Modèle : google/gemini-flash-1.5 via OpenRouter
URL de Base : https://openrouter.ai/api/v1

Structure des Fichiers

src/a2a_mcp_openrouter/server/ : Implémentation du serveur.
src/a2a_mcp_openrouter/client/ : Implémentation du client.
response.xml : Exemple de réponse du client.

Dépannage

Dépendances manquantes : Assurez-vous d'avoir uv installé.
Erreurs de clé API : Vérifiez que OPENROUTER_API_KEY est correctement définie.
Conflits de port : Assurez-vous que le port 9999 est libre.

A2A vs MCP : Similitudes de Protocole et Approche Unifiée

À travers cette implémentation, nous avons découvert que A2A (Agent2Agent) et MCP (Model Context Protocol) partagent des similitudes architecturales remarquables. Les deux protocoles suivent un modèle similaire pour la découverte, l'échange de capacités et l'exécution.

Modèle d'Implémentation Unifié

Découverte Clé : A2A et MCP suivent tous deux le même modèle d'implémentation sous-jacent :

Communication basée sur HTTP : Les deux utilisent HTTP pour la communication (A2A utilise les API REST, MCP utilise les Server-Sent Events)
Conception pilotée par prompt : Les deux s'appuient sur les prompts LLM pour décider quoi appeler et comment l'appeler
Mécanisme de Découverte : Les deux fournissent des moyens de découvrir les capacités disponibles
Réponses Structurées : Les deux retournent des données structurées qui peuvent être traitées programmatiquement

En regardant l'implémentation mcp.py, nous pouvons voir :

# Découverte d'outils MCP via HTTP
async with sse_client(url) as (read, write):
    resources = await session.list_tools()
    
# Générer un prompt pour la prise de décision LLM  
return template.render(tools=resources.tools)

# Exécuter l'appel d'outil via HTTP
return await session.call_tool(tool_name, arguments=arguments)

Ceci est conceptuellement identique au modèle d'appel d'agent A2A - découvrir les capacités, utiliser LLM pour décider quoi appeler, puis exécuter l'appel.

A2A comme Interface Universelle

Insight Clé : A2A peut servir d'interface unifiée pour la communication agent-à-agent et l'invocation d'outils, car les modèles d'appel sont essentiellement les mêmes :

A2A → Agent : Client → HTTP → Agent → Réponse LLM
A2A → Outil : Client → HTTP → Wrapper d'Outil → Réponse d'Outil MCP

Les deux modèles utilisent :

Communication HTTP
Découverte de capacités
Prise de décision pilotée par LLM
Format de requête/réponse structuré

Avantages de cette Approche Unifiée

Interface Unique : Les clients n'ont besoin de comprendre qu'un seul modèle d'appel
Interopérabilité : Mélanger agents et outils de manière transparente dans le même flux de travail
Architecture Cohérente : Même modèle d'implémentation à travers différents types de capacités
Conception native LLM : Les deux exploitent le raisonnement LLM pour la sélection intelligente de capacités

Cela démontre que A2A et MCP ne sont pas des protocoles concurrents mais des modèles complémentaires qui peuvent être unifiés sous un paradigme d'interface unique.

Architecture Système et Flux

Ci-dessous se trouve un diagramme de séquence détaillé montrant le flux complet du protocole A2A depuis l'entrée client jusqu'à la réponse finale :

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: Question d'entrée: "Qu'est-ce que le protocole A2A ?"
    
    Note over Client: Initialiser l'Agent avec agent_urls
    Client->>Server: GET /agent-card - Découvrir les agents disponibles
    Server-->>Client: Retourner AgentCard avec capacités
    
    Note over Client: Rendre le template de prompt d'agent
    Client->>LLM_Client: Envoyer prompt de décision avec question et agents disponibles
    LLM_Client-->>Client: Retourner JSON avec agents sélectionnés
    
    loop Pour chaque agent sélectionné
        Client->>Server: POST /send-message-streaming
        
        Server->>AgentExecutor: execute(context, event_queue)
        AgentExecutor->>Agent: stream(query)
        
        Agent->>MCP: Obtenir les outils disponibles
        MCP-->>Agent: Retourner les définitions d'outils
        
        Note over Agent: Rendre le template de prompt d'outil
        Agent->>LLM_Server: Envoyer prompt de décision avec question et outils
        LLM_Server-->>Agent: Retourner JSON avec outils sélectionnés
        
        loop Pour chaque outil sélectionné (max itérations)
            Agent->>MCP: Appeler l'outil avec arguments
            MCP-->>Agent: Retourner le résultat de l'outil
            
            Note over Agent: Mettre à jour l'historique called_tools
            Agent->>LLM_Server: Envoyer prompt mis à jour avec résultats d'outils
            LLM_Server-->>Agent: Retourner prochains outils ou réponse finale
            
            alt Plus d'outils nécessaires
                Note over Agent: Continuer à la prochaine itération
            else Tâche terminée
                Note over Agent: Tâche terminée
            end
        end
        
        Agent-->>AgentExecutor: Produire des événements de streaming
        AgentExecutor-->>Server: Transférer les événements vers event_queue
        Server-->>Client: Streamer les chunks de réponse via HTTP
        
        Client->>Client: Extraire la réponse des balises de réponse
        Note over Client: Ajouter à la liste agent_answers
    end
    
    alt Besoin de synthèse finale
        Client->>LLM_Client: Envoyer prompt de synthèse avec toutes les réponses
        LLM_Client-->>Client: Retourner réponse synthétisée finale
    else Pas de synthèse nécessaire
        Note over Client: Utiliser les réponses existantes
    end
    
    Client-->>User: Streamer la réponse finale avec sorties d'agent

Fonctionnalités Clés

Découverte d'Agent : Découverte automatique des agents disponibles via le protocole A2A
Sélection Pilotée par LLM : Sélection intelligente d'agents et d'outils utilisant le raisonnement LLM
Intégration MCP : Intégration transparente avec les outils MCP pour la récupération de connaissances
Pipeline de Streaming : Réponses de streaming en temps réel à travers tout le pipeline
Traitement Itératif : Appel d'outils multi-itération avec contexte maintenu

Description du Flux

Le système suit ces phases principales :

Phase Client : L'utilisateur saisit une question → Le client découvre les agents → LLM sélectionne les agents pertinents

Phase Serveur : Le serveur reçoit la requête → L'agent découvre les outils → LLM sélectionne les outils → Les outils s'exécutent de manière itérative

Phase Réponse : Les résultats remontent le pipeline → Le client synthétise la réponse finale → L'utilisateur reçoit la réponse

Cette architecture démontre la puissance du protocole A2A dans la création d'agents IA interopérables qui peuvent se découvrir mutuellement et collaborer, tout en exploitant les outils MCP pour accéder aux sources de connaissances externes.

A2A MCP Integration