Implantar agentes no Databricks
Para executar um agente em produção, você implanta o código dele em um compute gerenciado que atende a solicitações de seus usuários e aplicativos. Um agente implantado tem três camadas: sua estrutura ou harness, um servidor de agentes e um agent runtime. O Agent Bricks oferece opções em cada camada, desde DurableAgentServer até o Agent Runtime no Databricks Apps.
A pilha de compute do agente
Um agente implantado tem três camadas. Cada camada envolve aquela acima dela.
Camada | What it does | Opções no Databricks |
|---|---|---|
Realiza a execução do loop do agente: chama modelos e ferramentas e decide o que fazer em seguida. | Qualquer framework ou harness, como o LangGraph ou o OpenAI Agents SDK, ou um meta-harness como o Omnigent. | |
Envolve o loop do agente em um servidor HTTP. O servidor do agente expõe a API de invocação, gerencia conexões de clientes e lida com a durabilidade. |
| |
Realiza a execução do servidor do agente em compute gerenciado e lida com hospedagem, identidade e escalonamento. | Agent Runtime no Databricks Apps. |
Os seguintes termos descrevem como as camadas funcionam juntas:
Termo | O que significa |
|---|---|
API de invocação | A API HTTP que os clientes chamam para a execução do agente. Consulte Fazer query de agentes implantados no Databricks. |
Servir | O Runtime do agente executa o servidor do agente, que atende ao seu agente por meio da API de invocação. |
implantado | Coloque o código do seu agente no runtime do agente. |
Framework ou estrutura
O framework ou harness é o código do seu agente. Ele faz a execução do loop que raciocina com um modelo, chama ferramentas e decide quando responder. O Agent Bricks não requer um framework específico.
Framework or harness | Quando usar |
|---|---|
Template | Iniciando um novo agente. A CLI do Agent Bricks cria a estrutura de projetos para o LangGraph e o OpenAI Agents SDK. Os padrões mantêm o código do framework separado do código que o conecta ao servidor do agente. |
Agentes existentes | Como trazer um agente que você já construiu com o LangGraph ou o SDK do OpenAI Agents. Faça a execução de |
Meta-harness | Composição de vários harnesses, como agentes de programação, em um único agente com Omnigent. |
Servidor do agente
O servidor de agentes é uma biblioteca que envolve o loop do agente e o transforma em um serviço. Ele define a API que os clientes chamam, monitora cada execução e determina o que acontece quando uma execução é interrompida.
Servidor de agentes | Quando usar |
|---|---|
| Novos agentes criados com a CLI do Agent Bricks. |
Legacy agent servers | Mantendo agentes construídos a partir dos padrões de aplicativos. Para comparar |
Seu próprio servidor | Agentes que precisam de Endpoint, formatos de solicitação ou protocolos personalizados. Execução |
Runtime do agente
O Runtime do agente é o compute gerenciado que execução o servidor do agente. Em vez de provisionamento de servidores por conta própria, você implanta código nele.
Runtime do agente | Quando usar |
|---|---|
Novos agentes. Executa seu agente no Databricks Apps. | |
Model Serving (legado) | Agentes anteriores implantados em Model Serving Endpoint. Consulte Implantar um agente para aplicações de AI (Model Serving). Para movê-los para o Databricks Apps, consulte Migrar um agente do Model Serving para o Databricks Apps. |
Implantar com a CLI do Agent Bricks
A CLI do Agent Bricks conecta as três camadas. Ela cria a estrutura do seu código, faz a execução dele no DurableAgentServer localmente e o deixa implantado no Agent Runtime:
agentbricks init my-agent --framework langgraph
cd my-agent
agentbricks dev
agentbricks deploy my-agent
To build and implantado your first agent, see Agent Bricks quickstart.
Permissões para implantar um agente
O usuário ou Service Principal que executa agentbricks deploy precisa de permissão para fazer o seguinte:
- Crie Databricks Apps ou gerencie o aplicativo existente para uma nova implantação. Consulte Configurar permissões para um aplicativo Databricks.
- Crie o armazenamento de memória e de sessão declarado em
agent.tomlou gerencie os armazenamentos existentes para que o Agent Bricks possa conceder ao service principal do aplicativo acesso a eles. - Crie o experimento do MLflow que o projeto usa para o rastreamento ou edite-o caso ele já exista.
- Conceda ao service principal do aplicativo acesso aos recursos que as ferramentas declaram com
--auth app, comoEXECUTEem uma função do Unity Catalog,CAN RUNem um Genie Agent ouSELECTem uma tabela em um escopo de sandbox.
O Agent Bricks concede acesso apenas aos recursos que agent.toml declara diretamente. Se uma ferramenta usar outros recursos, como as tabelas por trás de um Genie Agent ou os objetos que uma função do Unity Catalog chama, conceda você mesmo acesso ao service principal do aplicativo. Se a implantação não puder aplicar uma permissão necessária, ela será interrompida antes de fazer o upload do seu código e deixará a implantação atual em execução.