A2A – Un arrêt au-delà de MCP

Auteur (s): Kelvin Lu

Publié à l’origine sur Vers l’IA.

Si vous avez suivi le buzz autour de MCP et passé un peu de temps à explorer ses détails, vous pourriez le voir comme un élément de construction crucial pour les futurs systèmes agentiques. Cependant, vous pourriez également penser que cela ne va pas assez loin. Peut-être que vous le percevez principalement comme un emballage de base pour les services locaux, en le trouvant potentiellement inadéquat pour les besoins à l’échelle de l’entreprise. Pour ceux qui ressentent cela, il y a des nouvelles passionnantes: Google a annoncé leur protocole de communication d’agent à Google ensuite il y a quelques semaines.

MCP Introduction

Entrez le Protocole de contexte du modèle (MCP), introduit par Anthropic comme standard ouvert. Son objectif était de relever le défi croissant de l’obtention LLMS pour bien jouer avec les sources de données externes et les outils. Réfléchissez à ce que c’était: l’intégration d’IA a souvent requis la création de connecteurs personnalisés pour chaque application et la rédaction de nombreux code de plaque de chaudière pour des tâches courantes telles que la mise en forme ou les erreurs de gestion. Cette méthode traditionnelle a souvent conduit à des maux de tête avec une mise à l’échelle, a rendu les données incohérentes et a ouvert la porte à plus de risques de sécurité.

Plus important encore, sans standard, le partage de ces développements était un véritable défi. MCP visait à simplifier tout cela en offrant une interface standardisée, permettant aux applications d’IA d’interagir uniformément avec des outils locaux, des ressources et, bien sûr, des invites.

Pourquoi c’est inadéquat
Malgré ses avantages, MCP fait face à plusieurs limites:

• Capacités d’intégraion limitées: Bien que le protocole ait un plan sur la feuille de route pour fournir une authentification et un chiffrement robustes, mais les implémentations actuelles ne prennent en charge que la communication client-serveur locale.
• Cooperations de tâches complexes: Le protocole MCP est capable d’exposer les services locaux pour que les clients puissent se connecter. Cependant, il n’a pas les capacités de haut niveau pour la communication inter-agents.

Toutes ces limitations signifient que le MCP est le mieux adapté à la construction agents de bas niveau – Considérez-les comme les travailleurs en coulisses qui gèrent spécifique et axé sur les tâches emplois en utilisant des ressources locales.

MCP dans la nature: l’exemple d’agent d’assurance

Imaginez AI génératif Système d’approbation d’assurance. L’agent «Boss» (les utilisateurs interagisse) gère la vue d’ensemble: la planification du flux de travail, les mises à jour de statut et la délégation de tâches à des sous-agents spécialisés. Ces sous-agents sont les vrais MVP ici:

• Agent de contrôle de crédit: Le détective financier.
• Agent de détection de fraude: Le sceptique suspect.
• Agent de tarification: L’assistant de croquette numéro.
• Agent de consolidation des clients: L’expert qui sait qui est qui.

MCP brille ici parce que c’est essentiellement le API du monde de l’agent – Il conclut soigneusement les détails de l’implémentation désordonnés et expose uniquement ce qui est nécessaire, ce qui le rend parfait pour ces tâches de la taille d’une bouchée.

Mais voici la prise…

Bien que MCP soit idéal pour les tâches individuelles, elle lutte avec orchestration. Essayer de construire un agent MCP qui dirige les autres agents – même sur la même machine – est comme des chats d’élevage. Et déploiement distribué? Oubliez ça (pour l’instant). MCP n’a pas rendu ces types de développement plus difficiles qu’auparavant, il n’est tout simplement pas pertinent dans ces scénarios.

Ainsi, bien que MCP résout des maux de tête d’intégration, ce n’est pas la balle magique pour les symphonies complexes et multi-agents. C’est le soliste, pas le chef d’orchestre.

