Ambiente de execução de agentes sem servidor no Azure Functions

O ambiente de execução de agentes serverless do Azure Functions é um modelo de programação para criar agentes de IA orientados a eventos na forma de aplicativos do Azure Functions. Os agentes podem começar com requisições HTTP, temporizadores, filas, blobs, alterações no banco de dados ou eventos do Connector. Você define agentes em .agent.md arquivos, configura ferramentas e padrões de runtime junto com seu projeto, e implanta o app como qualquer outro app funcional. O runtime gerencia o registro de gatilhos, chamadas ao modelo, montagem de ferramentas, histórico de sessões e observabilidade em infraestrutura sem servidor.

Importante

O ambiente de execução dos agentes serverless está atualmente em versão prévia. Recursos, nomes de configuração e conectores com suporte podem ser alterados antes da disponibilidade geral.

Quando usar o runtime de agentes sem servidor

Use o runtime de agentes sem servidor quando seu agente for orientado por eventos, rico em ferramentas ou operacionalmente próximo das cargas de trabalho do Azure Functions. Cenários para o ambiente de execução do agente serverless incluem:

  • Agentes em segundo plano agendados que resumem, monitoram, reconciliam ou geram relatórios.
  • Assistentes controlados por eventos que reagem a mensagens, emails, alertas, mensagens de fila ou alterações de dados.
  • Agentes multissistema que usam conectores para coordenar o trabalho entre aplicativos SaaS e corporativos.
  • Interfaces conversacionais que expõem o mesmo agente por meio de HTTP, interface de chat ou MCP.
  • Agentes que devem ser dimensionados para zero e usar identidade gerenciada, monitoramento, slots de implantação e outros recursos de hospedagem do Azure.

Nos seguintes cenários, o tempo de execução do agente serverless pode não ser a melhor opção:

Scenario Opção melhor
Expor funções determinísticas como ferramentas para outro cliente de IA extensão MCP do Azure Functions
Orquestração de execução prolongada, em várias etapas, com aprovações com intervenção humana Durable Functions
Construtor de agentes sem código Copilot Studio ou agentes de prompt do Foundry

Para uma comparação detalhada com outras opções de agentes Microsoft, veja Compare o runtime dos agentes serverless com outras opções de agentes Microsoft.

Dica

Para testar o runtime de agentes serverless, consulte Criar agentes serverless usando o Azure Functions. Usando um azd modelo, você pode ter um aplicativo funcional implantado no Azure em minutos.

Por que criar agentes em Azure Functions?

Os agentes de produção precisam de mais do que um prompt e um modelo. Eles precisam de maneiras confiáveis para iniciar o trabalho, chamar sistemas externos, persistir o histórico de conversas, executar código não confiável com segurança, autenticar sem segredos, emitir telemetria e dimensionar sob demanda.

O Functions fornece um modelo de computação orientado a eventos para essas preocupações operacionais. O ambiente de execução de agentes serverless simplesmente aplica esse mesmo modelo ao código do seu agente. Aqui estão alguns benefícios de usar o runtime do agente serverless para construir e rodar o código do seu agente:

  • Os agentes são a unidade de trabalho. Cada agente é definido em um arquivo markdown separado.
  • Os eventos iniciam agentes. O Functions dispara agentes iniciais a partir de agendamentos, solicitações HTTP, mensagens de fila, alterações de blobs, eventos da Grade de Eventos, mensagens do Barramento de Serviço e outros eventos com suporte.
  • Os recursos são configurados primeiro, com código quando você precisa dele. É possível configurar agentes para usar servidores MCP remotos, servidores MCP hospedados em namespaces de conector, habilidades e execuções de código em área restrita. Escreva suas próprias ferramentas baseadas em Python para lógica específica de aplicativos.
  • A hospedagem serverless está disponível. O runtime de agentes sem servidor oferece suporte aos planos Consumo Flexível e Dedicado (Serviço de Aplicativo). O plano Flex Consumption oferece escala até zero, cobrança por segundo e dimensionamento automático. Ambos os planos suportam identidade gerenciada, integração com redes virtuais e integração com Application Insights.
  • O encanamento operacional é interno. O runtime cuida da descoberta de agentes, do registro de gatilhos, da montagem de ferramentas, do histórico da sessão e de endpoints integrados opcionais.

