Déployer un agent hébergé

Cet article vous montre comment déployer un agent conteneurisé sur Foundry Agent Service à l’aide de l’interface CLI Azure Développeur (azd), du sdk Python ou de l’API REST. Choisissez une méthode de déploiement à l’aide du sélecteur en haut de l’article. Utilisez les approches SDK ou REST lorsque vous souhaitez gérer les déploiements d’agents directement à partir de vos propres applications ou services.

Si vous effectuez un déploiement pour la première fois ou si vous souhaitez une procédure pas à pas guidée, consultez le guide de démarrage rapide : Créer et déployer un agent hébergé. Azure Developer CLI (azd) et l’extension VS Code gèrent automatiquement la génération, la publication, le versionnement et la configuration du RBAC.

Conseil

Préférez une boucle interne sans Docker ? Vous pouvez également déployer un agent hébergé directement à partir du code source - téléchargez un .zip de votre code Python ou .NET, et la plateforme le génère et l’héberge pour vous.

Si vous utilisez un agent de codage tel que GitHub Copilot, la compétence Microsoft Foundry peut vous aider à planifier le flux de déploiement de conteneur, à préparer azd des commandes et à connecter les étapes DU KIT SDK ou REST à votre projet.

Cycle de vie du déploiement

Chaque déploiement d’agent hébergé suit cette séquence :

  1. Générer et envoyer (push) : empaqueter le code de votre agent dans une image conteneur et l’envoyer à Azure Container Registry.
  2. Créer une version d’agent - Enregistrer l’image auprès du service Foundry Agent Service. La plateforme provisionne l’infrastructure et crée une identité d’agent Entra dédiée.
  3. Vérifier l’état - Attendez que le statut de la version atteigne active.
  4. Appel : envoyer des demandes au point de terminaison dédié de l’agent.

Conditions préalables

Autorisations requises

Vous avez besoin du rôle Foundry Project Manager au niveau du projet pour déployer un agent hébergé. Ce rôle accorde les autorisations de plan de données pour créer et mettre à jour des agents, ainsi que la possibilité de créer des attributions de rôles pour l’identité de l’agent créé par la plateforme si nécessaire. Pour obtenir une répartition détaillée des autorisations impliquées, consultez la référence des 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.

La plateforme crée une identité d’agent Microsoft Entra dédiée pour chaque agent hébergé au moment du déploiement. Cette identité est un principal de service que votre conteneur en cours d’exécution utilise pour appeler des modèles et des outils. Vous n’avez pas besoin de configurer manuellement les identités managé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.

Si vous utilisez azd ou l’extension VS Code, les outils gèrent automatiquement la plupart des affectations RBAC, y compris Container Registry Repository Reader pour l’identité managée du projet (tirage d’images).

Pour plus d’informations, consultez Authentification et autorisation.

Important

La prise en charge du placement des Azure Container Registry de votre agent hébergé derrière un réseau privé (point de terminaison privé avec accès au réseau public désactivé) dépend du moment où le projet Foundry a été créé. Les projets créés après le 25 juin 2026 prennent en charge un registre privé. Les projets créés avant cette date nécessitent que le Registre soit accessible sur son point de terminaison public afin que la plateforme puisse extraire l’image. Les projets existants ne sont pas affectés. Pour obtenir la liste complète des contraintes réseau, consultez Limitations.

Exigences des conteneurs

Votre image de conteneur doit répondre aux exigences suivantes pour s’exécuter sur la plateforme d’agent hébergé.

Important

La plateforme d’hébergement nécessite des images conteneur x86_64 (linux/amd64). Si vous générez sur Apple Silicon ou sur d’autres machines ARM, utilisez docker build --platform linux/amd64 . pour éviter de produire une image ARM incompatible.

Bibliothèques de protocole

Les agents hébergés communiquent avec la passerelle Foundry via des bibliothèques de protocole. Choisissez le protocole qui correspond au modèle d’interaction de votre agent :

Protocole bibliothèque Python bibliothèque .NET Point de terminaison Idéal pour
Réponses azure-ai-agentserver-responses Azure.AI.AgentServer.Responses /responses Chatbots conversationnels, streaming, interactions multiples avec historique géré par la plateforme
Invocations azure-ai-agentserver-invocations Azure.AI.AgentServer.Invocations /invocations Récepteurs webhook, traitement non conversationnel, flux de travail asynchrones personnalisés
Invocations (WebSocket) azure-ai-agentserver-invocations Azure.AI.AgentServer.Invocations /invocations_ws Streaming bidirectionnel : agents vocaux en temps réel, médias interactifs

Le protocole WebSocket utilise l’identificateur invocations_ws et est inclus dans le même paquet azure-ai-agentserver-invocations que la route HTTP /invocations, de sorte qu’un conteneur puisse prendre en charge les deux. Utilisez-le lorsque vous avez besoin d’un flux continu persistant en duplex intégral, par exemple pour envoyer le flux PCM du microphone vers l’agent et recevoir en retour l’audio synthétisé. Pour les scénarios vocaux, consultez Créer un agent vocal avec des agents hébergés.

Un seul conteneur peut exposer plusieurs protocoles simultanément en les déclarant lorsque vous créez l’agent ( dans le protocols champ du azure.ai.agent service dans azure.yaml, un appel du SDK ou une demande d’API REST) et en important les bibliothèques requises. Utilisez les bibliothèques de protocole dans votre infrastructure existante, que ce soit Microsoft Agent Framework, LangChain ou du code personnalisé.

Bibliothèque de protocole de réponses

Les bibliothèques Python et .NET pour le protocole Réponses implémentent l’API réponses IA Azure. Importez le package et implémentez un gestionnaire de réponses. La bibliothèque gère le routage, la diffusion en continu avec des événements envoyés par le serveur (SSE), l’exécution en arrière-plan, l’annulation, la mise en cache et la gestion du cycle de vie des réponses.

Implémenter un gestionnaire

Le gestionnaire est l’abstraction principale que vous implémentez. La bibliothèque l’appelle pour chaque requête entrante et remet les événements retournés aux clients via SSE. Dans Python, vous décorez une fonction asynchrone avec @app.response_handler:

from azure.ai.agentserver.responses import (
    CreateResponse,
    ResponseContext,
    ResponsesAgentServerHost,
    TextResponse,
)

app = ResponsesAgentServerHost()


@app.response_handler
async def handler(
    request: CreateResponse,
    context: ResponseContext,
    _cancellation_signal,
):
    user_input = await context.get_input_text() or ""
    return TextResponse(context, request, text=f"Echo: {user_input}")

Gestion automatique des événements et du cycle de vie

La bibliothèque gère la séquence d’événements ( numéros de séquence, index de sortie et de contenu et ID d’élément) et le cycle de vie de réponse complet automatiquement, de sorte que vous ne suivez pas cet état vous-même. Chaque événement produit par votre gestionnaire correspond directement à un événement SSE, que le framework hôte gère pour vous.

Modes de streaming et d’arrière-plan

  • Mode de diffusion en continu (par défaut) : les événements SSE sont remis en temps réel au client connecté.
  • Mode d’arrière-plan : le gestionnaire s’exécute jusqu’à la fin sans client SSE connecté. Les événements sont mis en mémoire tampon et disponibles pour la relecture via GET /responses/{id}.

Cycle de vie de la réponse

La bibliothèque orchestre le cycle de vie de réponse complet : created>in_progress->completed (ou failedcancelled ). La bibliothèque gère également automatiquement l’annulation, la gestion des erreurs et les garanties d’événements terminaux.

Sécurité des threads

Les instances de gestionnaire ont une portée limitée à chaque requête, de sorte que l’état propre à chaque requête ne se propage pas d’une requête à l’autre. La bibliothèque gère les requêtes simultanées en toute sécurité.

Pour voir des exemples fonctionnels, consultez les exemples Python « bring-your-own ».

Points de terminaison d’intégrité

Les bibliothèques de protocole exposent automatiquement un /readiness point de terminaison pour les vérifications d’intégrité de la plateforme. Vous n’avez pas besoin d’implémenter cela vous-même.

Port

Les conteneurs servent le trafic sur le port 8088 localement. En production, la passerelle Foundry gère le routage : votre conteneur n’a pas besoin d’exposer un port public.

