Confronto tra Agent Memory Provider — Honcho, Mem0, Hindsight e altri cinque

Gli assistenti moderni continuano a dimenticare tutto quando si chiude 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 una sessione e l’altra — spesso integrati come plugin affinché il framework rimanga leggero mentre la memoria scala.

Questa guida confronta otto backend forniti come plugin di memoria esterna per Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover e Supermemory — e spiega come si inseriscono in stack AI systems più ampi. Gli stessi vendor appaiono in OpenClaw e altri strumenti per agenti tramite integrazioni della community o ufficiali. Il AI Systems Memory hub elenca questo articolo insieme a Cognee e alle guide correlate.

Per la memoria core limitata specifica di Hermes (MEMORY.md e USER.md), il comportamento di congelamento (freezing) e i trigger, consulta Hermes Agent Memory System.

Hermes Agent elenca otto plugin di provider di memoria esterna per una conoscenza persistente e multi-sessione. Solo un provider esterno può essere attivo alla volta. I file integrati MEMORY.md e USER.md rimangono caricati insieme ad esso — in modo additivo, non sostitutivo.

Dipendenze esterne. Ogni provider esterno, eccetto 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, sui costi e sulla possibilità di eseguire il proprio stack di memoria in modo completamente self-hosted. Hindsight e ByteRover raggruppano o eliminano la maggior parte delle dipendenze; Honcho, Mem0 e Supermemory richiedono il maggior numero di componenti in movimento. Laddove un provider supporti Ollama o qualsiasi endpoint compatibile con OpenAI, è possibile indirizzare le chiamate LLM e di embedding verso un modello locale, mantenendo i dati interamente al di fuori dei server di terze parti.

Attivazione con Hermes Agent

hermes memory setup   # Selettore interattivo + configurazione
hermes memory status  # Controlla 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 tra i Provider

Analisi Dettagliata

Honcho

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

Honcho funziona accanto alla memoria esistente — USER.md rimane invariato e Honcho aggiunge uno strato supplementare di contesto. Modella le conversazioni come peer che scambiano messaggi — un peer utente più un peer IA per ogni profilo Hermes, tutti con lo stesso workspace condiviso.

Dipendenze esterne: Honcho richiede un LLM per la sintesi della sessione, la derivazione della rappresentazione dell’utente e il ragionamento dialettico; un modello di embedding per la ricerca semantica tra le osservazioni; PostgreSQL con l’estensione pgvector per l’archiviazione vettoriale; e Redis per la cache. Il cloud gestito su api.honcho.dev si occupa di tutto questo per te. Per le implementazioni self-hosted (Docker, K3s o Fly.io), è necessario fornire le proprie credenziali. Lo slot LLM accetta qualsiasi endpoint compatibile con OpenAI, inclusi Ollama e vLLM, consentendo di mantenere l’inferenza on-premises. Lo slot di embedding è impostato di default su 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 le opzioni locali come vLLM con un modello BGE.

Strumenti: honcho_profile (leggi/aggiorna scheda peer), honcho_search (ricerca semantica), honcho_context (contesto della sessione — riassunto, rappresentazione, scheda, messaggi), honcho_reasoning (sintesi tramite LLM), honcho_conclude (crea/elimina conclusioni).

Parametri di configurazione principali:

• contextCadence (default 1): Numero minimo di turni tra il refresh dello strato base
• dialecticCadence (default 2): Numero minimo di turni tra le chiamate LLM di peer.chat() (consigliato 1-5)
• dialecticDepth (default 1): Passaggi .chat() per invocazione (limite 1-3)
• recallMode (default ‘hybrid’): hybrid (auto+tools), context (solo iniezione), tools (solo strumenti)
• writeFrequency (default ‘async’): Temporizzazione del flush: async, turn, session, o intero N
• observationMode (default ‘directional’): directional (tutto attivo) o unified (pool condiviso)

Architettura: Iniezione del contesto a due livelli — strato base (riassunto sessione + rappresentazione + scheda peer) + supplemento dialettico (ragionamento LLM). Seleziona automaticamente tra prompt per cold-start e warm-start.

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

Setup:

hermes memory setup  # seleziona "honcho"
# o versione 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                   # Popola i peer IA 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 offre il pieno controllo sull’archiviazione della memoria.

Dipendenze esterne: OpenViking richiede un VLM (vision-language model) per l’elaborazione semantica e l’estrazione della memoria, e un modello di embedding per la ricerca vettoriale — entrambi obbligatori. I provider VLM supportati includono OpenAI, Anthropic, DeepSeek, Gemini, Moonshot e vLLM (per il deployment 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 i modelli Ollama più adatti (es. Qwen3-Embedding 8B per gli embedding, Gemma 4 27B per il VLM) e configurare tutto automaticamente per un setup completamente locale e senza chiavi API. Non è richiesto alcun database esterno; OpenViking memorizza la memoria nel filesystem.

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

Setup:

pip install openviking
openviking-server init   # wizard interattivo (consiglia 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 automatizzata e senza interventi manuali.

Mem0 gestisce l’estrazione della memoria lato server tramite una chiamata LLM ad ogni operazione di add — legge la conversazione, estrae fatti discreti, rimuove i duplicati e li memorizza. L’API cloud gestita si occupa di tutta l’infrastruttura. La libreria open-source e il server self-hosted ti offrono il controllo totale.

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

Strumenti: mem0_profile, mem0_search, mem0_conclude.

Setup:

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 knowledge graph con relazioni tra entità.

Hindsight costruisce un knowledge graph della tua memoria, estraendo entità e relazioni. Il suo strumento unico reflect esegue una sintesi multi-memoria — combinando più memorie in nuove intuizioni. Il richiamo esegue quattro strategie di retrieval in parallelo (semantica, keyword/BM25, attraversamento del grafo, temporale), quindi unisce e riordina i risultati utilizzando il reciprocal rank fusion.

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

Strumenti: hindsight_retain, hindsight_recall, hindsight_reflect (sintesi multi-memoria unica).

Setup:

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

Installa automaticamente hindsight-client (cloud) o hindsight-all (locale). Richiede versione >= 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 esclusivamente locale.

Holographic utilizza l’algebra HRR (Holographic Reduced Representation) per la codifica della memoria, con un sistema di punteggio per l’affidabilità della memoria. Nessuna dipendenza dal cloud — tutto viene eseguito localmente sul proprio hardware.

Dipendenze esterne: Nessuna. Holographic non richiede LLM, modelli di embedding, database o connessione di rete. La codifica della memoria è effettuata interamente tramite algebra HRR eseguita 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 retrieval è inferiore rispetto alla ricerca semantica basata su embedding, e non esiste una sintesi multi-memoria come il reflect di Hindsight. Per gli utenti per i quali la privacy e il funzionamento senza dipendenze sono non negoziabili, Holographic è l’unica opzione che offre questo incondizionatamente.

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

Setup:

hermes memory setup  # seleziona "holographic"

RetainDB

Ideale per: aggiornamenti ad alta frequenza con compressione delta.

RetainDB utilizza la compressione delta per archiviare efficientemente gli aggiornamenti della memoria e il retrieval ibrido (vettore + BM25 + reranking) per far emergere il contesto rilevante. È basato su cloud con un costo di $20/mese, con tutto l’elaboramento della memoria gestito lato server.

Dipendenze esterne: Le chiamate LLM di RetainDB, la pipeline di embedding e il reranking vengono eseguiti tutti sulla propria infrastruttura cloud di RetainDB — l’utente fornisce solo una RETAINDB_KEY. L’estrazione della memoria utilizza Claude Sonnet lato server. Non esiste un’opzione di self-hosting o una modalità locale. Tutti i dati di conversazione vengono inviati ai server di RetainDB per l’elaborazione e l’archiviazione. Se la sovranità dei dati o l’operatività 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 pertinente al task), retaindb_remember (archivia con tipo + importanza), retaindb_forget (elimina memorie).

Setup:

hermes memory setup  # seleziona "retaindb"

ByteRover

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

ByteRover archivia la memoria come un albero di contesto markdown strutturato — una gerarchia di file per dominio, argomento e sottoargomento — anziché vettori di embedding o un database. Un LLM legge il contenuto sorgente, ragiona su di esso e colloca la conoscenza estratta nella posizione corretta della gerarchia. Il retrieval consiste in una ricerca full-text con MiniSearch con fallback a livelli verso la ricerca potenziata da LLM, senza necessità di un database vettoriale.

Dipendenze esterne: ByteRover richiede un LLM per la cura della memoria e la ricerca (sono supportati 18 provider, inclusi Anthropic, OpenAI, Google, Ollama e qualsiasi endpoint compatibile con OpenAI tramite lo slot del provider openai-compatible). Non richiede modelli di embedding né database — l’albero di contesto è una directory locale di file markdown in chiaro. La sincronizzazione cloud è opzionale e viene utilizzata solo per la collaborazione tra team; tutto funziona completamente offline per impostazione predefinita. Per un setup locale completamente autonomo, connetti Ollama come provider (brv providers connect openai-compatible --base-url http://localhost:11434/v1) e nessun dato lascerà la tua macchina.

Strumenti: 3 strumenti per operazioni di memoria.

Setup:

hermes memory setup  # seleziona "byterover"

Supermemory

Ideale per: workflow aziendali con context fencing e ingest del grafo di sessione.

Supermemory fornisce il context fencing (isolamento della memoria per contesto) e l’ingest del grafo di sessione (importazione di intere cronologie di conversazione). Estrae automaticamente le memorie, costruisce profili utente ed esegue un retrieval ibrido combinando ricerca semantica e per parole chiave. L’API cloud gestita è il principale target di deployment.

Dipendenze esterne: Il servizio cloud di Supermemory gestisce tutta l’inferenza LLM e l’embedding lato server — l’utente fornisce solo una chiave API Supermemory. L’auto-hosting è disponibile esclusivamente come add-on per i piani enterprise e viene distribuito su Cloudflare Workers; richiede di fornire 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 all’edge compute di Cloudflare Workers. Per gli utenti che necessitano di piena sovranità dei dati senza un contratto enterprise, questo provider non è la scelta giusta.

Strumenti: 4 strumenti per operazioni di memoria.

Setup:

hermes memory setup  # seleziona "supermemory"

Come Scegliere

• Hai bisogno del supporto multi-agente? Honcho
• Vuoi qualcosa di gratuito e self-hosted? OpenViking o Holographic
• Vuoi zero configurazione? Mem0
• Vuoi knowledge graph? Hindsight
• Vuoi la compressione delta? RetainDB
• Vuoi efficienza di banda? ByteRover
• Vuoi funzionalità enterprise? Supermemory
• Vuoi privacy (solo locale)? Holographic
• Vuoi un sistema totalmente locale senza servizi esterni? Holographic (nessuna dipendenza) o Hindsight/Mem0/ByteRover con Ollama
• Vuoi una memoria leggibile dall’uomo e verificabile senza pipeline di embedding? ByteRover

Per le configurazioni complete dei provider profilo per profilo e i modelli di workflow reali, consulta Hermes Agent production setup.

Guide correlate

• AI Systems Memory hub — ambito di questo sottogruppo e link alle guide di Cognee
• Hermes Agent Memory System — memoria core a due file prima dei plugin
• Hermes Agent production setup — collegamento dei profili per i provider nella pratica