Google Harness2 abre o código da autoaperfeiçoamento de agentes, mas a verificação continua sendo o teste

O Google abriu o código do Google Harness2 após relatar ganhos de até 11,5 pontos ao mudar o software que envolve um agente, em vez de seu modelo. Essa distinção cria a tensão central. O framework permite que um agente revise prompts, ferramentas, memória e outras instruções operacionais, mas ele precisa avaliar essas revisões sem respostas sabidamente corretas.

Chamado de Harness² por seus autores, o projeto vem de pesquisadores afiliados ao Google Cloud AI Research e à Northwestern University. Seu código surgiu junto a um artigo de pesquisa de 9 de outubro de 2026 e utiliza a licença Apache 2.0. O lançamento transforma um método de pesquisa em software que desenvolvedores podem inspecionar, executar e modificar.

O projeto também desafia uma suposição conhecida sobre agentes de IA. Melhores resultados nem sempre exigem um modelo mais novo ou maior. Eles podem surgir ao mudar o harness, isto é, o software e as instruções que transformam um modelo de linguagem em um sistema capaz de agir.

Esse argumento pressiona frameworks de agentes fixos. OpenCode, Codex, Claude Code e sistemas semelhantes combinam modelos com prompts, ferramentas, memória e orquestração. O Google Harness2 questiona se esses componentes ao redor devem continuar fixos após a implantação.

A resposta importa para além dos rankings de benchmarks. Um harness autoeditável pode se adaptar a trabalhos jurídicos, administrativos, web e de programação desconhecidos. Também pode preservar uma premissa ruim, selecionar uma revisão mais fraca ou consumir substancialmente mais computação para chegar a uma resposta.

Google Harness2 muda o software em torno de um modelo congelado

O lançamento transfere o aprimoramento recursivo do treinamento do modelo para oito partes editáveis do ambiente de execução do agente.

Um agente de IA é mais do que o modelo de linguagem que responde aos seus prompts. Ele também depende de instruções, ferramentas disponíveis, contexto armazenado, regras de delegação e software que controla cada ação. Em conjunto, esses componentes formam o harness do agente.

O Google Harness2 expõe oito componentes para revisão: o prompt de sistema, proteções, memória, orientações de ferramentas, subagentes, habilidades, scripts e plugins de middleware. Cada componente é representado como um arquivo montado no ambiente de execução. Os pesos do modelo subjacente permanecem congelados.

Essa separação é importante. Treinar ou ajustar finamente um modelo exige infraestrutura especializada, dados preparados e um processo de implantação separado. Editar um prompt, uma habilidade ou uma instrução de ferramenta pode ocorrer enquanto o agente trabalha em uma tarefa.

O repositório open-source empacota o método como um projeto Python para Linux. Ele suporta Python 3.12, refinamento paralelo e sequencial, além de integrações com executores OpenCode e Codex. Sua demonstração incluída usa editores determinísticos e execução local de Python, para que desenvolvedores possam inspecionar o fluxo de trabalho sem credenciais de modelo.

Avaliações baseadas em modelos exigem mais infraestrutura. O repositório especifica Node.js, autenticação do Google Cloud, acesso a modelos pelo Vertex AI e dependências específicas de cada benchmark. O WorkBuddy-Bench requer Docker, enquanto o benchmark jurídico requer utilitários de processamento de documentos.

Essa configuração sinaliza o público atual do projeto. Trata-se de software de pesquisa para equipes preparadas para executar avaliações controladas, e não de um recurso para consumidores que atualiza silenciosamente todos os agentes. O lançamento fornece o maquinário para experimentação, mas os adotantes ainda precisam de tarefas, ambientes de execução, avaliadores e limites operacionais.

O framework inicia cada tarefa recebida a partir de um harness-base comum. Ele não simplesmente transfere a configuração específica da tarefa mais recente para a próxima atribuição. Em vez disso, refina temporariamente o harness atual e registra lições reutilizáveis em uma biblioteca de aprimoramento separada.

Essa decisão aborda uma falha comum em sistemas adaptativos. Uma instrução que ajuda na análise de contratos pode prejudicar uma tarefa de planilha. Acumular diretamente cada edição bem-sucedida tornaria o harness cada vez mais especializado e difícil de compreender.

O Harness², em vez disso, tenta reter evidências sobre por que uma edição ajudou. Uma tarefa futura pode recorrer a essa experiência sem herdar toda a configuração de execução anterior.

Assim, o projeto representa duas formas de software. Um harness realiza o trabalho, enquanto outro aprimora o sistema que realiza esse trabalho. Essa segunda camada explica por que os autores descrevem o método como harnessing recursivo de agentes, e não como otimização comum de prompts.

Para desenvolvedores que já mantêm instruções de agentes manualmente, o lançamento formaliza um fluxo de trabalho reconhecível. As equipes inspecionam falhas, revisam instruções, executam tarefas novamente e preservam técnicas úteis. O Google Harness2 atribui grande parte desse ciclo aos agentes e registra as mudanças resultantes como artefatos estruturados.

Como o Google Harness2 refina um agente sem respostas corretas

Seu mecanismo central compara o comportamento sob condições equivalentes, em vez de pedir a um verificador perfeito que identifique a saída certa.

O framework chama seu principal processo no nível da tarefa de Propose-Probe-Compose. Um proponente primeiro estuda a execução original e sugere edições direcionadas no harness. Uma sonda executa novamente a mesma tarefa com esses candidatos. Em seguida, um compositor combina mudanças sustentadas por diferenças entre as trajetórias resultantes.

Uma trajetória é a sequência registrada de respostas do modelo, chamadas de ferramentas, observações e arquivos gerados. Ela oferece ao sistema mais evidências do que apenas uma resposta final. O editor pode ver se uma revisão encontrou entradas ausentes, invocou uma ferramenta adequada ou verificou um documento antes do envio.

O sistema divide as propostas em dois escopos. Um editor invariante concentra-se no comportamento geral de execução, como verificar saídas após gravá-las. Um editor de domínio concentra-se em conhecimento, formatos ou procedimentos específicos da tarefa.

Essa separação reduz a chance de que todo problema receba a mesma correção genérica. Ela também permite que o compositor combine uma regra de processo amplamente útil com orientações especializadas quando ambas produzem mudanças comportamentais úteis.

Crucialmente, o processo online não recebe o gabarito de respostas do benchmark. O artigo de pesquisa descreve um cenário de mundo aberto em que as tarefas chegam após a concepção do harness. Pode não haver um verificador confiável de verdade fundamental disponível durante a execução.

Em vez de declarar um candidato como correto, o sistema busca contrastes. Suponha que o agente-base ignore vários arquivos-fonte. Uma revisão inventaria todas as entradas, enquanto outra adicionaria orientações de reconciliação de planilhas. Suas trajetórias revelam se essas intervenções alteraram o processo do agente.

O compositor usa essas evidências para construir outro harness e executar a tarefa novamente. A abordagem não elimina o julgamento. Ela transfere o julgamento da comparação de uma saída com uma resposta conhecida para a comparação de comportamento observável entre execuções.

Os desenvolvedores podem gastar computação adicional em tempo de teste de duas formas. A recursão paralela explora várias revisões candidatas ao mesmo tempo e depois compõe evidências dessas tentativas. A recursão sequencial aplica outro refinamento após cada revisão anterior.

A variável k controla esse orçamento de exploração. Um valor maior oferece ao sistema mais oportunidades de encontrar e testar edições, mas cada oportunidade adiciona chamadas de modelo, uso de ferramentas e tempo de execução.

Depois que a tarefa termina, um segundo nível de recursão atualiza o harness de aprimoramento contínuo. Um refletor armazena o harness adotado e um arquivo de experiência que descreve a intervenção, as evidências e o resultado. Propostas posteriores podem consultar essa biblioteca.

Esse design torna a experiência mais portátil do que um prompt concluído. Uma lição armazenada pode indicar que tarefas de geração de documentos se beneficiam da reabertura dos arquivos finais e da verificação das seções exigidas. Esse processo pode se aplicar entre domínios, mesmo quando os documentos exatos diferem.

A distinção também conecta o framework ao trabalho cotidiano de conhecimento. Um agente pode precisar combinar notas de reuniões, planilhas, políticas e documentos de projeto antes de produzir um memorando de decisão. A parte difícil costuma ser rastrear alegações entre fontes, e não gerar prosa fluente.

As equipes já podem reduzir essa carga ao criar uma base de conhecimento pesquisável. O Harness² estende a ideia à política de execução: o agente pode revisar como coleta, verifica e usa esse material em uma tarefa específica.

O mecanismo continua experimental, no entanto. O contraste comportamental é evidência, não verdade. Dois candidatos podem compartilhar a mesma premissa equivocada, e uma trajetória bem elaborada ainda pode levar a uma entrega ruim.

Os ganhos de benchmark pressionam harnesses de agentes fixos

Os resultados relatados sugerem que o design do harness pode alterar o desempenho tanto quanto a troca de modelos, especialmente em sistemas iniciais mais fracos.

Os pesquisadores avaliaram o Harness² em três benchmarks profissionais. O WorkBuddy-Bench abrange tarefas de programação, web e escritório. O JobBench testa trabalho profissional, enquanto o Harvey’s Legal Agent Benchmark mede o desempenho em tarefas jurídicas.

Os testes cobriram quatro combinações de dois modelos e dois harnesses iniciais. Os modelos foram Gemini 3.5 Flash e GLM-5. Os harnesses iniciais de execução foram OpenCode e Codex, enquanto Claude Opus 4.8 atuou como editor padrão nos principais experimentos.

Uma única etapa de refinamento melhorou todas as combinações testadas de modelo e harness nos três benchmarks, segundo os autores. Os maiores ganhos relatados chegaram a 11,5 pontos no WorkBuddy-Bench, 4,5 pontos no JobBench e 11,8 pontos percentuais na taxa de aprovação parcial do benchmark jurídico.

A maior mudança no WorkBuddy-Bench apareceu com GLM-5 no OpenCode. Sua pontuação média subiu de 64,2 para 75,7 após uma etapa. O Gemini 3.5 Flash no OpenCode subiu de 72,4 para 77,5.

Esses números sustentam uma inferência prática. O harness pode reduzir parte da diferença entre modelos ao corrigir comportamentos de execução que a capacidade bruta do modelo não resolve.

Os resultados variaram conforme a configuração. O GLM-5 no Codex ganhou apenas 1,2 ponto no JobBench, passando de 23,6 para 24,8. O Gemini no OpenCode melhorou 4,5 pontos no mesmo benchmark.

Essa variação importa mais do que o maior número de destaque. O método não produziu uma melhoria uniforme em todos os modelos, harnesses e tarefas. Seu valor dependeu do sistema inicial e do domínio.

Os pesquisadores também aumentaram o orçamento de recursão. Com o Gemini no OpenCode, passar de uma etapa de refinamento para recursão paralela com k=5 elevou ainda mais o desempenho no WorkBuddy-Bench. Programação chegou a 80,8, web chegou a 81,7 e escritório chegou a 83,4.

O artigo relata que tanto as pontuações paralelas quanto as sequenciais aumentaram à medida que o orçamento subiu de um para cinco em domínios selecionados do WorkBuddy-Bench. Métodos concorrentes mostraram mudanças menores ou menos consistentes nesses testes.

Mais exploração não foi toda a explicação. Em um estudo de ablação, remover a biblioteca de aprimoramento reduziu o desempenho médio no WorkBuddy-Bench em 3,1 pontos. Remover funções de editor com escopo definido custou 2,9 pontos, enquanto pular a composição custou 1,6 ponto.

O JobBench mostrou um padrão semelhante. Remover a biblioteca reduziu sua pontuação em 1,8 ponto, editores genéricos perderam 3,7 pontos e omitir a composição perdeu 1,9 ponto. Esses resultados indicam que experiência retida, propostas especializadas e combinação baseada em evidências contribuíram individualmente.

Um estudo de caso do JobBench ilustra o mecanismo. O agente base não conseguiu reconciliar informações entre arquivos-fonte e não reabriu sua saída final para verificação. Sua pontuação foi 43,1.

Uma intervenção proposta exigia um inventário de todas as entradas e rastreabilidade explícita das fontes. Outra acrescentava orientação de domínio para a reconciliação de cronograma, local, mão de obra e orçamento. O compositor reteve todas as quatro edições introduzidas por essas intervenções, e a nova execução alcançou 77,8.

Esse exemplo reforça o argumento a favor da melhoria do harness de agentes porque a falha era processual. Ao modelo não faltavam capacidade linguística básica nem acesso aos arquivos. Faltava-lhe um método operacional confiável.

Mesmo com harnesses fixos, o desempenho variou entre os domínios. A comparação do artigo constatou que o Claude Code liderou entre os sistemas fixos em tarefas de código e escritório, enquanto o Codex liderou em tarefas web. Nenhum harness inalterado liderou em todos os cenários.

Partindo do OpenCode com um orçamento de recursão maior, o Harness² superou a alternativa fixa mais forte em 4,6 pontos em código, 5,8 em web e 4,9 em escritório. Os autores observam explicitamente que esse resultado adaptativo utilizou computação adicional durante o teste.

Portanto, a pressão competitiva se dirige à abordagem de harness fixo, não a um produto específico. Um fornecedor pode melhorar seu modelo, mas os usuários ainda podem receber resultados inconsistentes se as instruções e ferramentas ao redor não conseguirem se adaptar.

Harnesses de Agentes Autoaperfeiçoáveis Ainda Precisam de Verificações Independentes

O Harness² pode melhorar o processo de um agente, mas suas próprias evidências mostram que edições recursivas às vezes selecionam um comportamento pior ou propagam uma premissa equivocada.

Os resultados de benchmark vêm dos autores do projeto e ainda não estabeleceram confiabilidade em produção em implantações independentes. O artigo relata médias de três execuções, o que ajuda a medir a variabilidade, mas não substitui a replicação externa.

O método também consome computação adicional antes de entregar sua saída final. Cada proposta, sondagem, composição e nova execução consome tokens e tempo de execução. O processamento paralelo pode reduzir o tempo decorrido quando há capacidade disponível, mas não elimina o custo subjacente de recursos.

O artigo posiciona as configurações avaliadas em uma fronteira empírica de desempenho computacional para JobBench e WorkBuddy-Bench. Esse resultado significa que os ganhos medidos se compararam favoravelmente às alternativas testadas. Não significa que a recursão será econômica para toda carga de trabalho em produção.

Uma tarefa de baixo valor pode não justificar várias execuções do modelo. Um parecer jurídico ou uma decisão operacional pode justificar mais verificações, mas esses domínios também exigem controles mais rigorosos do que os oferecidos por um executor de benchmarks.

O alerta mais importante vem da própria análise de falhas dos autores. Eles examinaram nove regressões e as agruparam em falhas de seleção de candidatos, premissas incorretas compartilhadas e incerteza de avaliação ou execução.

Em um exemplo de programação, o framework selecionou uma saída com pontuação 55 em vez de uma alternativa com pontuação 95. Em uma tarefa jurídica, uma revisão mais restrita reduziu a cobertura e derrubou a pontuação de 54 para 26.

Outras falhas começaram com uma suposição incorreta compartilhada entre os candidatos. Esses erros produziram perdas entre 2 e 11 pontos. Se todas as edições propostas aceitam a mesma premissa falsa, comparar seus comportamentos não revela o erro original.

O artigo também identifica decisões ausentes do avaliador e a variabilidade comum entre execuções como problemas de atribuição. Uma mudança de pontuação pode refletir a edição, a execução estocástica ou ruído de avaliação. Mais sondagens ajudam, mas aumentam o custo.