Variables d’environnement injectées par la plateforme

La plateforme de l’agent hébergé injecte automatiquement des variables d’environnement dans votre conteneur au moment de l’exécution. Votre code peut lire ces variables sans les déclarer dans la env carte du azure.ai.agent service dans azure.yaml ou dans les paramètres des variables d’environnement REST et SDK. Le FOUNDRY_* préfixe est réservé à l’utilisation de la plate-forme.

Variable Objectif
FOUNDRY_PROJECT_ENDPOINT URL du point de terminaison de projet Foundry
FOUNDRY_PROJECT_ARM_ID ID de ressource ARM du projet Foundry
FOUNDRY_AGENT_NAME Nom de l’agent en cours d’exécution
FOUNDRY_AGENT_VERSION Version de l’agent en cours d’exécution
FOUNDRY_AGENT_SESSION_ID ID de session de la requête actuelle (conteneurs hébergés uniquement)
APPLICATIONINSIGHTS_CONNECTION_STRING "Chaîne de connexion « Application Insights » pour la télémétrie"

Ne redéclarez pas les variables injectées par la plateforme dans azure.yaml : elles sont définies automatiquement.

Les variables que vous déclarez vous-même, comme MODEL_DEPLOYMENT_NAME ou les points de terminaison MCP de la boîte à outils, se placent dans la carte env du service azure.ai.agent dans azure.yaml ou dans l’appel SDK create_version.

Important

Lorsque vous déployez votre agent hébergé sur Foundry Agent Service, la plateforme injecte automatiquement un chaîne de connexion Application Insights dans votre conteneur d’agent en tant que variable d’environnement, en activant le suivi OpenTelemetry par défaut. Pour afficher les traces distribuées, les demandes et les dépendances, ouvrez la ressource Application Insights approvisionnée lors de l’installation dans le portail Azure et accédez à Examiner > la recherche transactionnelle ou les performances. Utiliser azd ai agent monitor pour obtenir les journaux de console dynamiques. Lorsque AppInsights est activé, ce projet journalise les traces pour faciliter la surveillance et l’évaluation des interactions au niveau utilisateur avec les agents. Les membres du projet disposant du rôle Lecteur Log Analytics dans AppInsights peuvent afficher les données de traçage, qui peuvent contenir des données personnelles et/ou du Contenu Client. Si les tables Log Analytics sous-jacentes sont protégées, les membres ont plutôt besoin du rôle Lecteur de données de surveillance privilégié pour afficher ces données de trace. Passez en revue les données de trace collectées et qui peuvent afficher et utiliser ces données. Des frais supplémentaires liés à la tarification d’Azure Monitor App Insights peuvent s’appliquer. En savoir plus.

Référencer les connexions de projet dans les variables d’environnement

Au lieu de coder en dur les secrets (clés API, jetons, points de terminaison) dans azure.yaml ou votre image, extrayez-les à partir d’une connexion de projet Foundry au démarrage du bac à sable. Toute valeur que vous déclarez en tant que variable d’environnement peut être une expression d’espace réservé résolue par la plateforme avant le démarrage de votre conteneur.

Syntaxe de l’espace réservé

Un espace réservé se présente sous la forme ${{connections.<name>.<path>}}, où <name> est le nom de la ressource de la connexion (visible dans le portail sous Gérer>Détails du projet>Ressources connectées) et <path> est l’un des éléments suivants :

Chemin Est résolu en
credentials.<field> Champ secret sur la connexion
target La propriété target de la connexion (par exemple, une URL de point de terminaison)
metadata.<field> Champ sous la connexion metadata

Le nom du champ à utiliser dépend de la catégorie de connexion :

Catégorie de connexion Nom du champ dans le texte de substitution
ApiKey, AppInsights Toujours key--par exemple, credentials.key
CustomKeys Nom de clé que vous avez fourni lors de la création de la connexion, par exemple, credentials.github_token

Example

Tout d’abord, créez une CustomKeys connexion sur le projet qui contient le secret. Voir Ajouter une nouvelle connexion dans Microsoft Foundry. Ensuite, faites-y référence à partir de la carte env dans le service azure.ai.agent de azure.yaml :

services:
  my-agent:
    host: azure.ai.agent
    env:
      MODEL_DEPLOYMENT_NAME: gpt-5-mini
      GITHUB_TOKEN: ${{connections.agent-secrets.credentials.github_token}}

Au démarrage du sandbox, Foundry résout le marqueur de substitution et injecte la valeur résolue sous la forme d’une simple variable d’environnement. Votre code le lit comme n’importe quelle autre variable d’environnement :

import os
token = os.environ["GITHUB_TOKEN"]

Un GET sur la version de l’agent retourne le texte littéral ${{...}} - le secret résolu n’est jamais renvoyé par le biais de l’API de gestion.

Considerations

  • Créez la connexion avant de déployer la version. Si la connexion ou le champ référencé est absent au démarrage du bac à sable, l’espace réservé n’est pas résolu et la variable est vide.
  • Les secrets sont accessibles en écriture uniquement. Un GET sur une connexion renvoie credentials: null. Vérifiez la résolution en lisant la variable d’environnement depuis l’intérieur de votre conteneur en cours d’exécution, et non en inspectant la connexion.
  • Enregistrez vous-même les noms des champs CustomKeys. L’API de gestion ne les renvoie jamais après la création. Gardez-les à côté du code source de votre agent (par exemple, dans les modèles IaC ou à côté de azure.yaml) afin de pouvoir créer des espaces réservés ultérieurement sans avoir à les deviner.
  • Foundry gère le nom du secret sous-jacent. Lorsque vous créez la connexion, Foundry stocke la valeur dans Key Vault sous un nom choisi. Vous ne pouvez pas référencer un secret Key Vault préexistant par nom. Pour associer votre propre Key Vault en tant que magasin de stockage principal, consultez Configurer une connexion à Key Vault.

Empaqueter et tester votre agent localement

Avant de déployer sur Foundry, vérifiez que votre agent fonctionne localement à l’aide de la bibliothèque de protocole. Le conteneur sert les mêmes points de terminaison localement qu’en production.

Tester le protocole réponses

POST http://localhost:8088/responses
Content-Type: application/json

{
    "input": "Where is Seattle?",
    "stream": false
}

Tester le protocole Invocations

POST http://localhost:8088/invocations
Content-Type: application/json

{
    "message": "Hello!"
}

Déployer avec Azure Developer CLI ou VS Code

L’interface CLI Azure développeur (azd) et la Microsoft Foundry Toolkit pour Visual Studio Code automatiser le cycle de vie de déploiement complet : création du conteneur, envoi (push) vers Azure Container Registry, création de la version de l’agent et attribution de rôles RBAC. Pour obtenir une procédure pas à pas guidée pour la première fois, consultez le guide de démarrage rapide : Créer et déployer un agent hébergé.

Déployer avec une commande

À partir de votre répertoire de projet d’agent, approvisionnez l’infrastructure et déployez en une seule étape :

azd up

azd up associe azd provision, qui crée le projet Foundry, le déploiement du modèle, le registre de conteneurs, Application Insights et l’identité managée, à azd deploy. Utilisez-le pour les déploiements de première fois ou chaque fois que vous modifiez le code de l’infrastructure et de l’agent.

Déployer les modifications de code uniquement

Si vous avez déjà provisionné vos ressources Azure et que vous n’avez besoin que d’envoyer (push) une nouvelle version de l’agent :

azd deploy

Pendant azd deploy, le CLI :

  1. Génère votre image conteneur à distance dans Azure Container Registry, vous n'avez donc pas besoin de Docker local.
  2. Elle envoie (push) l’image au registre.
  3. Crée une version hébergée de l’agent sur Foundry Agent Service.
  4. Crée une identité d’agent Microsoft Entra dédiée et affecte les rôles RBAC dont l’agent a besoin pour accéder aux modèles et outils.

Gérer les versions

Chacun azd deploy crée une nouvelle version de l’agent. L’interface CLI conserve les versions précédentes et la dernière version est active par défaut.

Vérifier le déploiement

azd ai agent show

La sortie inclut le nom de l’agent, la version, les protocoles, les ressources de conteneur, les variables d’environnement et l’horodatage de création. Utiliser --output table pour une vue récapitulative.

Générer des images localement

Par défaut, azd génère des images conteneur à distance dans Azure Container Registry. Pour générer des images localement, définissez remoteBuild: false dans azure.yaml. Les builds locales nécessitent Docker Desktop.

Pour filtrer les requêtes et les réponses conformément à une politique de sécurité du contenu, ajoutez un garde-fou de sécurité du contenu à votre agent.

Déployer à l’aide du Kit de développement logiciel (SDK) Python

Utilisez le Kit de développement logiciel (SDK) lorsque vous souhaitez gérer les déploiements d’agents directement à partir de Python code.

Prérequis supplémentaires

Générer et pousser votre image de conteneur

  1. Générez votre image Docker :

    docker build --platform linux/amd64 -t myagent:v1 .
    

    Consultez des exemples de fichiers Dockerfiles pour Python et C#.

  2. Pousser vers Azure Container Registry :

    az acr login --name myregistry
    docker tag myagent:v1 myregistry.azurecr.io/myagent:v1
    docker push myregistry.azurecr.io/myagent:v1
    

Conseil

Utilisez des balises d’image uniques au lieu de :latest pour les déploiements reproductibles.

Configurer des autorisations de registre de conteneurs

Accordez l’accès à l’identité managée de votre projet pour extraire des images :

  1. Dans le portail Azure, accédez à votre ressource de projet Foundry.

  2. Sélectionnez Identité et copiez l’ID d’objet (principal) sous Système affecté.

  3. Attribuez le rôle Lecteur du référentiel du registre de conteneurs à cette identité sur votre registre de conteneurs. Consultez Azure Container Registry rôles et autorisations.

Créer une version de l’agent hébergé

Lorsque vous créez une version, la plateforme provisionne automatiquement l’agent. Il n’y a pas d’étape de début distincte. La plateforme génère un instantané de conteneur et prépare l’agent à traiter les demandes.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import (
    AgentEndpointProtocol,
    ContainerConfiguration,
    HostedAgentDefinition,
    ProtocolVersionRecord,
)
from azure.identity import DefaultAzureCredential

# Format: "https://resource_name.services.ai.azure.com/api/projects/project_name"
PROJECT_ENDPOINT = "your_project_endpoint"

# Create project client
credential = DefaultAzureCredential()
project = AIProjectClient(
    endpoint=PROJECT_ENDPOINT,
    credential=credential,
)

# Create a hosted agent version
agent = project.agents.create_version(
    agent_name="my-agent",
    definition=HostedAgentDefinition(
        protocol_versions=[
            ProtocolVersionRecord(protocol=AgentEndpointProtocol.RESPONSES, version="1.0.0")
        ],
        cpu="1",
        memory="2Gi",
        container_configuration=ContainerConfiguration(
            image="your-registry.azurecr.io/your-image:tag"
        ),
        environment_variables={
            "MODEL_DEPLOYMENT_NAME": "gpt-5-mini"
        },
    )
)

print(f"Agent created: {agent.name}, version: {agent.version}")

Pour exposer les deux protocoles, passez les deux dans protocol_versions:

protocol_versions=[
    ProtocolVersionRecord(protocol=AgentEndpointProtocol.RESPONSES, version="1.0.0"),
    ProtocolVersionRecord(protocol=AgentEndpointProtocol.INVOCATIONS, version="1.0.0"),
    ProtocolVersionRecord(protocol=AgentEndpointProtocol.INVOCATIONS_WS, version="1.0.0"),
],

Paramètres clés :

Paramètre Description
agent_name Nom unique (alphanumérique avec traits d’union, 63 caractères maximum)
container_configuration.image URL complète de l'image dans Azure Container Registry avec étiquette
cpu Allocation du processeur (par exemple, "1")
memory Allocation de mémoire (par exemple, "2Gi")
protocol_versions Protocoles que le conteneur expose (responses, invocationsou les deux)

Pour définir quand le calcul de session est inactif, consultez Gérer l’inactivité de la session.

Interroger l’état de la version

Après la création d’une version, interrogez jusqu’à ce que son statut atteigne active avant de solliciter l’agent. L’approvisionnement prend généralement moins d’une minute en fonction de la taille de l’image.

import time

# Poll until the agent version is active
while True:
    version_info = project.agents.get_version(
        agent_name="my-agent",
        agent_version=agent.version
    )
    status = version_info["status"]
    print(f"Status: {status}")

    if status == "active":
        print("Agent is ready!")
        break
    elif status == "failed":
        print(f"Provisioning failed: {version_info['error']}")
        break

    time.sleep(5)

Valeurs d’état de version :

Statut Description
creating Approvisionnement d’infrastructure en cours
active L’agent est prêt à traiter les demandes
failed Échec de l’approvisionnement : vérifiez le error champ pour plus d’informations
deleting La version est en cours de nettoyage
deleted La version a été entièrement supprimée

Appeler l’agent

Une fois que la version atteint le statut active, utilisez get_openai_client pour créer un client OpenAI lié au point de terminaison de l'agent.

Pour le protocole Réponses :

# Create an OpenAI client bound to the agent endpoint
openai_client = project.get_openai_client(agent_name="my-agent")

response = openai_client.responses.create(
    input="Hello! What can you do?",
)

print(response.output_text)

Pour le protocole Invocations , appelez directement le point de terminaison d’appel :

import requests

token = credential.get_token("https://ai.azure.com/.default").token
url = f"{PROJECT_ENDPOINT}/agents/my-agent/endpoint/protocols/invocations"

response = requests.post(url, headers={
    "Authorization": f"Bearer {token}",
    "Content-Type": "application/json",
}, params={"api-version": "v1"}, json={
    "message": "Process this task"
})

print(response.json())

Pour obtenir des exemples plus complets, consultez les exemples d’agents hébergés.

Déployer à l’aide du Kit de développement logiciel (SDK) JavaScript/TypeScript

Utilisez le Kit de développement logiciel (SDK) lorsque vous souhaitez gérer les déploiements d’agents directement à partir de Node.js code. L'appelant du Kit de développement logiciel (SDK) s'exécute dans Node.js, mais l'image conteneur elle-même exécute toujours votre code d'agent Python ou .NET généré avec les bibliothèques de protocole Réponses ou Invocations : il n'existe aucun runtime d'agent hébergé Node.js.

Prérequis supplémentaires

  • Node.js 22 ou version ultérieure

  • Image conteneur dans Azure Container Registry

  • Rôle de référentiel Container Registry ou AcrPush sur le registre de conteneurs (pour pousser des images)

  • Les packages @azure/identity et @azure/ai-projects

    npm install @azure/ai-projects @azure/identity
    

Avant de commencer, générez et envoyez (push) votre image conteneur à Azure Container Registry (consultez l’onglet Python par exemple commandes Docker) et accordez à l’identité managée du projet le rôle Lecteur du référentiel du Registre de conteneurs sur le Registre.

Créer une version de l’agent hébergé

Lorsque vous créez une version, la plateforme provisionne automatiquement l’agent. Il n’y a pas d’étape de début distincte. La plateforme génère un instantané de conteneur et prépare l’agent à traiter les demandes.

import { AIProjectClient } from "@azure/ai-projects";
import { DefaultAzureCredential } from "@azure/identity";

// Format: "https://resource_name.services.ai.azure.com/api/projects/project_name"
const projectEndpoint =
  process.env["FOUNDRY_PROJECT_ENDPOINT"] || "your_project_endpoint";
const agentName = "my-agent";

const project = new AIProjectClient(
  projectEndpoint,
  new DefaultAzureCredential(),
);

// Create a hosted agent version
const agent = await project.agents.createVersion(agentName, {
  kind: "hosted",
  cpu: "1",
  memory: "2Gi",
  container_configuration: {
    image: "your-registry.azurecr.io/your-image:tag",
  },
  protocol_versions: [{ protocol: "responses", version: "1.0.0" }],
  environment_variables: { MODEL_DEPLOYMENT_NAME: "gpt-5-mini" },
});

console.log(`Agent created: ${agent.name}, version: ${agent.version}`);

