Environnement d’exécution des agents sans serveur dans Azure Functions

L’environnement d’exécution serverless des agents Azure Functions est un modèle de programmation permettant de créer des agents d’IA pilotés par les événements sous forme d’applications Azure Functions. Les agents peuvent partir de requêtes HTTP, de minuteurs, de files d’attente, de blobs, de modifications de base de données ou d’événements Connector. Vous définissez des agents dans des .agent.md fichiers, configurez les outils et les paramètres par défaut à l’exécution en parallèle de votre projet, et déployez l’application comme n’importe quelle autre application de fonctions. L’environnement d’exécution gère l’enregistrement des déclencheurs, les appels aux modèles, l’assemblage des outils, l’historique des sessions et l’observabilité sur une infrastructure sans serveur.

Important

L’environnement d’exécution des agents serverless est actuellement en préversion. Les fonctionnalités, les noms de configuration et les connecteurs pris en charge peuvent changer avant la disponibilité générale.

Quand utiliser l’environnement d’exécution des agents serverless

Utilisez le runtime d’agents serverless lorsque votre agent est piloté par des événements, s’appuie sur de nombreux outils ou est étroitement lié aux charges de travail d’Azure Functions sur le plan opérationnel. Les scénarios pour l’exécution de l’agent serverless incluent :

  • Agents d’arrière-plan programmés qui résument, surveillent, effectuent des rapprochements ou génèrent des rapports.
  • Assistants pilotés par les événements qui réagissent aux messages, aux e-mails, aux alertes, aux messages de file d’attente ou aux modifications de données.
  • Agents inter-systèmes qui utilisent des connecteurs pour coordonner le travail entre les applications SaaS et d’entreprise.
  • Interfaces conversationnelles qui exposent le même agent via HTTP, une interface de chat ou MCP.
  • Assistants devant pouvoir être ramenés à zéro et utiliser l’identité gérée, la supervision, les emplacements de déploiement et d’autres fonctionnalités d’hébergement Azure.

Dans les scénarios suivants, l’exécution de l’agent serverless n’est peut-être pas la meilleure option :

Scenario Meilleure option
Exposer des fonctions déterministes comme outils pour un autre client IA extension MCP pour Azure Functions
Orchestration de longue durée en plusieurs étapes avec validation humaine intégrée Fonctions durables
Constructeur d’agents sans code Copilot Studio ou Foundry agents de prompts

Pour une comparaison détaillée avec d’autres options d’agents Microsoft, voir Comparer le runtime des agents serverless avec d’autres options d’agents Microsoft.

Tip

Pour essayer l’exécution des agents serverless, voir Build serverless agents using Azure Functions. En utilisant un azd modèle, vous pouvez déployer une application fonctionnelle sur Azure en quelques minutes.

Pourquoi créer des agents sur Azure Functions ?

Les agents de production ont besoin de plus qu’un prompt et un modèle. Ils ont besoin de moyens fiables pour démarrer le travail, appeler des systèmes externes, conserver l’historique des conversations, exécuter du code non approuvé en toute sécurité, s’authentifier sans secrets, émettre des données de télémétrie et mettre à l’échelle à la demande.

Functions fournit un modèle de calcul piloté par les événements pour ces préoccupations opérationnelles. L’exécution des agents serverless applique simplement ce même modèle au code de votre agent. Voici quelques avantages d’utiliser le runtime des agents serverless pour construire et exécuter le code de votre agent :

  • Les agents sont l’unité de travail. Chaque agent est défini dans un fichier markdown séparé.
  • Les événements déclenchent les assistants. Functions déclenche les agents de démarrage à partir de plannings, requêtes HTTP, messages de file d’attente, changements de blobs, événements Event Grid, messages Service Bus et autres événements pris en charge.
  • Les fonctionnalités sont configurées en premier, avec du code quand vous en avez besoin. Vous pouvez configurer des agents pour utiliser des serveurs MCP distants, des serveurs MCP hébergés dans des espaces de noms de connecteurs, des compétences et des exécutions de code en mode bac à sable. Écris tes propres outils basés sur Python pour la logique spécifique à chaque application.
  • L’hébergement sans serveur est disponible. L’environnement d’exécution des agents serverless prend en charge les plans Flex Consumption et Dedicated (App Service). Le plan Flex Consumption offre une mise à l’échelle jusqu’à zéro, une facturation à la seconde et une mise à l’échelle automatique. Les deux plans prennent en charge l’identité gérée, l’intégration réseau virtuel et l’intégration Application Insights.
  • La plomberie opérationnelle est intégrée. Le runtime gère la découverte de l’agent, l’enregistrement des déclencheurs, l’assemblage des outils, l’historique de session et les points de terminaison intégrés optionnels.

