Tencent publicó hy-memory==2.0.1, un SDK de Python para conservar y recuperar contexto de sesiones de chat, trabajo y programación. El código es público; su aplicación complementaria MemHub sigue siendo código fuente a la espera de artefactos públicos de lanzamiento. Los desarrolladores que evalúan una capa de memoria compartida ya pueden usar el SDK, pero deben proporcionar endpoints de modelos y embeddings y decidir qué registros de sesión puede leer cada agente.

El registro de cambios del proyecto fecha Hy Memory 2.0.1 el 16 de octubre de 2026. PyPI registra la subida del paquete el 15 de octubre, y el artículo sobre el modelo relacionado se presentó ese día. Son registros de publicación distintos, no una prueba de que el producto de escritorio se haya distribuido.

El gran cambio

  • Qué cambió: El SDK publicado ofrece vías separadas de memoria de chat, trabajo y programación mediante add() y search(), con filtros de origen y espacio de trabajo que puede utilizar la aplicación que lo integra.
  • Cómo funciona: El flujo de chat organiza conversaciones en capas de memoria. El de trabajo extrae un hecho de la sesión y, cuando corresponde, experiencias reutilizables de una traza de herramientas. El de programación añade una cadena de versiones de los cambios de código. Quien lo invoca proporciona el material de origen, las identidades, la configuración de almacenamiento y los servicios de modelos.
  • Por qué importa: El entorno que aloja un agente puede recuperar un registro compacto de conversaciones o decisiones de tareas anteriores en lugar de pasar todo el historial a cada sesión nueva. Que ese registro sea preciso, esté autorizado y resulte útil sigue dependiendo de lo que envíe ese entorno y de qué recuerdos permita reincorporar al prompt.

Elija el flujo de trabajo antes de integrar

El README del SDK describe tres valores de scene. chat acepta texto sin formato o matrices de mensajes y devuelve los canales de recuperación profile, normal y proactive. En el modo lite, almacena texto sin procesar para búsquedas por embeddings sin extracción mediante un LLM. pro añade extracción y reconciliación; ultra puede ejecutar una pasada adicional de evolución mediante evolve().

Para working, la entrada debe contener una traza de llamadas a herramientas. Una sesión produce un hecho sobre la tarea, el enfoque y el resultado, además de cero o más experiencias reutilizables que superen el umbral de valor del motor. coding utiliza las mismas dos capas y añade una cadena de evolución de versiones del código modificado. El README indica que la cadena puede usar diferencias locales de Git si se configura MEMORY_CODING_CHAIN_REPO_ROOT, o acciones de sustitución deterministas en la traza de herramientas. En lite, el SDK ignora la distinción entre los escenarios de trabajo y programación y almacena memoria sin procesar.

Estas estructuras de salida responden a preguntas distintas. Una preferencia de conversación corresponde a chat; una tarea completada con resultados de herramientas corresponde a working; un cambio de código cuya revisión anterior puede ser importante corresponde a coding. Es una distinción de enrutamiento documentada, no una prueba de rendimiento de BIG CHANGE.

Una vía documentada para usar el SDK

La siguiente secuencia se basa en el inicio rápido del repositorio y en la guía de configuración del SDK de MemHub. BIG CHANGE no ejecutó el paquete ni hizo llamadas a modelos.

Utilice Python 3.9 o posterior e instale la versión fijada del SDK:

Terminal
pip install hy-memory==2.0.1

ChromaDB y Kuzu forman parte de las dependencias básicas; Qdrant, FAISS, Neo4j, la caché MySQL y un reranker local tienen complementos separados. El entorno de desarrollo del código fuente de MemHub es distinto: requiere Node.js 24, pnpm 11, Python 3.12 y uv.

Configure un endpoint de LLM y otro de embeddings antes de inicializar el cliente. El README enumera MEMORY_LLM_API_KEY, MEMORY_LLM_BASE_URL, MEMORY_LLM_MODEL y las variables correspondientes MEMORY_EMBEDDER_*, además de MEMORY_EMBEDDING_DIMS; también documenta un valor predeterminado de OPENAI_API_KEY. Proporcione sus propias URL de endpoints, nombres de modelos, claves y dimensiones de embeddings compatibles. Son interfaces compatibles con OpenAI; no exigen utilizar el modelo independiente Hy-Memory-30B de Tencent. Mantenga las credenciales fuera de las trazas que se almacenan.

