Proveedores de memoria para agentes comparados: Honcho, Mem0, Hindsight y cinco más

Los asistentes modernos aún olvidan todo cuando cierras la pestaña, a menos que algo persista más allá de la ventana de contexto. Los proveedores de memoria de agentes son servicios o bibliotecas que retienen hechos y resúmenes a través de las sesiones, a menudo integrados como plugins para que el framework permanezca ligero mientras la memoria escala.

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

Para información sobre la memoria central acotada específica de Hermes (MEMORY.md y USER.md), el comportamiento de congelación y los desencadenantes, consulta el Sistema de Memoria de Hermes Agent.

Hermes Agent enumera ocho plugins de proveedores de memoria externa para conocimiento persistente y entre sesiones. Solo un proveedor externo puede estar activo a la vez. Los archivos MEMORY.md y USER.md integrados permanecen cargados junto con é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 búsqueda semántica o una base de datos como PostgreSQL para el almacenamiento. Estas dependencias tienen implicaciones directas para la privacidad, el costo y si tu stack de memoria puede ejecutarse completamente autoalojado. Hindsight y ByteRover agrupan o eliminan la mayoría de las dependencias; Honcho, Mem0 y Supermemory requieren más componentes móviles. Donde un proveedor soporte Ollama o cualquier endpoint compatible con OpenAI, puedes 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

hermes memory setup   # Selector interactivo + configuración
hermes memory status  # Verificar 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

Comparación de Proveedores

Desglose Detallado

Honcho

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

Honcho funciona junto con la memoria existente — USER.md permanece tal cual, 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 sesiones, la derivación de la representación del usuario y el razonamiento dialéctico; un modelo de embedding para búsqueda semántica a través de las observaciones; PostgreSQL con la extensión pgvector para el almacenamiento vectorial; y Redis para caché. La nube gestionada en api.honcho.dev maneja todo esto por ti. Para despliegues autoalojados (Docker, K3s o Fly.io), tú proporcionas tus propias credenciales. El slot del LLM acepta cualquier endpoint compatible con OpenAI, incluyendo Ollama y vLLM, por lo que la inferencia puede permanecer en las instalaciones. El slot de embedding predeterminado es openai/text-embedding-3-small pero soporta proveedores configurables vía LLM_EMBEDDING_API_KEY y LLM_EMBEDDING_BASE_URL — cualquier servidor de embedding compatible con OpenAI funciona, incluidas 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).

Principales parámetros de configuración:

• contextCadence (predeterminado 1): Mínimo de turnos entre actualizaciones de la capa base
• dialecticCadence (predeterminado 2): Mínimo de turnos entre llamadas LLM de peer.chat() (se recomienda 1-5)
• dialecticDepth (predeterminado 1): Pasos .chat() por invocación (limitado a 1-3)
• recallMode (predeterminado ‘hybrid’): hybrid (auto+herramientas), context (solo inyección), tools (solo herramientas)
• writeFrequency (predeterminado ‘async’): Timing de vaciado: async, turn, session, o entero N
• observationMode (predeterminado ‘directional’): directional (todo activado) o unified (pool compartido)

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 caliente.

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 predeterminado, hermes.<perfil> para otros).

Configuración:

hermes memory setup  # seleccionar "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

Ideal para: gestión de conocimiento autoalojada con navegación estructurada.

OpenViking proporciona una jerarquía de sistema de archivos con carga escalonada. Es gratis, autoalojado, y te da control total sobre tu almacenamiento de memoria.

Dependencias externas: OpenViking requiere un VLM (modelo de visión-idioma) para procesamiento semántico y extracción de memoria, y un modelo de embedding para búsqueda vectorial — ambos son obligatorios. Los proveedores 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 embedding servido localmente. El asistente interactivo openviking-server init puede detectar la RAM disponible y recomendar modelos 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 (escalada), viking_browse, viking_remember, viking_add_resource.

Configuración:

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

Mem0

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

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

Dependencias externas: Mem0 requiere un LLM para la extracción de memoria (predeterminado: OpenAI gpt-4.1-nano; 20 proveedores soportados, incluyendo Ollama, vLLM y LM Studio para modelos locales) y un modelo de embedding para la recuperación (predeterminado: OpenAI text-embedding-3-small; 10 proveedores soportados, incluyendo Ollama y HuggingFace para modelos locales). El almacenamiento usa Qdrant en /tmp/qdrant en modo biblioteca, o PostgreSQL con pgvector en modo servidor autoalojado — ambos pueden ejecutarse localmente. Un stack 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.

Herramientas: mem0_profile, mem0_search, mem0_conclude.

Configuración:

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

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

Hindsight

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

Hindsight construye un grafo de conocimiento de tu memoria, extrayendo entidades y relaciones. Su herramienta única reflect realiza síntesis cruzada de memoria: combina múltiples memorias en nuevos insights. La recuperación ejecuta cuatro estrategias de recuperación en paralelo (semántica, palabras clave/BM25, traversión de grafo, temporal), luego fusiona y reordena los resultados usando fusión de rango recíproco.

