Memória de agentes: curto e longo prazo
Como agentes lembram dentro de uma sessão e entre sessões, e os custos disso.
5 min de leitura
Escolha como aprender
combine como quiserDica: o vídeo é um resumo visual rápido; o áudio e o texto trazem a aula completa. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Um agente sem memória é como um colega que esquece tudo entre reuniões: você repete o contexto toda vez, ele comete os mesmos erros e nunca evolui. Memória é o que transforma um chatbot stateless em um agente que realmente aprende e age com contexto, e entender os seus custos é tão importante quanto entender os seus benefícios.
Curto prazo: a janela de contexto é a memória de trabalho
Toda vez que o agente chama o modelo, ele envia uma lista de mensagens, o histórico da conversa. Isso é a memória de curto prazo: o que está dentro da janela de contexto naquele momento. Não existe estado mágico no modelo; o modelo é stateless por natureza. O que parece "lembrar" é simplesmente o histórico que você coloca no prompt.
Isso tem uma consequência direta: cada token no histórico custa dinheiro e latência. Se você acumular todas as mensagens de uma sessão longa sem critério, o contexto cresce, o custo sobe e, pior, o modelo começa a perder foco no que importa. Pesquisadores chamam isso de lost in the middle: informação no meio de um contexto longo tende a ser ignorada pelo modelo.
A solução prática é gerenciar o histórico ativamente. As estratégias mais comuns são: manter apenas as últimas N mensagens (janela deslizante), sumarizar o histórico antigo em um bloco compacto, ou combinar as duas. O agente não precisa de tudo, precisa do suficiente para agir com coerência.
Longo prazo: persistência entre sessões
Memória de longo prazo é o que sobrevive quando a sessão termina. Ela não mora no contexto, mora em um armazenamento externo que o agente consulta quando precisa. E aqui a conexão com os módulos anteriores fica explícita: a forma mais eficaz de recuperar memória de longo prazo é via busca semântica em um vector store, exatamente como RAG (Lição 06).
Existem três sabores principais que você vai encontrar na prática:
- Episódica: fatos sobre interações passadas. "Na semana passada o usuário disse que prefere relatórios em PDF." São eventos com contexto temporal.
- Semântica: conhecimento geral que o agente acumulou. "A empresa usa Kubernetes na região us-east-1." Fatos sem âncora temporal forte.
- De perfil (ou de usuário): atributos estáveis do usuário ou da entidade. Nome, preferências, cargo, histórico de decisões. Geralmente armazenados de forma estruturada, não apenas como vetores.
Quando o agente inicia uma nova sessão, ele faz uma consulta ao armazenamento de longo prazo, usando o contexto atual como query, e injeta os fatos relevantes no prompt. Isso é memória como retrieval, não memória como estado global.
Camadas de memória de um agente
Fluxo de como o agente acessa e persiste memória durante e entre sessões.
- Janela de Contexto · Context Window
- Histórico da Conversa · Conversation History
- Sumarizador · Summarizer
- Vector Store · Episódica + Semântica
- Perfil do Usuário · User Profile Store
- Loop ReAct · Agent Loop
- Memory Retriever · Busca semântica
Na prática, o erro mais comum que vejo em implementações de agentes não é esquecer de implementar memória, é implementar sem critério de seleção. Guardar tudo e injetar tudo no contexto cria dois problemas sérios: custo de tokens cresce linearmente com o histórico, e o modelo começa a se contradizer ao tentar reconciliar fatos antigos com novos. Minha recomendação: trate memória como cache, expire o que não é mais relevante, priorize o que tem alta similaridade com a intenção atual, e nunca injete mais do que o necessário para a tarefa em mãos.
Trade-offs: o custo real de lembrar
Memória não é gratuita. Cada decisão de design tem um custo explícito que você precisa conhecer antes de ir para produção.
Tokens e latência: cada fato que você injeta no contexto aumenta o número de tokens de entrada. Em modelos cobrados por token, isso impacta diretamente o custo por sessão. Em modelos com janela limitada, você pode simplesmente ficar sem espaço.
Ruído e alucinação: memória irrelevante no contexto não é neutra, ela confunde o modelo. Se você injeta um fato de seis meses atrás que contradiz o estado atual, o modelo pode misturar os dois e gerar uma resposta incorreta com alta confiança. Isso é especialmente crítico em memória episódica.
Staleness (dados velhos): perfis e fatos semânticos envelhecem. O cargo do usuário mudou, a arquitetura foi migrada, a política foi atualizada. Sem uma estratégia de expiração ou atualização, a memória de longo prazo vira desinformação.
Privacidade e compliance: memória de usuário é dado pessoal. Antes de persistir qualquer coisa entre sessões, você precisa saber onde está armazenando, quem tem acesso e por quanto tempo. Isso não é detalhe de implementação, é requisito de arquitetura.
O equilíbrio certo é: memória de curto prazo gerenciada ativamente (janela deslizante + sumarização), memória de longo prazo recuperada por relevância (não por completude), e expiração explícita para tudo que tem prazo de validade.
Curto prazo vs. Longo prazo
| Dimensão | Curto prazo (contexto) | Longo prazo (store externo) |
|---|---|---|
| Onde mora | Janela de contexto do LLM | Vector store / banco estruturado |
| Duração | Apenas durante a sessão | Persiste entre sessões |
| Custo de acesso | Tokens de entrada (direto) | Latência de busca + tokens injetados |
| Risco principal | Contexto longo = lost in the middle | Dados velhos = alucinação por staleness |
| Estratégia de controle | Janela deslizante + sumarização | Retrieval por relevância + expiração |
Tipos de memória
Toque num cartão para virar.
O que você precisa saber desta lição
Perguntas frequentes
Preciso de um vector store dedicado para memória de longo prazo?
Não necessariamente. Para memória de perfil simples, um banco relacional ou DynamoDB resolve. Vector store faz sentido quando você precisa de busca semântica, por exemplo, recuperar episódios passados com base no contexto atual da conversa. Comece simples e adicione complexidade quando o caso de uso justificar.
Como evitar que o agente injete memória irrelevante no contexto?
Use um threshold de similaridade na busca vetorial, só injete fatos acima de um score mínimo. Além disso, limite o número de itens recuperados (top-k pequeno) e considere um passo de re-ranking para priorizar os mais relevantes para a intenção atual.
Memória de agente e RAG são a mesma coisa?
O mecanismo é o mesmo, embeddings + busca semântica + injeção no contexto. A diferença é a origem dos dados: RAG busca em documentos externos (base de conhecimento), memória de longo prazo busca em fatos gerados pelo próprio agente e usuário durante interações anteriores. São camadas complementares, não substitutas.
Próxima lição: Bedrock AgentCore Memory
No Módulo 4 (Lição 17), você vai ver como o Amazon Bedrock AgentCore implementa essas camadas de memória de forma gerenciada, sem precisar orquestrar manualmente o vector store, a expiração e a injeção no contexto. Os conceitos desta lição são o mapa; o AgentCore é o território na AWS.