DEV Community

Cover image for Modelo ou harness? O modelo define o teto, mas o harness decide o resultado

Modelo ou harness? O modelo define o teto, mas o harness decide o resultado

Por que o melhor agente de IA não é necessariamente aquele que usa o modelo mais poderoso — e como contexto, ferramentas, memória, validação e ciclos de feedback passaram a decidir o desempenho real.

Introdução

Durante boa parte da evolução recente da inteligência artificial, escolher uma tecnologia significava comparar modelos: qual raciocina melhor, qual escreve código com mais precisão, qual possui a maior janela de contexto ou qual lidera determinado benchmark.

Essa comparação continua importante. O problema é que ela se tornou insuficiente.

Quando usamos um modelo de linguagem de grande escala — ou LLM, do inglês large language model — dentro de um agente, o resultado não depende apenas dos parâmetros aprendidos durante o treinamento. Depende também de quais informações o modelo recebe, das ferramentas disponíveis, de como os resultados dessas ferramentas retornam ao contexto, de quando o agente tenta novamente, de como verifica seu próprio trabalho e até de quem decide que a tarefa terminou.

Esse sistema ao redor do modelo é chamado de harness: a camada de execução e controle que transforma um modelo, essencialmente capaz de receber entradas e produzir saídas, em um agente capaz de observar um ambiente, usar ferramentas, manter estado e executar tarefas. A própria Anthropic ressalta que avaliar um agente significa avaliar conjuntamente o modelo e seu harness; a OpenAI, ao descrever o Codex, também trata o harness como o agente loop, as ferramentas, o sandbox e a lógica de execução que tornam o modelo operacional. (Anthropic)

Então, qual possui maior relevância?

Para capacidade bruta, o modelo. Para desempenho real, confiabilidade e custo de um agente, o conjunto modelo–harness. Em aplicações de produção, o harness frequentemente se torna tão importante quanto o modelo — e, em alguns critérios, mais importante.

Modelo e harness não fazem o mesmo trabalho

O modelo é o mecanismo de inteligência probabilística. Ele interpreta instruções, produz texto, raciocina sobre problemas, escreve código e decide qual ação parece mais adequada.

O harness é o sistema que organiza essa inteligência. Ele pode incluir:

  • instruções de sistema e montagem do contexto;
  • ferramentas, APIs e suas descrições;
  • memória de curto e longo prazo;
  • acesso a arquivos, terminal, navegador e bancos de dados;
  • planejamento, delegação e uso de subagentes;
  • limites de tempo, custo e quantidade de interações;
  • validação, testes, tentativas adicionais e critérios de parada;
  • sandbox, permissões, auditoria e observabilidade.

Um modelo sozinho pode sugerir um comando. O harness decide se ele pode executá-lo, em qual diretório, com quais permissões, durante quanto tempo e o que fazer com o resultado.

A analogia mais útil é pensar no modelo como o motor de um carro de corrida. O harness inclui transmissão, pneus, direção, freios, telemetria e equipe de boxes. Um motor excelente em um veículo mal projetado não transforma potência em velocidade. Por outro lado, o melhor chassi do mundo não fará um motor fraco competir com a Fórmula 1.

Por isso, o desempenho de um agente pode ser representado de forma mais honesta assim:

Resultado observado = f(modelo, harness, tarefa, ambiente e orçamento)

Não se trata de uma soma simples. Há uma interação: um harness pode ampliar determinada capacidade do modelo, desperdiçá-la ou até limitá-la.

O modelo ainda importa — e muito

Um dos estudos recentes que mais diretamente separa essas variáveis é o Claw-SWE-Bench, publicado como preprint em 2026. O trabalho utiliza tarefas de engenharia de software baseadas em problemas reais de repositórios e realiza dois experimentos complementares: mantém o harness fixo enquanto troca os modelos e, depois, mantém modelos fixos enquanto troca os harnesses.

Com o mesmo harness e nove modelos diferentes, a escolha do modelo produziu uma variação de 29,4 pontos percentuais na taxa de resolução. Ou seja: trocar apenas o modelo continua alterando substancialmente a capacidade do agente. (arXiv)

Essa é também a lógica da área “Bash Only” do SWE-bench Verified. Para comparar modelos de maneira mais justa, todos são executados com o mesmo mini-SWE-agent, em um ambiente mínimo e com o mesmo loop de interação. Fixar o harness é justamente o que permite atribuir a diferença observada ao modelo, em vez de misturar inteligência, ferramentas e estratégias de execução. (Swebench)

