Memoria degli agenti: confronto tra provider, policy di cattura e self-hosting

Aggiornato a settembre 2026: aggiunti Mnemosyne e Memori, estesa la configurazione di Honcho e Hindsight, e aggiunta una tabella comparativa delle policy di cattura accanto alla tabella originale sull’infrastruttura.

Gli assistenti moderni dimenticano ancora tutto quando chiudi la scheda, a meno che qualcosa non permanga al di fuori della finestra di contesto. I fornitori 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 resti leggero mentre la memoria scala.

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

Per la memoria core a lunghezza finita specifica di Hermes (MEMORY.md e USER.md), il comportamento di congelamento e i trigger, vedere Sistema di Memoria di Hermes Agent. Il collegamento dei fornitori è un livello di una gerarchia più ampia della conoscenza degli agenti — file di identità, memoria residente, abilità, wiki e archivi di memoria, ciascuno con il proprio trigger di iniezione — mappata in Contesto a livelli: una gerarchia di conoscenza per agenti AI. Per il contesto su come i fornitori di memoria nativi di Hermes contribuiscano al loro crescente vantaggio di adozione rispetto a OpenClaw — incluse stelle su GitHub, classifiche di token su OpenRouter e confronti della dimensione dell’ecosistema — vedere OpenClaw vs Hermes Agent: Stelle, Download e Utilizzo 2026.

Esiste un altro asse che conta tanto quanto la qualità del richiamo: la governance della memoria. I fornitori differiscono drasticamente su cosa catturano automaticamente, se l’output generato dall’assistente può diventare memoria durevole, se le riflessioni vengono memorizzate come fatti, come vengono risolte le contraddizioni e se un umano può rivedere una scrittura prima che diventi contesto futuro. Per agenti a lungo termine, queste differenze possono contare più di altri pochi punti su un benchmark di richiamo — vedere Loop di Memoria Autorigeneranti negli Agenti AI per il motivo per cui la cattura automatica può trasformare una conclusione generata in una premessa futura, e Mnemosyne per Hermes Agent: avvio rapido della memoria locale per una configurazione conservativa dimostrata.

Hermes Agent elenca dieci plugin di fornitori di memoria esterni per la conoscenza persistente e tra sessioni — gli originali otto più Mnemosyne e Memori. Solo un fornitore esterno può essere attivo alla volta. I file integrati MEMORY.md e USER.md restano caricati accanto ad esso — aggiuntivi, non sostitutivi.

Dipendenze esterne. Ogni fornitore 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, sui costi e sulla possibilità di eseguire completamente il tuo stack di memoria in autogestione. Hindsight, ByteRover e Mnemosyne incapsulano o eliminano le dipendenze maggiori; Honcho, Mem0 e Supermemory richiedono il maggior numero di componenti in movimento. Dove un fornitore supporta Ollama o qualsiasi endpoint compatibile con OpenAI, è possibile instradare le chiamate LLM e di embedding a un modello locale e mantenere i dati completamente fuori dai server di terze parti.

Attivazione con Hermes Agent

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

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

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

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

Confronto dei fornitori

Policy di cattura e governance

L’archiviazione e le dipendenze rispondono alla domanda “posso eseguirlo?”. La tabella qui sotto risponde a una domanda diversa che conta tanto per gli agenti a lungo termine: cosa viene scritto senza essere richiesto e un umano o una policy possono intervenire prima che diventi durevole? Vedere Loop di Memoria Autorigeneranti negli Agenti AI per il motivo per cui questo asse conta.

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.

Dettaglio

Honcho

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

Honcho opera accanto alla memoria esistente — USER.md resta invariato, e Honcho aggiunge un ulteriore livello di contesto. Modella le conversazioni come peer che scambiano messaggi — un peer utente più un peer AI per profilo Hermes, tutti che condividono un workspace.

Dipendenze esterne: Honcho richiede un LLM per la sintesi delle sessioni, 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 caching. Il cloud gestito su api.honcho.dev gestisce tutto questo per te. Per i deploy autogestiti (Docker, K3s o Fly.io), fornisci le tue credenziali. Lo slot LLM accetta qualsiasi endpoint compatibile con OpenAI, incluso Ollama e vLLM, in modo che l’inferenza possa restare in loco. Lo slot di embedding predefinisce 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 (leggere/aggiornare la scheda del peer), honcho_search (ricerca semantica), honcho_context (contesto di sessione — sintesi, rappresentazione, scheda, messaggi), honcho_reasoning (sintetizzato da LLM), honcho_conclude (creare/eliminare conclusioni).

Principali parametri di configurazione:

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

Modalità di osservazione e modellazione autonoma. directional, il default per le nuove configurazioni, permette sia ai peer utente che AI di osservare sé stessi e gli altri — ragionamento dialettico più ricco, ma significa anche che i messaggi autografi AI contribuiscono al modello di Honcho dell’AI stessa. unified è l’opzione più conservativa: l’AI modella l’utente dai messaggi utente senza costruire il loop di auto-osservazione corrispondente dal suo stesso output. Chiunque sia specificamente preoccupato dalle conclusioni generate che alimentano il ragionamento futuro — vedere Loop di Memoria Autorigeneranti negli Agenti AI — dovrebbe trattare unified come il default più sicuro.

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

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

Configurazione:

hermes memory setup  # seleziona "honcho"
# oppure 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                   # Riempie retroattivamente i peer AI per i profili esistenti

OpenViking

Ideale per: gestione della conoscenza autogestita con navigazione strutturata.

OpenViking fornisce una gerarchia di filesystem con caricamento a livelli. È gratuito, autogestito, e ti dà il pieno controllo 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 sono obbligatori. I fornitori VLM supportati includono OpenAI, Anthropic, DeepSeek, Gemini, Moonshot e vLLM (per il deploy locale). Per gli embedding, i fornitori supportati includono OpenAI, Volcengine (Doubao), Jina, Voyage e — tramite Ollama — qualsiasi modello di embedding servito localmente. Il mago 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 VLM) e configurare tutto automaticamente per un setup completamente locale, senza API key. Nessun database esterno è richiesto; OpenViking archivia 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 namespace di memoria dell’utente da un peer assistente opzionale. Questa separazione conta 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 vuoi isolare lo stato autografo dell’assistente dallo stato autografo dell’utente.

Configurazione:

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

Mem0

Ideale per: gestione della memoria senza intoppi 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 autogestito ti danno il pieno controllo.

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 retrieval (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 autogestito — entrambi possono girare localmente. Uno stack Mem0 completamente locale, zero-cloud è fattibile: Ollama per LLM, Ollama per embedding, e un’istanza Qdrant locale, tutto configurato 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. Ciò è comodo, ma significa che la provenienza dell’estrazione conta — una conclusione generata dall’assistente può diventare strutturalmente indistinguibile da un fatto dichiarato dall’utente a meno che il percorso di cattura non la filtri fuori prima che l’estrazione si esegua.

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, estragendo entità e relazioni. Il suo unico strumento reflect esegue la sintesi tra memorie — combinando più memorie in nuovi spunti. Il richiamo esegue quattro strategie di retrieval in parallelo (semantica, parola chiave/BM25, attraversamento del grafo, temporale), quindi unisce e riordina i risultati usando la fusione di ranking reciproca.

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; fornitori supportati includono Anthropic, Gemini, Groq, Ollama, LM Studio e qualsiasi endpoint compatibile con OpenAI). Gli embedding e il reranking predefiniscono modelli locali in-processo (SentenceTransformers; l’immagine Docker grassa/hindsight-all include BGE + MiniLM), e puoi sostituirli con altri modelli locali o un endpoint esterno compatibile con OpenAI / TEI — per esempio Qwen3-Embedding-0.6B e BGE-reranker-v2-m3 su CPU. PostgreSQL è incluso tramite un directory pg0 gestito, o puoi puntare Hindsight a un’istanza PostgreSQL esterna. Per un percorso generativo completamente locale, imposta HINDSIGHT_API_LLM_PROVIDER su un server locale compatibile con OpenAI (Ollama o llama.cpp); retain e recall funzionano completamente, e reflect ha bisogno di un modello con capacità di tool-calling.

Strumenti: hindsight_retain, hindsight_recall, hindsight_reflect (sintesi unica tra memorie).

Configurazione:

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

La modalità cloud accetta ancora una chiave API in ~/.hermes/.env. L’installazione autogestita usa Docker Compose contro PostgreSQL incorporato o esistente — vedere la descrizione collegata qui sotto. Richiede una coppia client/API Hindsight attuale (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 la descrizione autogestita completa — Docker Compose, embedding e reranking locali, controllo del percorso di scrittura (auto_retain), e collegamento local_external di Hermes — vedere Hindsight per Hermes Agent: memoria autogestita con LLM locali. OpenCode, la Cursor CLI e gli altri harness di coding usano un pacchetto diverso, con una banca per repository: Memoria Hindsight per OpenCode, Cursor e altri agenti di coding.

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

Holographic

Ideale per: configurazioni attente alla privacy con archiviazione solo locale.

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

Dipendenze esterne: Nessuna. Holographic non richiede LLM, modello di embedding, database o connessione di rete. La codifica della memoria è fatta interamente tramite l’algebra HRR eseguita in-processo. Ciò lo rende unico tra ogni fornitore in questo confronto — è l’unico che opera con zero chiamate esterne. Il compromesso è che la qualità del richiamo è inferiore alla ricerca semantica basata su embedding, e non c’è sintesi tra memorie come reflect di Hindsight. Per gli utenti per i quali la privacy e il funzionamento zero-dipendenze sono non negoziabili, Holographic è l’unica opzione che lo delivers incondizionatamente.

auto_extract predefinisce su 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, ciò lo rende una delle due opzioni più semplici — accanto a Mnemosyne — per i lettori che deliberatamente non vogliono la cattura automatica.

Strumenti: 2 strumenti per le 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 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, la pipeline di embedding e il reranking di RetainDB girano tutti sulla propria infrastruttura cloud di RetainDB — fornisci solo una RETAINDB_KEY. L’estrazione della memoria usa Claude Sonnet lato server. Non c’è opzione di autogestione e nessuna modalità locale. Tutti i dati di conversazione vengono inviati ai server RetainDB per l’elaborazione e l’archiviazione. Se la sovranità dei dati o il funzionamento offline contano per il tuo caso d’uso, questo fornitore 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).

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

Configurazione:

hermes memory setup  # seleziona "retaindb"

Mnemosyne

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

Mnemosyne non è uno dei fornitori di memoria originali bundled di Hermes — è fornito come un plugin di fornitore separato di Hermes ma si integra tramite la stessa interfaccia MemoryProvider. Il suo principale vantaggio è il controllo: l’autosalvataggio delle conversazioni può essere limitato per ruolo o disattivato completamente con sync_roles: [], il logging dei risultati degli strumenti è disattivato per impostazione predefinita, le operazioni esplicite remember/recall/forget restano disponibili indipendentemente, e le versioni più recenti includono opzionale soppressione dell’eco autonoma attorno ai confini di compressione del contesto.

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

Mnemosyne implementa anche scritture staggiate 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 versioni esatte in deploy. La sofisticazione aggiuntiva ha un costo: la memoria derivata crea più stati del ciclo di vita da ispezionare e pulire. Le release recenti di Mnemosyne hanno specificamente stretto la validazione dei conflitti, il comportamento di cancellazione e la gestione dell’eco autonoma — vedere Loop di Memoria Autorigeneranti negli Agenti AI per l’audit di produzione che ha motivato il cambiamento di validazione dei conflitti.

Configurazione:

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

Per l’installazione completa e una descrizione della configurazione conservativa, vedere Mnemosyne per Hermes Agent: avvio rapido della memoria locale.

Memori

Ideale per: agenti dove la cronologia di esecuzione conta tanto quanto la cronologia di conversazione.

Memori è un’integrazione Hermes più recente focalizzata sulla memoria strutturata consapevole degli strumenti. Cattura i turni completati insieme al contesto di esecuzione disponibile — uso degli strumenti, passi del workflow, decisioni, risultati e vincoli — il che è eccellente per ricordare il lavoro operativo ma crea anche una superficie di feedback più grande, poiché azioni, decisioni del modello e risultati 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 di sintesi del richiamo, permettendo all’agente di recuperare il contesto operativo quando ne ha effettivamente bisogno piuttosto che a ogni prompt. Ciò riduce l’inquinamento del prompt ma non rimuove di per sé il rischio di feedback lato scrittura — i turni completati e le tracce di esecuzione possono ancora essere catturati automaticamente in background, quindi Memori si adatta a utenti che vogliono un agente che impari dal lavoro precedente più che a installazioni che richiedono una ritenzione rigorosamente solo esplicita.

Configurazione:

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

ByteRover

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

ByteRover archivia la memoria come un albero di contesto markdown strutturato — una gerarchia di file dominio, argomento e sottoargomento — piuttosto che vettori di embedding o un database. Un LLM legge il contenuto sorgente, ragiona al riguardo e posiziona la conoscenza estratta nel punto giusto della gerarchia. Il retrieval è MiniSearch full-text con fallback a livelli alla ricerca pilotata da LLM, senza necessità di database vettoriale.

Dipendenze esterne: ByteRover richiede un LLM per la curation della memoria e la ricerca (18 fornitori supportati, inclusi Anthropic, OpenAI, Google, Ollama e qualsiasi endpoint compatibile con OpenAI tramite lo slot del fornitore openai-compatible). Non richiede alcun modello di embedding né alcun database — l’albero di contesto è una directory locale di file markdown piuma. La sincronizzazione cloud è opzionale e usata solo per la collaborazione di squadra; tutto funziona completamente offline per impostazione predefinita. Per un setup locale completamente autonomo, collega Ollama come fornitore (brv providers connect openai-compatible --base-url http://localhost:11434/v1) e nessun dato lascia la tua macchina.

Hermes espone auto_extract: false per disattivare gli hook di curation automatica, il che mette ByteRover vicino a Holographic e Mnemosyne nel gruppo di fornitori dove la cattura automatica è opt-in piuttosto che predefinita.

Strumenti: 3 strumenti per le operazioni di memoria.

Configurazione:

hermes memory setup  # seleziona "byterover"

Supermemory

Ideale per: flussi di lavoro enterprise con recinzionamento contestuale e ingestione grafo di sessione.

Supermemory fornisce il recinzionamento contestuale (isolare la memoria per contesto) e l’ingestione grafo di sessione (importare intere cronologie di conversazione). Estrae automaticamente memorie, costruisce profili utente ed esegue il retrieval ibrido combinando ricerca semantica e per parola chiave. L’API cloud gestita è il bersaglio di deploy 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’autogestione è disponibile esclusivamente come add-on del piano enterprise e si deploya 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 c’è percorso di autogestione basato su Docker o locale — l’architettura è strettamente accoppiata al calcolo edge di Cloudflare Workers. Per gli utenti che necessitano di piena sovranità dei dati senza un contratto enterprise, questo fornitore non è la scelta giusta.

L’integrazione attuale di Hermes scrive un’intera sessione tramite l’endpoint di conversazione di Supermemory come unità, facendo buffering della conversazione e ingegnerizzandola a fine sessione, reset o compressione. Ciò 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 utente.

Strumenti: 4 strumenti per le operazioni di memoria.

Configurazione:

hermes memory setup  # seleziona "supermemory"

Come scegliere

Piuttosto che scegliere un vincitore globale, abbina il fornitore al compito:

• Memoria esplicita locale più semplice: Holographic — zero dipendenze, auto_extract disattivato per impostazione predefinita
• Memoria locale con controlli del ciclo di vita più ricchi: Mnemosyne — SQLite, ritenzione granulare, soppressione dell’eco autonoma
• Sintesi intensiva su grafi: Hindsight — grafo di conoscenza più reflect
• Modellazione del peer o dell’utente: Honcho — ragionamento dialettico, modalità unified per modellazione autonoma conservativa
• Conoscenza stile filesystem: OpenViking — gerarchia viking:// a livelli
• Estrazione automatica senza intoppi: Mem0 — estrazione di fatti basata su LLM senza configurazione
• Memoria operativa/consapevole degli strumenti: Memori — cattura del turno e della traccia di esecuzione
• Leggibile dall’uomo, ispezionabile, nessuna pipeline di embedding: ByteRover — albero di contesto markdown piuma
• Recinzionamento contestuale enterprise: Supermemory — ingestione grafo di sessione, ospitato da Cloudflare
• Aggiornamenti ad alta frequenza, nessuna autogestione necessaria: RetainDB — compressione delta, modello dialettico autonomo

Per le configurazioni del fornitore per profilo complete e pattern di flussi di lavoro reali, vedere Configurazione di produzione di Hermes Agent.

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

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

• Scope Recall tratta SQLite come verità durevole mantenendo la cattura grezza della conversazione in scope separati, con un opzionale companion turn-closure-audit per la revisione conservativa post-turno — separa le prove del diario grezzo dalla memoria semantica durevole invece di trattare ogni turno catturato come conoscenza a lungo termine immediatamente equivalente.
• Cognee è una pipeline di ingestione grafo di conoscenza / ECL piuttosto che un plugin di memoria conversazionale Hermes. Eccelle nella memoria di progetto o istituzionale strutturata ma è più automatico di uno store di fatti esplicito; vedere l’avvio rapido autogestito di Cognee e Scegliere il giusto LLM per Cognee piuttosto che trattarlo come un provider drop-in Hermes.
• AgentMemory enfatizza gli eventi sorgente, l’ispezionabilità e le semantica di cancellazione — rilevante dopo i problemi di record derivati orfani discussi per Mnemosyne qui sopra.
• XMemo fornisce default conservativi: la cattura automatica della timeline può restare disattiva, e la cancellazione può essere vincolata. L’adozione è ancora abbastanza precoce da non giustificare ancora una sezione completa.

Guide correlate

• Hub Memoria dei Sistemi AI — ambito di questo subcluster e link alle guide di Cognee
• Loop di Memoria Autorigeneranti negli Agenti AI — perché la policy di cattura e le soglie di approvazione contano, in profondità
• Mnemosyne per Hermes Agent: avvio rapido della memoria locale — installazione completa e configurazione conservativa per il fornitore Mnemosyne coperto qui sopra
• Sistema di Memoria di Hermes Agent — memoria core a due file prima dei plugin
• Configurazione di produzione di Hermes Agent — collegamento dei fornitori per profilo nella pratica