Harness2: o Google abriu o código do agente que reescreve o próprio harness

Até agora o harness era a parte do agente que você escrevia na mão. O modelo só obedecia.

O Google acabou de abrir o código de um harness que se reescreve sozinho entre uma tarefa e outra. Sem tocar em um peso do modelo.

O nome é Harness2 (no paper, Harness²). Saiu do Google Cloud AI Research, com uma autora da Northwestern University, código no GitHub sob Apache 2.0 e paper no arXiv publicado em 09/10/2026. A ideia cabe numa frase: o agente propõe mudanças no próprio system prompt, nas tools, na memória, nas skills e nos subagentes, testa essas mudanças na mesma tarefa, fica com o que se sustentou e leva as lições pra próxima.

Neste post você vai ver o que exatamente o Harness2 edita, como ele decide que uma mudança é melhor sem ter gabarito, o que os números provam (e o que não provam), como rodar o repo hoje e o problema que me parece o mais importante dessa história toda: governança de um harness que se edita.

TL;DR

• O que é: framework de pesquisa do Google que refina o harness do agente (não o modelo) via um ciclo Propose-Probe-Compose, sem ground truth.
• Stack/Modelos: Python 3.12 + uv, executor OpenCode ou Codex CLI; testado com GLM-5 e Gemini 3.5 Flash via Vertex AI.
• Custo/Acesso: open source (Apache 2.0). Rodar benchmark de verdade gasta API. Tem demo local sem credencial.
• Repositório: github.com/google-research/harness2

O que o Harness2 muda: o harness deixa de ser fixo

Não vou reexplicar o que é harness aqui. Se você precisa da base, comece por o que é harness de IA e depois pela anatomia de um agent harness.

O ponto é este: a tese que a gente repete aqui no blog é que o harness é o que separa demo de produção. Mesmo modelo, harness diferente, resultado completamente diferente. O próprio paper abre com isso: performance de agente depende do modelo e do harness de execução.

Só que até hoje esse trabalho era humano. Você olhava o trace, via o agente errando tool call, ajustava o prompt, adicionava um guardrail, criava uma skill. Repetia.

O Harness2 automatiza esse ciclo. Segundo o README, ele mexe em oito componentes:

• Construção de contexto: system prompt, guardrails, memória, skills
• Interface de tools: tool guidance, scripts
• Orquestração: subagentes
• Controle de middleware: plugins

O modelo fica congelado. Quem evolui é tudo em volta dele.

E ele trabalha em dois níveis de recursão:

1. Nível de tarefa: refina o harness de execução pra tarefa atual.
2. Nível de harnessing: atualiza um "improvement harness" persistente com os harnesses adotados e as lições que tiveram evidência, pra guiar o refinamento da próxima tarefa.

O segundo nível é o pulo do gato. Não é só "o agente se ajusta pra essa tarefa". É "o agente aprende a ajustar o próprio harness melhor da próxima vez".

Vale contexto: o Google não está sozinho nem é o primeiro nessa linha. O próprio Google Research tem o RRSI, outra abordagem de auto-melhoria recursiva de harness, e o paper do Harness2 compara contra Meta-Harness, ReasoningBank e Harness Scaling. A diferença declarada do Harness2 é mirar o "mundo aberto": tarefa que o harness nunca viu e sem verificador pra dizer se acertou.

Se você está construindo harness na mão hoje (e deveria, porque é ali que mora o diferencial), esse é o tipo de coisa que a gente desmonta e monta ao vivo toda semana no Clã Beer and Code: agente, harness e pipeline rodando, com gente revisando junto em vez de cada um travar sozinho no próprio trace.

Propose-Probe-Compose sem gabarito: como o Harness2 decide que uma mudança é melhor

Aqui está a parte que eu acho mais interessante, e que diferencia o Harness2 do loop clássico de auto-melhoria.

No agent improvement loop que a gente já mostrou aqui, o agente melhora o código e tem um eval com gabarito pra dizer se melhorou. Passou no teste, fica. Quebrou, volta.

O Harness2 melhora o harness e não tem gabarito. Em produção, a tarefa nova não vem com resposta certa anexada. Então como ele decide?

Pelo paper, cada passo funciona assim:

Propose. O harness atual roda uma vez na tarefa e gera uma execução de referência. Em cima dela, um editor propõe dois candidatos:

• um invariante, mirando fraquezas recorrentes de agente (planejamento, uso de tool, gestão de contexto, delegação);
• um específico do domínio, mirando conhecimento e restrições daquela área.

Probe. Cada candidato roda na mesma tarefa, mesmo modelo, mesmo ambiente. A trajetória e o entregável de cada um são comparados com a referência. Isso gera o que o paper chama de contraste comportamental: a mudança ajudou, não fez diferença ou causou regressão?

Compose. Um composer lê a referência, os candidatos, os diffs e as evidências da tarefa. Ele pode fundir as mudanças que se sustentaram, revisar as que conflitam, adotar um candidato inteiro ou manter o harness atual. Toda decisão precisa estar amarrada a uma observação concreta, não a um "acho que vai subir o score".

Depois de cada tarefa, um reflector revisa tudo e grava lições numa biblioteca. Cada entrada tem um harness executável e um EXPERIENCE.md com a situação em que se aplicou, a lição e a evidência. Se a evidência é fraca, não entra nada.

Repara na honestidade do paper aqui: a referência "revela como o harness se comporta, não se o entregável está correto". Ou seja, sem gabarito, o sinal é comportamento observado + julgamento do modelo. É engenharia de evidência, não prova.

Alguns cuidados de segurança no próprio desenho, que vale copiar no seu projeto: harnesses candidatos e artefatos são tratados como dado, não instrução, scripts vindos de candidatos nunca são executados pelo improver, e nenhum grader, rubrica ou score fica disponível pra ele.

Os números do paper do Harness2 (e o que eles não provam)

Os números que viralizaram são reais, mas precisam de contexto. Com um único passo de Propose-Probe-Compose (k=1), os autores reportam:

Com mais orçamento de recursão (k=5 em paralelo), os números sobem mais. No WorkBuddy-Bench, por exemplo, o GLM-5 + OpenCode vai pra perto de 79,6. Num apêndice, o JobBench mostra taxa de erro de tool caindo de 14,4% pra 9,1%.

Agora a parte que o hype pula:

• Os maiores ganhos são de configurações diferentes. Não existe um setup que pegou +11,5, +4,5 e +11,8 ao mesmo tempo.
• Quem mais ganha é o modelo mais fraco. O GLM-5 parte de bem mais baixo que o Gemini 3.5 Flash. Harness ruim tem mais espaço pra melhorar. Faz sentido, mas muda a leitura.
• Dois juízes são modelos. O juiz do LAB e o da rubrica do JobBench são baseados em LLM. Juiz LLM avaliando agente LLM tem viés compartilhado, e o próprio paper admite isso nas limitações.
• Não tem número de custo absoluto. O paper mostra o Harness2 na fronteira de Pareto de custo vs. performance, mas não dá conta de token ou dólar. E diz claramente: mais recursão = mais inferência.
• São três benchmarks e quatro configurações. Generalizar daí pro seu domínio é aposta, não conclusão.
• Números auto-reportados, v1 no arXiv, sem replicação independente ainda.

Ou seja: resultado promissor, metodologia honesta sobre os próprios limites. Não é "o agente agora se conserta sozinho".

Como rodar o repo do Harness2 no seu agente hoje

Requisitos segundo o README: Linux, Python 3.12 e uv. Pra benchmark com modelo de verdade: Node.js 20+, Google Cloud CLI e um projeto Vertex AI. O LAB pede Pandoc e Poppler; o WorkBuddy-Bench pede Docker.

Passo 1: demo local, sem credencial

Comece por aqui. Não gasta nada e mostra a estrutura de saída.

git clone https://github.com/google-research/harness2
cd harness2
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2

Passo 2: configurar o modelo

cp .env.example .env
# edite o .env com o projeto Vertex AI e os IDs de modelo
gcloud auth application-default login

Passo 3: rodar um recorte pequeno

O próprio README recomenda começar com poucas tarefas, porque cada passo de refinamento roda o agente várias vezes. Use --dry-run antes pra ver o que vai ser selecionado sem chamar modelo.

harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel \
  --only-domains antitrust-competition --max-tasks 1
harness2-judge --bench lab --k 1 --mode parallel
harness2-report --bench lab --k 1 --mode parallel

Flags que importam:

• --k: orçamento de recursão por tarefa. --k 1 é um único passo Propose-Probe-Compose.
• --mode parallel: testa K candidatos gerais e K de domínio, depois gera K composições. --mode sequential refina em K passos seguidos.
• --substrate cx: troca o executor padrão (OpenCode) pelo Codex.

Erro comum: rodar o judge ou o report com parâmetros diferentes da rodada de refinamento. Benchmark, executor, subset, --k, --mode e seed precisam bater. E se trocar de modelo ou de seleção de tarefa, aponte HARNESS2_RUNS_DIR pra um diretório novo.

Uma ressalva honesta: hoje o repo roda nos três benchmarks do paper, plugado em OpenCode ou Codex. "Rodar no seu agente" significa, na prática, estudar o que ele produz em runs/ (harnesses adotados, notas de reflexão, entregáveis) e levar o padrão pro seu harness. Não é uma lib que você importa no seu Laravel amanhã.

O problema que ninguém está discutindo: auditoria, versionamento e rollback de um harness que se edita

Aqui é onde eu quero que você pare um minuto.

Se o harness é o que separa demo de produção, um harness que se auto-ajusta muda quem faz esse trabalho. E cria uma pergunta que o paper não responde, porque não é o escopo dele:

Quando o agente mudou o próprio system prompt na terça, quem revisou?

Pensa no que o Harness2 pode editar: guardrails, memória, tool guidance, plugins de middleware. Isso é exatamente a camada onde mora segurança e comportamento do seu agente em produção. Um guardrail afrouxado porque "o contraste comportamental mostrou que a tarefa andou mais rápido sem ele" é um incidente esperando acontecer.

O que eu faria antes de deixar qualquer coisa nesse estilo perto de produção:

1. Harness é código. Vai pro git. Cada harness adotado vira commit, com a nota de reflexão como mensagem. Diff legível é pré-requisito.
2. Separar as zonas. Prompt de estilo e skill de domínio podem evoluir sozinhos em staging. Guardrail, permissão de tool e plugin de middleware só mudam com aprovação humana.
3. Gate com o seu eval, não com o dele. O Harness2 decide sem gabarito. Você, antes de promover pra produção, decide com gabarito. Aqui o agent improvement loop e o Harness2 se complementam.
4. Rollback é uma tag. Se o harness da versão N piorou métrica em produção, voltar pra N-1 tem que ser um comando, não uma arqueologia.

Um esqueleto mínimo dessa disciplina, adaptando o caminho pra onde o seu harness vive:

# depois de cada rodada de refinamento
HARNESS_DIR=./agent-harness   # system prompt, skills, AGENTS.md, guardrails...
cd "$HARNESS_DIR"

git add -A
git commit -m "harness: refinamento automático $(date +%F)" \
           -m "$(cat ../ultima-reflexao.md)"

# revisão humana obrigatória quando mexer em zona sensível
if git diff HEAD~1 --name-only | grep -Eq 'guardrails|plugins|permissions'; then
  echo "Mudança em zona sensível. Abrindo PR em vez de promover." && exit 1
fi

# promoção só se o eval com gabarito passar
./run-evals.sh && git tag "harness-$(date +%Y%m%d-%H%M)"

# rollback: git checkout <tag-anterior> -- .

O próprio README ajuda a entender o tamanho do cuidado: a rede do executor é irrestrita e o Codex roda com sandbox desligado. Os autores avisam também que rubricas de benchmark públicas podem estar acessíveis online e pedem restrição de rede antes de avaliar. E o projeto é explícito: "não é um produto oficialmente suportado pelo Google". É pesquisa. Trate como pesquisa.

Limitações e pontos de atenção

• Custo. Cada passo roda o agente várias vezes (referência + candidatos + composição). Mais k, mais token. O paper não dá número absoluto.
• Sinal ruidoso. Sem gabarito, a decisão depende de contraste comportamental e julgamento de modelo, sensíveis a variação de execução e a vieses compartilhados. Os próprios autores dizem que isso não garante correção nem transferência.
• Segurança de execução. Rede aberta e sandbox desligado no Codex. Não rode isso numa máquina com credencial de produção.
• Dados. Se você testar em tarefa interna, o editor vai ler trajetória e entregável. Não jogue dado de cliente sem mascarar.

FAQ rápido

Harness2 treina ou faz fine-tuning do modelo? Não. Os pesos ficam congelados. O que muda é o harness: system prompt, guardrails, memória, skills, tool guidance, scripts, subagentes e plugins. Por isso funciona com modelo fechado via API, como o Gemini 3.5 Flash.

Posso usar comercialmente? A licença do código é Apache 2.0. Mas código de terceiros em third_party/, benchmarks e datasets mantêm as licenças de origem. E o projeto não é produto suportado pelo Google. Confira o README antes.

Qual a diferença pro loop de auto-melhoria com evals? No agent improvement loop o agente melhora o código e um eval com gabarito decide. No Harness2 o agente melhora o harness e decide sem gabarito, por contraste entre execuções.

Roda com modelo local? O fluxo documentado usa Vertex AI e executores OpenCode ou Codex. O paper testou GLM-5, que tem pesos abertos, mas via a configuração dos autores. Modelo local não está no caminho documentado hoje.

Conclusão

O Harness2 pega o trabalho mais artesanal da engenharia de agentes, olhar trace e ajustar harness, e mostra que dá pra automatizar boa parte dele sem gabarito. Os números são bons, especialmente pra modelos mais fracos, e o paper é honesto sobre os próprios limites.

Mas a lição pra quem constrói produto não é "deixa o agente se virar". É que o harness virou um artefato vivo. E artefato vivo em produção precisa de versionamento, revisão e rollback, como qualquer outro código.

O próximo passo dessa tecnologia não vai ser um agente que se melhora mais. Vai ser quem consegue provar o que o agente mudou.

Se você ainda não tem a base de harness bem firme, volte na anatomia de um agent harness antes de deixar qualquer coisa editar o seu.