🤖 AI

HarnessOpt-Bench: Evaluating LLMs at Harness Optimization

Este artigo apresenta o HarnessOpt-Bench, um novo benchmark projetado para avaliar a capacidade de LLMs de fronteira de otimizar iterativamente harnesses agênticos (incluindo prompts, ferramentas e código de orquestração) sob restrições de recursos, demonstrando que essa capacidade de otimização é uma habilidade distinta e mensurável com margem significativa para melhoria.

Autores originais: Varun Ursekar, Apaar Shanker, Yash Maurya, Shehab Yasser, Vijay S. Kalmath, Veronica Chatrath, Yuan Xue

Publicado 2026-08-07

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Varun Ursekar, Apaar Shanker, Yash Maurya, Shehab Yasser, Vijay S. Kalmath, Veronica Chatrath, Yuan Xue

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você tenha um cérebro de robô brilhante e superinteligente. Ele consegue escrever código, resolver problemas matemáticos e responder perguntas. Mas esse cérebro não funciona no vácuo; ele precisa de um "harness" (um suporte ou estrutura). Pense no harness como a armadura do robô, seu manual de instruções e seu painel de controle, tudo em um só. É o código que diz ao cérebro como usar suas ferramentas, o que lembrar e como se comunicar com o mundo exterior. Assim como um carro de corrida precisa de um ótimo piloto e de um motor bem ajustado para vencer, uma IA inteligente precisa de um cérebro inteligente e de um ótimo harness para performar bem. Às vezes, o mesmo cérebro pode ser um gênio em um traje e um iniciante desajeitado em outro.

Aqui está a grande questão: Podemos ensinar uma IA a consertar seu próprio traje? Uma IA pode olhar para o seu próprio harness, perceber que ele é desajeitado e reescrever o código para torná-la mais inteligente? Isso é chamado de "otimização de harness". É um pouco como pedir a um chef não apenas para cozinhar uma refeição, mas também para redesenhar a cozinha, afiar as facas e reescrever o livro de receitas enquanto ele está cozinhando, tudo isso sem saber exatamente como os juízes irão degustar o prato final até o último momento. Este é um desafio massivo porque consertar o traje é caro e complicado; você tem que adivinhar o que funciona sem ver a pontuação final, e você tem que fazer isso antes de esgotar sua "energia" (ou, neste caso, tempo de computação e dinheiro).

É exatamente isso que os pesquisadores da Scale AI se propuseram a testar com um novo experimento chamado HarnessOpt-Bench. Eles construíram um playground especial e seguro onde diferentes modelos de IA de alto nível atuam como "otimizadores". O trabalho deles? Pegar um agente de IA básico e levemente desajeitado (a "semente"), ler seu código e tentar melhorá-lo. A pegadinha é que o otimizador tem um orçamento estrito: ele só pode executar um número limitado de testes para ver se suas mudanças funcionam. Ele recebe dicas de algumas execuções de teste (desenvolvimento e validação), mas a pontuação real e final é escondida até que ele envie sua melhor versão.

Os pesquisadores queriam ver se esses modelos de IA poderiam realmente melhorar nessa tarefa. Eles realizaram 111 experimentos diferentes usando cinco dos modelos de IA mais inteligentes disponíveis hoje, testando-os de duas maneiras: uma vez usando um "kit de ferramentas" padrão e compartilhado (um harness de codificação comum) e outra usando seus próprios kits de ferramentas nativos e integrados. Eles mediram o sucesso pelo quanto a IA melhorou o desempenho do agente em comparação com a versão original e desajeitada.

Aqui está o que eles descobriram, e é um pouco surpreendente. Primeiro, os próprios modelos de IA importam muito mais do que o kit de ferramentas que estão usando. A diferença de desempenho entre a IA mais inteligente e a menos inteligente foi enorme — quase duas vezes maior do que a diferença causada pela mudança do kit de ferramentas. Isso sugere que o "cérebro" é a verdadeira estrela, não apenas o "traje" que ele está vestindo.

Segundo, ter um kit de ferramentas nativo e sofisticado não garantia a vitória. Você poderia pensar que uma IA teria o melhor desempenho com suas próprias ferramentas personalizadas, mas os resultados foram mistos. Às vezes, o kit de ferramentas nativo ajudava, às vezes não, e às vezes o kit de ferramentas padrão era na verdade melhor. Não houve uma "vantagem de casa" consistente.

Terceiro, a maneira como as IAs buscavam soluções importava. Aquelas que tentaram mexer em mais partes do código (como os prompts, a memória, as regras de tentativa de novo e as ferramentas) tenderam a obter melhores resultados. No entanto, as IAs não dedicaram muito tempo à leitura dos relatórios detalhados de falhas (rastros/traces) do que deu errado. Elas focaram principalmente nas pontuações finais. Isso sugere que, para essas tarefas, olhar para o quadro geral era mais útil do que obcecar por cada pequeno erro.

Finalmente, as IAs eram frequentemente otimistas demais. As pontuações que elas viam durante a busca (nos testes de "prática") eram geralmente mais altas do que as pontuações que obtiveram no teste final e oculto. Isso significa que as IAs às vezes pensavam que haviam encontrado uma solução perfeita, mas quando os juízes reais viram, não era tão bom assim.

Em resumo, este artigo mostra que a otimização de harness é uma habilidade real e mensurável que os modelos de IA de fronteira possuem, mas eles ainda estão aprendendo a fazer isso de forma consistente. Os melhores modelos podem melhorar significamente o desempenho de um agente, mas ainda não são perfeitos. Eles precisam aprender a ser menos excessivamente confiantes e talvez ler os relatórios de falhas com um pouco mais de atenção. O aprendizado principal? Estamos nos movendo em direção a um futuro onde a IA não apenas realiza tarefas, mas também aprende a construir versões melhores de si mesma, mas ainda temos um longo caminho a percorrer antes de podermos fazer isso de forma confiável sem ajuda humana.

Resumo Técnico: HarnessOpt-Bench

Declaração do Problema

À medida que os Grandes Modelos de Linguagem (LLMs) são cada vez mais implementados em sistemas agênticos, seu desempenho depende não apenas dos pesos do modelo, mas também do "harness" (suporte/estrutura) — os prompts, ferramentas, fluxo de controle, memória e código de orquestração circundantes. Embora a otimização de harness (a melhoria iterativa e guiada por avaliação do suporte) seja uma rota crítica para construir sistemas de IA capazes, a comunidade carece de um protocolo comum para medir o quão bem os LLMs de fronteira realizam essa tarefa por si mesmos.

As avaliações existentes são frequentemente confundidas por variados agentes alvo, sementes (seeds), orçamentos e protocolos de pontuação, tornando difícil distinguir se os ganhos de desempenho decorrem do modelo otimizador, do harness de codificação que ele utiliza ou da configuração específica da tarefa. Além disso, a otimização de harness difere dos benchmarks de codificação padrão porque a avaliação é cara e estocástica; requer diagnosticar falhas a partir de evidências incompletas, gerenciar um orçamento de avaliação limitado e separar a melhoria real do ruído, em vez de simplesmente produzir um único passo de código correto.

Metodologia: HARNESSOPT-BENCH

Os autores introduzem o HARNESSOPT-BENCH, um benchmark projetado para avaliar a otimização de harness de ponta a ponta sob condições de avaliação caras e estocásticas. O framework impõe um ambiente controlado e reprodutível com os seguintes componentes principais:

1. O Problema de Otimização

Harness Candidato ( $H$ ): Uma base de código executável contendo prompts, ferramentas e fluxo de controle. O otimizador pode editar, adicionar ou excluir arquivos sujeito a uma interface de execução fixa e caminhos imutáveis.
Invariantes ( $\theta$ ): Os modelos, o ambiente e o verificador são fixos. O otimizador não pode alterar o modelo alvo ou a lógica de avaliação, apenas o código do harness.
Orçamento ( $B$ ): A busca é restringida por um orçamento fixo de chamadas de avaliação (limitado a 100 por partição) e o total de tokens do modelo alvo. O otimizador deve decidir o que avaliar e com qual fidelidade.
Política de Divulgação:
- Desenvolvimento ( $D_{dev}$ ): Revela entradas de casos, resultados por caso e traços de execução para apoiar o diagnóstico.
- Validação ( $D_{val}$ ): Revela apenas pontuações agregadas para apoiar a seleção.
- Teste ( $D_{test}$ ): Permanece completamente inacessível durante o processo de busca.

2. Ambiente de Execução Confiável

Para evitar o overfitting e garantir a equidade, o benchmark é executado dentro de um ambiente de execução confiável (baseado em VERO [23]):

Isolamento: Cada execução do agente alvo ocorre em um sandbox efêmero e sem privilégios.
Controle de Acesso: O otimizador pode escrever apenas o harness do agente alvo. Ele pode ler traços de desenvolvimento e métricas de validação, mas não pode acessar a partição de teste ou modificar o verificador.
Auditoria: Cada versão candidata é preservada para auditoria, e o uso de recursos é mensurado.

3. Métrica de Avaliação

A métrica primária é o Ganho Normalizado ( $g$ ), definido como a melhoria do candidato nomeado sobre a semente (seed) fixa na partição de teste retida, normalizada pela margem disponível:
$g = \frac{E_\theta(H^+) - E_\theta(H_0)}{1 - E_\theta(H_0)}$
onde $H_0$ é o harness da semente e $E_\theta$ é a pontuação esperada. Valores negativos indicam que o candidato teve um desempenho inferior à semente.

4. Design Experimental

Tarefas: Quatro tarefas downstream (OfficeQA, BrowseComp-Plus, Terminal-Bench, GAIA) com sementes fixas. Três sementes são competentes, porém básicas; uma (GAIA) é um stub não funcional.
Otimizadores: Cinco LLMs de fronteira (Claude Opus-5, Claude Sonnet-5, GPT-5.6-Sol, GPT-5.6-Terra, Kimi-K3) foram avaliados.
Configurações de Harness: Cada modelo foi testado sob duas condições:
1. Harness Compartilhado: Todos os modelos usam um harness de codificação comum (opencode).
2. Harness Nativo: Modelos usam suas respectivas ferramentas de codificação nativas (ex: claude-code, codex, kimi-cli).
Protocolo: Cada configuração rodou duas vezes. Os resultados são calculados pela média de $K=3$ rodadas de avaliação independentes por caso de teste para mitigar o ruído estocástico.

Principais Contribuições

Um Benchmark Controlado: O HARNESSOPT-BENCH desacopla o modelo otimizador do harness de codificação e da tarefa alvo, permitindo o isolamento da capacidade do modelo na otimização de harness.
Protocolo Confiável: A introdução de um limite de execução confiável que impõe orçamentos, bloqueia o acesso a dados retidos e preserva candidatos para auditoria, garantindo que as melhorias reflitam a generalização em vez do overfitting aos scores visíveis.
Avaliação Empírica: Uma avaliação abrangente de 5 modelos de fronteira através de 4 tarefas e 111 execuções pontuadas, comparando harnesses compartilhados vs. nativos.
Análise do Comportamento de Busca: Trajetórias de busca instrumentadas para correlacionar comportamentos específicos do otimizador (ex: amplitude de intervenção, leitura de traços) com o ganho de desempenho final.

Resultados

1. Sensibilidade Modelo vs. Harness

A Escolha do Modelo Domina: A escolha do modelo otimizador tem um efeito significativamente maior no desempenho do que a escolha do harness de codificação. Alterar o modelo otimizador moveu o ganho normalizado em uma média de 0,142, enquanto alterar o harness moveu-o em 0,079.
Sem Vantagem Nativa Consistente: Harnesses nativos (ex: claude-code para modelos Claude) não proporcionaram uma vantagem consistente sobre o harness compartilhado. Em 11 de 20 pares de modelo-tarefa, o harness compartilhado superou o nativo; em 9, o nativo venceu. A diferença agregada foi próxima de zero, sugerindo que a sensibilidade ao harness é heterogênea em vez de uniforme.

2. Lacunas de Capacidade e Progressão

Lançamentos de Modelos: O benchmark distingue com sucesso entre lançamentos sucessivos de modelos. No OfficeQA, os lançamentos do GPT-5.6 mostraram aumentos monotônicos de ganho, enquanto os lançamentos do Claude Opus mostraram uma dispersão não monotônica, mas significativa.
Variância de Tarefa: Os ganhos variam substancialmente entre as tarefas. As configurações mais fortes capturaram aproximadamente dois terços da margem disponível no OfficeQA, mas permaneceram sem resolução a partir do zero no BrowseComp-Plus e Terminal-Bench.

3. Insights do Comportamento de Busca

Amplitude de Intervenção: Existe uma forte correlação positiva ( $\rho$ de +0,34 a +0,88) entre a fração de "alavancas" do harness (ex: prompt, política de tentativa, esquema de ferramenta) tocadas durante a busca e o ganho normalizado final. Uma exploração mais ampla está associada a melhores resultados.
Leitura de Traços: Contrariando a intuição, a inspeção detalhada de traços de falha raramente foi usada (apenas 16 vezes em 111 células) e foi negativamente associada ao ganho. Os otimizadores confiaram principalmente em resumos de pontuação por caso.
Restrições de Orçamento: A permissão de passagens de casos (4 passagens completas por partição) foi a restrição limitante para a maioria dos otimizadores, não o limite de chamadas de avaliação.
Overfitting: Os scores de validação visíveis foram frequentemente otimistas em comparação com os scores finais de teste retidos, confirmando a necessidade da partição retida.

Significância e Alegações

O artigo estabelece a otimização de harness como uma capacidade mensurável e discriminativa para LLMs de fronteira. Os autores alegam que:

Os modelos atuais podem realizar a otimização de harness, mas seu desempenho é irregular e altamente dependente da tarefa específica e do regime de sementes.
A capacidade de otimizar um agente é distinta da capacidade de escrever código; a primeira exige raciocinar sobre sistemas estocásticos e gerenciar recursos limitados.
HARNESSOPT-BENCH transforma a engenharia de harness de uma demonstração específica de um otimizador em um alvo de avaliação reprodutível. Isso permite que a comunidade meça e desenvolva sistemas que possam tornar outros agentes confiavelmente melhores.

Os autores mantêm modéstia em suas alegações, observando que o benchmark é "resistente a hacks, mas não à prova de hacks" e que os resultados são específicos para a distribuição atual de tarefas e sementes. Eles enfatizam que a próxima fronteira não é apenas agentes melhores, mas modelos que possam tornar agentes confiavelmente melhores.