Como projetar a memória de um Agent: da sessão à memória de longo prazo

Você passa o dia inteiro discutindo com um Agent de IA: revisa a arquitetura, escolhe tecnologias e avalia riscos. No dia seguinte, abre a mesma conversa e ele pergunta: “Sobre o que você gostaria de conversar?”

Tudo o que foi discutido no dia anterior — preferências, conclusões e andamento — desapareceu. O problema não está na capacidade do Agent, mas na arquitetura: por padrão, um LLM não mantém estado. Cada requisição começa do zero, a menos que você construa um sistema de memória de forma intencional. Muitas equipes só percebem isso depois de colocar o Agent em produção, quando os usuários reclamam que ele fez a mesma pergunta de novo ou esqueceu um acordo anterior. A correção vem tarde.

Este artigo apresenta um projeto completo para um sistema de memória de Agent: como escolher entre quatro tipos de memória, montar um pipeline em cinco etapas, selecionar um framework e controlar os custos.

Capítulo 1: por que um Agent precisa de um sistema de memória

Um LLM nasce com “memória de peixe”. Você envia uma solicitação, ele responde e pronto. Quando chega a próxima solicitação, o estado é novo; ele não se lembra de nada. Isso não é um defeito, mas uma característica do projeto: cada inferência acontece de forma independente, o que ajuda a manter a saída previsível.

Em um Agent, porém, essa característica pode ser desastrosa.

Imagine um Agent de atendimento. O usuário diz: “Quero alterar o endereço”. O Agent responde: “Certo, informe o novo endereço”. O usuário continua: “Use o mesmo endereço do depósito da última vez”. Nesse momento, o Agent fica sem referência: qual foi a última vez? Qual depósito? Ele não sabe.

Há ainda um problema pior: o “apodrecimento do contexto” (Context Rot). À medida que mais conteúdo é adicionado à conversa, o contexto cresce e acumula informações irrelevantes. O usuário faz uma pergunta simples, mas o Agent precisa procurar a resposta em dezenas de interações anteriores. Segundo dados do blog oficial da Redis, uma abordagem que usa todo o contexto pode elevar a latência p95 para 17,12 segundos e multiplicar o consumo de tokens por 14.

A diferença de custo é ainda mais impressionante. Em uma comparação que analisei, usar todo o contexto consumia US$ 1 milhão por mês, enquanto a memória seletiva custava apenas US$ 100 mil. Uma diferença de dez vezes.

O conflito central é o seguinte: você quer que o Agent se lembre de tudo, mas não pode colocar tudo na janela de contexto. Como resolver? A resposta é simples: dar a ele um sistema de memória.

Esse sistema resolve três problemas centrais:

Continuidade entre sessões: se o usuário disser hoje que prefere respostas em português, o Agent deverá manter essa preferência amanhã, na semana seguinte e no mês seguinte.

Experiência personalizada: cada usuário tem hábitos, contexto de negócio e histórico próprios. A memória permite que o Agent “reconheça” cada pessoa.

Recuperação após falhas: se o Agent falhar no meio de uma tarefa, um sistema de memória permite retomar a execução do ponto em que parou após a reinicialização, sem começar tudo de novo.

Capítulo 2: quatro tipos de memória, da ciência cognitiva à arquitetura técnica

Memória não é um único espaço de armazenamento. Ela tem camadas e responsabilidades diferentes. A ciência cognitiva divide a memória humana em memória de trabalho, episódica, semântica e de longo prazo. A arquitetura de um Agent pode aproveitar o mesmo modelo.

Memória de trabalho (Working Memory)

A memória de trabalho é o “cérebro” da sessão atual do Agent. Tudo o que ele processa durante a conversa fica aqui: o que o usuário acabou de dizer, o progresso da tarefa e resultados intermediários do raciocínio.

O local de armazenamento é direto: a janela de contexto. O ciclo de vida também é curto. Quando a conversa termina, a memória de trabalho é apagada e a próxima conversa começa do zero.

Na implementação técnica, a maioria dos frameworks usa Redis ou um KV Store como backend, acompanhado de um Checkpointer que salva o estado periodicamente. O MemorySaver do LangGraph é um exemplo típico: depois da execução de cada nó, ele salva um snapshot do estado na memória ou em um banco de dados.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Memória episódica (Episodic Memory)

A memória episódica registra “o que aconteceu”. Quais perguntas o usuário fez da última vez, como o Agent respondeu e quais decisões foram tomadas ficam armazenados em ordem cronológica, como um diário de eventos.

Ao contrário da memória de trabalho, a memória episódica persiste entre sessões. A conversa pode terminar hoje e, amanhã, uma nova conversa ainda poderá consultar os eventos anteriores.

O armazenamento costuma usar fluxos de eventos, como Redis Streams, ou bancos de dados temporais. Uma estratégia importante de otimização é a “compactação por resumos”: eventos brutos podem ser extensos, então um LLM os resume em uma versão menor, preservando as informações essenciais e reduzindo os custos de armazenamento e recuperação.

Memória semântica (Semantic Memory)

A memória semântica representa “o que se sabe”. Ela armazena fatos e conhecimento abstrato, como “o usuário prefere respostas em português”, “a sede da empresa fica em Xangai” ou “o produto A custa 500 yuans”.

Não importa quando ou em qual conversa esse conhecimento surgiu. O que importa é o próprio fato.

O armazenamento usa principalmente bancos de dados vetoriais — Pinecone, Weaviate ou Milvus — combinados com grafos de conhecimento. Depois da vetorização, índices HNSW ou IVF aceleram a recuperação. O grafo de conhecimento, por sua vez, armazena relações entre entidades, como “o usuário A prefere B” ou “a empresa C está localizada em D”.

Memória de longo prazo (Long-Term Memory)

A memória de longo prazo responde à pergunta “quem é o usuário?”. Ela armazena perfil, preferências e conhecimento duradouro de domínio — informações que mudam pouco e valem para todas as sessões.

O armazenamento fica em um banco de dados persistente, como PostgreSQL, MongoDB ou uma solução dedicada de nuvem, como Alibaba Cloud AnalyticDB e PolarDB. A recuperação costuma combinar busca semântica e RAG com filtros por atributo, por exemplo, pelo ID do usuário.

Esses quatro tipos de memória não estão isolados. Eles formam uma pirâmide: a memória de trabalho fica na base, é a mais rápida e também a mais efêmera; a memória de longo prazo fica no topo, dura mais, mas é recuperada com menor velocidade. O Agent consulta diferentes camadas conforme a tarefa.

Capítulo 3: pipeline de memória em cinco etapas, da extração ao esquecimento

Salvar a conversa não basta. Um sistema de memória precisa de um pipeline completo: extração, consolidação, armazenamento, recuperação e esquecimento. Cada etapa exige decisões próprias.

Etapa 1: extração (Extraction)

Nem toda frase de uma conversa precisa ser lembrada. “Olá”, “obrigado” e “espere um momento” são ruídos; armazená-los apenas desperdiça espaço.

A etapa de extração identifica quais informações merecem ser preservadas. A abordagem usual combina classificação por LLM e filtragem por regras. O LLM avalia se a informação tem valor duradouro — “o usuário prefere respostas em português” em vez de “o usuário disse olá” — e as regras tratam padrões evidentes, como mensagens curtas demais ou simples saudações.

# Pseudocódigo da etapa de extração
def extract_memories(conversation):
    candidates = []
    for message in conversation:
        # Classificação pelo LLM: vale a pena guardar?
        classification = llm.classify(message, "memory_candidate")
        if classification == "worth_remembering":
            candidates.append(message)
    # Filtro por regras: remover ruído evidente
    candidates = filter_noise(candidates)
    return candidates

Etapa 2: consolidação (Consolidation)

As informações extraídas podem se repetir. “O usuário prefere português” pode aparecer três vezes em conversas diferentes; não é necessário armazenar três cópias.

A consolidação combina duplicatas, atualiza memórias antigas e cria triplas para o grafo de conhecimento.

Por exemplo:

• Memória anterior: “O usuário prefere respostas em português”
• Nova extração: “O usuário disse que prefere respostas concisas em português”
• Após a consolidação: “O usuário prefere respostas concisas em português” (combinação e refinamento)

# Pseudocódigo da etapa de consolidação
def consolidate_memories(new_memories, existing_memories):
    for new in new_memories:
        # Verificar se há memória existente duplicada ou relacionada
        similar = find_similar(new, existing_memories)
        if similar:
            # Combinar ou atualizar
            merged = llm.merge(new, similar)
            update_memory(similar.id, merged)
        else:
            # Adicionar uma nova memória
            add_memory(new)

Etapa 3: armazenamento (Storage)

Essa etapa envolve duas decisões centrais: o formato de armazenamento e o método de indexação.

O formato depende do tipo de memória: memória de trabalho usa KV Store; memória episódica usa um fluxo de eventos; memória semântica usa um banco de dados vetorial; memória de longo prazo usa um banco de dados relacional.

O índice afeta diretamente o desempenho da recuperação. As opções mais comuns são HNSW e IVF:

• HNSW: indicado para conjuntos de dados de pequeno e médio porte, de centenas de milhares a milhões de registros. Com a mesma latência, oferece uma taxa de recuperação maior, mas consome mais memória.
• IVF: indicado para conjuntos grandes, de milhões a centenas de milhões de registros. Usa memória com mais eficiência, mas oferece uma precisão um pouco menor.

Segundo o blog da Redis, o HNSW costuma alcançar uma taxa de recuperação maior sob a mesma meta de latência, enquanto o IVF economiza memória em grandes volumes. A escolha depende do tamanho dos dados e do nível de precisão exigido.

Etapa 4: recuperação (Retrieval)

Quando o Agent precisa usar uma memória, a etapa de recuperação encontra as informações relevantes.

Uma busca exclusivamente vetorial nem sempre é precisa o suficiente. Uma abordagem melhor é a “busca híbrida”, que combina busca vetorial, busca textual e filtros por atributo.

Se o usuário perguntar “qual era o endereço do depósito que mencionamos da última vez?”, o fluxo será:

1. Busca vetorial: encontrar memórias semanticamente semelhantes, como “endereço do depósito” e “informações de logística”
2. Filtro por atributo: considerar apenas as memórias desse usuário
3. Ordenação temporal: priorizar as memórias mais recentes

# Pseudocódigo de busca híbrida
def retrieve_memories(query, user_id):
    # Busca vetorial
    vector_results = vector_db.search(query, top_k=20)
    # Filtro por atributo: considerar apenas o usuário atual
    filtered = [m for m in vector_results if m.user_id == user_id]
    # Ordenação temporal: priorizar os mais recentes
    sorted_results = sort_by_time(filtered, descending=True)
    return sorted_results[:5]

Etapa 5: esquecimento (Forgetting)

“Esquecimento” pode parecer algo negativo, mas é essencial em um sistema de memória. Sem ele, o armazenamento cresce indefinidamente e o ruído encobre as informações valiosas.

Há duas estratégias principais:

Decaimento temporal: a importância de uma memória diminui com o tempo. Uma preferência registrada há um mês pode já estar desatualizada, então seu peso é reduzido automaticamente.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Descarte por importância: frequência de acesso, feedback do usuário, número de validações e outros indicadores determinam a importância. Memórias pouco relevantes são removidas periodicamente.

Um problema fácil de ignorar é a “cristalização de um erro isolado”. O usuário menciona por acaso uma informação incorreta, e o Agent a armazena como “fato”. Isso é perigoso. Uma solução é acrescentar validação na consolidação ou marcar memórias de baixa confiança como “pendentes de confirmação”.

Capítulo 4: comparação de frameworks — Mem0 vs. Zep vs. LangMem vs. LangChain

Já existem frameworks maduros de memória; não é necessário criar tudo do zero. A questão é qual deles escolher.

Os quatro frameworks têm características próprias. A tabela resume as diferenças:

Árvore de decisão

Antes de escolher um framework, responda a três perguntas:

P1: Você precisa de um grafo de conhecimento?
    → Sim → Mem0 Pro ou Zep (ambos oferecem recursos maduros de grafo)
    → Não → Continue para P2

P2: Você precisa de um serviço gerenciado?
    → Sim → Mem0 (mais simples para começar) ou MemoClaw (sem configurar API Key)
    → Não → Continue para P3

P3: Você usa LangGraph?
    → Sim → LangMem (integração nativa, sem dependências adicionais)
    → Não → Implemente sua própria solução (LangChain Checkpointer + banco de dados vetorial)

Recomendações por cenário

Atendimento inteligente → Mem0

Um Agent de atendimento precisa se lembrar das preferências do usuário, pedidos anteriores e reclamações. Essas informações se encaixam bem em um grafo de conhecimento, com relações como “o usuário A comprou o produto B” e “o usuário A reclamou do problema C”. A versão gerenciada da Mem0 reduz o custo operacional, e a versão Pro oferece o grafo.

Agent de diagnóstico médico → Zep

O setor de saúde envolve relações complexas entre entidades e linhas do tempo: quando os sintomas surgiram, quando a medicação mudou e quando os resultados dos exames se alteraram. O principal diferencial da Zep são os “fatos temporais” (Temporal Facts), que acompanham com precisão a dimensão temporal dos eventos e funcionam bem em cenários que exigem raciocínio sobre o histórico clínico.

Agent para ferramentas internas → LangMem

Se o Agent já foi criado com LangGraph, adicionar LangMem é a opção mais simples. Como biblioteca nativa do LangGraph, ela não exige dependências adicionais e integra Checkpointer e armazenamento de memória.

Validação rápida de protótipo → MemoClaw

Quer testar um sistema de memória sem criar uma conta ou configurar uma API Key? O MemoClaw oferece “memória como serviço” por meio de duas interfaces simples, store e recall. É adequado para protótipos; em produção, talvez seja necessário um framework mais robusto.

Ecossistema de integração da Mem0

A cobertura de integrações da Mem0 merece destaque. Segundo dados publicados no blog oficial da empresa no início de 2026, ela já oferecia integração com 21 frameworks e plataformas, incluindo OpenAI, LangChain, LlamaIndex, CrewAI e AutoGen. Se você usa um framework conhecido, provavelmente já existe um pacote de integração.

Capítulo 5: implementação em produção — controle de custos e otimização de desempenho

Fazer uma demonstração funcionar não significa que o sistema esteja pronto para produção. Antes de lançar a memória, três perguntas precisam de resposta: o desempenho é rápido o suficiente, o custo é baixo o bastante e a segurança é confiável?

Escolha do índice: precisão vs. escala

O gargalo da recuperação vetorial costuma estar no índice. Há três opções principais:

FLAT: busca por força bruta, com precisão perfeita, mas lenta. É adequada para poucos dados, abaixo de dezenas de milhares de registros, ou para cenários que exigem 100% de precisão.

HNSW: grafo hierárquico de mundo pequeno, com alta taxa de recuperação e boa velocidade. É indicado para volumes pequenos e médios, de centenas de milhares a milhões de registros, mas usa bastante memória — cerca de alguns GB para cada milhão de vetores.

IVF: índice invertido que divide os vetores em grupos e consulta apenas alguns deles. É indicado para grandes volumes, de milhões a centenas de milhões de registros. Usa memória com eficiência, mas perde um pouco de precisão porque pode deixar de encontrar vetores relevantes fora dos grupos consultados.

A escolha é direta: FLAT ou HNSW para poucos dados; IVF para grandes volumes. Se a precisão for especialmente importante, como em diagnóstico médico, vale sacrificar velocidade para obter uma taxa de recuperação maior com HNSW.

Otimização de latência: de segundos para milissegundos

Quando o usuário faz uma pergunta, o Agent recupera memórias, executa a inferência e gera uma resposta. A latência de cada etapa se acumula. A abordagem com todo o contexto é lenta porque precisa processar um contexto enorme antes da inferência; sua latência p95 pode chegar a 17 segundos.

A otimização consiste em fazer a recuperação antes da inferência — e fazê-la rapidamente.

Como plataforma unificada, o Redis oferece consultas com latência inferior a um milissegundo. Ele também aceita busca vetorial, fluxos de eventos e armazenamento KV. Assim, memória de trabalho, episódica e semântica podem ficar no mesmo lugar, eliminando a latência de rede entre serviços.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Outra armadilha é “acumular várias inferências”. Alguns projetos fazem o seguinte: recuperam memórias, usam um LLM para organizá-las e só então executam outra inferência para responder. Duas chamadas ao LLM dobram a latência. É melhor injetar diretamente os resultados da recuperação no contexto e resolver tudo em uma única inferência.

Controle de custos: o segredo por trás de uma diferença de dez vezes

Como já mencionei, o custo de usar todo o contexto pode ser dez vezes maior do que o da memória seletiva. Como alcançar essa redução?

Há três estratégias centrais:

Memória seletiva: armazene apenas informações valiosas, em vez de inserir todo o histórico de conversas. A extração remove o ruído, e o armazenamento limita a quantidade de memórias.

Compactação por resumos: uma conversa bruta pode ter milhares de palavras, enquanto o resumo tem apenas algumas centenas. Use um LLM para compactar periodicamente a memória episódica e reduzir o consumo de tokens.

Esquecimento inteligente: o armazenamento cresce indefinidamente, por isso é preciso remover periodicamente memórias de pouca importância. A combinação de decaimento temporal e descarte por frequência de acesso mantém o conjunto de memórias sob controle.

Segundo a estimativa da equipe oficial da Mem0, a memória seletiva pode reduzir o custo mensal de US$ 1 milhão para US$ 100 mil, principalmente pela queda no uso de tokens e no custo de armazenamento.

Segurança e privacidade: isolamento de memória

O sistema de memória armazena dados dos usuários, portanto a segurança não pode ser tratada de forma superficial.

Isolamento de memória: as memórias de cada usuário devem ser armazenadas separadamente, e toda recuperação precisa aplicar um filtro rigoroso por user_id. Um usuário nunca pode recuperar a memória de outra pessoa.

Defesa contra envenenamento de memória: um usuário mal-intencionado pode inserir informações falsas de propósito para que o Agent as memorize como fatos. A consolidação precisa incluir validação; informações de baixa confiança devem ser marcadas como “pendentes de confirmação”, e não gravadas diretamente na memória de longo prazo.

Anonimização de dados: informações sensíveis, como número de celular e documento de identidade, devem ser anonimizadas antes do armazenamento. A recuperação também precisa de controle de acesso para restaurar os dados.

Manutenção de consistência: bloqueio distribuído + reflexão

Em implantações com várias instâncias, a consistência da memória é um problema. A instância A pode atualizar uma memória enquanto a instância B ainda usa a versão anterior.

Dois mecanismos ajudam a resolver isso:

Bloqueio distribuído + controle de versão: bloqueie a memória antes da atualização e grave uma nova versão ao concluir. Na recuperação, selecione a versão mais recente por padrão para evitar dados desatualizados.

Reflexão periódica: peça ao LLM para verificar o repositório de memórias regularmente, identificar contradições ou informações obsoletas e removê-las ou atualizá-las. A solução Alibaba Cloud AnalyticDB já inclui esse mecanismo.

Conclusão

Em resumo, o sistema de memória não é um “recurso opcional” de um Agent. Ele é a capacidade central que diferencia um Agent de uma interface comum para LLMs. Sem memória, cada conversa começa como um novo contato: o Agent nunca consegue realmente “entender” o usuário nem manter continuidade em tarefas de longo prazo.

Ainda assim, instalar um sistema de memória não resolve tudo de uma vez. Primeiro é preciso decidir: você precisa de um grafo de conhecimento? Aceita um serviço gerenciado? A que framework o projeto atual está vinculado? Depois dessas respostas, a escolha fica bem mais clara.

Se ainda houver dúvida, recomendo começar com LangMem ou com a versão open source da Mem0. O investimento inicial é menor e o resultado é fácil de perceber. Depois de dominar a memória de trabalho, você pode avançar para a memória episódica e a memória de longo prazo.