Como Melhorar um Agente de IA Sem Mudar o Modelo? Harness², o Framework Open Source do Google Research

Ferramentas de IA — Geral
, , , , , ,
1

Google Research publicou Harness², um framework open source que melhora um agente de IA reescrevendo seu harness (prompts, ferramentas, memória, skills e orquestração) sem tocar nos pesos do modelo. O paper foi enviado para arXiv em 9 de outubro de 2026 e o código está disponível sob licença Apache 2.0.

A premissa é bem conhecida por quem lê yoDEV: a capacidade de um agente depende tanto do sistema que rodeia o modelo quanto do próprio modelo. Harness² vai um passo além. Em vez de uma pessoa ajustar esse sistema manualmente, o agente propõe mudanças ao seu próprio harness, as testa e fica com o que funciona.

Quais partes de um agente de IA podem ser otimizadas sem tocar no modelo?

O harness é tudo aquilo que rodeia o modelo e permite que ele atue como agente, e Harness² expõe oito componentes editáveis. Os autores chamam harnessing o processo de otimizar esse sistema. Já cobrimos a disciplina em si em Harness Engineering: O Novo Trabalho do Engineer; Harness² é uma tentativa de automatizá-la.

Os oito componentes são:

  • system prompt
  • guardrails
  • memória
  • guia de ferramentas (tool guidance)
  • subagentes
  • skills
  • scripts
  • plugins

Juntos, controlam como o contexto é construído, como a interface de ferramentas aparece, como o trabalho é delegado e como o agente se comporta dentro do tool loop.

Se você trabalha com Claude Code, Codex ou OpenCode, essa lista lhe parecerá familiar. Corresponde quase um a um ao seu CLAUDE.md ou AGENTS.md, sua pasta de skills, suas definições de subagentes e seus hooks. Harness² trata esses arquivos como algo que se otimiza, não como algo que você escreve uma vez e esquece.

Como um agente de IA melhora seu próprio harness?

Harness² melhora o harness com dois níveis de recursão, e em ambos o modelo permanece fixo.

A recursão no nível de tarefa refina o harness para a tarefa em questão. Faz isso com uma etapa de três partes que os autores chamam Propose–Probe–Compose:

  1. Propose. Um editor sugere mudanças ao harness. Algumas são gerais (invariant) e outras são específicas do domínio.
  2. Probe. Os harness candidatos são executados na mesma tarefa.
  3. Compose. Um compositor monta um harness refinado a partir dos contrastes de comportamento entre essas execuções.

O detalhe-chave é que isso funciona sem feedback de ground truth. O agente não precisa saber a resposta correta. Aprende como diferentes versões do harness se comportam de forma diferente perante o mesmo problema.

A recursão no nível de harnessing opera entre tarefas. Depois de cada tarefa, um “refletor de experiência” guarda o harness adotado e as lições apoiadas por evidência. Tudo isso vai para um improvement harness persistente, que guia o refinamento na próxima tarefa, mesmo que nunca tenha sido vista antes. Essa é a parte de “mundo aberto” do título: o cenário em que aparecem tarefas que ninguém antecipou ao projetar o harness.

Recursão paralela ou sequencial: qual convém?

Depende se você quer explorar mais opções ou refinar mais profundamente. Harness² escala a recursão no nível de tarefa de duas formas, ambas controladas por --k, o orçamento de recursão:

  • --mode parallel testa K harness candidatos gerais e K específicos do domínio, depois produz K composições a partir da evidência compartilhada. Explora mais amplamente.
  • --mode sequential leva o harness refinado e sua evidência acumulada através de K passos sucessivos de Propose–Probe–Compose. Refina mais profundamente.

--k 1 é um único passo. Segundo os autores, um único passo já ajuda, e um orçamento maior ajuda ainda mais.

Quanto o agente melhora segundo os benchmarks?

Segundo os próprios autores, um único passo de Harness² melhorou dois modelos em relação aos seus harness base:

  • GLM-5 e Gemini 3.5 Flash foram testados em quatro configurações modelo–harness.
  • As melhorias chegaram a 11,5 pontos em WorkBuddy-Bench.
  • Chegaram a 4,5 pontos em JobBench.
  • Chegaram a 11,8 pontos percentuais na taxa de aprovação parcial de LAB.

Há duas ressalvas importantes.

Primeiro, são números dos próprios autores em um preprint. Ainda não foram reproduzidos de forma independente.

Segundo, os benchmarks medem trabalho profissional, não programação. JobBench cobre tarefas profissionais gerais e LAB cobre trabalho jurídico. WorkBuddy-Bench cobre escritório, web e código, e apenas seu subconjunto code se parece com o que a maioria de nós faz todos os dias. Os resultados mostram que o método funciona em trabalho de conhecimento aberto. Ainda não dizem quanto melhora um coding agent sobre seu repositório.