A2A: L’interprète universel

Le protocole d’agent à agent (A2A), introduit par Google, traite d’un écart critique dans les écosystèmes d’IA: flux de travail fragmentés causés par des agents isolés. Contrairement à MCP, qui se concentre sur l’intégration des sources de données, A2A standardise communication inter-agentpermettant la collaboration entre les agents. Les avantages clés comprennent:

• «Cartes d’agent» = cartes de visite AI
  Chaque agent se présente avec un profil JSON soigné (compétences, points de terminaison, exigences d’authentification). Pas plus maladroit «alors… quoi exactement Pouvez-vous faire? conversations.
• Gestion des tâches qui ne vous fantôme pas
  Les mises à jour de statut effacées («Soumis» → «Working» → «Done») Gardez les workflows en synchronisation. Encore mieux? Il gère tâches de longue date (Pensez les heures ou les jours de recherche) avec des rapports de progression en direct – ne vous demandant plus si votre IA vous a oublié.
• Fonctionne avec n’importe quoi (oui, même vidéo)
  Besoin de texte? Formes? Streaming audio? A2A s’en fiche. C’est modalitéafin que les agents puissent négocier comment ils discutent à la volée.
• Sécurité sans mal de tête
  Construit sur HTTP, SSE et JSON-RPCc’est aussi sécurisé que votre API d’entreprise préférée – mais beaucoup plus flexible.

Dans l’annonce par Google de la publication d’A2A, ils ont déclaré que A2A «  compliments MCP  »:

Mise en œuvre

A2A exploite les normes Web existantes pour la compatibilité. Ses capacités sont:

• Découverte des capacités: Les agents peuvent annoncer leurs capacités à l’aide d’une «carte d’agent» au format JSON, permettant à l’agent client d’identifier le meilleur agent qui peut effectuer une tâche et exploiter A2A pour communiquer avec l’agent distant.
• Gestion des tâches: La communication entre un client et un agent distant est orientée vers l’achèvement des tâches, dans laquelle les agents travaillent pour répondre aux demandes de l’utilisateur final. Cet objet «tâche» est défini par le protocole et a un cycle de vie. Il peut être achevé immédiatement ou, pour les tâches de longue durée, chacun des agents peut communiquer pour rester en synchronisation entre eux sur le dernier statut de terminer une tâche. La sortie d’une tâche est connue comme un «artefact».
• Collaboration: Les agents peuvent se envoyer des messages pour communiquer le contexte, les réponses, les artefacts ou les instructions utilisateur.
• Négociation de l’expérience utilisateur: Chaque message comprend des «pièces», qui est un contenu entièrement formé, comme une image générée. Chaque pièce a un type de contenu spécifié, permettant aux agents des clients et distants de négocier le format correct nécessaire et d’inclure explicitement les négociations des capacités d’interface utilisateur de l’utilisateur – EG, IFRAMES, vidéo, formulaires Web, etc.

Contrairement à de nombreux produits Google précédents qui sont fraîchement livrés à partir de laboratoires, A2A est un mouvement stratégique évident. Au premier jour de sa version, Google a annoncé une longue liste d’utilisateurs de l’entreprise percutants. C’est une autre différence clé entre A2A et MCP – A2A a été positionné comme une solution d’entreprise.

Le balayage à travers la longue liste des serveurs MCP contre les partenaires Google contribuant au protocole A2A, il est facile de développer le sentiment que la communauté MCP marque la culture open source: courbe d’apprentissage plus fluide, plus d’options, une communauté plus grande, une qualité variée et un peu de chaos. En revanche, A2A présente un style commercial: plus d’autorité, moins d’options, de meilleure qualité, une communauté plus petite et mieux organisé.

Vous n’avez peut-être jamais choqué par la longueur des catalogues de services A2A comme lorsque vous avez vu la liste des serveurs MCP pour la première fois, mais A2A n’est pas question une option importante dans vos solutions d’entreprise.

