Tencent libera Hy Memory 2.0 bajo Apache 2.0: memoria para chat, trabajo y código, y un SDK listo para producción

Tencent Hunyuan ha liberado Hy Memory 2.0, un marco de memoria de código abierto para agentes de IA que organiza la información en tres capas independientes (chat, trabajo y código) y cuyo modelo dedicado, Hy-Memory-30B-A3B, supera a Claude Opus 5 en las pruebas de memoria publicadas por la compañía.

El lanzamiento incluye el SDK de Python (hy-memory) los pesos del modelo en Hugging Face y MemHub, una aplicación de escritorio y línea de comandos que unifica el historial de conversaciones y las trazas de código de distintas herramientas de IA en una memoria local gestionada. Todo el código está disponible en GitHub bajo licencia Apache 2.0.

¿Qué es Hy Memory 2.0 y por qué se diferencia de otros marcos de memoria?

Hy Memory 2.0 es un motor de memoria cognitiva de doble sistema diseñado para agentes que necesitan recordar información a lo largo de tareas largas y conversaciones múltiples.

La arquitectura se apoya en dos modos de procesamiento: un Sistema 1 rápido, que almacena y recupera información sin coste de LLM, y un Sistema 2 más lento, que extrae hechos, resuelve conflictos e induce esquemas mentales de orden superior.

La diferencia frente a otros marcos como Mem0, MemOS o EverOS es que Hy Memory no trata toda la memoria igual. Distingue tres escenarios y aplica a cada uno una estructura distinta:

• Chat: memoria personal de largo plazo, organizada en una jerarquía de ocho capas (L0 a L7).
• Working: memoria para tareas de productividad, con dos capas: hechos de la sesión y experiencias reutilizables.
• Coding: la misma estructura de dos capas que Working, más una cadena de evolución de versiones que registra cada cambio de código con su diff real.

Tencent afirma que es el primer marco de la industria que propone memoria de trabajo y memoria de código como capas diferenciadas.

Las tres capas de memoria explicadas

Memoria de chat: de hechos dispersos a cronologías de eventos

La capa de chat ha evolucionado desde el almacenamiento de hechos aislados hacia la construcción de cronologías de eventos completas. El sistema organiza el contenido fragmentado a través del tiempo y de las conversaciones en elementos clave: tiempo, lugar y personas, centrados en eventos.

Cuando una consulta requiere respuestas basadas en múltiples pistas, Hy Memory primero fusiona la información duplicada, elimina las inconsistencias y entrega la memoria limpia al modelo. La jerarquía incluye desde la conversación cruda (L1) hasta hechos atómicos versionados (L2), resúmenes de sesión (L3), esquemas mentales (L6) e intenciones prospectivas con fecha de caducidad (L7).

Memoria de trabajo: hechos de sesión y experiencias reutilizables

La capa de trabajo registra dos tipos de información por cada sesión con herramientas:

• Hechos (WorkingFact): qué se hizo en la sesión, con qué enfoque y con qué resultado. Exactamente un hecho por sesión, sin umbral.
• Experiencias: enfoques que pueden reutilizarse la próxima vez que aparezca una tarea similar. De cero a N por sesión, y deben superar un umbral de valor para almacenarse.

Las dos capas están vinculadas entre sí: cada experiencia apunta a los hechos de los que deriva, y los hechos superados permanecen trazables mediante una cadena de progreso de tareas.

Memoria de código: la cadena de evolución de versiones

La capa de código reutiliza la misma estructura de dos capas que la de trabajo, pero añade una cadena de evolución de versiones que resuelve un problema específico del desarrollo de software.

La extracción de hechos evita deliberadamente pegar código, porque el presupuesto de contexto se destina a coordenadas más informativas (archivo, función, rama). Eso significa que una versión que luego se revirtió nunca aparece en un hecho. Tampoco suele estar en el árbol de trabajo ni en HEAD, por lo que no puede recuperarse después.

La cadena almacena el diff real de cada versión con cero llamadas a LLM, rellenando exactamente la información que un resumen inevitablemente descarta. Funciona como un decorador, no como un recuperador: la capa vectorial decide qué hechos se devuelven, y la cadena adjunta a cada hecho cada revisión del código que toca.

Rendimiento: los resultados que Tencent publica

Tencent ha comparado Hy Memory con Mem0, MemOS, EverOS, OpenViking, RepoMemory y Simple RAG en cuatro pruebas y tres escenarios. Los resultados que reporta son los siguientes:

• Memoria de trabajo: 55,31% de media en las tareas de planificación de viajes y compras combinadas de MemoryArena, 10,2 puntos porcentuales por encima del segundo mejor, EverOS.
• Memoria de código: 64,2% de precisión en respuesta a preguntas de código y 35,6% de resolución de tareas en CodeMemoryBench. En SWE-ContextBench alcanza el 28,3%, frente al 25,3% de MemOS y Mem0.
• Memoria de chat: 72,6% de precisión en LoCoMo, superior al 71,9% de EverOS, con una reducción de tokens por pregunta de 1.159 a 703, un 39,3% menos.

