Shared Memory per flotte di agent: hermes-memory-pgvector
Quando si eseguono più agent IA — un minion per il marketing, un minion per il trading, un minion per la risposta agli incidenti — ognuno di loro ha bisogno di memoria. Lo strumento di memoria integrato fornisce a ogni agent la propria. Questo va bene finché non si vuole che la condividano, o finché non si vuole richiamare ciò che l'agent ha imparato sei settimane fa senza pagare un round-trip LLM solo per recuperarlo.
hermes-memory-pgvector è un piccolo plugin Postgres + pgvector che rispecchia le scritture di memoria degli agent in un archivio condiviso, embedded e interrogabile. Release attuale su PyPI: v1.0.0.
Novità nella v1.0.0 — una superficie stabile
La 1.0.0 dichiara stabile la superficie pubblica secondo il versioning semantico: chiavi di configurazione, nomi degli strumenti, comandi CLI e codici di uscita, e nomi delle tabelle. Viene rilasciata dopo una revisione pre-release in più passaggi che ha corretto un bug di perdita di dati e una serie di problemi minori, senza modifiche allo schema rispetto alla 0.6.0. Dalla v0.5.0 una semplice pip install registra il provider tramite un entry point, quindi lo shim di discovery descritto sotto è necessario solo su host meno recenti. Dettagli: hermes-memory-pgvector 1.0: A Stable Memory Surface.
Novità nella v0.4.2 — installazione pip-native
hermes-agent scopre i provider di memoria scansionando le directory dei plugin (plugins/memory/<name>/ integrati, $HERMES_HOME/plugins/<name>/ utente) — non cerca mai in site-packages, quindi un semplice pip install lasciava il plugin correttamente installato e completamente invisibile. La v0.4.2 chiude questa lacuna: pip install mette il codice sulla macchina, e un comando hermes-pgvector install genera lo shim di discovery che il framework effettivamente legge.
Novità nella v0.4.1 — richiamo ibrido (vettoriale + full-text)
recall_memory e recall_conversation ora fondono il ranking cosine HNSW con un ranking full-text di PostgreSQL tramite Reciprocal Rank Fusion (k=60). Una riga emerge se uno dei due ranker la apprezza, il che corregge i due punti ciechi della pura ricerca vettoriale: hit lessicali esatti che il cosine attenua (codici di errore, hostname, flag, identificatori rari), e righe solo testo con un embedding NULL — scritte mentre l'endpoint di embedding era giù — 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 "no LLM nel percorso critico" e ha aggiunto quattro capacità a livello di archiviazione:
- Identity governance. Le chiavi di sessione dei messaggi diretti si riducono a un unico bucket sicuro per la privacy — niente proliferazione di temi per contatto, niente PII — il traffico di benchmark è messo in quarantena, e una allow-list opzionale instrada nomi di temi con errori di battitura verso un default sicuro invece di crearne silenziosamente uno nuovo.
- Attribuzione & delega degli agent. Un nuovo registro e archi di provenienza registrano quale agent ha delegato cosa a chi, interrogabile tramite una vista del database. Pura provenienza who/when — mai un fact store.
- Backfill degli embedding. Le righe scritte solo testo durante un guasto dell'endpoint di embedding non sono più abbandonate: un comando idempotente le ri-embeddinga così tornano ricercabili.
- TTL delle conversazioni e controlli di costo. Un prune eseguito dall'operatore taglia i vecchi turni di chat (le memorie durevoli non vengono mai toccate), e una policy di embedding regola il costo degli embedding verso l'alto o verso il basso.
Il tutto viene fornito dietro una CLI di manutenzione (hermes-pgvector) i cui comandi distruttivi hanno il dry-run come impostazione predefinita. La linea 0.4.x è un aggiornamento drop-in dalla v0.3.x — applica le migrazioni additive e i nuovi hook si attivano; saltali e tutto il resto funziona invariato.
Cosa fa effettivamente
In una riga: "uno storage layer che fornisce al modello di memoria integrato un backing durevole, multi-tenant e ricercabile semanticamente, senza LLM nel percorso critico."
Due tabelle, entrambe con indici vettoriali HNSW. memory_entries rispecchia le scritture nei file MEMORY.md/USER.md dell'agent. conversations memorizza i turni di chat sostanziali (≥40 caratteri, con il boilerplate filtrato). Gli embedding sono 768-dim, calcolati da un endpoint esterno — Ollama, compatibile con OpenAI, a vostra scelta. L'agent non si ferma mai su di esso: le scritture ritornano in microsecondi e il worker di embedding gestisce il resto su una coda in background.
Temi per agent per impostazione predefinita
Ogni richiesta trasporta un header X-Hermes-Session-Key che scopa i dati per agent_identity. Le note del marketing non inquinano il richiamo del trading. Quando si desidera effettivamente una ricerca cross-theme, passare esplicitamente scope='all'. Il default è quello sicuro.
Perché standalone, non un fork
hermes-agent ha chiuso la lista dei provider di memoria integrati per policy, quindi questo vive come una scansione separata della directory /plugins invece di un fork upstream. Mettilo accanto all'agent, imposta alcune chiavi di configurazione, riavvia. Il rollback è simmetrico: disabilita il provider, opzionalmente elimina le tabelle. Nessuno stato di lunga durata da migrare, nessuna patch del kernel da mantenere.
Cosa non è
Non è un sostituto di Honcho. Non è un knowledge graph. Non è un framework RAG. È intenzionalmente un layer sottile che fa una cosa sola — trasformare lo strumento di memoria integrato in un archivio condiviso, durevole e ricercabile vettorialmente — e si toglie di mezzo. Nessun deriver LLM, nessun loop dialettico, nessuna opinione su come si dovrebbe chunkare o rerankare. Solo matematica vettoriale.
Ottienilo
pip install hermes-memory-pgvector
hermes-pgvector install
Sorgente, migrazione e configurazione su GitHub: