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

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

Gli assistenti moderni dimenticano ancora tutto quando si chiude la scheda, a meno che qualcosa non venga preservato oltre la finestra di contesto. I fornitori 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 si espande.

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 inseriscono nelle stack più ampie di sistemi di IA. Gli stessi fornitori compaiono in OpenClaw e in altri strumenti per agenti tramite integrazioni della comunità o ufficiali. L’hub della memoria per sistemi di IA](https://www.glukhov.org/it/ai-systems/memory/) elenca questo articolo accanto a Cognee e alle guide correlate.

Per la memoria centrale delimitata specifica di Hermes (MEMORY.md e USER.md), il comportamento di congelamento e i trigger, consulta il 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 su GitHub, le classifiche dei token su OpenRouter e i confronti di dimensioni dell’ecosistema — vedi OpenClaw vs Hermes Agent: Stelle, Download & Uso 2026.

C’è un altro asse che conta quanto la qualità del recupero: la governance della memoria. I fornitori differiscono notevolmente su cosa acquisiscono automaticamente, se l’output generato dall’assistente può diventare memoria durevole, se le riflessioni vengono salvate come fatti, come vengono risolti i conflitti e se un umano può riesaminare una scrittura prima che diventi contesto futuro. Per agenti a lunga durata, queste differenze possono contare più di pochi altri punti su un benchmark di richiamo — vedi Cicli di Memoria Auto-Rinforzanti negli Agenti IA per capire come l’acquisizione automatica possa trasformare una conclusione generata in una premessa futura, e Mnemosyne per Hermes Agent: Guida Rapida alla Memoria Locale per una configurazione conservativa esemplificata.

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 rimangono caricati insieme a questo — in modo additivo, non sostitutivo.

Dipendenze esterne. Ogni fornitore esterno, eccetto Holographic, richiede almeno una chiamata a un servizio esterno — un LLM per l’estrazione della memoria, un modello di incorporamento per la ricerca semantica, o un database come PostgreSQL per lo storage. Queste dipendenze hanno implicazioni dirette per la privacy, il costo e se la tua stack di memoria può funzionare completamente in auto-ospitato. Hindsight, ByteRover e Mnemosyne aggregano o eliminano la maggior parte delle dipendenze; Honcho, Mem0 e Supermemory richiedono più componenti mobili. Dove un fornitore supporta Ollama o qualsiasi endpoint compatibile OpenAI, puoi instradare le chiamate LLM e di incorporamento a un modello locale e mantenere i dati interamente fuori dai server di terze parti.

Attivazione con Hermes Agent

I passaggi da 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     # Disabilita il fornitore esterno

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

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

Confronto dei Fornitori

Politica di acquisizione e governance

Lo storage e le dipendenze rispondono alla domanda “posso eseguirlo?”. La tabella qui sotto risponde a una domanda diversa che conta ugualmente per gli agenti a lunga durata: cosa viene scritto senza essere richiesto, e può un umano o una policy intervenire prima che diventi durevole? Vedi Cicli di Memoria Auto-Rinforzanti negli Agenti IA per capire perché questo asse conta.

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

Analisi Dettagliata

Honcho

Migliore 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 il riassunto delle sessioni, la derivazione della rappresentazione dell’utente e il ragionamento dialettico; un modello di incorporamento per la ricerca semantica tra le osservazioni; PostgreSQL con l’estensione pgvector per lo storage vettoriale; e Redis per la cache. Il cloud gestito su api.honcho.dev gestisce tutto questo per te. Per le installazioni auto-ospitate (Docker, K3s o Fly.io), fornisci le tue credenziali. Lo slot LLM accetta qualsiasi endpoint compatibile OpenAI, incluso Ollama e vLLM, in modo che l’inferenza possa restare in loco. Lo slot di incorporamento predefinito è openai/text-embedding-3-small ma supporta fornitori configurabili tramite LLM_EMBEDDING_API_KEY e LLM_EMBEDDING_BASE_URL — qualsiasi server di incorporamento compatibile 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 — riepilogo, rappresentazione, carta, messaggi), honcho_reasoning (sintetizzato da LLM), honcho_conclude (crea/elimina conclusioni).

Principali manopole di configurazione:

• contextCadence (predefinito 1): Turni minimi tra un refresh del livello base
• dialecticCadence (predefinito 2): Turni minimi tra le chiamate LLM di peer.chat() (raccomandato 1-5)
• dialecticDepth (predefinito 1): Passaggi .chat() per invocazione (limitato 1-3)
• recallMode (predefinito ‘hybrid’): hybrid (auto+strumenti), context (solo iniezione), tools (solo strumenti)
• writeFrequency (predefinito ‘async’): Tempistica dello scarico: async, turn, session, o intero N
• observationMode (predefinito ‘directional’): directional (tutti on) o unified (pool condiviso)

