Harness² Do Google: E Se O Agente Reescrevesse O Próprio Harness Sem Tocar Nos Pesos?

Quem mantém um AGENTS.md, um conjunto de skills e um punhado de scripts de apoio conhece o ritual. A tarefa nova chega, o agente tropeça num lugar previsível, alguém abre o arquivo de instruções, acrescenta duas linhas, roda de novo e torce. Funciona quando a tarefa se parece com as anteriores. Quando ela é realmente nova, a pergunta incômoda aparece: quem ajusta o harness antes de a gente saber o que deu errado?

Essa dúvida me acompanhou durante a leitura de um paper que o Google Research submeteu ao arXiv em 9 de outubro de 2026, chamado Harness², e do repositório que veio junto. A proposta é que o próprio agente reescreva o seu harness, a cada tarefa, sem mexer nos pesos do modelo e sem ter um gabarito de respostas corretas para conferir. Não é a primeira vez que alguém tenta algo parecido, mas o desenho é específico o bastante para valer uma leitura devagar.

Preciso ser claro sobre o que fiz. Não rodei o Harness², não reproduzi nenhum benchmark e não tenho experiência de uso com ele. O que apresento vem da leitura do paper (resumo e a versão em HTML), da página do repositório e de uma análise secundária da Flowtivity. As seções de custo e de limitações do paper ficam nos apêndices, e esses eu não li. Onde a Flowtivity é a fonte de uma ressalva, eu aviso.

O texto segue assim: o problema que o paper descreve, o ciclo Propose–Probe–Compose passo a passo, a biblioteca que carrega lições entre tarefas, os números e o que eles sustentam, as ressalvas, e um cenário hipotético de como um time pequeno poderia aproveitar a ideia sem instalar o framework.

O Problema Que O Paper Descreve

O ponto de partida do paper é o chamado mundo aberto: tarefas que ninguém viu quando desenhou o harness. Nesse cenário, segundo os autores, não existem verificadores de ground truth para guiar edições online. Você não sabe se a saída do agente está certa; sabe apenas o que ele fez e o que entregou. Qualquer mecanismo de melhoria precisa funcionar nessa condição, com tarefas chegando em fluxo, sem respostas corretas e sem validação rotulada.

O paper também registra que as abordagens existentes de auto-melhoria recursiva são muito específicas de tarefa e generalizam mal. Faz sentido para quem já tentou: um prompt ajustado até a exaustão para um tipo de ticket costuma ser inútil, ou até prejudicial, no ticket seguinte. O desafio, então, é melhorar de forma que sobreviva à mudança de tarefa.

Para tornar o problema concreto, o paper define harness como o scaffolding de execução em volta do modelo. São oito componentes editáveis, tratados como arquivos: system prompt, guardrails, memória, skills, guia de ferramentas, scripts, subagentes e um plugin de middleware. Os pesos ficam congelados. Tudo o que o sistema pode alterar é esse conjunto de arquivos, o que o aproxima do que times de engenharia já fazem à mão. Já tratei dessa disciplina no post complementar sobre SDD e harness engineering, e o Harness² pode ser lido como a pergunta seguinte: e se essa edição fosse automática?

Vale registrar uma coisa sobre o repositório antes de avançar. Ele é da organização google-research, os autores listados são Ruiyao Xu, Yanfei Chen, Zhongying CuiZhu, Bhavana Dalvi Mishra, Yifei Ming, Han Yu, Rujun Han, Chen-Yu Lee e Tomas Pfister, do Google Cloud AI Research, e a licença é Apache 2.0. O README diz que não é um produto oficialmente suportado do Google. No momento em que o repositório foi capturado para este texto, ele tinha cerca de 21,2 mil estrelas e 2,1 mil forks. Isso diz que muita gente olhou; não diz nada sobre desempenho, e não uso o número como argumento.

Propose–Probe–Compose Passo A Passo

A recursão em nível de tarefa tem três fases, e a graça está em como elas substituem a ausência de gabarito por contraste. A primeira é o Propose. O sistema amostra uma execução de referência do harness atual e, a partir dela, gera dois candidatos de edição. Um é o candidato invariante, voltado a fraquezas transversais, como planejamento e uso de ferramentas. O outro é específico do domínio da tarefa. A separação é útil porque obriga a distinguir o que é problema do agente em geral do que é problema desta tarefa.

A segunda fase é o Probe. Cada candidato roda na mesma tarefa, em condições equivalentes à da referência, e o sistema contrasta a trajetória e o entregável de cada um com os da execução original. O paper trata esses contrastes como evidência, não como prova de correção. Essa distinção é o coração do método: sem verificador, ninguém afirma que o candidato A está certo; afirma-se que, comparado à referência, ele mudou o comportamento de um jeito observável e, em tese, favorável.

