Comparação de Provedores de Memória para Agentes: Política de Captura e Auto-Hospedagem

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

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

Este guia compara os backends de memória que vêm como plugins de memória externa do Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne e Memori — e explica como eles se encaixam em pilhas mais amplas de sistemas de IA. Os mesmos provedores aparecem no OpenClaw e em outras ferramentas de agentes por meio de integrações da comunidade ou oficiais. O hub de Memória de Sistemas de IA](https://www.glukhov.org/pt/ai-systems/memory/) lista este artigo junto com o Cognee e guias relacionados.

Para a memória central limitada específica do Hermes (MEMORY.md e USER.md), comportamento de congelamento e gatilhos, consulte o Sistema de Memória do Hermes Agent](https://www.glukhov.org/pt/ai-systems/hermes/hermes-agent-memory-system/). Para contexto sobre como os provedores de memória nativos do Hermes contribuem para sua vantagem crescente de adoção em relação ao OpenClaw — incluindo estrelas do GitHub, rankings de tokens do OpenRouter e comparações de tamanho do ecossistema — veja OpenClaw vs Hermes Agent: Estrelas, Downloads e Uso 2026.

Existe outro eixo que importa tanto quanto a qualidade de recuperação: a 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 gravação antes que ela se torne contexto futuro. Para agentes de longa duração, essas diferenças podem importar mais do que alguns pontos a mais em um benchmark de recuperação — veja Laços de Memória Auto-Reforçantes 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 de exemplo.

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

Dependências externas. Todo provedor externo, exceto o Holographic, requer pelo menos uma chamada de serviço externo — um LLM para extração de memória, um modelo de incorporação (embedding) 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 totalmente auto-hospedada. Hindsight, ByteRover e Mnemosyne agrupam ou eliminam a maior parte das dependências; Honcho, Mem0 e Supermemory exigem a maior quantidade de peças móveis. Quando um provedor suporta Ollama ou qualquer endpoint compatível com OpenAI, você pode rotear as chamadas de LLM e embedding para um modelo local e manter os dados fora de servidores de terceiros por completo.

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  # Verificar o que está ativo
hermes memory off     # Desativar 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 a “posso executar isso?”. 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 se um humano ou política pode intervir antes que se torne durável? Veja Laços de Memória Auto-Reforçantes em Agentes de IA para entender por que este eixo importa.

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 junto com a memória existente — o USER.md permanece intacto, 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 resumo de sessão, derivação de representação de usuário e raciocínio dialético; um modelo de embedding 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, de modo que a inferência pode permanecer local. O slot de embedding 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 embedding 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 ajustes 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 de peer.chat() (1-5 recomendado)
• dialecticDepth (padrão 1): Passadas .chat() por invocação (limitado a 1-3)
• recallMode (padrão ‘hybrid’): hybrid (auto+ferramentas), context (somente injeção), tools (somente ferramentas)
• writeFrequency (padrão ‘async’): Momento de descarte: async, turn, session ou inteiro N
• observationMode (padrão ‘directional’): directional (todos ativos) ou unified (pool compartilhado)

Modos de observação e auto-modelagem. directional, o padrão para configurações novas, permite que tanto os pares de usuário quanto os pares de IA se observem a si mesmos e uns aos outros — raciocínio dialético mais rico, mas isso também significa que mensagens autoradas 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 de sua própria saída. Qualquer pessoa especificamente preocupada com conclusões geradas retroalimentando o raciocínio futuro — veja Laços de Memória Auto-Reforçantes 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 LLM). Seleciona automaticamente prompts de inicialização fria vs quentes.

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

Configuração:

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

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

Gerenciamento 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á a você controle total sobre o armazenamento de sua memória.

Dependências externas: O OpenViking requer um VLM (modelo de visão-linguagem) para processamento semântico e extração de memória, e um modelo de embedding 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 embeddings, os provedores suportados incluem OpenAI, Volcengine (Doubao), Jina, Voyage e — via Ollama — qualquer modelo de embedding servido localmente. O assistente interativo openviking-server init pode detectar a RAM disponível e recomendar modelos Ollama adequados (por exemplo, Qwen3-Embedding 8B para embeddings, 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 de usuário versus memória de agente. O modelo de identidade do OpenViking pode separar o espaço de nomes 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ê deseja isolar o estado autorado pelo assistente do estado autorado pelo usuário.

Configuração:

pip install openviking
openviking-server init   # assistente interativo (recomenda modelos Ollama para configuração local)
openviking-server
hermes memory setup  # selecionar "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 LLM em cada operação de 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 a você 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 embedding 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 rodar localmente. Uma pilha Mem0 totalmente local, sem nuvem, é viável: Ollama para LLM, Ollama para embeddings, 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 desduplicação e atualização. Isso é conveniente, mas significa que a procedência da extração importa — uma conclusão gerada pelo assistente pode se tornar estruturalmente indistinguível de um fato declarado pelo usuário, a menos que o caminho de captura a filtre antes da execução da extração.

Ferramentas: mem0_profile, mem0_search, mem0_conclude.

Configuração:

pip install mem0ai
hermes memory setup  # selecionar "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: recuperação baseada em grafo de conhecimento com relacionamentos de 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 recuperação executa quatro estratégias de recuperação em paralelo (semântica, palavra-chave/BM25, travessia de grafo, temporal), depois mescla e reordena resultados usando fusão de rank recíproco.

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). Embeddings e reclassificação (reranking) usam modelos locais de processo padrão (SentenceTransformers; a imagem Docker gorda /hindsight-all inclui BGE + MiniLM), e você pode trocá-los por outros modelos locais ou um endpoint externo compatível com OpenAI / TEI — por exemplo, Qwen3-Embedding-0.6B e BGE-reranker-v2-m3 em CPU. O PostgreSQL é incluído via um diretório de dados pg0 gerenciado, ou você pode apontar o Hindsight para uma instância externa de PostgreSQL. Para um caminho generativo totalmente local, defina HINDSIGHT_API_LLM_PROVIDER para um servidor local compatível com OpenAI (Ollama ou llama.cpp); retain e recall funcionam totalmente, e reflect precisa de um modelo capaz de chamada de ferramentas.

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

Configuração:

hermes plugins install hindsight
hermes memory setup hindsight   # selecionar local_external para uma API Hindsight separada

O modo nuvem ainda aceita uma chave de API em ~/.hermes/.env. A instalação auto-hospedada usa Docker Compose contra PostgreSQL embutido ou existente — veja o passo a passo linkado abaixo. Requer um par cliente/API do Hindsight atual (a documentação do plugin cita >= 0.4.22).

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

• mode: cloud, local ou local_external
• 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 o passo a passo completo de auto-hospedagem — Docker Compose, embeddings e reclassificação local, controle de caminho de escrita (auto_retain), e conexão local_external do Hermes — veja Hindsight para Hermes Agent: Memória Auto-Hospedada com LLMs Locais.

Para higiene de memória conservadora, definir auto_retain=false enquanto deixa auto_recall=true vale a pena considerar — a recuperaçã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 de evidência das memórias 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 roda localmente no seu próprio hardware.

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

auto_extract é false por padrão, então o Holographic pode operar principalmente como um pequeno banco de dados explícito de fatos 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 desejam captura automática.

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

Configuração:

hermes memory setup  # selecionar "holographic"

RetainDB

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

O RetainDB usa compressão de delta para armazenar atualizações de memória eficientemente e recuperação híbrida (vetorial + BM25 + reclassificação) para apresentar 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 LLM do RetainDB, o pipeline de embedding e a reclassificação rodam todos na infraestrutura de nuvem própria 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 de conversa são enviados aos servidores do RetainDB para processamento e armazenamento. Se a soberania dos dados ou a operação offline importarem para o 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 RetainDB com o Hermes cresceu além de um banco de dados de memória remoto — agora inclui síntese dialética e um auto-modelo 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 da fonte de interpretação gerada, a mesma preocupação que se aplica ao modo directional do Honcho.

Configuração:

hermes memory setup  # selecionar "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 incluídos no Hermes — ele vem como um plugin de provedor separado do Hermes, mas se integra através da mesma interface MemoryProvider. Sua principal vantagem é o controle: a autosave de conversa pode ser restrita por papel ou desativada completamente com sync_roles: [], o registro de resultados de ferramentas está desativado por padrão, operações explícitas de lembrar/recuperar/esquecer permanecem disponíveis independentemente, e versões mais novas incluem supressão opcional de auto-eco em torno das 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, triplas temporais, fatos canônicos e consolidação.

O Mnemosyne também implementa gravações estagiadas específicas do provedor para memory.write_approval do Hermes, embora a aprovação de provedores externos ainda não seja padronizada entre o Hermes, então este caminho deve ser testado contra as versões exatas sendo implantadas. 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 especificamente apertaram a validação de conflito, o comportamento de exclusão e o tratamento de auto-eco — veja Laços de Memória Auto-Reforçantes em Agentes de IA para a auditoria de produção que motivou a mudança de validação de conflito.

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 consciente 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 maior superfície de realimentação, já que ações, decisões do modelo e resultados de ferramentas podem todos se tornar memória estruturada durável.

Diferente dos provedores queprimamente injetam um grande bloco de memória antes de cada turno, o Memori expõe ferramentas explícitas de recuperação e resumo de recuperaçã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 realimentação no lado da escrita — turnos concluídos e rastros de execução ainda podem ser capturados automaticamente em segundo plano, então o Memori se adapta a usuários que desejam que um agente aprenda com trabalho anterior mais do que se adapta a instalações que exigem retenção estritamente explícita.

Configuração:

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

ByteRover

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

O ByteRover armazena memória como uma árvore de contexto markdown estruturada — uma hierarquia de arquivos de domínio, tópico e subtópico — em vez de vetores de embedding ou um banco de dados. Um LLM lê o conteúdo de origem, raciocina sobre ele e coloca o conhecimento extraído no local correto na hierarquia. A recuperação é busca de 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 e busca de memória (18 provedores suportados, incluindo Anthropic, OpenAI, Google, Ollama e qualquer endpoint compatível com OpenAI através do slot de provedor openai-compatible). Ele não requer modelo de embedding 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 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 próximo 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  # selecionar "byterover"

Supermemory

Melhor para: fluxos de trabalho enterprise 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 em nuvem do Supermemory lida com toda a inferência LLM e o servidor de embedding no lado do servidor — você fornece apenas uma chave de API do Supermemory. A auto-hospedagem está disponível exclusivamente como um adicional de plano enterprise e é implantada em 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 adições opcionais). Não há caminho de auto-hospedagem baseado em Docker ou local — a arquitetura está fortemente acoplada à computação de borda dos Cloudflare Workers. Para usuários que precisam de soberania total dos dados sem um contrato enterprise, 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, fazendo buffer da conversa e ingerindo-a no final da sessão, reset ou compressão. Isso produz um contexto de entidade e perfil mais rico do que gravações de fatos isolados, mas também significa que o texto do assistente gerado faz parte do material apresentado ao pipeline de extração de memória, não apenas as declarações do usuário.

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

Configuração:

hermes memory setup  # selecionar "supermemory"

Como escolher

Em vez de escolher um vencedor global, combine o provedor com a tarefa:

• Memória local explícita mais simples: Holographic — zero dependências, auto_extract desativado 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 auto-modelagem conservadora
• 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 embedding: ByteRover — árvore de contexto markdown simples
• Cercamento de contexto enterprise: Supermemory — ingestão de grafo de sessão, hospedado em Cloudflare
• Atualizações de alta frequência, sem necessidade de auto-hospedagem: RetainDB — compressão de delta, auto-modelo dialético

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

O ecossistema mais amplo de memória Hermes de terceiros

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

• Scope Recall trata o SQLite como verdade durável, mantendo a captura bruta de conversa escopada separadamente, com um companheiro opcional turn-closure-audit para revisão pós-turno conservadora — ele separa a evidência bruta do diário da 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 se destaca em memória de projeto ou institucional estruturada, mas é mais automático do que um armazenamento explícito de fatos; 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ântica de exclusão — relevante após os problemas de registros derivados órfãos discutidos para o Mnemosyne acima.
• XMemo inclui padrões conservadores: a captura de linha do tempo automática pode permanecer desativada, e a exclusão pode ser restrita. A adoção ainda é recente o suficiente para não justificar uma seção completa.

Guias Relacionados

• Hub de Memória de Sistemas de IA — escopo deste subgrupo e links para guias do Cognee
• Laços de Memória Auto-Reforçantes em Agentes de IA — por que a política de captura e os 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 central de dois arquivos antes dos plugins
• Configuração de produção do Hermes Agent — conexão de perfis para provedores na prática