Comparativa de proveedores de memoria para agentes: política de captura y autoalojamiento

Actualizado en septiembre de 2026: se añadieron Mnemosyne y Memori, se expandieron las configuraciones de Honcho y Hindsight, y se incorporó una comparación de políticas de captura junto a la tabla original de infraestructura.

Los asistentes modernos aún olvidan 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 bibliotecas que almacenan hechos y resúmenes entre sesiones; a menudo se integran 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 incluyen como plugins de memoria externa 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 a través de integraciones comunitarias o oficiales. El Centro de memoria para sistemas de IA enumera este artículo junto a guías relacionadas con Cognee.

Para la memoria núcleo acotada específica de Hermes (MEMORY.md y USER.md), el comportamiento de congelación y los disparadores, consulte el Sistema de memoria de Hermes Agent. La conexión de proveedores es una capa dentro de una jerarquía de conocimiento para agentes más amplia: archivos de identidad, memoria residente, habilidades, wikis y bancos de memoria, cada uno con su propio disparador de inyección, lo cual se detalla en Contexto por niveles: una jerarquía de conocimiento para agentes de IA. Para obtener contexto sobre cómo los proveedores de memoria nativa de Hermes contribuyen a su creciente ventaja de adopción frente a OpenClaw — incluidos los estrellas de GitHub, las clasificaciones de tokens de OpenRouter y las comparaciones del tamaño del ecosistema —, vea OpenClaw vs Hermes Agent: Estrellas, Descargas y Uso 2026.

Existe otro eje que importa tanto como la calidad de la 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 duradera, 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 en ejecución prolongada, esas diferencias pueden importar más que unos pocos puntos adicionales en una métrica de recuperación; consulte Bucles de memoria autorreforzados en agentes de IA para entender por qué la captura automática puede convertir una conclusión generada en una premisa futura, y Mnemosyne para Hermes Agent: introducción a memoria local para una configuración de ejemplo conservadora.

Hermes Agent enumera diez plugins de proveedores de memoria externa para el conocimiento persistente y entre sesiones: los ocho originales más Mnemosyne y Memori. Solo un proveedor externo puede estar activo a la vez. Los archivos integrados MEMORY.md y USER.md se mantienen cargados junto a él; son aditivos, no sustitutivos.

Dependencias externas. Cada proveedor externo, excepto Holographic, requiere 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 en la privacidad, el coste y si su pila de memoria puede ejecutarse completamente autoservida. Hindsight, ByteRover y Mnemosyne agrupan o eliminan la mayor parte de las dependencias; Honcho, Mem0 y Supermemory requieren más componentes móviles. Donde un proveedor admita Ollama o cualquier punto final compatible con OpenAI, puede enrutarse 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 por línea de comandos que se detallan 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  # Comprobar qué está activo
hermes memory off     # Desactivar 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 la pregunta “¿puedo ejecutar esto?”. La tabla siguiente responde a una pregunta distinta que importa tanto para agentes en ejecución prolongada: qué se escribe sin que se lo pida y si un humano o una política pueden intervenir antes de que se convierta en algo duradero. Vea Bucles de memoria autorreforzados en agentes de IA para entender por qué este eje importa.

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

Desglose detallado

Honcho

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

Honcho funciona junto a la memoria existente: USER.md se mantiene igual y Honcho añade una capa adicional de contexto. Modela las conversaciones como pares intercambiando 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 el resumen de sesión, 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 la caché. La nube gestionada en api.honcho.dev se encarga de todo esto por usted. Para despliegues autoservidos (Docker, K3s o Fly.io), usted debe proporcionar sus propias credenciales. El hueco de LLM acepta cualquier punto final compatible con OpenAI, incluidos Ollama y vLLM, por lo que la inferencia puede mantenerse en las instalaciones. El hueco de embeddings tiene openai/text-embedding-3-small como predeterminado, pero admite proveedores configurables mediante LLM_EMBEDDING_API_KEY y LLM_EMBEDDING_BASE_URL — cualquier servidor de embeddings compatible con OpenAI funciona, incluidas opciones locales como vLLM con un modelo BGE.

Herramientas: honcho_profile (leer/actualizar tarjeta del 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).

Ajustes de configuración clave:

• contextCadence (predeterminado 1): Número mínimo de turnos entre actualizaciones de la capa base
• dialecticCadence (predeterminado 2): Número mínimo de turnos entre llamadas LLM a peer.chat() (se recomienda 1-5)
• dialecticDepth (predeterminado 1): Pasos de .chat() por invocación (limitado a 1-3)
• recallMode (predeterminado ‘hybrid’): hybrid (automático+herramientas), context (inyección solo), tools (solo herramientas)
• writeFrequency (predeterminado ‘async’): Momento de descarga: async, turn, session o un entero N
• observationMode (predeterminado ‘directional’): directional (todo activado) o unified (piscina compartida)

Modos de observación y automodelado. directional, el predeterminado para configuraciones nuevas, permite que tanto el par de usuario como el par de IA se observen a sí mismos y entre sí — un razonamiento dialéctico más rico, pero también significa que los mensajes autorizados por la IA contribuyen al modelo de Honcho de la propia IA. unified es la opción más conservadora: la IA modela al usuario a partir de mensajes del usuario sin construir el bucle de autoobservación correspondiente a partir de su propia salida. Quienes estén específicamente preocupados por conclusiones generadas que retroalimenten el razonamiento futuro — consulte Bucles de memoria autorreforzados en agentes de IA — deberían tratar unified como el predeterminado más seguro.

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

Mapeo de múltiples pares: 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.<perfil> para los demás).

Configuración:

hermes memory setup  # seleccionar "honcho"
# o legado: hermes honcho setup

