Implantar agentes no Azure Databricks

Para rodar um agente em produção, você implanta seu código em computação gerenciada que atende às solicitações dos seus usuários e aplicações. Um agente implantado possui três camadas: seu framework ou harness, um servidor de agente e um runtime de agente. O Agent Bricks oferece opções em cada camada, de DurableAgentServer até o Agent Runtime nos aplicativos Databricks.

A pilha de computação do agente

Um agente implantado possui três camadas. Cada camada envolve a que está acima.

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

Camada O que faz Opções no Azure Databricks
Estrutura ou agente Executa o loop de agentes: chama modelos e ferramentas e decide o que fazer a seguir. Qualquer framework ou harness, como LangGraph ou o OpenAI Agents SDK, ou um meta-harness como o Omnigent.
Servidor de agente Envolve o loop do agente em um servidor HTTP. O servidor agente expõe a API de invocação, gerencia as conexões dos clientes e cuida da durabilidade. DurableAgentServer (recomendado), servidores agentes legados ou seu próprio servidor.
Runtime do agente Roda o servidor agente em computação gerenciada e gerencia hospedagem, identidade e escalabilidade. Runtime do agente no Databricks Apps.

Os termos a seguir descrevem como as camadas funcionam juntas:

Term O que significa
API de invocação A API HTTP que os clientes chamam para executar o agente. Consulte Agentes de consulta implantados no Azure Databricks.
Atender O runtime do agente roda o servidor agente, que atende seu agente por meio da API de invocação.
Implantar Coloque o código do seu agente no runtime do agente.

Note

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

Framework ou arcabouço

O framework ou harness é o código do seu agente. Ele executa o ciclo que raciocina com um modelo, chama ferramentas e decide quando responder. Agent Bricks não exige uma estrutura específica.

Framework ou arcabouço Quando usar
Templates Iniciando um novo agente. O Agent Bricks CLI cria a estrutura de projetos para LangGraph e o SDK OpenAI Agents. Os templates mantêm seu código de framework separado do código que o conecta ao servidor agente.
Agentes existentes Trazer um agente que você já construiu com o LangGraph ou o SDK de Agentes da OpenAI. Execute agentbricks init --existing no diretório dele. Consulte Adicionar um agente existente.
Meta-harness Compor múltiplos harnesses, como agentes de codificação, em um único agente com o Omnigent.

Servidor do agente

O servidor agente é uma biblioteca que envolve seu loop de agentes e o transforma em um serviço. Ele 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 usar
DurableAgentServer (recomendado) Novos agentes construídos com a CLI do Agent Bricks.
Servidores de agente herdados Mantendo agentes construídos a partir dos templates de aplicativos. Para comparar DurableAgentServer com os servidores agentes legados, veja Servidores Agentes no Databricks.
Seu próprio servidor Agentes que precisam de endpoints personalizados, formatos de requisição ou protocolos. Execute agentbricks init --server custom, ou mantenha seu servidor atual.

Runtime do agente

O runtime do agente é a computação gerenciada que executa o servidor de agente. Você implanta código nele em vez de provisionar servidores você mesmo.

Runtime do agente Quando usar
Tempo de Execução do Agente Novos agentes. Roda seu agente no Databricks Apps. agentbricks deploy provisiona os recursos que o agente precisa, concede acesso ao agente a eles e os implanta em um ponto de extremidade estável e autenticado.
Serviço de Modelo (herdado) Agentes anteriores foram implantados em pontos de extremidade do Serviço de Modelo. Consulte Implantar um agente para aplicativos de IA (Model Serving). Para movê-los para os Apps Databricks, veja Migrar um agente de Model Serving para Databricks Apps.

Implantar com a CLI Agent Bricks

A CLI Agent Bricks conecta as três camadas. Ele estrutura o código do seu framework, roda DurableAgentServer localmente e o implanta no Agent Runtime:

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

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

Permissões para implantar um agente

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

  • Crie aplicativos Databricks ou gerencie o app existente para uma reimplantação. Consulte Configurar permissões para um aplicativo do Databricks.
  • Crie os repositórios de memória e sessão declarados em agent.toml, ou gerencie os repositórios existentes, para que o Agent Bricks possa conceder à entidade de serviço do aplicativo acesso a eles.
  • Crie o experimento MLflow que o projeto usa para rastreamento, ou edite-o se ele já existir.
  • Conceda ao principal de serviço do aplicativo acesso a recursos que as ferramentas declaram com --auth app, como EXECUTE em uma função do Unity Catalog, CAN RUN em um Agente Genie ou SELECT em uma tabela em um escopo sandbox.

O Agente Bricks concede acesso apenas a recursos que agent.toml declara diretamente. Se uma ferramenta usar outros recursos, como as tabelas usadas por um Agente Genie ou os objetos que uma função do Unity Catalog chamar, conceda você mesmo à entidade de serviço do aplicativo acesso a eles. Se o deploy não puder aplicar uma permissão obrigatória, ele para antes de enviar seu código e deixa a implantação atual rodando.

Recursos adicionais

  • Última atualização em