O modelo tende a ser o principal gargalo quando a tarefa exige uma capacidade que ele simplesmente não possui: compreender uma arquitetura complexa, deduzir uma causa não evidente, escrever um algoritmo difícil ou seguir restrições numerosas e contraditórias.

Nenhuma quantidade de orquestração cria magicamente uma capacidade ausente. O harness pode fornecer uma calculadora, mas não garante que o modelo saiba formular o cálculo correto.

O harness pode mudar quase tanto quanto o modelo

No outro eixo do Claw-SWE-Bench, os pesquisadores mantiveram o modelo fixo e trocaram cinco harnesses. A diferença chegou a 12,5 pontos percentuais com um modelo e a 27,4 pontos percentuais com outro. Nesse segundo caso, a mudança de harness teve impacto comparável à variação observada ao trocar modelos. (arXiv)

A importância da interface já aparecia no trabalho do SWE-agent, de 2024. Os autores criaram uma Agent-Computer Interface — uma interface computadorizada desenhada especificamente para as necessidades do agente — com comandos para navegar pelo repositório, visualizar e editar arquivos e executar testes. O sistema atingiu 12,5% de resolução no SWE-bench, resultado que, naquele momento, superava consideravelmente abordagens não interativas. O ponto central do paper não era apenas “usar um modelo melhor”, mas adaptar o ambiente à maneira como o modelo observa e atua. (arXiv)

Isso acontece porque um agente trabalha em ciclo fechado: ele age, observa o resultado, atualiza seu estado e decide a próxima ação. Pequenas escolhas do harness podem se acumular durante dezenas de interações. Uma saída de terminal truncada incorretamente, uma ferramenta descrita de forma ambígua ou um teste que nunca é executado pode colocar todo o restante da trajetória na direção errada.

Em produção, o harness pode dominar custo e eficiência

A taxa de acerto não é a única métrica relevante.

O preprint The Scaffold Effect in Coding Agents comparou dois modelos em três harnesses de código aberto, utilizando um subconjunto de 50 tarefas do Terminal-Bench Pro. As diferenças de resolução entre harnesses ficaram entre zero e oito pontos percentuais, enquanto a troca de modelo produziu diferenças de quatro a dez pontos. Para precisão, portanto, os dois fatores tiveram magnitudes próximas, com leve vantagem para o modelo naquele experimento.

A situação mudou completamente quando os autores avaliaram eficiência. Dependendo do harness, o consumo de tokens por tarefa resolvida variou em até 40 vezes. Token é a unidade de texto processada e normalmente utilizada para medir consumo e cobrança das APIs. Os harnesses também apresentaram padrões próprios de falha: um desistia mais cedo, outro continuava até atingir o limite de interações e outro gastava tempo em ciclos nos quais nenhuma nova ação era executada. (arXiv)

Isso significa que dois agentes com taxas de acerto semelhantes podem ter custos, latências e necessidades de supervisão completamente diferentes.

O estudo possui limitações importantes: avaliou apenas dois modelos, três harnesses e 50 tarefas, e a maioria das diferenças de resolução não foi estatisticamente conclusiva. Ainda assim, a variação de custo foi suficientemente grande para mostrar que escolher somente pelo nome do modelo pode levar a uma decisão operacional ruim. (arXiv)

Um harness melhor não significa um harness mais complexo

Reconhecer a importância do harness não é uma defesa de arquiteturas cheias de agentes, planejadores, memórias, roteadores e dezenas de ferramentas.

O paper Agentless apresentou uma abordagem deliberadamente simples para problemas de software: localizar o trecho relevante, produzir uma correção e validar o patch. Sem permitir que o modelo controlasse livremente uma sequência complexa de ações, o sistema alcançou 32% no SWE-bench Lite, com custo médio reportado de US$ 0,70 por problema. O resultado mostrou que um fluxo estruturado e previsível pode superar agentes mais sofisticados em tarefas bem delimitadas. (arXiv)

A Anthropic chegou a uma conclusão semelhante trabalhando com equipes que construíam sistemas de IA: as implementações mais bem-sucedidas frequentemente utilizavam padrões simples e combináveis. A recomendação é começar pela solução mais simples e aumentar a autonomia apenas quando a tarefa realmente exigir flexibilidade. Agentes acrescentam capacidade, mas também aumentam custo, latência e superfícies de falha. (Anthropic)

Portanto, harness engineering não significa “adicionar mais camadas”. Significa projetar a menor estrutura capaz de corrigir os modos de falha observados.

Um harness também pode atrapalhar um modelo melhor

Há outro detalhe importante: o mesmo harness não funciona igualmente bem para todos os modelos.

A Anthropic relatou que reinicializações periódicas de contexto ajudavam o Claude Sonnet 4.5 a não encerrar tarefas longas prematuramente. Ao aplicar a mesma estratégia ao Claude Opus 4.5, o problema já não aparecia, e as reinicializações se tornaram peso desnecessário. O mecanismo havia sido criado para compensar uma limitação específica de determinado modelo. Quando o modelo mudou, a premissa do harness ficou obsoleta. (Anthropic)

O preprint Rethinking the Evaluation of Harness Evolution for Agents fornece um alerta ainda mais direto. Em um experimento sem acesso a testes de unidade, um processo automático de alteração do harness reduziu o desempenho do GPT-5.4 de 75,3% para 69,7%. Quando os harnesses otimizados foram avaliados em tarefas separadas das utilizadas durante a otimização, o ganho médio ficou em apenas 0,6 ponto percentual, indicando risco de sobreajuste ao benchmark. (arXiv)

Em outras palavras: harness também precisa de engenharia, avaliação e manutenção. Um conjunto crescente de regras inventadas a partir de poucos erros pode engessar modelos mais capazes ou ensinar atalhos que não se generalizam.

Afinal, qual tem maior relevância?

A resposta depende do gargalo.

Quando o agente não consegue formular a solução, mesmo tendo acesso ao contexto correto, às ferramentas necessárias e a resultados verificáveis, o gargalo provavelmente está no modelo.

Quando o agente conhece a solução, mas busca os arquivos errados, perde informações, usa mal ferramentas, repete ações, interrompe o trabalho cedo demais ou entrega sem validar, o gargalo provavelmente está no harness.

Quando qualidade, custo, latência, segurança e esforço humano precisam ser considerados simultaneamente, a unidade correta de decisão não é o modelo. É o par modelo–harness.

Uma formulação prática é:

O modelo define a fronteira de capacidade. O harness define o ponto de operação dentro dessa fronteira.

Isso explica por que um modelo menor, em uma tarefa restrita e com ferramentas bem projetadas, pode superar um modelo maior executado de maneira ingênua. Mas também explica por que melhorar indefinidamente o harness encontra um teto: em algum momento, a limitação passa a ser o raciocínio do modelo.

O componente de maior alavancagem: feedback verificável

Dentro do harness, o elemento de maior impacto costuma ser o ciclo de feedback verificável.

Não basta pedir que o modelo “revise com atenção”. É melhor fornecer um mecanismo externo que determine se a ação realmente produziu o resultado esperado:

  • testes automatizados para um agente de código;
  • consulta ao banco de dados para confirmar que uma reserva foi criada;
  • validação de esquema para dados estruturados;
  • navegador automatizado para testar uma interface;
  • checagem de fontes e citações para um agente de pesquisa;
  • aprovação humana para ações financeiras ou irreversíveis.

A distinção fundamental é entre o que o agente declara ter feito e o estado real do ambiente. A Anthropic recomenda que avaliações de agentes considerem esse estado final, além da transcrição produzida pelo modelo. Já a OpenAI descreve ambientes, ferramentas de observabilidade, testes e ciclos de feedback como parte central da engenharia necessária para agentes trabalharem de maneira confiável por longos períodos. (Anthropic)

É o feedback que transforma uma geração probabilística em um processo iterativo: tentar, observar, corrigir e verificar.

Como aplicar isso na prática

1. Comece pela tarefa, não pelo ranking de modelos

Construa uma suíte de avaliação com exemplos reais do seu domínio. Defina o que significa sucesso, quais erros são inaceitáveis e quanto podem custar latência, tokens e intervenção humana.

2. Crie primeiro o harness mais simples possível

Teste uma chamada direta. Depois, adicione contexto recuperado, ferramentas ou um workflow determinístico. Só introduza autonomia, múltiplos agentes ou memória persistente quando os erros demonstrarem essa necessidade.

3. Separe os experimentos