Configuración: $HERMES_HOME/honcho.json (local del 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                   # Retroalimenta pares de IA para perfiles existentes

OpenViking

Mejor para: gestión de conocimiento autoservida con exploración estructurada.

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

Dependencias externas: OpenViking requiere un VLM (modelo de lenguaje visual) 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 admitidos incluyen OpenAI, Anthropic, DeepSeek, Gemini, Moonshot y vLLM (para despliegue local). Para embeddings, los proveedores admitidos incluyen OpenAI, Volcengine (Doubao), Jina, Voyage y — mediante 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, sin claves de API. No se requiere 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 de 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 autorizado por el asistente del estado autorizado por el usuario.

Configuración:

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

Mem0

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

Mem0 maneja la extracción de memoria en el servidor mediante una llamada a un LLM en cada operación add: lee la conversación, extrae hechos discretos, deduplica y los almacena. La API en la nube gestionada se encarga de toda la infraestructura. La biblioteca de código abierto y el servidor autoservido le dan control total.

Dependencias externas: Mem0 requiere un LLM para la extracción de memoria (predeterminado: OpenAI gpt-4.1-nano; se admiten 20 proveedores, incluidos Ollama, vLLM y LM Studio para modelos locales) y un modelo de embeddings para la recuperación (predeterminado: OpenAI text-embedding-3-small; se admiten 10 proveedores, incluidos Ollama y HuggingFace para modelos locales). El almacenamiento usa Qdrant en /tmp/qdrant en modo biblioteca, o PostgreSQL con pgvector en modo de servidor autoservido — ambos pueden ejecutarse localmente. Es posible una pila de Mem0 totalmente local y sin nube: Ollama para LLM, Ollama para embeddings y una instancia local de Qdrant, todo configurado mediante Memory.from_config.

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

Herramientas: mem0_profile, mem0_search, mem0_conclude.

Configuración:

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

Configuración: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

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

Hindsight construye un grafo de conocimiento de su memoria, extrayendo entidades y relaciones. Su herramienta única reflect realiza síntesis entre memorias — combinando múltiples memorias en nuevos insights. 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 recíproco por rango.

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 (predeterminado: OpenAI; proveedores admitidos incluyen Anthropic, Gemini, Groq, Ollama, LM Studio y cualquier punto final compatible con OpenAI). Los embeddings y el reranking son modelos locales dentro del proceso por defecto (SentenceTransformers; la imagen gorda de Docker/hindsight-all incluye 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 incluye mediante 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 en un servidor local compatible con OpenAI (Ollama o llama.cpp); retain y recall funcionan por completo, y reflect necesita un modelo con capacidad de llamada de herramientas.

Herramientas: hindsight_retain, hindsight_recall, hindsight_reflect (síntesis única entre memorias).

Configuración:

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

El modo en la nube aún acepta una clave de API en ~/.hermes/.env. La instalación autoservida usa Docker Compose contra PostgreSQL embebido o existente; vea la guía vinculada a continuación. Requiere un par de cliente/API de Hindsight actual (la documentación del plugin cita >= 0.4.22).

Configuración: $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 (predeterminado)

Interfaz local: hindsight-embed -p hermes ui start

Para la guía autoservida completa — Docker Compose, embeddings y reranking locales, control de ruta de escritura (auto_retain) y conexión local_external de Hermes —, vea Hindsight para Hermes Agent: memoria autoservida con LLMs locales. OpenCode, la CLI de Cursor y los otros marcos de codificación usan un paquete diferente, con un banco por repositorio: Memoria Hindsight para OpenCode, Cursor y otros agentes de codificación.

Para la higiene de memoria conservadora, configurar auto_retain=false mientras 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 a través de memorias, no como una observación independiente con el mismo peso probatorio que las memorias de las que se construyó.

Holographic

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

Holographic usa el álgebra HRR (Representación Reducida Holográfica) para la codificación de memoria, con puntuación de confianza para la fiabilidad de la memoria. Sin 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 por completo mediante álgebra HRR ejecutada dentro del proceso. Esto la hace única entre todos los proveedores de esta comparación: es la única que opera con cero llamadas externas. El precio a pagar es que la calidad de la recuperación es menor que la búsqueda semántica basada en embeddings, y no hay síntesis entre memorias como la reflect de Hindsight. Para usuarios para quienes la privacidad y la operación sin dependencias son innegociables, Holographic es la única opción que lo entrega incondicionalmente.

auto_extract predetermina 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, la hace una de las dos opciones más simples — junto a Mnemosyne — para lectores que deliberadamente no desean la captura automática.

Herramientas: 2 herramientas para operaciones de memoria mediante álgebra HRR.

Configuración:

hermes memory setup  # seleccionar "holographic"

RetainDB

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

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

Dependencias externas: Las llamadas a LLM, el pipeline de embeddings y el reranking de RetainDB se ejecutan todos en la infraestructura en la nube propia de RetainDB: usted solo debe proporcionar una RETAINDB_KEY. La extracción de memoria usa Claude Sonnet en el servidor. No hay opción de autoservicio ni modo local. Todos los datos de conversación se envían a los servidores de RetainDB para su procesamiento y almacenamiento. Si la soberanía de los 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 Hermes de RetainDB ha crecido más allá de una base de datos remota de memoria: ahora incluye síntesis dialéctica y un automodelado del agente, lo que la sitúa arquitectóticamente más cerca de Honcho que de un almacén vectorial simple. Eso es útil para la continuidad, pero también aumenta la importancia de separar los hechos de origen de la interpretación generada, la misma preocupación que aplica al modo directional de Honcho.

Configuración:

hermes memory setup  # seleccionar "retaindb"

Mnemosyne

Mejor para: memoria local primero 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 originales incluidos en Hermes: se empaqueta como un plugin de proveedor de Hermes separado, pero se integra a través de la misma interfaz MemoryProvider. Su principal ventaja es el control: el autoguardado de la conversación puede restringirse por rol o desactivarse por completo con sync_roles: [], el registro de resultados de herramientas está desactivado por defecto, las operaciones explícitas de recordar/recuperar/olvidar siguen disponibles sin importar el caso y las versiones más recientes incluyen supresión opcional de autoeco en torno a los límites de compresión de contexto.

Dependencias externas: Ninguna para la instalación core; la opción adicional 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 en etapas específicas del proveedor para memory.write_approval de Hermes, aunque la aprobación de proveedores externos aún no está estandarizada en Hermes, por lo que esta ruta debería 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 afianzado específicamente la validación de conflictos, el comportamiento de eliminación y el manejo de autoeco — vea Bucles de memoria autorreforzados 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 una guía de configuración conservadora, vea Mnemosyne para Hermes Agent: introducción a 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 centrada en la memoria estructurada consciente de herramientas. Captura los 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 el trabajo operativo, pero también crea una superficie de retroalimentación más grande, ya que las acciones, las decisiones del modelo y los resultados de las herramientas pueden convertirse todos en memoria estructurada duradera.

A diferencia de los proveedores que principalmente inyectan un bloque grande 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 en el 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 anteriores más que a instalaciones que requieren retención estricta de solo explícito.

Configuración:

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

ByteRover

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

ByteRover almacena la memoria como un árbol de contexto de 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 origen, razona sobre él y coloca el conocimiento extraído en el lugar correcto de la jerarquía. La recuperación es búsqueda de texto completo de 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 y búsqueda de memoria (se admiten 18 proveedores, incluidos Anthropic, OpenAI, Google, Ollama y cualquier punto final compatible con OpenAI mediante 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 de markdown plano. La sincronización en la nube es opcional y se usa solo para la colaboración del equipo; todo funciona completamente sin conexión por defecto. Para una configuración local totalmente autocontenida, conecte Ollama como proveedor (brv providers connect openai-compatible --base-url http://localhost:11434/v1) y ningún dato saldrá de su máquina.

Hermes expone auto_extract: false para desactivar los ganchos de curaduría automática, lo que sitúa a ByteRover cerca de Holographic y Mnemosyne en el grupo de proveedores donde la captura automática es opcional y no el predeterminado.

Herramientas: 3 herramientas para operaciones de memoria.

Configuración:

hermes memory setup  # seleccionar "byterover"

Supermemory

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

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

Dependencias externas: El servicio en la nube de Supermemory gestiona toda la inferencia de LLM y los embeddings en el servidor: usted solo debe proporcionar una clave de API de Supermemory. El autoservicio está disponible exclusivamente como adición al plan empresarial y se despliega en Cloudflare Workers; requiere que 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 ninguna ruta de autoservicio basada en Docker o local: la arquitectura está estrechamente acoplada al cómputo perimetral de Cloudflare Workers. Para usuarios que necesitan soberanía completa de datos 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 la conversación en búfer 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 aislados, pero también significa que el texto generado por el asistente 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  # seleccionar "supermemory"

Cómo elegir

En lugar de elegir un ganador global, adapte el proveedor a la tarea:

• Memoria local explícita más simple: Holographic — cero dependencias, auto_extract desactivado por defecto
• Memoria local con controles de ciclo de vida más ricos: Mnemosyne — SQLite, retención granular, supresión de autoeco
• Síntesis intensiva en grafos: Hindsight — grafo de conocimiento más reflect
• Modelado de pares o de usuario: Honcho — razonamiento dialéctico, modo unified para automodelado conservador
• Conocimiento estilo sistema de archivos: OpenViking — jerarquía viking:// por niveles
• Extracción automática sin complicaciones: 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, auditable, sin pipeline de embeddings: ByteRover — árbol de contexto de markdown plano
• Delimitación de contexto empresarial: Supermemory — ingesta del grafo de sesión, alojado en Cloudflare
• Actualizaciones de alta frecuencia, sin necesidad de autoservicio: RetainDB — compresión delta, automodelado dialéctico

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

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

Hermes documenta una interfaz de paquete/plugin para proveedores de memoria externos, incluidos 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. Hay algunos que vale la pena conocer sin añadir una sección completa por cada uno:

• Scope Recall trata SQLite como verdad duradera mientras mantiene la captura de conversación cruda acotada por separado, con un compañero opcional turn-closure-audit para revisión conservadora posterior al turno: separa la evidencia del registro crudo de la memoria semántica duradera 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. Excela en el conocimiento de proyecto o institucional estructurado, pero es más automático que un almacén de hechos explícito; consulte la introducción de autoservicio de Cognee y Elegir el LLM adecuado para Cognee en lugar de tratarlo como un proveedor de Hermes listo para usar.
• AgentMemory enfatiza eventos de origen, audibilidad y semántica de eliminación: relevante después de los problemas de registros derivados huérfanos discutidos para Mnemosyne arriba.
• XMemo emite predeterminados conservadores: la captura automática de la línea de tiempo puede mantenerse desactivada, y la eliminación puede restringirse. La adopción aún es lo suficientemente temprana como para no merecer todavía una sección completa.

Guías relacionadas

• Centro de memoria para sistemas de IA — alcance de este subclúster y enlaces a guías de Cognee
• Bucles de memoria autorreforzados en agentes de IA — por qué la política de captura y las compuertas de aprobación importan, en detalle
• Mnemosyne para Hermes Agent: introducción a memoria local — instalación completa y configuración conservadora para el proveedor Mnemosyne cubierto arriba
• Sistema de memoria de Hermes Agent — memoria central de dos archivos antes de plugins
• Configuración de producción de Hermes Agent — conexión de perfiles para proveedores en la práctica