Créer des agents hébergés avec Microsoft Foundry Toolkit pour Visual Studio Code

Utilisez Microsoft Foundry Toolkit pour Visual Studio Code pour créer un flux de travail basé sur du code à partir d’un exemple Microsoft Agent Framework. Exécutez-le localement avec Agent Inspector, puis déployez son code source sur Foundry Agent Service en tant qu’agent hébergé. Vous conservez le code et ses dépendances. Foundry gère l’infrastructure d’hébergement et la mise à l’échelle.

Les workflows hébergés coordonnent les agents dans le code. Ils diffèrent du service de flux de travail déclaratif Foundry mis hors service. Pour d’autres itinéraires de création, consultez Créer un agent.

Prerequisites

  • Installez Microsoft Foundry Toolkit pour Visual Studio Code.

  • Sélectionnez un projet Foundry avec un modèle déployé. Utilisez une région d’agent hébergé prise en charge.

  • Autorisation d’utiliser le modèle et de déployer des agents hébergés. Pour le déploiement de code-source, le rôle Foundry Project Manager à l’échelle du projet comprend les opérations liées à l’agent et les autorisations d’attribution de rôles. Consultez les autorisations de l’agent hébergé.

    Important

    Les rôles Foundry RBAC ont été récemment renommés. Foundry User, Foundry Owner, Propriétaire du compteFoundry et Foundry Project Manager ont été précédemment nommés Azure utilisateur IA, Azure propriétaire d’IA, propriétaire Azure compte IA et Azure gestionnaire Project IA. Il se peut que vous voyiez encore les anciens noms à certains endroits pendant le déploiement de ce changement de nom. Les ID de rôle et les autorisations de base ne sont pas modifiés par ce changement de nom.

  • Azure CLI pour les étapes d’authentification locales décrites dans cet article.

  • Pour le déploiement de conteneurs, l’accès au registre et à l’image requis par la configuration de Azure Container Registry. Ces exigences de Registre ne s’appliquent pas à un déploiement de code source.

  • Python 3.13 pour l’environnement d’exécution hébergé configuré pour l’exemple.
  • Extension Python pour Visual Studio Code.

Le chemin de déploiement principal utilise Code avec le mode package Remote et ne nécessite pas de build Docker local. L’exécution locale envoie toujours des demandes de modèle à Foundry et peut entraîner des frais. Passez en revue les limites et la disponibilité du service et les notes de publication du Kit de ressources pour connaître les fonctionnalités que vous utilisez.

Créer un flux de travail d’agent hébergé

Choisissez un exemple Agent Framework qui utilise le protocole Réponses. Vous n’avez pas besoin de créer d’abord un agent de prompt distinct. Pour comparer les exemples, Agent Builder et le codage assisté par Copilot, consultez Choisir une méthode de création.

Utilisez le flux de travail multi-agent (Agent Framework), qui enchaîne un rédacteur, un réviseur et un metteur en forme. La réponse finale provient du formatteur. Passez en revue l’exemple de flux de travail Python pour obtenir l’implémentation complète et son guide de modèle.

