Qu’est-ce que les agents hébergés ?

Lorsque vous générez des applications agentiques à l’aide de frameworks open source, vous gérez généralement de nombreuses préoccupations croisées : conteneurisation, configuration du serveur web, sécurité, persistance de la mémoire, mise à l’échelle, instrumentation et restaurations de versions. Ces tâches deviennent encore plus difficiles dans les environnements cloud hétérogènes.

Les agents hébergés dans le service De l’agent Foundry résolvent ces défis pour les utilisateurs Microsoft Foundry. Les agents hébergés appellent des modèles à partir du catalogue de modèles Foundry pour effectuer un raisonnement pendant que votre code personnalisé gère l’orchestration. À l’aide de cette plateforme managée, vous pouvez déployer et exploiter des agents IA en toute sécurité et à grande échelle. Vous pouvez utiliser votre code d’agent personnalisé ou une infrastructure d’agent préférée avec un déploiement et une gestion simplifiés.

Si vous explorez des agents hébergés avec un agent de codage IA, la compétence Microsoft Foundry peut vous aider à connecter ces concepts à l'implémentation, au déploiement et aux tâches d'exploitation.

Quand utiliser des agents hébergés

Choisissez des agents hébergés plutôt que des agents basés sur des prompts lorsque vous devez :

• Bring your own code : utilisez n’importe quelle infrastructure (Agent Framework, LangGraph, Noyau sémantique ou code personnalisé) plutôt que des définitions d’invite uniquement.
• Utilisez des protocoles personnalisés : acceptez les webhooks ou les charges utiles non OpenAI via le protocole Invocations.
• Gérez les ressources de calcul - spécifiez le processeur et la mémoire de l’environnement isolé de votre agent.
• Exécuter des charges de travail avec état : conservez les fichiers et l’état entre les itérations via $HOME et le point de terminaison /files.
• Exécutez de manière résiliente des tâches de longue durée - préservez le travail de l’agent en cours d’exécution malgré les interruptions de processus et rediffusez les résultats diffusés en continu aux clients qui se reconnectent.

Fonctionnement

Vous empaquetez votre agent en tant qu’image conteneur et envoyez-le à Azure Container Registry. Lorsque vous déployez, le service agent extrait l’image, affecte une Microsoft Entra ID dédiée (identité de l’agent) et expose un point de terminaison dédié pour l’agent.

Lors de l’exécution, Agent Service fournit les ressources de calcul pour la session et achemine les requêtes vers votre conteneur. Votre code d’agent gère ces demandes et peut appeler des modèles Foundry, des outils de boîte à outils et des services de Azure en aval à l’aide de son identité d’agent. La plateforme gère la mise à l’échelle, la persistance de l’état de session, l’observabilité et la gestion du cycle de vie.

Le diagramme suivant montre comment la responsabilité est divisée. Vous êtes propriétaire du code qui s’exécute dans le sandbox. La plateforme gère le terminal, l’identité, la mise à l’échelle et l’état de session qui lui sont associés.

Concepts clés

Agents hébergés

Les agents hébergés sont des applications IA d'agents conteneurisées qui s'exécutent sur Agent Service. Contrairement aux agents basés sur les invites, qui sont définis entièrement par le biais d’invites et de configuration d’outils dans le portail Foundry, les agents hébergés sont votre propre code empaqueté en tant qu’image conteneur. Vous choisissez l’infrastructure, contrôlez le comportement du runtime et déployez l’image sur une infrastructure gérée par Microsoft.

La plateforme gère automatiquement le cycle de vie du conteneur en fonction de l’activité, en approvisionnant les ressources lorsque vous créez une version et déprovisionnez lorsque le délai d’inactivité est atteint.

Modèle d’isolation

Les agents hébergés s'exécutent dans des sandboxes isolés par session de machine virtuelle. Chaque session dispose d’un bac à sable dédié avec un système de fichiers persistant ($HOME et /files), permettant une mise à l’échelle jusqu’à zéro avec reprise avec état et des démarrages à froid prévisibles. Les sessions sont isolées les unes des autres et l’état est automatiquement restauré lorsqu’une session reprend après avoir été inactive.

Protocoles : réponses, invocations et invocations (WebSocket)

Les conteneurs d’agents hébergés peuvent exposer un ou plusieurs protocoles. Chaque protocole est fourni par une bibliothèque légère qui gère le serveur HTTP ou WebSocket, les vérifications d’intégrité et l’intégration d’OpenTelemetry. Les protocoles Responses, Invocations et Invocations (WebSocket) sont disponibles dans toutes les régions prenant en charge les agents hébergés.

Quel protocole dois-je utiliser ?

