Microsoft Agent Framework : un agent en cinq étapes

Semantic Kernel et AutoGen ont cessé d'être deux chemins. Microsoft les a fusionnés en un seul SDK (SDK : la boîte à outils de bibliothèques avec laquelle vous programmez contre un service) : Microsoft Agent Framework, créé par les mêmes équipes que les deux, avec le meilleur de chacun dedans et des workflows à base de graphes au-dessus pour orchestrer plusieurs agents de façon explicite. Le module Microsoft Learn « Develop an Azure AI agent with Microsoft Agent Framework » le présente en construisant un agent contre Microsoft Foundry. Ce post le parcourt entièrement : ce qu'est le framework, comment on construit un agent en cinq étapes, où vit la mémoire de la conversation et comment fonctionnent les outils.

Ce qu'est Microsoft Agent Framework

C'est le SDK unifié issu de la fusion du meilleur de Semantic Kernel et d'AutoGen. D'AutoGen il prend les abstractions d'agent simples : peu de pièces pour définir quelque chose qui converse et agit. De Semantic Kernel il prend l'entreprise : gestion d'état basée sur session, sûreté de type (les erreurs de type se détectent avant de tourner, pas en production), filtres d'exécution (des points où le framework peut freiner, journaliser ou transformer un appel avant qu'il passe), middleware (couches intermédiaires qui filtrent, journalisent ou ajustent chaque appel qui passe) et télémétrie (métriques de ce que l'agent fait pendant qu'il tourne). Et il ajoute une pièce nouvelle : des workflows à base de graphes, pour quand l'orchestration de plusieurs agents doit être explicite et visible.

En dessous, les blocs sont modulaires : clients de modèles, sessions d'agent, fournisseurs de contexte pour la mémoire, outils de fonction avec génération de schémas, clients MCP (Model Context Protocol, le standard par lequel un assistant reçoit des outils externes) pour la découverte dynamique, middleware et orchestration de workflows. Chaque bloc fait un métier et se compose avec les autres.

Reste une question honnête : ce que le framework apporte au-delà d'utiliser Semantic Kernel ou AutoGen séparément. La réponse est dans le mélange : les abstractions simples de l'un, les caractéristiques d'entreprise de l'autre, et les workflows à base de graphes qu'il ajoute à la combinaison.

Un seul contrat : la classe Agent

Tout agent dérive d'une classe de base unifiée, Agent. C'est la fermeture de la bifurcation : deux SDK nés séparés, aujourd'hui avec une seule porte d'entrée. La conséquence est pratique : l'interface est la même quel que soit le fournisseur du modèle. Appels de fonction, conversations multi-tours, sorties structurées validées par schéma, réponses en streaming (les morceaux arrivent au fur et à mesure, sans attendre le bloc final) et outils fournis par le service fonctionnent pareil. Vous changez de fournisseur et le code de l'agent n'est pas réécrit. En pratique : une équipe peut changer de modèle sans toucher au code de l'agent, sans un if par fournisseur, et qui apprend le framework aujourd'hui ne dépend pas du fournisseur qu'il choisira demain.

Les cinq étapes avec Foundry

L'agent se construit contre Microsoft Foundry en cinq étapes, dans cet ordre :

Configurer le projet. Il vous faut le point de terminaison du projet Foundry et le nom du déploiement du modèle.
S'authentifier. DefaultAzureCredential est utilisé, qui résout la CLI Azure en développement et l'identité managée en production. La même ligne de code sert les deux environnements : en local vous prenez votre session de la CLI et en production l'identité managée de la ressource, sans secrets à cacher dans le code.
Initialiser le client de chat Foundry.
Créer l'agent, avec ses instructions et, si besoin, ses outils optionnels.
Ouvrir une session (AgentThread) pour l'exécuter.

sequenceDiagram
    participant Vos as Votre code
    participant C as Credential Azure
    participant F as Client de chat Foundry
    participant A as L'agent (ChatAgent)
    participant T as La session (AgentThread)
    Vos->>C: 1 et 2 : projet configuré et authentification
    C-->>Vos: La credential résout votre token
    Vos->>F: 3 : vous initialisez le client de chat
    Vos->>A: 4 : vous créez l'agent avec instructions et outils
    Vos->>T: 5 : vous ouvrez la session pour l'exécuter
    T->>F: La conversation tourne contre le service

En clair : cinq lignes de configuration et vous avez un agent qui tourne. La seule chose qui change entre votre machine et la production, c'est d'où vient la credential.

Aucune des cinq étapes ne vous demande de toucher au portail : les cinq vivent dans le code, dans votre même session de SDK. La séquence, résumée, est trois pièces : un client de chat Azure AI, un agent défini avec instructions et outils, et un AgentThread pour les conversations. Un détail qui évite de la friction : pas besoin de déployer votre propre modèle au préalable, ni de définir le modèle dans le constructeur d'AgentThread.

Où vit la mémoire

AgentThread est le conteneur de l'état de la conversation. Et c'est là la décision qui définit le fournisseur : avec Foundry, l'historique réside dans le service Foundry Agent, pas dans la mémoire de l'application. Le contexte entre tours se maintient nativement. Vous n'avez pas à persister les messages, sérialiser l'historique ni coordonner des caches entre instances.

