Trocamos o Harness (Não o Modelo) e o Benchmark Subiu +13,7 Pontos
Sexta passada um colega me perguntou qual GPT eu ia usar para melhorar nosso agente de suporte. A resposta certa era “nenhum”. A honesta era “acho que a gente está trocando a peça errada há três meses”.
Eu passei um fim de semana lendo o post da LangChain “The Anatomy of an Agent Harness” e a análise que a Hexabase fez a partir dele. O número que me travou foi este: de 52,8% para 66,5% no mesmo benchmark, mesmo modelo, só mudando o harness. Terminal Bench 2.0. deepagents-cli rodando em cima do gpt-5.2-codex. Top 30 → Top 5. O modelo embaixo continuou o mesmo.
Ganho de 13,7 pontos. Fica difícil olhar para o mercado de “escolher o melhor GPT” da mesma forma depois disso.
O que ninguém quer ouvir
Contrata-se muita gente hoje para “avaliar qual modelo é melhor”. Ninguém contrata para “avaliar qual harness é melhor”. Só que o segundo é quem move o benchmark.
Modelo importa, claro. Só que, quando você já usa um modelo razoável (qualquer coisa a partir de GPT-5.1 ou Claude Sonnet 4.5), a diferença entre um agente que funciona e um que anda em círculos está no harness: prompts de sistema, injeção de contexto, middleware de detecção de doom loops, reset de contexto, trace-driven iteration.
A LangChain provou isso com um único ajuste de infraestrutura. Não trocou o cérebro. Trocou o corpo.
Como eles chegaram a +13,7 pontos
Três coisas mudaram no harness do deepagents-cli, segundo o próprio time da LangChain:
- Prompts de sistema com self-verification loops. Depois de cada passo, o agente é obrigado a verificar seu próprio output antes de seguir. Sim, aumenta latência. Não, o custo compensa.
- Enhanced tools + context injection. As ferramentas ganharam contexto sobre o ambiente em que estão rodando. O agente parou de chutar coisas como “qual é o meu diretório atual”.
- Middleware hooks para detectar padrões problemáticos. Doom loop (o agente tenta a mesma coisa que já falhou), context bloat, decisões conflitantes. Um wrapper interceptando e cortando.
E o quarto ponto, o menos falado, é onde a diferença vira mensurável:
- LangSmith tracing at scale. Não dá para melhorar harness sem observar. Eles rodaram traces em escala, identificaram os modos de falha por padrão e iteraram a partir daí. É engenharia clássica aplicada a agentes.
Juntando as quatro peças, o que sobra é um loop de melhoria empírica que substitui o achismo de prompt.
5 padrões que eu tirei disso para o dia a dia
Peguei o que a LangChain fez e o que a Anthropic recomenda no guia “Effective harnesses for long-running agents”, cruzei com o que eu já venho usando, e reduzi a 5 padrões que dá para aplicar semana que vem.
1. Self-verification obrigatório depois de mudanças no repo
Todo passo que mexe em arquivo tem uma etapa “verificar que o que eu fiz corresponde ao que eu disse que ia fazer”. Isso vai além de git status: o agente relê o próprio diff e responde “sim, isso faz o que a task pediu?”. Latência sobe uns 20%, taxa de retrabalho cai bem mais.
2. Injeção de contexto ambiental direto na ferramenta
Em vez de escrever no prompt “você está no diretório X, rodando Y”, coloque isso no schema/return da ferramenta. Quando o agente chama read_file, o retorno já traz “current working directory: X”. O prompt fica curto e o contexto fica fresco.
3. Middleware que detecta doom loop e força reset
Se o agente tentou a mesma ação duas vezes seguidas sem progredir, um middleware corta e injeta um “você acabou de repetir uma ação. Reconsidere a estratégia antes do próximo passo.” Simples. Salva token e cabeça.
4. Reset de contexto com progress file
Ideia da Anthropic. Quando a janela de contexto começa a saturar (context anxiety), o agente escreve um progress.txt do estado atual e você inicia um novo agente com contexto limpo lendo só esse arquivo + git log. Continuidade sem carregar 200k tokens de “eu tentei isso, não deu, tentei aquilo”.
5. Trace-driven iteration em vez de prompt tweaking
Não fica trocando adjetivo no system prompt esperando magia. Instrumenta as chamadas (LangSmith, LangFuse, ou logs próprios), agrupa falhas por padrão, e melhora um padrão de cada vez. É lento no começo, mas cada melhoria fica.
Métricas para brigar internamente
Se você quiser convencer seu time (ou o líder) de que “trocar harness” é onde investir, essas são as quatro métricas que eu levo para reunião:
| Métrica | Como calcular |
|---|---|
| Taxa de sucesso de tarefa | Tarefas completas / tarefas atribuídas |
| Taxa de retrabalho | Revisões humanas necessárias / tarefas completas |
| Tokens por tarefa | Total de tokens / número de tarefas |
| Quality gate first-pass | Execuções que passam lint+test na primeira / total |
Toda mudança de harness devia mover pelo menos um desses números. Se não move nenhum, a mudança não teve efeito, e você acabou de gastar dois dias.
O caso 52,8 → 66,5 da LangChain tem número, causa e componente identificados. Se o seu time não consegue apontar nada parecido, é sinal de que ainda está brigando com o modelo enquanto o harness segue intocado.
Quem lucra com “trocar o modelo”
Quem vende modelo. Ficou fácil, né?
O mercado de LLM é um mercado de fornecedores. Cada release nova gera post, benchmark, thread no X, e a percepção de “agora sim vai resolver”. Mas quando a LangChain move 13,7 pontos sem trocar de modelo, a leitura é outra: ninguém chegou perto do teto do modelo atual. A maioria dos times está rodando bem abaixo do que o modelo consegue entregar, porque o harness em volta dele está mal montado.
Isso é uma notícia boa: o próximo salto de performance do seu agente não depende do próximo release da OpenAI/Anthropic. Depende de você. Do harness. Da ergonomia do prompt de sistema, do middleware, do tracing.
Semana que vem eu vou aplicar os cinco padrões acima no meu próprio harness (o que roda esse blog, entre outras coisas). Se der certo, escrevo a retrospectiva com números. Se der errado, escrevo mesmo assim: falhar em público ensina a comunidade BR mais rápido do que qualquer curso pago.
Os cinco padrões são o recorte que cabe num post; o playbook inteiro, do AGENTS.md aos hooks, está no meu livro Harness Engineering: De Usar IA a Controlar IA.
Fontes:
- LangChain — The Anatomy of an Agent Harness (blog) — post oficial de referência
- ZenML LLMOps Database — Harness Engineering for Agentic Coding Systems
- Terminal Bench 2.0 — deepagents-cli scoring
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews
Este artigo foi útil?