Agent Builder est désormais disponible en aperçu technique. Commencez avec un essai Elastic Cloud et consultez la documentation d’Agent Builder ici.
Introduction
Les systèmes actuels soutenus par le LLM évoluent rapidement au-delà des applications à modèle unique vers des réseaux complexes où des agents spécialisés travaillent ensemble pour accomplir des tâches que l'informatique moderne n'aurait jamais cru possibles auparavant. Au fur et à mesure que ces systèmes gagnent en complexité, l'infrastructure permettant la communication entre les agents et l'accès aux outils devient l'objectif principal du développement. Deux approches complémentaires sont apparues pour répondre à ces besoins : Les protocoles Agent2Agent (A2A) pour la coordination multi-agents, et le Model Context Protocol (MCP) pour l'accès standardisé aux outils et aux ressources.
Comprendre quand utiliser l'un et l'autre en harmonie ou non peut avoir un impact significatif sur l'évolutivité, la maintenabilité et l'efficacité de vos applications. Cet article explore les concepts et les implémentations de l'A2A dans l'exemple pratique d'une salle de presse numérique, où des agents LLM spécialisés collaborent à la recherche, à la rédaction, à l'édition et à la publication d'articles de presse.
Un référentiel d'accompagnement est disponible ici, et nous examinerons des exemples concrets d'A2A en action vers la fin de l'article, à la section 5.
Produits requis
Le référentiel est constitué d'implémentations basées sur Python des agents A2A. Un serveur API est fourni en Flask, ainsi qu'un service de messagerie Python personnalisé appelé Event Hub, qui achemine les messages pour la journalisation et les mises à jour de l'interface utilisateur. Enfin, une interface utilisateur React est fournie pour une utilisation autonome des fonctionnalités de la salle de presse. Tout est contenu dans une image Docker pour faciliter la mise en œuvre. Si vous souhaitez utiliser les services directement sur votre machine, vous devez vous assurer que ces technologies sont installées :
Langages et moteurs d'exécution
- Python 13.12 - Langage de base du backend
- Node.js 18+ - React UI en option
Cadres de base et SDKS :
- A2A SDK 0.3.8 - Coordination et communication des agents
- Anthropic SDK - Intégration de Claude pour la génération d'IA
- Uvicorn - Serveur ASGI pour l'exécution des agents
- FastMCP 2.12.5+ - Implémentation du serveur MCP
- React 18.2 - Cadre d'interface utilisateur frontale
Données & recherche
- Elasticsearch 9.1.1+ - Indexation et recherche d'articles
Déploiement de Docker (facultatif, mais recommandé)
- Docker 28.5.1+
Section 1 : Qu'est-ce que l'Agent2Agent (A2A) ?
Définition et concepts de base
Spécification officielle : https://a2a-protocol.org/latest/specification/
Origines et évolution
Le concept de communication Agent2Agent, ou de systèmes multi-agents, trouve ses racines dans les systèmes distribués, les microservices et la recherche multi-agents qui remonte à plusieurs dizaines d'années. Les premiers travaux sur l'intelligence artificielle distribuée ont jeté les bases d'agents capables de négocier, de coordonner et de collaborer. Ces premiers systèmes étaient destinés à des simulations sociales à grande échelle, à la recherche universitaire et à la gestion des réseaux électriques.
Avec l'arrivée des LLM et la réduction des coûts d'exploitation, les systèmes multi-agents sont devenus accessibles aux marchés "grand public", avec le soutien de Google et de l'ensemble de la communauté des chercheurs en intelligence artificielle. Désormais connu sous le nom de systèmes Agent2Agent, l'ajout du protocole A2A a évolué pour devenir une norme moderne conçue spécifiquement pour l'ère des modèles linguistiques multiples et de grande envergure coordonnant les efforts et les tâches.
Le protocole A2A garantit une communication et une coordination transparentes entre les agents en appliquant des normes et des principes cohérents aux points d'interaction où les MFR se connectent et communiquent. Cette normalisation permet aux agents de différents développeurs - utilisant différents modèles sous-jacents - de travailler ensemble de manière efficace.
Les protocoles de communication ne sont pas nouveaux et sont largement ancrés dans presque toutes les transactions numériques effectuées sur l'internet. Si vous avez tapé https://www.elastic.co/search-labs dans un navigateur pour accéder à cet article, il y a de fortes chances que les protocoles TCP/IP, de transport HTTP et de recherche DNS aient tous été exécutés, ce qui nous garantit une expérience de navigation cohérente.
Caractéristiques principales
Les systèmes A2A reposent sur plusieurs principes fondamentaux qui garantissent une communication fluide. Le fait de s'appuyer sur ces principes garantit que différents agents, basés sur des LLM, des cadres et des langages de programmation différents, interagissent tous de manière transparente.
Voici les quatre grands principes :
- Transmission de messages: Les agents communiquent par le biais de messages structurés dont les propriétés et les formats sont bien définis.
- Coordination: Les agents orchestrent des flux de travail complexes en se déléguant des tâches et en gérant les dépendances sans bloquer les autres agents.
- Spécialisation: Chaque agent se concentre sur un domaine ou une capacité spécifique, devenant ainsi un expert dans son domaine et offrant la possibilité d'accomplir des tâches basées sur cet ensemble de compétences.
- État distribué: L'état et les connaissances sont répartis entre les agents plutôt que centralisés, les agents ayant la possibilité de s'informer mutuellement de l'état d'avancement des tâches et des retours partiels (artefacts).
La salle de presse : Un exemple concret
Imaginez une salle de rédaction numérique alimentée par des agents d'IA, chacun spécialisé dans un aspect différent du journalisme :
- Chef de l'information (coordinateur/client) : Assigne les sujets et supervise le flux de travail
- Agent Reporter: Rédige des articles sur la base de recherches et d'interviews
- Agent de recherche: Recueille des faits, des statistiques et des informations de base
- Agent d'archivage: Recherche d'articles historiques et identification de tendances à l'aide d'Elasticsearch
- Agent rédacteur: Vérifie la qualité, le style et l'optimisation du référencement des articles.
- Agent de publication: Publie les articles approuvés sur la plateforme de blogs via CI/CD
Ces agents ne travaillent pas isolément ; lorsque le chef de l'information confie un article sur l'adoption des énergies renouvelables, le journaliste a besoin du chercheur pour rassembler des statistiques, du rédacteur en chef pour réviser le projet et de l'éditeur pour publier l'article final. Cette coordination s'effectue par le biais de protocoles A2A.

