Mnemosyne per Hermes Agent: avvio rapido della memoria locale

Mnemosyne è un provider di memoria local-first per Hermes Agent, che archivia memoria operativa, fatti strutturati, dati temporali e storico episodico in SQLite locale — nessun servizio gestito, nessuna chiamata di rete obbligatoria e un controllo delle scritture insolitamente granulare.

La sua proprietà più utile non è la qualità della memoria grezza. È la quantità di controllo che espone sul percorso di scrittura: l’auto-salveggio delle conversazioni può essere limitato per ruolo o disattivato del tutto, il logging dei risultati degli strumenti è disattivato di default, le operazioni esplicite di remember e forget rimangono disponibili indipendentemente, e le release più recenti aggiungono la soppressione opzionale degli echi di sé attorno ai confini di compressione del contesto. Questa combinazione lo rende una scelta ragionevole quando si desidera una memoria persistente senza trasformare automaticamente ogni conversazione in conoscenza permanente.

La disciplina del percorso di scrittura è importante perché la memoria degli agenti ha un modo di fallimento ampiamente documentato: l’inferenza stessa di un modello può essere catturata, recuperata in seguito come se fosse un’osservazione, e usata per giustificare una versione ancora più forte di sé stessa. Cicli di memoria auto-rinforzanti negli agenti AI copre quel modo di fallimento in profondità; questa guida si concentra sulla configurazione concreta di Mnemosyne che lo limita nella pratica. Per capire dove si colloca Mnemosyne rispetto agli altri backend di memoria Hermes, consulta Confronto dei provider di memoria per agenti.

Mnemosyne in un minuto

Un provider di memoria tipico esegue una versione di cattura, estrazione, archiviazione, recupero, quindi iniezione in un prompt futuro. Mnemosyne aggiunge diversi layer distinti attorno a quel loop di base: memoria operativa, recupero semantico e lessicale, fatti strutturati, informazioni temporali, link entità, memoria episodica, consolidamento, fatti canonici e validazione della memoria. Lo storage è SQLite locale con FTS5 e recupero vettoriale opzionale, il che lo rende considerevolmente più ispezionabile di un prodotto di memoria solo cloud e più capace di un semplice file MEMORY.md.

Molto brevemente, rispetto al resto dell’ecosistema di provider Hermes: Holographic è più semplice e deliberatamente orientato allo storage di fatti; Hindsight enfatizza il recupero ibrido, i grafi di conoscenza e la riflessione; Honcho enfatizza il modello di pari e utente con ragionamento dialettico; Mem0 enfatizza l’estrazione automatica di fatti basata su LLM; e Mnemosyne combina storage SQLite locale, recupero ibrido, consolidamento, fatti strutturati e controlli di ritenzione insolitamente granulari. La suddivisione completa, inclusi i requisiti infrastrutturali e le note di self-hosting per ogni provider, si trova in Confronto dei provider di memoria per agenti.

Versioni attuali

A settembre 2026, la release stabile su PyPI è mnemosyne-memory 3.15.1, con il ramo 4.0 disponibile come pre-release. Per un’installazione Hermes di produzione, si consiglia di partire dalla versione stabile a meno che non si necessiti specificamente di una correzione o funzionalità 4.0 e si sia pronti a testare la migrazione del database e la variazione di comportamento. Verificare la versione installata con:

hermes mnemosyne version

Installazione di Mnemosyne in Hermes

Attivare prima l’ambiente virtuale di Hermes se si è utilizzata l’installazione locale standard:

source ~/.hermes/hermes-agent/venv/bin/activate

Per il supporto a embedding locali, installare il pacchetto core con l’extra embeddings più il wrapper plugin Hermes:

python -m pip install \
  "mnemosyne-memory[embeddings]" \
  mnemosyne-hermes

Poi registrare il plugin:

mnemosyne-hermes install

Se si sta sostituendo una registrazione del plugin esistente:

mnemosyne-hermes install --force

Attivare il provider e riavviare il gateway:

hermes config set memory.provider mnemosyne
hermes gateway restart

Verificare con:

hermes memory status

L’output previsto è simile a:

Provider: mnemosyne

Plugin: installed
Status: available

Installazioni Docker e server persistenti

Se Hermes viene eseguito all’interno di una distribuzione Docker persistente o basata su immagini, installare in un ambiente virtuale secondario nella home Hermes montata invece che nell’ambiente Python ricostruibile del container, in modo che il plugin sopravviva alle ricostruzioni dell’immagine:

export HERMES_HOME=/opt/data
VENV="$HERMES_HOME/.mnemosyne/venv"
python3 -m venv "$VENV"
"$VENV/bin/python" -m pip install --upgrade "mnemosyne-memory[embeddings]" mnemosyne-hermes
"$VENV/bin/mnemosyne-hermes" install --mode wrapper --python "$VENV/bin/python"
hermes config set memory.provider mnemosyne

L’ambiente virtuale secondario deve utilizzare la stessa versione principale/minore di Python del gateway Hermes in esecuzione — non puntarlo a un python3 non correlato nel PATH. Riavviare quindi il container o il servizio effettivo e verificare con "$VENV/bin/mnemosyne-hermes" status insieme a hermes memory status.

Non disattivare l’intero set di strumenti di memoria di Hermes

Mantenere separati due concetti: la memoria incorporata di Hermes stessa (MEMORY.md / USER.md, coperta in dettaglio in Sistema di memoria di Hermes Agent) e il provider esterno (Mnemosyne). Non eseguire casualmente hermes tools disable memory quando si configura un provider esterno — a seconda della versione di Hermes, quel comando può anche nascondere gli strumenti dei provider di memoria esterni. Utilizzare invece la configurazione del provider, come mostrato di seguito.

Stato di base e ispezione

hermes memory status
hermes mnemosyne stats
hermes mnemosyne stats --global
hermes mnemosyne inspect "query"

Esportare un backup portatile:

hermes mnemosyne export \
  --output ~/mnemosyne-backup.json

Il database di supporto si trova normalmente sotto ~/.hermes/mnemosyne/data/mnemosyne.db. Essendo SQLite, l’ispezione e il backup sono semplici con gli strumenti standard. Per il resto dei comandi gateway, sessione e diagnostica menzionati in questa guida, la scheda rapida CLI di Hermes Agent è un riferimento più veloce che setacciare l’output di --help.

La politica di ritenzione di default merita attenzione

Il primo controllo da comprendere è sync_roles. I valori predefiniti attuali di Mnemosyne sono già più conservativi delle prime release — la sincronizzazione automatica di Hermes è predefinita per i turni utente piuttosto che per entrambi i turni utente e assistente — ma per una ritenzione esplicita rigorosa, disattivare completamente l’auto-salveggio dei turni vale il passo aggiuntivo. Modificare ~/.hermes/config.yaml:

memory:
  provider: mnemosyne

  mnemosyne:
    sync_roles: []

Un elenco vuoto significa che i turni di conversazione ordinari non vengono salvati automaticamente da sync_turn(). Le operazioni esplicite mnemosyne_remember continuano a funzionare indipendentemente — la conversazione normale smette di fluire automaticamente in memoria, mentre un “ricorda questo” esplicito raggiunge ancora Mnemosyne.

Disattivare il logging automatico dei risultati degli strumenti

Mnemosyne può anche registrare le esecuzioni degli strumenti come memoria. Per una configurazione conservatrice, lasciarlo disattivato in ~/.hermes/.env:

MNEMOSYNE_LOG_TOOLS=0

Questo è già il valore predefinito, ma impostarlo esplicitamente documenta la politica piuttosto che fare affidamento su un’assunzione sui valori predefiniti. Riavviare Hermes successivamente:

hermes gateway restart

Con sync_roles: [] e MNEMOSYNE_LOG_TOOLS=0 insieme, entrambi i principali percorsi di scrittura automatica — auto-salveggio della conversazione e auto-salveggio dei risultati degli strumenti — sono disattivati.

Mantenere il recupero automatico

Disattivare le scritture automatiche non richiede di disattivare il recupero. Una politica utile mantiene la ritenzione automatica off mentre il recupero automatico, il remember esplicito e il forget esplicito restano accesi — la memoria dovrebbe essere facile da leggere e difficile da scrivere, che è vicino all’opposto di un valore predefinito “cattura tutto e ordina dopo”.

Aggiungere un’istruzione persistente per l’agente

La configurazione del provider blocca la cattura a livello di provider, ma il modello può ancora decidere di chiamare uno strumento di scrittura esplicito di propria iniziativa. Aggiungere una politica esplicita a SOUL.md:

## Politica di memoria a lungo termine

Mnemosyne è il provider di memoria a lungo termine.

Non scrivere nulla in Mnemosyne a meno che l'utente non chieda esplicitamente di
ricordare, salvare, ritenere o archiviare quell'informazione.

Se un'informazione sembra utile per sessioni future ma l'utente non ha
richiesto esplicitamente che venga ricordata, chiedere il permesso prima di chiamare
mnemosyne_remember o un altro strumento di scrittura di Mnemosyne.

Non creare memorie durevoli dal proprio ragionamento, assunzioni,
riassunti, interpretazioni, conclusioni o preferenze inferite.

Non creare memorie durevoli dall'output degli strumenti a meno che l'utente non
chieda esplicitamente che quel risultato venga ricordato.

Quando si archivia una memoria approvata, preservare ciò che l'utente ha effettivamente dichiarato.
Non abbellirlo con contesto o conclusioni inferite.

Leggere e recuperare le memorie di Mnemosyne è consentito senza chiedere
il permesso.

Riavviare il gateway e iniziare una nuova sessione successivamente:

hermes gateway restart

/new

Questa è una politica imposta dal modello, non un confine di permesso rigido — integra la configurazione a livello di provider sopra descritta piuttosto che sostituirla.

Che dire di memory.write_approval?

Hermes supporta memory.write_approval: true per le scritture in MEMORY.md / USER.md incorporate, e Mnemosyne implementa una propria staging specifica del provider per le scritture esplicite nelle release più recenti. Questo è promettente, ma c’è un’avvertenza architetturale che va presa seriamente: Hermes non espone ancora un contratto di approvazione uniforme e indipendente dal provider per tutti i provider di memoria esterni, e l’implementazione pending/apply di Mnemosyne è specifica del provider piuttosto che parte di uno standard condiviso. Non dare per scontato che l’approvazione funzioni correttamente solo perché la chiave di configurazione è presente — testarla contro le proprie versioni esatte di Hermes e Mnemosyne. Fino a quando l’approvazione indipendente dal provider non matura, combinare sync_roles: [], MNEMOSYNE_LOG_TOOLS=0 e la politica di scrittura esplicita in SOUL.md sopra descritta fornisce una linea di base affidabile, con il percorso di approvazione testato separatamente se si intende fare affidamento su di esso.

Abilitare la soppressione dell’eco di sé

L’attuale Mnemosyne offre anche la soppressione opzionale dell’eco di sé:

MNEMOSYNE_SELF_ECHO_ENABLED=1

Metterlo in ~/.hermes/.env, poi riavviare:

hermes gateway restart

La soppressione dell’eco di sé mira specificamente ai confini di compressione del contesto — il suo scopo è ridurre i casi in cui la memoria appena creata dal provider viene immediatamente re-iniettata nell’agente come se fosse un contesto indipendente. È deliberatamente best-effort e non sostituisce il filtraggio delle scritture: i controlli di scrittura impediscono alle memorie dubbie di entrare in primo luogo, mentre i controlli dell’eco di sé impediscono all’output recente del provider di rimbalzare subito indietro. Entrambi contano, e nessuno sostituisce l’altro.

Una configurazione conservatrice di Mnemosyne

Mettendo insieme i pezzi, una configurazione iniziale per un agente ingegneristico personale self-hosted è la seguente. In ~/.hermes/config.yaml:

memory:
  provider: mnemosyne

  mnemosyne:
    sync_roles: []

In ~/.hermes/.env:

MNEMOSYNE_LOG_TOOLS=0
MNEMOSYNE_SELF_ECHO_ENABLED=1

E in SOUL.md, almeno:

Archiviare la memoria a lungo termine solo quando l'utente lo richiede esplicitamente.
Non promuovere conclusioni generate dal modello o output degli strumenti in memoria durevole
senza permesso esplicito.

Testare che la conversazione ordinaria non venga ritenuta

Verificare prima il conteggio di base:

hermes mnemosyne stats

Iniziare una nuova sessione Hermes e dire una frase fattuale semplice senza chiedere all’agente di ricordarla, per esempio:

PurpleOtter uses port 48123.

Poi cercarla:

hermes mnemosyne inspect "PurpleOtter"

Atteso: Results for 'PurpleOtter': 0. Ricontrollare anche hermes mnemosyne stats — il conteggio della memoria operativa non dovrebbe essere aumentato a causa di quel turno ordinario.

Testare la memoria esplicita

Ora dire lo stesso tipo di frase, ma chiedere esplicitamente la ritenzione:

Remember that BlueKoala uses port 17321.

Ispezionarla, poi iniziare una nuova sessione e richiederla:

hermes mnemosyne inspect "BlueKoala"

/new

What port does BlueKoala use?

Hermes dovrebbe recuperare il valore correttamente — questa coppia di test isola la politica del percorso di scrittura (nulla entra senza chiedere) dal meccanismo di recupero (ciò che entra esce in modo affidabile).

Testare il logging degli strumenti

Con MNEMOSYNE_LOG_TOOLS=0 impostato, chiedere a Hermes di eseguire un comando distintivo e unico:

Use the terminal tool to run:
echo tool-canary-834729

Poi cercare la stringa canary:

hermes mnemosyne inspect "tool-canary-834729"

Atteso: 0 results. Questo è un test molto più forte che fidarsi semplicemente che la variabile d’ambiente sia rispettata ovunque.

Ispezionare il database

Essendo lo storage SQLite, lo schema interno è direttamente ispezionabile:

sqlite3 ~/.hermes/mnemosyne/data/mnemosyne.db '.tables'

A seconda della versione, si potrebbero vedere tabelle come working_memory, episodic_memory, facts, consolidated_facts, gists, graph_edges, memoria_facts e memory_embeddings. Questo è importante quando si testa l’eliminazione — un sistema di memoria può rimuovere con successo una riga di memoria operativa lasciando un fatto derivato, un gist o un oggetto grafico. Mnemosyne ha avuto bug reali in quest’area coinvolgenti record derivati orfani, e le release più recenti hanno ristretto sia l’eliminazione che la diagnostica di conseguenza. Preferire i percorsi di eliminazione supportati dal provider e i percorsi di doctor/repair rispetto alla cancellazione manuale delle righe SQLite a meno di non comprendere completamente lo schema attuale.

Eliminazione della memoria operativa con ambito di sessione

Una sottigliezza: le memorie operative di Mnemosyne possono avere ambito di sessione, quindi una riga con scope = session potrebbe non essere visibile a un’eliminazione standalone che opera nella sessione default. Quando si fanno debug, ispezionare l’ambito direttamente:

SELECT id, session_id, scope, content
FROM working_memory;

Il provider o l’API necessita dell’ambito di sessione corretto per mutare i record locali alla sessione — un’altra ragione per preferire gli strumenti di amministrazione supportati rispetto alle modifiche SQL grezze.

Consolidamento: non affrettarsi con sleep()

Mnemosyne può consolidare la memoria operativa in rappresentazioni a vita più lunga, il che è utile ma è un’operazione mutante. Prima di abilitare un consolidamento automatico aggressivo, ispezionare ciò che viene effettivamente catturato, verificare che i turni ordinari non stiano entrando in memoria inaspettatamente, verificare l’eliminazione da capo a fine, e creare un backup del database. Poi sperimentare con:

hermes mnemosyne sleep

I recenti cambiamenti di Mnemosyne hanno reso la gestione dei conflitti più conservatrice — la sola similarità semantica non dimostra più che una memoria dovrebbe invalidarne un’altra, che è esattamente la direzione in cui un sistema di memoria per agenti durevole dovrebbe muoversi, come coperto in Cicli di memoria auto-rinforzanti negli agenti AI.

Backup prima degli aggiornamenti

Creare un’export portatile prima di qualsiasi cambiamento significativo:

hermes mnemosyne export \
  --output ~/mnemosyne-backup.json

Per installazioni importanti, copiare anche il database locale o la directory dei dati prima degli aggiornamenti maggiori. Mnemosyne 4.x è attualmente una linea pre-release, quindi un aggiornamento di versione maggiore merita più cautela di un aggiornamento di patch di routine.

Configurazione finale consigliata

Per un’installazione Hermes a lungo termine dove l’accuratezza della memoria conta più che ricordare tutto, la configurazione durevole è: storage locale Mnemosyne acceso, recupero automatico acceso, auto-salveggio conversazioni disattivato, auto-salveggio messaggi assistente disattivato, logging risultati strumenti disattivato, remember e forget espliciti accesi, soppressione eco di sé accesa, ricerca di sessione accesa, e revisione umana per scritture sensibili desiderabile una volta testato il percorso di approvazione. Questo fa funzionare Mnemosyne principalmente come un archivio di memoria a lungo termine curato piuttosto che un archivio di trascrizioni — l’obiettivo non è fare sì che Hermes ricordi tutto ciò che ha mai detto, ma farlo ricordare le cose che saranno ancora vere quando inizierà la prossima sessione. Se si eseguono più profili con provider o politiche di ritenzione diverse, [Configurazione di produzione di Hermes Agent](https://www.glukhov.org/it/ai-systems/hermes/production-setup/ “Configurazione Hermes basata su profili per ingegneri, ricercatori e operatori.”}) copre il collegamento a livello di profilo per mantenerli coerenti. Se si preferisce eseguire la memoria come un servizio Docker separato con un grafico di conoscenza e un’operazione di riflessione, [Hindsight per Hermes Agent](https://www.glukhov.org/it/ai-systems/hermes/hindsight-for-hermes-local-llms/ “Deploy di Hindsight per Hermes Agent con Docker e PostgreSQL. Collegamento di embedding e reranking locali Qwen3 attraverso Ollama o llama.cpp, senza inferenza cloud.”}) è la guida al provider esterno basato su Docker.