Construtor de agentes além da caixa de bate-papo: apresentando a infraestrutura ampliada

Nós não falamos. Nós fazemos.

Todos nós já vimos o crescimento dos agentes de IA. Eles são fantásticos em resumir textos, escrever trechos de código e responder a perguntas baseadas em documentação. Mas, para nós que trabalhamos com DevOps e engenharia de confiabilidade de sites (SRE), houve uma limitação frustrante. A maioria dos agentes está presa ao paradigma do call center, o que significa que eles podem ler, pensar e conversar, mas não conseguem entrar em contato e tocar na infraestrutura que deveriam estar gerenciando.

Para nosso último projeto de hackathon, decidimos eliminar essa limitação.

Nós construímos Infraestrutura Ampliada: um copiloto de infraestrutura que não apenas dá conselhos, mas também cria, implanta, monitora e corrige seu ambiente em tempo real.

O problema: copiar, formatar, colar

Os agentes padrão operam em um vácuo. Se o seu app for desativado e custar US$ 5 milhões para a empresa, um agente padrão poderá ler para você o manual de instruções para corrigi-lo. Mas você ainda precisa fazer o trabalho. Você terá que copiar o código, reformatá-lo para o seu ambiente e colá-lo no terminal.

Queríamos um agente que entendesse a diferença entre falar sobre o Kubernetes e configurar o Kubernetes.

O motor: o que é o Elastic Agent Builder?

Para construir isso, não começamos do zero. Construímos sobre o Elastic Agent Builder. Para quem não conhece, o Elastic Agent Builder é um framework projetado para desenvolver agentes rapidamente, e atua como a ponte entre um grande modelo de linguagem (LLM) (na nossa demonstração, usamos o Google Gemini) e dados privados armazenados no Elasticsearch.

O Agent Builder pode ser usado para IA conversacional, baseando-o em dados internos, como documentos ou registros. Mas seu recurso mais avançado é a capacidade de alocar ferramentas que permitem que o LLM saia da interface de bate-papo para realizar tarefas específicas. Vimos que, se levássemos esse recurso ao limite, poderíamos transformar o Agent Builder em uma potência de automação.

Fazendo funcionar: construindo a primeira versão

Quando começamos o projeto, sabíamos que queríamos que os agentes fossem capazes de mudar o mundo exterior. Tivemos uma ideia: e se construíssemos algum software "runner" (para executar qualquer comando que o agente pudesse imaginar no host)? E depois: e se os runners, o Elastic Agent Builder e o usuário estivessem em uma chamada tripla?

Começamos desenvolvendo um projeto em Python, os Runners de Infraestrutura Ampliada, que era essencialmente um loop while(true) que consultava a API de conversas do Elastic Agent Builder a cada segundo e verificava uma sintaxe especial que havíamos criado:

{
"tool_name": "my_tool",
       "tool_arguments": "\{stringified json arguments\}"
}

Depois, atualizamos o prompt para ensiná-lo nossa nova sintaxe de chamada de ferramenta. Bill é o mantenedor do FastMCP, o framework mais popular para a criação de servidores MCP (Model Context Protocol) em Python. Ele começou a trabalhar usando o cliente FastMCP com esse novo software de runner para montar servidores MCP e disponibilizar suas ferramentas ao runner. Quando o agente via isso, ele executava a chamada de ferramenta e enviava os resultados via POST de volta para a conversa como se o usuário tivesse enviado os resultados. Isso acionou o LLM para responder ao resultado, e seguimos em frente!

Foi ótimo, mas houve dois problemas principais:

1. O agente despejava todo esse JSON diretamente na conversa com o usuário.

2. A primeira vez que as mensagens ficaram visíveis pela API de conversas foi quando uma rodada de conversa foi concluída (ou seja, quando o LLM respondeu).

Então, começamos a descobrir como colocar isso em segundo plano.