Utilisez le flux de travail de traduction, qui chaîne trois agents de traduction : l’anglais en français, le français en espagnol et l’espagnol en anglais. Passez en revue l’exemple de flux de travail C# pour l’implémentation complète.

  1. Dans la vue Foundry Toolkit, sélectionnez Developer Tools>Build>Create Agent.

  2. Sous Coder un agent à partir d’exemples, sélectionnez Parcourir tous les exemples.

  3. Dans Créer un agent hébergé à partir d’un exemple, filtrez par votre Langue, Framework = Framework d’agent et Type de protocole = Réponses. Recherchez workflow.

    La capture d’écran suivante montre la galerie avec l’agent hébergé de base sélectionné comme exemple. Pour ce guide, sélectionnez l’exemple de flux de travail pour votre langue à la place.

    Capture d’écran de l’exemple de galerie d’agents hébergés avec l’agent hébergé de base sélectionné, les exemples de flux de travail et le langage, l’infrastructure et les filtres de protocole.

  4. Sélectionnez l’exemple de flux de travail pour votre langue.

  5. Cliquez sur Suivant.

  6. Dans Créer, choisissez le dossier de l’espace de travail. Si le dossier contient déjà des fichiers, entrez un nom de dossier pour un nouveau dossier enfant.

  7. Si le programme d’installation de l’environnement s’affiche, sélectionnez Configuration avec Microsoft Foundry, puis sélectionnez votre abonnement et votre projet. Lorsqu’un projet par défaut est déjà sélectionné, le formulaire utilise ce projet.

  8. Sélectionnez un déploiement de modèle compatible existant.

    La capture d’écran suivante montre des exemples de paramètres de projet avec des chemins d’accès locaux masqués. Utilisez votre propre destination et le déploiement du modèle requis pour votre exemple.

    Capture d’écran de l’onglet Créer montrant le dossier de l’espace de travail, le nom du dossier, le déploiement de modèle et les contrôles Créer, avec des chemins d’accès locaux masqués.

  9. Passez en revue la destination, puis sélectionnez Créer.

  10. Ouvrez le projet généré dans Visual Studio Code et lisez-leREADME.md.

Les vignettes Agent Framework, Copilot SDK et LangGraph dans Create Agent ouvrent l’onglet Create avec le modèle de démarrage « hello-world » sélectionné. Utilisez Parcourir tous les exemples pour choisir un flux de travail plutôt que l’un de ces modèles de départ. Vous pouvez également ouvrir la galerie à partir de My Resources>Agents>Hosted Agent>Add Hosted Agent.

Les exemples de noms et de contenu peuvent changer avec le catalogue. Certaines versions étiquetent ces exemples de flux de travail. Utilisez le lien GitHub de l'exemple pour confirmer que vous avez sélectionné le flux de travail prévu.

Ignorer pour le moment génère le code sans finaliser la configuration du modèle. Si vous le choisissez, configurez les valeurs de projet et de modèle nécessaires avant d’exécuter l’exemple. Déployer et utiliser un nouveau modèle, si cette option est proposée, crée un déploiement de modèle, et non l’agent hébergé. La création des fichiers de projet locaux ne déploie pas l’agent.

Configurer le projet local

Conservez le dossier qui contient azure.yaml ouvert en tant que racine de l’espace de travail. Vérifiez, dans ce fichier, le chemin project du service d’agent hébergé afin de trouver son répertoire source.

Artéfact Purpose
azure.yaml Déclare le service d’agent hébergé, le répertoire source, le runtime, les protocoles et les paramètres de déploiement.
main.py ou Program.cs dans le répertoire source Implémente le flux de travail et démarre son serveur Réponses.
requirements.txt ou le fichier .csproj Déclare les dépendances pour la langue sélectionnée.
.env dans le répertoire source Contient des valeurs de projet et de modèle locales. La boîte à outils le crée à partir de .env.example lorsque l’exemple fournit ce fichier.
.vscode/launch.json et .vscode/tasks.json Configurez le serveur local, l’attachement du débogueur et Agent Inspector.

Les exemples de dispositions peuvent changer. Utilisez le fichier généré README.md et azure.yaml au lieu de supposer que le code et le fichier d’environnement se trouvent à la racine de l’espace de travail.

Installer des dépendances

