Confronto tra i fornitori 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 al di fuori della finestra di contesto. I provider di memoria per agenti sono servizi o librerie che conservano fatti e riepiloghi tra le sessioni — spesso integrati come plugin in modo che il framework rimanga leggero mentre la memoria scala.

Questa guida confronta otto back-end che vengono distribuiti come plugin di memoria esterna per Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover e Supermemory — e spiega come si integrano nelle stack più ampie dei sistemi AI. Gli stessi fornitori appaiono in OpenClaw e in altri strumenti per agenti tramite integrazioni della comunità o ufficiali. Il hub della memoria dei sistemi AI elenca questo articolo insieme a Cognee e alle guide correlate.

Per informazioni sulla memoria core limitata specifica di Hermes (MEMORY.md e USER.md), comportamento di congelamento e trigger, consulta Sistema di memoria di Hermes Agent. Per il contesto su come gli otto provider di memoria nativi di Hermes contribuiscono al suo vantaggio di adozione crescente rispetto a OpenClaw — inclusi stelle su GitHub, classifiche dei token OpenRouter e confronti delle dimensioni dell’ecosistema — consulta OpenClaw vs Hermes Agent: Stelle, Download e Utilizzo 2026.

Hermes Agent elenca otto plugin di provider di memoria esterna per la conoscenza persistente e trasversale alle sessioni. Solo un provider esterno può essere attivo alla volta. I file MEMORY.md e USER.md integrati rimangono caricati accanto ad esso — sono aggiuntivi, non sostitutivi.

Dipendenze esterne. Ogni provider esterno, ad eccezione di 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 sul fatto che la tua stack di memoria possa essere eseguita completamente in auto-ospedato. Hindsight e ByteRover riducono o eliminano la maggior parte delle dipendenze; Honcho, Mem0 e Supermemory richiedono più 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 fuori dai server di terze parti.

Attivazione con Hermes Agent

I passaggi da riga di comando seguenti riflettono le tabelle nel reference rapido della CLI di Hermes Agent.

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

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

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

Confronto dei Provider

Analisi Dettagliata

Honcho

Ideale per: sistemi multi-agente, contesto trasversale alle sessioni, 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, che condividono tutti un 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 tra 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 in auto-ospedato (Docker, K3s o Fly.io), fornisci le tue credenziali. Lo slot LLM accetta qualsiasi endpoint compatibile con OpenAI, inclusi Ollama e vLLM, in modo che l’inferenza possa rimanere on-premise. Lo slot di embedding predefinisce 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 (lettura/aggiornamento scheda peer), honcho_search (ricerca semantica), honcho_context (contesto della sessione — riepilogo, rappresentazione, scheda, messaggi), honcho_reasoning (sintetizzato da LLM), honcho_conclude (crea/elimina conclusioni).

Principali parametri di configurazione:

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

Architettura: Iniezione del contesto a due strati — strato base (riepilogo sessione + rappresentazione + scheda peer) + supplemento dialettico (ragionamento LLM). Seleziona automaticamente prompt a freddo vs caldi.

Mappatura multi-peer: Il 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 predefinito, hermes.<profilo> 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 dei profili:

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

OpenViking

Ideale per: gestione della conoscenza in auto-ospedato con navigazione strutturata.

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

Dipendenze esterne: OpenViking richiede un VLM (modello visione-linguaggio) 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 il deploy 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 hands-off con estrazione automatica.

Mem0 gestisce l’estrazione della memoria lato server tramite una chiamata LLM su 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 in auto-ospedato ti danno il controllo completo.

Dipendenze esterne: Mem0 richiede un LLM per l’estrazione della memoria (predefinito: 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 (predefinito: 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 in auto-ospedato — entrambi possono essere eseguiti localmente. Una stack Mem0 completamente locale, senza cloud, è realizzabile: Ollama per LLM, Ollama per gli 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=your-key" >> ~/.hermes/.env

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

Hindsight

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

Hindsight costruisce un grafo di conoscenza della tua memoria, estraendo entità e relazioni. Il suo strumento reflect unico esegue la sintesi trasversale alla memoria — combinando multiple memorie in nuovi insights. Il recupero esegue quattro strategie di recupero in parallelo (semantica, parola chiave/BM25, traverso del grafo, temporale), quindi fonde e riordina i risultati usando la fusione del 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 (predefinito: OpenAI; 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. PostgreSQL è anche incluso con l’installazione Python embedded tramite una directory dati pg0 gestita; puoi alternativamente puntare Hindsight a un’istanza PostgreSQL esterna. Per una configurazione completamente locale, senza cloud, imposta HINDSIGHT_API_LLM_PROVIDER=ollama e puntalo 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 trasversale alla memoria unica).

Configurazione:

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

Auto-installa 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 (predefinito)

UI Locale: hindsight-embed -p hermes ui start

Holographic

Ideale per: configurazioni focalizzate 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 dal cloud — tutto viene eseguito localmente sul tuo hardware.

Dipendenze esterne: Nessuna. Holographic non richiede LLM, modello di embedding, database o connessione di rete. La codifica della memoria è eseguita interamente tramite 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 trasversale alla memoria come reflect di Hindsight. Per gli utenti per cui la privacy e l’operazione zero-dipendenze sono non negoziabili, Holographic è l’unica opzione che lo consegna 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 (vettore + BM25 + reranking) per far emergere il contesto rilevante. È basato su cloud con un costo di $20/mese, con tutta l’elaborazione della memoria gestita lato server.

Dipendenze esterne: Le chiamate LLM di RetainDB, il pipeline di embedding e il reranking vengono eseguiti tutti sull’infrastruttura cloud di RetainDB — fornisci solo una RETAINDB_KEY. L’estrazione della memoria usa Claude Sonnet lato server. Non esiste un’opzione di auto-ospedato e nessuna modalità locale. Tutti i dati delle conversazioni 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 compito), retaindb_remember (archivia con tipo + importanza), retaindb_forget (elimina memorie).

Configurazione:

hermes memory setup  # seleziona "retaindb"

ByteRover

Ideale per: memoria prima per il locale 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 alimentata da LLM, senza database vettoriale richiesto.

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

Strumenti: 3 strumenti per operazioni di memoria.

Configurazione:

hermes memory setup  # seleziona "byterover"

Supermemory

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

Supermemory fornisce il fencing del contesto (isolamento della memoria per contesto) e l’ingestione del grafo di sessione (importazione di intere storie delle conversazioni). Estrae automaticamente memorie, costruisce profili utente ed esegue il recupero ibrido combinando ricerca semantica e per parola chiave. L’API cloud gestita è il target di distribuzione principale.

Dipendenze esterne: Il servizio cloud di Supermemory gestisce tutta l’inferenza LLM e l’embedding lato server — fornisci solo una chiave API Supermemory. L’auto-ospedato è 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 auto-ospedato 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 auto-ospedato e gratuito? OpenViking o Holographic
• Vuoi zero-config? 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
• Vuoto completamente locale con zero servizi esterni? Holographic (nessuna dipendenza del tutto) o Hindsight/Mem0/ByteRover con Ollama
• Vuoi memoria leggibile dall’uomo e auditabile senza pipeline di embedding? ByteRover

Per configurazioni dei provider profilo-per-profilo complete e pattern di workflow del mondo reale, consulta Setup di produzione di Hermes Agent.

Guide correlate

• Hub della memoria dei sistemi AI — ambito di questo sottocluster e link alle guide di Cognee
• Sistema di memoria di Hermes Agent — memoria core a due file prima dei plugin
• Setup di produzione di Hermes Agent — cablaggio dei profili per i provider in pratica