Confronto dei provider di memoria per agenti: policy di acquisizione e self-hosting

Aggiornato a settembre 2026: aggiunti Mnemosyne e Memori, ampliata la configurazione di Honcho e Hindsight, e aggiunta una tabella di confronto delle policy di acquisizione accanto alla tabella infrastrutturale originale.

Gli assistenti moderni dimenticano ancora tutto quando chiudi la scheda, a meno che qualcosa non venga persistito oltre la finestra di contesto. I fornitori di memoria per agenti sono servizi o librerie che conservano fatti e riepiloghi tra una sessione e l’altra — spesso integrati come plugin, in modo che il framework rimanga snello mentre la memoria scala.

Questa guida confronta i backend di memoria disponibili come plugin di memoria esterna per Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne e Memori — ed spiega come si inseriscono negli stack di sistemi AI più ampi. Gli stessi fornitori compaiono in OpenClaw e in altri strumenti per agenti tramite integrazioni della community o ufficiali. Il hub Memoria per Sistemi AI](https://www.glukhov.org/it/ai-systems/memory/) elenca questo articolo insieme a Cognee e guide correlate.

Per la memoria core delimitata specifica di Hermes (MEMORY.md e USER.md), il comportamento di congelamento e i trigger, consulta Sistema di Memoria di Hermes Agent. Per il contesto su come i fornitori di memoria nativi di Hermes contribuiscano al suo crescente vantaggio di adozione rispetto a OpenClaw — incluse le stelle GitHub, le classifiche dei token OpenRouter e i confronti di dimensioni dell’ecosistema — vedi OpenClaw vs Hermes Agent: Stelle, Download e Utilizzo 2026.

Esiste un altro asse che conta tanto quanto la qualità del recupero: la governance della memoria. I fornitori differiscono notevolmente per ciò che acquisiscono automaticamente, se l’output generato dall’assistente può diventare memoria durevole, se le riflessioni vengono salvate come fatti, come vengono risolte le contraddizioni e se un umano può rivedere una scrittura prima che diventi contesto futuro. Per agenti in esecuzione prolungata, queste differenze possono contare più di qualche punto in più in un benchmark di richiamo — vedi Loop di Memoria Auto-Rinforzanti negli Agenti AI per capire perché l’acquisizione automatica può trasformare una conclusione generata in una premessa futura, e Mnemosyne per Hermes Agent: Guida Rapida alla Memoria Locale per una configurazione conservativa dettagliata.

Hermes Agent elenca dieci plugin di fornitori di memoria esterna per una conoscenza persistente e inter-sessione — gli originali otto più Mnemosyne e Memori. Solo un fornitore 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. Tutti i fornitori esterni, tranne Holographic, richiedono 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 per la privacy, i costi e per la possibilità che il tuo stack di memoria possa funzionare completamente auto-ospitato. Hindsight, ByteRover e Mnemosyne includono o eliminano la maggior parte delle dipendenze; Honcho, Mem0 e Supermemory richiedono più componenti mobili. Se un fornitore supporta Ollama o qualsiasi endpoint compatibile con OpenAI, puoi instradare le chiamate LLM e di embedding verso un modello locale e mantenere i dati lontani da server di terze parti.

Attivazione con Hermes Agent

I passaggi da riga di comando qui sotto ricalcano le tabelle nella scheda rapida CLI di Hermes Agent.

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

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

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

Confronto Fornitori

Policy di acquisizione e governance

L’archiviazione e le dipendenze rispondono alla domanda “posso eseguirlo?”. La tabella qui sotto risponde a una domanda diversa che conta tanto quanto per gli agenti in esecuzione prolungata: cosa viene scritto senza che sia richiesto, e può un umano o una policy intervenire prima che diventi durevole? Vedi Loop di Memoria Auto-Rinforzanti negli Agenti AI per capire perché questo asse è importante.

Queste sono categorie di rischio architetturale, non punteggi di qualità — un fornitore sofisticato configurato con cura può essere più sicuro nella pratica di uno semplice configurato male.

Analisi Dettagliata

Honcho

Ideale per: sistemi multi-agente, contesto inter-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 peer che scambiano messaggi — un peer utente più un peer AI per ogni profilo Hermes, tutti che condividono uno workspace.

Dipendenze esterne: Honcho richiede un LLM per la sintesi delle sessioni, la derivazione della rappresentazione utente e il ragionamento dialettico; un modello di embedding per la ricerca semantica tra osservazioni; PostgreSQL con l’estensione pgvector per l’archiviazione vettoriale; e Redis per la cache. Il cloud gestito a api.honcho.dev gestisce tutto questo per te. Per i deploy auto-ospitati (Docker, K3s o Fly.io), fornisci tu le tue credenziali. Lo slot LLM accetta qualsiasi endpoint compatibile con OpenAI, incluso Ollama e vLLM, in modo che l’inferenza possa restare on-premise. Lo slot di embedding ha come default openai/text-embedding-3-small ma supporta fornitori 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 carta peer), honcho_search (ricerca semantica), honcho_context (contesto di sessione — sintesi, rappresentazione, carta, messaggi), honcho_reasoning (sintetizzato da LLM), honcho_conclude (creazione/eliminazione conclusioni).

