Agente risca sozinho respostas antigas de ferramentas e corta os tokens de entrada pela metade

Um agente que circula entre ferramentas logo acumula um histórico enorme: logs, dumps, saídas de comandos, conteúdo de arquivos. Em cada resposta dessas, a parte útil costuma ser uma ordem de grandeza menor que a resposta inteira, mas tudo continua sendo enviado em cada requisição seguinte. Os autores de um preprint no arXiv propõem entregar a limpeza ao próprio modelo. No caso de pesquisa, o prompt final com essa abordagem somou 231 951 tokens, contra 912 492 com o armazenamento convencional do histórico. O volume total de entrada caiu 50%, e a estimativa de custo da API ficou em $1,28–1,44, em vez de cerca de $4,38.

Como funciona o esquecimento

O mecanismo é simples. O modelo em operação escolhe resultados de chamadas de ferramentas obtidos antes e substitui cada um por uma nota curta, exatamente na posição original dentro da conversa. A ordem das mensagens e a estrutura do histórico permanecem intactas. O original exato não é apagado: vai para um arquivo, de onde pode ser recuperado por um comando explícito, caso volte a ser necessário.

A abordagem foi implementada como um harness em Python, que dá ao agente duas ações: arquivamento em lote e restauração. Não é preciso fazer fine-tuning do modelo para a tarefa. Também há uma proteção: as instruções do usuário e as mensagens do assistente não podem ser alvo dessas operações. Só é possível esquecer observações, e nunca o que a pessoa pediu nem o que o próprio agente disse sobre si.

O que os experimentos mostraram

O caso principal é de pesquisa: depuração com OpenTelemetry, seguida de uma tarefa de implementação sem relação com ela. É justamente o tipo de trajetória ruidosa em que saídas volumosas são úteis por alguns passos e depois só atrapalham.

• Prompt final: 231 951 tokens, contra 912 492 com o histórico preservado.
• Tokens de entrada somados: 50% a menos.
• Estimativa de custo da API: $1,28–1,44, contra cerca de $4,38.
• Teste comportamental: as duas variantes passaram no oráculo principal de dois casos.
• Avaliação de follow-up: nenhuma das variantes a satisfez por completo.
• Custos: mais requisições e 17% mais tempo de execução.

Economizar tokens não significa economizar em tudo. O agente gasta passos no próprio processo de curadoria, e isso aparece no tempo de execução.

Onde o método não funcionou

Os autores apresentam contraexemplos com franqueza. Em um par de contraste ligado ao desenvolvimento de aplicativo, não houve economia nem de contexto nem de custo. Um experimento anterior, com continuação de sessão, mostrou qualidade menor na avaliação manual, embora o contexto tivesse diminuído. A amostra é pequena, os casos são exploratórios e não há estatística aqui. O trabalho não prova que a técnica serve para qualquer situação. Ele mostra que o ganho depende muito do perfil da carga, e os autores apontam essa dependência como o fator central no gerenciamento reversível de contexto.

O que testar na prática

Se o seu agente tem sessões longas de depuração, análise de logs ou busca em grandes volumes de resultados, a ideia merece um experimento. Comece pelas observações fáceis de restaurar: saída de testes, traces, dumps. Deixe as instruções e as falas do assistente intactas, como no esquema original.

Meça não só os tokens, mas também o número de requisições, o tempo e a qualidade do resultado nas suas tarefas, porque a economia pode ser apenas aparente. Em tarefas nas quais cada trecho de código ou de configuração volta repetidamente, o arquivamento pode não render nada. A reversibilidade funciona como um seguro, e não como uma garantia: se o agente esquecer o que não devia, ele precisará perceber isso e pedir o conteúdo de volta.