Modalità di osservazione e modellazione di sé. directional, la predefinita per le configurazioni nuove, permette sia ai peer utente che AI di osservare sé stessi e l’altro — ragionamento dialettico più ricco, ma significa anche che i messaggi autoriali dell’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 ciclo corrispondente di auto-osservazione dal proprio output. Chiunque sia specificamente preoccupato dalle conclusioni generate che si riversino nel ragionamento futuro — vedi Cicli di Memoria Auto-Rinforzanti negli Agenti IA — dovrebbe considerare unified la predefinita più sicura.

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

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 profilo Hermes (hermes predefinito, hermes.<profilo> per gli altri).

Configurazione:

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

Config: $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 i peer AI per i profili esistenti

OpenViking

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

OpenViking fornisce una gerarchia di file system con caricamento a livelli. È gratuito, auto-ospitato, e ti dà il pieno controllo sul tuo storage di memoria.

Dipendenze esterne: OpenViking richiede un VLM (vision-language model) per l’elaborazione semantica e l’estrazione della memoria, e un modello di incorporamento per la ricerca vettoriale — entrambi obbligatori. I fornitori VLM supportati includono OpenAI, Anthropic, DeepSeek, Gemini, Moonshot e vLLM (per deploy locale). Per gli incorporamenti, i fornitori supportati includono OpenAI, Volcengine (Doubao), Jina, Voyage e — tramite Ollama — qualsiasi modello di incorporamento servito localmente. L’assistente interattivo openviking-server init può rilevare la RAM disponibile e raccomandare modelli Ollama adatti (es. Qwen3-Embedding 8B per incorporamenti, Gemma 4 27B per VLM) e configurare tutto automaticamente per un setup completamente locale, senza chiavi API. Non è richiesto un database esterno; OpenViking salva la memoria nel file system.

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

Memoria utente rispetto alla 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 devono condividere la stessa politica di ritenzione, il che è una proprietà utile se vuoi isolare lo stato autorial dall’assistente dallo stato autorial dall’utente.

Configurazione:

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

Mem0

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

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

Dipendenze esterne: Mem0 richiede un LLM per l’estrazione della memoria (predefinito: OpenAI gpt-4.1-nano; supportati 20 fornitori, inclusi Ollama, vLLM e LM Studio per modelli locali) e un modello di incorporamento per il recupero (predefinito: OpenAI text-embedding-3-small; supportati 10 fornitori, inclusi Ollama e HuggingFace per modelli locali). Lo storage usa Qdrant su /tmp/qdrant in modalità libreria, o PostgreSQL con pgvector in modalità server auto-ospitato — entrambi possono girare localmente. È possibile realizzare una stack Mem0 completamente locale, zero-cloud: Ollama per LLM, Ollama per incorporamenti, 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. Questo è conveniente, ma significa che la provenienza dell’estrazione conta — una conclusione assistente generata può diventare strutturalmente indistinguibile da un fatto dichiarato dall’utente a meno che il percorso di acquisizione non la filtri prima che l’estrazione avvenga.

Strumenti: mem0_profile, mem0_search, mem0_conclude.

Configurazione:

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

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

Hindsight

Migliore per: recupero basato su grafi della conoscenza con relazioni tra entità.

Hindsight costruisce un grafo della tua memoria, estraendo entità e relazioni. Il suo strumento unico reflect esegue la sintesi tra memorie — combinando più memorie in nuove intuizioni. Il recupero esegue quattro strategie di ricerca in parallelo (semantica, keyword/BM25, traversata del grafo, temporale), poi unisce e riordina i risultati usando la fusione reciproca dei ranghi.

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; fornitori supportati includono Anthropic, Gemini, Groq, Ollama, LM Studio e qualsiasi endpoint compatibile OpenAI). Il modello di incorporamento e il modello di riordinazione a croce-incodificatore sono incorporati all’interno di Hindsight stesso — girano localmente all’interno del pacchetto hindsight-all e non richiedono API esterne. PostgreSQL è anche incorporato con l’installazione Python incorporata tramite un directory dati pg0 gestito; puoi alternativamente puntare Hindsight a un’istanza PostgreSQL esterna. Per un setup completamente locale, zero-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 chiamata di strumenti (es. qwen3:8b).

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

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.

Config: $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

Per un’igiene della memoria conservativa, impostare auto_retain=false lasciando auto_recall=true vale la pena considerare — il richiamo semantico resta disponibile, ma i turni completati non entrano più automaticamente nella memoria a lungo termine. Trattalo 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

Migliore per: setup focalizzati sulla privacy con solo storage locale.

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

Dipendenze esterne: Nessuna. Holographic non richiede LLM, modello di incorporamento, database e connessione di rete. L’encoding della memoria è fatto 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 incorporamenti, e non c’è sintesi tra memorie come reflect di Hindsight. Per utenti per cui la privacy e l’operazione a zero dipendenze sono non negoziabili, Holographic è l’unica opzione che lo offre incondizionatamente.

auto_extract è predefinito su false, quindi Holographic può operare principalmente come un piccolo database di fatti espliciti con punteggi di affidabilità piuttosto che come una pipeline autonoma da trascrizione a memoria. Combinato con le sue zero dipendenze, lo rende uno dei due servizi 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.

Configurazione:

hermes memory setup  # seleziona "holographic"

RetainDB

Migliore per: aggiornamenti ad alta frequenza con compressione delta.

RetainDB usa la compressione delta per memorizzare efficientemente gli aggiornamenti della memoria e il recupero ibrido (vettoriale + BM25 + riordinazione) per far emergere il contesto rilevante. È basato sul 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 incorporamento e la riordinazione 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 nessun modo locale. Tutti i dati della conversazione vengono inviati ai server RetainDB per l’elaborazione e lo storage. Se la sovranità dei dati o l’operazione 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 (salva con tipo + importanza), retaindb_forget (elimina memorie).

L’integrazione Hermes di RetainDB è cresciuta oltre un database di memoria remoto — ora include la sintesi dialettica e un modello di sé dell’agente, il che lo porta architettonicamente più vicino a Honcho che a un semplice store vettoriale. Questo è utile per la continuità ma solleva 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

Migliore per: memoria locale-first con controlli granulari di ritenzione, storage SQLite ispezionabile, fatti strutturati, memoria temporale e consolidamento configurabile.

Mnemosyne non è uno dei fornitori di memoria originali inclusi in Hermes — viene distribuito come un plugin di fornitore Hermes separato ma si integra tramite la stessa interfaccia MemoryProvider. Il suo principale vantaggio è il controllo: il salvataggio automatico della conversazione può essere limitato per ruolo o disabilitato completamente con sync_roles: [], la registrazione dei risultati degli strumenti è off per impostazione predefinita, le operazioni esplicite di ricordarsi/recuperare/dimenticare restano disponibili indipendentemente, e le versioni più recenti includono un’opzionale soppressione dell’auto-eco attorno ai confini di compressione del contesto.

Dipendenze esterne: Nessuna per l’installazione core; l’extra embeddings aggiunge la ricerca vettoriale locale. Lo storage è 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 a fasi specifiche del fornitore per Hermes memory.write_approval, sebbene l’approvazione dei fornitori esterni non sia ancora standardizzata in tutto Hermes, quindi questo percorso dovrebbe essere testato contro le versioni esatte in fase di distribuzione. La sofisticazione aggiuntiva ha un costo: la memoria derivata crea più stati del ciclo di vita da ispezionare e ripulire. Le release recenti di Mnemosyne hanno specificamente stretto la convalida dei conflitti, il comportamento di eliminazione e la gestione dell’auto-eco — vedi Cicli di Memoria Auto-Rinforzanti negli Agenti IA per l’audit di produzione che ha motivato il cambiamento nella convalida 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 un percorso per la configurazione conservativa, vedi Mnemosyne per Hermes Agent: Guida Rapida alla Memoria Locale.

Memori

Migliore per: agenti dove la storia di esecuzione conta quanto la storia della 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, passaggi del workflow, decisioni, risultati e vincoli — il che è eccellente per ricordare il lavoro operativo ma crea anche una superficie di feedback più ampia, poiché azioni, decisioni del modello e risultati degli strumenti possono tutti diventare memoria strutturata durevole.

A differenza dei fornitori che principalmente iniettano un blocco di memoria grande prima di ogni turno, Memori espone strumenti espliciti di richiamo e riepilogo del richiamo, permettendo all’agente di recuperare il contesto operativo quando ne ha davvero bisogno piuttosto che in ogni prompt. Questo riduce l’inquinamento del prompt ma non rimuove da solo 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 strettamente solo esplicita.

Configurazione:

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

ByteRover

Migliore per: memoria locale-first con storage leggibile e auditabile da umani.

ByteRover memorizza la memoria come un albero di contesto markdown strutturato — una gerarchia di file dominio, argomento e sotto-argomento — piuttosto che vettori di incorporamento o un database. Un LLM legge il contenuto sorgente, ragiona su di esso e posiziona le conoscenze estratte nella giusta posizione nella gerarchia. Il recupero è una ricerca full-text MiniSearch con fallback a livelli a ricerca alimentata da LLM, senza necessità di database vettoriale.

Dipendenze esterne: ByteRover richiede un LLM per la cura della memoria e la ricerca (supportati 18 fornitori, inclusi Anthropic, OpenAI, Google, Ollama e qualsiasi endpoint compatibile OpenAI tramite lo slot del fornitore openai-compatible). Non richiede un modello di incorporamento né un database — l’albero di contesto è un directory locale di file markdown semplici. 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 il tuo computer.

Hermes espone auto_extract: false per disabilitare gli hook di cura automatica, il che mette ByteRover vicino a Holographic e Mnemosyne nel gruppo di fornitori dove l’acquisizione automatica è opzionale piuttosto che predefinita.

Strumenti: 3 strumenti per operazioni di memoria.

Configurazione:

hermes memory setup  # seleziona "byterover"

Supermemory

Migliore per: workflow enterprise con recinzioni di contesto e ingestione del grafo di sessione.

Supermemory fornisce recinzioni di contesto (isolamento della memoria per contesto) e ingestione del grafo di sessione (importazione di intere storie di conversazione). Estrae automaticamente le memorie, costruisce profili utente ed esegue il recupero ibrido che combina ricerca semantica e per parole chiave. L’API cloud gestita è l’obiettivo di distribuzione principale.

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

L’integrazione Hermes corrente scrive un’intera sessione attraverso l’endpoint di conversazione di Supermemory come un’unità, tamponando la conversazione e ingrandendo alla fine della sessione, al reset o alla compressione. Questo produce un contesto di entità e profilo più ricco rispetto a scritture di fatti isolate, ma significa anche che il testo assistente generato è parte del materiale presentato al pipeline di estrazione della memoria, non solo le affermazioni dell’utente.

Strumenti: 4 strumenti per operazioni di memoria.

Configurazione:

hermes memory setup  # seleziona "supermemory"

Come scegliere

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

• Memoria locale esplicita più semplice: Holographic — zero dipendenze, auto_extract off per impostazione predefinita
• Memoria locale con controlli di ciclo di vita più ricchi: Mnemosyne — SQLite, ritenzione granulare, soppressione auto-eco
• Sintesi pesante su grafi: Hindsight — grafo della conoscenza più reflect
• Modellazione peer o utente: Honcho — ragionamento dialettico, modalità unified per modellazione di sé conservativa
• Conoscenza di tipo file system: OpenViking — gerarchia viking:// a livelli
• Estrazione automatica senza intervento: Mem0 — estrazione di fatti basata su LLM senza configurazione
• Memoria operativa/consapevole degli strumenti: Memori — acquisizione di turno e traccia di esecuzione
• Leggibile, auditabile, nessun pipeline di incorporamento: ByteRover — albero di contesto markdown semplice
• Recinzioni di contesto enterprise: Supermemory — ingestione del grafo di sessione, ospitato su Cloudflare
• Aggiornamenti ad alta frequenza, nessun auto-ospitamento necessario: RetainDB — compressione delta, modello dialettico di sé

Per configurazioni complete per profilo dei fornitori e pattern di workflow del mondo reale, vedi Configurazione di produzione di Hermes Agent.

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

Hermes documenta un’interfaccia pacchetto/plugin per fornitori di memoria esterni, incluse directory installate dall’utente e punti di ingresso Python, in modo che l’ecosistema ora si estenda oltre i fornitori con sezioni complete sopra. Ne vale la pena conoscere alcuni senza aggiungere una sezione completa per ciascuno:

• Scope Recall tratta SQLite come verità durevole mantenendo l’acquisizione grezza della conversazione in scope separati, con un compagno opzionale turn-closure-audit per revisione post-turno conservativa — separa le prove grezze del giornale dalla memoria semantica durevole invece di trattare ogni turno catturato come conoscenza a lungo termine immediatamente equivalente.
• Cognee è un pipeline di ingestione ECL/grafico della conoscenza piuttosto che un plugin di memoria conversazionale Hermes. Eccelle nella memoria strutturata di progetto o istituzionale ma è più automatica di uno store di fatti esplicito; vedi la Guida rapida per l’auto-ospitamento di Cognee e Scegliere il LLM giusto per Cognee invece di trattarlo come un fornitore drop-in Hermes.
• AgentMemory enfatizza gli eventi sorgente, l’auditabilità e la semantica dell’eliminazione — rilevante dopo i problemi di record derivati orfani discussi per Mnemosyne sopra.
• XMemo include predefiniti conservativi: l’acquisizione 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 della memoria per sistemi di IA — ambito di questo subcluster e link alle guide di Cognee
• Cicli di Memoria Auto-Rinforzanti negli Agenti IA — perché la politica di acquisizione e le porte di approvazione contano, in profondità
• Mnemosyne per Hermes Agent: Guida Rapida alla Memoria Locale — installazione completa e configurazione conservativa per il fornitore Mnemosyne coperto sopra
• Sistema di Memoria di Hermes Agent — memoria a due file centrale prima dei plugin
• Configurazione di produzione di Hermes Agent — cablaggio dei profili per i fornitori in pratica