Memoria condivisa per flotte di agenti: hermes-memory-pgvector
Quando esegui più di un agente AI — un minion marketing, un minion di trading, un minion di risposta agli incidenti — ognuno ha bisogno di memoria. Lo strumento di memoria integrato dà a ciascun agente la propria. Va bene finché non vuoi condividerla, oppure finché non vuoi richiamare ciò che l'agente ha imparato sei settimane fa senza pagare un round-trip a un LLM solo per cercarlo.
hermes-memory-pgvector è un piccolo plugin Postgres + pgvector che replica le scritture della memoria dell'agente in un archivio condiviso, incorporato e interrogabile. Pubblicato su PyPI alla v0.4.2.
Nuovo nella v0.4.2 — installazione nativa con pip
hermes-agent scopre i provider di memoria scansionando le directory dei plugin (plugins/memory/<name>/ incluso nel bundle, $HERMES_HOME/plugins/<name>/ utente) — non guarda mai in site-packages, quindi pip install da solo lasciava il plugin correttamente installato e completamente invisibile. La v0.4.2 colma questa lacuna: pip install mette il codice sulla macchina, e un singolo comando hermes-pgvector install genera lo shim di discovery che il framework legge davvero.
Nuovo nella v0.4.1 — richiamo ibrido (vettoriale + full-text)
recall_memory e recall_conversation ora fondono il ranking coseno HNSW con un ranking full-text di PostgreSQL usando Reciprocal Rank Fusion (k=60). Una riga emerge se piace a entrambi i ranker, e questo corregge i due punti ciechi della sola ricerca vettoriale: corrispondenze lessicali esatte che il coseno attenua (codici di errore, hostname, flag, identificatori rari) e righe solo testuali con un embedding NULL — scritte mentre l'endpoint di embedding era inattivo — che l'indice vettoriale non può vedere affatto. Il richiamo ibrido funge anche da recupero best-effort per quelle righe fino alla successiva esecuzione di backfill.
Cosa ha aggiunto la v0.4.0
Quella release ha mantenuto la regola "nessun LLM nel percorso critico" e ha aggiunto quattro capacità a livello di storage:
- Governance dell'identità. Le chiavi di sessione dei messaggi diretti confluiscono in un unico bucket sicuro per la privacy — nessuna proliferazione di temi per contatto, nessun PII — il traffico di benchmark viene isolato in quarantena, e una allow-list opzionale indirizza i nomi dei temi digitati male verso un valore predefinito sicuro invece di creare silenziosamente un nuovo tema.
- Attribuzione e delega dell'agente. Un nuovo registry e archi di provenance registrano quale agente ha delegato cosa a chi, interrogabili tramite una vista del database. Pura provenance di chi/quando — mai un fact store.
- Backfill degli embedding. Le righe scritte solo in testo durante un'interruzione dell'endpoint di embedding non restano più bloccate: un comando idempotente le re-incorpora così tornano a essere ricercabili.
- TTL della conversazione e controllo dei costi. Un prune eseguito dall'operatore elimina i vecchi turni di chat (le memorie durevoli non vengono mai toccate), e una policy di embedding regola verso l'alto o verso il basso il costo degli embedding.
Tutto viene fornito dietro una CLI di manutenzione (hermes-pgvector) i cui comandi distruttivi impostano per default il dry-run. La linea 0.4.x è un upgrade drop-in dalla v0.3.x — applica le migrazioni additive e i nuovi hook si attivano; saltali e tutto il resto continua a funzionare invariato.
Cosa fa davvero
In una riga: "uno strato di storage che offre al modello di memoria integrato un backing durevole, multi-tenant e semanticamente ricercabile, senza alcun LLM nel percorso critico."
Due tabelle, entrambe con indici vettoriali HNSW. memory_entries replica le scritture nei file MEMORY.md/USER.md dell'agente. conversations memorizza i turni di chat sostanziali (≥40 caratteri, con il testo boilerplate filtrato). Gli embedding sono a 768 dimensioni, calcolati da un endpoint esterno — Ollama, compatibile con OpenAI, a tua scelta. L'agente non resta mai bloccato su questo: le scritture ritornano in microsecondi e il worker degli embedding gestisce il resto su una coda in background.
Temi per agente per impostazione predefinita
Ogni richiesta include un header X-Hermes-Session-Key che delimita i dati in base a agent_identity. Le note del marketing non contaminano il richiamo del trading. Quando vuoi davvero una ricerca cross-theme, passa esplicitamente scope='all'. Il default è quello sicuro.
Perché standalone, non un fork
hermes-agent ha chiuso per policy il proprio elenco interno di provider di memoria, quindi questa soluzione vive come scansione separata della directory /plugins invece che come fork upstream. Mettila accanto all'agente, imposta alcune chiavi di configurazione, riavvia. Il rollback è simmetrico: disabilita il provider, opzionalmente elimina le tabelle. Nessuno stato a lunga durata da migrare, nessuna patch del kernel da mantenere.
Cosa non è
Non è un sostituto di Honcho. Non è una knowledge graph. Non è un framework RAG. È intenzionalmente uno strato sottile che fa una sola cosa — trasformare lo strumento di memoria integrato in un archivio condiviso, durevole e ricercabile tramite vettori — e poi si mette da parte. Nessun derivatore LLM, nessun loop dialettico, nessuna opinione su come dovresti fare chunking o reranking. Solo matematica vettoriale.
Ottienilo
pip install hermes-memory-pgvector
hermes-pgvector install
Codice sorgente, migrazioni e configurazione su GitHub: