Confronto tra i provider di memoria per gli agenti: Honcho, Mem0, Hindsight e altri cinque

Gli assistenti moderni dimenticano ancora tutto quando chiudi la scheda, a meno che qualcosa non persista oltre la finestra di contesto. I provider di memoria per agenti sono servizi o librerie che conservano fatti e riassunti tra le sessioni — spesso integrati come plugin in modo che il framework rimanga leggero mentre la memoria scala.

Questa guida confronta otto backend che vengono forniti come plugin di memoria esterni per Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover e Supermemory — e spiega come si inseriscono nelle stack più ampi di sistemi AI. Gli stessi fornitori appaiono in OpenClaw e in altri strumenti per agenti tramite integrazioni della comunità o ufficiali. Il hub Memoria Sistemi AI elenca questo articolo insieme a Cognee e guide correlate.

Per la memoria core limitata specifica di Hermes (MEMORY.md e USER.md), il comportamento di congelamento e i trigger, vedi Sistema di Memoria Hermes Agent.

Hermes Agent elenca otto plugin di provider di memoria esterna per conoscenza persistente e cross-sessione. Solo un provider esterno può essere attivo alla volta. I file built-in MEMORY.md e USER.md rimangono caricati insieme ad esso — sono additivi, non sostitutivi.

Dipendenze esterne. Ogni provider esterno, tranne Holographic, richiede almeno una chiamata a un servizio esterno — un LLM per l’estrazione della memoria, un modello di embedding per la ricerca semantica o un database come PostgreSQL per l’archiviazione. Queste dipendenze hanno implicazioni dirette sulla privacy, sul costo e sulla possibilità che il tuo stack di memoria possa essere eseguito in modo completamente self-hosted. Hindsight e ByteRover includono o eliminano la maggior parte delle dipendenze; Honcho, Mem0 e Supermemory richiedono il maggior numero di componenti mobili. Dove un provider supporta Ollama o qualsiasi endpoint compatibile con OpenAI, puoi instradare le chiamate LLM e di embedding a un modello locale e mantenere i dati completamente al di fuori dei server di terze parti.

Attivazione con Hermes Agent

hermes memory setup   # Selettore interattivo + configurazione
hermes memory status  # Verifica cosa è attivo
hermes memory off     # Disabilita il provider esterno

Oppure manualmente in ~/.hermes/config.yaml:

memory:
  provider: openviking  # o honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Confronto Provider

Analisi Dettagliata

Honcho

Ideale per: sistemi multi-agente, contesto cross-sessione, allineamento utente-agente.

Honcho funziona accanto alla memoria esistente — USER.md rimane invariato, e Honcho aggiunge un livello aggiuntivo di contesto. Modella le conversazioni come pari che si scambiano messaggi — un peer utente più un peer AI per ogni profilo Hermes, tutti condividono uno workspace.

Dipendenze esterne: Honcho richiede un LLM per il riassunto della sessione, la derivazione della rappresentazione utente e il ragionamento dialettico; un modello di embedding per la ricerca semantica attraverso le osservazioni; PostgreSQL con l’estensione pgvector per l’archiviazione vettoriale; e Redis per la caching. Il cloud gestito su api.honcho.dev gestisce tutto questo per te. Per le distribuzioni self-hosted (Docker, K3s o Fly.io), fornisci le tue credenziali. Lo slot LLM accetta qualsiasi endpoint compatibile con OpenAI, inclusi Ollama e vLLM, quindi l’inferenza può rimanere on-premise. Lo slot di embedding predefinito è openai/text-embedding-3-small ma supporta provider configurabili tramite LLM_EMBEDDING_API_KEY e LLM_EMBEDDING_BASE_URL — qualsiasi server di embedding compatibile con OpenAI funziona, incluse opzioni locali come vLLM con un modello BGE.

Strumenti: honcho_profile (leggisci/aggiorna scheda peer), honcho_search (ricerca semantica), honcho_context (contesto sessione — riassunto, rappresentazione, scheda, messaggi), honcho_reasoning (sintetizzato da LLM), honcho_conclude (crea/elimina conclusioni).

Principali parametri di configurazione:

• contextCadence (default 1): Turni minimi tra gli aggiornamenti del livello base
• dialecticCadence (default 2): Turni minimi tra le chiamate LLM di peer.chat() (raccomandato 1-5)
• dialecticDepth (default 1): Passaggi .chat() per invocazione (limitato a 1-3)
• recallMode (default ‘hybrid’): hybrid (auto+strumenti), context (solo iniezione), tools (solo strumenti)
• writeFrequency (default ‘async’): Timing del flush: async, turn, session, o intero N
• observationMode (default ‘directional’): directional (tutto attivo) o unified (pool condiviso)

Architettura: Iniezione di contesto a due livelli — livello base (riassunto sessione + rappresentazione + scheda peer) + supplemento dialettico (ragionamento LLM). Seleziona automaticamente prompt a freddo vs caldi.

Mappatura multi-peer: Lo workspace è un ambiente condiviso tra i profili. Il peer utente (peerName) è un’identità umana globale. Il peer AI (aiPeer) è uno per ogni profilo Hermes (hermes di default, hermes.<profile> per gli altri).

Configurazione:

hermes memory setup  # seleziona "honcho"
# o legacy: hermes honcho setup

Configurazione: $HERMES_HOME/honcho.json (locale al profilo) o ~/.honcho/config.json (globale).

Gestione profili:

hermes profile create coder --clone  # Crea hermes.coder con workspace condiviso
hermes honcho sync                   # Ripristina i peer AI per i profili esistenti

OpenViking

Ideale per: gestione della conoscenza self-hosted con navigazione strutturata.

OpenViking fornisce una gerarchia di filesystem con caricamento a livelli. È gratuito, self-hosted, e ti dà il controllo completo sulla tua archiviazione della memoria.

Dipendenze esterne: OpenViking richiede un VLM (modello lingua-visione) per l’elaborazione semantica e l’estrazione della memoria, e un modello di embedding per la ricerca vettoriale — entrambi sono obbligatori. I provider VLM supportati includono OpenAI, Anthropic, DeepSeek, Gemini, Moonshot e vLLM (per distribuzione locale). Per gli embedding, i provider supportati includono OpenAI, Volcengine (Doubao), Jina, Voyage e — tramite Ollama — qualsiasi modello di embedding servito localmente. Il wizard interattivo openviking-server init può rilevare la RAM disponibile e raccomandare modelli Ollama adatti (es. Qwen3-Embedding 8B per gli embedding, Gemma 4 27B per il VLM) e configurare tutto automaticamente per una configurazione completamente locale, senza chiavi API. Non è richiesto un database esterno; OpenViking archivia la memoria nel filesystem.

Strumenti: viking_search, viking_read (a livelli), viking_browse, viking_remember, viking_add_resource.

Configurazione:

pip install openviking
openviking-server init   # wizard interattivo (raccomanda modelli Ollama per setup locale)
openviking-server
hermes memory setup  # seleziona "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Ideale per: gestione della memoria senza intervento con estrazione automatica.

Mem0 gestisce l’estrazione della memoria lato server tramite una chiamata LLM ad ogni operazione add — legge la conversazione, estrae fatti discreti, deduplica e li archivia. L’API cloud gestita gestisce tutta l’infrastruttura. La libreria open-source e il server self-hosted ti danno il controllo completo.

Dipendenze esterne: Mem0 richiede un LLM per l’estrazione della memoria (default: OpenAI gpt-4.1-nano; 20 provider supportati, inclusi Ollama, vLLM e LM Studio per modelli locali) e un modello di embedding per il recupero (default: OpenAI text-embedding-3-small; 10 provider supportati, inclusi Ollama e HuggingFace per modelli locali). L’archiviazione usa Qdrant su /tmp/qdrant in modalità libreria, o PostgreSQL con pgvector in modalità server self-hosted — entrambi possono essere eseguiti localmente. Uno stack Mem0 completamente locale, zero-cloud è realizzabile: Ollama per LLM, Ollama per embedding, e un’istanza Qdrant locale, tutto configurato tramite Memory.from_config.

Strumenti: mem0_profile, mem0_search, mem0_conclude.

Configurazione:

pip install mem0ai
hermes memory setup  # seleziona "mem0"
echo "MEM0_API_KEY=tua-chiave" >> ~/.hermes/.env

Configurazione: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Ideale per: richiamo basato su grafo di conoscenza con relazioni tra entità.

Hindsight costruisce un grafo di conoscenza della tua memoria, estraendo entità e relazioni. Il suo unico strumento reflect esegue la sintesi cross-memory — combinando più memorie in nuove intuizioni. Il recupero esegue quattro strategie di recupero in parallelo (semantica, keyword/BM25, traversamento grafo, temporale), poi fonde e riordina i risultati usando la fusione di rango reciproco.

Dipendenze esterne: Hindsight richiede un LLM per l’estrazione di fatti ed entità sulle chiamate retain, e per la sintesi sulle chiamate reflect (default: OpenAI; provider supportati includono Anthropic, Gemini, Groq, Ollama, LM Studio e qualsiasi endpoint compatibile con OpenAI). Il modello di embedding e il modello di cross-encoder reranking sono inclusi all’interno di Hindsight stesso — vengono eseguiti localmente all’interno del pacchetto hindsight-all e non richiedono API esterne. PostgreSQL è anche incluso con l’installazione Python embedded tramite una directory dati pg0 gestita; puoi alternatively puntare Hindsight a un’istanza PostgreSQL esterna. Per una configurazione completamente locale, zero-cloud, imposta HINDSIGHT_API_LLM_PROVIDER=ollama e punta a un modello Ollama locale — retain e recall funzionano completamente; reflect richiede un modello capace di tool-calling (es. qwen3:8b).

Strumenti: hindsight_retain, hindsight_recall, hindsight_reflect (sintesi cross-memory unica).

Configurazione:

hermes memory setup  # seleziona "hindsight"
echo "HINDSIGHT_API_KEY=tua-chiave" >> ~/.hermes/.env

Installa automaticamente hindsight-client (cloud) o hindsight-all (locale). Richiede >= 0.4.22.

Configurazione: $HERMES_HOME/hindsight/config.json

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

UI Locale: hindsight-embed -p hermes ui start

Holographic

Ideale per: setup focalizzati sulla privacy con archiviazione solo locale.

Holographic usa l’algebra HRR (Holographic Reduced Representation) per la codifica della memoria, con punteggio di fiducia per l’affidabilità della memoria. Nessuna dipendenza cloud — tutto viene eseguito localmente sul tuo hardware.

Dipendenze esterne: Nessuna. Holographic non richiede LLM, nessun modello di embedding, nessun database e nessuna connessione di rete. La codifica della memoria viene eseguita interamente attraverso l’algebra HRR in-process. Questo lo rende unico tra tutti gli otto provider — è l’unico che opera con zero chiamate esterne. Il compromesso è che la qualità del recupero è inferiore rispetto alla ricerca semantica basata su embedding, e non c’è sintesi cross-memory come il reflect di Hindsight. Per gli utenti per cui la privacy e l’operazione zero-dipendenze sono non negoziabili, Holographic è l’unica opzione che lo offre incondizionatamente.

Strumenti: 2 strumenti per operazioni di memoria tramite algebra HRR.

Configurazione:

hermes memory setup  # seleziona "holographic"

RetainDB

Ideale per: aggiornamenti ad alta frequenza con compressione delta.

RetainDB usa la compressione delta per archiviare efficientemente gli aggiornamenti della memoria e il recupero ibrido (vettoriale + BM25 + reranking) per mostrare il contesto rilevante. È basato su cloud con un costo di $20/mese, con tutto l’elaborazione della memoria gestita lato server.

Dipendenze esterne: Le chiamate LLM di RetainDB, il pipeline di embedding e il reranking vengono eseguiti sull’infrastruttura cloud di RetainDB — fornisci solo una RETAINDB_KEY. L’estrazione della memoria usa Claude Sonnet lato server. Non esiste un’opzione di self-hosting e nessuna modalità locale. Tutti i dati della conversazione vengono inviati ai server RetainDB per l’elaborazione e l’archiviazione. Se la sovranità dei dati o l’operazione offline sono importanti per il tuo caso d’uso, questo provider non è adatto.

