Ambiente de execução de agentes sem servidor no Funções do Azure

O ambiente de execução de agentes serverless do Funções do Azure é um modelo de programação centrado em Markdown para criar agentes de IA como aplicações do Funções do Azure. Em vez de juntar alojamento, triggers, clientes de modelo, ferramentas, armazenamento de sessões, identidade e observabilidade, defines agentes em .agent.md ficheiros e implementas-nos como uma aplicação funcional.

O ambiente de execução foi concebido para agentes que reagem a eventos, invocam ferramentas e são executados numa infraestrutura sem servidor. Os agentes podem começar a partir de pedidos HTTP, agendamentos, filas, mensagens, alterações na base de dados e outros eventos; utilizar servidores MCP remotos, servidores MCP alojados em namespaces de conectores, competências reutilizáveis e execução em sandbox; e funcionam com as mesmas funcionalidades de implementação, identidade, monitorização e escalabilidade usadas por outras aplicações do Funções do Azure. Para lógica específica da aplicação, podes escrever ferramentas personalizadas na mesma aplicação de funções.

Porque criar agentes no Funções do Azure?

Os agentes de produção precisam de mais do que um prompt e um modelo. Precisam de formas fiáveis para iniciar o trabalho, ligar para sistemas externos, persistir o histórico de conversas, executar código não confiável em segurança, autenticar sem segredos, emitir telemetria e escalar a pedido.

O Funções do Azure já fornece um modelo de computação orientado a eventos para essas questões operacionais. O ambiente de execução dos agentes serverless aplica esse modelo aos agentes:

• Os agentes são a unidade de trabalho. Um .agent.md ficheiro define o gatilho e as instruções para um agente.
• Eventos iniciam agentes. Os disparadores de funções permitem que os agentes sejam executados de acordo com uma programação, reajam a filas e eventos, ou exponham endpoints HTTP.
• As funcionalidades configuram-se primeiro, recorrendo a código apenas quando necessário. Os agentes podem usar servidores MCP remotos, servidores MCP alojados em namespaces de conectores, competências e execução de código em sandbox a partir da configuração. Usa ferramentas personalizadas para lógica específica da aplicação.
• A hospedagem é sem servidor. O Flex Consumption suporta escalabilidade até zero, faturação por segundo, identidade gerida, integração com redes virtuais e Application Insights.
• A canalização operacional está incorporada. O runtime gere a descoberta de agentes, registo de gatilhos, montagem de ferramentas, histórico de sessões e endpoints opcionais incorporados.

Anatomia do projeto

Uma aplicação de agentes serverless é uma aplicação Python Funções do Azure com ficheiros específicos de agente ao lado dos ficheiros normais do projeto Functions.

Um projeto minimalista tem function_app.py, host.json, requirements.txt, e pelo menos um .agent.md ficheiro. Adicione agents.config.yaml quando a aplicação necessitar de valores predefinidos de tempo de execução ao nível de toda a aplicação.

Arquivos do agente

Um ficheiro de agente utiliza um cabeçalho YAML, seguido de instruções em Markdown. Este exemplo define um agente ativado por temporizador:

---
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".

A secção introdutória indica como o agente é invocado. O corpo em Markdown é o bloco de instruções que o ambiente de execução passa ao modelo durante a execução. A substituição de variáveis de ambiente permite que instruções e valores de configuração referenciam definições de aplicação, como $TO_EMAIL.

Cada .agent.md ficheiro define um agente. O nome do ficheiro é usado para determinar o nome da função do Azure e o segmento de rota para pontos finais incorporados. O name campo é um nome de visualização utilizado em registos, rótulos e documentação.

Utilize estes campos introdutórios para configurar um agente:

O tempo de execução é predefinido em agents.config.yaml

Use agents.config.yaml para predeterminações de runtime em toda a aplicação que todos os agentes possam herdar. O runtime pode carregar uma aplicação sem este ficheiro. Adiciona-o quando necessitares de definições partilhadas, como uma implementação do modelo, um tempo limite ou um ponto final de execução em sandbox.

Este ficheiro é uma entrada ao nível da aplicação. O runtime também descobre servidores MCP de mcp.json, competências de skills/ e ferramentas de Python personalizadas de tools/. Essas capacidades estão ativadas nos agentes por defeito. Os metadados iniciais do agente podem substituir as predefinições do runtime ou filtrar servidores, capacidades e ferramentas MCP herdados.

