Harness² do Google Research: o que desenvolvedores podem aproveitar?

O Harness² testa mudanças no ambiente do agente durante a tarefa e guarda lições para as próximas. O ganho precisa ser confirmado em tarefas reais, com custo e segurança considerados.

Quando um agente de código falha, trocar de modelo parece a solução mais direta. Mas o resultado também depende das instruções recebidas, das ferramentas disponíveis, da memória, dos scripts de verificação e da forma como tudo isso é organizado durante a tarefa.

Foi esse ambiente, chamado agent harness, que me interessou no Harness². O projeto foi publicado no repositório google-research, com código sob licença Apache 2.0, e acompanha o preprint Harness²: Recursive Agent Harnessing for an Open World, submetido em 9 de outubro de 2026. O próprio README esclarece que não se trata de um produto Google oficialmente suportado.

A proposta merece atenção porque transforma uma pergunta vaga — “como melhorar o agente?” — em um processo de alteração, execução e comparação. O artigo descreve resultados promissores, mas ainda precisamos separar o que o estudo demonstrou do que faria sentido adotar num fluxo de desenvolvimento.

O que é o harness que o projeto modifica?

Um harness é a estrutura que permite ao modelo agir: instruções, interface de ferramentas, memória, regras e mecanismos de orquestração. No Harness², há oito componentes editáveis: prompt de sistema, guardrails, memória, orientação de ferramentas, subagentes, skills, scripts e plugins.

Eles atuam em lugares diferentes. Uma instrução pode orientar como o agente planeja; um script pode verificar um artefato; uma skill pode carregar um procedimento específico; um plugin pode interferir no ciclo de uso de ferramentas. Modificar esses componentes muda o comportamento do agente sem alterar os pesos do modelo.

Esse é o harness de execução. Ele é diferente do harness de avaliação usado para repetir testes de prompts, modelos e fluxos. Um executa a tarefa; o outro ajuda a medir o resultado. Também já discuti planejamento, ferramentas e contexto em agentes de código. O Harness² traz um passo adicional: experimentar mudanças nesse ambiente durante a tarefa e aprender com o processo.

Primeiro nível: propor, testar e compor

O núcleo do método é chamado Propose–Probe–Compose. O preprint descreve uma sequência:

1. O agente executa a tarefa com o harness atual e registra a trajetória e o artefato produzido.
2. Um processo de melhoria propõe alterações. Uma candidata trata falhas gerais, como planejamento ou uso de ferramentas; outra trata necessidades do domínio da tarefa.
3. Os harnesses candidatos executam a mesma tarefa em condições comparáveis. As trajetórias e os artefatos são confrontados com a execução de referência.
4. O processo compõe um novo harness a partir das mudanças que encontraram apoio nesse contraste — ou preserva a configuração anterior quando a evidência é insuficiente.

O contraste mostra como o comportamento mudou. Ele não é uma prova automática de que a resposta final está correta. Execuções podem variar, e candidatos diferentes podem compartilhar a mesma premissa errada.

O projeto também permite ampliar a exploração. No modo paralelo, testa várias candidatas e composições; no sequencial, uma rodada usa o harness e as evidências da rodada anterior. Mais tentativas podem trazer informação, mas também consomem mais chamadas de modelo e tempo.

Segundo nível: guardar o que foi aprendido

O “quadrado” do nome aparece na segunda camada. Depois de uma tarefa, o sistema registra o harness adotado e lições respaldadas pelas execuções em uma biblioteca de melhoria. Em uma tarefa futura, essa experiência pode orientar novas propostas.

Há uma escolha importante nesse desenho: a tarefa seguinte começa do harness base. Ela não recebe automaticamente toda a configuração criada para o problema anterior. Componentes e lições são recuperados seletivamente, conforme a nova situação. Isso reduz a chance de transformar um ajuste local em regra permanente sem evidência de transferência.

É uma ideia útil mesmo para quem nunca instalar o projeto: registrar não só “esta instrução funcionou”, mas em qual falha, em qual tarefa e com qual evidência ela pareceu ajudar.

O que os resultados realmente mostram?

Os autores avaliaram o método em WorkBuddy-Bench, JobBench e LAB, com combinações de Gemini 3.5 Flash e GLM-5 como modelos executores sob OpenCode e Codex. O editor padrão do harness nos experimentos foi Claude Opus 4.8. Portanto, o resultado não deve ser descrito como um teste de um único modelo trabalhando sozinho.

Segundo o artigo, uma rodada de melhoria superou o harness inicial nas configurações avaliadas, com ganhos máximos de 11,5 pontos no WorkBuddy-Bench, 4,5 pontos no JobBench e 11,8 pontos percentuais na métrica de aprovação parcial do LAB. Os números são máximos em recortes específicos, não uma média de ganho aplicável a qualquer agente.

Para devs, o WorkBuddy-Bench é especialmente interessante porque inclui tarefas de código, além de web e escritório. Ainda assim, ele não substitui uma avaliação em repositórios, linguagens, ferramentas e critérios de qualidade da sua equipe. O estudo também apresenta casos de regressão: uma seleção escolheu um resultado pior, e premissas incorretas foram propagadas entre candidatas. A melhoria é uma hipótese sustentada por execuções, não uma garantia de acerto.

Um experimento pequeno para um agente de código

Imagine uma tarefa fictícia: corrigir um formulário cujo estado de erro desaparece depois de uma nova tentativa de envio. O agente localiza o componente, edita o código, roda os testes e entrega um resumo. Na primeira execução, porém, ele descreve comandos de teste no texto final sem executá-los.

Uma hipótese é que a orientação de ferramentas esteja insuficiente. Antes de adicionar memória, subagentes e novos plugins, eu testaria uma mudança pequena: instruir o agente a executar a verificação disponível, registrar o comando e distinguir teste executado de teste apenas sugerido.

Compararia o harness original e o alterado na mesma tarefa e no mesmo ambiente isolado. Guardaria o diff do harness, as trajetórias, os arquivos produzidos e o resultado dos testes. Depois, repetiria o experimento em algumas tarefas semelhantes e diferentes. O critério não seria só “o texto ficou melhor”, mas:

• os testes foram realmente executados e passaram?
• a correção resolve o comportamento pedido sem introduzir regressão?
• o agente usou ferramentas corretamente?
• quanto tempo e custo adicional a melhoria exigiu?
• a instrução ajudou outras tarefas ou criou rigidez desnecessária?

Esse exemplo é um plano de avaliação, não um teste que executei com o Harness². Uma equipe poderia aplicar o mesmo princípio com seu agente atual, mesmo sem reproduzir o framework inteiro.

Quando vale testar — e quando o custo pesa

O método parece mais interessante quando há tarefas repetidas, trajetórias observáveis e espaço para verificar resultados. Nesse cenário, pequenas mudanças em ferramentas, instruções ou scripts podem ser avaliadas antes de virar padrão. Em tarefas únicas e baratas, várias execuções para refinar o harness podem custar mais do que uma revisão humana direta.

O apêndice de limitações reconhece o custo extra de inferência e a fragilidade de julgar sem resposta correta conhecida. O README também informa que o executor pode ter acesso irrestrito à rede e que a integração com Codex desativa a sandbox. Isso torna isolamento, dados não sensíveis, permissões e restrições de rede parte do desenho do experimento. O próprio repositório oferece uma demo local determinística sem credenciais de modelo; rodadas com modelos e benchmarks podem gerar custo de API.

Meu principal aprendizado da leitura é metodológico: antes de “melhorar o agente” com mais instruções, descubra onde ele falha, escolha um componente correspondente e compare o efeito em execuções observáveis. Se o resultado não resistir a tarefas novas, a mudança talvez pertença apenas àquela situação.