Provedores de Memória de Agentes Comparados — Honcho, Mem0, Hindsight e Mais Cinco

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 retê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 distribuídos 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 amplos de sistemas de IA. Os mesmos fornecedores 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 lista este artigo ao lado do Cognee e de guias relacionados.

Para memória de núcleo delimitada específica do Hermes (MEMORY.md e USER.md), comportamento de congelamento e gatilhos, consulte Sistema de Memória do Hermes Agent.

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 integrados MEMORY.md e USER.md permanecem carregados junto com ele — de forma aditiva, não de substituição.

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 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 exigem mais componentes móveis. Onde um provedor suporta Ollama ou qualquer endpoint compatível com OpenAI, você pode rotear chamadas de LLM e embedding para um modelo local e manter os dados totalmente fora de servidores de terceiros.

Ativação com 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

Detalhamento

Honcho

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

O Honcho roda ao lado da memória existente — 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 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 do 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 lida com 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 no 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 da sessão — resumo, representação, cartão, mensagens), honcho_reasoning (sintetizado por LLM), honcho_conclude (criar/deletar conclusões).

Principais configurações:

• contextCadence (padrão 1): Mínimo de turnos entre atualizações da camada base
• dialecticCadence (padrão 2): Mínimo de turnos entre chamadas LLM de peer.chat() (1-5 recomendado)
• dialecticDepth (padrão 1): Passos .chat() por invocação (limitado a 1-3)
• recallMode (padrão ‘hybrid’): hybrid (auto+ferramentas), context (injetar apenas), tools (apenas ferramentas)
• writeFrequency (padrão ‘async’): Timing de flush: async, turn, session, ou inteiro N
• observationMode (padrão ‘directional’): directional (tudo ativado) ou unified (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 cold-start vs warm.

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 de IA (aiPeer) é um por perfil Hermes (hermes padrão, hermes.<profile> para outros).

Configuração:

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

Config: $HERMES_HOME/honcho.json (local do perfil) ou ~/.honcho/config.json (global).

Gerenciamento de perfil:

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 em camadas. É gratuito, auto-hospedado, e dá a você controle total sobre o armazenamento de 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 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 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.

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 lida com toda a infraestrutura. A biblioteca open-source 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 stack Mem0 totalmente local, sem nuvem, é alcançá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

Config: $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 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 rank recíproco.

Dependências externas: O Hindsight requer um LLM para extração de fatos e entidades nas chamadas retain, e para síntese nas 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 reranking cross-encoder estão embutidos no próprio Hindsight — eles rodam localmente dentro do pacote hindsight-all e não requerem API externa. O PostgreSQL também está embutido com a instalação Python embutida via um diretório de dados gerenciado pg0; 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 (por exemplo, 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.

Config: $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

Holographic

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

O 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. Nenhuma dependência de nuvem — tudo roda localmente no seu próprio hardware.

Dependências externas: Nenhuma. O Holographic não requer LLM, não requer modelo de embedding, não requer banco de dados e não requer conexão de rede. A codificação de memória é feita inteiramente através da álgebra HRR rodando no processo. Isso o torna único entre todos os oito provedores — é o único que opera com zero chamadas externas. O trade-off é 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, o 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 delta.

O RetainDB usa compressão delta para armazenar eficientemente atualizações de memória e recuperação híbrida (vetorial + BM25 + reranking) para trazer contexto relevante à tona. É 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 do RetainDB, o pipeline de embedding e o reranking rodam 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 e nenhum modo local. Todos os dados de conversa são enviados para os servidores do 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 a 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 audível e legí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 da 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: 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 via o slot de provedor openai-compatible). Ele não requer modelo de embedding e não requer 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 autocontida, 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 empresariais com cercamento de contexto e ingestão de gráfico de sessão.

O Supermemory fornece cercamento de contexto (isolando memória por contexto) e ingestão de gráfico de sessão (importando históricos inteiros de conversação). Ele extrai memórias automaticamente, constrói perfis de usuário e executa recuperação híbrida combinando busca semântica e por palavras-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 de LLM e embedding no lado do servidor — você fornece apenas uma chave de API do Supermemory. A auto-hospedagem está disponível exclusivamente como um complemento de plano enterprise e é implantada nos Cloudflare Workers; exige 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 ao compute de borda dos Cloudflare Workers. Para usuários que precisam de soberania de dados total sem um 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 grátis? OpenViking ou Holographic
• Quer configuração zero? Mem0
• Quer grafos de conhecimento? Hindsight
• Quer compressão delta? RetainDB
• Quer eficiência de banda? ByteRover
• Quer recursos empresariais? Supermemory
• Quer privacidade (apenas local)? Holographic
• Quer totalmente local com zero serviços externos? Holographic (nenhuma dependência) ou Hindsight/Mem0/ByteRover com Ollama
• Quer memória audível e legí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 de dois arquivos principal antes dos plugins
• Configuração de produção do Hermes Agent — fiação de perfil para provedores na prática