El siguiente ejemplo de chat utiliza las API documentadas MemoryConfig.from_env(), HyMemoryClient, add() y search(). La aplicación que realiza la llamada debe proporcionar authorized_messages como texto sin formato o mensajes en formato OpenAI, un identificador autorizado y estable user_id y la consulta query. Muestra el valor devuelto sin afirmar un resultado concreto:

Python
from hy_memory import HyMemoryClient, MemoryConfig

def write_and_recall(authorized_messages, user_id, query):
    config = MemoryConfig.from_env()  # Caller supplies LLM and embedding settings.
    client = HyMemoryClient(config=config, mode="pro")
    try:
        client.add(authorized_messages, user_id=user_id)
        return client.search(query, user_ids=[user_id], limit=10)
    finally:
        client.close()

Para trabajo o programación, pase una traza de mensajes que contenga una llamada a una herramienta o una entrada role="tool" y configure scene explícitamente. Configure workspace_id para aislar el material del proyecto; branch lo requiere. Configure source en las escrituras y include_sources o exclude_sources en las búsquedas cuando sean importantes los límites de la aplicación que realiza la llamada. La búsqueda de chat devuelve canales de memoria; la de trabajo o programación devuelve facts y experiences, con chain_block para programación. Inspeccione los registros devueltos antes de entregarlos al entorno que aloja el agente. list_memories, get, update y delete permiten gestionar registros individuales.

Una integración correcta tendría un registro guardado a partir de una entrada autorizada y un resultado de búsqueda acotado que responda a la pregunta de recuperación prevista. El README documenta los campos devueltos, pero no hemos observado una ejecución que permita afirmar que la extracción o la recuperación funcionaron. Si una búsqueda de trabajo o programación está vacía, compruebe primero que la escritura incluía resultados de herramientas y utilizaba pro o ultra; después compruebe los mismos valores de user_id, workspace_id, branch y los filtros de origen. Si cambia el modelo de embeddings o sus dimensiones, la guía de configuración de MemHub advierte que una colección existente no puede reutilizarse sin más con una anchura de vector diferente.

MemHub y el modelo son decisiones separadas

MemHub es el producto de escritorio y CLI propuesto sobre el SDK. Su README describe un entorno de ejecución local administrado, conectores de fuentes e integraciones con los entornos anfitriones. Su registro de cambios precisa mejor la disponibilidad: existe la versión de código fuente 1.0.0, compilación 4, pero la publicación en npm y los artefactos de lanzamiento de GitHub siguen pendientes. La guía de instalación indica Linux y macOS como plataformas de destino y señala que Windows no es compatible; su secuencia de instalación con npm depende de que se publiquen esos artefactos. Por ahora, considérela una vía de instalación prevista.

El almacenamiento local tampoco significa que cada paso del procesamiento sea local. El documento de privacidad de MemHub distingue el permiso para leer una fuente de conversación, el permiso para enviar material autorizado a un servicio de modelos externo elegido y el permiso para que el entorno que aloja un agente recupere memoria. Indica que las pruebas de origen sin procesar se guardan en el directorio de datos local y que, cuando se elige un servicio de modelos externo, este recibe el contenido autorizado necesario para la tarea seleccionada. Quien integre directamente el SDK debe implementar sus propios controles de consentimiento de fuentes, acceso a modelos y recuperación por el entorno anfitrión; la guía de integración de MemHub explica que su puente de producto añade esos pasos de gobernanza en lugar de limitarse a invocar el SDK.

Tencent también publicó Hy-Memory-30B-A3B, un modelo entrenado para escribir memoria, con un informe técnico presentado el 15 de octubre. El informe afirma que supera a los sistemas comparados en submuestras fijas de benchmarks. Es una evaluación del modelo comunicada por el proveedor, no una prueba independiente de que este SDK o MemHub mejoren las respuestas de un agente desplegado. El SDK acepta otros servicios de modelos compatibles.

El archivo de licencia actual del repositorio y los metadatos del proyecto indican Apache-2.0. El registro de cambios señala que se adoptó después de la subida de 2.0.1, cuyos metadatos inmutables de PyPI siguen indicando MIT. El paquete se descarga gratis, pero el servicio de modelos o embeddings elegido puede cobrar por las solicitudes; el lanzamiento no documenta un precio de funcionamiento universal. La decisión práctica es, por tanto, qué vía de memoria y qué límite de autorización integrar, midiendo los cargos del proveedor y la calidad de la recuperación en el entorno del propio desarrollador.

Fuentes y lecturas adicionales