system_tools:
  dynamic_sessions_code_interpreter:
    endpoint: $ACA_SESSION_POOL_ENDPOINT

model: $FOUNDRY_MODEL
timeout: 900

Os agentes individuais podem substituir definições suportadas de tempo de execução nos seus próprios metadados iniciais.

Use estes campos de topo em agents.config.yaml:

O ambiente de execução determina primeiro os valores a partir dos metadados iniciais do agente, depois de agents.config.yaml, e, em seguida, das definições da aplicação e dos valores predefinidos do ambiente de execução. Valores de string em agents.config.yaml podem referenciar definições de aplicação, como $AZURE_OPENAI_DEPLOYMENT ou $ACA_SESSION_POOL_ENDPOINT.

Mantenha as predefinições do modelo, do tempo de espera e da ferramenta do sistema em agents.config.yaml. Mantenha definições remotas de servidores MCP, incluindo endpoints de servidores MCP a partir de namespaces de conectores, em mcp.json.

Substituição de variáveis

O ambiente de execução pode substituir definições da aplicação e variáveis de ambiente em cadeias de texto no front matter do agente, nos corpos de instruções do agente, agents.config.yaml e mcp.json. Utilizar $SETTING_NAME ou %SETTING_NAME%. Os nomes das variáveis devem começar por uma letra ou sublinhado e podem conter letras, números e sublinhados.

model: $FOUNDRY_MODEL
system_tools:
  dynamic_sessions_code_interpreter:
    endpoint: %ACA_SESSION_POOL_ENDPOINT%

Email the summary to $TO_EMAIL.

{
  "servers": {
    "office365": {
      "type": "http",
      "url": "$O365_MCP_SERVER_URL"
    }
  }
}

A substituição aplica-se a valores de cadeia, incluindo cadeias aninhadas em objetos ou listas. Não se aplica às chaves de objeto. Os blocos de código delimitados no corpo das instruções dos agentes não são substituídos, pelo que os exemplos podem incluir o texto literal $VALUE ou %VALUE%.

Use $$SETTING_NAME ou %%SETTING_NAME%% quando precisar de incluir um marcador literal em conteúdo substituído. As variáveis de ambiente em falta permanecem inalteradas, valores vazios resolvem-se para cadeias vazias e a substituição é uma única passagem. A ${SETTING_NAME} sintaxe não é suportada.

Para desativar a substituição do conteúdo introdutório e das instruções de um agente, defina substitute_variables: false no ficheiro do agente. Esta definição não desativa a substituição em agents.config.yaml ou mcp.json.

Como o runtime inicia uma aplicação

Quando o anfitrião Funções do Azure importa a aplicação, create_function_app() constrói um FunctionApp configurado a partir dos ficheiros do projeto:

1. Determinar a raiz da aplicação.
2. Carregar agents.config.yaml.
3. Carregue cada ficheiro .agent.md.
4. Descubra servidores, competências e ferramentas personalizadas do MCP.
5. Defina as predefinições globais da aplicação e a configuração de cada agente.
6. Valide a configuração resolvida do agente.
7. Constrói a ferramenta final e as capacidades de competência para cada agente.
8. Regista os triggers do Funções do Azure e os endpoints incorporados opcionais.

Depois de arrancar, o host do Funções do Azure indexa os triggers registados, tal como acontece com outras aplicações de funções. Quando um gatilho é ativado, o runtime constrói o agente com as suas instruções, definição de modelo, ferramentas, competências e histórico de sessões, e depois executa-o através do Microsoft Agent Framework.

Acionar agentes através de eventos

Os agentes sem servidor são úteis quando o evento que desencadeia o trabalho é tão importante quanto a invocação do modelo. O ambiente de execução suporta um disparador por ficheiro de agente.

Uma definição de gatilho tem um type e um args objeto. O type identifica o vínculo do acionador, e args contém as definições específicas do acionador que determinam que evento inicia o agente.

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