Como instalar Harness² e testar a demo sem API keys?

Você pode rodar a demo localmente em poucos minutos e sem credenciais de nenhum modelo. O README exige Linux, Python 3.12 e uv. A partir da raiz do repositório:

uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2

A demo executa ambos os modos de recursão com editores determinísticos e execuções reais de Python. É a forma mais rápida de ver o ciclo Propose–Probe–Compose e inspecionar como fica em disco um harness adotado.

O que você precisa para usá-lo com Vertex AI?

As execuções com modelos reais exigem mais preparação. Você precisa de:

  • Node.js 20 ou superior
  • Google Cloud CLI
  • as dependências do benchmark que escolher: LAB necessita Pandoc e Poppler, e WorkBuddy-Bench necessita Docker

Os modelos são configurados com um arquivo .env que aponta para um projeto Vertex AI:

cp .env.example .env
# Edite .env com seu projeto Vertex AI e IDs de modelo.
gcloud auth application-default login

O guia de instalação documenta quatro variáveis:

  • HARNESS2_SOLVER_MODEL, o modelo executor
  • HARNESS2_IMPROVER_MODEL, que por padrão é o mesmo que o executor
  • HARNESS2_JUDGE_MODEL
  • HARNESS2_RUNS_DIR

A configuração incluída usa Gemini no Vertex como executor e como juiz. Como improver, aceita Claude no Vertex ou Gemini.

O exemplo do README executa uma única tarefa de LAB de ponta a ponta:

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

Essas execuções geram custos de API, e os autores recomendam começar com uma seleção pequena de tarefas. Se você adicionar --dry-run a harness2, vê a seleção de tarefas sem chamar nenhum modelo. Os resultados ficam em runs/, incluindo os harness adotados e as notas de reflexão. Se rodar o mesmo comando novamente, a execução é retomada.

Funciona com OpenCode e Codex CLI?

Sim. OpenCode é o executor padrão, e Codex é ativado com --substrate cx. Para usar Codex com Gemini, o repositório inclui harness2-bridge, um servidor local de LiteLLM que expõe Vertex AI através de uma interface compatível com a API Responses. Para usar outro endpoint da API Responses, o guia documenta HARNESS2_CODEX_BASE_URL, HARNESS2_CODEX_API_KEY e HARNESS2_CODEX_MODEL.

No momento da publicação desta nota, a versão suporta esses dois executores e esses três benchmarks. É um repositório em estágio inicial, então essa lista provavelmente mudará.

Quais riscos de segurança tem?

O README diz explicitamente: o acesso à rede do executor não tem restrições e Codex é executado com seu sandbox desativado. Quando a bridge roda para WorkBuddy, escuta em 0.0.0.0, ou seja, em todas as interfaces de rede, e o guia avisa que você deve restringir quem pode alcançá-la.

Os autores também apontam um problema de integridade: as rubricas públicas dos benchmarks podem estar disponíveis na internet. Recomendam configurar restrições de rede antes de qualquer avaliação. Não rode em uma máquina com acesso a algo que você se importe. O conselho vale o dobro porque o projeto deixa claro que não é um produto com suporte oficial do Google e fica fora do programa de recompensas por vulnerabilidades open source do Google.

Por que importa se você não roda benchmarks?

Porque a ideia de fundo se aplica a qualquer agente que você use, mesmo que Harness² seja um artefato de pesquisa e não uma ferramenta que você vá somar ao seu fluxo diário na próxima semana. Seu harness é um conjunto de arquivos, e esses arquivos podem ser medidos e melhorados de forma sistemática: rode variantes sobre a mesma tarefa, compare o comportamento, fique com o que vence e registre por quê.

É a mesma direção do trabalho da Microsoft com SkillOpt, mas aplicada a todo o harness em vez de apenas uma skill. Agora o Google Research tem uma versão pública e reproduzível desse ciclo. Se sua equipe mantém uma pilha crescente de instruções para agentes, é uma boa referência para parar de ajustá-las de olho.

E você? Qual parte do seu harness você muda com mais frequência: o system prompt, as skills ou a memória?

Como você melhora hoje as instruções de seus agentes?
  • Ajusto manualmente quando algo falha
  • Testo variantes e comparo resultados
  • Quase não as toco depois de escrevê-las
  • Prefiro outra opção (conta pra gente qual)
0 votantes

Comente abaixo ou, se este artigo chegou para você por email, responda diretamente ao email: sua resposta é publicada aqui.

Relacionado: Composer 2.5: Por Que o Harness Importa Mais que o Modelo