💡 Como ler este módulo
Memória é a feature mais mal compreendida do DeerFlow. A maioria confunde com histórico. A maioria acumula sem revisar. A maioria trata como caixa-preta. O primeiro tópico corrige a confusão, os outros três constroem o hábito, e o lab força você a sentir a diferença entre memória limpa e memória envenenada.
💾 O que é lembrado (e o que não é)
Memória é o armazenamento de fatos e preferências que sobrevivem ao fim da sessão. Histórico é o log da conversa — só existe enquanto a sessão está aberta, e some quando ela fecha. São dois sistemas diferentes. Confundi-los gera expectativas erradas ("por que ele não lembra do que eu disse ontem?" — porque você estava falando no histórico, não na memória).
🎯 A separação essencial
Um fato entra na memória quando o agente decide explicitamente salvar (ou quando você manda salvar). Não é automático. Não é "lembrar de tudo". É seletivo e rastreável. Isso é deliberado — memória automática vira caixa-preta e caixa-preta vira veneno.
- •Histórico — mensagens cruas, morre no fim da sessão (ou é compactado)
- •Memória — itens estruturados, categorizados, persistidos, visíveis na UI
- •Decisão explícita — o lead_agent escreve o fato, você vê, você pode editar
- •Forçar — "guarde isso" no prompt funciona como comando de salvamento
💡 Teste rápido de entendimento
Se você não sabe dizer se um determinado fato está na memória ou estava no histórico de uma sessão antiga, abra o painel de memória e procure. Se não aparece lá, é histórico — ou melhor, já morreu. A UI expõe a memória exatamente para você não precisar adivinhar.
📊 Como o DeerFlow decide salvar
- Fatos declarativos explícitos — "meu projeto é X", "prefiro Y" — alta propensão a virar memória
- Correções do usuário — "não faça assim, faça assado" — vira feedback automaticamente
- Referências externas mencionadas — URLs, paths, IDs — viram reference se forem reutilizáveis
- Texto de trabalho comum — rascunho de email, geração de código — não entra na memória
- Comando explícito — "guarde isso" no prompt é aceito e processado como salvamento direto
🗂️ Tipos: user, feedback, project, reference
Toda memória é taggeada com uma de quatro categorias. Isso não é organizacional — é funcional: cada categoria tem critério de salvamento diferente, regra de relevância diferente e decaimento diferente. Entender as quatro é o que te permite revisar a memória com cabeça de editor, não de leitor passivo.
user
Perfil e preferências de quem opera
Quem você é, o que faz, como gosta de trabalhar, quais tons e formatos prefere. Exemplo: "trabalha com data engineering, prefere respostas com código Python em vez de SQL quando possível, não gosta de respostas longas sem bullets". Persistente e raramente decai.
feedback
Correções explícitas
Coisas que o agente fez errado e você corrigiu, ou confirmou como certas. Exemplo: "não use 'aproveitamento' como tradução de 'leverage', use 'uso estratégico' ou deixe em inglês". Peso alto na hora da aplicação.
project
Fatos do trabalho atual
Contexto específico do projeto que não mora no código-fonte. Exemplo: "o cliente chama-se Contoso, o deadline é 15 de abril, o stack é Next.js + Supabase, o analytics roda no Cube". Decai rápido quando o projeto muda.
reference
Ponteiros para sistemas externos
URLs, IDs, caminhos para dashboards, issue trackers, documentos. Exemplo: "dashboard principal: https://grafana.corp/d/xyz, issue tracker: jira/ENG, doc de arquitetura: confluence/ARCH-42". Útil como atalho de navegação.
✏️ Revisar, editar, limpar
O DeerFlow expõe a memória como uma lista editável na UI. Você lê cada item, corrige texto inline, move de categoria, remove, arquiva. Isso é deliberado — é a diferença principal entre memória útil e memória envenenada. Memória que você nunca revisa vira memória ruim em algumas semanas.
🎯 Operações disponíveis
- •Edição inline — clica e reescreve. Útil quando o agente salvou o fato com fraseado ruim.
- •Delete com confirmação — some de vez. Não há undo, por isso o dialog.
- •Merge — quando dois itens dizem quase a mesma coisa, funde em um.
- •Export — JSON para backup ou migração. Importante antes de experimentos grandes.
- •Mover categoria — arrastar de project para reference, por exemplo.
💡 Hábito semanal
Reserve 10 minutos por semana para abrir o painel de memória e fazer uma revisão rápida. Você vai achar: (1) fatos duplicados que precisam de merge, (2) fatos obsoletos de projetos antigos para arquivar, (3) itens mal categorizados. Em um mês, sua memória vira um ativo em vez de um passivo.
⚖️ Quando ajuda, quando atrapalha
Memória não é universalmente boa. Existem tarefas em que ela melhora dramaticamente os resultados, e tarefas em que ela os piora — no limite, memory poisoning é quando fatos antigos ou errados contaminam decisões novas. Saber quando desligar a memória é tão importante quanto saber quando mantê-la.
✓ Quando memória ajuda
- ✓Pesquisas continuadas sobre o mesmo tema
- ✓Trabalho em projeto único por semanas
- ✓Preferências de estilo/formato que você cansa de repetir
- ✓Correções explícitas que você quer que o agente lembre
✗ Quando memória atrapalha
- ✗Exploração aberta de um tema novo
- ✗Tarefa crítica que precisa de avaliação sem viés
- ✗Quando você quer uma segunda opinião "limpa"
- ✗Mudou de projeto e o agente ainda assume o antigo
🚨 Memory poisoning é real
Um fato salvo errado, um fato que era verdade e virou mentira, uma preferência antiga — qualquer um desses pode guiar o agente por meses se você não revisar. O sintoma é sutil: respostas "coerentes" que seguem uma premissa inválida. A cura é a revisão semanal.
Dica: quando uma resposta vem estranha, a primeira checagem é "o que a memória tem sobre este assunto?". Às vezes a resposta está exatamente lá.
🧪 Lab: projeto em 3 sessões
A única forma de sentir como a memória se comporta é fazer um experimento longitudinal pequeno. Três sessões separadas no tempo, mesma "persona" de projeto, com uma contradição intencional na sessão 3. O objetivo é ver com os olhos o que é lembrado, o que é esquecido, o que é sobrescrito.
🎯 O que você vai fazer
Criar um "projeto fake" com alguns fatos iniciais, retomar em uma segunda sessão para validar o que o agente lembra sozinho, e na terceira sessão introduzir uma contradição deliberada para ver como a memória se atualiza (ou não).
📊 Por que esse lab
Memória só revela seu comportamento através do tempo. Um único turno mostra nada. A continuidade mostra tudo: o que persiste, o que decai, o que sobrescreve. Sem isso, memória é folclore; com isso, vira ferramenta.
Sessão 1 — estabelecer contexto
Abra sessão nova. Conte ao agente que você está começando um projeto fictício (exemplo: lançar uma newsletter de AI/ML, chamada "Silicon PT", stack Ghost, público Brasil, tom técnico-irônico). Peça ajuda em algo pequeno (gerar 5 ideias de pauta). Ao final, abra o painel de memória e confira o que foi salvo. Anote os itens.
Sessão 2 — retomar
No dia seguinte (ou algumas horas depois), abra uma sessão nova. Pergunte algo como "gere mais 3 ideias de pauta para o projeto que começamos" sem relembrar o nome ou stack. Veja se o agente recupera sozinho. Se sim, a memória funcionou; se não, ela não estava tão completa quanto parecia.
Sessão 3 — contradição
Outra sessão nova. Diga que decidiu trocar o stack para Substack (contradizendo o Ghost). Peça uma tarefa que envolva stack. Observe: o agente aceita? confirma? pede confirmação? E o mais importante: a memória antiga foi sobrescrita ou uma nova foi adicionada? Abra o painel e confira.
Anotar as observações
Quantos itens foram criados no total? Quais categorias? O agente precisou de dica para recuperar contexto? A contradição resultou em sobrescrita, merge, ou dois itens conflitantes? Isso te dá um modelo mental concreto do comportamento da memória.
📝 Resumo do Módulo
Próximo Módulo:
1.7 — 📲 Integrações de bolso
Telegram, Slack, Feishu/WeChat/WeCom para falar com o agente fora do navegador — e LangSmith/Langfuse para ver o que ele fez.