Strumenti: retaindb_profile (profilo utente), retaindb_search (ricerca semantica), retaindb_context (contesto rilevante per il task), retaindb_remember (archivia con tipo + importanza), retaindb_forget (elimina memorie).

Configurazione:

hermes memory setup  # seleziona "retaindb"

ByteRover

Ideale per: memoria local-first con archiviazione leggibile dall’uomo e auditabile.

ByteRover archivia la memoria come un albero di contesto markdown strutturato — una gerarchia di file di dominio, argomento e sotto-argomento — piuttosto che vettori di embedding o un database. Un LLM legge il contenuto sorgente, ragiona su di esso e posiziona la conoscenza estratta nella posizione corretta nella gerarchia. Il recupero è la ricerca full-text MiniSearch con fallback a livelli alla ricerca potenziata da LLM, senza necessità di database vettoriale.

Dipendenze esterne: ByteRover richiede un LLM per la curatela e la ricerca della memoria (18 provider supportati, inclusi Anthropic, OpenAI, Google, Ollama e qualsiasi endpoint compatibile con OpenAI tramite lo slot provider openai-compatible). Non richiede un modello di embedding e nessun database — l’albero di contesto è una directory locale di file markdown semplici. Il sync cloud è opzionale e usato solo per la collaborazione di team; tutto funziona completamente offline di default. Per una configurazione locale completamente autonoma, connetti Ollama come provider (brv providers connect openai-compatible --base-url http://localhost:11434/v1) e nessun dato lascia il tuo computer.

Strumenti: 3 strumenti per operazioni di memoria.

Configurazione:

hermes memory setup  # seleziona "byterover"

Supermemory

Ideale per: flussi di lavoro enterprise con context fencing e ingestione grafo di sessione.

Supermemory fornisce context fencing (isolamento della memoria per contesto) e session graph ingest (importazione di intere storie di conversazione). Estrae automaticamente memorie, costruisce profili utente ed esegue il recupero ibrido combinando ricerca semantica e per keyword. L’API cloud gestita è il target di distribuzione primario.

Dipendenze esterne: Il servizio cloud di Supermemory gestisce tutta l’inferenza LLM e l’embedding lato server — fornisci solo una chiave API Supermemory. Il self-hosting è disponibile esclusivamente come add-on del piano enterprise e si distribuisce su Cloudflare Workers; richiede che tu fornisca PostgreSQL con l’estensione pgvector (per l’archiviazione vettoriale) e una chiave API OpenAI (obbligatoria, con Anthropic e Gemini come aggiunte opzionali). Non esiste un percorso di self-hosting basato su Docker o locale — l’architettura è strettamente accoppiata al calcolo edge di Cloudflare Workers. Per gli utenti che hanno bisogno di piena sovranità dei dati senza un contratto enterprise, questo provider non è la scelta giusta.

Strumenti: 4 strumenti per operazioni di memoria.

Configurazione:

hermes memory setup  # seleziona "supermemory"

Come Scegliere

• Hai bisogno di supporto multi-agente? Honcho
• Vuoi self-hosted e gratuito? OpenViking o Holographic
• Vuoi zero-configurazione? Mem0
• Vuoi grafi di conoscenza? Hindsight
• Vuoi compressione delta? RetainDB
• Vuoi efficienza della larghezza di banda? ByteRover
• Vuoi funzionalità enterprise? Supermemory
• Vuoi privacy (solo locale)? Holographic
• Vuoi completamente locale con zero servizi esterni? Holographic (nessuna dipendenza) o Hindsight/Mem0/ByteRover con Ollama
• Vuoi memoria leggibile dall’uomo e auditabile senza pipeline di embedding? ByteRover

Per configurazioni provider per profilo e pattern di flusso di lavoro reali, vedi Setup produzione Hermes Agent.

Guide correlate

• Hub Memoria Sistemi AI — ambito di questo sottocluster e link alle guide Cognee
• Sistema di Memoria Hermes Agent — memoria core a due file prima dei plugin
• Setup produzione Hermes Agent — configurazione dei provider nella pratica