L'Architecture Émergente des Agents IA

Le paysage numérique évolue au-delà de la navigation Web centrée sur l’humain vers un royaume d’agents autonomes collaborant de manière transparente à travers divers systèmes. Ce changement nécessite une infrastructure nouvelle, et une solution convaincante prend forme, comprenant quatre composantes clés open source.

• Agent2Agent (A2A) de Google : Un protocole conçu pour faciliter la découverte et l’interaction des agents.
• Model Context Protocol (MCP) d’Anthropic : Une norme définissant comment les agents utilisent les outils et les données contextuelles externes.
• Apache Kafka : Une colonne vertébrale de communication robuste, axée sur les événements, permettant une coordination fiable et découplée.
• Apache Flink : Un moteur de traitement en temps réel, essentiel pour enrichir, surveiller et agir sur les flux d’activité des agents.

Cet article explore les relations synergiques entre ces technologies, soulignant les limites de la confiance exclusive dans les protocoles et démontrant comment cette architecture jette les bases du passage des bots isolés à des écosystèmes d’agents dynamiques et intelligents.

La prolifération anticipée des agents d’IA au sein des organisations suggère que la plupart des entreprises déploieront une multitude d’agents spécialisés plutôt qu’un seul agent global. Ces agents automatiseront des tâches telles que la génération de code, la gestion des tickets de support, l’analyse des données clients, l’intégration des employés et la surveillance de l’infrastructure.

Cependant, les outils actuels sont inadéquats pour soutenir un tel avenir.

Le défi s’étend au-delà du problème de l’’île des agents’, où les agents fonctionnent en silos et manquent de capacités de communication. Il englobe une fragmentation plus étendue de l’écosystème :

• Manque de communication inter-agents : Les agents fonctionnent généralement dans des environnements isolés. Un agent de gestion de la relation client (CRM) n’est pas au courant des informations obtenues par un agent d’entrepôt de données. Un agent de support ne peut pas répondre aux anomalies détectées par un agent de surveillance.
• Utilisation fragile et personnalisée des outils : Sans méthodes standardisées pour accéder aux outils ou aux interfaces de programmation d’applications externes (API), les agents s’appuient sur des intégrations codées en dur et une logique non réutilisable.
• Cadres incohérents : Différents environnements d’exécution d’agents utilisent divers modèles, traitant les agents comme des chatbots, des graphes acycliques dirigés (DAG) ou des planificateurs récursifs. Il en résulte l’absence d’une couche d’exécution portable ou d’un état partagé.
• Conception axée sur les environnements de notebook : De nombreux agents sont développés comme des prototypes ponctuels, caractérisés par des opérations linéaires, synchrones et éphémères. Cependant, les systèmes du monde réel nécessitent une gestion robuste des nouvelles tentatives, des échecs, de la coordination, de la journalisation et de la mise à l’échelle, ce qui nécessite une infrastructure de support.
• Absence d’une colonne vertébrale collaborative : Il n’y a pas de bus d’événements, de mémoire partagée ou d’historique traçable des activités et du raisonnement des agents. Les informations sont confinées aux appels HTTP directs ou enfouies dans les journaux.

Comme souligné par le projet 12-Factor Agents, les agents doivent adhérer aux principes natifs du cloud, en présentant une observabilité, un couplage lâche, une reproductibilité et une connaissance de l’infrastructure. Malheureusement, la majorité sont construits comme des scripts fragiles, assemblés manuellement et supposés fonctionner indépendamment.

Il en résulte des inefficacités, une duplication des efforts et une fragilité.

Agent2Agent aborde partiellement ce problème en fournissant aux agents un protocole standardisé pour la découverte et la communication. Cependant, passer des démonstrations superficielles à l’évolutivité et à la fiabilité exigées par les systèmes de production nécessite plus que de simples protocoles. Cela nécessite une infrastructure complète.

L’écosystème actuel des agents reflète les premières étapes du Web, caractérisées par des systèmes puissants mais isolés et incompatibles. Semblables aux premiers défis rencontrés par les navigateurs communiquant avec les serveurs sans protocole standard, les agents d’IA d’aujourd’hui ont du mal à se découvrir, à communiquer et à collaborer efficacement les uns avec les autres.

Agent2Agent (A2A) de Google : Un protocole universel pour la communication des agents

Le protocole A2A de Google est une tentative importante pour résoudre ce problème. Il se distingue en n’étant pas un autre framework d’agent, mais plutôt un protocole universel conçu pour connecter n’importe quel agent, quelle que soit son origine ou son environnement de déploiement.

