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. Eso está bien hasta que quieres que la compartan, o hasta que quieres recordar lo que aprendió el agente hace seis semanas sin pagar un viaje de ida y vuelta a un LLM solo para consultarlo.
hermes-memory-pgvector es un pequeño plugin de Postgres + pgvector que refleja las escrituras de memoria del agente en un almacén compartido, incrustado y consultable. Publicado en PyPI en v0.4.2.
Nuevo en v0.4.2 — instalación nativa con pip
hermes-agent descubre los proveedores de memoria buscando en directorios de plugins (plugins/memory/<name>/ incluido, $HERMES_HOME/plugins/<name>/ de usuario) — nunca mira en site-packages, así que pip install por sí solo dejaba el plugin correctamente instalado y completamente invisible. v0.4.2 cierra esa brecha: pip install pone el código en la máquina, y un único comando hermes-pgvector install genera el shim de descubrimiento que el framework realmente lee.
Nuevo en v0.4.1 — recuperación híbrida (vector + texto completo)
recall_memory y recall_conversation ahora fusionan la clasificación coseno 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 vectorial pura: coincidencias léxicas exactas que el coseno suaviza (códigos de error, nombres de host, flags, identificadores poco frecuentes) y filas solo de texto con una incrustación NULL — escritas mientras el endpoint de embeddings estaba caído — que el índice vectorial no puede ver en absoluto. La recuperación híbrida también sirve como recuperación de mejor esfuerzo para esas filas hasta la siguiente ejecución de backfill.
Lo que añadió v0.4.0
Esa versión mantuvo la regla de "sin LLM en la ruta crítica" y añadió cuatro capacidades en la capa de almacenamiento:
- Gobernanza de identidad. Las claves de sesión de mensajes directos se consolidan en un único contenedor seguro para la privacidad — sin proliferación de temas por contacto, sin PII — el tráfico de benchmark se pone en cuarentena, y una allow-list opcional dirige los nombres de tema con erratas a un valor predeterminado seguro en lugar de crear silenciosamente uno nuevo.
- 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. Pura procedencia de quién/cuándo — nunca un almacén de hechos.
- Relleno de embeddings. Las filas escritas solo en texto durante una caída del endpoint de embeddings ya no quedan varadas: un único comando idempotente las vuelve a incrustar para que vuelvan a ser consultables.
- TTL de conversaciones y controles de coste. Una depuración ejecutada por el operador recorta los turnos antiguos del chat (las memorias duraderas nunca se tocan), y una política de embeddings ajusta el coste de los embeddings al alza o a la baja.
Todo se entrega detrás de una CLI de mantenimiento (hermes-pgvector) cuyos comandos destructivos tienen por defecto dry-run. La línea 0.4.x es una actualización directa desde v0.3.x — aplica las migraciones aditivas y los nuevos hooks se activan; sáltatelas y todo lo demás sigue ejecutándose sin cambios.
Lo que realmente hace
En una línea: "una capa de almacenamiento que le da al modelo de memoria integrado una base duradera, multiinquilino y con búsqueda semántica, sin 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 sustanciales (≥40 caracteres, con el texto rutinario filtrado). Los embeddings son de 768 dimensiones, calculados por un endpoint externo — Ollama, compatible con OpenAI, el que elijas. El agente nunca queda bloqueado por esto: las escrituras vuelven en microsegundos y el worker de embeddings se encarga del resto en una cola en segundo plano.
Temas por agente por defecto
Cada solicitud 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 predeterminado es el seguro.
Por qué independiente, no un fork
hermes-agent cerró por política su lista integrada de proveedores de memoria, así que esto vive como un escaneo separado del directorio /plugins en lugar de un fork upstream. Colócalo junto al agente, configura unas pocas claves de configuración y reinicia. La reversión es simétrica: desactiva el proveedor, opcionalmente elimina las tablas. No hay estado de larga duración que migrar, ni parches del kernel que mantener.
Lo que no es
No es un sustituto de Honcho. No es un grafo de conocimiento. No es un framework RAG. Está deliberadamente concebido como una capa fina que hace una cosa — convertir la herramienta de memoria integrada en un almacén compartido, duradero y consultable por vectores — y apartarse del camino. Sin derivador LLM, sin bucle dialéctico, sin opinión sobre cómo deberías fragmentar o reordenar. Solo matemáticas vectoriales.
Consíguelo
pip install hermes-memory-pgvector
hermes-pgvector install
Código fuente, migración y configuración en GitHub: