Harness² explicado: agentes que se aprimoram sem treinamento

Autoria: Prompt Engineering · 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: Harness² Explained: Self-Improving Agents Without Training · Canal: Prompt Engineering · 11:25 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Engenharia de prompts e contexto

Resumo

O vídeo apresenta o Harness², um projeto de Google Research e Northwestern University que permite a agentes modificar instruções, criar ferramentas e alterar o próprio control loop enquanto executam tarefas. Em vez de acumular regras no system prompt, o sistema usa skills sob demanda, scripts, subagents e alterações no control loop, testando as mudanças antes de incorporá-las. O método também registra ferramentas e lições reutilizáveis para tarefas futuras, sem carregar indiscriminadamente as adaptações de uma tarefa para outra. Os resultados mostram ganhos de desempenho, mas o processo exige bastante compute e pode falhar quando o agente verifica o próprio trabalho com critérios incorretos.

Pontos-chave

Um harness específico para a tarefa pode superar um harness genérico, e nenhum harness testado venceu em todos os domínios.
Adicionar regras permanentemente ao system prompt pode consumir tokens e atenção; o Harness² prefere camadas menores, ativadas quando necessário.
O agente pode criar skills, scripts e subagents e editar o próprio control loop para impor regras.
No ciclo propose, probe e compose, as alterações são testadas na mesma tarefa e só as que corrigem falhas concretas são mantidas.
O sistema separa a adaptação à tarefa atual do aprendizado reutilizável, guardando ferramentas e skills úteis numa biblioteca de experiências.
Um modelo menor com um harness evoluído pode superar um modelo mais forte com o harness padrão, e também pode se beneficiar de um harness criado para outro modelo.
Testar candidatos pode exigir de 4 a 20 execuções completas do agent por tarefa, tornando o método custoso para uso imediato em prompts simples.
Um verificador criado pelo próprio agent pode reproduzir suas suposições incorretas; verificadores independentes são uma proteção importante.
Agentes com acesso à internet podem buscar recursos que revelem respostas ou critérios de avaliação, por isso precisam de guardrails adequados.

Capítulos

Início	Capítulo	Resumo
00:00	O problema dos harnesses genéricos	O vídeo apresenta as limitações de harnesses pré-construídos e introduz o Harness² e a ideia de um agent que evolui o próprio harness.
03:41	Alterações verificadas e aprendizado entre tarefas	O agent pode impor regras no control loop, testar mudanças com o ciclo propose, probe e compose e guardar adaptações reutilizáveis para tarefas futuras.
06:46	Resultados e custos do método	O Harness² separa ajustes específicos de cada tarefa de aprendizados reutilizáveis, apresenta ganhos de desempenho e destaca o custo elevado das execuções de teste.
09:23	Riscos, guardrails e principais lições	O vídeo alerta para verificadores que reproduzem erros do agent e para o acesso a rubricas de avaliação, concluindo com recomendações para projetar harnesses.

Citações

E se, no momento em que você entrega uma tarefa a um agent, ele pudesse construir e evoluir o próprio harness na hora? — 00:32

Quando você dá a um agent uma tarefa nova, não existe gabarito. — 04:43

Só as alterações comprovadamente úteis são incorporadas ao harness final. — 06:16

Como você projeta o harness agora importa tanto quanto o modelo que escolhe. — 10:54

Conceitos e entidades

