O que acontece quando a conversa com o agente enche a janela?

Quando a conversa se aproxima do limite da janela, o harness faz uma chamada de modelo à parte que transforma os turnos antigos em um resumo, substitui aqueles turnos por ele, mantém os mais recentes literais e continua a tarefa. A sessão não morre e não recomeça. Ela perde detalhe, em silêncio, e segue com um histórico reescrito por um modelo.

Essa operação é o último recurso da gestão de contexto do harness: ela só entra depois que descartar saída de ferramenta antiga já não libera espaço suficiente. A técnica em si é a mesma compactação e sumarização de contexto usada fora de agentes. O que muda no agente é a frequência e o que está em jogo: não é uma conversa que fica vaga, é uma tarefa que muda de rumo.

O efeito colateral aparece antes disso, aliás. O modelo já se perde em conversas longas sem nenhuma compactação envolvida, e a compactação acrescenta uma segunda causa de perda por cima da primeira.

O que acontece, passo a passo

1. O harness cruza o limiar. Perto de 90% de ocupação, dependendo da configuração, com uma folga reservada para a resposta.
2. Escolhe a fatia a compactar. Quase sempre tudo menos os dois ou três turnos mais recentes, que continuam literais.
3. Monta um prompt de resumo. Um prompt fixo, escrito por quem fez a ferramenta, dizendo o que preservar. É o ponto onde a maior parte da qualidade se decide, e você raramente o vê.
4. Chama o modelo. Entrada de 150 mil tokens, saída de alguns milhares. Essa chamada custa mais que qualquer iteração comum da tarefa.
5. Substitui. A fatia antiga sai, o resumo entra no lugar, os turnos recentes ficam onde estavam.
6. Recola o que é literal. Um harness cuidadoso reinjeta certos itens sem passar pelo resumo. É a caixa de baixo da Figura 1.
7. Continua. O modelo recebe a próxima requisição e não tem como saber que houve um corte, a menos que o harness escreva isso no contexto.

O passo 3 merece atenção porque é o único ajustável de fora, quando a ferramenta deixa. Um prompt de resumo razoável pede quatro coisas nomeadamente: o objetivo original, as decisões com o motivo de cada uma, as restrições em texto literal e o estado atual do trabalho, incluindo o que já foi verificado e o que ainda não. Um prompt ruim pede “um resumo da conversa”, e o modelo entrega o que essa frase pede: uma narrativa do que foi conversado, que é a forma mais inútil possível para retomar uma tarefa.

A formulação canônica dessa ideia trata a janela de contexto como memória principal e o armazenamento externo como memória secundária, com o próprio modelo emitindo chamadas de função para mover dados entre os dois níveis e interromper o fluxo quando precisa¹. Vale a distinção: aquela proposta dá ao modelo controle sobre o que sai e o que volta. A compactação automática que a maioria das ferramentas faz é mais simples — o harness decide, o modelo só escreve o resumo.

O que nunca deveria entrar no resumo

Decisão já tomada. “Vamos com Postgres” precisa chegar do outro lado como decisão, não como “houve uma discussão sobre banco de dados”. A segunda forma convida o agente a reabrir a discussão, e reabrir custa iterações.

Restrição dada pelo usuário. “Não mexa em migrations/” tem a forma de uma mensagem de conversa e o peso de uma regra de sistema. Um resumo que a transforma em “o usuário pediu cuidado com migrações” removeu a parte que importava, que era o caminho exato.

Caminho de arquivo, número de linha, nome de função. São a única maneira de voltar ao lugar certo. Resumo tende a substituir por descrição: “o arquivo do serviço de pagamento” em vez de src/billing/charge.py:212. A descrição não abre no editor.

Identificador. Hash de commit, número de issue, id de pedido, chave de erro. Um dígito trocado é pior que a ausência, porque o agente age com confiança em cima do valor errado.

Os quatro têm em comum a natureza literal. Resumo é uma operação semântica, e o que ela preserva bem é significado, não a cadeia de caracteres. Por isso a solução não é escrever um prompt de resumo melhor: é tirar esses itens do caminho do resumo.

Existem três formas de fazer isso, da mais frágil para a mais confiável. A primeira é pedir no prompt de resumo que ele preserve caminhos e identificadores, e ela falha exatamente quando o histórico é grande, que é quando você precisa dela. A intermediária é o harness manter uma lista de itens fixados e recolá-los depois do resumo, sem passar pelo modelo; é o que a caixa de baixo da Figura 1 representa, e funciona bem desde que alguém tenha marcado os itens. A mais forte é gravar fora da janela, num arquivo que o agente relê. Só a terceira sobrevive à sessão inteira cair.

Compactação recursiva

Numa sessão longa, a compactação roda mais de uma vez, e a segunda recebe como entrada a saída da primeira.

A perda não é linear. O que sobrevive a uma compactação já é a parte mais genérica do que existia, então a compactação seguinte trabalha sobre material que tem menos detalhe para perder e perde mesmo assim. Em três passadas, “usar Postgres em vez de MySQL por causa da licença” chega como “backend definido”, que é verdadeiro e inútil.

A ideia de resumir recursivamente não é um defeito de implementação; é uma proposta de pesquisa. Um trabalho de 2023 gerou memória de diálogo de forma recursiva, combinando a memória anterior com o trecho seguinte da conversa, e relatou respostas mais consistentes em conversas longas, tanto em modelos abertos quanto fechados². O que esse trabalho mediu foi consistência de resposta em diálogo. Preservar um caminho de arquivo ou o motivo de uma decisão de arquitetura ao longo de oitenta iterações de código é outro problema, e não é o que ele avaliou.

Por que o resumo perde o que perde

Resumo automático tem um modo de falha conhecido e medido desde antes dos agentes existirem. Uma avaliação humana de larga escala publicada em 2020 analisou vários sistemas neurais de sumarização abstrativa e encontrou quantidade substancial de conteúdo alucinado em todos eles, ou seja, afirmações que não estavam no documento de origem³. Os modelos daquele estudo são anteriores aos LLMs atuais e as taxas envelheceram; a tipologia de falha não. Um resumo pode acrescentar, não só omitir.

Pior: detectar isso é difícil para o próprio modelo. Um benchmark de 2023 testou LLMs na tarefa de julgar se um resumo é factualmente consistente com o texto de origem, em dez domínios, e a maioria dos modelos ficou perto do acaso; o melhor deles ainda apareceu 8% abaixo do desempenho humano estimado⁴. A implicação para o harness é direta: não dá para fechar o ciclo pedindo ao modelo que verifique o próprio resumo. Ele não é bom nisso.

O que os benchmarks de memória longa mostram

Existe um jeito de medir o efeito sem olhar o resumo. Um benchmark de 2024 avaliou assistentes de chat em cinco habilidades de memória de longo prazo (extração de informação, raciocínio entre sessões, raciocínio temporal, atualização de conhecimento e abstenção), com 500 perguntas embutidas em históricos longos, e reportou queda de 30% de acurácia em assistentes comerciais e modelos de contexto longo ao ter que memorizar informação ao longo de interações sustentadas⁵.

O número é de um arranjo específico de perguntas e não é uma taxa de perda de compactação. Serve para calibrar a expectativa: manter informação viva ao longo de uma sessão longa é um problema aberto, não um detalhe de configuração.

A medição equivalente no seu próprio trabalho é barata. Pegue cinco sessões que compactaram, anote as restrições e decisões ditas antes do corte e confira quais delas o agente continuou respeitando depois. Cinco sessões bastam para saber se o seu problema é a compactação ou outra coisa, e é a única evidência que fala das suas tarefas.

Onde a compactação falha

O caso típico tem esta forma. Você pede um ajuste no cálculo de frete e avisa, na segunda mensagem, que o arquivo legacy/frete_v1.py está congelado e não deve ser tocado. Trinta e poucas iterações depois, o agente compacta. O resumo registra “o usuário pediu atenção com o código legado de frete”. Na iteração 40, a correção mais direta passa por editar exatamente aquele arquivo, e o agente edita, porque o que sobrou no contexto era um conselho e não uma proibição. A camada de permissão pergunta, você aprova sem lembrar do que combinou trinta iterações antes, e ninguém no ciclo tinha a informação inteira.

A perda não gera evento. Nenhum log diz “a restrição do usuário saiu”. O sintoma aparece como uma ação que contradiz algo combinado, e a essa altura já não existe o registro para comparar.

O prompt de resumo é genérico. Ele foi escrito para todas as tarefas, então não sabe que num projeto de migração de banco a palavra “licença” é a informação central.

O agente pode compactar no pior momento. A janela enche mais rápido quando a tarefa está mais complexa, ou seja, o corte acontece no ponto de maior densidade de informação.

Compactar não devolve o custo. A chamada de resumo é paga com o histórico inteiro na entrada. Uma compactação de 150 mil tokens custa mais que várias iterações comuns, e uma sessão que compacta três vezes gastou meio milhão de tokens só nisso.

Sessão longa nem sempre é o objetivo. Boa parte do que a compactação existe para salvar não deveria ter entrado na sessão. Duas tarefas independentes na mesma conversa competem pela mesma janela sem nenhum ganho.

Ela joga fora o cache de prompt. A compactação reescreve o meio do prompt, então todo prefixo em cache dali para a frente deixa de casar. A chamada logo depois de uma compactação paga preço cheio num contexto que vinha saindo com desconto havia vinte iterações, e é parte da razão pela qual a fatura sobe num lugar que não parece ter relação com o resumo.

O que fazer

1. Escreva o estado num arquivo antes de precisar. Decisões, restrições, caminhos e próximos passos. É a única cópia que não depende de um resumo ter escolhido guardá-la.
2. Force a compactação no momento que você escolher. Compactar aos 60% com a tarefa em ponto estável é melhor que aos 92% no meio de uma investigação.
3. Abra sessão nova por tarefa. É a medida mais eficaz e a menos usada. A retomada de sessão resolve continuidade sem obrigar a arrastar o histórico inteiro.
4. Trunque saída de ferramenta na origem. A maior parte do que a compactação precisa engolir é saída de comando que nunca deveria ter entrado inteira.
5. Releia o resumo quando ele acontecer. Se a ferramenta mostra o resumo, leia. Trinta segundos ali economizam as iterações que o agente gastaria refazendo o que ficou de fora.
6. Depois de compactar, repita as restrições. Uma linha só. É barato e corrige o modo de falha mais comum.

O passo 1 é o que muda o jogo, e ele não depende de o seu harness ser bom. Anotação em arquivo sobrevive à compactação, à queda da sessão e à troca de ferramenta, porque não é o harness que a guarda.

Quanto custa

Ordem de grandeza, para ter noção da forma da conta. Uma compactação numa janela de 200 mil tokens processa algo entre 120 mil e 180 mil tokens de entrada e produz de 3 mil a 8 mil de saída. Isso é comparável a cinco ou dez iterações comuns da mesma tarefa, concentradas numa chamada só.

Uma sessão que compacta três vezes gasta em compactação algo próximo do que gastaria em vinte iterações de trabalho. A conta que importa não é o preço absoluto: é comparar com o custo de abrir uma sessão nova com um arquivo de anotações de 2 mil tokens, que faz o mesmo trabalho por uma fração do preço e sem perda semântica.

Footnotes

1. Packer et al. (2023) propuseram gestão virtual de contexto inspirada na hierarquia de memória de sistemas operacionais, com o modelo movendo dados entre níveis por meio de chamadas de função e interrupções. ↩

2. Wang et al. (2023) geraram memória de diálogo recursivamente, combinando a memória anterior com o trecho seguinte da conversa, e relataram respostas mais consistentes em conversas longas em modelos abertos e fechados. ↩

3. Maynez et al. (2020) conduziram avaliação humana de larga escala em sistemas neurais de sumarização abstrativa e encontraram quantidade substancial de conteúdo alucinado em todos os resumos gerados. ↩

4. Laban et al. (2023) criaram um benchmark de dez domínios para detecção de inconsistência factual em resumos; a maioria dos modelos ficou perto do acaso e o melhor deles apareceu 8% abaixo do desempenho humano estimado. ↩

5. Wu et al. (2024) avaliaram cinco habilidades de memória de longo prazo com 500 perguntas em históricos longos e reportaram queda de 30% de acurácia em assistentes comerciais e modelos de contexto longo. ↩