Le protocole que vous choisissez détermine la charge utile que votre conteneur reçoit et la quantité de session, de diffusion en continu et de cycle de vie en arrière-plan que la plateforme gère pour vous. Un seul agent peut prendre en charge plusieurs protocoles. Ce choix n’est donc pas permanent. Utilisez l’arbre de décision suivant pour choisir un point de départ.

Comparaison des protocoles

Le mode en arrière-plan et l’exécution résiliente résolvent différents problèmes. Le mode d’arrière-plan permet au traitement de se poursuivre une fois la requête initiale terminée. L’exécution résiliente conserve le travail après l’arrêt du processus d’hébergement. Pour connaître le modèle de récupération et les responsabilités d’application, consultez Résilience pour les agents hébergés de longue durée.

Protocoles supplémentaires

Les agents hébergés prennent également en charge le protocole Activity pour Teams et l’intégration du canal Microsoft 365. Lorsque vous utilisez le protocole Réponses pour la logique de l’agent et que vous publiez sur des canaux Microsoft 365 tels que Teams, la plateforme relie automatiquement les réponses au protocole d’activité pour la remise des canaux. Aucun câblage distinct n’est nécessaire. Le protocole A2A prend en charge la délégation agent-à-agent. Les protocoles pris en charge peuvent être combinés dans un seul agent.

Identité et point de terminaison de l’agent

Chaque agent hébergé déployé sur un projet Foundry obtient son propre ID Microsoft Entra dédié (identité de l’agent) et son propre point de terminaison dédié — tous deux créés automatiquement lors du déploiement. Vous n’avez pas besoin de configurer manuellement les identités managées ou le routage.

Le point de terminaison est disponible immédiatement après le déploiement : la publication n’est pas requise pour l’accès par programmation :

• Réponses : {project_endpoint}/agents/{name}/endpoint/protocols/openai/responses
• Invocations : {project_endpoint}/agents/{name}/endpoint/protocols/invocations
• Invocations (WebSocket) : wss://{account}.services.ai.azure.com/api/projects/{project}/agents/{name}/endpoint/protocols/invocations_ws?api-version=v1
• A2A (version préliminaire) : {project_endpoint}/agents/{name}/endpoint/protocols/a2a

Les points de terminaison actifs dépendent des protocoles déclarés dans la définition de version de l’agent. Définissez cette définition dans le service azure.ai.agent de azure.yaml lorsque vous utilisez azd, ou via protocol_versions lorsque vous utilisez le SDK.

Deux identités sont impliquées :

Par défaut, l’identité de l’agent a accès à l’inférence de modèle via le point de terminaison du projet et au stockage de session. Pour les ressources externes (par exemple, votre propre stockage Azure), attribuez manuellement des rôles RBAC aux Microsoft Entra ID de l'agent. Pour plus d’informations, consultez l’accès agent au-delà des valeurs par défaut.

Lorsqu'ils sont intégrés via des canaux Microsoft 365 (par exemple, Teams), les agents hébergés peuvent fonctionner en deux modes d'identité en fonction de la façon dont ils sont appelés :

• Scénarios appelés par l’utilisateur (interactifs) : si un jeton utilisateur est présent, la plateforme prend en charge les flux OAuth 2.0 on-Behalf-Of (OBO). Dans ce cas, l’agent peut appeler des services en aval au nom de l’utilisateur en utilisant les permissions déléguées de celui-ci, sous réserve des stratégies du locataire Microsoft Entra ID.

• Scénarios automatiques ou en arrière-plan : si aucun jeton utilisateur n’est disponible, l’agent s’authentifie à l’aide de son propre Microsoft Entra ID (identité de l’agent), généralement via une identité managée, pour accéder aux services en aval.

Dans les deux cas, l’agent conserve son Microsoft Entra ID dédié pour l’authentification, l’autorisation et l’auditabilité. Pour plus d’informations, consultez les applications de l’agent et les concepts d’identité de l’agent.

Sessions et conversations

Les agents hébergés utilisent des sessions et des conversations pour gérer l’état. Leur fonctionnement dépend du protocole.

Sessions

Un ID de session identifie une session logique avec un état persistant, notamment $HOME et les fichiers chargés via le point de terminaison /files. La plateforme provisionne les ressources de calcul à la demande et y restaure l’état persistant.

• Persistance de l’état : $HOME et le contenu /files sont conservés entre les tours et les périodes d’inactivité. Lorsque le calcul est inactif et est restauré (sur une infrastructure nouvelle ou existante), l’état de la session est automatiquement restauré.
• Isolation : chaque session est isolée des autres sessions.
• Cycle de vie automatique : les sessions sont créées lors de la première utilisation. La plateforme provisionne et déprovisionne automatiquement les ressources de calcul.
• Durée de vie de la session : vous pouvez configurer le délai d’inactivité par version de l’agent de 5 à 60 minutes, avec une valeur par défaut de 15 minutes. Si aucune requête n’arrive dans cette fenêtre, la plateforme déprovisionne le calcul et conserve l’état de session. La plateforme supprime définitivement une session après 30 jours d’inactivité.
• API de gestion de session : répertorier les sessions, arrêter les sessions et charger ou télécharger des fichiers par session.