Dependencias externas: Hindsight requiere un LLM para la extracción de hechos y entidades en llamadas retain, y para síntesis en llamadas reflect (predeterminado: OpenAI; proveedores soportados incluyen Anthropic, Gemini, Groq, Ollama, LM Studio y cualquier endpoint compatible con OpenAI). El modelo de embedding y el modelo de reranking cross-encoder están incluidos dentro del propio Hindsight — se ejecutan localmente dentro del paquete hindsight-all y no requieren API externa. PostgreSQL también está incluido con la instalación embebida de Python vía un directorio de datos pg0 gestionado; alternativamente, puedes apuntar Hindsight a una instancia externa de PostgreSQL. Para una configuración totalmente local y sin nube, establece HINDSIGHT_API_LLM_PROVIDER=ollama y apunta a un modelo Ollama local — retain y recall funcionan completamente; reflect requiere un modelo capaz de llamadas a herramientas (p. ej., qwen3:8b).

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

Configuración:

hermes memory setup  # seleccionar "hindsight"
echo "HINDSIGHT_API_KEY=tu-clave" >> ~/.hermes/.env

Instala automáticamente hindsight-client (nube) o hindsight-all (local). Requiere >= 0.4.22.

Config: $HERMES_HOME/hindsight/config.json

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

Interfaz local: hindsight-embed -p hermes ui start

Holographic

Ideal 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 tu propio hardware.

Dependencias externas: Ninguna. Holographic no requiere LLM, no requiere modelo de embedding, no requiere base de datos y no requiere conexión a red. La codificación de memoria se realiza completamente a través del álgebra HRR ejecutándose en el proceso. Esto lo hace único entre los ocho proveedores: 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 son innegociables, Holographic es la única opción que ofrece eso incondicionalmente.

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

Configuración:

hermes memory setup  # seleccionar "holographic"

RetainDB

Ideal 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 (vector + BM25 + reranking) para mostrar contexto relevante. Es basado en la nube con un costo de $20/mes, con todo el procesamiento de memoria manejado en el servidor.

Dependencias externas: Las llamadas LLM de RetainDB, el pipeline de embedding y el reranking se ejecutan toda la infraestructura de nube de RetainDB — tú solo proporcionas una RETAINDB_KEY. La extracción de memoria usa Claude Sonnet en el servidor. No hay opción de autoalojamiento y no hay modo local. Todos los datos de conversación se envían a los servidores de RetainDB para procesamiento y almacenamiento. Si la soberanía de datos o la operación offline importan para tu 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).

Configuración:

hermes memory setup  # seleccionar "retaindb"

ByteRover

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

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 embedding o una base de datos. Un LLM lee el contenido fuente, razona sobre él y coloca el conocimiento extraído en la ubicación correcta en la jerarquía. La recuperación es búsqueda de texto completo MiniSearch con respaldo escalonado a búsqueda impulsada por LLM, sin necesidad de base de datos vectorial.

Dependencias externas: ByteRover requiere un LLM para la curación de memoria y búsqueda (18 proveedores soportados, incluyendo Anthropic, OpenAI, Google, Ollama y cualquier endpoint compatible con OpenAI vía el slot de proveedor openai-compatible). No requiere modelo de embedding 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 colaboración en equipo; todo funciona completamente offline por defecto. Para una configuración local totalmente autónoma, conecta Ollama como proveedor (brv providers connect openai-compatible --base-url http://localhost:11434/v1) y ningún dato sale de tu máquina.

Herramientas: 3 herramientas para operaciones de memoria.

Configuración:

hermes memory setup  # seleccionar "byterover"

Supermemory

Ideal para: flujos de trabajo empresariales con cerramiento de contexto e ingesta de grafo de sesión.

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

Dependencias externas: El servicio en la nube de Supermemory maneja toda la inferencia LLM y el servidor de embedding en el servidor — tú solo proporcionas una clave API de Supermemory. El autoalojamiento está disponible exclusivamente como un complemento de plan empresarial y se despliega en Cloudflare Workers; requiere que proporciones PostgreSQL con la extensión pgvector (para almacenamiento vectorial) y una clave API de OpenAI (obligatoria, con Anthropic y Gemini como adiciones opcionales). No hay una ruta de autoalojamiento basada en Docker o local — la arquitectura está estrechamente acoplada al cómputo en el borde de Cloudflare Workers. Para usuarios que necesitan soberanía de datos completa sin un contrato empresarial, este proveedor no es la opción correcta.

Herramientas: 4 herramientas para operaciones de memoria.

Configuración:

hermes memory setup  # seleccionar "supermemory"

Cómo Elegir

• ¿Necesitas soporte multi-agente? Honcho
• ¿Quieres autoalojado y gratis? OpenViking o Holographic
• ¿Quieres configuración cero? Mem0
• ¿Quieres grafos de conocimiento? Hindsight
• ¿Quieres compresión delta? RetainDB
• ¿Quieres eficiencia de ancho de banda? ByteRover
• ¿Quieres características empresariales? Supermemory
• ¿Quieres privacidad (solo local)? Holographic
• ¿Quieres totalmente local sin servicios externos? Holographic (sin dependencias en absoluto) o Hindsight/Mem0/ByteRover con Ollama
• ¿Quieres memoria legible por humanos y auditable sin pipeline de embedding? ByteRover

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

Guías relacionadas

• Hub de Memoria de Sistemas de IA — alcance de este subclúster y enlaces a guías de Cognee
• Sistema de Memoria de Hermes Agent — memoria central de dos archivos antes de los plugins
• Configuración de producción de Hermes Agent — cableado de perfiles para proveedores en la práctica