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

Actualizado septiembre de 2026: se han añadido Mnemosyne y Memori, se ha ampliado 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 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 integrados como plugins para que el framework se mantenga ligero mientras la memoria escala.

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

Para la memoria central acotada específica de Hermes (MEMORY.md y USER.md), el comportamiento de congelación y los desencadenantes, 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 sobre OpenClaw, incluyendo estrellas de GitHub, clasificaciones de tokens de OpenRouter y comparaciones de tamaño de ecosistema, vea OpenClaw vs Hermes Agent: Estrellas, Descargas y Uso 2026.

Hay otro eje que importa tanto 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 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 de larga duración, estas diferencias pueden importan más que unos pocos puntos extra en una métrica de recuperación; consulte Bucles de Memoria Autorreforzantes 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: Inicio Rápido de Memoria Local para una configuración conservadora de ejemplo.

Hermes Agent enumera diez plugins de proveedores de memoria externa para conocimiento persistente 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 permanecen cargados junto a él, de forma aditiva, no como 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 búsqueda semántica, o una base de datos como PostgreSQL para almacenamiento. Estas dependencias tienen implicaciones directas para la privacidad, el coste y si su pila de memoria puede ejecutarse completamente autoalojada. Hindsight, ByteRover y Mnemosyne incluyen o eliminan la mayoría de las dependencias; Honcho, Mem0 y Supermemory requieren más piezas móviles. Donde un proveedor admite Ollama o cualquier endpoint compatible con OpenAI, puede enrutizar 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 CLI de 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, 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 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 una política intervenir antes de que se vuelva duradero? Vea Bucles de Memoria Autorreforzantes 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 bien configurado puede ser más seguro en la práctica que uno simple mal configurado.

Desglose detallado

Honcho

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

Honcho se ejecuta 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 resumición de sesiones, la derivación de la representación del usuario y el razonamiento dialéctico; un modelo de embeddings para búsqueda semántica entre observaciones; PostgreSQL con la extensión pgvector para almacenamiento vectorial; y Redis para caché. La nube gestionada en api.honcho.dev maneja todo esto por usted. Para despliegues autoalojados (Docker, K3s o Fly.io), usted suministra sus propias credenciales. El slot de LLM acepta cualquier endpoint compatible con OpenAI, incluyendo Ollama y vLLM, por lo que la inferencia puede permanecer en las instalaciones. El slot de embeddings usa openai/text-embedding-3-small por defecto pero admite 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/borrar conclusiones).

Perillas de configuración clave:

• contextCadence (por defecto 1): Turnos mínimos entre actualizaciones de la capa base
• dialecticCadence (por defecto 2): Turnos mínimos entre llamadas peer.chat() de LLM (se recomienda 1-5)
• dialecticDepth (por defecto 1): Pasos .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 descarga: async, turn, session o entero N
• observationMode (por defecto ‘directional’): directional (todo activado) o unified (pool compartido)

Modos de observación y autamodelado. directional, el defecto para configuraciones nuevas, permite que tanto los pares de usuario como los de IA se observen a sí mismos y entre sí — razonamiento dialéctico más rico, pero también significa que los mensajes escritos por la IA contribuyen al modelo de Honcho de la IA misma. unified es la opción más conservadora: la IA modela al usuario desde los mensajes del usuario sin construir el bucle de autoobservación correspondiente desde su propia salida. Cualquier persona específicamente preocupada por las conclusiones generadas que retroalimentan el razonamiento futuro — ver Bucles de Memoria Autorreforzantes 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 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.<perfil> para otros).

Configuración:

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

Configuración: $HERMES_HOME/honcho.json (local de 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 autoalojada con navegación estructurada.

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

Dependencias externas: OpenViking requiere un VLM (modelo de visión-lenguaje) para procesamiento semántico y extracción de memoria, y un modelo de embeddings para 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 — vía Ollama — cualquier modelo de embeddings 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 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 vs memoria de 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 escrito por el asistente del estado escrito 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  # seleccionar "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Mejor para: gestión de memoria manos-libres con extracción automática.

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

Dependencias externas: Mem0 requiere un LLM para la extracción de memoria (por defecto: OpenAI gpt-4.1-nano; 20 proveedores admitidos, 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 admitidos, 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. Una pila Mem0 totalmente local, sin nube, es posible: 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 material conversacional en memorias discretas y realiza lógica de desduplicación y actualización. Eso es conveniente, pero significa que el origen de la extracción importa — una conclusión generada por el asistente puede volverse estructuralmente 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=your-key" >> ~/.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 nuevas perspectivas. La recuperación ejecuta cuatro estrategias de recuperación en paralelo (semántica, palabra clave/BM25, recorrido de grafo, temporal), luego combina y reordena resultados usando fusión de rangos recíproca.

Dependencias externas: Hindsight requiere un LLM para la extracción de hechos y entidades en llamadas retain, y para síntesis en llamadas reflect (por defecto: OpenAI; proveedores admitidos incluyen Anthropic, Gemini, Groq, Ollama, LM Studio y cualquier endpoint compatible con OpenAI). El modelo de embeddings y el modelo de reordenamiento de cross-encoder están incluidos dentro de Hindsight mismo — se ejecutan localmente dentro del paquete hindsight-all y no requieren API externa. PostgreSQL también está incluido con la instalación de Python integrada vía un directorio de datos pg0 gestionado; alternativamente, puede apuntar Hindsight a una instancia externa de PostgreSQL. Para una configuración totalmente local, sin nube, establezca HINDSIGHT_API_LLM_PROVIDER=ollama y apúntela 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 única entre memorias).

Configuración:

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

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

Configuración: $HERMES_HOME/hindsight/config.json

• mode: cloud o local
• 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 una higiene de memoria conservadora, vale la considerar establecer auto_retain=false dejando auto_recall=true — la recuperación semántica sigue disponible, pero los turnos completados ya no entran automáticamente en la memoria a largo plazo. 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 fue construida.

Holographic

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

Holographic usa álgebra HRR (Holographic Reduced Representation) para el codificado 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, ni modelo de embeddings, ni base de datos, ni conexión de red. El codificado de memoria se realiza completamente a través del álgebra HRR ejecutándose en el proceso. Esto lo hace único entre todos los proveedores de esta comparación — es el único que opera con cero llamadas externas. El contrapunto es que la calidad de recuperación es menor que la búsqueda semántica basada en embeddings, y no hay síntesis entre memorias como reflect de Hindsight. Para usuarios donde la privacidad y la operación sin dependencias son innegociables, Holographic es la única opción que lo entrega incondicionalmente.

auto_extract está en false por defecto, 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, eso lo hace una de las dos opciones más simples — junto con Mnemosyne — para lectores que deliberadamente no quieren captura automática.

Herramientas: 2 herramientas para operaciones de memoria vía á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 + reordenamiento) para mostrar el contexto relevante. Es basado en la nube con un coste de $20/mes, con todo el procesamiento de memoria manejado en el servidor.

Dependencias externas: Las llamadas LLM, el pipeline de embeddings y el reordenamiento de RetainDB se ejecutan todos en la infraestructura propia en la nube de RetainDB — usted suministra solo una RETAINDB_KEY. La extracción de memoria usa Claude Sonnet en el servidor. No hay opción de autoalojamiento ni 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 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 (borrar 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 autamodelo de agente, lo que la coloca 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 fuente de la interpretación generada, la misma preocupación que se 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 integrados originales de Hermes — se distribuye como un plugin de proveedor de Hermes separado pero se integra a través de la misma interfaz MemoryProvider. Su ventaja principal es el control: el guardado automático de conversaciones 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 remember/recall/forget permanecen disponibles sin importar, y las versiones más recientes incluyen supresión opcional de autoeco 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, triplets temporales, hechos canónicos y consolidación.

Mnemosyne también implementa escrituras etapeadas específicas del proveedor para memory.write_approval de Hermes, aunque la aprobación de proveedores externos aún no está estandarizada en todo 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 recientes versiones de Mnemosyne han ajustado específicamente la validación de conflictos, el comportamiento de eliminación y el manejo de autoeco — ver Bucles de Memoria Autorreforzantes 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, vea 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 centrada 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 convertirse todos en memoria estructurada duradera.

A diferencia de los 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 contexto operativo cuando realmente lo necesita en lugar de en cada prompt. Eso reduce la polución del prompt pero no elimina el riesgo de retroalimentación en el lado de escritura por sí solo — 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 del trabajo anterior más que a instalaciones que requieren retención estrictamente explícita.

Configuración:

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

ByteRover

Mejor para: memoria local primero con almacenamiento auditable y legible 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 fuente, 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 MiniSearch con respaldo por niveles a búsqueda impulsada por LLM, sin necesidad de base de datos vectorial.

Dependencias externas: ByteRover requiere un LLM para curaduría y búsqueda de memoria (18 proveedores admitidos, incluyendo Anthropic, OpenAI, Google, Ollama y cualquier endpoint compatible con OpenAI vía el slot de proveedor openai-compatible). No requiere modelo de embeddings ni base de datos — el árbol de contexto es un directorio local de archivos markdown planos. La sincronización en la nube es opcional y se usa solo para colaboración de equipos; todo funciona completamente sin conexión por defecto. Para una configuración local totalmente autónoma, 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 desactivar hooks de curaduría automática, lo que coloca a ByteRover cerca de Holographic y Mnemosyne en el grupo de proveedores donde la captura automática es opt-in en lugar de predeterminada.

Herramientas: 3 herramientas para operaciones de memoria.

Configuración:

hermes memory setup  # seleccionar "byterover"

Supermemory

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

Supermemory proporciona fencing de contexto (aislando memoria por contexto) e ingesta de grafo de sesión (importando historiales de conversación completos). 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 en la 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 embeddings en el lado del servidor — usted suministra solo una clave API de Supermemory. El autoalojamiento está disponible exclusivamente como añadido de plan empresarial y se despliega en Cloudflare Workers; requiere que usted proporcione PostgreSQL con la extensión pgvector (para almacenamiento vectorial) y una clave API de OpenAI (obligatoria, con Anthropic y Gemini como additions opcionales). No hay ruta de autoalojamiento basada en Docker o local — la arquitectura está fuertemente acoplada al cómputo de borde de Cloudflare Workers. Para usuarios que necesitan plena soberanía 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 endpoint 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 escrituras de hechos aislados, 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  # seleccionar "supermemory"

Cómo elegir

En lugar de elegir un ganador global, adapte el proveedor al trabajo:

• 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 centrada en grafos: Hindsight — grafo de conocimiento más reflect
• Modelado de pares o usuarios: Honcho — razonamiento dialéctico, modo unified para autamodelado conservador
• Conocimiento estilo sistema de archivos: OpenViking — jerarquía viking:// por niveles
• Extracción automática manos-libres: Mem0 — extracción de hechos basada en LLM sin configuración
• Memoria operacional/consciente de herramientas: Memori — captura de turnos y trazas de ejecución
• Legible por humanos, auditable, sin pipeline de embeddings: ByteRover — árbol de contexto de markdown plano
• Fencing de contexto empresarial: Supermemory — ingesta de grafo de sesión, alojado en Cloudflare
• Actualizaciones de alta frecuencia, sin necesidad de autoalojamiento: RetainDB — compresión delta, autamodelo dialéctico

Para configuraciones de proveedores 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 Hermes de terceros

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 valen la pena conocerlos sin añadir una sección completa cada uno:

• Scope Recall trata SQLite como verdad duradera mientras mantiene la captura de conversación cruda limitada por separado, con un compañero opcional turn-closure-audit para revisión post-turno conservadora — separa la evidencia del journal 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 memoria de proyecto o institucional estructurada pero es más automático que un almacén de hechos explícitos; vea el inicio rápido de Autoalojamiento de Cognee y Elegir el LLM correcto para Cognee en lugar de tratarlo como un proveedor de Hermes plug-and-play.
• AgentMemory enfatiza eventos fuente, auditabilidad y semántica de eliminación — relevante después de los problemas de registros derivados huérfanos discutidos para Mnemosyne arriba.
• XMemo empuja valores predeterminados conservadores: la captura de línea de tiempo automática puede permanecer desactivada, y la eliminación puede restringirse. La adopción aún es lo suficientemente temprana como para no justificar una sección completa.

Guías relacionadas

• Hub de Memoria de Sistemas de IA — alcance de este subclúster y enlaces a guías de Cognee
• Bucles de Memoria Autorreforzantes en Agentes de IA — por qué la política de captura y las puertas 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 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