Harness² (repo): Projeto de pesquisa que permite a agentes evoluir o próprio harness por meio de alterações testadas e de uma biblioteca de experiências reutilizáveis.
Harness (conceito): Estrutura que orienta o funcionamento de um agent, incluindo instruções, ferramentas e mecanismos de controle.
control loop (conceito): Ciclo de controle que determina como o agent executa etapas, usa ferramentas e decide quando concluir uma tarefa.
skill (conceito): Playbook especializado que pode ser carregado sob demanda quando uma tarefa exige um workflow específico.
subagent (conceito): Agent separado, com memória própria, que pode lidar com parte de uma tarefa sem sobrecarregar o contexto do agent principal.
Claude Code (ferramenta): Harness citado como eficaz em tarefas de programação e planilhas nos testes apresentados.
Codex (ferramenta): Harness citado como eficaz em tarefas na web nos testes apresentados.
DeepSeek (modelo): Nome associado no vídeo a um harness cujo loop agentic pode ser modificado.
GLM 5 (modelo): Modelo menor que, no exemplo apresentado, superou um modelo mais forte ao usar um harness evoluído.
Gemini 3.5 Flash (modelo): Modelo usado como comparação com GLM 5 no exemplo de desempenho com harness padrão.
Google Research (empresa): Organização que desenvolveu o projeto Harness² em parceria com Northwestern University.
Northwestern University (empresa): Universidade que desenvolveu o projeto Harness² em parceria com Google Research.
Hugging Face (empresa): Plataforma mencionada no exemplo em que um agent acessou a internet e encontrou a rubrica de avaliação de um benchmark.

Tradução completa (pt-BR)

00:00 Todo agent que usamos hoje vem com um harness pré-construído. O problema é que um harness pré-construído precisa servir para todos os casos. E, na maioria dos casos, um harness genérico simplesmente não é otimizado para as tarefas específicas que você está tentando resolver. Na verdade, quando pesquisadores testaram exatamente o mesmo modelo de IA dentro de quatro harnesses populares, incluindo Claude Code e Codex, nenhum harness venceu em todas as categorias. Claude Code foi melhor em programação e planilhas, enquanto Codex foi melhor em

00:32 tarefas na web. E as pesquisas continuam comprovando que um harness feito sob medida para a sua tarefa sempre supera um harness genérico pré-construído. Então, e se, no momento em que você passasse uma tarefa a um agent, ele pudesse criar e evoluir o próprio harness na hora? E se pudesse reescrever as próprias instruções, criar as próprias ferramentas e até editar o próprio loop de controle enquanto trabalha? Essa é exatamente a ideia por trás de um novo

01:03 projeto do Google Research e da Northwestern University chamado Harness Squared, ou Harness 2. E a maior descoberta deles é surpreendente. Um modelo menor e mais fraco, executado dentro de um harness que evolui sozinho, superou com folga um modelo de fronteira muito mais forte executado em seu harness pré-construído padrão. Então, neste vídeo, vamos analisar quais são as ideias centrais do Harness 2, o que acontece quando um agent pode editar o próprio loop e onde essa abordagem falha

01:33 no mundo real. Quando a maioria das pessoas tenta criar um agent que evolui sozinho, a ideia óbvia é permitir que o modelo continue adicionando novas regras ao system prompt sempre que comete um erro. Os pesquisadores testaram isso, e, na verdade, o agent fica pior. Por quê? Porque o system prompt está sempre ativo. Então, cada palavra adicionada ao prompt é enviada em cada etapa de cada tarefa, o que acaba consumindo a atenção do modelo e o orçamento de tokens.

02:04 Em tarefas longas, o principal motivo pelo qual os agents falham é que passam tempo demais lendo instruções e raciocinando, até ficarem sem orçamento antes mesmo de tentar concluir o trabalho. Então, em vez de carregar o system prompt, esse novo projeto de harness permite que o agent edite quatro camadas bem menores na hora. A primeira são skills sob demanda. Quando o agent aprende um workflow especializado, como revisar um contrato jurídico ou limpar uma planilha, ele registra esse procedimento como uma

02:36 skill separada, que custa zero tokens até que uma tarefa realmente a acione. A segunda são ferramentas personalizadas. LLMs não são bons em fazer cálculos repetitivos nem em verificar mentalmente centenas de células. Então, quando uma tarefa exige verificação de dados, o agent escreve um pequeno script Python para conferir os dados de forma determinística. E essa abordagem tem se mostrado muito eficaz para agents de IA. A terceira são subagents. Se uma tarefa exigir

03:08 a leitura de 20 documentos enormes só para extrair uma pequena tabela, o agent cria um subagent separado, com a própria memória limpa, para que todo o texto bruto não sobrecarregue o contexto do agent principal. Dessa forma, eles conseguem evitar a degradação do contexto e remover distrações. E, em quarto lugar, editar o próprio loop de controle. Essa é a maior mudança. Uma regra no prompt é apenas uma sugestão educada que um modelo distraído pode ignorar.

03:41 Ao injetar hooks de código diretamente no próprio loop, o agent pode impor regras rígidas a si mesmo. Em uma tarefa na qual o agent continuava raciocinando até o tempo acabar, ele escreveu um hook de vigilância no próprio loop, que contava as etapas e o obrigava a parar de pesquisar e a escrever o arquivo final. Em outra tarefa, ele se impediu de concluir até que um script respondesse no arquivo do Excel e verificasse que nenhuma das

04:11 fórmulas estava em branco. Já vimos esse padrão em outros lugares também. Você pode modificar completamente o loop agêntico do harness do DeepSeek, ou os Claude mods agora permitem modificar o loop de controle do Claude Code. Certo. Isso levanta a pergunta mais difícil do artigo, porque a maioria dos experimentos é feita com evals. Em laboratório, você pode otimizar um harness porque tem um conjunto de treinamento com um gabarito. No mundo real, quando você

04:43 dá uma tarefa inédita a um agent, não há gabarito. E, quando os pesquisadores deixaram a IA escrever o próprio harness às cegas, sem testar essas edições, o desempenho caiu 10%. Para resolver isso sem um gabarito, o Harness 2 usa um loop de três etapas chamado propor, testar e compor. Veja como funciona. Primeiro, na etapa de propor, o agent executa a tarefa uma vez com o harness padrão. Então, mesmo sem uma nota, o registro mostra onde o agent teve dificuldades.

05:15 Em seguida, dois editores especializados inspecionam esse registro. Um editor corrige apenas a mecânica do workflow, como erros de ferramentas ou conexões do loop, enquanto o segundo editor atua como especialista no domínio, como um contador ou advogado, e continua adicionando regras específicas da área. A segunda etapa é testar. Nessa etapa, o sistema executa esses harnesses aprimorados na mesma tarefa.

05:45 Assim, temos o resultado de referência com um harness padrão e os resultados com o harness aprimorado. E a terceira etapa é compor. Nela, o sistema compara lado a lado o comportamento de antes e depois. Então, em vez de tentar adivinhar qual resposta parece melhor, ele verifica se uma edição corrigiu uma falha concreta da primeira execução, como detectar 12 células vazias da planilha que passaram despercebidas na primeira execução.

06:16 E somente as edições comprovadamente úteis são incorporadas ao harness final. Se a edição não ajudou, o sistema simplesmente mantém o harness original. Então, essa é uma maneira muito boa de adicionar à base os recursos que realmente ajudam na computação, em vez de recorrer a tentativas que apenas parecem ajudar. Certo. A questão é que isso corrige o harness do agent para a tarefa atual em que ele está trabalhando. Mas o que acontece na próxima tarefa?

06:46 Digamos que temos a tarefa um e a tarefa dois. Se você levar o harness muito personalizado da tarefa um diretamente para a tarefa dois, ele pode falhar, porque metade dessas regras era específica da tarefa um. É por isso que o projeto se chama Harness Squared. Ele usa dois níveis de recursão. O nível um evolui o harness para a tarefa que está diante de você. O nível dois evolui a forma como o sistema cria harnesses para tarefas futuras. Depois de cada tarefa, o sistema reflete

07:17 sobre quais edições realmente ajudaram, elimina o ruído específico da tarefa e salva as ferramentas, skills e lições reutilizáveis em uma biblioteca de experiências. Então, quando a próxima tarefa chega, o agent começa do zero com um harness-base limpo e recupera dessa biblioteca apenas as ferramentas e skills comprovadas de que precisa. Assim, com o tempo, ele vai criar uma biblioteca de ferramentas e skills que poderão ser usadas em tarefas posteriores.

07:48 Certo, agora vamos falar sobre o que realmente funciona, o que falha e quais são as conclusões práticas deste artigo. Primeiro, vamos falar sobre o que realmente funciona. Em tarefas de programação, web, escritório e jurídicas, evoluir o harness na hora supera harnesses estáticos, incluindo Claude Code e Codex sem alterações, em todos os domínios. Em tarefas complexas, como revisar contratos jurídicos ou conciliar orçamentos, evoluir o harness aumentou a precisão nas tarefas em 35 a 50 pontos em uma

08:19 única etapa, o que é bastante significativo. Mais importante, isso comprova o efeito do harness sobre o modelo. Não só um modelo menor, o GLM 5, com um harness evoluído, superou um modelo mais forte, neste caso o Gemini 3.5 Flash, com seu harness padrão, como também, quando os pesquisadores pegaram o harness evoluído para o Gemini e o entregaram sem alterações a um modelo menor, a pontuação do modelo menor em programação subiu 17 pontos imediatamente.

08:50 Agora, esse é um ponto muito importante para ter em mente. Isso significa que você pode personalizar um harness com um modelo maior e mais poderoso e, depois, em produção, potencialmente usar esse harness evoluído com um modelo relativamente menor. Em segundo lugar, precisamos pensar em onde esse conceito como um todo falha. O primeiro problema é o multiplicador de computação. Testar harnesses candidatos na hora exige de 4 a 20 execuções completas do agent para uma única tarefa. Então, você

09:23 nunca iria querer executar isso ao vivo para um prompt rápido. Em vez disso, use isso nas suas primeiras 10 ou 20 tarefas para criar sua biblioteca de domínio e, depois, reutilize o harness aprimorado com baixo custo nas tarefas em produção. O segundo problema é a armadilha da câmara de eco. Sem um gabarito real, quando o agent escreve os próprios scripts de verificação, ele pode incorporar as próprias suposições equivocadas ao verificador. Em um teste, o agent escreveu

09:54 o verificador informou que passou três vezes, embora tenha falhado no teste real. Então, é algo para ter em mente. E, na maioria dos casos, você deve ter um verificador ou checker separado, diferente do modelo para o qual está evoluindo o harness. E, em terceiro lugar, vem o momento mais engraçado do repo. Durante uma execução de validação com acesso à internet aberta, o agent percebeu que estava sendo testado em um benchmark público,

10:24 acessou o Hugging Face e baixou sozinho os critérios de avaliação do benchmark. Esse é um comportamento que temos começado a ver cada vez mais. Esses agents têm muito mais autonomia e vão usar qualquer recurso possível ou disponível para realizar uma tarefa. Então, se você estiver avaliando seu harness em evolução ou harnesses em geral, precisa garantir que haja barreiras de proteção realmente boas em torno do tipo de acesso que eles

10:54 terão. Mas a principal conclusão do Harness² é simples: a forma como você projeta o harness agora importa tanto quanto o modelo que escolhe. Se você está criando agents, mantenha seus prompts sempre ativos bem pequenos, transfira os guias de domínio para skills sob demanda, substitua raciocínios repetitivos de LLM por scripts pequenos e aplique suas regras mais importantes dentro do próprio loop de controle. Vou deixar o artigo e o GitHub

11:25 repo na descrição abaixo. E, se você está achando úteis estas análises aprofundadas, considere se inscrever no canal. Isso ajuda muito. Enfim, espero que este vídeo tenha sido útil. Obrigado por assistir e, como sempre, até o próximo.

Transcrição original

[00:00] Every agent that we use today comes with a pre-built harness. The problem is that a pre-built harness has to be one-size-fits-all. And in most cases, a generic harness is simply not optimized for the specific tasks that you are trying to solve. In fact, when researchers tested the exact same AI model inside four popular harnesses, including Claude, Code, and Codex, no single harness won everywhere. Claude Code was better at coding and spreadsheets, while Codex was better at

[00:32] web tasks. And research keeps proving that a purpose-built harness tailored to your task always beats a generic pre-built one. So, what if the moment you hand an agent a task, the agent could build and evolve its own harness on the fly? What if it could rewrite its own instructions, create its own tools, and even edit its own control loop while it works? This is the exact idea behind a new

[01:03] project from Google Research and Northwestern University called Harness Squared or Harness 2. And their biggest finding is wild. A smaller, weaker model running inside a self-evolving harness flat-out beat a much stronger frontier model running on its default pre-built harness. So, in this video, let’s break it down what the core ideas of this Harness 2 are, what happens when an agent can edit its own loop, and where this approach breaks

[01:33] in the real world. When most people try to build a self-evolving agent, the obvious move is to let the model keep adding new rules to its system prompt whenever it makes a mistake. The researchers tested that, and it actually makes the agent worse. Why? Because your system prompt is always on. So, every word that you add to the prompt gets sent at every single step of every task, which ends up eating up the model’s attention and token budget.

[02:04] On long tasks, the number one reason agent fail is that they spend too much time reading instructions and reasoning uh that they run out of budget before even trying to finish the job. So, instead of loading the system prompt, this new harness design lets the agent edits uh four much smaller layers on the fly. First is on-demand skills. When the agent learns a specialized workflow, like how to uh redline a legal contract or clean a spreadsheet, it writes that playbook as

[02:36] a separate skill that costs zero tokens until a task actually triggers it. Second is custom tools. LLMs are bad at doing repetitive math or checking hundreds of cells in their head. So, when a task needs data verification, the agent writes small Python script to check the data deterministically. And this approach has shown to work really well for AI agents. Third is sub-agents. If a task requires

[03:08] reading 20 huge documents just to pull out one small table, the agent spawns a separate sub-agent with its own clean memory, so all the raw text never clutters the main agent’s context. This way, they’re able to avoid context rot and are able to remove distractors. And fourth, editing its own control loop. This is the biggest shift. A rule in the prompt is just a polite suggestion that uh distracted model can ignore.

[03:41] By injecting uh code hooks directly into its own loop, the agent can enforce hard rules on itself. On one task where the agent kept reasoning until uh time ran out, it wrote a watchdog hook into its own loop that counted its steps and forced it to stop researching and write the final file. On another task, it blocked itself from finishing until a script responded in Excel file and verified that none of the

[04:11] formulas were blank. Now, we have seen this pattern elsewhere as well. You can completely modify the DeepSeek harness agentic loop or the Claude mods now enables you to modify the control loop of Claude code. Okay. Uh so, this actually raises the hardest question in the paper because most of the experiments are done under Evals. Uh in a lab, you can optimize a harness because you have a training set with an answer key. In the real world, when you

[04:43] give an agent a brand new task, there is no answer key. And when the researchers let the AI write its own harness blindly without testing those edits, performance dropped by 10%. To solve this without an answer key, harness two uses a three-step loop called propose, probe, and compose. Now, here’s how it works. First, in propose, the agent runs the task once with its default harness. So, even without a grade, uh the log shows where the agent struggled.

[05:15] Then, two specialized editors inspects that log. One editor only fixes workflow mechanics like tool errors or uh loop hookups, while the second editor acts like a domain expert, uh like an accountant or a lawyer, uh which keeps adding domain rules. The second step is uh probe. So, in the probe step, the system runs uh those upgraded harnesses uh on the exact same task.

[05:45] So, now we have the baseline with a default harness and we have results with the upgraded harness. And the third step is compose. In compose, the system compares the before and after behavior side by side. So, instead of guessing which answer sounds nicer, it checks whether an edit fixed a concrete failure from the first run, like catching 12 blank spreadsheet cells that the first run missed.

[06:16] And only proven edits gets merged to the final harness. If the edit didn’t help, the system simply keeps the original harness. So, this is a very nice way of adding the capabilities that are actually helping compute to the baseline, rather than going with attempts that seems to be helping. Okay. Now, the thing is that this fixes the current task that the harness for the agent is working on. But, what happens on the next task?

[06:46] Let’s say uh we have task one and task two. If you carry task one’s heavily customized harness straight into task two, it potentially is going to break because half of those rules were specific to task one. That is why the project is called harness squared. It uses two levels of recursions. So, level one evolves the harness for the task right in front of you. Level two evolves how the system builds harnesses for future tasks. After each task, the system reflects

[07:17] on which edits actually helped, stripes out the task-specific noise, and saves the reusable tools, skills, and lessons into an experience library. So, when the next uh task arrives, the agent starts fresh with a clean base harness and pulls only the proven tools and skills it needs from that library. So, over time, it’s going to build a library of tools and skills that can potentially be used for subsequent tasks.

[07:48] Okay, now let’s talk about what actually works, what breaks, and what are the real takeaways from this paper. First, let’s talk about what actually works. So, across coding, web, office, and legal work, evolving the harness on the fly beats static harnesses, including untouched cloud code codex in every domain. On complex tasks like legal redlining or budget reconciliation, evolving the harness boosted task accuracy by 35 to 50 points in a

[08:19] single step, which is pretty significant. Most importantly, it proves the harness or model effect. Not only did a smaller model GLM 5 uh with an evolved harness beats a stronger model, uh in this case, Gemini 3.5 flash, on its default harness, but when the researchers took the harness evolved for Gemini and handed it unchanged to a smaller model, the smaller model code score jumped by 17 points instantly.

[08:50] Now, this is a very important point to keep in mind. This means you can customize a harness with a larger, more stronger model, and then in production, you can potentially use that evolved harness with a relatively smaller model. Now, second, and we need to think about where this um whole concept breaks. The first one is the compute multiplier. Testing candidate harnesses on the fly takes um anywhere from 4 to 20 full agent runs for a single task. Uh so, you

[09:23] would never want to run this live on a quick prompt. Instead, you use it on your own uh first 10 or 20 tasks to build up your domain library, and then reuse the upgraded harness cheaply on our task in production. Second is the echo chamber trap. Without a real answer key, when the agent writes its own verification scripts, uh it can bake its own bad assumptions into the checker. In one test, the agent’s self-written

[09:54] checker reported pass three times while failing in the real test. So, this is something to keep in mind. And in most of the cases, you want to have a separate uh verifier or checker uh that is different from the model that you are uh evolving the harness for. And third is the funniest moment in the repo. During a validation run with uh open internet access, the agent realized it was being tested on public benchmark,

[10:24] went on to hugging face, and downloaded the benchmark’s grading rubric all by itself. This is the behavior that we have started seeing more and more. These agents have a lot more autonomy and they’re going to use any resource possible or available to them in order to accomplish a task. So, you want to make sure uh if you’re evaluating your uh evolving harness or harnesses in general, uh you need to have really good guardrails around what type of access these are

[10:54] going to have. But, the big takeaway uh from harness two is simple. How you engineer the harness now matters just as much as which model you pick. If you’re building agents, keep your always-on prompts tiny, move domain playbooks into on-demand skills, replace repetitive LLM reasonings with small script, and enforce your most important rules inside the control loop itself. I’ll put uh the paper and the GitHub

[11:25] repo in the description below. And if you’re finding these deep dives helpful, please consider subscribing to the channel. That helps a lot. Anyways, I hope you found this video useful. Thanks for watching and as always see you in the next one.