Distribuire agenti su Azure Databricks

Per eseguire un agente in produzione, distribuisci il suo codice in un ambiente di calcolo gestito che risponde alle richieste degli utenti e delle applicazioni. Un agente distribuito in esecuzione ha tre livelli: il framework o harness, un agent server e un runtime agente. Agent Bricks offre opzioni a ogni livello, da DurableAgentServer Agent Framework all'Agent Runtime sulle app Databricks.

Lo stack di calcolo dell'agente

Un agente schierato ha tre strati. Ogni strato avvolge quello sopra.

Livello	Funzionamento	Opzioni in Azure Databricks
Framework o imbracatura	Esegue il ciclo agente: chiama modelli e strumenti e decide cosa fare dopo.	Qualsiasi framework o harness, come LangGraph o l'OpenAI Agents SDK, o un meta-harness come Omnigent.
Server dell'agente	Avvolge il ciclo agente in un server HTTP. L'agent server espone l'API di invocazione, gestisce le connessioni client e gestisce la durabilità.	DurableAgentServer (consigliato), server degli agent legacy o il tuo server personale.
Runtime dell'agente	Esegue l'agent server su calcolo gestito e gestisce hosting, identità e scalaggio.	Runtime dell'agente sulle app Databricks.

I seguenti termini descrivono come funzionano insieme i livelli:

Termine	Che cosa significa
API di invocazione	L'API HTTP che i client chiamano per eseguire l'agente. Vedi agenti Query distribuiti su Azure Databricks.
Servi	Il runtime dell'agente gestisce il server agente, che serve il tuo agente tramite l'API di invocazione.
Deploy	Carica il codice dell'agente nel runtime dell'agente.

Note

Il Sandbox di Databricks non è uno strato dello stack di calcolo. È uno strumento che il tuo agente chiama per eseguire codice in un ambiente isolato, separato dal runtime dell'agente, con accesso limitato ai tuoi dati governati. Usa un sandbox quando il tuo agente scrive ed esegue codice, come script di analisi dati. Per dare a un progetto CLI uno strumento sandbox, esegui agentbricks tools add sandbox.

Framework o imbracatura

Il framework o harness è il codice del tuo agente. Gestisce il ciclo che ragiona con un modello, chiama gli strumenti e decide quando rispondere. Agent Bricks non richiede un framework specifico.

Framework o harness	Quando utilizzare
Modelli	Avvio di un nuovo agente. La CLI Agent Bricks genera l'impalcatura dei progetti per LangGraph e l'SDK OpenAI Agents. I template mantengono il codice del framework separato da quello che lo collega al server agente.
Agenti esistenti	Portare un agente che hai già creato con LangGraph o con l'SDK OpenAI Agents. Esegui agentbricks init --existing nella sua directory. Vedi Importa un agente esistente.
Meta-imbracatura	Comporre più harness, come gli agenti di codifica, in un unico agente con Omnigent.

Server dell'agente

L'agent server è una libreria che avvolge il tuo loop agente e lo trasforma in un servizio. Definisce l'API che i client chiamano, tiene traccia di ogni esecuzione e determina cosa accade quando un'esecuzione viene interrotta.

Server dell'agente	Quando utilizzare
DurableAgentServer (scelta consigliata)	Nuovi agenti costruiti con la CLI di Agent Bricks.
Server agent precedenti	Mantenere gli agenti costruiti dai template dell'app. Per confrontare DurableAgentServer con i server agent legacy, vedi Agent server su Databricks.
Il tuo server	Agenti che necessitano di endpoint personalizzati, formati di richiesta o protocolli. Esegui agentbricks init --server custom, oppure mantieni il tuo server esistente.

Runtime dell'agente

Il runtime dell'agente è l'ambiente di calcolo gestito che esegue il server dell'agente. Distribuisci il codice su di essa invece di fare tu stesso il provisioning dei server.

Runtime dell'agente	Quando utilizzare
Runtime dell'agente	Nuovi agenti. Esegue il tuo agente su Databricks Apps. agentbricks deploy Fornisce le risorse di cui il tuo agente ha bisogno, gli concede l'accesso a tali risorse e lo distribuisce su un endpoint stabile e autenticato.
Model Serving (legacy)	Le versioni precedenti degli agenti venivano distribuite sugli endpoint Model Serving. Vedere Distribuire un agente per le applicazioni di intelligenza artificiale (Model Serving) . Per spostarli nelle app Databricks, vedi Migra un agente da Model Serving alle app Databricks.

Deploy con la CLI Agent Bricks

La CLI Agent Bricks collega i tre livelli. Struttura il codice del tuo framework, lo esegue localmente su DurableAgentServer e lo distribuisce su Agent Runtime:

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

Per costruire e schierare il tuo primo agente, consulta l'avvio rapido di Agent Bricks.

Permessi per installare un agente

L'utente o il principale del servizio che esegue agentbricks deploy ha bisogno del permesso per fare quanto segue:

• Crea Databricks Apps, oppure gestisci l'app esistente per una ridistribuzione. Vedere Configurare le autorizzazioni per un'app Databricks.
• Crea gli archivi di memoria e di sessione dichiarati in agent.toml, oppure gestisci gli archivi esistenti, in modo che gli Agent Bricks possano concedere all'entità servizio dell'app l'accesso a essi.
• Crea l'esperimento MLflow che il progetto usa per il tracciamento, oppure modificalo se esiste già.
• Concedi al principale di servizio dell'app l'accesso alle risorse che gli strumenti dichiarano con --auth app, come EXECUTE su una funzione Unity Catalog, CAN RUN su un Genie Agent o SELECT su una tabella in un ambito sandbox.

Agent Bricks concede l'accesso solo alle risorse che agent.toml dichiara direttamente. Se uno strumento utilizza altre risorse, come le tabelle dietro un Genie Agent o gli oggetti che una funzione del Catalogo Unity chiama, concedi tu stesso l'accesso al service principal dell'app. Se deploy non può applicare un grant richiesto, si ferma prima di caricare il tuo codice e lascia il deployment attuale in esecuzione.

Risorse aggiuntive

• Agent Server
• Runtime dell'agente
• Query agents distribuiti su Azure Databricks