Tipos comuns de gatilhos incluem http_trigger, timer_trigger, queue_trigger, blob_trigger, event_grid_trigger, e service_bus_trigger. Para acionadores incorporados do Funções do Azure, utilize a documentação sobre acionadores e associações do Python v2 e a referência de associação do acionador para encontrar as definições a incluir em args. Por exemplo, um trigger de temporizador usa uma schedule definição, um trigger de fila usa definições como queue_name e connection, e um trigger de blob usa definições como path e connection. O runtime fornece o ponto de entrada da função gerada, por isso o ficheiro agente só precisa das definições de gatilho que identificam a origem do evento.

Padrões comuns de gatilho incluem:

Como cada agente está registado como uma Função Azure, a aplicação pode utilizar funcionalidades de alojamento de Funções, como regras de escala, identidade gerida, redes e monitorização.

Dar ferramentas aos agentes

Os agentes tornam-se úteis quando podem agir. Comece com capacidades configuradas: servidores MCP remotos, servidores MCP alojados em espaços de nomes de conectores, competências e execução isolada. Use ferramentas Python personalizadas para capacidades específicas da aplicação que não se enquadrem nessas opções.

Servidores MCP remotos

Quando uma aplicação usa servidores MCP remotos, adicione mcp.json à raiz do projeto de aplicação de funções. O runtime descobre, a partir deste ficheiro, servidores HTTP remotos ou servidores MCP HTTP com capacidade de transmissão em fluxo e disponibiliza as respetivas ferramentas aos agentes, em função de quaisquer filtros específicos de cada agente.

Use estes campos em cada servers entrada:

Use servidores MCP remotos quando os agentes precisarem de chamar ferramentas alojadas por outro serviço ou compor agentes e ferramentas através das fronteiras da aplicação.

Conectores do Azure

Os conectores permitem que os agentes trabalhem com serviços externos sem código cliente personalizado da API. Por exemplo, um conector Microsoft 365 Outlook pode enviar emails, um conector Teams pode funcionar com mensagens, e outros conectores podem chamar ações em sistemas como Salesforce, SAP ou SQL. Um Espaço de Nomes de Conectores aloja as ligações, triggers e servidores MCP que disponibilizam essas integrações à sua aplicação.

Para usar capacidades de conectores numa aplicação de agentes serverless, crie primeiro um Espaço de Nomes de Conectores, crie uma ligação ao serviço e autorize essa ligação. Depois escolhe como o agente usa a ligação:

• Os acionadores de conectores iniciam agentes quando algo acontece num serviço conectado, como uma nova mensagem de e-mail, uma mensagem do Teams ou um evento do calendário. Para utilizar um, crie um gatilho no Espaço de Nomes do Conector que utilize a ligação autorizada e, depois, configure o agente com o nome do gatilho e os argumentos dessa definição de gatilho do conector.
• As ferramentas MCP Connector permitem que os agentes chamem ações de serviço, como enviar emails ou atualizar um registo. Para os usar, crie um servidor MCP no Espaço de Nomes do Conector que utilize a ligação autorizada e depois adicione o endpoint do servidor MCP a mcp.json.

Para as ferramentas de conector MCP, uma entrada de servidor MCP em mcp.json armazena o endpoint e as definições de autenticação de identidade gerida. Use o âmbito do Azure API Hub quando o agente consome um servidor MCP gerido a partir de um namespace de conectores. Não guarde segredos de utilizador em mcp.json.

{
  "servers": {
    "office365-outlook": {
      "type": "http",
      "url": "$O365_MCP_SERVER_URL",
      "auth": {
        "scope": "https://apihub.azure.com/.default",
        "client_id": "$O365_MCP_CLIENT_ID"
      }
    }
  }
}

A definição auth.client_id seleciona qual identidade gerida é utilizada para autenticação no servidor MCP. Defina-o como o ID de cliente de uma identidade gerida atribuída a utilizador. Omita-o para usar a identidade gerida atribuída pelo sistema da aplicação de funções no Azure. A identidade selecionada, ou a sua identidade de programador quando a execução é feita localmente, deve estar autorizada a invocar o servidor MCP.

Competências

As competências são recursos de prompts reutilizáveis armazenados em skills/. Ajudam a manter as instruções base do agente pequenas enquanto disponibilizam instruções específicas do domínio quando necessário. O ambiente de execução utiliza o formato Agent Skills.

O ambiente de execução analisa skills/ na pasta raiz do projeto da aplicação de funções e descobre recursivamente as pastas que contêm SKILL.md:

skills/
  incident-response/
    SKILL.md
    triage-checklist.md
    escalation-policy.md

O ficheiro SKILL.md contém um cabeçalho YAML seguido de instruções em Markdown:

---
name: incident-response
description: Triage production incidents, summarize impact, and recommend next steps. Use when the task mentions incidents, outages, alerts, or severity levels.
---

Follow the incident response checklist in [triage-checklist.md](triage-checklist.md).

Utilize as seguintes regras de criação de competências:

• Cada pasta de habilidades deve conter um SKILL.md ficheiro.
• Os name campos e description são obrigatórios.
• Os nomes das habilidades devem usar letras minúsculas, números e hífens simples. Não use espaços, caracteres de sublinhado, letras maiúsculas, hífens iniciais, hífens finais ou hífens repetidos.
• Os nomes das habilidades devem ser únicos em toda a aplicação.
• A descrição deve explicar tanto o que a habilidade faz como quando o agente deve usá-la. O runtime carrega primeiro os nomes e descrições das habilidades para que o agente possa decidir quando carregar a habilidade completa.
• As competências podem incluir vários ficheiros de markdown na mesma pasta de competências. Consulte os ficheiros Markdown de suporte a partir de SKILL.md utilizando ligações relativas.
• Apenas ficheiros markdown são suportados como conteúdo de skill no runtime do agente serverless. Se uma competência precisar de comportamento executável, empacota esse código como uma ferramenta Python personalizada e refere-te à ferramenta pelo nome das instruções da competência.

Os agentes herdam todas as competências descobertas por predefinição. Desativar ou excluir competências num ficheiro de agente quando um agente específico não deve usá-las:

skills: false

skills:
  exclude:
    - incident-response

Execução em sandbox

Para execução de código ou automação do navegador, o runtime pode usar sessões dinâmicas do Azure Container Apps. As sessões dinâmicas fornecem ambientes isolados dos pools de sessão. O runtime utiliza sessões de interpretadores de código para fornecer uma execute_python ferramenta aos agentes.

Configurar execução em sandbox em agents.config.yaml:

system_tools:
  dynamic_sessions_code_interpreter:
    endpoint: $ACA_SESSION_POOL_ENDPOINT

Utilize estes requisitos da sandbox:

• O pool de sessões deve ser um pool de sessões de interpretador de código Python, por exemplo, um pool criado com --container-type PythonLTS.
• O valor endpoint é o endpoint de gestão do pool de sessões.
• No Azure, a identidade gerida usada pela aplicação de funções deve ter as atribuições de papéis necessárias para executar código no pool de sessões. As sessões do intérprete de código do Azure Container Apps requerem as funções Azure ContainerApps Session Executor e Contributor no conjunto de sessões.
• Ao correr localmente, a identidade do seu programador deve ter o mesmo acesso necessário ao pool de sessões.
• Para usar uma identidade gerida atribuída pelo utilizador para execução em sandbox, defina system_tools.dynamic_sessions_code_interpreter.client_id o ID do cliente da identidade que tem as atribuições de funções necessárias. Se esta definição não estiver configurada, o ambiente de execução utiliza AZURE_CLIENT_ID e, em seguida, a cadeia de credenciais predefinida.

A ferramenta sandbox executa Python numa sessão isolada. Variáveis, importações e ficheiros podem persistir entre chamadas de ferramenta na mesma sessão do agente. Quando não existe o ID de sessão do agente disponível, o runtime usa uma sessão sandbox nova para que execuções não relacionadas não partilhem estado.

Os agentes herdam a execução em sandbox quando esta está configurada a nível global. Desative-o para um agente específico quando esse agente não deveria executar código:

system_tools:
  dynamic_sessions_code_interpreter: false

Ferramentas personalizadas de Python

Use ferramentas Python personalizadas para capacidades específicas de aplicação que não se encaixem em servidores MCP, servidores MCP alojados em namespaces de conectores, skills ou execuções em sandbox. Ferramentas personalizadas permitem usar pacotes Funções do Azure e Python da mesma aplicação de funções.

Adicione ficheiros de ferramenta à tools/ pasta na raiz do projeto da aplicação de funções:

tools/
  submit_ticket.py
  lookup_customer.py

O tempo de execução descobre .py ficheiros em tools/ cujos nomes de ficheiro não começam por _. Na versão de pré-visualização atual, o runtime regista a primeira ferramenta suportada em cada ficheiro. Use uma ferramenta por ficheiro para manter a descoberta previsível.

Pode definir uma ferramenta decorando uma função com @tool a partir do pacote de runtime:

from azure_functions_agents import tool


@tool(name="submit_ticket", description="Create a support ticket with a title and summary.")
async def submit_ticket(title: str, summary: str) -> str:
    return f"Created ticket for {title}: {summary}"

Para descrições de parâmetros mais detalhadas e validação, use um modelo Pydantic como esquema de ferramenta:

from pydantic import BaseModel, Field
from azure_functions_agents import tool


class LookupCustomerParams(BaseModel):
    customer_id: str = Field(description="Customer identifier from the CRM system.")


@tool(schema=LookupCustomerParams, description="Look up customer details by customer ID.")
async def lookup_customer(params: LookupCustomerParams) -> str:
    return f"Customer details for {params.customer_id}"

Também podes definir uma função Python simples sem o decorador. O runtime envolve a primeira função simples que encontra no ficheiro, usa o nome da função como nome da ferramenta e usa a docstring como descrição da ferramenta.

def summarize_order(order_id: str) -> str:
    """Summarize an order by order ID."""
    return f"Summary for order {order_id}"

Os nomes das ferramentas, as descrições, as anotações de tipo e as descrições dos campos do Pydantic ajudam o modelo a decidir quando e como invocar a ferramenta. Adiciona quaisquer dependências de pacotes usadas por ferramentas personalizadas ao requirements.txt, tal como farias com outro código de Python numa aplicação Funções do Azure.

Os agentes herdam ferramentas personalizadas descobertas por defeito. Desabilite ou exclua ferramentas personalizadas num ficheiro de agente quando um agente específico não as deveria usar:

tools: false

tools:
  exclude:
    - submit_ticket

Configurar fornecedores de modelos

O runtime utiliza o Microsoft Agent Framework para chamar fornecedores de modelos. O suporte de pré-visualização inclui Azure OpenAI, Azure AI Foundry e OpenAI.

A seleção do fornecedor baseia-se nas definições da aplicação. Pode fixar o fornecedor com AZURE_FUNCTIONS_AGENTS_PROVIDER, ou deixar o tempo de execução inferir o fornecedor a partir de definições como AZURE_OPENAI_ENDPOINT, FOUNDRY_PROJECT_ENDPOINT, ou OPENAI_API_KEY.

A seleção do modelo utiliza esta precedência geral:

1. O modelo solicitado pelo agente ou pela chamada em tempo de execução.
2. Definições específicas do fornecedor, como AZURE_OPENAI_DEPLOYMENT ou FOUNDRY_MODEL.
3. AZURE_FUNCTIONS_AGENTS_MODEL.
4. O fornecedor predefinido.

Para aplicações de produção, prefira a identidade gerida quando suportada. Quando uma aplicação deve usar uma identidade gerida atribuída pelo utilizador, defina AZURE_CLIENT_ID para que os fornecedores de modelo e a execução em sandbox usem essa identidade.

Configurar identidades gerenciadas

O runtime utiliza identidade gerida para recursos Azure que suportam autenticação Microsoft Entra. Use AZURE_CLIENT_ID como seletor de identidade predefinido da aplicação. Os servidores MCP alojados em namespaces de conectores e histórico de sessões apoiado por blobs podem usar definições de identidade mais específicas.

Para fornecedores de modelos e execução em sandbox, define AZURE_CLIENT_ID quando queres que o runtime use uma identidade gerida atribuída pelo utilizador. Se AZURE_CLIENT_ID não estiver definido, o ambiente de execução utiliza o comportamento padrão das credenciais do SDK do Azure, que pode incluir a identidade gerida atribuída pelo sistema quando esta estiver disponível.

Use estas definições para selecionar identidades geridas:

Para Azure OpenAI, estas definições de identidade aplicam-se apenas quando AZURE_OPENAI_API_KEY não está definido. Se uma chave API for configurada, o fornecedor do modelo usa a chave em vez da identidade gerida.

O histórico de sessões utiliza a mesma configuração de identidade de armazenamento que o host do Funções do Azure. Use AzureWebJobsStorage, AzureWebJobsStorage__blobServiceUri, e AzureWebJobsStorage__clientId para configurar armazenamento baseado em identidade para o histórico apoiado em blobs. O runtime não utiliza uma definição de identidade específica para o agente para o histórico da sessão.

Sessões e estado

As interações com agentes em múltiplos turnos precisam de histórico de sessões. No Azure, o runtime armazena o histórico da sessão no Armazenamento de Blobs utilizando a conta AzureWebJobsStorage da aplicação de funções. Este design evita uma base de dados de sessões separada para muitas aplicações e funciona com configuração de armazenamento baseada em strings de ligação ou identidade.

Para desenvolvimento local sem configuração de armazenamento do Azure, o ambiente de execução pode recorrer ao histórico de sessões assente em ficheiros no diretório de configuração local dos agentes.

A execução em sandbox também tem em conta a sessão. Quando o runtime cria ferramentas sandbox sem um ID de sessão explícito, utiliza uma sessão isolada para a invocação em vez de partilhar o estado entre execuções de agentes não relacionadas.

Pontos finais incorporados

O ambiente de execução pode expor endpoints de depuração e composição integrados sem código adicional na aplicação. Use a interface de chat e as APIs de chat para desenvolvimento, testes e diagnóstico, não como interface principal de aplicação de produção.

Qualquer ficheiro de agente pode aderir através das definições builtin_endpoints nos seus metadados iniciais. O segmento <AGENT_NAME> de rota é derivado do .agent.md nome do ficheiro, não do campo de visualização name . Por exemplo, main.agent.md usa /agents/main/.

Quando alojado no Azure, a interface de chat pede uma tecla de função antes de enviar mensagens. Também pode usar esta chave para chamar diretamente as APIs de chat HTTP:

az functionapp keys list \
  --resource-group <RESOURCE_GROUP> \
  --name <FUNCTION_APP_NAME> \
  --query "functionKeys.default" \
  --output tsv

Passa a chave no x-functions-key cabeçalho ou no code parâmetro da string de consulta. Para ligar um cliente MCP, obtenha a chave de sistema de extensão MCP em vez disso:

az functionapp keys list \
  --resource-group <RESOURCE_GROUP> \
  --name <FUNCTION_APP_NAME> \
  --query "systemKeys.mcp_extension" \
  --output tsv

O endpoint MCP requer esta chave de sistema, a menos que a aplicação configure o acesso anónimo.

Quando utilizar o ambiente de execução dos agentes serverless

Utilize o ambiente de execução dos agentes serverless se o seu agente for orientado por eventos, recorrer intensivamente a ferramentas ou estiver operacionalmente próximo das cargas de trabalho do Funções do Azure.

Boas opções incluem:

• Agentes programados em segundo plano que resumem, monitorizam, fazem reconciliação ou geram relatórios.
• Assistentes orientados por eventos que reagem a mensagens, emails, alertas, mensagens em fila ou alterações de dados.
• Agentes entre sistemas que utilizam conectores para coordenar o trabalho entre aplicações SaaS e empresariais.
• Interfaces conversacionais que expõem o mesmo agente através de HTTP, interface de chat ou MCP.
• Agentes que devem escalar para zero e utilizar identidade gerida, monitorização, slots de implementação e outras capacidades de alojamento do Azure.

Se só precisares de expor funções determinísticas como ferramentas para outro cliente de IA, a extensão Funções do Azure MCP pode ser um melhor ponto de partida. Para obter mais informações, consulte Usar ferramentas e modelos de IA no Funções do Azure.

Introdução

Comece pelo guia de início rápido para implementar uma aplicação de agentes sem servidor com um agente de conversação, um agente de resumo de blogue acionado por temporizador, a implementação de um modelo, execução em sandbox e ferramentas MCP opcionais a partir de um espaço de nomes de conetor:

Conteúdo relacionado

• Usa ferramentas e modelos de IA em Funções do Azure
• Construa um servidor MCP remoto personalizado usando Funções do Azure
• Ligue um servidor MCP em Funções do Azure ao Foundry Agent Service
• Alojamento do plano Flex Consumption