Implementar agentes no Azure Databricks

Para executar um agente em produção, implementa o seu código em computação gerida que serve pedidos dos seus utilizadores e aplicações. Um agente implantado tem três camadas: o seu framework ou harness, um servidor agente e um runtime de agente. O Agent Bricks oferece opções em cada camada, desde DurableAgentServer até ao Agent Runtime nas aplicações Databricks.

A stack de computação do agente

Um agente implementado tem três camadas. Cada camada envolve a que está por cima.

A pilha de computação do agente: o seu framework ou harness, envolvido por um servidor agente que expõe a API de invocação, a correr em Agent Runtime.

Camada O que faz Opções no Azure Databricks
Framework ou arnês Executa o ciclo do agente: chama modelos e ferramentas e decide o que fazer a seguir. Qualquer framework ou harness, como o LangGraph ou o OpenAI Agents SDK, ou um meta-harness como o Omnigent.
Servidor do agente Envolve o loop do agente num servidor HTTP. O servidor agente expõe a API de invocação, gere as ligações ao cliente e assegura a durabilidade. DurableAgentServer (recomendado), servidores agentes legados, ou o seu próprio servidor.
Tempo de execução do agente Executa o servidor agente em computação gerida e gere alojamento, identidade e escalabilidade. Runtime do agente no Databricks Apps

Os termos seguintes descrevem como as camadas funcionam em conjunto:

Term O que significa
API de invocação A API HTTP que os clientes chamam para executar o agente. Consulte Agentes de consulta implementados no Azure Databricks.
Serve O runtime do agente executa o servidor do agente, que disponibiliza o seu agente através da API de invocação.
Deploy Coloca o código do teu agente no runtime do agente.

Note

O Sandbox do Databricks não é uma camada da stack de computação. É uma ferramenta que o seu agente chama para executar código num ambiente isolado, separado do runtime do agente, com acesso com âmbito definido aos seus dados governados. Utilize um sandbox quando o seu agente escreve e executa código, como scripts de análise de dados. Para dar a um projeto CLI uma ferramenta sandbox, execute agentbricks tools add sandbox.

Framework ou arnês

O framework ou harness é o código do teu agente. Executa o ciclo que raciocina com um modelo, chama ferramentas e decide quando responder. O Agent Bricks não requer um framework específico.

framework ou arcabouço Quando utilizar
Modelos A começar um novo agente. O Agent Bricks CLI gera a estrutura de projetos para o LangGraph e o SDK OpenAI Agents. Os templates mantêm o seu código de framework separado do código que o liga ao servidor do agente.
Agentes existentes Traga um agente que já criou com LangGraph ou com o SDK de Agentes da OpenAI. Executa agentbricks init --existing no seu diretório. Veja Adicionar um agente existente.
Meta-arnês Compor múltiplos harnesses, como agentes de programação, num único agente com o Omnigent.

Servidor do agente

O servidor de agentes é uma biblioteca que envolve o seu loop de agentes e o transforma num serviço. Define a API que os clientes chamam, acompanha cada execução e determina o que acontece quando uma execução é interrompida.

Servidor do agente Quando utilizar
DurableAgentServer (recomendado) Novos agentes construídos com a CLI Agent Bricks.
Servidores de agentes legados Manutenção de agentes construídos a partir dos modelos da aplicação. Para comparar DurableAgentServer com os servidores agente legados, veja Servidores Agentes em Databricks.
O seu próprio servidor Agentes que precisam de endpoints personalizados, formatos de pedido ou protocolos. Executa agentbricks init --server custom, ou mantém o teu servidor existente.

Ambiente de execução do agente

O runtime do agente é a computação gerida que executa o servidor do seu agente. Implementas código nele em vez de aprovisionares os servidores tu próprio.

Ambiente de execução do agente Quando utilizar
Execução do Agente Novos agentes. Executa o seu agente nas aplicações Databricks. agentbricks deploy Provisiona os recursos de que o seu agente necessita, concede-lhe acesso a eles e implementa-o num endpoint estável e autenticado.
Model Serving (legado) Agentes mais antigos foram implantados em endpoints de Model Serving. Consulte Implementar um agente para aplicações de IA (Serviço de Modelos). Para as mover para as Databricks Apps, consulte Migrar um agente do Model Serving para as Databricks Apps.

Implementar com a CLI Agent Bricks

A CLI Agent Bricks liga as três camadas. Ele gera a estrutura base do código do teu framework, executa-o no DurableAgentServer localmente e implementa-o para o Agent Runtime:

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

Para construir e implementar o seu primeiro agente, veja o quickstart do Agente Bricks.

Permissões para instalar um agente

O utilizador ou principal de serviço que executa agentbricks deploy precisa de permissão para fazer o seguinte:

  • Crie aplicações Databricks ou faça a gestão da aplicação existente para uma nova implementação. Consulte Configurar permissões para um aplicativo Databricks.
  • Crie os armazenamentos de memória e de sessão declarados em agent.toml, ou gira os armazenamentos existentes, para que Agent Bricks possa conceder ao principal de serviço da aplicação acesso aos mesmos.
  • Crie o experimento MLflow que o projeto usa para rastreio, ou edite-o se já existir.
  • Conceda ao service principal da aplicação acesso a recursos que as ferramentas declaram com --auth app, como EXECUTE numa função do Unity Catalog, CAN RUN num Agente Genie ou SELECT numa tabela num âmbito sandbox.

O Agente Bricks concede acesso apenas a recursos que agent.toml declara diretamente. Se uma ferramenta usar outros recursos, como as tabelas por trás de um Agente Genie ou os objetos que uma função do Unity Catalog chama, conceda o principal do serviço da aplicação acesso a esses recursos. Se o deploy não conseguir aplicar uma permissão obrigatória, para antes de carregar o teu código e deixa o deployment atual a funcionar.

Recursos adicionais