C'est pourquoi Foundry reste le fournisseur recommandé pour la production. Si vous avez essayé des agents qui oublient ce qui s'est dit deux tours plus tôt, le problème vit presque toujours dans l'état logé dans l'application ; avec Foundry, ce problème n'apparaît pas : le service garde l'historique. En pratique, l'historique côté service signifie que l'état de la conversation ne vit pas dans la mémoire de votre application. Pour que les pièces ne se mélangent pas : ChatAgent définit le comportement de l'agent, le client gère l'authentification et le routage, et AgentThread administre l'état.

Les outils que le service apporte

Il y a deux familles d'outils, et la différence est qui les héberge et les exécute. La première est celle du fournisseur :

Interpréteur Python en environnement isolé.
Recherche de fichiers.
Recherche web.
Outils MCP hébergés.
Azure AI Search via la connexion Foundry.
Boîtes à outils Foundry : paquets nommés et versionnés dans le projet.

Être hébergés par le service compte : vous ne les déployez pas ni ne les maintenez. Si votre cas est couvert par l'un d'eux, l'agent les utilise sans que vous hébergiez rien : l'avantage est au service, et la maintenance aussi. Si votre cas entre dans la liste, vous gagnez de la capacité sans toucher une ligne de votre propre code. Les outils de l'autre famille sont ceux que vous écrivez.

Les outils que vous apportez

La deuxième famille, ce sont vos propres fonctions Python. Elles passent à l'agent au moment de sa création, et le framework fait le sale travail : il inspecte la signature de la fonction et génère le schéma. Pour la décrire, vous avez deux chemins :

# Annotated : le docstring et les descriptions de champ servent de description
def enviar_correo(
    destinatario: Annotated[str, Description("Correo del destinatario")],
    asunto: Annotated[str, Description("Asunto del correo")],
) -> str:
    ...

# @tool : nom et description explicites, avec schéma Pydantic optionnel
@tool(name="enviar_correo", description="Envía el correo de notificación")
def enviar_correo(destinatario: str, asunto: str) -> str:
    ...

Vous écrivez une fonction Python normale avec de bonnes descriptions, et cette fonction devient invocable par le modèle sans que vous déclariez le schéma à la main. Le détail est l'enregistrement : sans lui, l'agent ne sait même pas que la fonction existe. La différence entre les deux chemins est de style : Annotated laisse les descriptions à côté des types de la fonction ; @tool vous donne le contrôle explicite du nom et de la description, avec schéma Pydantic optionnel (Pydantic, la bibliothèque Python avec laquelle on valide des structures de données). Dans les deux cas, le schéma finit par voyager avec la fonction. Et il faut le savoir : l'enregistrement ne se configure pas dans le portail et ne requiert pas de modifier le modèle. Ça se passe dans le code, à la création de l'agent.

L'enregistrement vit dans le paramètre tools de ChatAgent. Plusieurs outils peuvent s'enregistrer à la fois, et le modèle choisit le bon. C'est le même principe que tout outil personnel : bien décrire et laisser l'agent décider quand l'utiliser. Ce qui se passe en dessous quand il choisit : le framework exécute la fonction et renvoie le résultat avant de générer la réponse finale. L'utilisateur voit la réponse ; l'appel à votre fonction reste au milieu, sans que vous l'écriviez ni le répétiez.

Le cas complet

Le cas se ferme avec un agent de notification de dépenses, un mandat que toutes les équipes ont : quelqu'un envoie des rapports de dépenses par courriel et il faut les traiter et prévenir. Il extrait les données des rapports envoyés, les formate correctement et envoie le courriel aux bons destinataires. L'exercice du SDK construit cet agent de courriel entier, de la credential à la session : c'est la même recette des cinq étapes avec un cas de métier dedans. Client de chat, agent avec instructions, outils enregistrés et session ouverte. C'est l'exemple typique où l'agent ne raisonne pas avec une connaissance privée : il exécute un processus avec des étapes, sur des données qui arrivent par courriel. Le motif se reconnaît dans n'importe quel processus semblable : lire un document, en extraire les données, les formater et prévenir quelqu'un.

Le faire tourner

Ce qui manque, c'est l'étape qui n'a pas été exécutée ici : l'exercice « Develop an Azure AI agent with the Microsoft Agent Framework SDK », qui exige un abonnement Azure. Le post a parcouru le framework, les cinq étapes, la mémoire côté service et les deux types d'outils ; il reste à le tourner et à voir la session persister vraiment entre les tours.

Si vous l'appliquez à votre machine, l'ordre du post est celui qui convient : projet et credential d'abord (en local, la CLI ; en production, l'identité managée), ensuite client, agent et session. La credential est la seule chose qui change entre votre laptop et le déploiement ; le reste du code, rien. Et une note pour ne pas se perdre en le cherchant : le titre en espagnol mentionne Semantic Kernel, mais le contenu se centre sur Microsoft Agent Framework. C'est le même héritage que décrit le post, avec le nouveau nom devant.

Mon avis

Ce qui décrit le choix du fournisseur, c'est l'historique côté service. L'état de la conversation entre les mains du service, et non les vôtres, c'est la différence entre avoir une infrastructure de session à maintenir et appeler quand vous en avez besoin. Et ce que le framework simplifie le plus est double. Un contrat unique (la classe Agent) pour ne pas réécrire en changeant de fournisseur ; la génération automatique de schémas pour que chaque fonction soit invocable sans la déclarer deux fois.

---

*Source : le module « Develop an Azure AI agent with Microsoft Agent Framework » de Microsoft Learn.*