Pour exposer les deux protocoles, passez les deux dans protocol_versions:

protocol_versions: [
  { protocol: "responses", version: "1.0.0" },
  { protocol: "invocations", version: "1.0.0" },
  { protocol: "invocations_ws", version: "1.0.0" },
],

Interroger l’état de la version

Après la création d’une version, interrogez jusqu’à ce que son statut atteigne active avant de solliciter l’agent. L’approvisionnement prend généralement moins d’une minute en fonction de la taille de l’image.

function sleep(ms: number) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

// Poll until the agent version is active
for (;;) {
  const versionInfo = await project.agents.getVersion(
    agentName,
    agent.version,
  );
  console.log(`Status: ${versionInfo.status}`);
  if (versionInfo.status === "active") {
    break;
  }
  if (versionInfo.status === "failed") {
    console.log(`Provisioning failed: ${versionInfo.error}`);
    break;
  }
  await sleep(5_000);
}

Router le point de terminaison de l’agent et l’invoquer

Routez le point de terminaison de l’agent vers la version que vous avez créée, puis liez un client OpenAI au point de terminaison.

Pour le protocole Réponses :

await project.agents.patchAgentObject(agentName, {
  agentEndpoint: {
    version_selector: {
      version_selection_rules: [
        {
          type: "FixedRatio",
          agent_version: agent.version,
          traffic_percentage: 100,
        },
      ],
    },
    protocol_configuration: { responses: {} },
  },
});

// Create an OpenAI client bound to the agent endpoint
const openAIClient = project.getOpenAIClient({
  azureConfig: { allowPreview: true, agentName },
});

const response = await openAIClient.responses.create({
  input: "Hello! What can you do?",
});
console.log(response.output_text);

Pour le protocole Invocations , appelez directement le point de terminaison d’appel :

const credential = new DefaultAzureCredential();
const token = await credential.getToken("https://ai.azure.com/.default");
if (!token) {
  throw new Error("Failed to acquire an access token.");
}
const url = `${projectEndpoint}/agents/my-agent/endpoint/protocols/invocations`;

const response = await fetch(`${url}?api-version=v1`, {
  method: "POST",
  headers: {
    Authorization: "Bearer " + token.token,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ message: "Process this task" }),
});
console.log(await response.json());

Référence : AIProjectClient

Déployer à l’aide de l’API REST

Utilisez l’API REST pour les déploiements basés sur HTTP directs ou lors de l’intégration à des outils personnalisés.

Avant de commencer, générez et envoyez (push) votre image conteneur à Azure Container Registry, puis accordez à l’identité managée du projet le rôle Lecteur du référentiel du Registre de conteneurs sur le Registre.

Configurer des variables

BASE_URL="https://{account}.services.ai.azure.com/api/projects/{project}"
API_VERSION="v1"
TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

Créer un agent

curl -X POST "$BASE_URL/agents?api-version=$API_VERSION" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-agent",
    "definition": {
      "kind": "hosted",
      "container_configuration": {
        "image": "myacr.azurecr.io/my-agent:v1"
      },
      "cpu": "1",
      "memory": "2Gi",
      "protocol_versions": [
        {"protocol": "responses", "version": "1.0.0"}
      ],
      "environment_variables": {
        "MODEL_DEPLOYMENT_NAME": "gpt-5-mini"
      }
    }
  }'

La création d’un agent crée également une version 1 et déclenche l’approvisionnement.

Pour définir quand le calcul de session est inactif, consultez Gérer l’inactivité de la session.

Pour analyser les requêtes et les réponses au regard d’une politique de sécurité du contenu, incluez un objet rai_config dans le definition. Consultez Ajouter un garde-fou de sécurité de contenu à un agent hébergé.

Interroger l’état de la version

Sondez le point de terminaison de version jusqu’à ce que status soit active :

while true; do
  STATUS=$(curl -s -X GET "$BASE_URL/agents/my-agent/versions/1?api-version=$API_VERSION" \
    -H "Authorization: Bearer $TOKEN" | jq -r '.status')
  echo "Status: $STATUS"
  [ "$STATUS" = "active" ] && echo "Ready!" && break
  [ "$STATUS" = "failed" ] && echo "Provisioning failed." && exit 1
  sleep 5