Ce qui reste non résolu

La combinaison de A2A et MCP présente une base solide pour la communication des agents, mais leurs limites révèlent des défis plus profonds dans le développement orienté vers l’agent lui-même – pas seulement dans la conception du protocole, mais dans la façon dont nous conceptualisons et architectes des systèmes multi-agents.

Le problème de dénomination: un signe d’immaturité

Considérez la demande d’agent d’approbation de l’assurance: différents agents jouent des rôles distincts et nécessitent différents modèles de conception, mais nous manquons de terminologie standardisée pour les classer. Devrions-nous adopter des termes comme agent managérial contre employé? L’absence d’un vocabulaire partagé souligne à quel point ce champ reste naissant.

Défis critiques dans MCP et A2A

Bien que ces protocoles avancent l’interopérabilité, plusieurs problèmes non résolus nécessitent un examen minutieux:

1. Risques de sécurité dans la sélection des agents
   Les systèmes actuels s’appuient sur les descriptions des points de terminaison pour déterminer la pertinence – une approche naïve vulnérable à l’exploitation. Si un service malveillant se déguise comme légitime, les cadres existants peuvent-ils le rejeter de manière fiable? La sécurité des agents reste une frontière sous-développée, mûre pour de nouveaux vecteurs d’attaque.
2. Ambiguïté dans les descriptions de service
   Contrairement aux API traditionnelles, où les points de terminaison sont explicitement définis par les URL, les demandes d’itinéraire des systèmes agentiques basés sur les descriptions sémantiques. Les définitions de service qui se chevauchent ou vagues risquent de risquer une mauvaise orientation, car les LLM n’ont pas le discernement pour résoudre les conflits entre des offres similaires.
3. Le dilemme de version
   Mlops Des pratiques telles que le déploiement bleu-vert – où plusieurs versions du modèle coexistent – se heurtent avec le manque de protocoles de version d’A2A et MCP. Les clients devraient-ils cache des descriptions de services ou les récupérer dynamiquement par invocation? Aucune des deux approches n’est standardisée, laissant la fiabilité incertaine.
4. Contrôle de la mémoire inadéquat
   La mémoire partagée est une pierre angulaire de la collaboration des agents, mais aucun protocole ne spécifie comment les données sensibles doivent être partitionnées. Un agent juridique peut exiger les détails du contrat, tandis qu’un agent comptable a besoin d’un historique de paiement – mais l’accès croisé doit être restreint. Les implémentations actuelles manquent de gouvernance de la mémoire granulaire.
5. Gestion des erreurs peu claires
   Le logiciel traditionnel définit les erreurs rigidement, mais les systèmes agentiques fonctionnent dans la zone grise. Et si un LLM reçoit des entrées absurdes ou des données insuffisantes? Et si le client veut contester le résultat d’un agent? Les protocoles A2A exalté TAG permet une conversation multi-tours, mais des impasses peuvent survenir si plusieurs agents sont en attente d’une entrée mutuelle.
6. Le déficit de planification
   Certaines implémentations Hardcode Agent Workflows, les réduisant à un comportement déterministe de type chatbot. Les véritables applications agentiques devraient tirer parti des LLM pour la planification dynamique – mais la plupart aujourd’hui échouent de manière imprévisible lors de la déviation des chemins scénarisés. Bien que ce déficit dépasse la portée de l’A2A et du MCP, les futures itérations du protocole doivent s’adapter à un raisonnement de niveau supérieur.

Aller de l’avant

Ces lacunes soulignent que le développement agentique n’est pas seulement un défi technique, mais un changement de paradigme nécessitant de nouvelles philosophies de conception. À mesure que le domaine mûrit, les protocoles doivent évoluer au-delà de la connectivité – vers la sécurité, l’adaptabilité et l’intentionnalité.

Publié via Vers l’IA