Definição do projeto

Um aplicativo de agentes sem servidor é um projeto padrão de aplicação de função Python v2, implantado junto com arquivos específicos de agentes. Os seguintes arquivos de projeto são sempre necessários para aplicativos de função Python:

Arquivo Purpose
function_app.py Importa create_function_app() e retorna o aplicativo de Azure Functions configurado.
host.json Configura o host do Azure Functions.
requirements.txt Inclui o pacote de runtime de agentes sem servidor e as dependências de Python específicas do aplicativo.

Para mais informações, consulte o guia de referência para desenvolvedores do Azure Functions para aplicativos Python.

Arquivos de runtime do agente

O runtime descobre esses arquivos e pastas específicos do agente, que são implantados com o projeto do app:

Arquivo ou pasta Purpose
*.agent.md Define os agentes. O front matter YAML configura o agente, e o corpo em markdown se transforma nas instruções. Seu projeto deve ter pelo menos um arquivo de definição de agente.
agents.config.yaml (Opcional) Define padrões de runtime para todo o app, como modelo, timeout e configurações sandbox.
mcp.json Define os servidores HTTP MCP remotos que os agentes podem usar como ferramentas, incluindo ferramentas conectoras para tarefas como enviar e-mails ou trabalhar com o Teams.
tools/ (Opcional) Contém quaisquer ferramentas Python personalizadas que você crie para fornecer capacidades ainda não fornecidas por servidores MCP, conexões, habilidades ou execuções sandbox.
skills/ (Opcional) Contém ativos de prompt reutilizáveis SKILL.md que os agentes podem carregar conforme necessário.

Cada arquivo de agente usa um cabeçalho YAML seguido por instruções em Markdown. Este exemplo define um agente acionado por temporizador que roda diariamente às 15h (UTC):

---
name: Daily Tech News Email
description: Fetches top tech news and emails a summary daily.

trigger:
  type: timer_trigger
  args:
    schedule: "0 0 15 * * *"
---

You are a news assistant. When triggered, do the following:

1. Gather today's top technology news from reputable sources.
1. Summarize the stories in a concise HTML email body.
1. Email the summary to $TO_EMAIL with the subject "Daily Tech News Summary".

O front matter declara como o agente é invocado. O corpo de markdown é o bloco de instrução que o runtime passa para o modelo durante a execução. A substituição de variável de ambiente permite que instruções e valores de configuração referenciem configurações de aplicativo, como $TO_EMAIL.

Cada .agent.md arquivo define um agente. O nome do arquivo deriva o nome da Azure Function e o segmento de rota para pontos de extremidade internos. O name campo é um nome de exibição para logs, rótulos e documentação.

Para a lista completa de campos do arquivo do agente, opções de configuração do aplicativo e regras de substituição de variáveis, confira Referência do runtime de agentes sem servidor.

Processo de inicialização do aplicativo

Quando o host do Functions carrega o aplicativo, o método create_function_app descobre arquivos de agente (triggers), servidores MCP, habilidades e ferramentas personalizadas no projeto. Ele valida a configuração, monta as ferramentas para cada agente e registra os gatilhos e endpoints necessários.

Quando um gatilho específico do agente é acionado, o runtime constrói o agente com suas instruções resolvidas, modelo, ferramentas e histórico de sessões, e então o executa usando o Microsoft Agent Framework.

Disparar agentes de eventos

O ambiente de execução oferece suporte a vários gatilhos para agentes no seu aplicativo, mas apenas um gatilho por arquivo do agente. Uma definição de gatilho tem um objeto type e um objeto args. type identifica a vinculação de gatilho, e args contém as configurações específicas do gatilho que definem qual evento inicia o agente.

Os padrões de gatilho comuns incluem:

Pattern Example
Agente HTTP Receber uma solicitação, chamar ferramentas e retornar uma resposta estruturada.
Agente agendado Execute um relatório diário, resumo, limpeza ou fluxo de trabalho de reconciliação.
Fila ou agente de mensagens Processar itens de trabalho que precisam de raciocínio de modelo ou chamadas de ferramenta.
Agente de eventos de armazenamento ou banco de dados Reagir a arquivos, registros ou eventos alterados.
Agente acionado pelo conector Reaja a eventos de conectores gerenciados, como mensagens do Teams, correspondências do Outlook ou eventos de calendário suportados pelo conector.

Para disparar detalhes de configuração, tipos com suporte e referência de args, confira Referência de runtime de agentes sem servidor.

Fornecer ferramentas de agentes

O ambiente de execução de agentes serverless suporta vários tipos de ferramentas. Comece com capacidades configuradas e use ferramentas Python personalizadas para lógica específica de aplicativos que não se encaixem nessas opções.

Servidores MCP remotos

Defina servidores remotos HTTP ou HTTP MCP com streaming em mcp.json. O runtime descobre esses servidores e disponibiliza suas ferramentas para todos os agentes. Use servidores MCP remotos quando os agentes precisarem chamar ferramentas hospedadas por outro serviço ou compor agentes e ferramentas entre os limites do aplicativo.

Conectores do Azure

Os conectores permitem que os agentes trabalhem com serviços externos sem código de cliente de API personalizada. Um Namespace de Conectores hospeda conexões, triggers e servidores MCP para serviços como Microsoft 365 Outlook, Teams, Salesforce, SAP ou SQL. Use gatilhos de conector para iniciar agentes a partir de eventos externos, e ferramentas MCP de conector para chamar ações de serviço a partir de instruções do agente.

Habilidades

Armazene recursos de prompt reutilizáveis em skills/. Cada pasta de habilidades contém um SKILL.md arquivo com nome, descrição e instruções de marcação. O runtime descobre automaticamente habilidades e as disponibiliza aos agentes. As habilidades ajudam a manter as instruções básicas do agente pequenas enquanto disponibilizam orientações específicas de domínio quando necessário.

Execução em área restrita

O runtime pode usar sessões dinâmicas de Aplicativos de Contêiner do Azure para fornecer a agentes uma ferramenta execute_python. Essa ferramenta roda Python em um pool de sessões isolado, o que é útil para execução de código e tarefas de análise de dados. Configure o endpoint do pool de sessões em agents.config.yaml.

Ferramentas de Python personalizadas

Use ferramentas Python personalizadas para capacidades específicas de cada app. Adicione arquivos .py à pasta tools/ e decore as funções com @tool do pacote de runtime. O runtime descobre e registra automaticamente essas ferramentas.

Para detalhes de configuração, tabelas de campos e exemplos de código para cada tipo de ferramenta, consulte Referência do ambiente de execução de agentes sem servidor.

Sessões e estado

Interações de agente de vários turnos precisam de histórico de sessão. No Azure, o tempo de execução armazena o histórico da sessão no Armazenamento de Blobs usando a conta AzureWebJobsStorage do aplicativo de função. Para desenvolvimento local, o runtime volta ao histórico de sessão baseado em arquivos. A execução em sandbox também tem reconhecimento de sessão e usa sessões isoladas para execuções independentes de agentes.

Observability

A partir da azure-functions-agents-runtime versão 0.1.0b6, o runtime inclui um conjunto de recursos de observabilidade que ainda está em desenvolvimento ativo e sujeito a mudanças.

Para os detalhes mais recentes de configuração, campos de telemetria e orientações de uso, use a documentação do repositório em tempo de execução: