Comparación de proveedores de memoria para agentes: política de captura y autoalojamiento

Actualizado en septiembre de 2026: se han añadido Mnemosyne y Memori, se ha expandido la configuración de Honcho y Hindsight, y se ha añadido una comparación de políticas de captura junto a la tabla de infraestructura original.

Los asistentes modernos siguen olvidando todo al cerrar la pestaña, a menos que algo persista más allá de la ventana de contexto. Los proveedores de memoria para agentes son servicios o librerías que conservan hechos y resúmenes entre sesiones, a menudo integrados como plugins para que el marco de trabajo se mantenga ligero mientras la memoria escala.

Esta guía compara los backends de memoria que se distribuyen como plugins externos de memoria para Hermes Agent: Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne y Memori, y explica cómo encajan en las pilas más amplias de sistemas de IA. Los mismos proveedores aparecen en OpenClaw y otras herramientas de agentes mediante integraciones comunitarias o oficiales. El Centro de Memoria para Sistemas de IA lista este artículo junto con Cognee y guías relacionadas.

Para la memoria de núcleo acotada específica de Hermes (MEMORY.md y USER.md), el comportamiento de congelación y los disparadores, consulte Sistema de Memoria de Hermes Agent. Para el contexto sobre cómo los proveedores de memoria nativos de Hermes contribuyen a su creciente ventaja de adopción frente a OpenClaw —incluyendo estrellas de GitHub, clasificaciones de tokens de OpenRouter y comparaciones del tamaño del ecosistema—, consulte OpenClaw vs Hermes Agent: Estrellas, Descargas y Uso 2026.

Existe otro eje tan importante como la calidad de recuperación: la gobernanza de la memoria. Los proveedores difieren drásticamente en lo que capturan automáticamente, si la salida generada por el asistente puede convertirse en memoria durable, si las reflexiones se almacenan como hechos, cómo se resuelven las contradicciones y si un humano puede revisar una escritura antes de que se convierta en contexto futuro. Para agentes de larga duración, esas diferencias pueden importar más que unos pocos puntos adicionales en una prueba de referencia de recuperación; consulte Bucles de Memoria Auto-Reforzantes en Agentes de IA para saber por qué la captura automática puede convertir una conclusión generada en una premisa futura, y Mnemosyne para Hermes Agent: Inicio Rápido de Memoria Local para una configuración conservadora trabajada.

Hermes Agent lista diez plugins de proveedores de memoria externos para conocimiento persistente y entre sesiones: los ocho originales más Mnemosyne y Memori. Solo puede haber un proveedor externo activo a la vez. MEMORY.md y USER.md integrados permanecen cargados junto a él: son aditivos, no un reemplazo.

Dependencias externas. Todos los proveedores externos, excepto Holographic, requieren al menos una llamada a un servicio externo: un LLM para la extracción de memoria, un modelo de embeddings para la búsqueda semántica, o una base de datos como PostgreSQL para el almacenamiento. Estas dependencias tienen implicaciones directas para la privacidad, el coste y si su pila de memoria puede funcionar totalmente auto-albergada. Hindsight, ByteRover y Mnemosyne empaquetan o eliminan la mayoría de las dependencias; Honcho, Mem0 y Supermemory requieren más piezas móviles. Si un proveedor soporta Ollama o cualquier punto final compatible con OpenAI, puede enrutar las llamadas de LLM y embeddings a un modelo local y mantener los datos fuera de servidores de terceros por completo.

Activación con Hermes Agent

Los pasos de línea de comandos a continuación reflejan las tablas de la hoja de referencia de la CLI de Hermes Agent.

hermes memory setup   # Selector interactivo + configuración
hermes memory status  # Compruebe lo que está activo
hermes memory off     # Desactive el proveedor externo

O manualmente en ~/.hermes/config.yaml:

memory:
  provider: openviking  # o honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory, mnemosyne, memori

Comparación de Proveedores

Política de captura y gobernanza

El almacenamiento y las dependencias responden a “¿puedo ejecutar esto?”. La tabla a continuación responde a una pregunta diferente que importa tanto para agentes de larga duración: ¿qué se escribe sin ser pedido y puede un humano o política intervenir antes de que se vuelva durable? Consulte Bucles de Memoria Auto-Reforzantes en Agentes de IA para saber por qué este eje importa.

Estas son categorías de riesgo arquitectónico, no puntuaciones de calidad; un proveedor sofisticado configurado cuidadosamente puede ser más seguro en la práctica que uno simple configurado mal.

Desglose Detallado

Honcho

Mejor para: sistemas multi-agente, contexto entre sesiones, alineación usuario-agente.

Honcho funciona junto a la memoria existente: USER.md permanece igual y Honcho añade una capa adicional de contexto. Modela las conversaciones como pares que intercambian mensajes: un par de usuario más un par de IA por perfil de Hermes, todos compartiendo un espacio de trabajo.

Dependencias externas: Honcho requiere un LLM para la resumen de sesiones, la derivación de la representación del usuario y el razonamiento dialéctico; un modelo de embeddings para la búsqueda semántica entre observaciones; PostgreSQL con la extensión pgvector para el almacenamiento vectorial; y Redis para el caché. La nube gestionada en api.honcho.dev maneja todo esto por usted. Para despliegues auto-albergados (Docker, K3s o Fly.io), usted proporciona sus propias credenciales. El hueco de LLM acepta cualquier punto final compatible con OpenAI, incluyendo Ollama y vLLM, por lo que la inferencia puede permanecer en las instalaciones. El hueco de embeddings por defecto es openai/text-embedding-3-small pero soporta proveedores configurables vía LLM_EMBEDDING_API_KEY y LLM_EMBEDDING_BASE_URL — cualquier servidor de embeddings compatible con OpenAI funciona, incluyendo opciones locales como vLLM con un modelo BGE.

Herramientas: honcho_profile (leer/actualizar tarjeta de par), honcho_search (búsqueda semántica), honcho_context (contexto de sesión — resumen, representación, tarjeta, mensajes), honcho_reasoning (sintetizado por LLM), honcho_conclude (crear/eliminar conclusiones).

Perillas de configuración clave:

• contextCadence (por defecto 1): Turnos mínimos entre la actualización de la capa base
• dialecticCadence (por defecto 2): Turnos mínimos entre las llamadas LLM de peer.chat() (se recomienda 1-5)
• dialecticDepth (por defecto 1): Pasos de .chat() por invocación (limitado a 1-3)
• recallMode (por defecto ‘hybrid’): hybrid (auto+herramientas), context (solo inyección), tools (solo herramientas)
• writeFrequency (por defecto ‘async’): Momento de la escritura: async, turn, session o un entero N
• observationMode (por defecto ‘directional’): directional (todo encendido) o unified (pool compartido)

Modos de observación y auto-modelado. directional, el defecto para configuraciones nuevas, permite que tanto el par de usuario como el de IA se observen a sí mismos y entre sí — razonamiento dialéctico más rico, pero también significa que los mensajes creados por la IA contribuyen al modelo de Honcho sobre la propia IA. unified es la opción más conservadora: la IA modela al usuario a partir de mensajes de usuario sin construir el bucle de auto-observación correspondiente a partir de su propia salida. Cualquiera específicamente preocupado por conclusiones generadas que retroalimenten el razonamiento futuro — consulte Bucles de Memoria Auto-Reforzantes en Agentes de IA — debería tratar unified como el defecto más seguro.

Arquitectura: Inyección de contexto de dos capas — capa base (resumen de sesión + representación + tarjeta de par) + suplemento dialéctico (razonamiento LLM). Selecciona automáticamente prompts de arranque en frío vs. cálidos.

Mapeo multi-par: El espacio de trabajo es un entorno compartido entre perfiles. El par de usuario (peerName) es una identidad humana global. El par de IA (aiPeer) es uno por perfil de Hermes (hermes por defecto, hermes.<profile> para otros).

Configuración:

hermes memory setup  # seleccione "honcho"
# o legacy: hermes honcho setup

Config: $HERMES_HOME/honcho.json (local al perfil) o ~/.honcho/config.json (global).

Gestión de perfiles:

hermes profile create coder --clone  # Crea hermes.coder con espacio de trabajo compartido
hermes honcho sync                   # Rellena pares de IA para perfiles existentes

OpenViking

Mejor para: gestión de conocimiento auto-albergada con navegación estructurada.

OpenViking proporciona una jerarquía de sistema de archivos con carga por niveles. Es gratis, auto-albergado, y le da control total sobre su almacenamiento de memoria.

Dependencias externas: OpenViking requiere un VLM (modelo de visión-lenguaje) para el procesamiento semántico y la extracción de memoria, y un modelo de embeddings para la búsqueda vectorial — ambos son obligatorios. Los proveedores de VLM soportados incluyen OpenAI, Anthropic, DeepSeek, Gemini, Moonshot y vLLM (para despliegue local). Para embeddings, los proveedores soportados incluyen OpenAI, Volcengine (Doubao), Jina, Voyage y — vía Ollama — cualquier modelo de embeddings servido localmente. El asistente interactivo openviking-server init puede detectar la RAM disponible y recomendar modelos de Ollama adecuados (p. ej. Qwen3-Embedding 8B para embeddings, Gemma 4 27B para VLM) y configurar todo automáticamente para una configuración totalmente local y sin claves de API. No se requiere ninguna base de datos externa; OpenViking almacena la memoria en el sistema de archivos.

Herramientas: viking_search, viking_read (por niveles), viking_browse, viking_remember, viking_add_resource.

Memoria del usuario frente a memoria del agente. El modelo de identidad de OpenViking puede separar el espacio de nombres de memoria del usuario de un par de asistente opcional. Esa separación importa para la higiene de la memoria: los hechos sobre el usuario y la experiencia generada por el agente no necesitan compartir la misma política de retención, lo cual es una propiedad útil si desea aislar el estado creado por el asistente del estado creado por el usuario.

Configuración:

pip install openviking
openviking-server init   # asistente interactivo (recomienda modelos Ollama para configuración local)
openviking-server
hermes memory setup  # seleccione "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Mejor para: gestión de memoria sin intervención con extracción automática.

Mem0 maneja la extracción de memoria lado servidor mediante una llamada LLM en cada operación add — lee la conversación, extrae hechos discretos, elimina duplicados y los almacena. La API de nube gestionada maneja toda la infraestructura. La librería de código abierto y el servidor auto-albergado le dan control total.

Dependencias externas: Mem0 requiere un LLM para la extracción de memoria (por defecto: OpenAI gpt-4.1-nano; 20 proveedores soportados, incluyendo Ollama, vLLM y LM Studio para modelos locales) y un modelo de embeddings para la recuperación (por defecto: OpenAI text-embedding-3-small; 10 proveedores soportados, incluyendo Ollama y HuggingFace para modelos locales). El almacenamiento usa Qdrant en /tmp/qdrant en modo librería, o PostgreSQL con pgvector en modo servidor auto-albergado — ambos pueden ejecutarse localmente. Una pila de Mem0 totalmente local y sin nube es alcanzable: Ollama para LLM, Ollama para embeddings y una instancia local de Qdrant, todo configurado vía Memory.from_config.

Mem0 es fundamentalmente un sistema de extracción: un LLM transforma el material conversacional en memorias discretas y realiza la lógica de eliminación de duplicados y actualización. Eso es conveniente, pero significa que la procedencia de la extracción importa — una conclusión de asistente generada puede volverse estructuralmente indistinguible de un hecho declarado por el usuario a menos que la ruta de captura lo filtre antes de que corra la extracción.

Herramientas: mem0_profile, mem0_search, mem0_conclude.

Configuración:

pip install mem0ai
hermes memory setup  # seleccione "mem0"
echo "MEM0_API_KEY=su-clave" >> ~/.hermes/.env

Config: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Mejor para: recuperación basada en grafos de conocimiento con relaciones de entidades.

Hindsight construye un grafo de conocimiento de su memoria, extrayendo entidades y relaciones. Su herramienta única reflect realiza la síntesis cruzada de memorias — combinando múltiples memorias en nuevos conocimientos. La recuperación ejecuta cuatro estrategias de recuperación en paralelo (semántica, palabra clave/BM25, recorrido de grafo, temporal), luego fusiona y reordena los resultados usando fusión de rangos recíprocos.

Dependencias externas: Hindsight requiere un LLM para la extracción de hechos y entidades en llamadas retain, y para la síntesis en llamadas reflect (por defecto: OpenAI; los proveedores soportados incluyen Anthropic, Gemini, Groq, Ollama, LM Studio y cualquier punto final compatible con OpenAI). Los embeddings y el re-rankeo por defecto son modelos locales en proceso (SentenceTransformers; la imagen Docker gorda/hindsight-all empaqueta BGE + MiniLM), y puede intercambiarlos por otros modelos locales o un punto final externo compatible con OpenAI / TEI — por ejemplo Qwen3-Embedding-0.6B y BGE-reranker-v2-m3 en CPU. PostgreSQL se integra vía un directorio de datos pg0 gestionado, o puede apuntar Hindsight a una instancia externa de PostgreSQL. Para una ruta generativa totalmente local, establezca HINDSIGHT_API_LLM_PROVIDER a un servidor local compatible con OpenAI (Ollama o llama.cpp); retain y recall funcionan totalmente, y reflect necesita un modelo con capacidad de llamada de herramientas.

Herramientas: hindsight_retain, hindsight_recall, hindsight_reflect (síntesis cruzada de memoria única).

Configuración:

hermes plugins install hindsight
hermes memory setup hindsight   # seleccione local_external para una API de Hindsight separada

El modo de nube aún acepta una clave de API en ~/.hermes/.env. La instalación auto-albergada usa Docker Compose contra PostgreSQL embebido o existente — consulte el paso a paso enlazado a continuación. Requiere un par cliente/API de Hindsight actual (la documentación del plugin cita >= 0.4.22).

Config: $HERMES_HOME/hindsight/config.json

• mode: cloud, local, o local_external
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (por defecto)

UI local: hindsight-embed -p hermes ui start

Para el paso a paso completo auto-albergado — Docker Compose, embeddings y re-rankeo local, control de la ruta de escritura (auto_retain) y conexión local_external de Hermes — consulte Hindsight para Hermes Agent: Memoria Auto-Albergada con LLMs Locales.

Para la higiene de memoria conservadora, establecer auto_retain=false mientras se deja auto_recall=true vale la pena considerarlo — la recuperación semántica sigue disponible, pero los turnos completados ya no entran en la memoria a largo plazo automáticamente. Trate la salida de reflect como conocimiento derivado sintetizado entre memorias, no como una observación independiente con el mismo peso probatorio que las memorias de las que fue construido.

Holographic

Mejor para: configuraciones centradas en la privacidad con almacenamiento solo local.

Holographic usa el álgebra HRR (Holographic Reduced Representation) para la codificación de memoria, con puntuación de confianza para la fiabilidad de la memoria. No hay dependencia de la nube — todo se ejecuta localmente en su propio hardware.

Dependencias externas: Ninguna. Holographic no requiere LLM, modelo de embeddings, base de datos ni conexión de red. La codificación de memoria se realiza completamente a través del álgebra HRR ejecutándose en proceso. Esto lo hace único entre todos los proveedores de esta comparación — es el único que opera con cero llamadas externas. El contrapeso es que la calidad de recuperación es menor que la búsqueda semántica basada en embeddings, y no hay síntesis cruzada de memoria como la reflect de Hindsight. Para usuarios donde la privacidad y la operación sin dependencias no son negociables, Holographic es la única opción que lo entrega incondicionalmente.

auto_extract por defecto es false, por lo que Holographic puede operar principalmente como una pequeña base de datos de hechos explícitos con puntuaciones de confianza, en lugar de un pipeline autónomo de transcripción a memoria. Combinado con sus cero dependencias, lo hace una de las dos opciones más simples — junto con Mnemosyne — para lectores que deliberadamente no desean captura automática.

Herramientas: 2 herramientas para operaciones de memoria vía álgebra HRR.

Configuración:

hermes memory setup  # seleccione "holographic"

RetainDB

Mejor para: actualizaciones de alta frecuencia con compresión delta.

RetainDB usa la compresión delta para almacenar eficientemente las actualizaciones de memoria y la recuperación híbrida (vectorial + BM25 + re-rankeo) para presentar el contexto relevante. Es basado en la nube con un coste de $20/mes, con todo el procesamiento de memoria manejado lado servidor.

Dependencias externas: Las llamadas de LLM de RetainDB, el pipeline de embeddings y el re-rankeo se ejecutan todos en la infraestructura de la nube propia de RetainDB — usted solo proporciona una RETAINDB_KEY. La extracción de memoria usa Claude Sonnet lado servidor. No hay opción de auto-albergaje y no hay modo local. Todos los datos de la conversación son enviados a los servidores de RetainDB para su procesamiento y almacenamiento. Si la soberanía de datos o la operación sin conexión importan para su caso de uso, este proveedor no es adecuado.

Herramientas: retaindb_profile (perfil de usuario), retaindb_search (búsqueda semántica), retaindb_context (contexto relevante para la tarea), retaindb_remember (almacenar con tipo + importancia), retaindb_forget (eliminar memorias).

La integración de RetainDB con Hermes ha crecido más allá de una base de datos de memoria remota — ahora incluye síntesis dialéctica y un auto-modelo de agente, lo que lo pone arquitectónicamente más cerca de Honcho que de un simple almacén vectorial. Eso es útil para la continuidad pero también aumenta la importancia de separar los hechos de la fuente de la interpretación generada, la misma preocupación que aplica al modo directional de Honcho.

Configuración:

hermes memory setup  # seleccione "retaindb"

Mnemosyne

Mejor para: memoria local-first con controles de retención granulares, almacenamiento SQLite inspeccionable, hechos estructurados, memoria temporal y consolidación configurable.

Mnemosyne no es uno de los proveedores de memoria empaquetados originalmente de Hermes — se distribuye como un plugin de proveedor separado de Hermes pero se integra a través de la misma interfaz MemoryProvider. Su principal ventaja es el control: la autoguardado de conversación puede restringirse por rol o deshabilitarse por completo con sync_roles: [], el registro de resultados de herramientas está apagado por defecto, las operaciones explícitas de recordar/recuperar/olvidar siguen disponibles sin importar, y las versiones nuevas incluyen supresión opcional de eco propio alrededor de los límites de compresión de contexto.

Dependencias externas: Ninguna para la instalación core; el extra embeddings añade búsqueda vectorial local. El almacenamiento es SQLite local con FTS5 y recuperación vectorial opcional. El sistema también mantiene memoria de trabajo, memoria episódica, hechos estructurados, triples temporales, hechos canónicos y consolidación.

Mnemosyne también implementa escrituras escalonadas específicas del proveedor para memory.write_approval de Hermes, aunque la aprobación de proveedor externo aún no estandarizada en Hermes, por lo que esta ruta debe probarse contra las versiones exactas que se desplieguen. La sofisticación adicional tiene un coste: la memoria derivada crea más estados de ciclo de vida para inspeccionar y limpiar. Las versiones recientes de Mnemosyne han ajustado específicamente la validación de conflictos, el comportamiento de eliminación y el manejo de eco propio — consulte Bucles de Memoria Auto-Reforzantes en Agentes de IA para la auditoría de producción que motivó el cambio de validación de conflictos.

Configuración:

python -m pip install "mnemosyne-memory[embeddings]" mnemosyne-hermes
mnemosyne-hermes install
hermes config set memory.provider mnemosyne

Para la instalación completa y un recorrido de configuración conservadora, consulte Mnemosyne para Hermes Agent: Inicio Rápido de Memoria Local.

Memori

Mejor para: agentes donde el historial de ejecución importa tanto como el historial de conversación.

Memori es una integración más nueva de Hermes enfocada en memoria estructurada consciente de herramientas. Captura turnos completados junto con el contexto de ejecución disponible — uso de herramientas, pasos de flujo de trabajo, decisiones, resultados y restricciones — lo cual es excelente para recordar trabajo operativo, pero también crea una mayor superficie de retroalimentación, ya que las acciones, decisiones del modelo y resultados de herramientas pueden todos volverse memoria estructurada durable.

A diferencia de proveedores que principalmente inyectan un gran bloque de memoria antes de cada turno, Memori expone herramientas explícitas de recuperación y resumen de recuperación, permitiendo al agente recuperar el contexto operativo cuando realmente lo necesita, en lugar de en cada prompt. Eso reduce la contaminación del prompt, pero no elimina por sí solo el riesgo de retroalimentación del lado de la escritura — los turnos completados y las trazas de ejecución aún pueden capturarse automáticamente en segundo plano, por lo que Memori se adapta a usuarios que quieren que un agente aprenda de trabajos previos más que a instalaciones que requieren retención estricta solo explícita.

Configuración:

pip install hermes-memori
hermes memory setup  # seleccione "memori"

ByteRover

Mejor para: memoria local-first con almacenamiento legible y auditable por humanos.

ByteRover almacena la memoria como un árbol de contexto markdown estructurado — una jerarquía de archivos de dominio, tema y subtema — en lugar de vectores de embeddings o una base de datos. Un LLM lee el contenido de la fuente, razona sobre ello y coloca el conocimiento extraído en la ubicación correcta de la jerarquía. La recuperación es búsqueda de texto completo MiniSearch con retroceso por niveles a búsqueda impulsada por LLM, sin necesidad de base de datos vectorial.

Dependencias externas: ByteRover requiere un LLM para la curaduría de memoria y la búsqueda (18 proveedores soportados, incluyendo Anthropic, OpenAI, Google, Ollama y cualquier punto final compatible con OpenAI vía el hueco de proveedor openai-compatible). No requiere modelo de embeddings ni base de datos — el árbol de contexto es un directorio local de archivos markdown simples. La sincronización de la nube es opcional y se usa solo para colaboración de equipo; todo funciona totalmente sin conexión por defecto. Para una configuración local totalmente auto-contenida, conecte Ollama como proveedor (brv providers connect openai-compatible --base-url http://localhost:11434/v1) y ningún dato sale de su máquina.

Hermes expone auto_extract: false para deshabilitar los ganchos de curaduría automática, lo que pone a ByteRover cerca de Holographic y Mnemosyne en el grupo de proveedores donde la captura automática es opcional en lugar de por defecto.

Herramientas: 3 herramientas para operaciones de memoria.

Configuración:

hermes memory setup  # seleccione "byterover"

Supermemory

Mejor para: flujos de trabajo empresariales con cerceo de contexto e ingesta de grafo de sesión.

Supermemory proporciona cerceo de contexto (aislamiento de memoria por contexto) e ingesta de grafo de sesión (importación de historiales de conversación completos). Extrae memorias automáticamente, construye perfiles de usuario y ejecuta recuperación híbrida que combina búsqueda semántica y de palabras clave. La API de nube gestionada es el objetivo de despliegue principal.

Dependencias externas: El servicio de nube de Supermemory maneja toda la inferencia de LLM y los embeddings lado servidor — usted solo proporciona una clave de API de Supermemory. El auto-albergaje está disponible exclusivamente como un complemento de plan empresarial y se despliega a Cloudflare Workers; requiere que usted proporcione PostgreSQL con la extensión pgvector (para almacenamiento vectorial) y una clave de API de OpenAI (obligatoria, con Anthropic y Gemini como adiciones opcionales). No hay una ruta de auto-albergaje basada en Docker o local — la arquitectura está fuertemente acoplada a la computación de borde de Cloudflare Workers. Para usuarios que necesitan soberanía de datos completa sin un contrato empresarial, este proveedor no es la elección correcta.

La integración actual de Hermes escribe una sesión completa a través del punto final de conversación de Supermemory como una unidad, almacenando en búfer la conversación e ingiriéndola al final de la sesión, reinicio o compresión. Eso produce un contexto de entidad y perfil más rico que las escrituras de hechos aisladas, pero también significa que el texto de asistente generado es parte del material presentado al pipeline de extracción de memoria, no solo declaraciones del usuario.

Herramientas: 4 herramientas para operaciones de memoria.

Configuración:

hermes memory setup  # seleccione "supermemory"

Cómo elegir

En lugar de elegir un ganador global, combine el proveedor con el trabajo:

• Memoria local explícita más simple: Holographic — cero dependencias, auto_extract apagado por defecto
• Memoria local con controles de ciclo de vida más ricos: Mnemosyne — SQLite, retención granular, supresión de eco propio
• Síntesis pesada en grafos: Hindsight — grafo de conocimiento más reflect
• Modelado de pares o usuarios: Honcho — razonamiento dialéctico, modo unified para auto-modelado conservador
• Conocimiento estilo sistema de archivos: OpenViking — jerarquía viking:// por niveles
• Extracción automática sin intervención: Mem0 — extracción de hechos basada en LLM sin configuración
• Memoria operativa/consciente de herramientas: Memori — captura de turno y traza de ejecución
• Legible por humanos, auditable, sin pipeline de embeddings: ByteRover — árbol de contexto markdown simple
• Cerceo de contexto empresarial: Supermemory — ingesta de grafo de sesión, alojado en Cloudflare
• Actualizaciones de alta frecuencia, no requiere auto-albergaje: RetainDB — compresión delta, auto-modelo dialéctico

Para configuraciones de proveedor perfil por perfil y patrones de flujo de trabajo del mundo real, consulte Configuración de producción de Hermes Agent.

El ecosistema más amplio de memoria de terceros de Hermes

Hermes documenta una interfaz de paquete/plugin para proveedores de memoria externos, incluyendo directorios instalados por el usuario y puntos de entrada de Python, por lo que el ecosistema ahora se extiende más allá de los proveedores con secciones completas arriba. Algunos vale la pena conocer sin añadir una sección completa cada uno:

• Scope Recall trata SQLite como la verdad durable mientras mantiene la captura de conversación cruda separada, con un compañero opcional turn-closure-audit para revisión conservadora post-turno — separa la evidencia de registro cruda de la memoria semántica durable en lugar de tratar cada turno capturado como conocimiento a largo plazo inmediatamente equivalente.
• Cognee es un pipeline de ingesta de grafo de conocimiento / ECL en lugar de un plugin de memoria conversacional de Hermes. Brilla en memoria de proyecto o institucional estructurada, pero es más automático que un almacén de hechos explícito; consulte el Inicio rápido de Auto-Albergaje de Cognee y Elegir el LLM correcto para Cognee en lugar de tratarlo como un proveedor de Hermes de inserción directa.
• AgentMemory enfatiza eventos de fuente, auditabilidad y semántica de eliminación — relevante después de los problemas de registros derivados huérfanos discutidos para Mnemosyne arriba.
• XMemo se distribuye con valores por defecto conservadores: la captura de línea de tiempo automática puede permanecer apagada, y la eliminación puede restringirse. La adopción aún es lo suficientemente temprana como para no justificar aún una sección completa.

Guías relacionadas

• Centro de Memoria para Sistemas de IA — alcance de este subcúmulo y enlaces a guías de Cognee
• Bucles de Memoria Auto-Reforzantes en Agentes de IA — por qué la política de captura y las compuertas de aprobación importan, a fondo
• Mnemosyne para Hermes Agent: Inicio Rápido de Memoria Local — instalación completa y configuración conservadora para el proveedor Mnemosyne cubierto arriba
• Sistema de Memoria de Hermes Agent — memoria de dos archivos de núcleo antes de los plugins
• Configuración de producción de Hermes Agent — conexión de perfiles para proveedores en la práctica