Déployer des agents sur Azure Databricks

Pour exécuter un agent en production, vous déployez son code sur une infrastructure de calcul gérée qui répond aux requêtes de vos utilisateurs et applications. Un agent déployé comporte trois couches : votre framework ou harnais, un serveur d’agents et un runtime d’agent. Agent Bricks offre des options à chaque couche, de DurableAgentServer jusqu’à Agent Runtime sur Databricks Apps.

La pile de calcul de l’agent

Un agent déployé comporte trois couches. Chaque couche enveloppe celle au-dessus.

Couche	Qu’est-ce que cela fait ?	Options sur Azure Databricks
Framework ou harnais	Il exécute la boucle agent : appelle des modèles et des outils et décide de la suite à faire.	Tout framework ou environnement, comme LangGraph ou le SDK OpenAI Agents, ou un méta-environnement comme Omnigent.
Serveur d’agent	Encapsule la boucle agent dans un serveur HTTP. Le serveur agent expose l’API d’invocation, gère les connexions clients et gère la durabilité.	DurableAgentServer (recommandé), serveurs agents hérités, ou votre propre serveur.
Exécution de l’agent	Exécute le serveur d’agent sur une infrastructure de calcul gérée et gère l’hébergement, l’identité et la mise à l’échelle.	Runtime d’agent sur Databricks Apps.

Les termes suivants décrivent comment les calques fonctionnent ensemble :

Terme	Ce que cela signifie
API d’invocation	L’API HTTP que les clients appellent pour exécuter l’agent. Voir les agents de requête déployés sur Azure Databricks.
Servir	L’environnement d’exécution de l’agent exécute le serveur d’agents, qui sert votre agent via l’API d’invocation.
Deploy	Mettez le code de votre agent sur l’environnement d’exécution de l’agent.

Note

Databricks Sandbox n’est pas une couche de la pile de calcul. C’est un outil que votre agent appelle pour exécuter du code dans un environnement isolé, séparé de l’exécution de l’agent, avec un accès restreint à un périmètre de vos données gouvernées. Utilisez un bac à sable lorsque votre agent écrit et exécute du code, comme des scripts d’analyse de données. Pour ajouter à un projet avec interface de ligne de commande un outil de bac à sable, exécutez agentbricks tools add sandbox.

Framework ou harnais

Le framework ou harnais est votre code d’agent. Il exécute la boucle qui raisonne avec un modèle, appelle des outils et décide quand répondre. Agent Bricks ne nécessite pas de framework spécifique.

Framework ou harnais	Quand utiliser
Templates	Démarrage d’un nouvel agent. Le CLI Agent Bricks génère la structure de projets pour LangGraph et le SDK OpenAI Agents. Les gabarits gardent votre code du framework séparé de celui qui le relie au serveur agent.
Agents existants	Importer un agent que vous avez déjà créé avec LangGraph ou le SDK OpenAI Agents. Exécutez agentbricks init --existing dans son répertoire. Voir Importer un agent existant.
Meta-harnais	Composer plusieurs harnais, tels que des agents de codage, en un seul agent avec Omnigent.

Serveur Agent

Le serveur agent est une bibliothèque qui encapsule votre boucle d’agent et la transforme en service. Il définit l’API que les clients appellent, suit chaque exécution et détermine ce qui se passe lorsqu’une exécution est interrompue.

Serveur Agent	Quand utiliser
DurableAgentServer (recommandé)	Nouveaux agents créés avec la CLI Agent Bricks.
Serveurs d’agent hérités	Maintenance des agents construits à partir des modèles d’application. Pour comparer DurableAgentServer avec les serveurs agents hérités, voir Comparer serveurs agents sur Azure Databricks.
Votre propre serveur	Des agents qui ont besoin de points de terminaison personnalisés, de formats de requête ou de protocoles. Exécutez agentbricks init --server custom, ou gardez votre serveur actuel.

Environnement d'exécution de l’agent

L’environnement d’exécution de l’agent est la ressource de calcul gérée qui exécute le serveur de votre agent. Vous déployez du code dessus au lieu de provisionner vous-même les serveurs.

Environnement d'exécution de l’agent	Quand utiliser
Runtime de l’agent	Nouveaux agents. Fait tourner votre agent sur Databricks Apps. agentbricks deploy provisionne les ressources dont votre agent a besoin, lui accorde l’accès à celles-ci, puis le déploie sur un point de terminaison stable et authentifié.
Service de modèles (hérité)	Les agents anciens étaient déployés sur les points de terminaison de mise en service de modèles. Consultez Déployer un agent pour les applications IA (Service de modèle). Pour les transférer vers Databricks Apps, voir Migrer un agent de Model Serving vers Databricks Apps.

Déployer avec la CLI Agent Bricks

Le CLI Agent Bricks relie les trois couches. Il génère l’ossature du code de votre framework, l’exécute localement sur DurableAgentServer, puis le déploie dans Agent Runtime :

agentbricks init my-agent --framework langgraph
cd my-agent
agentbricks dev
agentbricks deploy my-agent

Pour construire et déployer votre premier agent, consultez Agent Bricks quickstart.

Autorisations pour déployer un agent

L’utilisateur ou le principal de service qui exécute agentbricks deploy a besoin d’une autorisation pour faire ce qui suit :

• Créez des applications Databricks, ou gérez l’application existante pour un redéploiement. Consultez Configurer des autorisations pour une application Databricks.
• Créez les magasins de mémoire et les magasins de session déclarés dans agent.toml, ou gérez les magasins existants, afin que Agent Bricks puisse accorder au principal de service de l’application l’accès à ces magasins.
• Créez l’expérience MLflow que le projet utilise pour le traçage, ou modifiez-la si elle existe déjà.
• Accordez au principal de service de l’application un accès aux ressources que les outils déclarent avec --auth app, comme EXECUTE sur une fonction Unity Catalog, CAN RUN sur un agent Genie ou SELECT sur une table dans un périmètre de bac à sable.

Agent Bricks n’accorde l’accès qu’aux ressources que agent.toml déclare directement. Si un outil utilise d’autres ressources, comme les tables derrière un agent Genie ou les objets qu’une fonction du catalogue Unity appelle, accordez vous-même au principal de service de l’application l’accès à ces ressources. Si Deploy ne peut pas appliquer une autorisation requise, il s’arrête avant de télécharger votre code et laisse le déploiement en cours d’exécution.

Ressources additionnelles

• Agent Server
• Runtime de l’agent
• Agents de requête déployés sur Azure Databricks