De la même manière que HTTP a standardisé la communication des sites Web, A2A définit un langage commun pour les agents, leur permettant de :

• Annoncer les capacités : Via une AgentCard, un descripteur JSON qui décrit les capacités d’un agent et les méthodes d’interaction.
• Envoyer et recevoir des tâches : Grâce à des interactions structurées utilisant JSON-RPC, où un agent demande de l’aide et un autre répond avec des résultats ou des ‘artefacts’.
• Diffuser des mises à jour avec Server-Sent Events (SSE) : Faciliter le feedback en temps réel pendant les tâches longues ou collaboratives.
• Échanger du contenu enrichi : Prendre en charge l’échange de fichiers, de données structurées et de formulaires, au-delà du simple texte.
• Maintenir la sécurité par défaut : Intégrer une prise en charge intégrée de HTTPS, de l’authentification et des autorisations.

La force d’A2A réside dans son évitement de réinventer des solutions établies. Il exploite des normes Web bien établies, similaires à HTTP et SMTP, facilitant ainsi l’adoption et l’intégration plus rapides.

Cependant, A2A ne représente qu’un aspect de la solution globale.

Model Context Protocol (MCP) d’Anthropic : Standardisation de l’utilisation des outils et de l’accès au contexte

Le MCP d’Anthropic aborde l’aspect crucial de la façon dont les agents utilisent les outils et accèdent aux informations contextuelles. MCP standardise le processus par lequel les agents invoquent des API, appellent des fonctions et s’intègrent aux systèmes externes, définissant essentiellement la façon dont ils opèrent dans leur environnement. Alors qu’A2A régit la communication inter-agents, MCP se concentre sur l’interaction d’un agent avec le monde extérieur.

En substance :

• MCP renforce l’intelligence de l’agent individuel.
• A2A permet l’intelligence collective.

De la même manière que HTTP et SMTP nécessitaient une adoption, une infrastructure et des outils de développement étendus pour atteindre un succès généralisé, A2A et MCP auront besoin d’un écosystème robuste pour réaliser pleinement leur potentiel.

Même avec les efforts de standardisation comme A2A et MCP, une question critique persiste : comment les communications des agents peuvent-elles être efficacement mises à l’échelle dans des environnements d’entreprise complexes et dynamiques ? Le fait de s’appuyer uniquement sur des connexions directes point à point définies par ces protocoles introduit des défis liés à l’évolutivité, à la résilience et à l’observabilité. Cela souligne la nécessité d’une infrastructure de communication sous-jacente robuste.

Imaginez une entreprise où les employés ne peuvent communiquer que par le biais de messages directs individuels. Le partage d’une mise à jour nécessiterait l’envoi de messages à chaque individu séparément. La coordination d’un projet entre plusieurs équipes impliquerait de relayer manuellement les informations entre chaque groupe.

La mise à l’échelle d’un tel système à des centaines d’employés entraînerait le chaos.

Ce scénario reflète les défis rencontrés dans les écosystèmes d’agents construits sur des connexions directes. Chaque agent doit savoir quels agents contacter, comment les joindre et leur disponibilité. À mesure que le nombre d’agents augmente, le nombre de connexions requises augmente de façon exponentielle, ce qui entraîne un système fragile, difficile à gérer et non évolutif.

A2A et MCP fournissent aux agents le langage et la structure pour la communication et l’action. Cependant, le langage seul est insuffisant. Pour coordonner de nombreux agents au sein d’une entreprise, une infrastructure est nécessaire pour gérer le flux de messages et les réponses des agents.

Kafka et Flink : La colonne vertébrale pour une collaboration évolutive des agents

Apache Kafka et Apache Flink fournissent cette infrastructure cruciale.

Kafka et Flink expliqués

Apache Kafka, initialement développé chez LinkedIn et maintenant un projet de la Apache Software Foundation, est une plateforme distribuée de streaming d’événements. Il fonctionne comme un bus de messages durable et à haut débit, permettant aux systèmes de publier et de s’abonner à des flux d’événements en temps réel. Kafka est largement utilisé dans diverses applications, notamment les systèmes financiers, la détection de la fraude et les pipelines de télémétrie, en raison de sa capacité à découpler les producteurs des consommateurs et à assurer la durabilité, la relecture et l’évolutivité des données.

Flink, un autre projet Apache, est un moteur de traitement de flux en temps réel conçu pour le traitement d’événements avec état, à haut débit et à faible latence. Alors que Kafka gère le mouvement des données, Flink gère la transformation, l’enrichissement, la surveillance et l’orchestration des données au fur et à mesure qu’elles circulent dans un système.

Ensemble, Kafka et Flink forment une combinaison puissante. Kafka sert de flux sanguin, tandis que Flink agit comme le système réflexe.

De la même manière que le rôle d’A2A en tant que HTTP du monde des agents, Kafka et Flink fournissent une base axée sur les événements pour la communication et le calcul évolutifs des agents, en relevant les défis que la communication directe point à point ne peut pas relever :

• Découplage : Avec Kafka, les agents n’ont pas besoin de connaître les consommateurs de leur production. Ils publient des événements (par exemple, ‘“TaskCompleted”‘, ‘“InsightGenerated”‘) sur un sujet, permettant à tout agent ou système intéressé de s’abonner.
• Observabilité et relecture : Kafka maintient un journal durable et ordonné dans le temps de tous les événements, garantissant que le comportement de l’agent est entièrement traçable, vérifiable et rejouable.
• Prise de décision en temps réel : Flink permet aux agents de réagir en temps réel aux flux d’événements, en filtrant, en enrichissant, en rejoignant ou en déclenchant des actions en fonction des conditions dynamiques.
• Résilience et mise à l’échelle : Les tâches Flink peuvent être mises à l’échelle indépendamment, récupérer après des échecs et maintenir l’état sur des flux de travail de longue durée, ce qui est essentiel pour les agents effectuant des tâches complexes en plusieurs étapes.
• Coordination native des flux : Au lieu d’attendre des réponses synchrones, les agents peuvent se coordonner via des flux d’événements, en publiant des mises à jour, en s’abonnant à des flux de travail et en faisant progresser l’état de manière collaborative.

En résumé :

• A2A définit la façon dont les agents communiquent.
• MCP définit la façon dont ils interagissent avec les outils externes.
• Kafka définit la façon dont leurs messages circulent.
• Flink définit la façon dont ces flux sont traités, transformés et utilisés pour prendre des décisions.

Les protocoles tels qu’A2A et MCP sont cruciaux pour standardiser le comportement et la communication des agents. Cependant, sans un substrat axé sur les événements comme Kafka et un environnement d’exécution natif des flux comme Flink, les agents restent isolés, incapables de se coordonner efficacement, de mettre à l’échelle efficacement ou de raisonner au fil du temps.

L’architecture à quatre couches pour les agents d’IA de qualité entreprise

Pour réaliser pleinement la vision d’agents d’IA interopérables de qualité entreprise, une architecture à quatre couches est nécessaire :

• Protocoles : A2A, MCP – définissant le quoi.
• Frameworks : LangGraph, CrewAI, ADK – définissant le comment.
• Infrastructure de messagerie : Apache Kafka – prenant en charge le flux.
• Calcul en temps réel : Apache Flink – prenant en charge la pensée.

Ensemble, ces couches forment la nouvelle pile Internet pour les agents d’IA, fournissant une base pour la construction de systèmes quisont non seulement intelligents, mais aussi collaboratifs, observables et prêts pour la production.

Nous sommes actuellement à un point crucial de l’évolution des logiciels.

Tout comme la pile Internet d’origine – composée de protocoles comme HTTP et SMTP et d’infrastructures comme TCP/IP – a inauguré une ère de connectivité mondiale, une nouvelle pile émerge pour les agents d’IA. Cependant, au lieu que des humains naviguent sur des pages Web ou envoient des e-mails, cette pile est conçue pour que des systèmes autonomes collaborent pour raisonner, décider et agir.

A2A et MCP fournissent les protocoles pour la communication des agents et l’utilisation des outils, tandis que Kafka et Flink fournissent l’infrastructure pour la coordination en temps réel, l’observabilité et la résilience. Ensemble, ils permettent la transition des démonstrations d’agents déconnectés vers des écosystèmes évolutifs, intelligents et de qualité production.

Cette évolution ne consiste pas uniquement à relever des défis d’ingénierie. Il s’agit de permettre un nouveau paradigme de logiciels où les agents collaborent au-delà des frontières, fournissant des informations et stimulant des actions en temps réel, permettant ainsi à l’intelligence de devenir un système distribué.

Cependant, cette vision nécessite un développement actif, en mettant l’accent sur l’ouverture, l’interopérabilité et l’exploitation des leçons apprises de la précédente révolution Internet.

Par conséquent, lors du développement d’un agent, il est essentiel de tenir compte de son intégration dans le système plus large. Peut-il communiquer efficacement ? Peut-il se coordonner avec d’autres agents ? Peut-il évoluer et s’adapter aux conditions changeantes ?

L’avenir n’est pas seulement alimenté par les agents ; il est connecté aux agents.