En la comparación de modelos, Hy-Memory-30B-A3B obtuvo una puntuación media macro del 55,49%, frente al 54,62% de Claude Opus 5, el 53,64% de DeepSeek V4.1 Flash y el 44,37% de Qwen3-30B-A3B. El modelo tiene aproximadamente 3.000 millones de parámetros activos y fue entrenado con aprendizaje por refuerzo atribuido para extracción de memoria y reconciliación de conflictos.

¿Cómo se instala y se usa?

Instalación

El SDK está disponible en PyPI. La instalación básica incluye ChromaDB y Kuzu:

pip install hy-memory==2.0.3

Hay extras para backends específicos:

pip install "hy-memory[qdrant]==2.0.3"
pip install "hy-memory[faiss]==2.0.3"
pip install "hy-memory[graph]==2.0.3"   # Neo4j
pip install "hy-memory[mysql]==2.0.3"
pip install "hy-memory[rerank]==2.0.3"
pip install "hy-memory[all]==2.0.3"

Configuración

Solo se necesita un endpoint de LLM y otro de embeddings compatibles con OpenAI:

export MEMORY_LLM_API_KEY="sk-your-key"
export MEMORY_LLM_BASE_URL="https://api.deepseek.com"
export MEMORY_LLM_MODEL="deepseek-chat"
export MEMORY_EMBEDDER_API_KEY="sk-your-key"
export MEMORY_EMBEDDER_BASE_URL="https://dashscope.aliyuncs.com/compatible-mode/v1"
export MEMORY_EMBEDDER_MODEL="text-embedding-v3"
export MEMORY_EMBEDDING_DIMS=1024

También se puede usar la configuración por defecto de OpenAI con una sola clave.

Ejemplo de memoria de chat

from hy_memory import HyMemoryClient

client = HyMemoryClient(mode="pro")

client.add("I love sci-fi movies, especially Interstellar", user_id="user_1")
client.add([
    {"role": "user", "content": "Recommend a movie"},
    {"role": "assistant", "content": "Try Interstellar — a sci-fi masterpiece by Nolan"},
], user_id="user_1")

results = client.search("What movies does the user like?", user_ids=["user_1"], limit=10)
for mem in results["memories"]["normal"]:
    print(f"  [{mem['score']:.2f}] {mem['content']}")

client.close()

Ejemplo de memoria de código

Las escrituras en modo trabajo o código deben incluir una traza de llamadas a herramientas (tool_calls o mensajes con role="tool") y solo tienen efecto en los modos pro o ultra. El modo lite ignora el escenario y almacena todo como memoria cruda.

messages = [
    {"role": "user", "content": "Fix the timeout in the search client."},
    {"role": "assistant", "content": "", "tool_calls": [{
        "id": "call_1", "type": "function",
        "function": {"name": "apply_patch", "arguments": '{"path":"src/search.py"}'},
    }]},
    {"role": "tool", "tool_call_id": "call_1", "name": "apply_patch",
     "content": "Patch applied successfully"},
]

client.add(
    messages,
    scene="coding",
    user_id="user_123",
    workspace_id="github.com/example/service",
    branch="fix/search-timeout",
)

result = client.search(
    "Which timeout implementation was finally kept?",
    scene="coding",
    user_ids=["user_123"],
    workspace_id="github.com/example/service",
    branch="fix/search-timeout",
    limit=5,
)

El resultado incluye tres bloques: facts (capa de hechos), experiences (capa de experiencias) y chain_block (solo en coding, con el contexto de evolución de versiones).

MemHub: la aplicación que unifica la memoria entre herramientas

MemHub es una aplicación de escritorio y línea de comandos que gestiona la memoria de forma local. Una vez que el usuario autoriza la asociación de aplicaciones, MemHub importa las sesiones históricas de cada herramienta y las almacena mediante el SDK de Hy Memory. Las nuevas sesiones se sincronizan e importan en tiempo real.

MemHub se integra con herramientas de IA mediante complementos de un solo clic. Actualmente es compatible con 10 herramientas, entre ellas WorkBuddy, Cursor, Codex, Pi, Qwen Code, Hermes, DeepSeek Harness y OpenCode.

El usuario puede iniciar tareas dentro de cualquier herramienta vinculada, y MemHub gestiona y utiliza la información relevante como contexto adicional.

Modos de funcionamiento y backends de almacenamiento

Hy Memory ofrece tres modos:

• lite: solo embeddings crudos, sin llamadas a LLM. Ignora el escenario y las capas. Ideal para RAG vectorial simple y ingesta rápida.
• pro: añade extracción y reconciliación con LLM. El grafo es opcional.
• ultra: añade inducción de esquemas del Sistema 2 y barrido entre dominios, activado mediante evolve(). El grafo está siempre activo.

Los backends de almacenamiento incluyen ChromaDB, Qdrant y FAISS para vectores; Kuzu y Neo4j para grafos en modo ultra; y SQLite local para metadatos de trabajo y código.

Disponibilidad

El SDK y MemHub están disponibles en GitHub. Los pesos de Hy-Memory-30B-A3B están publicados en Hugging Face. La licencia es Apache 2.0, y los componentes de terceros mantienen sus propias licencias.