Provedores de Memória de Agentes Comparados: Política de Captura e Self-Hosting

Atualizado em setembro de 2026: adicionados Mnemosyne e Memori, expandida a configuração de Honcho e Hindsight, e incluída uma comparação de políticas de captura ao lado da tabela original de infraestrutura.

Assistentes modernos ainda esquecem tudo quando você fecha a aba, a menos que algo persista além da janela de contexto. Provedores de memória para agentes são serviços ou bibliotecas que armazenam fatos e resumos entre sessões — frequentemente integrados como plugins para que a estrutura base permaneça enxuta enquanto a memória escala.

Este guia compara os backends de memória que são fornecidos como plugins externos de memória para o Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne e Memori — e explica como eles se encaixam em pilhas de sistemas de IA mais amplos. Os mesmos fornecedores aparecem no OpenClaw e em outras ferramentas de agentes por meio de integrações comunitárias ou oficiais. O hub de Memória de Sistemas de IA AI Systems Memory hub lista este artigo junto com o Cognee e guias relacionados.

Para a memória do núcleo limitada específica do Hermes (MEMORY.md e USER.md), comportamento de congelamento e gatilhos, consulte Sistema de Memória do Hermes Agent Hermes Agent Memory System. Para contexto sobre como os provedores de memória nativos do Hermes contribuem para sua crescente vantagem de adoção em relação ao OpenClaw — incluindo estrelas no GitHub, rankings de tokens do OpenRouter e comparações do tamanho do ecossistema — consulte OpenClaw vs Hermes Agent: Stars, Downloads & Usage 2026.

Existe outro eixo que importa tanto quanto a qualidade de recuperação: governança de memória. Os provedores diferem drasticamente no que capturam automaticamente, se a saída gerada pelo assistente pode se tornar memória durável, se as reflexões são armazenadas como fatos, como as contradições são resolvidas e se um humano pode revisar uma escrita antes que ela se torne contexto futuro. Para agentes de longa duração, essas diferenças podem importar mais do que alguns pontos adicionais em um benchmark de recordação — veja Laços de Memória Auto-Reforçados em Agentes de IA para entender por que a captura automática pode transformar uma conclusão gerada em uma premissa futura, e Mnemosyne para Hermes Agent: Início Rápido de Memória Local para uma configuração conservadora trabalhada.

O Hermes Agent lista dez plugins de provedores externos de memória para conhecimento persistente e entre sessões — os oito originais mais o Mnemosyne e o Memori. Apenas um provedor externo pode estar ativo de cada vez. Os arquivos integrados MEMORY.md e USER.md permanecem carregados junto com ele — de forma aditiva, não substitutiva.

Dependências externas. Todos os provedores externos, exceto o Holographic, exigem pelo menos uma chamada a serviço externo — um LLM para extração de memória, um modelo de incorporação para busca semântica ou um banco de dados como PostgreSQL para armazenamento. Essas dependências têm implicações diretas para privacidade, custo e se sua pilha de memória pode ser executada totalmente auto-hospedada. Hindsight, ByteRover e Mnemosyne empacotam ou eliminam a maior parte das dependências; Honcho, Mem0 e Supermemory exigem as mais partes móveis. Quando um provedor suporta Ollama ou qualquer endpoint compatível com OpenAI, você pode direcionar as chamadas de LLM e incorporação para um modelo local e manter os dados fora de servidores de terceiros inteiramente.

Ativação com o Hermes Agent

As etapas de linha de comando abaixo espelham as tabelas na folha de dicas da CLI do Hermes Agent.

hermes memory setup   # Seletor interativo + configuração
hermes memory status  # Verifique o que está ativo
hermes memory off     # Desative provedor externo

Ou manualmente em ~/.hermes/config.yaml:

memory:
  provider: openviking  # ou honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory, mnemosyne, memori

Comparação de Provedores

Política de captura e governança

Armazenamento e dependências respondem “posso executar isto?”. A tabela abaixo responde a uma pergunta diferente que importa tanto quanto para agentes de longa duração: o que é gravado sem ser solicitado, e um humano ou política pode intervir antes que se torne durável? Veja Laços de Memória Auto-Reforçados em Agentes de IA para entender por que este eixo é importante.

Estas são categorias de risco arquitetural, não pontuações de qualidade — um provedor sofisticado cuidadosamente configurado pode ser mais seguro na prática do que um simples mal configurado.

Detalhamento

Honcho

Melhor para: sistemas multi-agente, contexto entre sessões, alinhamento usuário-agente.

O Honcho funciona ao lado da memória existente — o USER.md permanece como está, e o Honcho adiciona uma camada adicional de contexto. Ele modela conversas como pares trocando mensagens — um par de usuário mais um par de IA por perfil do Hermes, todos compartilhando um espaço de trabalho.

Dependências externas: O Honcho requer um LLM para resumir sessões, derivar representações do usuário e raciocínio dialético; um modelo de incorporação para busca semântica entre observações; PostgreSQL com a extensão pgvector para armazenamento vetorial; e Redis para cache. A nuvem gerenciada em api.honcho.dev cuida de tudo isso para você. Para implantações auto-hospedadas (Docker, K3s ou Fly.io), você fornece suas próprias credenciais. O slot de LLM aceita qualquer endpoint compatível com OpenAI, incluindo Ollama e vLLM, para que a inferência possa permanecer local. O slot de incorporação tem como padrão openai/text-embedding-3-small, mas suporta provedores configuráveis via LLM_EMBEDDING_API_KEY e LLM_EMBEDDING_BASE_URL — qualquer servidor de incorporação compatível com OpenAI funciona, incluindo opções locais como vLLM com um modelo BGE.

Ferramentas: honcho_profile (ler/atualizar cartão do par), honcho_search (busca semântica), honcho_context (contexto de sessão — resumo, representação, cartão, mensagens), honcho_reasoning (sintetizado por LLM), honcho_conclude (criar/excluir conclusões).

Principais parâmetros de configuração:

• contextCadence (padrão 1): Turnos mínimos entre atualizações da camada base
• dialecticCadence (padrão 2): Turnos mínimos entre chamadas LLM peer.chat() (1-5 recomendado)
• dialecticDepth (padrão 1): Passagens .chat() por invocação (limitado a 1-3)
• recallMode (padrão ‘hybrid’): hybrid (auto+ferramentas), context (apenas injeção), tools (apenas ferramentas)
• writeFrequency (padrão ‘async’): Temporalidade de descarte: async, turn, session ou inteiro N
• observationMode (padrão ‘directional’): directional (todos ativos) ou unified (pilha compartilhada)

Modos de observação e autoprojeto. directional, o padrão para novas configurações, permite que os pares do usuário e da IA observem a si mesmos e entre si — raciocínio dialético mais rico, mas isso também significa que mensagens escritas por IA contribuem para o modelo do Honcho sobre a própria IA. unified é a opção mais conservadora: a IA modela o usuário a partir das mensagens do usuário sem construir o laço correspondente de auto-observação a partir da sua própria saída. Qualquer pessoa especificamente preocupada com conclusões geradas alimentando o raciocínio futuro — veja Laços de Memória Auto-Reforçados em Agentes de IA — deve tratar unified como o padrão mais seguro.

Arquitetura: Injeção de contexto em duas camadas — camada base (resumo da sessão + representação + cartão do par) + suplemento dialético (raciocínio do LLM). Seleciona automaticamente prompts frios vs. quentes.

Mapeamento multi-par: O espaço de trabalho é um ambiente compartilhado entre perfis. O par do usuário (peerName) é uma identidade humana global. O par da IA (aiPeer) é um por perfil do Hermes (hermes padrão, hermes.<perfil> para os outros).

Configuração:

hermes memory setup  # selecione "honcho"
# ou legado: hermes honcho setup

Configuração: $HERMES_HOME/honcho.json (local do perfil) ou ~/.honcho/config.json (global).

Gestão de perfis:

hermes profile create coder --clone  # Cria hermes.coder com espaço de trabalho compartilhado
hermes honcho sync                   # Preenche pares de IA para perfis existentes

OpenViking

Melhor para: gerenciamento de conhecimento auto-hospedado com navegação estruturada.

O OpenViking fornece uma hierarquia de sistema de arquivos com carregamento por camadas. É gratuito, auto-hospedado, e dá controle total sobre seu armazenamento de memória.

Dependências externas: O OpenViking requer um VLM (modelo de linguagem-visual) para processamento semântico e extração de memória, e um modelo de incorporação para busca vetorial — ambos são obrigatórios. Os provedores de VLM suportados incluem OpenAI, Anthropic, DeepSeek, Gemini, Moonshot e vLLM (para implantação local). Para incorporações, os provedores suportados incluem OpenAI, Volcengine (Doubao), Jina, Voyage e — via Ollama — qualquer modelo de incorporação servido localmente. O assistente interativo openviking-server init pode detectar a RAM disponível e recomendar modelos Ollama adequados (ex.: Qwen3-Embedding 8B para incorporações, Gemma 4 27B para VLM) e configurar tudo automaticamente para uma configuração totalmente local, sem chave de API. Nenhum banco de dados externo é necessário; o OpenViking armazena a memória no sistema de arquivos.

Ferramentas: viking_search, viking_read (por camadas), viking_browse, viking_remember, viking_add_resource.

Memória do usuário versus memória do agente. O modelo de identidade do OpenViking pode separar o namespace de memória do usuário de um par de assistente opcional. Essa separação é importante para a higiene de memória: fatos sobre o usuário e experiência gerada pelo agente não precisam compartilhar a mesma política de retenção, o que é uma propriedade útil se você quiser isolar o estado autoral do assistente do estado autoral do usuário.

Configuração:

pip install openviking
openviking-server init   # assistente interativo (recomenda modelos Ollama para configuração local)
openviking-server
hermes memory setup  # selecione "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Melhor para: gerenciamento de memória sem intervenção com extração automática.

O Mem0 lida com a extração de memória no lado do servidor via uma chamada de LLM em cada operação add — ele lê a conversa, extrai fatos discretos, remove duplicatas e os armazena. A API de nuvem gerenciada cuida de toda a infraestrutura. A biblioteca de código aberto e o servidor auto-hospedado dão controle total.

Dependências externas: O Mem0 requer um LLM para extração de memória (padrão: OpenAI gpt-4.1-nano; 20 provedores suportados, incluindo Ollama, vLLM e LM Studio para modelos locais) e um modelo de incorporação para recuperação (padrão: OpenAI text-embedding-3-small; 10 provedores suportados, incluindo Ollama e HuggingFace para modelos locais). O armazenamento usa Qdrant em /tmp/qdrant no modo biblioteca, ou PostgreSQL com pgvector no modo servidor auto-hospedado — ambos podem ser executados localmente. Uma pilha de Mem0 totalmente local e sem nuvem é possível: Ollama para LLM, Ollama para incorporações e uma instância local de Qdrant, tudo configurado via Memory.from_config.

O Mem0 é fundamentalmente um sistema de extração: um LLM transforma material conversacional em memórias discretas e executa lógica de remoção de duplicatas e atualização. Isso é conveniente, mas significa que a procedência da extração é importante — uma conclusão do assistente gerada pode se tornar estruturalmente indistinguível de um fato declarado pelo usuário a menos que o caminho de captura o filtre antes que a extração seja executada.

Ferramentas: mem0_profile, mem0_search, mem0_conclude.

Configuração:

pip install mem0ai
hermes memory setup  # selecione "mem0"
echo "MEM0_API_KEY=sua-chave" >> ~/.hermes/.env

Configuração: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Melhor para: recordação baseada em grafo de conhecimento com relacionamentos entre entidades.

O Hindsight constrói um grafo de conhecimento da sua memória, extraindo entidades e relacionamentos. Sua ferramenta única reflect executa síntese entre memórias — combinando múltiplas memórias em novos insights. A recordação executa quatro estratégias de recuperação em paralelo (semântica, palavra-chave/BM25, travessia de grafo, temporal), depois mescla e reordena os resultados usando fusão de ranking recíproca.

Dependências externas: O Hindsight requer um LLM para extração de fatos e entidades em chamadas retain, e para síntese em chamadas reflect (padrão: OpenAI; provedores suportados incluem Anthropic, Gemini, Groq, Ollama, LM Studio e qualquer endpoint compatível com OpenAI). O modelo de incorporação e o modelo de reclassificação por cross-encoder são embutidos dentro do próprio Hindsight — eles são executados localmente dentro do pacote hindsight-all e não requerem API externa. O PostgreSQL também é embutido na instalação Python embutida via um diretório de dados pg0 gerenciado; você pode alternativamente apontar o Hindsight para uma instância externa do PostgreSQL. Para uma configuração totalmente local e sem nuvem, defina HINDSIGHT_API_LLM_PROVIDER=ollama e aponte para um modelo Ollama local — retain e recall funcionam totalmente; reflect requer um modelo com capacidade de chamada de ferramenta (ex.: qwen3:8b).

Ferramentas: hindsight_retain, hindsight_recall, hindsight_reflect (síntese única entre memórias).

Configuração:

hermes memory setup  # selecione "hindsight"
echo "HINDSIGHT_API_KEY=sua-chave" >> ~/.hermes/.env

Instala automaticamente hindsight-client (nuvem) ou hindsight-all (local). Requer >= 0.4.22.

Configuração: $HERMES_HOME/hindsight/config.json

• mode: cloud ou local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (padrão)

UI local: hindsight-embed -p hermes ui start

Para uma higiene de memória conservadora, definir auto_retain=false enquanto mantém auto_recall=true vale a pena considerar — a recordação semântica permanece disponível, mas os turnos concluídos não entram mais na memória de longo prazo automaticamente. Trate a saída de reflect como conhecimento derivado sintetizado entre memórias, não como uma observação independente com o mesmo peso evidenciário das memórias a partir das quais foi construído.

Holographic

Melhor para: configurações focadas em privacidade com armazenamento apenas local.

O Holographic usa álgebra HRR (Holographic Reduced Representation) para codificação de memória, com pontuação de confiança para confiabilidade da memória. Nenhuma dependência de nuvem — tudo funciona localmente no seu próprio hardware.

Dependências externas: Nenhuma. O Holographic não requer LLM, modelo de incorporação, banco de dados nem conexão de rede. A codificação de memória é feita inteiramente através da álgebra HRR executando em processo. Isso o torna único entre todos os provedores nesta comparação — é o único que opera com zero chamadas externas. O compromisso é que a qualidade de recuperação é menor do que a busca semântica baseada em incorporações, e não há síntese entre memórias como reflect do Hindsight. Para usuários onde privacidade e operação sem dependências são inegociáveis, o Holographic é a única opção que entrega isso incondicionalmente.

auto_extract tem como padrão false, então o Holographic pode operar principalmente como um pequeno banco de dados de fatos explícitos com pontuações de confiança, em vez de um pipeline autônomo de transcrição-para-memória. Combinado com suas zero dependências, isso o torna uma das duas opções mais simples — junto com o Mnemosyne — para leitores que deliberadamente não querem captura automática.

Ferramentas: 2 ferramentas para operações de memória via álgebra HRR.

Configuração:

hermes memory setup  # selecione "holographic"

RetainDB

Melhor para: atualizações de alta frequência com compressão delta.

O RetainDB usa compressão delta para armazenar atualizações de memória eficientemente e recuperação híbrida (vetorial + BM25 + reclassificação) para destacar contexto relevante. É baseado em nuvem com um custo de $20/mês, com todo o processamento de memória tratado no lado do servidor.

Dependências externas: As chamadas de LLM, o pipeline de incorporação e a reclassificação do RetainDB são executados todos na própria infraestrutura de nuvem do RetainDB — você fornece apenas uma RETAINDB_KEY. A extração de memória usa Claude Sonnet no lado do servidor. Não há opção de auto-hospedagem nem modo local. Todos os dados da conversa são enviados aos servidores do RetainDB para processamento e armazenamento. Se a soberania de dados ou operação offline forem importantes para seu caso de uso, este provedor não é adequado.

Ferramentas: retaindb_profile (perfil do usuário), retaindb_search (busca semântica), retaindb_context (contexto relevante para a tarefa), retaindb_remember (armazenar com tipo + importância), retaindb_forget (excluir memórias).

A integração do Hermes do RetainDB cresceu além de um banco de dados de memória remoto — agora inclui síntese dialética e um autoprojeto do agente, o que o coloca arquiteturalmente mais próximo do Honcho do que de um simples armazenamento vetorial. Isso é útil para continuidade, mas também aumenta a importância de separar fatos de origem de interpretação gerada, a mesma preocupação que se aplica ao modo directional do Honcho.

Configuração:

hermes memory setup  # selecione "retaindb"

Mnemosyne

Melhor para: memória local-first com controles granulares de retenção, armazenamento SQLite inspecionável, fatos estruturados, memória temporal e consolidação configurável.

O Mnemosyne não é um dos provedores de memória originais embutidos do Hermes — ele é fornecido como um plugin de provedor separado do Hermes, mas se integra através da mesma interface MemoryProvider. Sua principal vantagem é o controle: o autosave de conversa pode ser restrito por função ou desativado completamente com sync_roles: [], o registro de resultados de ferramentas está desligado por padrão, operações explícitas de lembrar/recuperar/esquecer permanecem disponíveis independentemente, e versões mais recentes incluem supressão opcional de auto-eco ao redor de fronteiras de compressão de contexto.

Dependências externas: Nenhuma para a instalação core; o extra embeddings adiciona busca vetorial local. O armazenamento é SQLite local com FTS5 e recuperação vetorial opcional. O sistema também mantém memória de trabalho, memória episódica, fatos estruturados, triplos temporais, fatos canônicos e consolidação.

O Mnemosyne também implementa escritas em estágios específicas do provedor para memory.write_approval do Hermes, embora a aprovação de provedores externos ainda não seja padronizada em todo o Hermes, então este caminho deve ser testado contra as versões exatas em implantação. A sofisticação adicional tem um custo: a memória derivada cria mais estados de ciclo de vida para inspecionar e limpar. Lançamentos recentes do Mnemosyne apertaram especificamente a validação de conflitos, o comportamento de exclusão e o tratamento de auto-eco — veja Laços de Memória Auto-Reforçados em Agentes de IA para a auditoria de produção que motivou a mudança na validação de conflitos.

Configuração:

python -m pip install "mnemosyne-memory[embeddings]" mnemosyne-hermes
mnemosyne-hermes install
hermes config set memory.provider mnemosyne

Para instalação completa e um passo a passo de configuração conservadora, veja Mnemosyne para Hermes Agent: Início Rápido de Memória Local.

Memori

Melhor para: agentes onde o histórico de execução importa tanto quanto o histórico de conversa.

O Memori é uma integração mais nova do Hermes focada em memória estruturada com consciência de ferramentas. Ele captura turnos concluídos junto com o contexto de execução disponível — uso de ferramentas, etapas de fluxo de trabalho, decisões, resultados e restrições — o que é excelente para lembrar trabalho operacional, mas também cria uma superfície de feedback maior, já que ações, decisões do modelo e resultados de ferramentas podem todos se tornar memória estruturada durável.

Ao contrário de provedores que primariamente injetam um grande bloco de memória antes de cada turno, o Memori expõe ferramentas explícitas de recordação e resumo de recordação, permitindo que o agente recupere contexto operacional quando realmente precisa, em vez de em cada prompt. Isso reduz a poluição do prompt, mas não remove sozinho o risco de feedback no lado da escrita — turnos concluídos e rastros de execução ainda podem ser capturados automaticamente em segundo plano, então o Memori atende melhor usuários que querem um agente para aprender de trabalhos anteriores do que instalações que exigem retenção estritamente explícita.

Configuração:

pip install hermes-memori
hermes memory setup  # selecione "memori"

ByteRover

Melhor para: memória local-first com armazenamento legível por humanos e auditável.

O ByteRover armazena memória como uma árvore de contexto de markdown estruturado — uma hierarquia de arquivos de domínio, tópico e subtópico — em vez de vetores de incorporação ou um banco de dados. Um LLM lê o conteúdo de origem, raciocina sobre ele e coloca o conhecimento extraído no lugar certo na hierarquia. A recuperação é busca em texto completo MiniSearch com fallback por camadas para busca impulsionada por LLM, sem necessidade de banco de dados vetorial.

Dependências externas: O ByteRover requer um LLM para curadoria de memória e busca (18 provedores suportados, incluindo Anthropic, OpenAI, Google, Ollama e qualquer endpoint compatível com OpenAI via o slot do provedor openai-compatible). Não requer modelo de incorporação nem banco de dados — a árvore de contexto é um diretório local de arquivos markdown simples. A sincronização em nuvem é opcional e usada apenas para colaboração em equipe; tudo funciona totalmente offline por padrão. Para uma configuração local totalmente autossuficiente, conecte o Ollama como o provedor (brv providers connect openai-compatible --base-url http://localhost:11434/v1) e nenhum dado sai da sua máquina.

O Hermes expõe auto_extract: false para desativar ganchos de curadoria automática, o que coloca o ByteRover perto do Holographic e do Mnemosyne no grupo de provedores onde a captura automática é opt-in em vez de padrão.

Ferramentas: 3 ferramentas para operações de memória.

Configuração:

hermes memory setup  # selecione "byterover"

Supermemory

Melhor para: fluxos de trabalho empresariais com cercamento de contexto e ingestão de grafo de sessão.

O Supermemory fornece cercamento de contexto (isolando memória por contexto) e ingestão de grafo de sessão (importando históricos de conversa inteiros). Ele extrai automaticamente memórias, constrói perfis de usuário e executa recuperação híbrida combinando busca semântica e por palavra-chave. A API de nuvem gerenciada é o alvo principal de implantação.

Dependências externas: O serviço de nuvem do Supermemory cuida de toda a inferência de LLM e incorporação no lado do servidor — você fornece apenas uma chave de API do Supermemory. O auto-hospedagem está disponível exclusivamente como um adicional do plano empresarial e é implantado nos Cloudflare Workers; requer que você forneça PostgreSQL com a extensão pgvector (para armazenamento vetorial) e uma chave de API da OpenAI (obrigatória, com Anthropic e Gemini como adicionais opcionais). Não há caminho de auto-hospedagem baseado em Docker ou local — a arquitetura está fortemente acoplada ao compute de borda dos Cloudflare Workers. Para usuários que precisam de soberania total de dados sem um contrato empresarial, este provedor não é a escolha certa.

A integração atual do Hermes escreve uma sessão completa através do endpoint de conversa do Supermemory como uma unidade, em buffer a conversa e ingerindo-a no final da sessão, reset ou compressão. Isso produz contexto de entidade e perfil mais rico do que escritas de fatos isoladas, mas também significa que o texto do assistente gerado é parte do material apresentado ao pipeline de extração de memória, não apenas declarações do usuário.

Ferramentas: 4 ferramentas para operações de memória.

Configuração:

hermes memory setup  # selecione "supermemory"

Como escolher

Em vez de escolher um vencedor global, corresponda o provedor ao trabalho:

• Memória local explícita mais simples: Holographic — zero dependências, auto_extract desligado por padrão
• Memória local com controles de ciclo de vida mais ricos: Mnemosyne — SQLite, retenção granular, supressão de auto-eco
• Síntese pesada em grafos: Hindsight — grafo de conhecimento mais reflect
• Modelagem de par ou usuário: Honcho — raciocínio dialético, modo unified para autoprojeto conservador
• Conhecimento estilo sistema de arquivos: OpenViking — hierarquia viking:// por camadas
• Extração automática sem intervenção: Mem0 — extração de fatos baseada em LLM sem configuração
• Memória operacional/consciente de ferramentas: Memori — captura de turnos e rastros de execução
• Legível por humanos, auditável, sem pipeline de incorporação: ByteRover — árvore de contexto markdown simples
• Cercamento de contexto empresarial: Supermemory — ingestão de grafo de sessão, hospedado na Cloudflare
• Atualizações de alta frequência, sem necessidade de auto-hospedagem: RetainDB — compressão delta, autoprojeto dialético

Para configurações de provedor por perfil completas e padrões de fluxo de trabalho do mundo real, veja Configuração de produção do Hermes Agent.

O ecossistema de memória Hermes de terceiros mais amplo

O Hermes documenta uma interface de pacote/plugin para provedores externos de memória, incluindo diretórios instalados pelo usuário e pontos de entrada Python, então o ecossistema agora se estende além dos provedores com seções completas acima. Alguns valem a pena saber sem adicionar uma seção completa cada:

• Scope Recall trata o SQLite como verdade durável, mantendo a captura bruta de conversa separada, com um companheiro opcional turn-closure-audit para revisão pós-turno conservadora — ele separa evidência de journal bruto de memória semântica durável, em vez de tratar cada turno capturado como conhecimento de longo prazo imediatamente equivalente.
• Cognee é um pipeline de ingestão de grafo de conhecimento / ECL, não um plugin de memória conversacional do Hermes. Ele destaca em memória de projeto ou institucional estruturada, mas é mais automático do que um armazenamento de fatos explícito; veja o Início rápido de Auto-hospedagem do Cognee e Escolhendo o LLM certo para o Cognee em vez de tratá-lo como um provedor plug-and-play do Hermes.
• AgentMemory enfatiza eventos de origem, auditabilidade e semânticas de exclusão — relevante após as questões de registros derivados órfãos discutidos para o Mnemosyne acima.
• XMemo fornece padrões conservadores: a captura de linha do tempo automática pode permanecer desligada, e a exclusão pode ser restrita. A adoção ainda é cedo demais para justificar uma seção completa.

Guias relacionados

• AI Systems Memory hub — escopo deste subcluster e links para guias do Cognee
• Laços de Memória Auto-Reforçados em Agentes de IA — por que política de captura e portões de aprovação importam, em profundidade
• Mnemosyne para Hermes Agent: Início Rápido de Memória Local — instalação completa e configuração conservadora para o provedor Mnemosyne coberto acima
• Sistema de Memória do Hermes Agent — memória de dois arquivos central antes dos plugins
• Configuração de produção do Hermes Agent — conexão de perfis para provedores na prática