Sobre o Agent Substrate do GKE

O Agent Substrate executa cargas de trabalho de agentes em grande escala em clusters do Kubernetes. Ele aborda uma ineficiência comum de recursos: os agentes interativos (como assistentes pessoais e agentes de programação) geralmente passam a maior parte do tempo esperando a entrada do usuário ou acionadores externos. Manter esses agentes inativos em execução contínua usa CPU e memória que poderiam ser alocadas para cargas de trabalho ativas.

O Agent Substrate resolve esse problema suspendendo agentes inativos e tirando um snapshot da memória ativa (RAM) e dos arquivos locais do agente. Quando o agente suspenso precisa agir novamente, o sistema restaura o estado dele em um sandbox disponível em menos de um segundo.

O Agent Substrate se baseia nos recursos do sandbox do agente e o melhora ao ignorar os gargalos do plano de controle padrão do Kubernetes. Como resultado, ele executa muito mais agentes simultâneos por máquina e reduz drasticamente os tempos de inicialização dos agentes.

As implantações padrão do Kubernetes (incluindo o sandbox do agente) associam cada carga de trabalho do agente a um pod dedicado. Embora o Kubernetes seja altamente escalonável, ele é limitado pela capacidade de processamento de programação e pela latência de inicialização dos pods. Além disso, o Kubernetes não oferece suporte à hibernação de pods, e manter milhões de agentes inativos em um cluster esgotaria os limites de pods e a memória do plano de controle. Para evitar pagar por recursos computacionais inativos, é necessário desligar os pods e gerenciar o estado do agente em um armazenamento externo. O Agent Substrate resolve essas restrições de escalonamento ao desacoplar o estado do agente dos pods subjacentes. Ele armazena milhões de snapshots de agentes suspensos no armazenamento e os restaura sob demanda em um pool compartilhado de workers ativos.

O Agent Substrate é um sistema de código aberto que você implanta diretamente nos seus próprios clusters GKE Standard. Embora o projeto principal seja desenvolvido no repositório Agent Substrate de código aberto, o Google fornece ferramentas e scripts de implantação otimizados para o GKE no repositório substrate-gke para clientes Google Cloud qualificados.

Benefícios do Agent Substrate

Você pode usar o Agent Substrate para alcançar as seguintes metas:

  • Execute código não confiável com segurança: o Agent Substrate impõe o isolamento do kernel e da rede para que você possa executar o código gerado por IA sem arriscar sua infraestrutura mais ampla.
  • Crie agentes com estado e de longa duração: a memória de trabalho e os arquivos de um agente são preservados entre as sessões. O agente retoma do ponto exato em que foi pausado.
  • Responder a solicitações em tempo real: quando uma nova solicitação aciona um agente suspenso, o sistema restaura o estado do agente em uma fração de segundo.
  • Reduzir os custos de computação: é possível executar mais agentes em menos máquinas compartilhando um pool de sandboxes de worker em todos os agentes. Como os agentes inativos são suspensos e não usam CPU nem memória, você paga pela computação somente quando os agentes estão processando tarefas ativamente.

Casos de uso

O Agent Substrate foi projetado para executar agentes em qualquer escala, de dezenas a milhões de agentes simultâneos. Confira três exemplos de cargas de trabalho:

  • Agentes de produtividade: assistentes em segundo plano de longo prazo que mantêm o contexto por semanas. Como esses assistentes passam a maior parte do tempo aguardando acionadores, suspender as cargas de trabalho quando não estão em uso reduz os custos de computação.
  • Sandboxes efêmeros: ambientes isolados e sob demanda para executar código não confiável gerado por LLMs, executar chamadas de ferramentas ou analisar dados. Como os sandboxes são restaurados em menos de um segundo, o sistema pode fornecer ambientes descartáveis para tarefas de curta duração e liberar recursos quando a execução termina.
  • Agentes de programação: assistentes de IA que conversam em tempo real com desenvolvedores para escrever, criar e testar código. O agente executa comandos de terminal e modifica arquivos em um sandbox. Quando o agente fica inativo, o sistema o suspende até que o desenvolvedor envie outro comando.

Como o Agent Substrate funciona

O Agent Substrate é criado no Kubernetes, mas não é necessário entender o Kubernetes para usá-lo. Os principais conceitos do Agent Substrate são:

  • Ator: uma única instância em execução de um agente.
  • ActorTemplate: um modelo de configuração (que define imagens de contêineres, variáveis de ambiente e recursos de computação) usado para instanciar atores.
  • Worker: uma sandbox segura em que um ator ativo é executado.
  • WorkerPool: um grupo de workers ociosos e pré-iniciados que ficam prontos para receber um ator.

Como um ator não está vinculado a um worker específico, o sistema pode suspender agentes inativos e reutilizar a computação liberada. Essa arquitetura permite que o sistema execute milhões de agentes em um número limitado de máquinas.