A atividade do repositório também revelou riscos de implementação. Uma questão aberta sobre identidade de cache informa que experimentos retomados podem reutilizar saídas anteriores depois que as instruções da tarefa ou os arquivos-fonte mudam, enquanto os identificadores de tarefa permanecem constantes.

O autor da questão reproduziu o comportamento sem chamadas ao modelo e observou que o conteúdo de entrada está ausente de partes da identidade salva da execução. O relatório não quantifica qualquer efeito sobre as pontuações de benchmark publicadas, e nenhuma resolução de mantenedor estava anexada quando ele foi analisado.

Ainda assim, a questão ilustra o desafio operacional mais amplo. Um sistema recursivo precisa de linhagem confiável para tarefas, material-fonte, revisões de harness, saídas em cache e configurações de avaliação. Caso contrário, uma melhoria aparente pode refletir evidências desatualizadas.

A segurança cria outra preocupação. Os oito componentes editáveis incluem guardrails, scripts, plugins e instruções de ferramentas. Esses arquivos podem influenciar o que um agente acessa e quais ações ele executa.

Um editor autônomo não deveria receber autoridade irrestrita para enfraquecer controles de acesso, executar scripts não revisados ou persistir detalhes sensíveis de tarefas. O uso em produção exige permissões por componente, limites de segurança imutáveis, registros de auditoria e reversão.

A experiência persistente merece cautela semelhante. Uma lição útil de um cliente, departamento ou questão jurídica pode expor informações confidenciais quando recuperada para outro. Portanto, uma biblioteca de melhorias precisa de políticas de separação e retenção de dados, e não apenas de relevância semântica.

As equipes também devem distinguir a otimização de desempenho da validação de segurança. Uma pontuação de benchmark recompensa a conclusão de tarefas sob seu avaliador. Ela não mede automaticamente privacidade, autorização, precisão factual ou resistência a entradas maliciosas.

O próprio Google Harness2 demonstra por que essa distinção importa. Seu compositor pode preferir um candidato comportamentalmente convincente que é objetivamente mais fraco. A ausência de verdade fundamental é o problema que o framework aborda, mas continua sendo um limite que ele não pode eliminar.

Um projeto de produção sensato permitiria que o sistema modificasse orientações de menor risco enquanto protege políticas centrais. A redação de prompts e listas de verificação de fluxo de trabalho poderiam ser editáveis. Regras de credenciais, limites de rede, etapas de aprovação e limites para ações destrutivas deveriam permanecer fora da autoridade do agente.

A revisão humana também continua valiosa para mudanças propostas que persistem entre tarefas. O framework pode produzir evidências que explicam por que uma edição foi adotada. Os operadores podem usar esse registro para aprovar, rejeitar ou restringir a mudança antes que ela entre em uma biblioteca compartilhada.

O Harnessing Recursivo de Agentes Muda o Roteiro da Engenharia de Agentes

O próximo teste é saber se as organizações conseguem reproduzir os ganhos enquanto controlam computação, regressões e memória persistente.

O primeiro sinal a observar é a replicação independente de benchmarks. O repositório expõe código, configurações, prompts e comandos de avaliação, oferecendo às equipes externas um ponto de partida prático. As reproduções devem relatar tanto as pontuações finais quanto o uso total do modelo.

Uma replicação bem-sucedida entre diferentes fornecedores fortaleceria a alegação central. Ela mostraria que o harnessing adaptativo não está fortemente acoplado aos modelos, ao editor ou ao ambiente do Google Cloud testados.

A incapacidade de reproduzir os ganhos enfraqueceria o argumento de generalidade. Os pesquisadores precisariam identificar se a diferença decorreu do comportamento do modelo, das versões do benchmark, dos ambientes de execução ou das configurações de avaliação.

O segundo sinal é o desempenho em fluxos de tarefas reais, e não em execuções isoladas de benchmark. A recursão no nível do harness promete valor cumulativo porque lições de tarefas anteriores orientam propostas posteriores.

