Provedores de Memória de Agentes Comparados — Honcho, Mem0, Hindsight e mais cinco
Oito backends plugáveis para memória persistente de agentes.
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 de agentes são serviços ou bibliotecas que mantêm fatos e resumos entre sessões — frequentemente integrados como plugins para que o framework permaneça leve enquanto a memória escala.
Este guia compara oito backends que são fornecidos como plugins de memória externa do Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover e Supermemory — e explica como eles se encaixam em stacks mais amplas de sistemas de IA. 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 lista este artigo junto com o Cognee e outros guias relacionados.
Para memória central limitada específica do Hermes (MEMORY.md e USER.md), comportamento de congelamento e gatilhos, consulte Sistema de Memória do Hermes Agent. Para contexto sobre como os oito provedores de memória nativos do Hermes contribuem para sua vantagem crescente de adoção em comparação com o OpenClaw — incluindo estrelas no GitHub, classificações de tokens no OpenRouter e comparações de tamanho do ecossistema — consulte OpenClaw vs Hermes Agent: Estrelas, Downloads e Uso 2026.
O Hermes Agent lista oito plugins de provedores de memória externa para conhecimento persistente e entre sessões. Apenas um provedor externo pode estar ativo por vez. Os arquivos MEMORY.md e USER.md integrados permanecem carregados junto com ele — de forma aditiva, não substitutiva.
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 stack de memória pode ser totalmente auto-hospedada. Hindsight e ByteRover agrupam ou eliminam a maioria das dependências; Honcho, Mem0 e Supermemory requerem as mais partes móveis. Onde um provedor suporta Ollama ou qualquer endpoint compatível com OpenAI, você pode encaminhar chamadas de LLM e incorporação para um modelo local e manter os dados completamente fora de servidores de terceiros.