Manopole di configurazione chiave:

• contextCadence (default 1): Turni minimi tra rinfreschi del livello base
• dialecticCadence (default 2): Turni minimi tra chiamate LLM peer.chat() (consigliato 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 di flush: async, turn, session, o intero N
• observationMode (default ‘directional’): directional (tutto attivo) o unified (pool condiviso)

Modalità di osservazione e auto-modellazione. directional, il default per configurazioni nuove, consente sia ai peer utente sia AI di osservare se stessi e gli altri — ragionamento dialettico più ricco, ma significa anche che i messaggi creati dall’AI contribuiscono al modello di Honcho sull’AI stessa. unified è l’opzione più conservativa: l’AI modella l’utente dai messaggi utente senza costruire il loop di auto-osservazione corrispondente dal proprio output. Chiunque sia specificamente preoccupato per le conclusioni generate che si riverberino nel ragionamento futuro — vedi Loop di Memoria Auto-Rinforzanti negli Agenti AI — dovrebbe trattare unified come il default più sicuro.

Architettura: Iniezione di contesto a due livelli — livello base (sintesi di sessione + rappresentazione + carta peer) + supplemento dialettico (ragionamento LLM). Seleziona automaticamente prompt cold-start vs warm.

Mapping 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).

Setup:

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                   # Riempie retroattivamente i peer AI per i profili esistenti

OpenViking

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

OpenViking fornisce una gerarchia di filesystem con caricamento a livelli. È gratuito, auto-ospitato, e ti dà il controllo totale sulla tua archiviazione di 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 fornitori VLM supportati includono OpenAI, Anthropic, DeepSeek, Gemini, Moonshot e vLLM (per deploy locali). Per gli embedding, i fornitori supportati includono OpenAI, Volcengine (Doubao), Jina, Voyage e — tramite Ollama — qualsiasi modello di embedding servito localmente. L’assistente interattivo openviking-server init può rilevare la RAM disponibile e raccomandare modelli Ollama adatti (es. Qwen3-Embedding 8B per embedding, Gemma 4 27B per VLM) e configurare tutto automaticamente per un setup completamente locale, senza chiavi API. Non è richiesto un database esterno; OpenViking memorizza la memoria nel filesystem.

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

Memoria utente vs memoria agente. Il modello di identità di OpenViking può separare lo spazio dei nomi della memoria dell’utente da un peer assistente opzionale. Questa separazione è importante per l’igiene della memoria: i fatti sull’utente e l’esperienza generata dall’agente non hanno bisogno di condividere la stessa policy di ritenzione, il che è una proprietà utile se si desidera isolare lo stato creato dall’assistente dallo stato creato dall’utente.

Setup:

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

Mem0

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

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

