O blog de desenvolvedores do Google publicou em 2 de setembro um artigo sobre engenharia de harness, assinado por Shir Meir Lador. O texto define harness de forma bem direta: todo o conjunto de componentes determinísticos que envolve o modelo de linguagem — camada de orquestração, sandbox de execução, persistência de estado e ferramentas de validação entram todos nessa definição.
O artigo abre com um número que chama atenção: em um produto experimental interno da OpenAI, a quantidade de código escrito à mão foi zero linhas — três engenheiros construíram e lançaram uma versão beta interna usando apenas código gerado pelo modelo. A autora usa o exemplo para mostrar que o problema não está na capacidade do modelo, e sim na estrutura que o mantém dentro de um processo controlável.
Rédeas, viseiras e pista de corrida
O artigo recorre a uma metáfora do turfe: o modelo é o cavalo, o harness é a pista, as viseiras e as rédeas, responsáveis por mantê-lo correndo numa única direção.
"The harness is composed of all the deterministic components that wrap the LLM."
O harness é composto por todos os componentes determinísticos que envolvem o modelo de linguagem.
Essa definição desloca uma parte do trabalho que antes era classificada como "prompt engineering". Restringir o comportamento do modelo só tem dois caminhos: escrever no prompt ou escrever no código externo. O primeiro depende da disciplina do próprio modelo — trocar de modelo exige reajustar tudo de novo; o segundo é uma restrição rígida, que continua valendo mesmo em novas gerações do modelo. No último ano, a maioria das equipes que construíram produtos de agentes testou os dois caminhos e pagou o preço dos dois. Aquela linha no prompt dizendo "não altere os arquivos de teste" — lá pela trigésima rodada de um contexto longo, o modelo começa a ficar seletivamente "cego" para ela.
Três princípios de design
Limites rígidos. Trancar o agente em uma sandbox, sem chance de tocar em dados de produção. Na demonstração do artigo, o agente só pode gravar arquivos dentro do diretório ./sandbox; operações fora desse limite simplesmente não são executadas.
Loop de correção. Erros não deveriam ir direto para uma pessoa resolver. Quando o teste falha, o harness devolve o log limpo ao modelo para que ele mesmo corrija o código. Aqui o ADK 2.0 usa um workflow baseado em grafo — a própria etapa de validação é um nó de roteamento dentro do grafo; uma execução falha redireciona automaticamente o fluxo de controle de volta ao nó de geração, sem precisar escrever lógica de retry à mão no código de orquestração.
Estrutura de repositório descobrível aos poucos. Em vez de escrever um arquivo de instruções com milhares de linhas e jogar tudo de uma vez para o agente, organizar o repositório para que ele consiga se aprofundar camada por camada, descobrindo o contexto conforme precisa.
O Antigravity SDK, que acompanha o ADK, cuida do lado do ambiente local: delimita as fronteiras do workspace e, ao mesmo tempo, oferece persistência de memória. Juntas, as duas ferramentas cobrem duas questões: "onde o agente roda" e "como ele volta ao normal quando erra".
O limite de cinco rodadas e aquele interruptor
O loop de autocorreção da demonstração completa um ciclo inteiro: o agente escreve código dentro de uma sandbox restrita, roda os testes automaticamente, o teste falha, o log volta, o agente corrige e roda de novo. O limite é de cinco rodadas; ao atingir esse teto, o harness interrompe o processo — a autora chama isso de kill switch.
Esse número cinco é o dado mais prático de todo o artigo. O modo de falha típico de um loop de autocorreção é o modelo ficar oscilando entre dois estados de erro, queimando tokens a cada rodada sem convergir. Definir um limite rígido é, na prática, admitir de antemão que o modelo às vezes não consegue resolver sozinho, devolvendo o problema para um humano mais cedo. Sem esse interruptor, um loop desgovernado pode estourar todo o orçamento durante uma noite sem supervisão.
Comparado aos frameworks de agentes que fizeram sucesso no primeiro semestre deste ano, essa mudança de foco fica bem clara. Os frameworks da primeira geração falavam sobretudo de orquestração — como encadear vários agentes, dividir tarefas, trocar mensagens. Agora o assunto é validação e limites: onde a execução acontece, como os erros retornam, quando parar. O primeiro resolve a questão de "consegue rodar?"; o segundo resolve a de "dá para confiar que vai rodar em um projeto real?".
Para equipes que não usam exatamente a pilha do Google, o ADK 2.0 e o Antigravity SDK como ferramentas específicas talvez não se apliquem diretamente — mas os três princípios podem ser copiados sem alterações. Sandbox, loop de correção, contexto descobrível aos poucos: qualquer agente de codificação construído internamente esbarra nesses três pontos, a única diferença é planejar isso desde o início ou só corrigir depois que ele apagar os arquivos de teste uma vez.
Fontes: blog de desenvolvedores do Google, CocoLoop, documentação dos projetos ADK e Antigravity SDK; a definição de harness, os três princípios de design e o limite de cinco rodadas foram conferidos no artigo original, e os números de zero linhas de código manual e três engenheiros foram citados conforme relatado no texto.