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 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) (em 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 atribuir ferramentas. Essas ferramentas permitem que o LLM saia da interface de bate-papo para realizar tarefas específicas. Percebemos 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:

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 este novo software de runner para montar servidores MCP e disponibilizar suas ferramentas ao runner. Quando o agente via isso, executava a chamada de ferramenta e POST os resultados 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!

Isso foi ótimo, mas houve dois problemas principais:

1. O agente despejaria todo esse JSON diretamente na conversa com o usuário.
2. O momento mais antigo em que mensagens eram 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.

Depois, passamos a dar ao agente uma ferramenta chamada call_external_tool com dois argumentos: o argumento tool_name e o argumento da ferramenta JSON stringified. Essa chamada de ferramenta externa não retornaria 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:

Com isso, em vez de depender do pedido de chamada de ferramenta registrado 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: nós 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 buscar híbridas. Não busca apenas conhecimento; busca 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 localmente 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 cenários distintos que demonstram como essa arquitetura pode melhorar.

Cenário 1: Resgate 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 faço para 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 instantaneamente 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.

Cenário 2: transferência de segurança

Uma regra fundamental da segurança da infraestrutura é que você não pode proteger o que não 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 garantir 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.
• Remediação: com uma simples aprovação, o copiloto implantou Elastic Security detecção estendida e resposta (XDR) e detecção e resposta na nuvem (CDR) 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

Este projeto prova 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 pode melhorar:

• Synthetics ampliados: diagnosticando erros TLS em executores globais.
• Desenvolvimento ampliado: criando pull requests e implementando CAPTCHAs em serviços frontend.
• Operações aprimoradas: Reconfiguração automática de resolvedores de DNS durante uma interrupção.

Experimente você mesmo

Acreditamos que o futuro da IA não se resume apenas ao suporte por chat; trata-se de Infraestrutura Ampliada. Trata-se de ter um parceiro que possa implantar, consertar, Observe e Protect ao seu lado.

Confira o código e experimente você mesmo com 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 executor.
• Prepare o runner.
• Configure seu mcp.json.
• Execute o runner, que criará seu agente e suas ferramentas automaticamente.
• 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