Définition du Project

Une application d’agents serverless est un projet standard d’application de fonctions Python v2, déployé avec des fichiers propres aux agents. Les fichiers de projet suivants sont toujours requis pour les applications de fonctions Python :

Fichier Purpose
function_app.py Importe create_function_app() et retourne l’application Azure Functions configurée.
host.json Configure l’hôte Azure Functions.
requirements.txt Inclut le package d’exécution des agents serverless et toutes les dépendances Python spécifiques à l’application.

Pour plus d’informations, consultez le guide de référence développeur Azure Functions pour les applications Python.

Fichiers de l’environnement d’exécution de l’agent

L’exécution découvre ces fichiers et dossiers spécifiques à l’agent, qui sont déployés avec le projet applicatif :

Fichier ou dossier Purpose
*.agent.md Définit les agents. L’en-tête YAML configure l’agent, et le corps du document Markdown devient les instructions. Votre projet doit avoir au moins un fichier de définition d’agent.
agents.config.yaml (Optionnel) Définit les paramètres d’exécution par défaut à l’échelle de l’application, tels que le modèle, le délai d’expiration et les paramètres du bac à sable.
mcp.json Définit les serveurs HTTP MCP distants que les agents peuvent utiliser comme outils, y compris des outils de connecteur pour des tâches telles que l’envoi d’emails ou la collaboration avec Teams.
tools/ (Optionnel) Contient tous les outils Python personnalisés que vous créez pour fournir des fonctionnalités non déjà fournies par les serveurs MCP, les connexions, les compétences ou les exécutions en sandbox.
skills/ (Optionnel) Contient des prompts réutilisables SKILL.md que les agents peuvent charger selon les besoins.

Chaque fichier d’agent utilise un en-tête YAML suivi d’instructions en Markdown. Cet exemple définit un agent déclenché par minuterie qui s’exécute quotidiennement à 15h (UTC) :

---
name: Daily Tech News Email
description: Fetches top tech news and emails a summary daily.

trigger:
  type: timer_trigger
  args:
    schedule: "0 0 15 * * *"
---

You are a news assistant. When triggered, do the following:

1. Gather today's top technology news from reputable sources.
1. Summarize the stories in a concise HTML email body.
1. Email the summary to $TO_EMAIL with the subject "Daily Tech News Summary".

Les métadonnées d’en-tête indiquent comment l’agent est invoqué. Le corps en Markdown est le bloc d’instructions que l’environnement d’exécution transmet au modèle pendant l’exécution. La substitution de variable d’environnement permet aux instructions et aux valeurs de configuration de référencer les paramètres d’application tels que $TO_EMAIL.

Chaque .agent.md fichier définit un agent. Le nom du fichier est utilisé pour déterminer le nom de la fonction Azure et le segment de route pour les points de terminaison intégrés. Le champ name est un nom affiché dans les journaux, les étiquettes et la documentation.

Pour la liste complète des champs de fichiers d’agent, des options de configuration de l’application et des règles de substitution de variables, voir Serverless agents runtime reference.

Processus de démarrage d’applications

Lorsque l’hôte Fonctions charge l’application, la create_function_app méthode découvre les fichiers agents (triggers), les serveurs MCP, les compétences et les outils personnalisés dans le projet. Il valide la configuration, assemble les outils pour chaque agent, et enregistre les déclencheurs et terminaux requis.

Lorsqu’un déclencheur spécifique à un agent se déclenche, l’exécution construit l’agent avec ses instructions résolues, son modèle, ses outils et son historique de session, puis l’exécute en utilisant le cadre Microsoft Agent.

Déclencher des agents à partir d’événements