Section 2 : comprendre l'architecture A2A
Rôles de l'agent client et de l'agent distant
Dans l'architecture A2A, les agents jouent deux rôles principaux. L'agent client est chargé de formuler et de communiquer des tâches aux autres agents du système. Il identifie les agents distants et leurs capacités, et utilise ces informations pour prendre des décisions éclairées en matière de délégation de tâches. L'agent client coordonne le flux de travail global, en veillant à ce que les tâches soient correctement réparties et à ce que le système progresse vers ses objectifs.
L'agent à distance, quant à lui, s'occupe des tâches déléguées par les clients. Il fournit des informations ou entreprend des actions spécifiques en réponse à des demandes, mais n'entreprend pas d'actions de manière indépendante. Les agents à distance peuvent également communiquer avec d'autres agents à distance si nécessaire pour s'acquitter des responsabilités qui leur sont confiées, créant ainsi un réseau collaboratif de capacités spécialisées.
Dans notre salle de presse, le chef de l'information joue le rôle d'agent client, tandis que le journaliste, le chercheur, le rédacteur en chef et l'éditeur sont des agents distants qui répondent aux demandes et se coordonnent les uns avec les autres.
Capacités essentielles de l'A2A
Les protocoles A2A définissent plusieurs capacités permettant une collaboration multi-agents :
1. La découverte
Les serveurs A2A doivent annoncer leurs capacités afin que les clients sachent quand et comment les utiliser pour des tâches spécifiques. Pour ce faire, les cartes d'agent sont des documents JSON qui décrivent les capacités, les entrées et les sorties d'un agent. Les cartes d'agent sont disponibles à des points d'extrémité cohérents et bien connus (tels que le point d'extrémité recommandé /.well-known/agent-card.json ), ce qui permet aux clients de découvrir et d'interroger les capacités d'un agent avant d'entamer une collaboration.
Voici un exemple de carte d'agent pour l'agent d'archivage personnalisé d'Elastic "Archie Archivist". Notez que les fournisseurs de logiciels tels qu'Elastic hébergent leurs agents A2A et fournissent une adresse URL pour l'accès :
Cette carte d'agent révèle plusieurs aspects importants de l'agent d'archivage d'Elastic. L'agent s'identifie comme "Archie Archivist" et indique clairement son objectif : aider à trouver des documents d'actualités historiques dans un index Elasticsearch. La carte précise le fournisseur (Elastic) et la version du protocole (0.3.0), ce qui garantit la compatibilité avec d'autres agents conformes à la norme A2A. Plus important encore, le tableau skills énumère les capacités spécifiques offertes par cet agent, notamment une puissante fonctionnalité de recherche et une exploration intelligente de l'index. Chaque compétence définit les modes d'entrée et de sortie qu'elle prend en charge, ce qui permet aux clients de savoir exactement comment communiquer avec cet agent. Cet agent est dérivé du service Agent Builder d'Elastic, qui fournit une suite d'outils et de points d'extrémité d'API natifs soutenus par LLM pour avoir une conversation avec votre magasin de données, et pas seulement pour en extraire des données. L'accès aux agents A2A dans Elasticsearch peut être trouvé ici.
2. Négociation
Les clients et les agents doivent se mettre d'accord sur les méthodes de communication - que les interactions se fassent par le biais de textes, de formulaires, d'iframes ou même d'audio/vidéo - afin de garantir une interaction correcte entre les utilisateurs et l'échange de données. Cette négociation a lieu au début de la collaboration des agents et établit les protocoles qui régiront leur interaction tout au long du flux de travail. Par exemple, un agent du service clientèle basé sur la voix peut négocier pour communiquer via des flux audio, tandis qu'un agent chargé de l'analyse des données peut préférer JSON structuré. Le processus de négociation permet aux deux parties d'échanger efficacement des informations dans un format adapté à leurs capacités et aux exigences de la tâche à accomplir.
Les capacités énumérées dans l'extrait JSON ci-dessus ont toutes des schémas d'entrée et de sortie ; ces schémas définissent la manière dont les autres agents doivent interagir avec cet agent.
3. Gestion des tâches et des états
Les clients et les agents ont besoin de mécanismes pour communiquer l'état des tâches, les changements et les dépendances tout au long de l'exécution des tâches. Il s'agit notamment de gérer l'ensemble du cycle de vie d'une tâche, depuis sa création et son affectation jusqu'aux mises à jour et aux changements d'état. Les statuts typiques sont les suivants : en attente, en cours, terminé ou en échec. Le système doit également suivre les dépendances entre les tâches afin de s'assurer que les travaux préalables sont achevés avant que les tâches dépendantes ne commencent. La gestion des erreurs et la logique de réessai sont également des éléments essentiels, qui permettent au système de se remettre gracieusement des défaillances et de continuer à progresser vers l'objectif principal.
Exemple de message de tâche :
Cet exemple de message de tâche démontre plusieurs aspects clés de la communication A2A.
- La structure du message comprend des métadonnées telles qu'un identifiant de message unique, le type de message envoyé, l'identification de l'expéditeur et du destinataire, et un horodatage pour le suivi et le débogage.
- La charge utile contient les informations relatives à la tâche proprement dite, spécifiant la capacité invoquée sur l'agent distant et fournissant les paramètres nécessaires à l'exécution de cette capacité.
- La section contexte fournit des informations supplémentaires qui aident l'agent récepteur à comprendre le flux de travail général, y compris les délais et les niveaux de priorité qui indiquent comment l'agent doit allouer ses ressources et planifier son travail.
4. La collaboration
Les clients et les agents doivent permettre une interaction dynamique mais structurée, permettant aux agents de demander des clarifications, des informations ou des sous-actions au client, à d'autres agents ou à des utilisateurs. Cela crée un environnement de collaboration dans lequel les agents peuvent poser des questions complémentaires lorsque les instructions initiales sont ambiguës, demander un contexte supplémentaire pour prendre de meilleures décisions, déléguer des sous-tâches à d'autres agents ayant une expertise plus appropriée et fournir des résultats intermédiaires pour obtenir un retour d'information avant de procéder à l'ensemble de la tâche. Cette communication multidirectionnelle garantit que les agents ne travaillent pas de manière isolée, mais qu'ils sont au contraire engagés dans un dialogue permanent qui aboutit à de meilleurs résultats.
Communication distribuée, d'égal à égal
L'A2A permet une communication distribuée où les agents peuvent être hébergés par différentes organisations, certains agents étant maintenus en interne tandis que d'autres sont fournis par des services tiers. Ces agents peuvent fonctionner sur différentes infrastructures - couvrant potentiellement plusieurs fournisseurs de services en nuage ou des centres de données sur site. Ils peuvent utiliser différents LLM sous-jacents, certains agents étant alimentés par des modèles GPT, d'autres par Claude, et d'autres encore par des alternatives à code source ouvert. Les agents peuvent même opérer dans différentes régions géographiques pour se conformer aux exigences en matière de souveraineté des données ou pour réduire les temps de latence. Malgré cette diversité, tous les agents conviennent d'un protocole de communication commun pour l'échange d'informations, ce qui garantit l'interopérabilité indépendamment des détails de la mise en œuvre. Cette architecture distribuée offre une certaine souplesse dans la manière dont les systèmes sont construits et déployés, ce qui permet aux organisations de combiner les agents et les infrastructures les mieux adaptés à leurs besoins spécifiques.
Il s'agit de l'architecture finale de l'application de la salle de presse :

Section 3 : Protocole de contexte de modèle (PCM)
Définition et objectif
Le Model Context Protocol (MCP) est un protocole standardisé développé par Anthropic pour améliorer et renforcer un LLM individuel avec des outils, des ressources et des invites définis par l'utilisateur, ainsi que d'autres ajouts supplémentaires à la base de code. MCP fournit une interface universelle entre les modèles linguistiques et les ressources externes dont ils ont besoin pour accomplir efficacement leurs tâches. Cet article présente l'état actuel du MCP avec des exemples de cas d'utilisation, les tendances émergentes et la propre mise en œuvre d'Elastic.
Concepts de base du MCP
MCP fonctionne selon une architecture client-serveur avec trois composants principaux :
- Clients : applications (comme Claude Desktop ou des applications IA personnalisées) qui se connectent aux serveurs MCP pour accéder à leurs capacités.
- Serveurs: applications qui exposent les ressources, les outils et les messages-guides aux modèles linguistiques. Chaque serveur est spécialisé dans l'accès à des capacités ou à des sources de données spécifiques.
- Outils: fonctions définies par l'utilisateur que les modèles peuvent invoquer pour effectuer des actions, telles que la recherche dans des bases de données, l'appel à des API externes ou l'exécution de transformations sur les données.
- Ressources : sources de données que les modèles peuvent lire, servies avec des données dynamiques ou statiques, et accessibles via des modèles d'URI (similaires aux routes REST).
- Invitations : modèles d'invitations réutilisables avec des variables qui guident le modèle dans l'accomplissement de tâches spécifiques.
Modèle demande-réponse
MCP suit un modèle d'interaction demande-réponse familier, similaire aux API REST. Le client (LLM) demande une ressource ou invoque un outil, puis le serveur MCP traite la demande et renvoie le résultat, que le LLM utilise pour poursuivre sa tâche. Ce modèle centralisé avec des serveurs périphériques offre un modèle d'intégration plus simple que la communication d'agent pair à pair.
MCP dans la salle de presse
Dans notre exemple de salle de presse, les agents individuels utilisent des serveurs MCP pour accéder aux outils et aux données dont ils ont besoin :
- Le chercheur utilise l'agent:
- Serveur MCP News API (accès aux bases de données d'actualités)
- Fact-Checking MCP Server (vérification des affirmations par rapport à des sources fiables)
- Base de données académique MCP Server (articles et recherches universitaires)
- Utilisation de l'agent rapporteur:
- Guide de style MCP Server (normes de rédaction des salles de presse)
- Serveur de modèles MCP (modèles et formats d'articles)
- Bibliothèque d'images MCP Server (photos d'archives et graphiques)
- L'éditeur utilise l'agent:
- Grammar Checker MCP Server (outils de qualité linguistique)
- Serveur MCP de détection du plagiat (vérification de l'originalité)
- Analyse SEO MCP Server (optimisation des titres et des mots-clés)
- L'agent éditeur utilise :
- Serveur CMS MCP (système de gestion de contenu API)
- Serveur CI/CD MCP (pipeline de déploiement)
- Serveur Analytics MCP (suivi et contrôle)

Section 4 : comparaison des architectures
Quand utiliser A2A
L'architecture A2A excelle dans les scénarios nécessitant une véritable collaboration multi-agents. Les flux de travail à plusieurs étapes nécessitant une coordination bénéficient grandement de l'A2A, en particulier lorsque les tâches impliquent plusieurs étapes séquentielles ou parallèles, les flux de travail nécessitant une itération et un affinement, et les processus avec des points de contrôle et des besoins de validation. Dans notre exemple de salle de presse, le flux de travail de l'article exige que le journaliste écrive, mais il peut être nécessaire de revenir au chercheur si la confiance en certains faits est faible, puis de passer au rédacteur en chef et enfin à l'éditeur.
La spécialisation spécifique à un domaine est un autre cas d'utilisation important de l'A2A. Lorsque plusieurs experts dans différents domaines sont nécessaires pour accomplir une tâche plus importante, chaque agent apportant une connaissance approfondie du domaine et des capacités de raisonnement spécialisées pour différents aspects, A2A fournit le cadre de coordination nécessaire pour établir ces connexions. La salle de rédaction en est un parfait exemple : le chercheur se spécialise dans la collecte d'informations, le journaliste dans la rédaction et le rédacteur en chef dans le contrôle de la qualité, chacun ayant une expertise distincte.
La nécessité d'un comportement autonome des agents rend l'A2A particulièrement utile. Les agents capables de prendre des décisions indépendantes, d'adopter un comportement proactif en fonction de l'évolution des conditions et de s'adapter de manière dynamique aux exigences du flux de travail s'épanouissent dans une architecture A2A. L'échelonnement horizontal des fonctions spécialisées est un autre avantage clé : plutôt que d'avoir un seul maître à tout faire, plusieurs agents spécialisés travaillent en coordination, et plusieurs instances du même agent peuvent gérer des tâches secondaires de manière asynchrone. Dans notre salle de presse, par exemple, lors d'une nouvelle de dernière minute, plusieurs agents de Reporter peuvent travailler simultanément sur différents aspects d'un même sujet.
Enfin, les tâches nécessitant une véritable collaboration multi-agents sont idéales pour l'A2A. Cela inclut les mécanismes d'évaluation du LLM en tant que jury, les systèmes de consensus et de vote, et la résolution collaborative de problèmes où de multiples perspectives sont nécessaires pour atteindre le meilleur résultat.
Quand utiliser MCP
Le protocole de contexte de modèle est idéal pour étendre les capacités d'un modèle d'IA unique. Lorsqu'un modèle d'IA unique doit accéder à plusieurs outils et sources de données, MCP fournit la solution parfaite avec un raisonnement centralisé associé à des outils distribués et à une intégration simple des outils. Dans notre exemple de salle de presse, l'agent chercheur (un modèle) doit avoir accès à plusieurs sources de données, notamment l'API des actualités, les services de vérification des faits et les bases de données universitaires, toutes accessibles par l'intermédiaire de serveurs MCP normalisés.
L'intégration d'outils normalisés devient une priorité lorsque le partage et la réutilisation des intégrations d'outils sont importants. MCP se distingue ici par son écosystème de serveurs MCP préconstruits qui réduisent considérablement le temps de développement pour les intégrations courantes. Lorsque la simplicité et la facilité de maintenance sont requises, les modèles demande-réponse de MCP sont familiers aux développeurs, plus faciles à comprendre et à déboguer que les systèmes distribués, et leur complexité opérationnelle est moindre.
Enfin, le MCP est souvent proposé par les fournisseurs de logiciels pour faciliter la communication à distance avec leurs systèmes. Ces serveurs MCP proposés par les fournisseurs réduisent considérablement le temps d'intégration et de développement tout en offrant une interface standardisée avec les systèmes propriétaires, ce qui rend l'intégration beaucoup plus simple que le développement d'API personnalisées.
Quand utiliser les deux (A2A ❤️'s MCP)
De nombreux systèmes sophistiqués bénéficient de la combinaison d'A2A et de MCP, comme l'indique la documentation d'A2A sur l'intégration de MCP. Les systèmes nécessitant à la fois une coordination et une normalisation sont des candidats idéaux pour une approche hybride. A2A s'occupe de la coordination des agents et de l'orchestration du flux de travail, tandis que MCP permet aux agents individuels d'accéder aux outils. Dans notre exemple de salle de presse, les agents se coordonnent via A2A, le flux de travail passant du journaliste au chercheur, puis au rédacteur en chef et à l'éditeur. Cependant, chaque agent utilise des serveurs MCP pour ses outils spécialisés, ce qui crée une séparation architecturale nette.
Plusieurs agents spécialisés, chacun utilisant MCP pour l'accès aux outils, représentent un modèle commun où il y a une couche de coordination des agents gérée par A2A et une couche d'accès aux outils gérée par MCP. Cette séparation claire des préoccupations rend les systèmes plus faciles à comprendre et à entretenir.
Les avantages de la combinaison de ces deux approches sont considérables. Vous bénéficiez des avantages organisationnels des systèmes multi-agents, notamment la spécialisation, l'autonomie et le traitement parallèle, tout en profitant de la normalisation et des avantages de l'écosystème du MCP, tels que l'intégration des outils et l'accès aux ressources. Il existe une séparation claire entre la coordination des agents (A2A) et l'accès aux ressources (MCP) et, surtout, l'A2A n'est pas nécessaire pour les petites tâches telles que l'accès à l'API uniquement - MCP les gère efficacement sans les frais généraux de l'orchestration multi-agents.
FAQ : A2A vs. MCP - Cas d'utilisation
| Fonctionnalité | Agent2Agent (A2A) | Protocole de contexte de modèle (MCP) | Hybride (A2A + MCP) |
|---|---|---|---|
| Objectif principal | Coordination multi-agents : Permet à une équipe d'agents spécialisés de travailler ensemble sur des flux de travail complexes à plusieurs étapes. | Amélioration de l'agent unique : Extension des capacités d'un seul LLM/Agent à l'aide d'outils, de ressources et de données externes. | Une force combinée : A2A gère le flux de travail de l'équipe, tandis que MCP fournit des outils à chaque membre de l'équipe. |
| Exemple d'équipe de salle de presse | La chaîne de travail : Chef de l'information → Reporter → Chercheur → Rédacteur en chef → Éditeur. Il s'agit de la couche de coordination. | Outils individuels de l'agent : L'agent rapporteur accède au serveur de guides de style et au serveur de modèles (via MCP). Il s'agit de la couche d'accès aux outils. | Le système complet : Le journaliste se coordonne avec le rédacteur en chef (A2A) et le journaliste utilise le serveur MCP de la bibliothèque d'images pour trouver un graphique pour l'article. |
| Quand utiliser quoi ? | Lorsque vous avez besoin d'une véritable collaboration, d'une itération et d'un perfectionnement, ou d'une expertise spécialisée répartie entre plusieurs agents. | Lorsqu'un agent unique a besoin d'accéder à plusieurs outils et sources de données ou nécessite une intégration standardisée avec des systèmes propriétaires. | Lorsque vous avez besoin des avantages organisationnels des systèmes multi-agents et des avantages de normalisation et d'écosystème du MCP. |
| Prestations de base | Autonomie et mise à l'échelle : Les agents peuvent prendre des décisions indépendantes et le système permet une mise à l'échelle horizontale des fonctions spécialisées. | Simplicité et normalisation : Le raisonnement centralisé facilite le débogage et la maintenance et fournit une interface universelle pour les ressources. | Séparation claire des préoccupations : Facilite la compréhension du système : A2A = travail d'équipe, MCP = accès aux outils. |

Conclusion
Il s'agit de la première section de deux articles couvrant la mise en œuvre d'agents basés sur A2A et renforcés par des serveurs MCP pour fournir un support et un accès externe aux données et aux outils. La prochaine partie explorera le code réel pour démontrer qu'ils travaillent ensemble afin d'émuler les activités d'une salle de rédaction en ligne. Bien que les deux cadres soient extrêmement compétents et flexibles, vous verrez à quel point ils se complètent lorsqu'ils travaillent en tandem.