O artigo oferece evidência inicial dessa transferência. Uma biblioteca de experiência construída sobre o JobBench melhorou o refinamento em uma etapa no WorkBuddy-Bench em 0,6 ponto para código, 0,5 para web e 2,9 para escritório.

Esses ganhos são menores do que os resultados mais fortes no nível da tarefa, e uma análise usou retrospectivamente a experiência de tarefas posteriores. Uma implantação ao vivo deveria mostrar que lições úteis se acumulam em ordem cronológica, sem importar informações futuras.

Os operadores devem medir as taxas de regressão junto com o desempenho médio. Também devem acompanhar a frequência de intervenções, a latência, o consumo do modelo e a porcentagem de edições persistentes que sobrevivem à revisão humana.

O terceiro sinal é uma camada mais forte de verificação e governança. Os autores recomendam sondagens que desafiem premissas compartilhadas, execução repetida para separar edições de variabilidade e métodos de seleção melhores que equilibrem cobertura e precisão.

Correções no repositório podem oferecer outro indicador. Identidades de cache sensíveis ao conteúdo, revisões de benchmark fixadas e invalidação confiável tornariam os experimentos mais fáceis de reproduzir. Limites de segurança claros para componentes editáveis tornariam a implantação mais segura.

O campo de pesquisa mais amplo também testará formas alternativas de adaptação de harnesses. Meta-Harness busca configurações antes da implantação. ReasoningBank recupera experiência de raciocínio útil enquanto mantém o harness fixo. Harness Scaling revisa um harness para tarefas individuais.

O Harness² combina adaptação online de tarefas com um mecanismo persistente de melhoria. Essa combinação é sua principal distinção, mas também concentra riscos. Uma revisão ruim no nível da tarefa afeta um resultado, enquanto uma lição ruim retida pode influenciar tarefas posteriores.

Para desenvolvedores, a mensagem prática não é que todo agente deva se reescrever imediatamente. É que prompts, memória, ferramentas e orquestração merecem avaliação como um sistema conectado.

As equipes podem começar com experimentos delimitados. Podem selecionar tarefas representativas, preservar um harness base imutável, permitir revisões apenas em um sandbox e comparar a qualidade da saída com o custo computacional total. Toda mudança persistente deve permanecer atribuível e reversível.

Profissionais do conhecimento devem se importar porque a qualidade do harness molda o comportamento visível do agente. Um modelo pode parecer pouco confiável quando suas instruções de ferramentas são fracas, sua memória é ruidosa ou seu fluxo de trabalho omite verificações. Por outro lado, um procedimento melhor pode aprimorar resultados sem alterar o modelo.

A publicação aberta torna essas hipóteses testáveis. Ela oferece aos pesquisadores uma implementação comum para estudar como agentes diagnosticam falhas, revisam instruções operacionais e retêm experiência.

Em última análise, o Google Harness2 desloca o debate sobre autoaperfeiçoamento da inteligência abstrata de modelos para artefatos de software inspecionáveis. Essa é uma mudança útil porque as equipes podem revisar arquivos, rastrear revisões e medir execuções.

Ele não resolve a questão mais difícil: quem verifica o aperfeiçoador quando não existe uma chave de respostas? O framework substitui a edição cega por evidências comportamentais estruturadas, mas as evidências ainda podem induzir ao erro.

Nos próximos meses, observe replicações independentes, resultados ao vivo entre tarefas e controles mais rigorosos em torno de componentes editáveis. Esses sinais determinarão se o harnessing recursivo de agentes se tornará uma camada de engenharia confiável ou continuará sendo um fluxo de pesquisa promissor.

Para equipes que avaliam agentes de IA agora, a ação imediata é direta. Testem o modelo e seu harness separadamente, registrem cada mudança e exijam evidências claras antes de reter uma revisão automatizada. O Google Harness2 oferece um framework concreto para esse experimento, enquanto suas falhas relatadas mostram por que a supervisão continua importante.