← Todos os materiais

O que é harness, afinal

Você troca de modelo e o resultado continua ruim. Sai do Claude, entra no GPT. Sai do GPT, volta pro Claude. Mesma bagunça. Isso acontece porque você ficou mexendo no cérebro, e o problema tava em volta dele.

Esse “em volta” tem nome: harness. Todo mundo fala, quase ninguém explica. Então vamos lá.

A definição

A conta que resume tudo:

Agente = Modelo + Harness

O modelo pensa. O harness age. Um modelo de linguagem sozinho só cospe texto: ele não abre arquivo, não roda comando e não lembra de nada de uma conversa pra outra. Harness é toda a infraestrutura de software em volta do modelo que dá mão e memória pra ele.

A analogia que eu mais gosto: o modelo é o motor, o harness é o carro. Motor solto no chão faz barulho e não sai do lugar. Precisa de roda, volante, freio, painel e tanque. Trocar de motor num carro sem freio não resolve nada. Só te faz bater mais rápido.

As peças

Traduzindo o jargão pro português:

  • Ferramentas (o que chamam de tool dispatch): ler arquivo, rodar comando, buscar na web
  • Memória (state persistence): o que ficou decidido, salvo fora do chat
  • Oficina (sandbox): uma pasta ou máquina isolada onde a IA pode quebrar coisa sem derrubar o resto
  • Contexto (context management): quem escolhe o que ela vê agora
  • Freio (guardrails): o que ela pode fazer sozinha e o que precisa te perguntar antes

Você já usa um

Codex, Cursor e Claude Code são harness de fábrica: vêm prontos, feitos por quem fez o modelo ou a ferramenta. Você não controla o que tem dentro.

Em volta do de fábrica, você monta o seu: arquivo de instruções, servidores MCP, skills próprias. Essa camada é sua e é nela que mora a diferença entre uma IA que te atrapalha e uma que trabalha do seu jeito. A distinção entre harness interno e externo é da Birgitta Böckeler, da Thoughtworks, e está citada no próprio verbete de agent harness.

Ela também separa as duas coisas que todo harness bom precisa ter. Guias falam antes da ação: suas regras, seus padrões, suas skills. Sensores conferem depois: teste, lint, um revisor que olha o resultado. Cada um pode ser código (um lint que roda) ou outra IA (um modelo julgando o trabalho do primeiro). Sem sensor, a IA jura que terminou e você descobre a mentira em produção.

Por que isso importa

Um paper de 2026 testou a mesma tarefa, com o mesmo modelo, em dois harness que diferiam apenas em como apresentavam informação auxiliar. As taxas de sucesso foram drasticamente diferentes. A conclusão dos autores: capacidade de agente deveria ser reportada por configuração modelo mais harness, não pelo modelo puro.

Ou seja: quando a sua IA erra, na maioria das vezes não é o modelo. É o que você montou (ou deixou de montar) em volta dele.

O vocabulário de “harness engineering” apareceu no começo de 2026, com a autoria disputada entre Mitchell Hashimoto e Vivek Trivedy, da LangChain. É uma camada mais ampla que engenharia de prompt e de contexto, e contém as duas. Um harness bem projetado inclusive se recupera quando o modelo inventa uma ação ou diz que terminou sem ter terminado.

O que fazer com isso

A prática atribuída ao Hashimoto virou a minha regra de trabalho: a cada erro do agente, um conserto permanente no ambiente dele. Errou? Você não repete o pedido com outras palavras. Você arruma o ambiente pra aquele erro não caber mais. O pedido morre na conversa; o conserto fica pra sempre.

É isso que separa quem reclama de IA de quem entrega com IA.

Quer ver como o meu harness está montado hoje? Me chama no WhatsApp ou no Instagram que eu te mostro o setup.

Fontes