Em seguida, passamos a dar ao agente uma ferramenta chamada call_external_tool com dois argumentos: o tool_name e os argumentos da ferramenta JSON em string. Essa chamada de ferramenta externa não retornava nada, mas, mais importante, seria visível na requisição GET para a API de conversas. Em seguida, demos permissão aos runners para escrever documentos diretamente no Elasticsearch, que o agente do Elastic Agent Builder poderia recuperar conforme necessário. O agente está sempre operando em resposta a uma mensagem do usuário, então precisamos iniciar o agente com uma mensagem de usuário para que ele busque os resultados e continue o processamento. Então pedimos aos agentes que inserissem uma pequena mensagem no chat para retomar a conversa:

Então, agora tínhamos chamadas de ferramentas externas. No entanto, devido ao segundo problema mencionado acima, tivemos que eliminar a parte final do pontapé inicial. Caso contrário, cada chamada de ferramenta externa exigiria uma rodada completa de conversas para recuperar os resultados!

Aprimorando: introduzindo fluxos de trabalho

Além das chamadas da linguagem de consulta Elasticsearch (ES|QL) e da ferramenta de busca de índice, os agentes do Agent Builder podem chamar ferramentas baseadas em fluxo de trabalho da Elastic. Fluxos de trabalho da Elastic oferecem uma forma flexível e fácil de gerenciar para executar uma sequência arbitrária e uma lógica de ações. Para nossos propósitos, tudo o que precisamos é que o fluxo de trabalho armazene uma solicitação de ferramenta externa para o Elasticsearch e retorne uma ID para pesquisar os resultados. Isso resulta na seguinte definição simples de fluxo de trabalho:

nome: chamada-ferramenta-ai
 ativado: verdadeiro
 gatilhos:
 - tipo: manual
 entradas:
 - nome: runner_id
 tipo: string
 - nome: chamadas_de_ferramenta
 tipo: string

 passos:
 - nome: solicitação_armazenar
 tipo: elasticsearch.create
 com:
 índice: solicitações-de-ferramentas-distribuídas
 id: "{{inputs.runner_id}}_{{ execution.id }}"
 documento:
 request_id: "{{ execution.id }}"
 runner_id: "{{inputs.runner_id}}"
 chamada_de_ferramenta: "{{inputs.tool_calls}}"
 status: "não tratado"

 - nome: resultado_de_saída
 tipo: console
 com:
 mensagem: "Ferramenta chamada, com ID de execução: {{ execution.id }}. Use este ID para consultar os resultados.

Com isso, em vez de depender da solicitação de chamada de ferramenta ser gravada na conversa, os runners podem simplesmente consultar o índice distributed-tool-requests do Elasticsearch para novas solicitações de ferramentas externas e registrar os resultados em outro índice do Elasticsearch com o execution.id fornecido.

Isso elimina os dois principais problemas mencionados acima:

1. O histórico de conversas não está mais saturado com a carga útil das chamadas de ferramentas externas.

2. Como os runners estão consultando o índice do Elasticsearch em vez do histórico de conversas, eles não são bloqueados pela rodada de conversa a ser concluída para que os pedidos externos de ferramentas fiquem visíveis.

O segundo ponto tem a grande vantagem de que o processamento das chamadas de ferramentas externas começa dentro da fase de pensamento do agente (e não quando a rodada de conversação é concluída). Isso nos permite instruir o LLM no prompt do sistema para sondar os resultados da ferramenta externa até que os resultados estejam disponíveis e elimina a necessidade da mensagem de inicialização. De modo geral, isso tem o efeito positivo de tornar a conversa mais natural: o LLM consegue processar várias solicitações de ferramentas externas em uma única rodada de conversa (em vez de exigir uma rodada de conversa para cada solicitação de ferramenta) e, portanto, consegue atender a solicitações de usuários mais complexas de uma só vez.

Juntando tudo

Para preencher a lacuna entre o LLM e o rack de servidores, desenvolvemos uma arquitetura específica usando as capacidades da ferramenta do Agent Builder:

1. Runners de infraestrutura ampliada: implantamos executantes leves dentro dos ambientes de destino (servidores, clusters Kubernetes, contas de nuvem). Esses executores são conectados diretamente à Elastic, usando endpoints seguros e segredos disponíveis apenas para cada um dos executores.

2. Recuperação ES|QL: o copiloto usa o ES|QL da Elastic para realizar buscas híbridas. Ele não procura apenas conhecimento; procura capacidades. Ele consulta os executores runners para ver quais ferramentas estão disponíveis (por exemplo, list_ec2_instances, install_helm_chart).

3. Execução do fluxo de trabalho: quando o agente decide sobre um curso de ação, ele cria um fluxo de trabalho estruturado.

4. Ciclo de feedback: os runners executam o comando no local e enviam os resultados de volta ao Elasticsearch. O copiloto lê o resultado do índice e decide o próximo passo.

A demonstração: da interrupção à observabilidade

No vídeo, apresentamos dois casos distintos que demonstram como essa arquitetura pode melhorar.

Caso 1: Resgate do DevOps

Começamos com um usuário entrando em pânico por causa de uma queda de 5 milhões de dólares causada por um ponto cego no cluster Kubernetes deles.

• O pedido: "como garantir que isso não aconteça de novo?"

• A ação: o agente não se limitou a oferecer um tutorial. Ele identificou o cluster, criou os espaços de nome necessários, gerou secrets do Kubernetes, instalou o OpenTelemetry Operator e forneceu na hora um link para um dashboard de APM em tempo real.

• O resultado: total observabilidade do Kubernetes e insights do aplicativo sem que o usuário escreva uma única linha de YAML.

Caso 2: Transferência de segurança

Uma regra fundamental da segurança da infraestrutura é que você só pode proteger o que pode ver. Ao realizar nosso resgate de DevOps, o agente vê uma oportunidade de melhorar a segurança do ambiente.

Com um alerta iniciado a partir de uma investigação anterior relacionada ao Elastic Observability, demonstramos como um profissional de segurança pode interagir diretamente com sua infraestrutura: primeiro, para enumerar os ativos e recursos em seu ambiente de nuvem; e, segundo, para implantar as ferramentas necessárias para que o ambiente esteja seguro.

• Descoberta: o copiloto enumerou os recursos da AWS para o profissional de segurança e identificou uma lacuna crítica: uma instância do Amazon Elastic Compute Cloud (EC2) e um cluster do Amazon Elastic Kubernetes Service (EKS) com endpoints públicos sem proteção de endpoint.

• Correção: com uma simples aprovação, o copiloto implantou a detecção estendida e resposta (XDR) e detecção e resposta na nuvem (CDR) do Elastic Security nos ativos vulneráveis, protegendo o ambiente em tempo real.

• Resultado: proteção dos ativos e recursos AWS implantados com segurança completa em tempo de execução.

O futuro: tudo ampliado

Esse projeto comprova que o Elastic Agent Builder pode ser o cérebro central para operações distribuídas. Não estamos limitados apenas à infraestrutura. Nossa tecnologia de runners cobre:

• Synthetics ampliados: diagnosticando erros TLS em executores globais.

• Desenvolvimento ampliado: criando pull requests e implementando CAPTCHAs em serviços frontend.

• Operações aprimoradas: para reconfiguração automática de resolvedores de DNS durante uma interrupção.

Veja você mesmo

Acreditamos que o futuro da IA não se resume apenas ao suporte por chat; envolve Infraestrutura Ampliada. Envolve um parceiro que possa implantar, consertar, observar e proteger ao seu lado.

Confira o código e use os executores distribuídos (GitHub) e o Elastic Agent Builder no Elastic Cloud Serverless hoje mesmo!

• Crie um projeto serverless no Elastic Cloud.

• Implante o código em um runner.

• Prepare o runner.

• Configure seu mcp.json.

• Execute o runner, que criará automaticamente seu agente e as ferramentas.

• Converse com um agente que pode raciocinar, planejar e executar ações nos seus runners distribuídos!

A equipe: Alex, Bill, Gil, Graham e Norrie