Utilisez les fichiers de dépendance de l’exemple généré. Conservez l’interpréteur ou le KIT de développement logiciel (SDK) sélectionné en cohérence avec sa configuration d’exécution.

  1. Exécutez Python : Créer un environnement... à partir de la palette de commandes pour créer un environnement virtuel ou Python : sélectionnez Interpréteur pour sélectionner un environnement Python 3.13 existant. Pour la configuration et la sélection de l’environnement, consultez Python environnements dans Visual Studio Code.

  2. Ouvrez un terminal avec cet environnement actif. Accédez au répertoire source qui contient main.py et requirements.txt.

  3. Installez les packages de l’exemple :

    python -m pip install -r requirements.txt

    Les exigences incluent debugpy, que la configuration F5 générée utilise. Référence : Python dépendances de flux de travail.

  1. Exécuter C# : Vérifiez les exigences de l’espace de travail à partir de la palette de commandes.

  2. Dans un terminal, accédez au répertoire source qui contient le .csproj fichier et restaurez ses packages :

    dotnet restore

    Référence : dotnet restore.

Pour connaître les contrôles et la configuration du débogueur, consultez débogage C# dans Visual Studio Code.

Définir le projet et le modèle

Passez en revue le .env fichier dans le répertoire source. S’il n’existe pas, créez-le avec les valeurs requises par l’exemple.

Variable Valeur
FOUNDRY_PROJECT_ENDPOINT Votre point de terminaison de projet, sous la forme https://<resource-name>.services.ai.azure.com/api/projects/<project-name>.
AZURE_AI_MODEL_DEPLOYMENT_NAME Nom du déploiement du modèle dans ce projet, pas seulement le nom du catalogue du modèle.

Les deux exemples de flux de travail chargent .env au démarrage. Le point de terminaison du projet n’est pas un point de terminaison de compte OpenAI Azure. Conservez le fichier hors contrôle de code source et ne placez pas d’informations d’identification dans votre code d’application.

S’authentifier localement

Les exemples utilisent DefaultAzureCredential. Pour le chemin d'accès des informations d'identification Azure CLI, connectez-vous avec un compte qui peut accéder au modèle du projet :

az login

Référence : Connectez-vous avec Azure CLI.

La connexion à la boîte à outils sélectionne le projet pour les opérations liées aux extensions. Le processus d’agent local a également besoin d’informations d’identification prises en charge. Pour d’autres options, consultez DefaultAzureCredential pour Python ou les chaînes d’informations d’identification pour .NET.

Exécuter votre flux de travail hébergé localement

Utilisez la configuration de débogage générée pour démarrer le serveur HTTP et ouvrir l’inspecteur d’agent. Ouvrir Agent Inspector à lui seul ne démarre pas le serveur.

Pour connaître les paramètres de connexion, les approbations d’outils, les diagnostics de flux de travail et les exportations d’événements, consultez Déboguer des agents avec l’Inspecteur d’agents. Les événements Live Inspector ne nécessitent pas de collecteur OTLP. Pour enregistrer les spans OpenTelemetry pour une analyse ultérieure, configurez le traçage local.

Utilisez cette demande de test : Create a slogan for a new electric SUV that is affordable and fun to drive. Le flux de travail renvoie un slogan mis en forme une fois que le rédacteur, le réviseur et le metteur en forme ont terminé.

Utilisez cette demande de test : The quick brown fox jumps over the lazy dog. le flux de travail exécute sa chaîne de traduction et retourne une réponse.

  1. Revenez à l’espace de travail de projet généré.
  2. Définissez un point d’arrêt dans le code de flux de travail si vous souhaitez inspecter l’exécution.
  3. Appuyez sur F5. Si vous y êtes invité, sélectionnez Déboguer le serveur HTTP de l’agent local.
  4. Attendez que le serveur démarre et que Agent Inspector s’ouvre.
  5. Envoyez la demande de test pour votre exemple.
  6. Inspectez la réponse et répétez-la avec une autre requête. Si vous définissez un point d’arrêt, inspectez les valeurs et poursuivez l’exécution.

Une fois l’exemple terminé, modifiez le flux de travail et répétez le test local. Si vous ajoutez des outils, envoyez une demande qui nécessite un résultat réel de l’outil et inspectez l’appel. Une réponse de modèle uniquement ou une réponse fictive ne prouve pas que l’outil en direct fonctionne.

La capture d’écran montre un agent local prenant en charge l’outil, pas l’un ou l’autre exemple de flux de travail. Agent Inspector affiche sa réponse et ses appels d’outils avec un diagramme en cascade de la latence et une frise chronologique d’exécution. Les détails d’inspection disponibles dépendent de l’agent en cours d’exécution et de son instrumentation.

Capture d’écran d’Agent Inspector connecté à localhost sur le port 8088 avec le protocole Responses, des appels d’outils, un diagramme en cascade de latence et une chronologie d’exécution.

Si vous utilisez GitHub Copilot, vous pouvez exécuter /validate-microsoft-foundry-hosted-agent dans Copilot Chat pour passer en revue le projet par rapport aux meilleures pratiques de Foundry. Cette commande conversation ouvre un rapport ; il ne s’agit pas d’une commande de terminal ou d’une substitution pour l’exécution du flux de travail.

Les tâches générées utilisent le port 8088 pour le serveur d’agent. Le débogage de Python utilise également le port 5679. Si le démarrage signale un conflit de port, arrêtez le processus en conflit que vous possédez ou ajustez la configuration de tâche générée de manière cohérente.

Exécuter sans le débogueur

Pour l’exécuter manuellement, ouvrez un terminal dans le répertoire source de l’exemple, avec ses dépendances, ses variables d’environnement et les identifiants Azure disponibles.

python main.py

Référence : Python point d’entrée du flux de travail.

Définissez l’adresse HTTP du serveur local, puis exécutez-la :

$env:ASPNETCORE_URLS = "http://localhost:8088"
dotnet run

Référence : URL du serveur ASP.NET Core et dotnet run.

Exécutez ensuite Foundry Toolkit : Ouvrez l’inspecteur d’agent à partir de la palette de commandes et connectez-vous au serveur local sur le port 8088. L’exécution d’un exemple avec python ou dotnet run démarre un processus local, et non un conteneur.

Visualiser l’exécution du flux de travail de l’agent hébergé

Utilisez Agent Inspector pour examiner les événements, les réponses et les appels aux outils émis par votre agent en cours d’exécution. Lorsque le runtime émet des événements de flux de travail, utilisez la visualisation de flux de travail pour inspecter la séquence d’étapes.

Les détails disponibles dépendent de l’instrumentation de l’échantillon. Suivez les instructions de configuration de la télémétrie de l’exemple pour connaître les exigences spécifiques au runtime.

Ces étapes utilisent le protocole Réponses. D'autres exemples nécessitent des clients adaptés à leur protocole : la vue des invocations HTTP n'est pas un client WebSocket, et les exemples d’activité Python utilisent Microsoft 365 Agents Playground. Suivez les instructions de test local de l’exemple sélectionné. La modification d’un nom de protocole dans la configuration n’ajoute pas ce protocole à votre serveur. Consultez Choisir un protocole d’agent hébergé.

Déployer l’agent hébergé

Une fois que le flux de travail local se comporte comme prévu, déployez-le à partir de l’espace de travail du projet. Python et C# partagent la procédure de déploiement. Commencez avec le mode Code et le mode package Remote pour téléverser le code source et laisser Foundry restaurer les dépendances.

Préparer la configuration du déploiement

Vérifiez et enregistrez le service d’agent hébergé dans azure.yaml. Conservez la configuration du protocole de l’exemple et déclarez le déploiement du modèle et d’autres paramètres d’exécution requis.

Le déploiement résout les valeurs d’environnement déclarées du répertoire source ou de l’environnement .env de processus. Il ne transfère pas chaque entrée locale .env . La plateforme fournit des valeurs d’exécution réservées telles que FOUNDRY_PROJECT_ENDPOINT; ne les rédéclarez pas en tant que paramètres de déploiement. Consultez les variables d’environnement injectées par la plateforme.

Passez en revue les règles d’exclusion du répertoire source avant l’empaquetage. Conservez .env, informations d’identification, environnements virtuels et caches hors du package. Pour le déploiement ZIP, une racine source .agentignore remplace les règles dans .gitignore et .dockerignore, alors conservez les exclusions nécessaires si vous ajoutez ce fichier.

Important

N'effectuez pas de commit et n'empaquetez pas de secrets. La connexion locale ne transfère pas les autorisations de votre utilisateur à l’agent déployé. Configurez l’accès à l’identité d’exécution de l’agent et aux connexions prises en charge. Consultez les autorisations de l’agent hébergé.

Déployer le code source avec le mode de package à distance

Utilisez la racine de l’espace de travail généré pour que le Kit de ressources puisse lire la configuration du service et localiser son répertoire source.

  1. Arrêtez la session de débogage locale.

  2. Sélectionnez Developer Tools>Build>Déployer vers Microsoft Foundry. Vous pouvez également exécuter Foundry Toolkit : déployer l’agent hébergé à partir de la palette de commandes.

    Capture d’écran de Déployer vers Microsoft Foundry sous Build dans la section Outils de développement de Foundry Toolkit.

  3. Si Configuration du projet Foundry s’affiche, sélectionnez l’abonnement et le projet, puis sélectionnez Suivant. Sinon, vérifiez que le projet par défaut est la destination prévue.

  4. Dans Notions de base, sélectionnez Code comme méthode de déploiement et Distant comme mode de package.

  5. Sélectionnez Nouvel agent et entrez le nom de l’agent hébergé. Pour mettre à jour un agent déployé, sélectionnez l’agent existant et choisissez cet agent à la place.

    Capture d’écran des concepts de base avec le déploiement du code, le mode package distant et l’option Nouvel agent sélectionné, avec le nom de l’agent masqué.

  6. Cliquez sur Suivant.

  7. Dans Révision + Déployer, vérifier le langage, la version du runtime, le point d’entrée et le processeur et la mémoire par rapport à l’exemple. Vérifiez que le répertoire source correspond au chemin du project service.

    La capture d’écran suivante montre un exemple avec Python 3.14 et son point d’entrée masqué, et non les paramètres de ces exemples de flux de travail. Pour Python, utilisez Python 3.13 avec python3 main.py. Pour C#, utilisez .NET 10 et le point d’entrée détecté pour votre projet généré.

    Capture d’écran de Review + Deploy montrant Python 3.14 comme exemple, un point d’entrée masqué, le processeur et la mémoire, et déployer des contrôles.

  8. Sélectionnez Déployer. Suivez la progression dans les notifications et Output.

  9. Continuez à tester le flux de travail déployé.

Faire correspondre le runtime à votre exemple de configuration et à votre environnement local. N’acceptez pas un environnement d’exécution différent simplement parce que c’est la valeur par défaut de l’assistant.

Le Kit de ressources enregistre les choix de déploiement lorsque vous envoyez le formulaire. Ces paramètres locaux ne prouvent pas que le déploiement cloud a réussi. La mise à jour d’un agent existant crée une nouvelle version plutôt que de modifier une version précédente en place.

Choisir un autre mode de package ZIP

Le Kit de ressources offre ces options d’empaquetage de code source :

Empaqueter un mode Que se passe-t-il ? Ce qu’il faut préparer
À distance Source des packages toolkit. Foundry restaure les exigences Python ou le projet .NET lors de l’approvisionnement. Source, déclarations de dépendance et point d’entrée compatible.
Groupé La boîte à outils met en scène la source et exécute la commande de package localement avant de créer le fichier ZIP. Foundry exécute le package préparé. Dépendances Linux compatibles et outils locaux requis par la commande. La commande Python par défaut installe les dépendances compatibles dans packages/; la commande .NET crée une sortie de publication.