L’exécution prend en charge plusieurs déclencheurs d’agents dans votre application, mais un seul déclencheur par fichier d’agent. Une définition de déclencheur a un type objet et un args objet. type identifie la liaison du déclencheur, et args contient les paramètres spécifiques au déclencheur qui configurent l’événement qui démarre l’agent.

Les modèles de déclencheur courants sont les suivants :

Motif Exemple
agent utilisateur HTTP Recevez une demande, des outils d’appel et retournez une réponse structurée.
Agent planifié Lancez un rapport quotidien, une synthèse, un nettoyage ou un processus de rapprochement.
Agent de file d’attente ou de message Traitez les éléments de travail qui nécessitent un raisonnement du modèle ou des appels à des outils.
Agent d’événements de stockage ou de base de données Réagir aux fichiers, enregistrements ou événements modifiés.
Agent déclenché par le connecteur Réagir aux événements issus de connecteurs gérés, tels que les messages Teams, les courriels Outlook ou les événements de calendrier supportés par le connecteur.

Pour des détails sur la configuration des déclencheurs, les types pris en charge et la args référence, consultez la référence de l’environnement d’exécution des agents serverless.

Donner des outils aux agents

L’exécution des agents serverless prend en charge plusieurs types d’outils. Commencez avec des capacités configurées, et utilisez des outils Python personnalisés pour la logique spécifique à l'application qui ne correspond pas à ces options.

Serveurs MCP distants

Définissez des serveurs HTTP distants ou HTTP MCP streamables dans mcp.json. Le runtime découvre ces serveurs et met leurs outils à disposition de tous les agents. Utilisez des serveurs MCP distants lorsque les agents doivent appeler des outils hébergés par un autre service ou composer des agents et des outils dans les limites de l’application.

connecteurs Azure

Les connecteurs permettent aux agents d’utiliser des services externes sans code client d’API personnalisé. Un espace de noms de connecteur héberge des connexions, des déclencheurs et des serveurs MCP pour des services tels que Microsoft 365 Outlook, Teams, Salesforce, SAP ou SQL. Utilisez des déclencheurs de connecteurs pour démarrer des agents à partir d’événements externes, et des outils MCP de connecteurs pour appeler des actions de service à partir des instructions d’agent.

Compétences

Enregistrez les ressources de prompt réutilisables dans skills/. Chaque dossier de compétences contient un SKILL.md fichier avec un nom, une description et des instructions de markdown. Le runtime découvre automatiquement les compétences et les met à disposition des agents. Les compétences aident à garder les instructions de base des agents de base réduites tout en rendant des conseils spécifiques au domaine disponibles lorsque c’est nécessaire.

Exécution en bac à sable

L’environnement d’exécution peut utiliser les sessions dynamiques d’Azure Container Apps pour fournir aux agents un outil execute_python. Cet outil exécute Python dans un pool de sessions isolé, ce qui est utile pour l’exécution de code et l’analyse de données. Configurez le point de terminaison du pool de session dans agents.config.yaml.

Outils de Python personnalisés

Utilisez des outils Python personnalisés pour les capacités spécifiques à chaque application. Ajoutez des fichiers .py au dossier tools/ et annotez les fonctions avec @tool du package d’exécution. Le runtime découvre et enregistre automatiquement ces outils.

Pour des détails de configuration, des tables de champs et des exemples de code pour chaque type d’outil, voir Référence d’exécution des agents sans serveur.

Sessions et état

Les interactions d’assistant à plusieurs tours nécessitent un historique de session. Dans Azure, l’environnement d’exécution stocke l’historique des sessions dans Stockage Blob via le compte AzureWebJobsStorage de l’application de fonction. Pour le développement local, l’environnement d’exécution bascule sur un historique de session fondé sur des fichiers. L’exécution en bac à sable tient également compte de la session et utilise des sessions isolées pour des exécutions d’agent sans lien entre elles.

Observability

À partir de azure-functions-agents-runtime la version 0.1.0b6, l’exécution inclut un ensemble de fonctionnalités d’observabilité encore en développement actif et sujet à modifications.

Pour les dernières configurations, champs de télémétrie et conseils d’utilisation, utilisez la documentation du dépôt d’exécution :

Contenu connexe

  • Last updated on