Conversations

Un ID de conversation est un enregistrement durable de l’historique des conversations (messages, appels d’outils et réponses) stocké dans Foundry.

• Persistance : l’historique des conversations est stocké dans Foundry et persiste indépendamment de l'état de calcul.
• Accès entre canaux : les utilisateurs peuvent accéder à la même conversation à partir du terrain de jeu, de l’API, de Teams ou d’autres canaux publiés.

Fonctionnement des sessions et des conversations avec chaque protocole

Protocole réponses : l’ID de conversation est le concept principal. La plateforme gère automatiquement l’historique des conversations et associe un ID de session à chaque conversation. La plateforme retourne l’ID de session au client, qui peut l’utiliser pour charger des fichiers via le point de terminaison /files, ce qui rend ces fichiers disponibles pour le calcul de la conversation.

Protocole d’appel : ID de session est le concept principal. Le client gère directement l’ID de session pour maintenir l’état entre les interactions. Le client peut charger du contenu via le point de terminaison /files à l’aide de l’ID de session pour le rendre disponible pour la session. Il n’existe pas d’historique de conversation géré par la plateforme : vous gérez l’état dans votre propre code.

Cycle de vie du calcul de session

Le calcul suit la session, et non la requête individuelle. La plateforme provisionne un bac à sable lorsqu’une session démarre et la libère lorsque le délai d’inactivité configuré s’écoule après la demande la plus récente. Lorsque la session reprend, la plateforme restaure $HOME et /files, par conséquent, votre code trouve les fichiers qu’il a écrits précédemment. Le diagramme suivant montre comment une requête passe par ces états.

Gestion de la sécurité et des données

Traitez un agent hébergé comme le code d’application de production.

• Ne placez pas de secrets dans des images conteneur ou des variables d’environnement. Utilisez des identités managées et des connexions, et stockez des secrets dans un magasin de secrets managés. Pour obtenir des conseils, consultez Configurer une connexion Key Vault.
• Be prudent avec les outils et serveurs non Microsoft. Si votre agent appelle des outils soutenus par des non-services Microsoft, certaines données peuvent être transmises à ces services. Passez en revue les stratégies de partage, de rétention et d’emplacement des données pour tout service non Microsoft que vous connectez.

Détails de la plateforme

Versionnage

Chaque appel pour créer une version produit une version d’agent immuable. La version est un instantané de l’image conteneur, de l’allocation de ressources, des variables d’environnement et de la configuration du protocole. Pour mettre à jour votre agent, créez et déployez une nouvelle version.

Un point de terminaison d’agent sert une version à la fois et achemine 100% de son trafic vers cette version. Le fractionnement du trafic entre les versions n’est pas pris en charge.

Les variables d’environnement sont le mécanisme principal permettant de transmettre la configuration à votre conteneur au moment de l’exécution (par exemple, le point de terminaison du projet, le nom du déploiement du modèle et les paramètres personnalisés). Ils sont définis par version et sont immuables une fois la version créée.

Observabilité

Les agents hébergés offrent une observabilité intégrée. La plateforme injecte automatiquement une chaîne de connexion "Application Insights" dans votre conteneur d’agent via des variables d’environnement. Les agents qui utilisent les bibliothèques de protocole émettent des traces OpenTelemetry par défaut, qui apparaissent dans la ressource Application Insights liée sous Examiner> larecherche transactionnelle ou les performances.

Pour obtenir des conseils sur la configuration et l’analyse, consultez Activer le suivi dans votre projet.

Boîte à outils dans Foundry

Les agents hébergés ont un accès complet aux outils gérés par Foundry, notamment l’interpréteur de code, la recherche web (avec Recherche personnalisée Bing), Recherche Azure AI, OpenAPI, MCP, A2A, Skills, etc. Vous connectez ces outils via un point de terminaison MCP de boîte à outils approvisionné dans votre projet Foundry plutôt qu’en les ajoutant directement à la définition de l’agent. La boîte à outils vous offre une authentification consolidée sur la passe d’identité OAuth, l’identité de l’agent, l’authentification basée sur des clés, etc. Si vous utilisez Microsoft Agent Framework, connectez-vous via FoundryToolbox en Python ou AddFoundryToolboxes en .NET plutôt qu’au moyen d’un client MCP générique. D’autres runtimes se connectent à l’aide de bibliothèques clientes MCP standard. Pour plus d’informations, consultez la boîte à outils Curate basée sur les intentions dans Foundry.

Prise en charge linguistique

Les agents hébergés prennent en charge Python et C#. Vous pouvez utiliser n’importe quelle infrastructure d’agent : les bibliothèques de protocole sont indépendantes de l’infrastructure. Pour obtenir des exemples utilisant Microsoft Agent Framework, LangGraph et du code personnalisé, consultez le dépôt foundry-samples.

Tailles de bac à sable

Les bacs à sable des agents hébergés prennent en charge les configurations de processeur et de mémoire suivantes :

Stockage de session

Chaque session a un $HOME persistant. La plateforme conserve son contenu lorsqu’elle déprovisionne le calcul après le délai d’inactivité configuré. La plateforme restaure le contenu lorsque la session reprend, de sorte que les fichiers écrits en période $HOME d’inactivité survivent. La plateforme écrit les fichiers téléversés via le point de terminaison /files dans $HOME, où ils partagent le même espace de stockage. Chaque session dispose d’un quota disque total pouvant atteindre 20 Gio pour 1 vCPU ou plus, lequel diminue proportionnellement pour les niveaux de processeur inférieurs. La plateforme réserve environ 20% de ce budget pour l’utilisation du système, et elle n’est pas visible ou disponible pour votre agent. Le reste est partagé entre votre image de conteneur, $HOME, et tous les autres emplacements accessibles en écriture dans votre conteneur.

Mise à l’échelle et dimensionnement adapté

Les agents hébergés effectuent une mise à l’échelle par session, et non par réplica. La plateforme crée à la demande une nouvelle sandbox isolée au niveau de la VM pour chaque session et maintient ses ressources de calcul actives tant que les requêtes se poursuivent. Chaque requête réinitialise le minuteur inactif. Lorsque le délai d’inactivité configuré expire après la requête la plus récente, la plateforme libère les ressources de calcul du bac à sable et conserve l’état de la session.

Le délai d’inactivité peut être de 5 à 60 minutes et la valeur par défaut est de 15 minutes. La plateforme supprime définitivement une session après 30 jours d’inactivité. Il n’existe aucun nombre de réplicas à configurer et aucun pool à chaud à dimensionner.

Étant donné que chaque session s’exécute dans son propre bac à sable, les valeurs de processeur et de mémoire que vous définissez sur une version de l’agent décrivent une session unique, et non l’empreinte agrégée de l’agent. La facturation est basée sur le CPU et la mémoire consommés dans l’ensemble des sessions actives, de sorte qu’un surdimensionnement multiplie le coût par votre niveau de simultanéité.

Pour une taille appropriée, exécutez une charge de travail représentative et inspectez l’utilisation des ressources dans la ressource Application Insights liée :

1. Ouvrez la ressource App Insights dans le portail Azure et sélectionnez Investigate>Performance.
2. Passez en revue le processeur, la mémoire disponible, le taux de requêtes et la durée moyenne de la requête au fil du temps que vous avez testé.

Comparez les pics observés par rapport au processeur et à la mémoire que vous avez alloués. Si les pics soutenus dépassent environ 70 % de l’allocation, augmentez l’allocation de la prochaine version de l’agent ; si les pics restent nettement en dessous, diminuez-la pour réduire les coûts. Retestez toujours après une modification, car chaque nouvelle version est immuable.

Mise en réseau privé

Les agents hébergés prennent en charge le déploiement dans les ressources Foundry isolées du réseau et peuvent utiliser un Réseau virtuel Azure fourni par le client pour le trafic sortant. Cela permet aux agents dans les déploiements Foundry isolés du réseau d’atteindre des ressources privées telles que des bases de données ou des API internes. Pour plus d’informations, consultez Configurer des réseaux virtuels.

Limites, tarification et disponibilité

Prix

La facturation du runtime d’hébergement managé est basée sur la consommation des ressources processeur et mémoire pendant les sessions actives. Pour connaître les tarifs actuels, consultez la page de tarification Foundry.

Disponibilité de la région

Les agents hébergés sont actuellement disponibles dans les régions suivantes :

• Australie Est
• Brésil Sud
• Centre du Canada
• Est du Canada
• États-Unis du Centre
• East US
• USA Est 2
• France Centre
• Allemagne Centre-Ouest
• Italy North
• Japon Est
• Japon Ouest
• Corée Centrale
• USA Centre Nord
• Norvège Est
• Pologne Centre
• Afrique du Sud Nord
• États-Unis – partie centrale méridionale
• Inde sud
• Asie Sud-Est
• Espagne Centre
• Suède Centre
• Suisse Nord
• Switzerland West
• UAE North
• UK South
• UK West
• Ouest du centre des États-Unis
• West Europe
• USA Ouest
• Ouest des États-Unis 3

Étapes suivantes

Contenu connexe

• Composants d’exécution de l’agent
• Cycle de vie du développement de l’agent
• concepts de l'identité d'Agent dans Microsoft Foundry
• Qu’est-ce que la boîte à outils dans Foundry ?
• documentation Azure Container Registry