L’équipe .NET de Microsoft, en collaboration avec CopilotKit, a annoncé un SDK officiel .NET pour le protocole AG-UI, une norme qui définit la manière dont les agents d’intelligence artificielle communiquent avec les applications et les interfaces destinées aux utilisateurs. Le paquet a été publié dans le dépôt AG-UI aux côtés des paquets TypeScript et Python, et il est disponible via NuGet sous licence MIT.
Le changement pratique est que tout service .NET peut désormais communiquer directement via AG-UI, sans dépendre d’une implémentation propre à un framework d’agents donné. La prise en charge d’AG-UI dans Microsoft Agent Framework, connu sous l’abréviation MAF, repose également désormais sur les nouveaux paquets SDK.
Qu’ajoute le paquet ?
AG-UI vise à résoudre un problème courant dans les applications utilisant des agents de longue durée. Les agents peuvent envoyer progressivement des jetons, appeler des outils, déléguer des tâches à des sous-agents ou modifier l’état de l’application pendant l’exécution de la requête. En l’absence de protocole commun, les interfaces frontales doivent comprendre des formats d’événements différents pour chaque framework ou service.
Le protocole transforme ces interactions en événements typés, parmi lesquels RUN_STARTED, TEXT_MESSAGE_CONTENT, STATE_DELTA et RUN_FINISHED. Le client décide de la manière de les afficher, que ce soit dans une application web, un terminal, une application mobile ou des plateformes de conversation comme Slack et Teams.
Prise en charge du serveur et du client
Le paquet comprend deux volets complémentaires. AGUI.Server transforme l’agent en point de terminaison compatible avec AG-UI, tandis que AGUI.Client permet à une application .NET de se connecter à tout agent prenant en charge le protocole. L’intégration repose sur IChatClient, la couche d’abstraction dédiée aux conversations au sein de Microsoft.Extensions.AI.
Côté serveur, la fonction ToChatRequestContext décompose la requête AG-UI entrante en messages et options attendus par le client, puis AsAGUIEventStreamAsync transforme le flux de réponse en événements du protocole. Cette conversion crée également les événements de début et de fin d’exécution, et ferme les blocs de texte ou de raisonnement ouverts avant de passer à un autre message ou appel d’outil.
Les utilisateurs de Microsoft Agent Framework peuvent quant à eux s’appuyer sur l’intégration ASP.NET Core, qui fournit les fonctions AddAGUIServer() et MapAGUIServer() afin de réduire le code de configuration du point de terminaison.
Composants du SDK et compatibilité
Le paquet se compose de cinq composants publiés via NuGet :
- AGUI.Abstractions : modèles du protocole pour les événements, les messages, les outils, l’état et les interruptions.
- AGUI.Formatting : formatage des données sur le réseau, avec prise en charge de Server-Sent Events par défaut.
- AGUI.Protobuf : prise en charge facultative de Protobuf couvrant un sous-ensemble des types d’événements.
- AGUI.Client : consommation de flux AG-UI.
- AGUI.Server : production de flux AG-UI.
SSE reste le format par défaut et prend en charge tous les types d’événements mentionnés dans le SDK, tandis que la prise en charge de Protobuf se limite à un sous-ensemble.
Qu’est-ce qui change pour les utilisateurs d’Agent Framework ?
Le modèle de programmation de base ne change pas pour les utilisateurs actuels, et le format des événements reste compatible, ce qui signifie que les interfaces frontales existantes peuvent continuer à fonctionner avec un serveur mis à niveau. Toutefois, certains noms d’interfaces ont changé : AddAGUIServer() et MapAGUIServer() remplacent AddAGUI() et MapAGUI(), tandis que les espaces de noms et les classes ont été transférés vers les paquets AGUI.Client, AGUI.Server et AGUI.Abstractions.
Le client prend en charge la consommation d’AG-UI à partir de .NET Framework 4.7.2 et des versions ultérieures, tandis que l’exposition du point de terminaison nécessite une version actuelle de .NET.
Pourquoi cette annonce est-elle importante ?
Cette publication offre aux services .NET une voie unifiée pour gérer plusieurs interfaces sans reconstruire une couche de diffusion des événements pour chaque application. Elle permet également d’alterner entre des composants écrits en C#, Python et TypeScript, tout en maintenant une couche d’intégration fondée sur IChatClient. Cela revêt une importance accrue pour les entreprises qui souhaitent connecter un même agent à des interfaces web, des applications internes ou différents canaux de conversation.
Le SDK ne supprime toutefois pas la nécessité de construire le serveur ou de choisir la manière d’afficher les événements : il prend en charge le protocole, tandis que l’architecture web et le point de terminaison restent sous la responsabilité de l’application. De plus, la prise en charge de Protobuf ne couvre pas tous les événements, raison pour laquelle SSE demeure l’option complète par défaut.