Dipendenze esterne: Mem0 richiede un LLM per l’estrazione della memoria (default: OpenAI gpt-4.1-nano; 20 fornitori 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 fornitori supportati, inclusi Ollama e HuggingFace per modelli locali). L’archiviazione usa Qdrant in /tmp/qdrant in modalità libreria, o PostgreSQL con pgvector in modalità server auto-ospitato — entrambi possono funzionare localmente. Uno stack Mem0 completamente locale, senza cloud, è raggiungibile: Ollama per LLM, Ollama per embedding, e un’istanza Qdrant locale, tutti configurati tramite Memory.from_config.

Mem0 è fondamentalmente un sistema di estrazione: un LLM trasforma il materiale conversazionale in memorie discrete ed esegue la logica di deduplicazione e aggiornamento. Questo è comodo, ma significa che la provenienza dell’estrazione conta — una conclusione generata dall’assistente può diventare strutturalmente indistinguibile da un fatto affermato dall’utente a meno che il percorso di acquisizione non lo filtri prima che l’estrazione venga eseguita.

Strumenti: mem0_profile, mem0_search, mem0_conclude.

Setup:

pip install mem0ai
hermes memory setup  # seleziona "mem0"
echo "MEM0_API_KEY=la-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 strumento reflect unico esegue sintesi inter-memoria — combinando più memorie in nuove intuizioni. Il richiamo esegue quattro strategie di recupero in parallelo (semantica, parola chiave/BM25, attraversamento del grafo, temporale), poi unisce e riordina i risultati usando reciprocal rank fusion.

Dipendenze esterne: Hindsight richiede un LLM per l’estrazione di fatti e entità nelle chiamate retain, e per la sintesi nelle chiamate reflect (default: OpenAI; fornitori supportati includono Anthropic, Gemini, Groq, Ollama, LM Studio e qualsiasi endpoint compatibile con OpenAI). Embedding e reranking hanno come default modelli locali in-process (SentenceTransformers; l’immagine Docker fat hindsight-all include BGE + MiniLM), e puoi sostituirli con altri modelli locali o un endpoint esterno compatibile con OpenAI / TEI — ad esempio Qwen3-Embedding-0.6B e BGE-reranker-v2-m3 su CPU. PostgreSQL è incluso tramite un data directory gestito pg0, o puoi puntare Hindsight a un’istanza PostgreSQL esterna. Per un percorso generativo completamente locale, imposta HINDSIGHT_API_LLM_PROVIDER a un server locale compatibile con OpenAI (Ollama o llama.cpp); retain e recall funzionano completamente, e reflect richiede un modello in grado di fare tool-calling.

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

Setup:

hermes plugins install hindsight
hermes memory setup hindsight   # seleziona local_external per una API Hindsight separata

La modalità cloud accetta ancora una chiave API in ~/.hermes/.env. L’installazione auto-ospitata usa Docker Compose contro PostgreSQL incorporato o esistente — vedi il tour illustrato linkato qui sotto. Richiede una coppia client/API Hindsight aggiornata (la documentazione del plugin cita >= 0.4.22).

Configurazione: $HERMES_HOME/hindsight/config.json

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

UI Locale: hindsight-embed -p hermes ui start

Per il tour illustrato completo di auto-ospitamento — Docker Compose, embedding e reranking locali, controllo del percorso di scrittura (auto_retain), e collegamento local_external di Hermes — vedi Hindsight per Hermes Agent: Memoria Auto-Ospitata con LLM Locali.

Per un’igiene della memoria conservativa, impostare auto_retain=false lasciando auto_recall=true vale la considerazione — il richiamo semantico rimane disponibile, ma i turni completati non entrano più automaticamente nella memoria a lungo termine. Tratta l’output di reflect come conoscenza derivata sintetizzata tra le memorie, non come un’osservazione indipendente con lo stesso peso probante delle memorie da cui è stata costruita.

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 scoring di fiducia per l’affidabilità della memoria. Nessuna dipendenza cloud — tutto funziona localmente sul tuo hardware.