Les runtimes ZIP sélectionnables sont Python 3.13, Python 3.14 et .NET 10. Mettre en correspondance le runtime avec votre code et vos dépendances. Pour connaître les dispositions, les limites et les exigences de service, consultez Déployer à partir du code source. Pour connaître la stratégie de prise en charge du runtime, consultez Les runtimes d’agent hébergé pris en charge.

Déployer une image conteneur

Choisissez Container on Basics lorsque vous avez besoin d’une image runtime personnalisée ou que vous disposez déjà d’une image compatible.

Choix du registre Comportement du kit de ressources
ACR par défaut Crée ou réutilise un registre pour le projet sélectionné, puis génère et envoie (push) l’image via Azure Container Registry (ACR).
ACR personnalisé Utilise un registre existant que vous sélectionnez, puis génère et envoie (push) l’image via ACR.
Image ACR personnalisée Utilise une référence d’image ACR prédéfinie sans générer ou envoyer (push) une source.

Pour les options de génération, passez en revue le fichier Dockerfile et le contexte de build avant le déploiement. Si vous générez un fichier Dockerfile dans l’Assistant, passez en revue le fichier, puis sélectionnez Continuer et déployer. Ces options utilisent des builds ACR distantes, et non des builds Docker locales.

Les options de Registre personnalisées utilisent un registre dans l’abonnement sélectionné. Le processus de génération à partir d’un registre personnalisé nécessite un accès au réseau public ; le processus basé sur une image préconstruite est soumis à des exigences distinctes concernant le réseau privé. Le choix d’une image ne configure pas la connectivité réseau.

Passez en revue les exigences de conteneur et les conseils de mise en réseau privé avant d’utiliser un registre personnalisé. Ces déploiements ciblent le service de l’agent Foundry, et non la voie d'agent hébergée sur Azure Container Apps abandonnée. Pour déplacer un agent plus ancien, suivez Effectuer la migration depuis la version préliminaire de l’agent hébergé.

Tester le flux de travail déployé

Une demande de création réussie ne prouve pas que le runtime est prêt ou que son modèle et ses outils sont accessibles. Testez la version exacte déployée.

Pour examiner une demande déployée, affichez les traces de l’agent hébergé. Les traces cloud utilisent la ressource Application Insights connectée du projet, et non votre base de données de trace locale.

  1. Sous Mes ressources>Agents>Agent hébergé, sélectionnez le nom de l’agent.
  2. Sélectionnez la version numérotée que vous venez de déployer.
  3. Dans Détails, attendez que l’état du déploiement indique que l’agent est en cours d’exécution. En cas d’échec, inspectez la sortie du déploiement avant de réessayer.
  4. Ouvrez Playground et envoyez la même demande que celle que vous avez testée localement.
  5. Passez en revue la réponse. Si vous avez ajouté des outils, envoyez une demande qui nécessite ces outils et inspectez les appels.

Les exécutions locales et cloud utilisent des informations d’identification, des environnements de dépendance et des chemins réseau différents. Une réponse locale réussie ne garantit pas une réponse distante réussie.

Inspecter et mettre à jour l’agent déployé

Utilisez le terrain de jeu distant pour tester et inspecter votre agent déployé. Contrairement aux tests locaux avec Agent Inspector, les requêtes dans ce bac à sable sont exécutées sur l’agent hébergé dans Foundry.

  1. Dans Foundry Toolkit, sélectionnez Developer Tools>Build>Hosted Agent Playground.

    Capture d’écran de Hosted Agent Playground sous Build dans la section Developer Tools de Foundry Toolkit.

  2. Dans la liste déroulante Agent hébergé , sélectionnez votre agent déployé et la version à inspecter. Ouvrez Playground pour envoyer une demande et afficher les détails de la réponse et de la session.

    La capture d’écran suivante montre une réponse de l’agent déployé illustrant, et non la sortie attendue de l’un ou l’autre exemple de flux de travail. Les identificateurs d’agent et de session sont masqués.

    Capture d’écran du terrain de jeu de l’agent hébergé à distance avec une réponse, des détails de session et des onglets d’inspection, avec des identificateurs d’agent et de session masqués.

Utilisez ces contrôles pour inspecter et mettre à jour l’agent. Les onglets disponibles dépendent de son protocole et de ses services connectés.

Task Action
Vérifier les détails du déploiement Ouvrez Details pour afficher le statut, la configuration et le point de terminaison pouvant être copié.
Tester une version Sélectionnez une version numérotée pour les demandes de terrain de jeu. Automatique suit la sélection de version du point de terminaison de service, qui n’est pas nécessairement la dernière version. Le sélecteur ne change pas le routage pour d’autres clients.
Passer en revue les journaux d’exécution Ouvrez Sessions, sélectionnez une session et affichez ses journaux. Les journaux d’exécution nécessitent une session ; la sortie de compilation est distincte. L’arrêt d’un flux de journal ou l’annulation d’une demande n’arrête pas l’agent hébergé.
Récupérer le code déployé Utilisez Télécharger la ressource de code pour un déploiement ZIP. Un déploiement d’images expose la référence d’image au lieu d’un projet source téléchargeable.
Mettre à jour le comportement Modifiez et testez le code local, puis répétez la procédure de déploiement avec l’agent existant pour créer une nouvelle version.

Utilisez Traces et Évaluation, si possible, pour l’analyse et la mesure de la qualité au-delà d’une seule réponse réussie. Suivez les conditions préalables pour le suivi d’agent hébergé et l’évaluation de l’agent hébergé.

Le déploiement donne à l’agent un point de terminaison pour une utilisation programmatique. Une étape de publication distincte n’est pas requise pour l’accès à l’API. La publication dans Teams ou Microsoft 365 est une tâche distincte. Consultez le point de terminaison de l’agent actuel et le modèle de publication.

Troubleshooting

Utilisez l’erreur signalée et l’exemple de configuration pour identifier l’étape défaillante.

Symptôme Action
Le démarrage local échoue, car un package est manquant. Vérifiez l’interpréteur ou le KIT SDK sélectionné, puis installez les dépendances à partir du répertoire source de l’exemple.
Le point de terminaison ou le modèle du projet est introuvable. Vérifiez FOUNDRY_PROJECT_ENDPOINT et AZURE_AI_MODEL_DEPLOYMENT_NAME. Ne remplacez pas un point de terminaison du compte ou un nom du catalogue de modèles.
L’authentification ou l’autorisation échoue. Vérifiez les informations d’identification locales et l’accès au projet. Passez en revue les autorisations de l’agent hébergé pour connaître les exigences de déploiement et d’identité d’exécution.
Agent Inspector ne peut pas se connecter. Vérifiez que le serveur a démarré et que le port 8088 est disponible. L’ouverture d’Inspector à elle seule ne démarre pas le serveur.
Un déploiement échoue. Passez en revue l’erreur de déploiement et la sortie de build. Pour le code, vérifiez le runtime, le point d’entrée, le mode package et ignorez les règles. Pour un conteneur, vérifiez les autorisations d’image et de Registre.
La réponse locale fonctionne, mais la version déployée échoue. Comparez l’environnement déployé et les autorisations d’identité à la configuration locale. Retestez la version exacte déployée.

Nettoyer les ressources

Arrêtez la session de débogage locale lorsque vous avez terminé. Si vous n’avez plus besoin de l’agent de test déployé, suivez Gérer les agents hébergés pour le supprimer.

La suppression de l’agent supprime ses versions et met fin à des sessions actives. Elle ne supprime pas toutes les ressources Azure associées.

Supprimez uniquement les ressources cloud créées pour cet exercice qu’aucune autre application n’utilise. Ne supprimez pas un projet Foundry partagé, un déploiement de modèle ou un registre de conteneurs.

Contenu connexe

Utilisez ces guides pour étendre votre flux de travail :

  • Dernière mise à jour :