Série Agent Gateway (partie 3 de 7) | A2A alimenté par TrueFoundry : standardisation du monologue interne

Au début des années 2010, la révolution des microservices s'est heurtée à un mur. Nous avions divisé nos monolithes en centaines de services, mais nous ne nous étions pas mis d'accord sur la manière dont ils devaient parler. Certaines équipes ont utilisé REST, d'autres XML-RPC, d'autres le TCP brut. Le résultat a été une « Tour de Babel », un écosystème fragmenté où l'intégration était difficile et l'observabilité impossible.

L'industrie a résolu ce problème grâce à la standardisation : grPC pour le transport, Protobuf pour le schéma, et OpenTelemetry pour l'observabilité.

Aujourd'hui, le IA agentique L'écosystème se trouve exactement dans ce chaos d'avant la standardisation.

• Votre équipe de science des données développe des « agents de raisonnement » dans Python utilisant LangChain.
• Votre équipe Frontend développe des « assistants d'interface utilisateur » dans Node.js utilisant le SDK Vercel AI.
• Votre équipe R&D expérimente Microsoft AutoGen essaims.

Ces agents ne peuvent naturellement pas collaborer. Ils ont des représentations d'état différentes, des mécanismes de gestion des erreurs différents et aucun concept d'identité commun.

Pour résoudre ce problème, TrueFoundry introduit le support pour Protocole A2A (agent à agent). Il s'agit d'une couche de transport stricte qui normalise la communication, transformant une collection fragmentée de scripts en un ensemble unifié Maillage cognitif.

Le concept de base : l'enveloppe A2A

L'erreur fondamentale de la plupart des premières conceptions d'agents est de traiter la communication agent-agent comme un simple appel d'API (POST /chat {« prompt » : «... »}). C'est insuffisant car il manque Métacognition.

Un agent n'a pas seulement besoin du texte du message. Il a besoin de savoir :

1. Qui Tu as dit ça ? (Identité)
2. Pourquoi C'est ce que nous faisons ? (Traçabilité)
3. Peut J'ai les moyens de répondre ? (Budget)

Le protocole A2A résout ce problème en encapsulant chaque interaction dans un Enveloppe. Nous traitons la logique métier de l'agent (l'invite) comme Charge utile, mais nous l'enveloppons dans un emballage rigide Plan de contrôle.

‍

Figure 1 : Enveloppe A2A de sa structure sous-jacente

Lisez également : MCP contre A2A

Un exemple concret : la salle des transactions « fusions et acquisitions »

Pour illustrer la puissance de ce protocole, examinons un scénario complexe à plusieurs piles : Système de due diligence en matière de fusions et acquisitions.

Ce système nécessite trois agents hautement spécialisés qui utilisent des technologies complètement différentes :

1. Le responsable de la transaction (directeur) : Intégré Python/LangChain. Il orchestre le processus.
2. Le réviseur juridique : Intégré Node.js. Il utilise des bibliothèques spécialisées pour analyser les contrats PDF.
3. Le juricomptable : Construit comme L'équipe Microsoft AutoGen. Il organise un débat multi-agents pour détecter les fraudes dans les feuilles Excel.

Le défi de l'interopérabilité

Sans protocole, le Python Manager ne peut pas facilement déclencher l'équipe AutoGen. AutoGen s'attend à un format d'historique des conversations spécifique, tandis que LangChain s'attend à une « chaîne ». Si le Legal Reviewer (Node) génère une erreur, le Python Manager peut l'interpréter comme une hallucination plutôt que comme une défaillance du système.

La solution A2A

1. Normalisation : Le responsable de la transaction envoie un message A2A standard : Tâche : « Analyser les données financières cibles ».
2. Routage : Le Gateway le reçoit. Il sait que le « juricomptable » est un essaim d'AutoGen.
3. Traduction : The Gateway Adaptateur de protocole convertit le JSON A2A dans le format de message user_proxy spécifique requis par AutoGen.
4. Injection contextuelle : La passerelle injecte le jeton autorisé par la NDA dans le contexte, prouvant au comptable qu'il est autorisé à consulter les fichiers Excel sensibles.

‍

Figure 2 : Le déroulement détaillé d'un processus de révision juridique

‍

Le modèle de routage Hub-and-Spoke

Dans un maillage d'agents poste à poste, l'agent A appelle directement l'agent B. C'est dangereux car cela nuit à l'observabilité et à la sécurité. Si l'agent A est compromis, il peut inonder l'agent B de demandes, et personne ne le saura avant l'arrivée de la facture.

Le protocole A2A applique un Hub-and-Spoke modèle.

• Pas de liens directs : Les agents ne sont pas autorisés à se parler directement. Ils s'adressent à la passerelle.
• L'intermédiaire de confiance : La passerelle valide l'enveloppe. Cela garantit la présence du trace_id. Il vérifie le budget_remaining.
• Le « spoof proof » : Étant donné que la passerelle injecte le contexte d'identité, l'agent B sait que la demande vraiment provenait du Deal Lead, et non d'un acteur malveillant prétendant être le principal acteur.

‍

Traçage distribué : le « Thought Stack »

Le débogage d'un seul LLM est difficile. Le débogage d'une chaîne récursive de 5 agents est impossible sans traçage distribué.

Lorsque le « responsable de la transaction » ne parvient pas à conclure l'opération de fusion et d'acquisition, vous devez savoir pourquoi. Y a-t-il eu un délai d'attente pour l'agent juridique ? Le juricomptable n'a-t-il plus de jetons ?

Les mandats du protocole A2A Propagation d'en-tête. Lorsque la passerelle reçoit la demande initiale, elle génère un TraceID. Cela oblige chaque agent en aval à inclure cet identifiant dans ses sous-appels.

Cela nous permet de visualiser « Thought Stack »—un diagramme de Gantt temporel de la cognition. Nous pouvons constater que l'agent juridique a pris 45 secondes (problème de latence) alors que le comptable a pris 2 secondes.

Figure 3 : Diagramme de Gantt de cette opération de fusion et acquisition

‍

L'agnosticisme du framework : l'adaptateur universel

Le dernier élément du protocole A2A est le Adaptateur universel.

Nous reconnaissons que les développeurs utiliseront toujours des outils différents. Certains adorent LangGraph pour son contrôle ; d'autres préfèrent CrewAI pour ses fonctionnalités de jeu de rôle.

Le Gateway agit comme Couche de traduction.

• Entrant : Il accepte la sortie native de ces frameworks (par exemple, un LangChain AIMessage).
• Normalisation : Il le convertit en JSON standard A2A.
• Sortant : Il le convertit dans le format d'entrée attendu par le récepteur.

Cela vous permet de créer un Maille d'agents hétérogènes. Vous n'êtes pas bloqué dans une seule bibliothèque Python. Vous pouvez choisir le meilleur outil pour le travail de chaque agent spécifique et laisser le Protocole gérer la communication.

Conclusion

La standardisation est la condition préalable à la mise à l'échelle. Tout comme le protocole TCP/IP permettait à Internet de connecter différents ordinateurs, le Protocole A2A de plus, les fonctionnalités de passerelle d'agent TrueFoundry AI permettent à l'entreprise de connecter différentes intelligences. Il transforme une collection de « chatbots » en un outil coordonné, observable et sécurisé Main-d'œuvre numérique.

‍