Executar mais passos não garante aproximação da solução. Controle de custo e de progresso passa por detectar quando a trajetória estagnou.
Um relato circulou no TLDR descrevendo execuções em que o agente repetiu a mesma consulta SQL bem-sucedida centenas de vezes — 113 em um caso, 254 em outro. Sem o texto completo, o episódio serve só como ilustração: atividade intensa, resultado que não muda. O ponto útil não é a frequência desse bug em produção; é a diferença entre "ainda está rodando" e "ainda está progredindo".
O paper TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents (Li et al., UC Berkeley / Microsoft Research / Microsoft Security, arXiv 2610.22732) trata exatamente desse tipo de desperdício em sequências reais de tarefas. Em vez de avaliar o agente em tarefas isoladas, os autores olham repositórios onde o mesmo ambiente e os mesmos padrões se repetem ao longo de várias sessões. O custo recorrente aparece em três frentes: rediscoberta de fatos do ambiente (comando que funciona aqui, variável obrigatória, ordem de build), ferramentas que permanecem irrelevantes e loops de falha improdutivos — o agente insiste no mesmo caminho sem alterar o estado útil do problema.
TokenEconomizer atua como controlador externo, sem alterar pesos do modelo nem o código do loop do agente. Três mecanismos: injetar micro-skills aprendidas de sessões anteriores no mesmo repositório; podar tools que consistentemente não ajudam; intervir quando a trajetória entra em loop de falha. Em Claude Code, Codex e GitHub Copilot CLI com modelos frontier, o método reportou redução média de custo de 18,4-30,9% em SWE-Bench, com Pass@1 comparável ou melhor em 4 de 5 combinações agente-modelo. A economia apareceu em todos os repositórios testados; em web e auditoria de segurança, a faixa foi 6,4-21,2% conforme a estrutura das tarefas.
O desenho importa para quem opera agentes no dia a dia. Limite de tokens ou de passos corta custo de forma cega e pode interromper trabalho que ainda avançava. Intervir só quando o humano "acha que está travado" depende de atenção intermitente. O que o paper formaliza é política baseada em experiência do próprio repositório: o que já falhou de forma repetida, o que já foi descoberto e não precisa ser redescoberto, quando a sequência de ações deixou de mudar o estado do problema de forma útil.
Progresso, nesse sentido, não é número de tool calls nem de linhas geradas. É mudança observável em direção ao objetivo — teste que passa, erro que some, arquivo que deixa de ser reescrito em loop, consulta cujo resultado informa a próxima decisão em vez de ser reexecutada idêntica. Sem um sinal explícito de estagnação (mesmo que imperfecto), o agente pode consumir orçamento enquanto o humano só vê "ainda está trabalhando".
Para times que já medem custo por tarefa, o próximo passo concreto é registrar, por repositório, quantas sessões rediscobrem o mesmo fato operacional e quantas vezes a mesma ação é repetida sem alteração de estado. Aí a decisão de interromper ou redirecionar deixa de ser só feeling no meio do turno.
Leia o artigo mais aprofundado clicando abaixo.
Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon). Aprofunde-se no tema de forma estruturada do contexto à governança de agentes consultando a série clicando na imagem abaixo:
- Cupom de 30% OFF:
LEIA30 - Disponível também no Kindle Unlimited
Referências
- Li et al., TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents, arXiv:2610.22732 (2026) UC Berkeley, Microsoft Research, Microsoft Security.
- Projeto: tokeneconomizer.github.io
Tags
#EngenhariaDeSoftware #IA #AgentesDeCodigo #TokenEconomizer #CustoDeAgentes #SWEBench #SoftwareEngineering #AI #CodeAgents #Progresso
Top comments (1)
Essa é exatamente a pergunta que todo time que constrói agentes eventualmente faz. "Ainda trabalhando" só significa que os tokens estão sendo gerados. Isso não diz nada sobre se o agente está realmente fazendo progresso.
A única maneira de saber é comparar o estado entre os turnos. Se o estado não mudou em N turnos, o agente não está mais "trabalhando", está apenas girando em falso. Você precisa de uma camada de runtime para matá-lo nesse momento exato.