done

Appeler l’agent

Utilisez le point de terminaison dédié de l’agent pour envoyer des demandes. Définir "stream": true pour recevoir les événements envoyés par le serveur.

Protocole réponses :

curl -X POST "$BASE_URL/agents/my-agent/endpoint/protocols/openai/responses?api-version=$API_VERSION" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "input": "Hello! What can you do?",
    "store": true
  }'

Protocole d’appel :

curl -X POST "$BASE_URL/agents/my-agent/endpoint/protocols/invocations?api-version=$API_VERSION" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Process this task"
  }'

Créer une nouvelle version

Déployez le code ou la configuration mis à jour en créant une nouvelle version :

curl -X POST "$BASE_URL/agents/my-agent/versions?api-version=$API_VERSION" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "definition": {
      "kind": "hosted",
      "container_configuration": {
        "image": "myacr.azurecr.io/my-agent:v2"
      },
      "cpu": "1",
      "memory": "2Gi",
      "protocol_versions": [
        {"protocol": "responses", "version": "1.0.0"}
      ],
      "environment_variables": {
        "MODEL_DEPLOYMENT_NAME": "gpt-5-mini"
      }
    }
  }'

Nettoyer les ressources

Pour éviter les frais, nettoyez les ressources une fois terminées. L’agent de déprovisionnement de plateforme calcule après le délai d’inactivité configuré, qui est de 15 minutes par défaut, il n’y a donc aucun coût lorsqu’un agent ne répond pas aux demandes.

Nettoyage de l'Azure Developer CLI

azd down

Nettoyage du Kit de développement logiciel (SDK

Supprimez une seule version :

project.agents.delete_version(agent_name="my-agent", agent_version=agent.version)

Ou supprimez l’ensemble de l’agent et toutes ses versions. Permet force=True de supprimer en cascade toutes les sessions actives, telles que juste après avoir appelé l’agent ; sans cela, l’appel échoue avec une erreur de conflit pendant que les sessions sont actives :

project.agents.delete(agent_name="my-agent", force=True)

Nettoyage du Kit de développement logiciel (SDK

Supprimez une seule version :

await project.agents.deleteVersion("my-agent", agent.version);

Ou supprimez l’ensemble de l’agent et toutes ses versions :

await project.agents.delete("my-agent", { force: true });

Référence : AIProjectClient

Nettoyage de l’API REST

Supprimez une seule version :

curl -X DELETE "$BASE_URL/agents/my-agent/versions/1?api-version=$API_VERSION" \
  -H "Authorization: Bearer $TOKEN"

Ou supprimez l’agent entier :

curl -X DELETE "$BASE_URL/agents/my-agent?api-version=$API_VERSION" \
  -H "Authorization: Bearer $TOKEN"

Avertissement

La suppression d’un agent supprime toutes ses versions et met fin à des sessions actives. Cette action ne peut pas être annulée.

Dépannage

Les erreurs d'approvisionnement s'affichent sur les champs error.code et error.message de l'objet de version. Vérifiez l’état de la version après la création pour identifier les problèmes.

Code d’erreur Code HTTP Solution
image_pull_failed 400 Vérifiez l’URI de l’image. Vérifiez que l’identité managée du projet dispose du rôle Lecteur de référentiel pour Container Registry sur l’ACR et que l’état de la stratégie azureADAuthenticationAsArmPolicy du registre est enabled
SubscriptionIsNotRegistered 400 Inscrire le fournisseur d’abonnement
InvalidAcrPullCredentials 401 Corriger l’identité managée ou le RBAC du registre
UnauthorizedAcrPull 403 Fournir des informations d’identification ou une identité correctes
AcrImageNotFound 404 Corriger le nom/la balise de l'image ou publier l'image
RegistryNotFound 400/404 Réparer le registre DNS ou l'accessibilité du réseau

Pour les erreurs 5xx, contactez Microsoft support technique.

Pour connaître les exigences RBAC détaillées et la résolution des problèmes d’autorisation, consultez les informations de référence sur les autorisations de l’agent hébergé.

Étapes suivantes