Memorizar o histórico de sessões não é útil para agentes
(12gramsofcarbon.com)- Em tarefas de SWE, se o agente já consegue ver contextos como documentos, PRs e commits, a busca em históricos de sessões não trouxe ganho de desempenho
- Uma implementação comum salva todos os transcripts em um banco de dados e depois expõe busca vetorial, Elasticsearch, busca SQL e grafos via MCP ou uma skill de CLI, mas em testes comparativos ao longo de vários meses isso não fez diferença e, às vezes, pôde até piorar a qualidade do modelo
- Em ambientes que mantêm boas mensagens de commit, mensagens de PR, documentação e metadados, as informações importantes já estão organizadas nos artefatos de código, então o histórico de sessões faz o agente reler informações duplicadas e anotações temporárias como tokens
- Agentes não são bons em fazer a remoção de contexto necessária para memória de longo prazo; como não têm estado, podem tratar todo o código, notas e tokens no contexto de entrada como intenção, acumulando intent drift
- O histórico de sessões pode ser útil para observabilidade da equipe, mas é negativo como meio de melhorar desempenho; as sugestões semanais de mudanças dos nori bots também exigiam revisão humana do diff, e a taxa real de aceitação ficava abaixo de 20%
Por que a busca em históricos de sessões não aumentou o desempenho
- Em tarefas de SWE, mesmo permitindo buscar históricos de sessões anteriores, quando havia outros contextos disponíveis, o ganho de desempenho foi zero
- Tentativas de varrer automaticamente históricos de sessões para melhorar o contexto do agente também não trouxeram grande benefício sem revisão humana
- Uma arquitetura comum de memória baseada em sessões segue este fluxo
- Salvar todos os transcripts de toda a organização em um banco de dados
- Adicionar por cima camadas de busca vetorial, Elasticsearch e busca SQL
- Equipes mais ambiciosas usam as três e também incluem um grafo
- Expor isso ao agente por meio de MCP ou de uma CLI com skills
- Após comparar por vários meses abordagens com e sem busca em sessões, esse trabalho adicional não fez diferença e, em alguns casos, pôde piorar o modelo
- As informações úteis já estão organizadas nos artefatos de código
- Mudanças de código incluem boas mensagens de commit, mensagens de PR, documentação abrangente e metadados commitados junto com o código
- Ao trabalhar em um código específico, o agente é instruído a consultar a documentação e PRs anteriores
- A busca em históricos de sessões faz o agente reler coisas que ele já sabe e consumir tokens com decisões temporárias e scratchpads que, desde o início, não deveriam ter sido registrados
Onde a memória automática se desestabiliza
- Agentes não fazem a limpeza de memória que é crucial para manter memória de longo prazo
- Não houve casos observados, em milhares de sessões, em que o contexto fosse de fato removido
- Isso não é algo que se resolva com prompt engineering; como agentes não têm estado, eles tratam tudo na janela de contexto de entrada como ground truth
- Código, memórias existentes e todos os tokens são tratados como expressão de intenção, inclusive decisões arbitrárias de sessões anteriores do agente ou conteúdos não revisados por humanos
- Nesse processo, o intent drift se acumula
- Quanto mais o agente constrói autonomamente uma base de memória, mais interpretações incorretas de intenções de entradas anteriores continuam se acumulando
- Não há benchmarks de codificação que presumam que os dados de entrada estejam contaminados, e o modelo é penalizado se presumir que os dados de entrada estão errados
- Também não há uma forma fácil de satisfazer ao mesmo tempo “não exclua o codebase” e “exclua parte do contexto de entrada”
- A memorização automática acaba resultando em contexto-lixo desnecessário, que consome tokens, aumenta custos e reduz a qualidade do modelo
- Históricos de sessões podem ser úteis para observabilidade da equipe, mas é difícil vê-los como uma ferramenta que torna agentes melhores
O modelo de revisão humana dos nori bots
- Aprender contexto ao longo do tempo não é impossível em si; os nori bots revisam semanalmente o que aconteceu na empresa em PRs, Slack, Drive etc. e sugerem mudanças nos skillsets nori incorporados
- As propostas de mudança marcam a equipe no Slack, mas o padrão é rejeitar tudo
- Para aceitar uma mudança, é preciso olhar o diff diretamente e confirmar se está alinhado à intenção
- A taxa de aceitação é inferior a 20%, e acredita-se que os outros 80% das atualizações “automáticas” teriam piorado o modelo
- Se uma organização com centenas de pessoas salvasse automaticamente essas atualizações o tempo todo, isso poderia se tornar ainda menos sustentável
1 comentários
Comentários do Hacker News
Isso me lembra quando a OpenAI disse que tinha colocado memória entre sessões no ChatGPT. No fim, pareceu um recurso que fica vasculhando informações aleatórias sobre mim e colando entre prompts sem meu consentimento explícito
Tipo: “Compare estes três carros. Ah, e só para constar, eu sou engenheiro de dados, o sobrenome de solteira da minha mãe é Joana, tenho alergia em épocas ruins, o código deve ser DRY, prefiro SQL a Python, e qual é a flor mais venenosa da Escandinávia?”
Contexto memorizado acaba vazando para projetos e conversas totalmente sem relação, gerando saídas estranhas demais, então é a primeira coisa que eu desativo
Concordo fortemente. O sistema de memória do claude-code às vezes é útil, mas com muito mais frequência ele puxa informações antigas que atrapalham o trabalho atual e acaba sendo prejudicial. Já vi muitas vezes as próprias memórias do Claude levarem o Claude seriamente para o caminho errado
Meu palpite é que isso tem a ver com o treinamento: o modelo parece não conseguir distinguir entre “o que está acontecendo agora” e “o que aconteceu antes”. Talvez fosse diferente se o processo de raciocinar a partir da memória fizesse parte do treinamento, mas como é um recurso acoplado só no momento da inferência, a sensação é que isso confunde o modelo
LLMs não são inteligentes o suficiente para tolerar nem uma contaminação de contexto leve
Há uma inércia no raciocínio ou no contexto que o levou até ali, e isso fica grudado se você deixar
Então é bem irritante quando ele puxa isso de volta da memória depois
A ideia de treiná-los incluindo memória é interessante
Para código, “o que ele estava tentando fazer” em geral não importa muito. O que importa é o que o código realmente faz
Logs de sessão certamente podem ser úteis, mas não quando você está desenvolvendo em cima deles continuamente, e sim quando entra na fase de verificação. Naquele trecho entre um plano em Markdown e um CI passando, em que apareceram 800 linhas novas de código e, clicando por cima, parece estar mais ou menos tudo certo
O log da sessão pode mostrar que tipo de verificação manual houve. O CI roda os testes existentes, o código mostra quais são os novos testes unitários, mas o log da sessão mostra se o agente realmente operou o app com Playwright e se leu e considerou não só a configuração de dev, mas também a de prod
Não é perfeito, mas nem todo trabalho de verificação precisa virar um teste que fica no repositório para sempre. Tivemos muito resultado reanalisando sessões para encontrar os pontos em que o agente tomou decisões sem perguntar e forçando a consideração de verificações para essas decisões. É difícil instruir isso desde o começo, mas com logs de sessão isso aparece facilmente
É um problema irritante. Por causa de uma pergunta hipotética que fiz no passado, ele continua inventando premissas falsas
Só porque pedi para investigar algo, ele assume que eu possuo um datacenter e tenho muitas GPUs
Acho que isso é só uma forma de lição escrita com dor. Há uma boa chance de que o contexto e os agentes que construímos com tanto esforço desapareçam quando surgirem modelos maiores e melhores
Esses registros de conversa são muito úteis para modelos menos capazes, mas talvez sejam quase desnecessários para os modelos de ponta
Eu uso um harness customizado baseado em https://minimal-agent.com/, que por sua vez é baseado no swe-mini-agent, e a lógica central tem umas 50 linhas. Só Bash já basta
Em tarefas pequenas, ele é cerca de 8 vezes mais rápido e usa 8 vezes menos tokens do que os harnesses padrão de cada modelo
Em tarefas grandes, não testei muito. Funciona, mas nesses casos parece menos focado e um pouco menos produtivo. Talvez o prompt de sistema de 20 mil tokens dos harnesses maiores esteja fazendo um trabalho importante para conduzir o fluxo de desenvolvimento de software. Por exemplo, ouvi dizer que a Fable tem um prompt de sistema customizado no Claude Code, e isso pode explicar por que ele age de forma muito mais proativa
Então eu ainda gostaria de acreditar que há valor em engenharia de contexto. Só que esse valor parece diminuir a cada nova geração de modelos, porque eles vêm sendo ajustados para se comportarem de forma menos idiota no geral, então precisam de menos condução pela mão
Para começar, ainda acho que os modelos precisam de camadas de contexto. Uma forma de pensar contexto é como compressão. Você fornece contexto para facilitar que o modelo entenda o que deve fazer. Mesmo num mundo com capacidade de modelo e comprimento de contexto infinitos, isso ainda seria útil, porque evita ter que rederivar tudo a partir de primeiros princípios toda vez. Se o modelo consegue performar melhor com menos tokens, e enquanto nos importarmos com custo de tokens, o contexto é um atalho útil, talvez até necessário
Se assumirmos que algum tipo de camada de contexto é necessário, a próxima pergunta passa a ser que camada deve ser essa. Aqui eu concordo que é melhor trabalhar com formas familiares ao modelo, como arquivos Markdown ao lado do código. Mas isso parece menos uma questão sobre a necessidade de contexto e mais um problema de soluções excessivamente projetadas que não entendem seu principal usuário: o agente
Mas tenho muita curiosidade para saber se uma previsão de próximo token muito melhor não vai simplesmente tornar toda essa construção obsoleta. Seja qual for a resposta, ela vai revelar muita coisa
Também é preciso lembrar que a estrutura do cérebro também é aprendida. Só que em uma escala de tempo muito maior do que a duração da vida de um indivíduo
Concordo que não há necessidade de construir à força um sistema de memória sofisticado. O que vale a pena lembrar deveria estar em documentos, guias, comentários no código-fonte, mensagens de commit e tickets
Não é necessária outra camada. Qualquer granularidade que se possa imaginar já está coberta pelas melhores práticas existentes
Esta extensão faz o seguinte: https://github.com/gitsense/pi-brains
Por enquanto, um “humano” precisa definir as regras de roteamento sobre como acessar as informações, mas no futuro a ideia é oferecer suporte a um “agente de conhecimento” que monitore as conversas e injete contexto quando necessário
~/.claude/…Nos projetos em que precisei de memória, eu só acrescentava uma linha no AGENTS.md dizendo para salvar a memória em MEMORY.md ou acompanhar o progresso em STATUS.md
Mas, se estiver marcado com tags em um log de rastreamento, dá para encontrar com eficiência quando necessário. Além disso, documentos apodrecem, mas logs de rastreamento podem ter hash de commit ou outras informações anexadas, deixando sua validade mais explícita
Discordo fortemente disso
Eu faço o Claude/Codex manter logs [1]. Só deixei isso instruído por prompt no AGENTS.md [0]
“Toda sessão deve gerar um log da sessão ou um plano e, ao final, anexar o resumo produzido. O padrão é log, e planos só devem ser usados para trabalho de design substancial.”
Isso é extremamente valioso. Por exemplo, hoje mesmo comecei algumas sessões assim: “Como está o status do trabalho do Renovate?”, “Encontre aquele trabalho recente em X”, “O problema de backup foi corrigido? Qual é o próximo passo?”, “Esse bug voltou. A gente não já tinha corrigido isso?”
[0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
[1]: https://github.com/shepherdjerred/monorepo/tree/main/package...
No geral, gosto de sistemas de memória. Como referência, uso principalmente Opus 4.8 + Max effort
Com bastante frequência ele recupera algo relevante da memória. Por exemplo, se eu pedir para sugerir alguns candidatos a provedor OIDC self-hosted, ele diz algo como: “Considerando o tamanho da equipe de operações, esta opção pode fazer mais sentido por causa de X e Y”
Claro, isso pode ser informação que deveria estar em um CLAUDE.md. Mas, nesse caso, eu nem tinha pensado que deveria colocar isso no CLAUDE.md, e foi bom a memória ter puxado isso
Às vezes erra. Hoje perguntei sobre um problema de autenticação e ele disse: “Como vocês colocam o app atrás de haproxy, isso pode ter esbarrado nesta configuração de trusted proxy.” Isso fazia sentido para 95% dos nossos apps, então valia a pena mencionar, mas desta vez não era o caso e precisei corrigir. Mesmo assim, se estivesse atrás de proxy, isso poderia ter economizado muito tempo, então foi bom ele ter mencionado
Isso fica ainda mais difícil se você faz muitas perguntas hipotéticas ou ajuda com problemas de outras pessoas. Um humano provavelmente faria perguntas de confirmação em vez de presumir: “Isso é sobre a equipe de operações do X? O tamanho ainda é Y?”, “Este app também está atrás de proxy como os outros apps que você mencionou antes?”
Também há uma hierarquia clara nesse contexto que precisa ser modelada corretamente. Por exemplo, você pode estar envolvido ao mesmo tempo com várias equipes sujeitas a regras diferentes, e humanos entendem isso naturalmente
Mesmo com a memória desligada, isso acontece dentro de uma conversa só
É como um amigo irritante que se lembra de algo de conversas anteriores e continua trazendo isso à tona, mesmo que eu já tenha crescido e mudado
No fundo, é um problema de hardware. 1 milhão de tokens não é contexto suficiente para entender uma base de código da forma como humanos a entendem
A capacidade de esquecer seletivamente tem potencial para ser muito valiosa. Mas, no momento, isso só substitui parcialmente a capacidade humana de lembrar da forma aproximada de algo, decidir que aquilo não é interessante e lembrar que não é interessante
Dizem que a memória só é útil quando guiada por humanos, mas acho que a solução correta vai mais fundo do que isso. Talvez seja algo como colocar toda a base de código e todas as sessões do agente em fine-tuning do modelo. Ainda assim, talvez nesse ponto seja necessário orientar para que certas sessões específicas não entrem no modelo. Ou talvez não seja necessário, e as lições aprendidas com dor se apliquem