Memoria compartida para flotas de agentes: hermes-memory-pgvector
Cuando ejecutas más de un agente de IA —un minion de marketing, un minion de trading, un minion de respuesta a incidentes— cada uno necesita memoria. La herramienta de memoria integrada le da a cada agente la suya propia. Esto está bien hasta que quieres que la compartan, o hasta que quieres recordar lo que el agente aprendió hace seis semanas sin pagar por un viaje de ida y vuelta al LLM solo para consultarlo.
hermes-memory-pgvector es un pequeño complemento de Postgres + pgvector que refleja las escrituras de memoria del agente en un almacén compartido, embebido y consultable. Versión actual en PyPI: v1.0.0.
Novedades de la v1.0.0 — una superficie estable
1.0.0 declara la superficie pública estable bajo versionado semántico: claves de configuración, nombres de herramientas, comandos de la CLI y códigos de salida, y nombres de tablas. Se publica tras una revisión de prelanzamiento de varias pasadas que corrigió un error de pérdida de datos y un conjunto de problemas menores, sin cambios de esquema desde 0.6.0. Desde la v0.5.0, un simple pip install registra el proveedor mediante un entry point, así que el shim de descubrimiento descrito más abajo solo es necesario en hosts más antiguos. Detalles: hermes-memory-pgvector 1.0: A Stable Memory Surface.
Novedades de la v0.4.2 — instalación nativa con pip
hermes-agent descubre los proveedores de memoria escaneando directorios de complementos (plugins/memory/<name>/ incluido, $HERMES_HOME/plugins/<name>/ de usuario) — nunca busca en site-packages, así que pip install por sí solo dejaba el complemento correctamente instalado y completamente invisible. La v0.4.2 cierra esa brecha: pip install coloca el código en la máquina, y un comando hermes-pgvector install genera el shim de descubrimiento que el framework realmente lee.
Novedades de la v0.4.1 — recuperación híbrida (vectorial + texto completo)
recall_memory y recall_conversation ahora combinan la clasificación coseno de HNSW con una clasificación de texto completo de PostgreSQL usando Reciprocal Rank Fusion (k=60). Una fila aparece si cualquiera de los clasificadores la favorece, lo que corrige los dos puntos ciegos de la búsqueda puramente vectorial: las coincidencias léxicas exactas que el coseno difumina (códigos de error, nombres de host, flags, identificadores raros), y las filas solo de texto con un embedding NULL —escritas mientras el endpoint de embeddings estaba caído— que el índice vectorial no puede ver en absoluto. La recuperación híbrida sirve también como recuperación de mejor esfuerzo para esas filas hasta la próxima ejecución de backfill.
Qué añadió la v0.4.0
Esa versión mantuvo la regla de "ningún LLM en la ruta crítica" y añadió cuatro capacidades de la capa de almacenamiento:
- Gobernanza de identidad. Las claves de sesión de mensajes directos se colapsan en un único bucket seguro para la privacidad —sin proliferación de temas por contacto, sin PII— el tráfico de benchmark se pone en cuarentena, y una lista de permitidos opcional redirige los nombres de tema con erratas a un valor predeterminado seguro en lugar de acuñar uno nuevo en silencio.
- Atribución y delegación de agentes. Un nuevo registro y aristas de procedencia registran qué agente delegó qué a quién, consultable a través de una vista de base de datos. Procedencia pura de quién/cuándo —nunca un almacén de hechos.
- Backfill de embeddings. Las filas escritas solo como texto durante una caída del endpoint de embeddings ya no quedan varadas: un comando idempotente las re-embebe para que vuelvan a ser buscables.
- TTL de conversación y controles de coste. Una poda ejecutada por el operador recorta turnos de chat antiguos (las memorias duraderas nunca se tocan), y una política de embeddings sube o baja el coste de embeddings.
Todo esto se entrega detrás de una CLI de mantenimiento (hermes-pgvector) cuyos comandos destructivos están por defecto en dry-run. La línea 0.4.x es una actualización drop-in desde la v0.3.x —aplica las migraciones aditivas y los nuevos hooks se activan; si las omites, todo lo demás funciona sin cambios.
Qué hace realmente
En una línea: "una capa de almacenamiento que da al modelo de memoria integrado un respaldo duradero, multi-tenant y con búsqueda semántica, sin un LLM en la ruta crítica."
Dos tablas, ambas con índices vectoriales HNSW. memory_entries refleja las escrituras en los archivos MEMORY.md/USER.md del agente. conversations almacena turnos de chat sustantivos (≥40 caracteres, con el texto repetitivo filtrado). Los embeddings son de 768 dimensiones, calculados por un endpoint externo —Ollama, compatible con OpenAI, tú eliges—. El agente nunca se bloquea por ello: las escrituras devuelven en microsegundos y el worker de embeddings se encarga del resto en una cola en segundo plano.
Temas por agente por defecto
Cada petición lleva una cabecera X-Hermes-Session-Key que delimita los datos por agent_identity. Las notas de marketing no contaminan la recuperación de trading. Cuando realmente quieres búsqueda entre temas, pasa scope='all' explícitamente. El valor por defecto es el seguro.
Por qué independiente, no un fork
hermes-agent cerró su lista de proveedores de memoria integrados por política, así que esto vive como un escaneo de directorio /plugins independiente en lugar de un fork upstream. Colócalo junto al agente, configura unas pocas claves, reinicia. La reversión es simétrica: desactiva el proveedor, y opcionalmente elimina las tablas. No hay estado de larga duración que migrar, ni parches del kernel que mantener.
Qué no es
No es un sustituto de Honcho. No es un grafo de conocimiento. No es un framework RAG. Es intencionadamente una capa fina que hace una sola cosa —convertir la herramienta de memoria integrada en un almacén compartido, duradero y con búsqueda vectorial— y se quita del medio. Sin derivador LLM, sin bucle dialéctico, sin opinión sobre cómo deberías fragmentar o re-clasificar. Solo matemática vectorial.
Consíguelo
pip install hermes-memory-pgvector
hermes-pgvector install
Código fuente, migración y configuración en GitHub: