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.

Quand utiliser des agents hébergés

Choisissez des agents hébergés plutôt que des agents basés sur des invites 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.
• Contrôler les ressources de calcul : spécifiez le CPU et la mémoire pour le bac à sable de votre agent.
• Exécuter des charges de travail avec état : conservez les fichiers et l’état des tours via $HOME et le point de terminaison /files.

Fonctionnement

Vous empaquetez votre agent en tant qu’image conteneur et envoyez-le à Azure Container Registry. Lorsque vous déployez, agent Service extrait l’image, provisionne le calcul, affecte une Microsoft Entra ID dédiée (identité de l’agent) et expose un point de terminaison dédié. Au moment de l’exécution, le code de votre agent gère les demandes des clients et peut appeler des modèles Foundry, des outils de boîte à outils et des services 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.

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), ce qui permet une mise à l'échelle jusqu'à zéro avec reprise de l'état et 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 et appels

Les conteneurs d’agents hébergés exposent un ou les deux protocoles. Chaque protocole est fourni par une bibliothèque légère qui gère le serveur HTTP, les vérifications d’intégrité et l’intégration d’OpenTelemetry.

Quel protocole dois-je utiliser ?

Comparaison des protocoles

Protocoles supplémentaires

Les agents hébergés prennent également en charge le protocole d’Activité pour l’intégration des canaux de Teams et de M365 (généralement employés avec Réponses) et le protocole A2A pour la délégation d’agent à agent. Les quatre protocoles (réponses, appels, activité et A2A) 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 Microsoft Entra ID dédié (identité de l’agent) et point de terminaison dédié, tous deux créés automatiquement au moment 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/v1/responses
• Invocations : {project_endpoint}/agents/{name}/endpoint/protocols/invocations

Les points de terminaison actifs dépendent des protocoles déclarés dans la définition de version de l’agent (défini dans agent.yaml lors de l’utilisation d’azd, ou via container_protocol_versions lors de l’utilisation du Kit de développement logiciel (SDK).

Deux identités sont impliquées :

Lorsque vous déployez avec azd, le rôle RBAC requis (Azure AI User au niveau de l'étendue du compte) est affecté automatiquement à l'ID Microsoft Entra de l'agent. Pour les ressources externes (par exemple, votre propre stockage Azure), vous affectez manuellement RBAC aux Microsoft Entra ID de l'agent.

Lorsqu'ils sont intégrés via des canaux Microsoft 365 (par exemple, Teams), les agents hébergés peuvent également fonctionner au nom de l'utilisateur (OBO). Le Microsoft Entra ID de l'agent peut échanger un jeton utilisateur pour appeler des services en aval en tant qu'utilisateur, sous réserve des stratégies des clients. 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 des ressources de calcul à la demande, et restaure l’état persistant sur celles-ci.

• 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 : les sessions persistent pendant jusqu’à 30 jours. Le délai d’inactivité est de 15 minutes : si aucune requête n’arrive dans cette fenêtre, la plateforme déprovisionne le calcul et conserve l’état de la session.
• 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

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 , un instantané de l’image conteneur, l’allocation de ressources, les variables d’environnement et la configuration du protocole. Les déploiements référencent une version spécifique. Pour mettre à jour votre agent, vous créez une nouvelle version et la plateforme la déploie. Notez que les demandes de création de version de l’agent sans modification des paramètres de version de l’agent tels que l’image conteneur, les variables d’environnement, etc. n’entraînent pas la création d’une nouvelle version. Vous pouvez fractionner le trafic entre les versions avec une répartition pondérée pour prendre en charge les déploiements canary et bleu-vert.

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.

Boîte à outils dans Foundry

Les agents hébergés accèdent aux outils gérés par Foundry (interpréteur de code, recherche web, Recherche Azure AI, OpenAPI, connexions MCP personnalisées, A2A) via un point de terminaison Toolbox MCP provisionné dans votre projet Foundry. Votre code d’agent se connecte à ce point de terminaison à l’aide de bibliothèques clientes MCP standard. La plateforme n’injecte pas automatiquement des outils. Pour plus d’informations, consultez la boîte à outils Curate basée sur les intentions dans Foundry. Nous vous recommandons d'utiliser l'ensemble d'outils de Foundry pour connecter des outils dans l'agent hébergé avec prise en charge unifiée de l'authentification à travers le passthrough OAuth Identity, l'identité d'agent, l'authentification à base de clé, et d'autres.

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 d'agent hébergé prennent en charge des allocations de vCPU et de mémoire allant de 0,25 vCPU / 0,5 Gio à 2 vCPU / 4 Gio.

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. Pour plus d’informations, consultez Configurer des réseaux virtuels. Notez que l'Azure Container Registry contenant l'image de votre agent doit actuellement rester accessible via son point de terminaison public ; un ACR sécurisé par un réseau privé n'est pas encore pris en charge.

Limites, tarification et disponibilité (aperçu)

Les agents hébergés sont actuellement en aperçu.

Limitations pendant l'aperçu

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 :

• USA Est 2
• USA Centre Nord
• Suède Centre
• Centre du Canada
• Asie Sud-Est
• Pologne Centre
• Afrique du Sud Nord
• Corée Centrale
• Inde sud
• Brésil Sud
• USA Ouest
• Ouest des États-Unis 3
• Norvège Est
• Japon Est
• France Centre
• Suisse Nord
• Espagne Centre
• Australie Est

É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
• Découvrir des outils dans Les outils Foundry
• documentation Azure Container Registry