Agentes híbridos no Antigravity: a fronteira de dados importa mais que a divisão de tokens

O Google adicionou suporte a modelos locais no Antigravity SDK, permitindo combinar agentes executados no computador com modelos de nuvem.[9] A InfoQ descreve uma arquitetura com um planejador de visão geral e executores especializados em tarefas menores e ambientes isolados.[9] A oportunidade de engenharia é controlar melhor onde cada informação é processada, não apenas transferir consumo de tokens para outro lugar.

O que muda para quem desenvolve

Na variante apresentada, o arquiteto remoto pode receber nomes de arquivos e descrições de tarefas sem receber o código-fonte; executores locais reproduzem problemas, propõem correções e executam regressões.[9] Outros agentes locais podem validar as mudanças.[9]

Em uma demonstração com três módulos Python vulneráveis, o Google informa que 95 de aproximadamente 3.400 tokens foram consumidos na nuvem, com 97,2% na execução local, e afirma que nenhum código-fonte foi enviado ao serviço remoto.[9] Esse é o escopo do relato, não uma comprovação de privacidade para qualquer configuração híbrida.

Minha análise é que a fronteira precisa ser definida por conteúdo permitido. Uma descrição de tarefa pode conter segredo, trecho de erro ou nome sensível mesmo quando o arquivo completo não é transmitido. Planejamento remoto sem código só ajuda se mensagens, ferramentas e diagnósticos também obedecerem à política escolhida.

A implementação inicial usa Gemma 4 26B A4B com LiteRT e aceita servidores locais compatíveis com a API OpenAI por LocalOpenAIAgentConfig, incluindo Ollama, LM Studio e vLLM.[9] Essa flexibilidade deve ser avaliada como opção de implantação, não como prova de equivalência entre os modelos e servidores.

Como aplicar

Monte um repositório de teste com uma falha pequena e critérios de aceite definidos antes da execução. Compare uma configuração inteiramente remota com a híbrida, mantendo a mesma tarefa e o mesmo avaliador.

No piloto híbrido, prepare manualmente uma descrição sanitizada para o planejador. Autorize apenas leitura e testes necessários aos executores. Capture as mensagens destinadas ao serviço externo em um ambiente sem dados reais e procure trechos que não deveriam cruzar essa fronteira.

Use marcadores fictícios no código para verificar a política de saída. O teste passa se a tarefa for concluída e esses marcadores não aparecerem nas requisições remotas. Não use credenciais reais como isca.

Meça patches aceitos, tempo total, memória e necessidade de intervenção. Inclua o custo operacional de servir o modelo local. Reduzir chamadas de API só é vantagem quando a tarefa continua correta e o equipamento não vira o gargalo.

Cuidados e limites

Um comentário citado pela InfoQ destaca recomendação de 24 GB ou mais de VRAM ou memória unificada e pede comparações de tempo, energia e aceitação de patches.[9] Isso é uma observação da comunidade, não uma medição reproduzida no seu hardware.

O SDK não deve ser confundido com a IDE Antigravity.[9] Também não presuma que inferência local significa ausência de rede. A arquitetura útil é aquela cuja fronteira foi observada, cujas permissões são limitadas e cujo resultado passou por uma verificação independente.

Fonte

[9] Fonte: InfoQ