Comparativo de Agent Memory Providers — Honcho, Mem0, Hindsight e outros cinco

Os 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 — muitas vezes 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 de AI systems mais amplas. Os mesmos fornecedores aparecem no OpenClaw e em outras ferramentas de agentes por meio de integrações comunitárias ou oficiais. O AI Systems Memory hub lista este artigo ao lado do Cognee e de guias relacionados.

Para a memória central limitada específica do Hermes (MEMORY.md e USER.md), comportamento de congelamento e gatilhos, consulte Hermes Agent Memory System.

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 substitutiva.

Dependências externas. Cada provedor externo, exceto o Holographic, requer pelo menos uma chamada de serviço externa — 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 na privacidade, no custo e na possibilidade de sua stack de memória ser executada totalmente de forma self-hosted. O Hindsight e o ByteRover agrupam ou eliminam a maioria das dependências; Honcho, Mem0 e Supermemory exigem o maior número de componentes móveis. Onde 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 inteiramente fora de servidores de terceiros.

Ativação com Hermes Agent

hermes memory setup   # Seletor interativo + configuração
hermes memory status  # Verifica o que está ativo
hermes memory off     # Desativa o 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 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 sumarização 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 de vetores; e Redis para cache. A nuvem gerenciada em api.honcho.dev cuida de tudo isso para você. Para implantações self-hosted (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 (on-premises). O slot de embedding usa por 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/deletar conclusões).

Principais controles de configuração:

• contextCadence (padrão 1): Turnos mínimos entre a atualização da camada base
• dialecticCadence (padrão 2): Turnos mínimos entre chamadas de LLM peer.chat() (recomendado 1-5)
• dialecticDepth (padrão 1): Passagens de .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’): Tempo de flush: async, turn, session ou inteiro N
• observationMode (padrão ‘directional’): directional (todos ativos) 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 de LLM). Seleciona automaticamente entre prompts de cold-start ou warm prompts.

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 por 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 ao 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 self-hosted com navegação estruturada.

O OpenViking fornece uma hierarquia de sistema de arquivos com carregamento em camadas. É gratuito, self-hosted e oferece controle total sobre o armazenamento da sua memória.

Dependências externas: O OpenViking requer um VLM (modelo de linguagem de visão) 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 (ex: Qwen3-Embedding 8B para embeddings, Gemma 4 27B para VLM) e configurar tudo automaticamente para uma configuração totalmente local e sem chaves de API. Nenhum banco de dados externo é necessário; o 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 setup local)
openviking-server
hermes memory setup  # selecione "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Melhor para: gerenciamento de memória automatizado e sem intervenção manual.

O Mem0 lida com a extração de memória no lado do servidor por meio de 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 self-hosted oferecem 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 utiliza Qdrant em /tmp/qdrant no modo biblioteca, ou PostgreSQL com pgvector no modo servidor self-hosted — ambos podem rodar localmente. Uma stack Mem0 totalmente local e sem nuvem é possí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.

O Hindsight constrói um grafo de conhecimento da sua memória, extraindo entidades e relacionamentos. Sua ferramenta exclusiva reflect realiza síntese entre memórias — 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 reciprocal rank fusion.

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 embedding e o modelo de reranking cross-encoder são embutidos no próprio Hindsight — eles rodam localmente dentro do pacote hindsight-all e não requerem API externa. O PostgreSQL também é embutido na instalação Python via um diretório de dados pg0 gerenciado; alternativamente, você pode apontar o Hindsight para uma instância externa de 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 capaz de chamada de ferramentas (ex: qwen3:8b).

Ferramentas: hindsight_retain, hindsight_recall, hindsight_reflect (síntese exclusiva 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)

Interface Local: hindsight-embed -p hermes ui start

Holographic

Melhor para: configurações focadas em privacidade com armazenamento exclusivamente 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. Sem 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 da memória é feita inteiramente por meio de álgebra HRR rodando em processo. Isso o torna único entre os oito provedores — é o único que opera com zero chamadas externas. A desvantagem é que a qualidade da recuperação é inferior à 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 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 atualizações de memória de forma eficiente e recuperação híbrida (vetor + BM25 + reranking) para apresentar o contexto relevante. É baseado em nuvem com um custo de $20/mês, com todo o processamento de memória realizado no lado do servidor.

Dependências externas: As chamadas de LLM, o pipeline de embedding e o reranking do RetainDB rodam todos na própria infraestrutura de nuvem do RetainDB — você fornece apenas uma RETAINDB_KEY. A extração de memória utiliza o Claude Sonnet no lado do servidor. Não há opção de self-hosting ou modo local. Todos os dados de conversação são enviados para os servidores do RetainDB para processamento e armazenamento. Se a soberania de dados ou operação offline for importante para o seu caso de uso, este provedor não é adequado.

Ferramentas: retaindb_profile (perfil de 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 legível por humanos e auditável.

O ByteRover armazena a 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 da hierarquia. A recuperação é uma busca de texto completo MiniSearch com fallback em camadas para busca baseada em 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 de provedor openai-compatible). 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 com a 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 sairá 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 context fencing e ingestão de grafo de sessão.

O Supermemory fornece context fencing (isolando a memória por contexto) e ingestão de grafo de sessão (importando históricos de conversas inteiros). Ele extrai memórias automaticamente, 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 principal alvo de implantação.

Dependências externas: O serviço de 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. O self-hosting está disponível exclusivamente como um adicional para planos enterprise e é implantado no Cloudflare Workers; ele exige que você forneça o 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 self-hosting baseado em Docker ou local — a arquitetura é fortemente acoplada ao edge compute do Cloudflare Workers. Para usuários que precisam de soberania total de dados 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 algo gratuito e self-hosted? OpenViking ou Holographic
• Quer configuração zero? Mem0
• Quer grafos de conhecimento? Hindsight
• Quer compressão delta? RetainDB
• Quer eficiência de largura de banda? ByteRover
• Quer recursos enterprise? Supermemory
• Quer privacidade (apenas local)? Holographic
• Quer algo totalmente local com zero serviços externos? Holographic (sem dependências de modo algum) ou Hindsight/Mem0/ByteRover com Ollama
• Quer memória auditável e legível por humanos sem pipeline de embedding? ByteRover

Para configurações completas de provedores perfil por perfil e padrões de fluxo de trabalho do mundo real, consulte Hermes Agent production setup.

Guias relacionados

• AI Systems Memory hub — escopo deste subaglomerado e links para guias do Cognee
• Hermes Agent Memory System — memória central de dois arquivos antes dos plugins
• Hermes Agent production setup — integração de perfis para provedores na prática