O contexto também envelhece: por que agentes de código precisam esquecer para continuar corretos

Em tarefas longas de repositório, o agente inspeciona arquivos, busca referências, edita, roda testes e volta a inspecionar. Cada passo deixa rastros no contexto. Parte desse material ainda importa na etapa seguinte; outra parte já virou lixo — hipótese descartada, saída de ferramenta que não se aplicou, tentativa que falhou. Quando o sistema trata todo o histórico como sagrado, o modelo continua raciocinando em cima de coisas que deixaram de ser verdadeiras.

O paper AutoCompact (arXiv:2610.02163, 1º de outubro de 2026) parte dessa observação e muda a pergunta. Em vez de comprimir só quando a janela estoura, o agente aprende a decidir quando compactar, o que preservar como estado de trabalho e como seguir a partir desse resumo. Nos experimentos em SWE-bench Verified e SWE-PolyBench Verified, o ganho absoluto de taxa de sucesso chegou a 9,2 e 5,0 pontos percentuais sobre o modelo base — inclusive com janela de 256K que nunca estoura e com janela curta de 16K em que a compactação de fallback entra quando necessário.

A diferença prática é sutil e cara. Compactação por limite de tokens é reação a estouro. Compactação por estado de tarefa é reconhecimento de que uma fase acabou: a causa raiz foi localizada, certos caminhos foram eliminados, o próximo passo é editar e verificar. O resumo útil guarda conclusões confirmadas, trechos de código relevantes, status do workspace e a lista do que ainda falta. O que sobra de exploração barulhenta some. Se o resumo for ruim, o agente perde o fio — goal loss, regressão de raciocínio, correção aplicada no lugar errado.

Isso mexe com o desenho do harness e com a governança de contexto. Quem só amplia a janela e nunca ensina o agente a descartar acaba pagando em tokens, em latência e em decisões tomadas sobre premissas mortas. Quem trata compactação como política — gatilho por estágio, critérios do que deve sobreviver, auditoria do resumo antes de continuar — reduz o risco de o modelo “lembrar” de um arquivo que já mudou ou de uma hipótese que o próprio agente já rejeitou três passos atrás.

Na operação diária, o sintoma aparece quando o agente insiste em um caminho que a própria trajetória já mostrou inviável, ou quando o patch final ignora uma restrição que estava no início da conversa e sumiu no meio do ruído. Nesses casos o problema não foi falta de contexto. Foi excesso de contexto que envelheceu e ninguém mandou esquecer.

Gerenciar contexto em agentes de código deixou de ser só “não estourar a janela”. Passou a ser decidir, no meio da tarefa, o que ainda é estado de trabalho e o que já é história que atrapalha.

Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.

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 pode consultar a série "Engenharia de Software Assistida por IA" clicando na imagem abaixo:

• Cupom de 30% OFF: LEIA30.
• Disponível também no Kindle Unlimited.

Referências

• arXiv:2610.02163 - AutoCompact: Learning When to Compact Context in Long-Horizon Coding Agents (Zhang, Zheng, Du, An, Dong; 1 out 2026)
• Discussões correlatas sobre compaction em harnesses de agentes de código (Claude Code, Codex, Deep Agents)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #ContextEngineering #CodingAgents #EngenhariaDeSoftwareAssistidaPorIA