A IA do Google reescreve seu próprio harness revolucionário (Harness²)

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Google’s AI Rewrites Its Own REVOLUTIONARY Harness (Harness²) · Canal: Prompt Engineer 48 · 06:40 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Open source e ecossistemas de software, Segurança de IA

Resumo

Harness Squared é uma abordagem do Google Research para permitir que um agent melhore o próprio harness sem alterar ou retreinar o modelo. Em um ciclo interno, o sistema cria e testa versões alternativas do harness, compara evidências e compõe uma versão final; em um ciclo externo, registra aprendizados úteis em uma biblioteca para tarefas futuras. Nos testes apresentados, uma única etapa de melhoria elevou os resultados em diferentes benchmarks, mas o método tem custos e pode ser afetado por aleatoriedade e vieses compartilhados pelo modelo. O vídeo também descreve a implementação open source e possíveis próximos passos.

Pontos-chave

O desempenho de um modelo pode mudar bastante conforme o harness que o envolve, mesmo sem alterar os pesos.
Harness Squared divide o harness em oito arquivos editáveis, que abrangem instruções, memória, ferramentas e delegação.
O ciclo interno propõe duas versões, testa ambas nas mesmas condições e compõe um harness final com base nas evidências.
A recursão paralela explora várias opções ao mesmo tempo; a sequencial encadeia refinamentos e evidências.
Após cada tarefa, uma biblioteca registra aprendizados sustentados por evidências para apoiar tarefas futuras.
No exemplo apresentado, o resultado de uma tarefa subiu de 43,1 para 77,8 após a melhoria do harness.
Uma única etapa de melhoria elevou os resultados em todas as configurações e benchmarks mencionados.
O vídeo relata que um modelo mais fraco com harness aprimorado superou um modelo mais forte com seu harness original.
Mais execuções aumentam o custo, e a ausência de respostas corretas conhecidas deixa o método vulnerável à aleatoriedade e a vieses do modelo.

Capítulos

Início	Capítulo	Resumo
00:00	A ideia: melhorar o harness sem retreinar o modelo	O vídeo apresenta Harness Squared e explica por que o harness pode alterar o desempenho de um modelo.
01:33	O ciclo interno de teste e composição	O sistema edita oito arquivos, testa candidatos e compõe uma versão final com base em evidências.
03:35	Biblioteca de experiências e resultados	O ciclo externo registra aprendizados e o vídeo demonstra melhorias em tarefas e benchmarks.
05:07	Escala, limitações e como experimentar	O vídeo discute ganhos com mais exploração, ablações, custos, limitações e a demonstração local.

Citações

A única coisa que mudou foi o harness ao redor dele. — 00:00

O sistema só pergunta: “Essa edição corrigiu a falha visada, não mudou nada ou quebrou algo?” — 02:34

43,1 virou 77,8. — 04:06

Mais computação, por si só, não é a resposta; o importante é usá-la de forma mais inteligente. — 05:38

O harness aprendeu a se aprimorar e depois aprendeu a aprimorar a forma como se aprimora. — 06:40

Conceitos e entidades

Harness Squared (conceito): Abordagem do Google Research que usa ciclos de teste e revisão para melhorar um harness e o processo de melhoria.
Harness (conceito): Conjunto de instruções, ferramentas, memória, skills e regras que orienta como um modelo executa tarefas.
recursão em nível de tarefa (conceito): Ciclo que propõe, testa e combina alterações no harness para uma tarefa específica.
recursão em nível de harness (conceito): Ciclo que registra aprendizados de tarefas anteriores em uma biblioteca para reutilização futura.
Gemini 3.5 Flash (modelo): Modelo usado no estudo de caso e nas avaliações descritas no vídeo.
GLM 5 (modelo): Modelo incluído nas comparações de desempenho apresentadas.
Google Research (empresa): Grupo de pesquisa do Google ao qual o vídeo atribui o desenvolvimento do Harness Squared.
OpenCode (ferramenta): Ambiente citado como um dos harnesses iniciais usados nas configurações avaliadas.
Codex (ferramenta): Ambiente citado como um dos harnesses iniciais usados nas configurações avaliadas.
WorkBuddyBench (conceito): Benchmark profissional mencionado para avaliar tarefas de escritório, web e código.
JobBench (conceito): Benchmark mencionado para avaliar tarefas completas de trabalho.
Apache License 2.0 (conceito): Licença open source sob a qual o vídeo afirma que o projeto está disponível.

Tradução completa (pt-BR)

00:00 Imagine um agent de IA que falha em uma tarefa e, depois, sem que um humano encoste nele, reescreve o próprio manual de instruções e tenta de novo. Em uma tarefa real, a primeira tentativa marcou 43,1; a segunda, 77,8. Mesmo modelo, mesmos pesos, nada foi retreinado. A única coisa que mudou foi o harness ao redor dele. Isso é Harness Squared Recursive Agent Harnessing, do Google Research. Para entender, comece com uma equação simples. Um agent é um modelo mais um harness.

00:31 O modelo é o cérebro: congelado, treinado, pronto. O harness é tudo o que o envolve: os prompts, as ferramentas, a memória, as skills e as regras. E aqui está a verdade incômoda: o mesmo modelo pode ter desempenhos muito diferentes dependendo apenas do harness que usa. Hoje, humanos criam harnesses manualmente: ajustam um prompt, executam, leem os logs, ajustam de novo. É lento e não escala para novos tipos de trabalho. Então, os pesquisadores fazem uma pergunta ousada: um agent pode melhorar o próprio harness? Essa ideia é chamada de autoaperfeiçoamento recursivo.

01:02 Mas, no mundo aberto, há um porém. Surgem novas tarefas sem gabarito, sem teste unitário, sem verificador que diga se você acertou. Como melhorar algo quando não é possível medir o sucesso? Esse é o primeiro problema que Harness Squared resolve. O segundo problema é a memória. Corrigir um harness para uma tarefa geralmente não ensina nada ao sistema sobre a próxima. A resposta do artigo são dois loops, um dentro do outro: recursão no nível da tarefa e recursão no nível do harness. Antes dos loops, vamos conhecer o elemento que será editado.

01:33 Harness Squared divide um harness em oito arquivos que o modelo pode ler: um system prompt, proteções, memória e skills. Esses quatro moldam o que entra no context. Orientações sobre ferramentas e scripts definem como o modelo interage com o mundo. Subagents cuidam da delegação, e um plugin intercepta cada chamada de ferramenta fora do controle do modelo. Oito arquivos de texto simples. Tudo o que o sistema aprende precisa ser registrado em um deles. Agora, o loop interno, a recursão no nível da tarefa, funciona em três etapas: propor, testar, compor.

02:03 Primeiro, o agent simplesmente executa a tarefa uma vez com o harness original. Essa é a execução de referência. Ela mostra como o harness se comporta, não se a resposta está certa. Propor: um editor lê essa execução e elabora dois novos harnesses: um geral, voltado a falhas como planejamento e uso de ferramentas, e outro específico do domínio, voltado ao conhecimento daquela área exata. Testar: os dois candidatos executam a mesma tarefa em condições idênticas. Agora, há três execuções para comparar lado a lado. Essa comparação é o truque. Ninguém precisa saber a resposta certa. O sistema

02:34 só pergunta: “Essa edição corrigiu a falha visada, não mudou nada ou quebrou alguma coisa?” Compor: um editor final lê todas as execuções e todos os diffs. Ele pode combinar edições, resolver conflitos, adotar um dos candidatos ou manter o original. Cada decisão precisa apontar para evidências. O harness composto executa a tarefa pela última vez. Essa execução é o resultado que você realmente recebe. Quer mais? Você usa um orçamento maior, chamado K, e há duas maneiras de gastá-lo. A recursão paralela testa K candidatos gerais e K candidatos específicos do domínio

03:04 ao mesmo tempo e, depois, produz K composições com base nas evidências compartilhadas. Ela explora mais possibilidades. A recursão sequencial encadeia as etapas, levando cada harness refinado e todas as evidências para a próxima etapa. Ela refina mais profundamente. Quando K é maior que um, um avaliador anônimo compara os resultados finais sem saber qual harness produziu cada um e escolhe o melhor. Agora, o loop externo: após cada tarefa, um refletor analisa todo o registro de melhorias — o que falhou, o que foi tentado e o que os testes revelaram. O harness vencedor é arquivado em uma biblioteca, junto com uma nota de experiência:

03:35 a situação, a lição e as evidências que a sustentam. Se as evidências forem fracas, nada é registrado. Na tarefa seguinte, o agent começa de novo com o harness-base simples, mas agora o aprimorador tem uma biblioteca de ideias testadas para consultar — tomar emprestadas, não herdar. Vamos ver um estudo de caso: uma tarefa do benchmark Jobbench, com Gemini 3.5 flash rodando em open code. A pontuação de base foi 43,1. A trajetória mostrou falhas de processo, não falta de conhecimento. O agent nunca conciliou os números entre os arquivos de origem e nunca reabriu os próprios resultados para

04:06 verificá-los. A edição geral adicionou uma proteção: inventariar cada entrada, rastrear cada número até sua fonte e, em seguida, executar um script para reabrir e verificar cada arquivo produzido. A edição específica do domínio adicionou uma skill de conciliação para arquivos de cronograma, local, mão de obra e orçamento, além de orientações sobre ferramentas para formatos numéricos complicados. O compositor manteve as quatro edições. Na nova execução, os números foram conferidos, e as seções ausentes foram restauradas. A pontuação passou de 43,1 para 77,8. Agora, o placar: três benchmarks profissionais — WorkBuddyBench, para tarefas de escritório, web e programação; Jobbench, para tarefas de ponta a ponta; e o benchmark jurídico de Harvey, LAB. Dois modelos congelados, Gemini 3.5 flash e GLM 5; dois harnesses iniciais, open code e Codex: quatro configurações ao todo. Uma única etapa de melhoria elevou todas as configurações em todos os benchmarks. O maior salto foi no WorkBuddyBench com GLM 5: 11,5 pontos a mais. No Jobbench, os ganhos chegam a 4,5 pontos. Em tarefas jurídicas, chegam a 11,8 pontos na taxa de aprovação parcial. Note uma coisa: um modelo mais fraco com um harness melhor

04:37 superou um modelo mais forte com o harness original. O GLM 5, após a melhoria, marcou 75,7. A pontuação de base do Gemini, sem alterações, foi 72,4. As pontuações de base também contam uma história. O Reasoning Bank ficou até 6,6 pontos abaixo da base em programação. A escalabilidade do harness ficou abaixo da base em sete dos 12 casos. Aumente o orçamento e os ganhos continuam. Em programação, o Gemini sobe de 76,5 para 80,8 em tarefas de escritório, e de 79,5 para 83,4.

05:07 Até K igual a 2 supera todas as pontuações de base com K igual a 5 em programação e tarefas de escritório. Mais computação, por si só, não é a resposta; é preciso usá-la de forma mais inteligente. Remova qualquer componente, e o desempenho cai. Sem biblioteca: menos 3,1; sem editores de escopo: menos 2,9; sem composição: menos 1,6. E a biblioteca realmente transfere a experiência: os resultados melhorados no Jobbench também melhoraram no WorkBuddyBench, sem testes adicionais. É necessário um editor mais forte? Não. Usando o mesmo modelo como executor e editor, todos os cinco modelos testados melhoraram em todos os benchmarks.

05:38 Agora, os limites reais: mais execuções significam mais custos e, sem uma resposta correta conhecida, os sinais podem ser enganados pela aleatoriedade e por vieses compartilhados do modelo. Os próximos passos são uma biblioteca que se depura sozinha e um sistema que decide quanto explorar com base na dificuldade da tarefa. Quer experimentar? É open source sob a licença Apache 2.0. Instale com UV e execute a demonstração local, que não precisa de credenciais de modelo. Depois, configure um benchmark e comece executando uma única tarefa. As execuções do modelo custam dinheiro, então comece em pequena escala. Harness Squared: o modelo nunca mudou. O harness aprendeu

06:09 a melhorar a si mesmo e, depois, aprendeu a melhorar a maneira como melhora.

06:40 para melhorar a si mesmo e então aprendeu a melhorar a forma como melhora.

Transcrição original

[00:00] Imagine an AI agent that fails a job, then without a human touching it, rewrites its own instruction manual and tries again. On one real task, the first attempt scored 43.1, the second attempt scored 77.8. Same model, same weights, nothing retrained. The only thing that changed was the harness around it. This is Harness Squared Recursive Agent Harnessing from Google Research. To understand it, start with a simple equation. An agent is a model plus a harness.

[00:31] The model is the brain, frozen, trained, finished. The harness is everything wrapped around it, the prompts, the tools, the memory, the skills, and the rules. And here’s the uncomfortable truth. The same model can perform wildly differently depending only on the harness it wears. Today, humans build harnesses by hand, tweak a prompt, run it, read the logs, tweak again. It’s slow and it doesn’t scale to new kinds of work. So, researchers ask a bold question, can an agent improve its own harness? That idea is called recursive

[01:02] self-improvement. But in the open world, there’s a catch. New tasks arrive with no answer key, no unit test, no verifier to say whether you got it right. How do you improve something when you can’t measure success? That is the first problem Harness Squared solves. The second problem is memory. Fixing a harness for one task usually teaches the system nothing about the next one. The paper’s answer is two loops, one inside the other, task-level recursion and harnessing-level recursion. Before the loops, meet the thing being edited.

[01:33] Harness Squared splits a harness into eight files that the model can read. A system prompt, guardrails, memory, and skills. These four shape what enters the context. Tool guidance and scripts define how the model touches the world. Sub-agents handle delegation and a plugin hooks every tool call outside the model’s control. Eight plain files. Anything the system learns has to be written into one of them. Now, the inner loop task level recursion works in three moves: propose, probe, compose.

[02:03] First, the agent simply does the task once with the original harness. That’s the reference run. It shows how the harness behaves, not whether the answer is right. Propose, an editor reads that run and drafts two new harnesses, one invariant aimed at general failures like planning and tool use, one domain specific aimed at the knowledge of this exact field. Probe, both candidates then run the same task under identical conditions. Now, there are three runs to compare side by side. That comparison is the trick. Nobody needs to know the right answer. The

[02:34] system only asks, “Did this edit fix the targeted flaw, change nothing, or break something?” Compose, a final editor reads every run and every diff. It can merge edits, resolve conflicts, adopt one candidate, or keep the original. Each decision must point to evidence. The composed harness runs the task one last time. That run is the deliverable you actually get. Want more? You spend a bigger budget called K, and there are two ways to spend it. Parallel recursion probes K general and K domain candidates

[03:04] at once, then writes K compositions from the shared evidence. It explores wider. Sequential recursion chains the steps, carrying each refined harness and all its evidence into the next one. It refines deeper. When K is above one, an anonymous lector compares the finished outputs without knowing which harness made which and picks the best. Now, the outer loop, after every task, a reflector reviews the whole improvement record, what failed, what was tried, what the probes revealed. The winning harness is filed in a library beside an experience note,

[03:35] the situation, the lesson, and the evidence behind it. If the evidence is thin, nothing is written. Next task, the agent starts again from the plain base harness, but the improver now has a library of tried ideas to borrow from, borrow, not inherit. Let’s see a case study, a job bench task, Gemini 3.5 flash running in open code, the baseline scored 43.1. The trajectory showed process failures, not missing knowledge. The agent never reconciled numbers across source files, and it never reopened its own outputs to

[04:06] check them. The invariant edit added a guardrail, inventory every input, trace each figure to its source, then run a script to reopen and verify every file you produce. The domain edit added a reconciliation skill for schedule, venue, labor, and budget files, plus tool guidance for tricky number formats. The composer kept all four edits. The rerun cross-checked the figures and restored the missing sections. 43.1 became 77.8. Now the scoreboard, three professional benchmarks, work buddy bench for office,

[04:37] web, and code work, jobbench for end-to-end jobs, and LAB Harvey’s legal benchmark. Two frozen models, Gemini 3.5 flash and GLM 5, two starting harnesses, open code and codex four setups in all. One single improvement step lifted every setup on every benchmark. The biggest jump, GLM 5 on work buddy, up 11.5 points. On jobbench, gains reach 4.5 points. On legal work, up to 11.8 points of partial pass rate. Notice something, a weaker model with a better harness

[05:07] beat a stronger model with its original one. GLM 5 once improved scored 75.7. Gemini’s untouched baseline was 72.4. The baselines tell a story, too. Reasoning bank fell as much as 6.6 points below base on coding. Harness scaling lost to the base in seven of 12 cases. Turn up the budget and the gains keep coming on. Code, Gemini climbs from 76.5 to 80.8 on office work, from 79.5 to 83.4.

[05:38] Even k equals 2 beats every baseline at k equals 5 on code and office. More compute alone isn’t the answer, smarter use of it is. Remove any piece and it hurts. No library minus 3.1 no scope editors minus 2.9 no composition minus 1.6. And the library really does transfer experience from job bench improved results on work buddy with no extra probing. Does it need a stronger editor? No. Using the same model as both worker and editor, all five models tested improved on every benchmark.

[06:09] Now the honest limits more runs mean more cost and with no ground truth the signals can be fooled by randomness and shared model bias. Next steps are a library that prunes itself and a system that decides how much to explore based on how hard the task is. Want to try it? It’s open source under Apache 2.0 install with UV and run the local demo which needs no model credentials. Then set up a benchmark and run a single task to start. Model runs cost money so keep it small. Harness squared, the model never changed. The harness learned

[06:40] to improve itself and then learned to improve how it improves.