Para comparar modelos, mantenha prompt, ferramentas, orçamento, contexto e critérios de parada fixos. Para comparar harnesses, mantenha o modelo e suas configurações fixos. Sem esse controle, qualquer melhoria fica difícil de atribuir.

4. Analise trajetórias, não apenas respostas finais

Registre chamadas ao modelo, uso de ferramentas, consumo de tokens, tentativas, erros e estado final do ambiente. Pergunte onde ocorreu a primeira decisão incorreta. Frequentemente, o erro final é apenas consequência de contexto ruim ou feedback incompleto em uma etapa anterior.

5. Escolha o sistema pela fronteira qualidade–custo–risco

O melhor sistema não é necessariamente o de maior taxa de acerto. Pode ser aquele que atinge o nível de qualidade necessário com menor custo, menor latência e menor necessidade de supervisão. Em produção, versão do modelo, prompt, ferramentas, políticas, memória e avaliadores devem ser tratados como um único artefato implantável.

Conclusão

Ainda precisamos de modelos melhores. Eles continuam elevando o teto de raciocínio, planejamento, compreensão e geração. Ignorar o modelo seria tão equivocado quanto imaginar que um motor fraco pode vencer apenas com boa aerodinâmica.

Mas também não é mais tecnicamente correto avaliar um agente apenas pelo modelo que aparece em sua página comercial.

As evidências mostram que trocar o harness pode produzir variações de desempenho comparáveis às de uma troca de modelo. Além disso, o harness pode dominar custos, latência, padrões de falha, segurança e necessidade de supervisão — dimensões que determinam se um protótipo realmente pode entrar em produção.

A decisão madura não é “modelo ou harness”. É:

Qual combinação de modelo, contexto, ferramentas, controle e feedback resolve esta tarefa de forma correta, verificável e economicamente sustentável?

O modelo fornece inteligência. O harness transforma essa inteligência em trabalho. E as avaliações mostram se o conjunto realmente funciona.

Referências

Claw-SWE-Bench: A Benchmark for Evaluating OpenClaw-style Agent Harnesses on Coding Tasks — Mengyu Zheng e colaboradores, arXiv, 2026. Utilizado para comparar, sob condições controladas, a variação causada pela troca de modelos e pela troca de harnesses. (arXiv)

The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation — Naman Vats e Oleg Golev, arXiv, 2026. Base para a discussão sobre custo por tarefa resolvida, latência e padrões de falha específicos de cada harness. (arXiv)

SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering — John Yang e colaboradores, arXiv, 2024. Utilizado para explicar como interfaces desenhadas para agentes influenciam navegação, edição e validação de código. (arXiv)

Agentless: Demystifying LLM-based Software Engineering Agents — Chunqiu Steven Xia, Yinlin Deng, Soren Dunn e Lingming Zhang, arXiv, 2024. Utilizado como evidência de que workflows simples e estruturados podem competir com agentes complexos. (arXiv)

Meta-Harness: End-to-End Optimization of Model Harnesses — Yoonho Lee e colaboradores, Stanford, MIT e KRAFTON, arXiv, 2026. Referência sobre otimização automática de contexto, memória e código do harness, incluindo ganhos de desempenho e eficiência. (arXiv)

Rethinking the Evaluation of Harness Evolution for Agents — Yike Wang e colaboradores, Allen Institute for AI e University of Washington, arXiv, 2026. Utilizado para apresentar riscos de sobreajuste, feedback autorreferente e degradação provocada por alterações inadequadas no harness. (arXiv)

SWE-bench Verified — Bash Only: Comparing Language Models — SWE-bench. Utilizado como exemplo de comparação entre modelos com um harness fixo. (Swebench)

Harness engineering: leveraging Codex in an agent-first world — Ryan Lopopolo, OpenAI, 2026. Utilizado para discutir ambientes legíveis para agentes, organização de contexto, observabilidade e ciclos de feedback. (OpenAI)

Building effective agents — Anthropic, 2024. Utilizado para fundamentar a recomendação de começar com padrões simples e acrescentar complexidade apenas quando necessária. (Anthropic)

Demystifying evals for AI agents e Scaling Managed Agents: Decoupling the brain from the hands — Anthropic, 2026. Utilizados para definir agent harness, explicar avaliações baseadas no estado real do ambiente e demonstrar como premissas do harness podem ficar obsoletas conforme os modelos evoluem. (Anthropic)

Top comments (0)