Agents IA : les frameworks open source s’adaptent (doucement) aux infrastructures IT

Kagent : Un catalogue agentique pour les projets CNCF

Kagent, publié le 17 mars, se compose d’agents, d’une API déclarative et d’un contrôleur basé sur la version 0.4 d’AutoGen de Microsoft, ainsi que des plugins préintégrés basés sur le protocole open source Model Context Protocol d’Anthropic. Au moment du lancement, des plugins étaient disponibles pour Argo, Helm, Istio, Kubernetes, Prometheus et une base de connaissances d’experts natifs du cloud.

Selon Lin Sun, directrice de l’open source chez Solo.io, l’idée de Kagent est née des missions de conseil répétées des développeurs experts de Solo.io pour aider les clients à mettre en place une infrastructure cloud-native complexe.

« Parfois, lorsque nos ingénieurs en contact avec les clients discutent avec eux, ils n’ont pas la réponse, ce qui nous oblige à faire appel à un expert supplémentaire », explique Lin Sun. « Nous avons commencé à réfléchir à la possibilité de “cloner” certains de ces développeurs de haut niveau afin qu’ils puissent aider plus efficacement notre équipe d’ingénieurs d’assistance, sans que cela ait un impact sur leur travail de développement quotidien, car nous voulons que les humains se concentrent sur l’élaboration de nouvelles fonctionnalités ».

L’objectif du projet est de faire un don à la Cloud Native Computing Foundation, affirme Lin Sun. Là, il servirait de cadre à d’autres projets CNCF pour contribuer à leurs propres « clones » : des agents virtuels pour aider les utilisateurs finaux à effectuer des tâches délicates de configuration, de dépannage, d’observabilité et de sécurité du réseau.

« Nous pensons que le runtime de conteneur et la nature déclarative de Kubernetes permettent aux utilisateurs d’exécuter Kagent facilement partout où Kubernetes est pris en charge. »

Kagent est conçu pour Kubernetes et les projets cloud-native, mais les utilisateurs pourraient l’exécuter en dehors de l’orchestrateur s’ils le souhaitent, anticipe Lin Sun.

« Nous pensons que le runtime de conteneur et la nature déclarative de Kubernetes permettent aux utilisateurs d’exécuter Kagent facilement, partout où Kubernetes est pris en charge », estime-t-elle. « Dans Kubernetes, il suffit de configurer l’autoscaling, les répliques de pods et les tentatives pour augmenter la résilience d’un agent. »

Si Kagent décolle, il pourrait aider à fournir un ensemble standard de connecteurs entre plusieurs grands modèles de langage (LLM) autonomes capables d’utiliser des outils dans plusieurs clouds en utilisant les normes existantes de Kubernetes à Model Context Protocol, selon Paul Nicholson, analyste chez IDC.

« Quiconque peut fournir des frameworks et une cohérence pour aider les entreprises à accélérer ces déploiements et ensuite résoudre cette complexité d’accès aux LLM… est un atout », avance Paul Nicholson.

Les agents enrichissent Dapr Workflow

Entre-temps, un projet CNCF a lancé ce mois-ci son propre framework d’agents IA. Celui-ci présente d’importants recoupements avec AutoGen. Le 12 mars, le projet d’orchestration de microservices Dapr a lancé Dapr Agents. Celui-ci est basé sur une extension de son outil Dapr Workflow créé à l’origine par un chercheur en sécurité de Microsoft.

Lorsque Roberto Rodriguez, aujourd’hui mainteneur principal de Dapr Agents et ex-employé Microsoft, a créé l’extension de Dapr Workflow, AutoGen en était à la version 0.2. Cette version était limitée à un seul environnement et n’était pas destinée à être utilisée en production.

Roberto Rodriguez avait besoin de quelque chose de plus robuste pour l’aider dans la chasse aux menaces. À l’époque, AutoGen se concentrait sur une approche de « conversation de groupe » pour la coordination des agents d’IA plutôt que sur une série d’étapes ordonnées. M. Rodriguez souhaitait mieux contrôler l’ordre dans lequel le système exécutait les tâches. Il a commencé à écrire sa propre librairie Python pour cela, mais il a découvert Dapr Workflow et s’est rendu compte qu’il contenait déjà un cadre pour orchestrer des microservices, y compris des fonctions intégrées d’observabilité et de résilience.

« Dapr a fait ses preuves et a prouvé qu’il pouvait s’adapter », a assuré M. Rodriguez lors d’une réunion hebdomadaire de la communauté Dapr, le 19 mars. « Pour être honnête, la plupart des [frameworks d’agents IA] biens connus sont excellents pour faire des démonstrations. Ils sont incroyables lorsqu’ils vous montrent tout ce qui se passe sur un seul écran, mais si vous voulez découpler tout cela et également être en mesure d’échanger des composants du système agentique avec différents fournisseurs de cloud et différentes bases de données, c’est une autre paire de manches ».

Dapr Workflow, publié en 2024, a ajouté l’orchestration de microservices au cadre d’application distribué, qui a également été créé à l’origine chez Microsoft en 2019 et donné à la CNCF en 2021. Dapr connecte les applications à d’autres éléments d’un environnement IT, tels que les outils de mise en cache et de pipeline de données, par le biais d’un ensemble d’API standard. Workflow ajoute la possibilité de configurer comment et dans quel ordre les workflows de microservices sont exécutés.

Selon Roberto Rodriguez, Dapr contenait la plupart des fondements d’un framework d’agent d’IA, mais avait besoin de quelques ajustements pour mieux s’intégrer aux LLM, tels que des sorties dans certains schémas structurés et la sélection d’outils. Son extension initiale de Dapr Workflow, appelée Floki, est maintenant devenue Dapr Agents avec des mises à jour des autres mainteneurs de Dapr.

Dapr Agents ajoute un nouvel objet agent à Dapr Workflow. Cet agent est un processus long qui choisit les outils pour différentes tâches et analyse les résultats des autres agents. Il évite ainsi de coder les étapes du workflow à l’avance.

« Kubernetes est un choix évident pour exécuter des agents, [...] mais il manque des outils de gestion aux agents, une surveillance de la sécurité et des interactions LLM. Dapr est donc un choix naturel. »

Dapr Agents élargit les chaînes de tâches ordonnées de Floki. Il prend en charge les modèles de workflow d’IA en groupe, les modèles fan-in et fan-out, ou des combinaisons de plusieurs modèles. Ces patterns sont gérés comme un seul workflow logique dans Dapr. Cela inclut l’infrastructure d’origine, les API de services, les fonctionnalités de résilience, et les métriques intégrées pour la surveillance.

« Kubernetes est un choix évident pour exécuter des agents, car il est déclaratif et offre automatisation et observabilité », déclare Steve Deng. « Mais il manque des outils de gestion aux agents, une surveillance de la sécurité et des interactions LLM. Dapr est donc un choix naturel ».

Du fait de sa jeunesse et de son lien avec une technologie émergente, Dapr Agents a des limites, selon Mark Fussell, co-créateur de Dapr, fondateur et PDG de Diagrid. Cette startup fondée en 2021 héberge des services managés Kubernetes et Dapr.

« Il s’agit encore d’un projet préliminaire, et seulement d’un SDK dans Python. […] D’ici quelques mois, nous souhaitons que tous les SDK et le runtime aient une syntaxe d’agent à travers Java, .NET, Python, JavaScript et Go », anticipe Ken Fussell lors d’une interview avec Informa TechTarget. « Comme Dapr Workflow, Agents sera multilingue ».

Semantic Kernel va-t-il s’imposer ?  

Depuis que Roberto Rodriguez a commencé à travailler sur Floki, Microsoft a intégré un projet précédemment séparé, le Semantic Kernel Process Framework (SKPF). Il a été introduit dans AutoGen 0.4, publié en janvier. Cette intégration a permis de renforcer l’évolutivité, la résilience, l’orchestration des flux de travail et l’intégration avec des applications d’entreprise. Une solution plus proche de Dapr Agents.

En fait, les premières démonstrations de SKPF incluaient des intégrations avec Dapr open source ainsi qu’avec le framework de systèmes distribués Microsoft Orleans. Microsoft a continué à vanter la compatibilité avec Dapr dans un billet de blog sur la feuille de route d’AutoGen 0.4 ce mois-ci. Une question GitHub est ouverte dans le dépôt AutoGen de Microsoft concernant la coordination des efforts avec la communauté Dapr, mais elle montre peu d’activité.

« La communauté Dapr n’est pas engagée avec Microsoft sur SKPF », a déclaré M. Fussell dans un courriel adressé à Informa TechTarget la semaine dernière. « SKPF pourrait, comme les agents Dapr, s’appuyer sur les API Dapr… mais il semble aussi qu’ils aient construit leur propre gestion des processus pour les états ». Au moment d’écrire ces lignes, Microsoft n’a pas répondu à la demande de la rédaction.