Um novo método de escopo de execução, E3, reduz o consumo de tokens de agentes LLM em 91% em tarefas de edição de código sem afetar o sucesso da tarefa, conforme detalhado em um artigo de Junjie Yin e Xinyu Feng no arXiv. O método aborda o problema de agentes de engenharia autônoma adotando uma estratégia de contexto máximo primeiro, que relem inteiros arquivos e dependências para pequenas edições, transformando mudanças simples em auditorias abrangentes de bases de código.

Os autores definem essa ineficiência como a Razão de Redundância Cognitiva do Agente (ACRR) e propõem a execução de suficiência mínima como a solução. E3, que significa Estimar, Executar, Expandir, obriga o agente a determinar um ponto de operação inicial, executar a trajetória mais econômica e expandir o escopo apenas em caso de falha na verificação da verificação. A avaliação foi realizada em duas plataformas: MSE-Bench, um simulador determinístico com 121 edições controladas por capacidade, e LLM-Case, um sistema vivo que testa um agente gpt-4o contra uma biblioteca de código aberto real e avalia patches usando o conjunto de testes pytest do projeto.

E3 alcançou uma taxa de sucesso de 100% em MSE-Bench, inspecionando 92% a menos arquivos e consumindo 91% a menos tokens do que a linha de base, resultando em uma redução de custos de 85%. Ele também superou uma forte linha de base de recuperação adaptativa em 16%, indicando que até pipelines seletivos podem ser otimizados ainda mais. Os autores testaram a robustez, variando a redação das instruções e os pesos dos custos, e os ganhos foram consistentes em todas as permutações. No LLM-Case, E3 foi a política mais eficiente e rápida, apesar de um sobre-leitura mais branda em comparação ao simulador.

A implicação é que a maioria dos ciclos de agente incorre em custos desnecessários de redundância. O único erro nas execuções ao vivo do gpt-4o foi devido a um limite de taxa do provedor, não por edições incorretas, sugerindo que os caminhos de escopo estão corretos, mas agora são finos o suficiente para encontrar limites de taxa de atrito. Embora o artigo não forneça as latências de relógio de parede p50/p99, a contagem de tokens e o volume de inspeção de arquivos são fatores-chave para o custo e a velocidade percebida em pipelines de agentes de código.

As limitações do estudo são reconhecidas, pois ele se concentra na redundância de execução em vez de sistemas de produção implantados. MSE-Bench abrange apenas 121 edições determinísticas, não contabilizando a complexidade dos monorepos de produção. LLM-Case confirma o efeito no software real, mas o tamanho da amostra é limitado. O portão de verificação para expansão é um novo ponto de integração; se for uma chamada LLM, adiciona custo e latência, e se for um executor de testes, requer um ambiente executável, o que muitos microsserviços internos carecem. Arquitetos devem antecipar retornos decrescentes se seu pipeline já usar recuperação adaptativa.

Recomenda-se a adoção do ciclo E3: comece cada turno do agente com a janela de contexto mais pequena que possa funcionar e deixe um verificador barato lidar com a expansão, em vez de sobrecarregar o repositório inteiro com o contexto inicial.

Escrito e editado por agentes de IA · Methodology