Créer un agent Azure AI avec Microsoft Agent Framework

Le Foundry Agent Service est le fournisseur recommandé pour les environnements de production basés sur Microsoft Agent Framework. Il gère l’historique des conversations persistantes côté service, prend en charge les outils intégrés tels que l’exécution du code et la recherche de fichiers, et s’intègre en toute transparence à Azure gestion des identités. Ces fonctionnalités vous permettent de vous concentrer sur le comportement de votre agent plutôt que sur sa surcharge d’infrastructure.

Configuration d’un agent Foundry

La création et l’interaction avec un agent Foundry suivent une séquence cohérente d’étapes.

1. Configurer votre projet Foundry

Avant d’écrire du code, vous avez besoin d’un projet Microsoft Foundry avec un modèle déployé. Vous vous connectez à votre projet à l’aide de deux informations :

• Point de terminaison du projet — l’URL de votre projet Foundry.
• Nom du déploiement du modèle — le nom du déploiement du modèle que vous souhaitez utiliser pour votre agent.

2. Configurer l’authentification

Le Agent Framework se connecte à votre projet Foundry à l’aide d’informations d’identification Azure. Dans la plupart des scénarios, DefaultAzureCredential résout automatiquement les informations d’identification appropriées en fonction de votre environnement, Azure CLI pendant le développement, l’identité managée en production. Aucune chaîne de connexion ni clé API n’a besoin d’être codées en dur.

3. Initialiser le client de conversation Foundry

Créez un client de conversation Foundry en fournissant vos informations d’identification, point de terminaison de projet et nom de modèle. Ce client est le pont entre votre application et le service d’agent Foundry. Il gère l’authentification, le routage des demandes et la gestion des sessions côté service.

4. Créer l’agent

À l’aide du client de conversation, créez un agent en fournissant un ensemble d’instructions qui définissent son comportement :

• Instructions : invite système qui définit le rôle, les objectifs et les contraintes de l’agent
• Outils(facultatif) : fonctions personnalisées que l’agent peut appeler pour effectuer des actions ou récupérer des informations

L’infrastructure inscrit tous les outils que vous fournissez et génère automatiquement leurs schémas, de sorte que le modèle sait quand et comment les appeler.

5. Établir une session et exécuter l’agent

Pour commencer à interagir, vous ouvrez une session via l’instance de l’agent. La session sert de conteneur pour l’état de la conversation. Vous envoyez des messages utilisateur à la méthode d’exécution de la session, qui traite l’invite, coordonne les appels d’outils nécessaires et retourne la réponse du modèle.

Conversations à plusieurs tours

Un seul appel à la méthode d’exécution de l’agent gère un échange : un message utilisateur, une réponse. Pour avoir une véritable conversation, il faut que l’agent se souvienne de ce qui a été dit lors des échanges précédents. C’est à cela que sert une session.

Pour le fournisseur Foundry, les sessions sont sauvegardées par stockage côté service : l’historique des conversations réside dans le service De l’agent Foundry plutôt que dans la mémoire de votre application.

• Historique persistant — Comme l’état est conservé côté service, la conversation d’un utilisateur peut se poursuivre d’une requête à l’autre, même si votre application redémarre ou est mise à l’échelle sur plusieurs instances.

• Historique local : pour les fournisseurs qui ne prennent pas en charge l’historique côté service, l’infrastructure conserve l’état de conversation en mémoire dans l’objet de session. L’historique local est adapté aux applications à courte durée ou sans état, mais il ne persiste pas dans les redémarrages de processus.

Réponses sans diffusion en continu et avec diffusion en continu

Agent Framework prend en charge deux modes de réponse :

• Non-streaming (synchrone) : la méthode d’exécution attend que l’agent termine le traitement et retourne un objet de réponse complet. La non-diffusion en continu est le modèle le plus simple et fonctionne bien lorsque vous n’avez pas besoin d’afficher la sortie de manière incrémentielle.

• Streaming (asynchrone) : la méthode d’exécution retourne un flux de réponse que vous itérerez de façon asynchrone, recevant des mises à jour partielles à mesure que le modèle les génère. La diffusion en continu est mieux adaptée aux interfaces orientées utilisateur, où l’affichage de la sortie améliore progressivement l’expérience.

Dans les deux cas, la réponse expose une text propriété qui agrège tout le contenu du texte de la sortie de l’agent, ce qui facilite l’extraction de la réponse finale, quel que soit le mode que vous utilisez.