Ativação com Hermes Agent
Os passos de linha de comando abaixo espelham as tabelas na folha de referência do 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
Comparação de Provedores
| Provedor | Armazenamento | Custo | Dependências Externas | Auto-hospedável | Recurso Único |
|---|---|---|---|---|---|
| Honcho | Nuvem/Auto-hospedado | Pago/Gratuito | LLM + Modelo de Embedding + PostgreSQL/pgvector + Redis | Sim — Docker / K3s / Fly.io | Modelagem dialética do usuário + contexto escopado por sessão |
| OpenViking | Auto-hospedado | Gratuito | LLM (VLM) + Modelo de Embedding | Sim — servidor local; assistente de inicialização nativo do Ollama | Hierarquia de sistema de arquivos + carregamento em camadas |
| Mem0 | Nuvem/Auto-hospedado | Pago/Gratuito (OSS) | LLM + Modelo de Embedding + Armazenamento Vetorial (Qdrant ou pgvector) | Sim — Docker Compose OSS; totalmente local possível | Extração de LLM no lado do servidor |
| Hindsight | Nuvem/Local | Gratuito/Pago | LLM + PostgreSQL embutido + embutidor integrado + reclassificador integrado | Sim — Docker ou Python embutido; totalmente local com Ollama | Grafos de conhecimento + síntese reflect |
| Holographic | Local | Gratuito | Nenhuma | Nativo — nenhuma infraestrutura necessária | Álgebra HRR + pontuação de confiança |
| RetainDB | Nuvem | $20/mês | Gerenciado na nuvem (LLM + recuperação nos servidores RetainDB) | Não | Compressão de delta |
| ByteRover | Local/Nuvem | Gratuito/Pago | Apenas LLM — sem modelo de embedding, sem banco de dados | Sim — local por padrão; Ollama suportado | Árvore de contexto baseada em arquivos; sem pipeline de embedding |
| Supermemory | Nuvem | Pago | LLM + PostgreSQL/pgvector (implantação enterprise na Cloudflare) | Apenas plano enterprise | Cercamento de contexto + ingestão de grafo de sessão |
Detalhamento
Honcho
Melhor para: sistemas multi-agente, contexto entre sessões, alinhamento usuário-agente.
Honcho roda ao lado da memória existente — USER.md permanece inalterado, e 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: Honcho requer um LLM para resumo de sessão, derivação de representação do usuário e raciocínio dialético; um modelo de embedding para busca semântica através das 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 do LLM aceita qualquer endpoint compatível com OpenAI, incluindo Ollama e vLLM, para que a inferência possa permanecer on-premises. 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 da sessão — resumo, representação, cartão, mensagens), honcho_reasoning (sintetizado por LLM), honcho_conclude (criar/deletar conclusões).
Principais parâmetros de configuração:
contextCadence(padrão 1): Mínimo de turnos entre atualizações da camada basedialecticCadence(padrão 2): Mínimo de turnos entre chamadas LLM depeer.chat()(1-5 recomendado)dialecticDepth(padrão 1): Passos.chat()por invocação (limitado a 1-3)recallMode(padrão ‘hybrid’):hybrid(auto+tools),context(injetar apenas),tools(apenas ferramentas)writeFrequency(padrão ‘async’): Timing de flush:async,turn,session, ou inteiro NobservationMode(padrão ‘directional’):directional(todos ligados) ouunified(pool compartilhado)
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 a frio vs. aquecidos.
Mapeamento multi-par: O espaço de trabalho é um ambiente compartilhado entre perfis. Par do usuário (peerName) é uma identidade humana global. Par de IA (aiPeer) é um por perfil do Hermes (hermes padrão, hermes.<perfil> para 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).
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.
OpenViking fornece uma hierarquia de sistema de arquivos com carregamento em camadas. É gratuito, auto-hospedado, e dá controle total sobre seu armazenamento de memória.
Dependências externas: 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. Provedores VLM suportados incluem OpenAI, Anthropic, DeepSeek, Gemini, Moonshot e vLLM (para implantação local). Para embeddings, 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 (ex. 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; OpenViking armazena a memória no sistema de arquivos.
Ferramentas: viking_search, viking_read (em camadas), viking_browse, viking_remember, viking_add_resource.
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 esforço com extração automática.
Mem0 lida com a extração de memória no lado do servidor via uma chamada LLM em cada operação add — ele lê a conversa, extrai fatos discretos, elimina 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: 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 stack Mem0 totalmente local, sem nuvem, é viável: Ollama para LLM, Ollama para embeddings, e uma instância local do Qdrant, tudo configurado via Memory.from_config.
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: recuperação baseada em grafos de conhecimento com relacionamentos de entidades.
Hindsight constrói um grafo de conhecimento de sua memória, extraindo entidades e relacionamentos. Sua ferramenta única reflect realiza síntese cruzada de memória — combinando múltiplas memórias em novos insights. A recuperação executa quatro estratégias de busca em paralelo (semântica, palavra-chave/BM25, travessia de grafo, temporal), depois mescla e reordena os resultados usando fusão de classificação recíproca.
Dependências externas: 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 embedding e o modelo de reclassificação cross-encoder estão embutidos no próprio Hindsight — eles rodam localmente dentro do pacote hindsight-all e não exigem API externa. PostgreSQL também está embutido com a instalação Python via um diretório de dados pg0 gerenciado; você pode alternativamente apontar o Hindsight para uma instância PostgreSQL externa. Para uma configuração totalmente local, sem nuvem, defina HINDSIGHT_API_LLM_PROVIDER=ollama e aponte para um modelo Ollama local — retain e recall funcionam totalmente; reflect requer um modelo capaz de chamar ferramentas (ex. qwen3:8b).
Ferramentas: hindsight_retain, hindsight_recall, hindsight_reflect (síntese cruzada de memória única).
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:cloudoulocalrecall_budget:low/mid/highmemory_mode:hybrid/context/toolsauto_retain/auto_recall:true(padrão)
UI Local: hindsight-embed -p hermes ui start
Holographic
Melhor para: configurações focadas em privacidade com armazenamento apenas local.
Holographic usa álgebra HRR (Representação Reduzida Holográfica) para codificação de memória, com pontuação de confiança para confiabilidade da memória. Sem dependência de nuvem — tudo roda localmente no seu próprio hardware.
Dependências externas: Nenhuma. 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 de álgebra HRR rodando no processo. Isso o torna único entre todos os oito provedores — é o único que opera com zero chamadas externas. A compensação é que a qualidade da recuperação é inferior à busca semântica baseada em embedding, e não há síntese cruzada de memória como o reflect do Hindsight. Para usuários onde privacidade e operação sem dependências são inegociáveis, Holographic é a única opção que entrega isso incondicionalmente.
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 de delta.
RetainDB usa compressão de delta para armazenar eficientemente atualizações de memória e recuperação híbrida (vetorial + BM25 + reclassificação) para trazer contexto relevante. É baseado em nuvem com custo de $20/mês, com todo o processamento de memória tratado no lado do servidor.
Dependências externas: As chamadas LLM, pipeline de embedding e reclassificação do RetainDB rodam 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 e nenhum modo local. Todos os dados de conversa são enviados para os servidores RetainDB para processamento e armazenamento. Se soberania de dados ou operação offline importam 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 tarefa), retaindb_remember (armazenar com tipo + importância), retaindb_forget (deletar memórias).
Configuração:
hermes memory setup # selecione "retaindb"
ByteRover
Melhor para: memória local-first com armazenamento legível e auditável por humanos.
ByteRover armazena memória como uma árvore de contexto markdown estruturada — uma hierarquia de arquivos de domínio, tópico e sub-tópico — em vez de vetores de embedding ou banco de dados. Um LLM lê o conteúdo fonte, raciocina sobre ele e coloca o conhecimento extraído no local correto na hierarquia. A recuperação é busca de texto completo MiniSearch com fallback em camadas para busca alimentada por LLM, sem necessidade de banco de dados vetorial.
Dependências externas: 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 via o slot de provedor openai-compatible). Não requer modelo de embedding e nem banco de dados — a árvore de contexto é um diretório local de arquivos markdown simples. 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 contida, conecte o Ollama como provedor (brv providers connect openai-compatible --base-url http://localhost:11434/v1) e nenhum dado sai da sua máquina.
Ferramentas: 3 ferramentas para operações de memória.
Configuração:
hermes memory setup # selecione "byterover"
Supermemory
Melhor para: fluxos de trabalho enterprise com cercamento de contexto e ingestão de grafo de sessão.
Supermemory fornece cercamento de contexto (isolando memória por contexto) e ingestão de grafo de sessão (importando históricos inteiros de conversação). 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 embedding no lado do servidor — você fornece apenas uma chave de API Supermemory. Auto-hospedagem está disponível exclusivamente como um complemento de plano enterprise e é implantado na Cloudflare Workers; exige que você forneça PostgreSQL com a extensão pgvector (para armazenamento vetorial) e uma chave de API 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 ao compute de borda da Cloudflare Workers. Para usuários que precisam de soberania de dados total sem contrato enterprise, este provedor não é a escolha certa.
Ferramentas: 4 ferramentas para operações de memória.
Configuração:
hermes memory setup # selecione "supermemory"
Como Escolher
- Precisa de suporte multi-agente? Honcho
- Quer auto-hospedado e gratuito? OpenViking ou Holographic
- Quer configuração zero? Mem0
- Quer grafos de conhecimento? Hindsight
- Quer compressão de delta? RetainDB
- Quer eficiência de largura de banda? ByteRover
- Quer recursos enterprise? Supermemory
- Quer privacidade (apenas local)? Holographic
- Quer totalmente local com zero serviços externos? Holographic (sem dependências alguma) ou Hindsight/Mem0/ByteRover com Ollama
- Quer memória legível e auditável por humanos sem pipeline de embedding? ByteRover
Para configurações de provedor por perfil e padrões de fluxo de trabalho do mundo real, consulte Configuração de produção do Hermes Agent.
Guias relacionados
- Hub de Memória de Sistemas de IA — escopo deste subcluster e links para guias do Cognee
- Sistema de Memória do Hermes Agent — memória central de dois arquivos antes dos plugins
- Configuração de produção do Hermes Agent — fiação de provedores na prática