Dipendenze esterne: Nessuna. Holographic non richiede LLM, modello di embedding, database o connessione di rete. La codifica della memoria viene eseguita interamente tramite l’algebra HRR che gira in-process. Questo lo rende unico tra tutti i fornitori in questo confronto — è l’unico che opera con zero chiamate esterne. Il compromesso è che la qualità del recupero è inferiore alla ricerca semantica basata su embedding, e non c’è sintesi inter-memoria come reflect di Hindsight. Per gli utenti per i quali privacy e operazione a zero dipendenze sono non negoziabili, Holographic è l’unica opzione che lo garantisce incondizionatamente.

auto_extract ha come default false, quindi Holographic può operare principalmente come un piccolo database di fatti espliciti con punteggi di fiducia piuttosto che come una pipeline autonoma da trascrizione a memoria. Combinato con le sue zero dipendenze, lo rende una delle due opzioni più semplici — insieme a Mnemosyne — per i lettori che deliberatamente non vogliono l’acquisizione automatica.

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 usa la compressione delta per archiviare efficientemente gli aggiornamenti di memoria e il retrieval ibrido (vettoriale + 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, la pipeline di embedding e il reranking girano tutti sull’infrastruttura cloud di RetainDB stessa — fornisci solo una RETAINDB_KEY. L’estrazione della memoria usa Claude Sonnet lato server. Non c’è opzione di auto-ospitamento e nessuna modalità locale. Tutti i dati di conversazione vengono inviati ai server di RetainDB per elaborazione e archiviazione. Se la sovranità dei dati o l’operazione offline sono importanti per il tuo caso d’uso, questo fornitore non è adatto.

Strumenti: retaindb_profile (profilo utente), retaindb_search (ricerca semantica), retaindb_context (contesto rilevante al task), retaindb_remember (archiviazione con tipo + importanza), retaindb_forget (eliminazione memorie).

L’integrazione di RetainDB con Hermes è cresciuta oltre un database di memoria remoto — ora include sintesi dialettica e un auto-modello dell’agente, il che lo mette architetturalmente più vicino a Honcho che a un semplice store vettoriale. Questo è utile per la continuità ma aumenta anche l’importanza di separare i fatti di origine dall’interpretazione generata, la stessa preoccupazione che si applica alla modalità directional di Honcho.

Setup:

hermes memory setup  # seleziona "retaindb"

Mnemosyne

Ideale per: memoria local-first con controlli granulari di ritenzione, archiviazione SQLite ispezionabile, fatti strutturati, memoria temporale e consolidamento configurabile.

Mnemosyne non è uno dei fornitori di memoria bundle originali di Hermes — viene fornito come un plugin di provider Hermes separato ma si integra tramite la stessa interfaccia MemoryProvider. Il suo principale vantaggio è il controllo: l’autosave della conversazione può essere limitato per ruolo o disabilitato completamente con sync_roles: [], la logging dei risultati degli strumenti è off di default, le operazioni esplicite remember/recall/forget rimangono disponibili indipendentemente, e le versioni più recenti includono un’opzionale soppressione dell’auto-echo attorno ai confini di compressione del contesto.

Dipendenze esterne: Nessuna per l’installazione core; l’extra embeddings aggiunge la ricerca vettoriale locale. L’archiviazione è locale SQLite con FTS5 e retrieval vettoriale opzionale. Il sistema mantiene anche memoria di lavoro, memoria episodica, fatti strutturati, triple temporali, fatti canonici e consolidamento.

Mnemosyne implementa anche scritture a stadi specifiche del fornitore per memory.write_approval di Hermes, sebbene l’approvazione dei fornitori esterni non sia ancora standardizzata tra Hermes, quindi questo percorso dovrebbe essere testato contro le esatte versioni in deploy. L’aggiunta di sofisticazione ha un costo: la memoria derivata crea più stati di ciclo di vita da ispezionare e ripulire. Le recenti release di Mnemosyne hanno specificamente rafforzato la validazione dei conflitti, il comportamento di eliminazione e la gestione dell’auto-echo — vedi Loop di Memoria Auto-Rinforzanti negli Agenti AI per l’audit di produzione che ha motivato il cambiamento nella validazione dei conflitti.

Setup:

python -m pip install "mnemosyne-memory[embeddings]" mnemosyne-hermes
mnemosyne-hermes install
hermes config set memory.provider mnemosyne

Per un’installazione completa e una panoramica della configurazione conservativa, vedi Mnemosyne per Hermes Agent: Guida Rapida alla Memoria Locale.

Memori

Ideale per: agenti in cui la storia delle esecuzioni conta tanto quanto la storia della conversazione.

Memori è un’integrazione Hermes più recente focalizzata su memoria strutturata consapevole degli strumenti. Cattura i turni completati insieme al contesto di esecuzione disponibile — utilizzo degli strumenti, passaggi di workflow, decisioni, esiti e vincoli — il che è eccellente per ricordare il lavoro operativo ma crea anche una superficie di feedback più ampia, poiché azioni, decisioni del modello ed esiti degli strumenti possono tutti diventare memoria strutturata durevole.

A differenza dei fornitori che iniettano principalmente un grande blocco di memoria prima di ogni turno, Memori espone strumenti espliciti di richiamo e summary di richiamo, permettendo all’agente di recuperare il contesto operativo quando ne ha effettivamente bisogno piuttosto che a ogni prompt. Questo riduce l’inquinamento del prompt ma non rimuove da solo il rischio di feedback sul lato di scrittura — i turni completati e le tracce di esecuzione possono ancora essere catturati automaticamente in background, quindi Memori si adatta agli utenti che vogliono che un agente impari dal lavoro precedente più che alle installazioni che richiedono una ritenzione strettamente solo esplicita.

Setup:

pip install hermes-memori
hermes memory setup  # seleziona "memori"

ByteRover

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

ByteRover memorizza 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, ne ragiona e colloca la conoscenza estratta nel punto giusto della gerarchia. Il recupero è MiniSearch full-text search con fallback a livelli a ricerca potenziata da LLM, senza necessità di un database vettoriale.

Dipendenze esterne: ByteRover richiede un LLM per la curatela della memoria e la ricerca (18 fornitori 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 piane. Il sincronizzazione cloud è opzionale e usata solo per la collaborazione di team; tutto funziona completamente offline di default. Per un setup locale completamente auto-contenuto, collega Ollama come provider (brv providers connect openai-compatible --base-url http://localhost:11434/v1) e nessun dato lascia la tua macchina.

Hermes espone auto_extract: false per disabilitare gli hook di curatela automatica, il che mette ByteRover vicino a Holographic e Mnemosyne nel gruppo di fornitori in cui l’acquisizione automatica è opt-in piuttosto che default.

Strumenti: 3 strumenti per operazioni di memoria.

Setup:

hermes memory setup  # seleziona "byterover"

Supermemory

Ideale per: workflow enterprise con contengono di contesto e ingest di grafo di sessione.

Supermemory fornisce contenimento di contesto (isolamento della memoria per contesto) e ingest di grafo di sessione (importazione di intere storie di conversazione). Estrae automaticamente memorie, costruisce profili utente ed esegue retrieval ibrido combinando ricerca semantica e per parola chiave. L’API cloud gestita è il principale obiettivo di deploy.

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-ospitamento è disponibile esclusivamente come add-on del piano enterprise e si deploya su Cloudflare Workers; richiede di fornire PostgreSQL con l’estensione pgvector (per archiviazione vettoriale) e una chiave API OpenAI (obbligatoria, con Anthropic e Gemini come aggiunte opzionali). Non esiste un percorso di auto-ospitamento basato su Docker o locale — l’architettura è strettamente accoppiata all’edge compute di Cloudflare Workers. Per gli utenti che hanno bisogno di piena sovranità dei dati senza un contratto enterprise, questo fornitore non è la scelta giusta.

L’integrazione Hermes corrente scrive una sessione completa attraverso l’endpoint di conversazione di Supermemory come unità, bufferizzando la conversazione e ingerendola a fine sessione, reset o compressione. Questo produce un contesto di entità e profilo più ricco delle scritture di fatti isolate, ma significa anche che il testo generato dall’assistente fa parte del materiale presentato alla pipeline di estrazione della memoria, non solo le affermazioni degli utenti.

Strumenti: 4 strumenti per operazioni di memoria.

Setup:

hermes memory setup  # seleziona "supermemory"

Come scegliere

Invece di scegliere un vincitore globale, abbina il fornitore al compito:

• Memoria locale esplicita più semplice: Holographic — zero dipendenze, auto_extract off di default
• Memoria locale con controlli di ciclo di vita più ricchi: Mnemosyne — SQLite, ritenzione granulare, soppressione auto-echo
• Sintesi pesante su grafi: Hindsight — grafo di conoscenza più reflect
• Modellazione di peer o utente: Honcho — ragionamento dialettico, modalità unified per auto-modellazione conservativa
• Conoscenza in stile filesystem: OpenViking — gerarchia a livelli viking://
• Estrazione automatica senza pensieri: Mem0 — estrazione di fatti basata su LLM senza configurazione
• Memoria operativa/consapevole degli strumenti: Memori — cattura di turni e tracce di esecuzione
• Leggibile dall’uomo, auditabile, senza pipeline di embedding: ByteRover — albero di contesto markdown piano
• Containmeto di contesto enterprise: Supermemory — ingest di grafo di sessione, ospitato su Cloudflare
• Aggiornamenti ad alta frequenza, nessun auto-ospitamento necessario: RetainDB — compressione delta, auto-modello dialettico

Per configurazioni complete di fornitori per profilo e pattern di workflow reali, vedi setup di produzione Hermes Agent.

L’ecosistema più ampio di memoria Hermes di terze parti

Hermes documenta un’interfaccia package/plugin per fornitori di memoria esterni, incluse directory installate dall’utente e entry point Python, quindi l’ecosistema si estende ora oltre i fornitori con sezioni complete sopra. Alcuni vale la pena conoscerli senza aggiungere una sezione completa ciascuno:

• Scope Recall tratta SQLite come verità durevole mantenendo la cattura della conversazione grezza separata, con un compagno opzionale turn-closure-audit per la revisione conservativa post-turno — separa le prove grezze del diario dalla memoria semantica durevole invece di trattare ogni turno catturato come immediatamente equivalente a conoscenza a lungo termine.
• Cognee è una pipeline di ingest di grafo di conoscenza / ECL piuttosto che un plugin di memoria conversazionale Hermes. Eccelle nella memoria strutturata di progetto o istituzionale ma è più automatico di un store di fatti esplicito; vedi la guida rapida Self-Hosting Cognee e Come scegliere il giusto LLM per Cognee piuttosto che trattarlo come un provider Hermes drop-in.
• AgentMemory enfatizza eventi sorgente, auditabilità e semantica di eliminazione — rilevante dopo i problemi di record derivati orfani discussi per Mnemosyne sopra.
• XMemo offre default conservativi: la cattura automatica della timeline può restare off, e l’eliminazione può essere vincolata. L’adozione è ancora abbastanza precoce da non giustificare una sezione completa.

Guide correlate

• Hub Memoria per Sistemi AI — ambito di questo subcluster e link alle guide Cognee
• Loop di Memoria Auto-Rinforzanti negli Agenti AI — perché policy di acquisizione e porte di approvazione contano, in profondità
• Mnemosyne per Hermes Agent: Guida Rapida alla Memoria Locale — installazione completa e configurazione conservativa per il provider Mnemosyne coperto sopra
• Sistema di Memoria di Hermes Agent — memoria core a due file prima dei plugin
• setup di produzione Hermes Agent — collegamento dei profili per i fornitori nella pratica