Um ciclo de vida típico do agente segue estas etapas:

  1. Roteamento: cada solicitação de API recebida do seu aplicativo especifica o ator de destino. Por exemplo, quando um usuário digita um novo comando em uma interface de chat, o aplicativo envia uma solicitação direcionada ao ator específico que gerencia a sessão do usuário.
  2. Retomada: se a solicitação for para um ator suspenso, o sistema vai reivindicar um worker ativo do WorkerPool e restaurar o snapshot do ator nesse worker.
  3. Execução: o sistema encaminha a solicitação para esse worker recém-ativado, e o ator processa a tarefa.
  4. Suspensão: quando o ator termina o trabalho e fica inativo, o sistema faz um novo snapshot da memória e dos arquivos do ator, salva o snapshot no armazenamento e libera o worker vazio de volta para o pool.

Isolamento de carga de trabalho e GKE Sandbox

O Agent Substrate usa o gVisor ou o Cloud Hypervisor para executar cada carga de trabalho em um sandbox que isola o código do aplicativo do kernel do host. A instalação do Agent Substrate inclui um tempo de execução do gVisor para workers. Assim, não é necessário configurar o GKE Sandbox nos nós do GKE subjacentes.

Limitações e requisitos

O Agent Substrate tem as seguintes limitações e requisitos:

  • Versão do cluster e APIs Beta: o Agent Substrate é compatível com clusters GKE Standard que executam a versão 1.36 (com flags Beta ativadas) ou a versão 1.37 ou mais recente. Versões anteriores à 1.36 não têm suporte. Além disso, o GKE exige APIs Beta (podcertificaterequests e clustertrustbundles). Se você ativar essas APIs em um cluster atual que executa a versão 1.36, também será necessário substituir os nós atuais para que a projeção de certificado do pod seja ativada neles. Na versão 1.37 ou mais recente, não é necessário substituir os nós atuais.
  • Federação de identidade da carga de trabalho para GKE: os clusters do GKE precisam ter a Federação de identidade da carga de trabalho para GKE ativada. O Agent Substrate usa a Federação de Identidade da Carga de Trabalho para GKE para autenticar APIs do Google Cloud , como o Cloud Storage para salvar snapshots do agente.
  • Famílias de VMs:
    • Arquiteturas de CPU mistas: o Agent Substrate não é compatível com séries de máquinas de uso geral que são executadas em arquiteturas de CPU mistas (como tipos de máquinas E2) devido a um problema conhecido com o gVisor.
    • Tipos de VM uniformes por modelo de ator: não é possível misturar tipos de VM em um único ActorTemplate (o plano de configuração usado para criar atores). Por exemplo, se o cluster tiver dois pools de nós usando VMs C4 e N2, um ActorTemplate precisará incluir um seletor de nós que especifique um único tipo de VM (como C4) para evitar que os atores desse modelo sejam divididos em diferentes tipos de máquina.
  • Suporte a GPU: a transmissão direta de dispositivos de GPU para contêineres de atores não é compatível. Especificar nvidia.com/gpu só coloca pods em nós habilitados para GPU, mas não transmite o dispositivo de GPU para o contêiner do ator. Além disso, o gVisor não pode criar snapshots de contextos CUDA ativos.
  • Rede:
    • Políticas de saída: as regras EgressPolicy (controles de rede por nome do host e endereço IP) não são compatíveis, incluindo os seguintes recursos:
      • Regras de negação padrão
      • Regras com base no nome do host
      • Injeção de credenciais
    • Conexões abertas: as conexões de rede abertas (como sessões de banco de dados ou conexões com servidores MCP) não são preservadas quando um agente é suspenso. O código do agente precisa processar a reconexão a serviços externos quando o agente é retomado.
  • Observabilidade e OpenTelemetry gerenciado: o OpenTelemetry gerenciado para GKE tem as seguintes limitações:
    • O OpenTelemetry gerenciado para GKE está em prévia.
    • Os conectores do coletor não são compatíveis, o que exige o uso de um medidor de proxy externo para comparativo de mercado de telemetria.
    • As implantações do coletor geram uma sobrecarga de cache em memória que é escalonada linearmente com o número de pods em clusters grandes.
    • O TLS não é compatível com o OpenTelemetry gerenciado para GKE.
  • Armazenamento: o sistema exige o Cloud Storage para salvar os snapshots dos seus agentes.
  • Ambiente de instalação: não é possível instalar o Agent Substrate no Cloud Shell. O Cloud Shell tem um limite de armazenamento em disco permanente de 5 GB, o que não oferece espaço em disco suficiente para a instalação. É necessário instalar o Agent Substrate em uma estação de trabalho local ou em uma máquina virtual (VM) com espaço em disco suficiente.

A seguir