A terceira é o Compose. Aqui o sistema funde seletivamente as mudanças que foram apoiadas pelas observações, revisa as que entram em conflito, e então adota um candidato, combina partes dos dois ou mantém o harness atual. O paper insiste que cada decisão fica ligada a uma observação. Manter o harness como estava é uma saída legítima do ciclo, e isso importa: um sistema que sempre edita tende a acumular mudanças que ninguém sabe justificar.

Existem dois modos de escalar esse ciclo com um orçamento k. No modo paralelo, k composições independentes partem de um pool compartilhado de evidências, e um seletor escolhe entre entregáveis anonimizados. No modo sequencial, k passos são encadeados, cada um condicionado ao histórico dos anteriores. O paralelo troca profundidade por diversidade e depende da qualidade do seletor; o sequencial pode refinar, mas carrega para a frente qualquer erro anterior. Nas comparações que reproduzo adiante, o paper usa k=1 e a recursão paralela com k=5.

Quem trabalha com feedback sensors e a ideia de colocar coding agents na coleira reconhece o tipo de problema: o sinal de feedback é a parte difícil. A escolha do Harness² é fabricar sinal por comparação entre execuções da mesma tarefa, em vez de importar um sinal externo. É uma aposta razoável e, ao mesmo tempo, o ponto mais frágil, como as ressalvas vão mostrar.

Um detalhe de arquitetura merece atenção. Quem propõe as edições é um modelo editor, que nos experimentos é o Claude Opus 4.8, enquanto os executores que realizam as tarefas são outros modelos. Isso significa que os ganhos medidos combinam o harness melhorado com a capacidade do editor de enxergar o que melhorar. O paper separa os papéis, o que é um desenho claro, mas é um lembrete de que o editor também é um modelo forte trabalhando em favor de executores mais fracos.

A Biblioteca Que Aprende Entre Tarefas

O ciclo anterior é a primeira recursão. A segunda, que o paper chama de recursão em nível de harnessing, opera entre tarefas. Depois de cada tarefa, o sistema reflete sobre o registro daquela melhoria e atualiza uma biblioteca. Cada entrada guarda duas coisas: um harness executável e um arquivo EXPERIENCE.md, com a aplicabilidade da entrada, as lições aprendidas e a evidência que as sustenta.

Há uma regra de conservação aqui: as lições só permanecem se forem apoiadas por contrastes de execução. Ou seja, o sistema não escreve "aprendi que X" por opinião; precisa apontar a observação que mostra X. É um filtro contra a acumulação de folclore, problema bem conhecido de qualquer base de conhecimento de agente que cresce sem curadoria. Quem acompanha o tema reconhece também a família de ideias do Memento Skills e do automelhoramento de agentes, em que habilidades são acumuladas a partir da experiência.

Um ponto fácil de entender errado: a biblioteca não faz o harness ir ficando cada vez mais ajustado de tarefa em tarefa. Segundo o paper, tarefas futuras ainda partem do harness base e reutilizam entradas da biblioteca por meio de propostas e de composição, em vez de herdar um harness já ajustado. Pense nisso como um repertório de edições testadas à disposição do Propose e do Compose, não como um estado que deriva. A vantagem é que um ajuste ruim não contamina tudo o que vem depois.

Outro detalhe de protocolo: a biblioteca começa vazia em cada fluxo de benchmark. Isso evita que o resultado dependa de conhecimento acumulado fora do experimento, mas também significa que o paper mede a biblioteca aprendendo dentro de um fluxo de tarefas, não uma biblioteca madura de meses de uso. O que acontece depois de milhares de entradas, com sobreposições e contradições entre elas, não é algo que o material que li responda.

Na análise secundária, a Flowtivity relata uma ablação: remover a biblioteca custou 3,1 e 1,8 pontos em dois benchmarks. Isso vem da Flowtivity, não do trecho do paper que li, e o texto dela não me permite dizer quais foram os dois benchmarks. Mesmo assim, o dado ajuda a dimensionar: a biblioteca contribui, mas é uma fração do ganho total, e boa parte do que o método entrega vem do ciclo Propose–Probe–Compose dentro de cada tarefa.

Os Números E O Que Eles Sustentam

Os testes usam três benchmarks: WorkBuddy-Bench (com subconjuntos Code, Web e Office), JobBench, de tarefas profissionais longas, e LAB, de trabalho jurídico, com a métrica Partial pass rate. Os executores são Gemini 3.5 Flash e GLM-5, cada um sob dois harnesses base, OpenCode e Codex. Os resultados são médias de três execuções com a ordem das tarefas embaralhada. Os baselines são o harness base, o ReasoningBank (memória por recuperação), o Meta-Harness (busca offline) e o Harness Scaling (revisão por instância). A tabela abaixo reúne uma parte dos números do paper, só com o harness OpenCode, indo do harness base ao Harness² com k=1 e à recursão paralela com k=5.

Executor e benchmark	Base	Harness² k=1	Paralelo k=5
Gemini 3.5 Flash, WorkBuddy médio	72,4	77,5	80,8
GLM-5, WorkBuddy médio	64,2	75,7	79,6
Gemini 3.5 Flash, JobBench	31,5	36,0	39,0
GLM-5, JobBench	20,6	24,2	28,4
Gemini 3.5 Flash, LAB Partial	79,9	81,9	84,5
GLM-5, LAB Partial	59,6	71,4	78,1

Os maiores ganhos com um único passo foram 11,5 pontos no WorkBuddy (GLM-5 com OpenCode), 4,5 no JobBench e 11,8 pontos no LAB Partial. A recursão paralela acrescentou de 2,9 a 3,9 pontos no WorkBuddy, de 3,0 a 4,2 no JobBench e de 2,6 a 6,7 no LAB, sobre o passo único. Os escores subiram de forma monotônica com k nas análises de WorkBuddy-code e WorkBuddy-office. Os resultados com Codex seguem padrão parecido, e os números completos estão no paper.

O padrão mais interessante é que o executor mais fraco ganha mais. O GLM-5 com Harness² chega a 75,7 no WorkBuddy com OpenCode, contra 72,4 do Gemini 3.5 Flash com o harness original, uma diferença de 3,3 pontos a favor do modelo mais fraco com harness melhorado. Esse é o tipo de dado que alimenta manchetes, e é onde convém cuidado. O paper mostra que, nestes testes, o harness importa muito. Não mostra, nem pretende mostrar, que o harness vale mais que o modelo em geral. E são benchmarks do próprio Google, com um editor forte ajudando um executor fraco.

Os baselines contam parte da história. O ReasoningBank ficou até 6,6 pontos abaixo do harness base em tarefas de código, e o Harness Scaling ficou abaixo do base em 7 de 12 pares benchmark–configuração. Ou seja, abordagens plausíveis de melhoria podem piorar o resultado, o que reforça o argumento do paper sobre a dificuldade de editar sem verificador. O paper também aponta que a recursão não fecha de maneira uniforme a diferença entre os harnesses OpenCode e Codex, então o harness de partida continua importando.

Sobre como ler tudo isso, minha regra é a que uso para qualquer resultado de laboratório: são números de paper, medidos pelos autores, em benchmarks escolhidos por eles, com três execuções por configuração. São evidência séria de que o mecanismo funciona nessas condições, e não são previsão do que acontece no seu repositório. Quem já passou por como avaliar a qualidade de agentes com evals sabe que a distância entre um benchmark bem comportado e o seu fluxo real costuma ser grande.

As Ressalvas, E O Que Eu Não Li

Começo pelo que não li. O paper traz o texto das análises de custo e de limitações apenas nos apêndices, e eu não os li. Tudo o que segue sobre ressalvas vem da análise da Flowtivity, que se apoia no paper, e portanto é uma leitura de segunda mão. Relato de imprensa especializada não substitui a fonte primária, e quem for decidir algo com base nisso deve abrir os apêndices.

Segundo a Flowtivity, o seletor pode escolher uma saída pior do que as alternativas; o exemplo citado compara um entregável de nota 55 escolhido sobre outro de 95. Como o seletor trabalha com entregáveis anonimizados e sem gabarito, isso é uma consequência natural do desenho: se o critério de escolha for fraco, escalar k só multiplica a chance de uma escolha errada. A mesma análise diz que premissas erradas podem se propagar entre candidatos, com custo de 2 a 11 pontos. Se o candidato nasce de uma execução de referência que interpretou mal a tarefa, o erro de interpretação contamina a família inteira de edições.

Há também o custo. Compute extra em tempo de teste aumenta o custo de inferência, e o modo paralelo com k=5 roda várias composições por tarefa. A Flowtivity aponta isso como ressalva, e eu não tenho os números de custo do paper. Sem ground truth, a evidência também é ruidosa e as lições podem não transferir de uma tarefa para outra. E o escopo experimental é estreito: dois executores e dois modelos, o que limita o quanto se pode extrapolar para outras combinações.

Para equilibrar, a mesma análise registra que as taxas de erro de ferramenta caíram em todos os benchmarks, em até 36,8% em termos relativos. É um dado interessante porque aponta um mecanismo plausível para o ganho: se o agente erra menos ao chamar ferramentas, boa parte da melhoria pode vir daí. Mas é uma leitura sobre o resultado, não uma explicação causal completa, e, de novo, vem da Flowtivity.

Sobre o uso, o README descreve que o projeto requer Linux, Python 3.12 e uv. Há uma demonstração local sem credenciais de modelo, harness2-demo --output runs/demo --k 2. Os benchmarks com modelo exigem Node.js 20 ou superior, Google Cloud CLI e dependências adicionais, como Pandoc e Poppler para o LAB e Docker para o WorkBuddy-Bench. As rodadas com modelo geram custo de API, os resultados vão para a pasta runs/ e repetir um comando retoma a execução. Os executores suportados são OpenCode, que é o padrão, e Codex. Quem gosta de agentes enxutos, como o que comentei no post sobre o pi coding agent e o minimalismo no terminal, vai notar que aqui o harness é a parte pesada do sistema.

Cenário Hipotético Para Um Time Pequeno

Nem todo mundo vai instalar o framework, e a ideia central é transportável. O cenário a seguir é hipotético, uma adaptação minha, não algo que o paper recomende nem que eu tenha testado. Imagine um time de cinco pessoas com um AGENTS.md de uns cinquenta linhas e uma tarefa recorrente que o agente faz mal, como migrar endpoints de uma versão de API para outra.

Em vez de reescrever o arquivo por intuição, o time faz o equivalente manual do Propose–Probe–Compose. Primeiro, roda uma execução de referência com o AGENTS.md atual e guarda a trajetória e o resultado. Depois, escreve duas edições candidatas: uma geral, sobre um hábito ruim do agente, como não rodar os testes antes de declarar a tarefa pronta, e outra específica, com as regras da migração. Cada candidato roda na mesma tarefa, no mesmo commit de partida, e alguém compara as trajetórias com a referência.

A comparação é o passo que o paper chama de Probe, e o ponto é tratar o resultado como evidência, não como veredito. Se a edição geral reduziu um erro de ferramenta visível na trajetória, isso é um indício; se a específica produziu um diff melhor mas quebrou outra coisa, o time funde só a parte que se sustenta. No final, a decisão fica registrada com a observação que a motivou, e uma nota curta sobre aplicabilidade e lições faz o papel do EXPERIENCE.md. Uma pasta no repositório com essas notas é a versão artesanal da biblioteca.

Os limites do exercício são os mesmos das ressalvas. Uma única execução por candidato é ruidosa, e rodar três vezes triplica o custo. Se a execução de referência entendeu mal a tarefa, os dois candidatos podem herdar o erro. E sem um critério claro do que é uma saída boa, o time corre o risco de escolher a edição que parece melhor, não a que é melhor. Por isso eu começaria por tarefas em que o resultado é verificável por teste, onde o contraste tem um chão firme, e só depois tentaria as tarefas sem gabarito.

Conclusão

O que mais me interessa no Harness² não é o ganho numérico, e sim o desenho: trocar o verificador ausente por contraste entre execuções da mesma tarefa, tratar o contraste como evidência, e deixar a decisão de manter o harness como estava. Essa humildade metodológica é mais transferível do que o framework. Mesmo quem nunca instalar o repositório pode adotar o hábito de testar uma edição de instrução contra uma referência, na mesma tarefa, antes de acreditar nela.

Os limites do que sei são claros. Li o paper e o repositório, não rodei nada, não li os apêndices de custo e limitações, e as ressalvas mais concretas vêm de uma análise secundária. Os resultados são do próprio Google, em benchmarks escolhidos pelos autores, com um editor forte (Claude Opus 4.8) e dois executores. Isso sustenta a afirmação de que, nesses testes, o harness fez uma diferença grande. Não sustenta a de que harness importa mais que modelo em geral, e eu evitaria repeti-la.

Fico com uma dúvida em aberto, que o material que li não responde: o que acontece com uma biblioteca de melhorias depois de meses de uso real, quando as lições se acumulam, se contradizem e envelhecem junto com o código? No paper ela começa vazia a cada fluxo, e a pergunta da manutenção de longo prazo é, no fim, a mesma que já temos com qualquer AGENTS.md. Talvez a resposta seja que alguém continua precisando ler o que o agente escreveu sobre si mesmo.

Fontes:

Harness² Do Google: E Se O Agente Reescrevesse O Próprio Harness Sem Tocar Nos Pesos?

Harness² Do Google: E Se O Agente Reescrevesse O Próprio Harness Sem Tocar Nos Pesos?

O Problema Que O Paper Descreve

Propose–Probe–Compose Passo A Passo

A Biblioteca Que Aprende Entre Tarefas

Os Números E O Que Eles Sustentam

As Ressalvas, E O Que Eu Não Li

Cenário Hipotético Para Um Time Pequeno

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose