![Imagem de capa de [Contexto de IA #6] Memória de agentes fora do contexto](/assets/images/posts/9c901582-b6d3-47a4-a582-ff7c6393053d/1.jpg)
O tema desta edição é esse destino. Onde e como armazenar o conhecimento que precisa sobreviver ao fim de uma sessão? A janela de contexto é uma bancada de trabalho, e o sistema de arquivos é um depósito. A bancada é pequena, cara e é limpa quando a sessão termina. O depósito é grande, barato e permanece. No fim, operar bem um agente é projetar a logística entre a bancada e o depósito.
O tema desta edição é esse destino. Onde e como colocar o conhecimento que precisa sobreviver ao fim de uma sessão. A janela de contexto é uma bancada de trabalho, e o sistema de arquivos é um depósito. A bancada é pequena, cara e é limpa quando a sessão termina. O depósito é grande, barato e permanece. No fim, operar bem um agente é projetar a logística entre a bancada e o depósito.
Arquivos de plano, a linha de vida de tarefas longas
A forma mais básica de externalização é um arquivo de plano. Ao iniciar uma tarefa, faça o agente criar um arquivo como PLAN.md com os objetivos, as decisões confirmadas e as etapas restantes, atualizando-o conforme o trabalho avança.
Esse único arquivo resolve vários problemas de uma vez. Primeiro, ele sobrevive aos resets de sessão. Seja executando /clear porque o contexto ficou cheio, seja fechando o notebook e abrindo uma nova sessão no dia seguinte, ler o arquivo de plano permite continuar o trabalho. Diferentemente do resumo incerto produzido pelo auto-compact visto na Parte 3, ele é um registro preciso cujo conteúdo você controla diretamente.
Há também um efeito colateral. Se o agente atualizar e reler o arquivo de plano a cada etapa, o objetivo geral reaparecerá repetidamente perto do fim do contexto. Como vimos na Parte 2, a atenção do modelo se concentra fortemente nessa região. Ao explorar essa propriedade, você mantém à vista “o que eu estava fazendo”. Esse é o remédio para o problema de agentes que esquecem o objetivo original e se desviam em tarefas com dezenas de etapas. Na prática, produtos de agentes que lidam com tarefas longas usam este padrão: mantêm uma lista de tarefas em um arquivo e a reescrevem continuamente.
Memória, conhecimento acumulado entre sessões
Se um arquivo de plano prolonga a vida de uma tarefa, a memória acumula conhecimento ao longo de todo o projeto. Agentes, incluindo o Claude Code, oferecem recursos de diretório de memória, cujo princípio é simples: registrar cada fato descoberto em um arquivo separado, manter carregado continuamente apenas um índice resumido e ler o conteúdo completo quando uma tarefa relacionada precisar dele. O princípio dos ponteiros da Parte 4 também se aplica aqui.
O ponto importante aqui é o critério de armazenamento. Se você anotar qualquer coisa, a memória logo vira um depósito de lixo. O critério é “informação que não pode ser derivada de outro lugar”. A estrutura do código fica de fora porque pode ser descoberta lendo o código; o histórico de commits fica de fora porque o Git se lembra dele. Já regras operacionais como “o servidor de desenvolvimento deste projeto deve sempre ser iniciado no worktree principal”, preferências como “o usuário quer linguagem formal” e armadilhas específicas do ambiente descobertas depois de muita tentativa e erro valem ser armazenadas, pois não estão registradas em nenhum outro lugar.
Memórias antigas também precisam entrar no plano. Não há garantia de que um fato registrado há seis meses ainda seja verdadeiro. As regras de leitura e escrita da memória devem incluir “se uma memória consultada não corresponder à realidade, atualize-a ou exclua-a”. Isso impede que uma lembrança incorreta retorne como o context poisoning descrito na Parte 2.
RAG, quando o depósito tem o tamanho de uma biblioteca
Arquivos de plano e memória cobrem algumas dezenas de arquivos. Mas e se o depósito tiver o tamanho de uma biblioteca? Milhares de páginas da wiki interna, dezenas de milhares de artigos e centenas de milhares de registros de atendimento ao cliente. A informação necessária certamente está em algum lugar, mas não é possível carregar tudo no contexto.
A técnica usada nesses casos é RAG (Retrieval-Augmented Generation, geração aumentada por recuperação). Quando chega uma pergunta, o sistema primeiro busca fragmentos relevantes no depósito e depois coloca apenas alguns deles no contexto para gerar a resposta. A busca normalmente usa embeddings. Ao transformar o texto em coordenadas no espaço semântico, uma pergunta sobre “regras de reembolso” e um documento sobre “política de cancelamento de pagamento” podem ficar próximos mesmo usando expressões diferentes, permitindo encontrá-los sem palavras-chave em comum.
Por algum tempo, RAG foi visto como a única resposta para lidar com documentos longos, mas os agentes de programação trouxeram uma reviravolta interessante. Descobriu-se que agentes capazes de usar ferramentas encontram o código necessário muito bem repetindo buscas com grep e explorando arquivos, mesmo sem busca por embeddings. Por isso, a visão prática atual é híbrida. A exploração direta do agente é forte para código com identificadores precisos, enquanto a busca por embeddings é forte para grandes conjuntos de documentos em linguagem natural com expressões variadas. Em qualquer caso, o princípio é o mesmo: não carregue tudo; carregue apenas o que for relevante no momento da consulta.
Resumo
- O contexto é uma bancada de trabalho, e os arquivos são um depósito. A prática básica é tirar do contexto e enviar para arquivos o conhecimento que precisa permanecer depois que a sessão termina.
- Arquivos de plano salvam tarefas longas dos resets de sessão e expõem repetidamente o objetivo perto do fim do contexto, evitando desvios.
- Armazene na memória apenas informações que não possam ser derivadas de outro lugar, mantenha somente o índice carregado continuamente e gerencie itens antigos com regras de atualização e exclusão.
- Quando o depósito for muito grande, use RAG para carregar apenas fragmentos relevantes no momento da consulta. A exploração direta é forte para código; a busca por embeddings é forte para coleções de documentos em linguagem natural.
Agora resta apenas a última edição da série. Até aqui, gerenciamos o contexto em busca de qualidade; a última fala de dinheiro. Ela aborda como o funcionamento do cache de prompts pode fazer os custos de API variarem várias vezes conforme a forma de montar o mesmo contexto, e por que não se deve alterar levianamente o início do contexto.