O custo oculto de deixar agentes rodando

A economia dos agentes de código com IA muda quando eles deixam de responder a perguntas isoladas e passam a trabalhar por conta própria. Uma previsão única é barata. Uma execução longa e não supervisionada não é: etapas de raciocínio se acumulam sobre chamadas de ferramentas, que se acumulam sobre ciclos de feedback, e a conta de tokens cresce a cada ciclo. Pesquisadores da Nvidia publicaram um artigo descrevendo um sistema que ataca essa conta por um ângulo inesperado: não tornando o modelo subjacente mais barato de executar, mas reescrevendo o arcabouço que o cerca.

Segundo os pesquisadores, seu método, chamado SoL-Pi, reduz o consumo de tokens em quase metade, mantendo o desempenho praticamente inalterado. O trabalho foi noticiado pelo The Decoder, que observa que o sistema tem como alvo a camada de controle conhecida como harness, e não o modelo em si.

O que o harness realmente faz

O harness é a camada de software que fica entre um modelo e o ambiente em que ele opera. Ele mostra ao agente em que estado ele está, decide como as ações são executadas e determina qual feedback retorna ao modelo depois. Produtos conhecidos como Codex, Claude Code e OpenClaw dependem de harnesses desse tipo para transformar um modelo de linguagem em algo capaz de editar arquivos, rodar testes e iterar.

Como essa camada governa boa parte do ciclo, ela tem um efeito desproporcional sobre o custo. Cada chamada de ferramenta redundante, cada janela de contexto superdimensionada, cada etapa de verificação que dispara tarde demais adiciona tokens que não eram estritamente necessários. Até agora, a maior parte do trabalho de eficiência se concentrou em outros pontos: reduzir o preço de um único token por meio de kernels de atenção mais rápidos e infraestrutura de serving, comprimir modelos via quantização ou encaminhar trabalho para modelos menores e mais baratos.

Por que a otimização do harness é difícil

Ajustar o harness manualmente é difícil porque suas responsabilidades estão intimamente entrelaçadas. Uso de ferramentas, gerenciamento de contexto, rotinas de verificação e lógica de aborto interagem entre si. Uma mudança que reduz tokens em uma etapa pode introduzir falhas em outro lugar, ou simplesmente deslocar o custo para uma fase posterior da execução, onde é mais difícil de enxergar.

Diagrama do loop de auto-pesquisa do SoL-Pi mostrando ambientes de pesquisa, uma IA de pesquisa, um banco de ideias e quatro mecanismos mantidos, ao lado de gráficos de barras comparando pontuação e custos de API para Codex, Claude Code, Pi e SoL-Pi no EdgeBench.
Uma IA de pesquisa analisa traces de agentes, propõe mudanças no harness e mantém apenas as que preservam o desempenho enquanto cortam custos. O SoL-Pi economiza 50% em comparação ao Codex e 54,3% em comparação ao Claude Code no EdgeBench. | Imagem: Nvidia

Na prática, engenheiros leem longos traces de execução, identificam padrões de falha recorrentes e traduzem essas observações em mudanças de código. É um trabalho lento e manual, que depende de alguém notar o mesmo erro pela décima vez.

Como o SoL-Pi automatiza a busca

O SoL-Pi pega esse loop humano e o automatiza. Um agente de pesquisa observa os traces produzidos por outro agente, propõe modificações no harness e então testa essas propostas em ambientes preparados. As mudanças candidatas passam por verificações de capacidade e de eficiência, e apenas as variantes que mantêm o desempenho estável enquanto cortam custo são mantidas.

Os autores descrevem a abordagem como baseada em autoaperfeiçoamento recursivo: um sistema de IA melhora efetivamente as condições de operação de outro. Um detalhe importante é que a avaliação usada para julgar o resultado final acontece somente depois que o harness foi congelado, e essa avaliação held-out não realimenta a busca. Essa separação importa, porque limita o quanto o processo de otimização pode se ajustar aos testes que eventualmente enfrentará.

A escala do experimento

A busca foi ampla. Em 535 ambientes executáveis, o SoL-Pi explorou 152 direções distintas. A mistura de tarefas incluiu:

  • 495 tarefas construídas a partir de pares de issues e pull requests do GitHub
  • 40 casos de teste sintéticos projetados para a avaliação
  • Mais de 3.000 execuções no total
  • Mais de 60.000 interações entre agente e ambiente

Os pesquisadores apresentam esse volume como evidência de quão amplamente o sistema buscou, mas também alertam que buscar mais não produz automaticamente melhores resultados. A amplitude aumenta a chance de encontrar uma configuração de harness útil, mas não a garante.

As economias medidas

Os números principais são substanciais. No EdgeBench, o SoL-Pi economizou 50% dos tokens em comparação ao Codex e 54,3% em comparação ao Claude Code, segundo os pesquisadores, enquanto o desempenho permaneceu aproximadamente no mesmo nível. O artigo enquadra a redução geral de tokens como de até 49%, com pouca mudança na capacidade de realizar tarefas.

Fluxograma do pipeline de busca, desde rollouts de trajetória passando por análise map-reduce, proposta de mecanismo, implementação de candidato, revisão independente e validação de desenvolvimento até uma avaliação held-out separada.
A avaliação held-out acontece somente depois que o harness é congelado e não realimenta o processo de busca. | Imagem: Nvidia

Esse enquadramento é importante. Cortar o uso de tokens é fácil se o agente puder falhar com mais frequência, pular a verificação ou abortar cedo em tarefas legítimas. A alegação aqui é diferente: as economias vêm de uma lógica de controle mais enxuta, e não de um comportamento degradado, e é por isso que as verificações de capacidade ficam ao lado das verificações de eficiência no processo de seleção.

A questão do overfitting

Há um risco conhecido nessa linha de pesquisa. Trabalhos anteriores mostraram que harnesses otimizados automaticamente tendem a sofrer overfitting, tornando-se altamente eficientes nos traces para os quais foram ajustados, mas generalizando mal para novas situações. Os autores da Nvidia parecem estar cientes disso, e é por isso que a avaliação final é conduzida em um harness congelado e isolada do loop de busca.

Mesmo assim, a ressalva vale ser levada adiante. Os ambientes usados aqui, embora numerosos, ainda são uma amostra finita da realidade bagunçada que os agentes de código encontram. Se um harness refinado em 535 ambientes se sustenta diante de um repositório genuinamente desconhecido, de uma suíte de testes instável ou de um relatório de bug ambíguo, continua sendo uma questão em aberto que só uma implantação mais ampla responderá.

O que isso significa para a economia dos agentes

Se os resultados se mantiverem fora do laboratório, as implicações são práticas, e não filosóficas. Equipes que rodam agentes de código autônomos pagam por token, e as longas sessões não supervisionadas que tornam os agentes úteis são justamente as que os tornam caros. Extrair quase metade dos tokens de um fluxo de trabalho sem perder capacidade muda quantas dessas sessões um orçamento consegue sustentar.

O trabalho também sugere uma mudança em onde vale a pena gastar esforço de otimização. A eficiência no nível do modelo tem sido o alvo padrão por anos, e certamente ainda importa. Mas é no harness que se tomam as decisões sobre contexto, verificação e novas tentativas e, como este artigo ilustra, é nessas decisões que uma grande parte do desperdício se acumula. A lacuna entre o modelo e o ambiente pode ser o lugar mais produtivo que resta para se investigar.

Este artigo é baseado em reportagem do The Decoder. Leia o artigo original.

Originally published on the-decoder.com