Tencent a publié hy-memory==2.0.1, un SDK Python destiné à conserver et retrouver le contexte des sessions de conversation, de travail et de programmation. Le code est public ; l'application associée MemHub en est encore au stade du code source et attend ses artefacts de distribution publics. Les développeurs qui évaluent une couche de mémoire partagée peuvent déjà utiliser le SDK, mais doivent fournir les points d'accès aux modèles et aux embeddings et décider quels enregistrements de session chaque agent peut lire.

Le journal des modifications du projet date Hy Memory 2.0.1 du 16 octobre 2026. PyPI enregistre le dépôt du paquet le 15 octobre, et l'article sur le modèle associé a été soumis ce jour-là. Ce sont des traces de publication distinctes, pas une preuve que le produit de bureau a été livré.

Le grand changement

  • Ce qui a changé : Le SDK publié expose des chemins de mémoire distincts pour la conversation, le travail et la programmation via add() et search(), avec des filtres de source et d'espace de travail utilisables par l'application qui l'intègre.
  • Comment cela fonctionne : Le flux de conversation organise les échanges en couches de mémoire. Le flux de travail extrait d'une trace d'outils un fait sur la session et, si cela se justifie, des expériences réutilisables. Le flux de programmation ajoute une chaîne de versions pour les modifications de code. L'appelant fournit le contenu source, les identités, la configuration de stockage et les services de modèles.
  • Pourquoi c'est important : L'hôte d'un agent peut retrouver un enregistrement compact des conversations ou décisions de travail antérieures au lieu de transmettre tout l'historique à chaque nouvelle session. L'exactitude, l'autorisation et l'utilité de cet enregistrement dépendent toujours de ce que l'hôte envoie et des souvenirs qu'il autorise à réintégrer dans le prompt.

Choisir le flux avant l'intégration

Le README du SDK décrit trois valeurs de scene. chat accepte du texte brut ou des tableaux de messages, puis renvoie les canaux de récupération profile, normal et proactive. En mode lite, le texte brut est stocké pour la recherche par embeddings, sans extraction par LLM. pro ajoute l'extraction et la réconciliation ; ultra peut effectuer une passe d'évolution supplémentaire via evolve().

Pour working, l'entrée doit contenir une trace d'appels d'outils. Une session produit un fait sur la tâche, l'approche et le résultat, ainsi que zéro ou plusieurs expériences réutilisables qui franchissent le seuil de valeur du moteur. coding utilise les deux mêmes couches et ajoute une chaîne d'évolution des versions du code modifié. Le README indique que cette chaîne peut utiliser les différences Git locales si MEMORY_CODING_CHAIN_REPO_ROOT est défini, ou des actions de remplacement déterministes dans la trace d'outils. En mode lite, le SDK ignore la distinction entre les scénarios de travail et de programmation et stocke la mémoire brute.

Ces structures de sortie répondent à des questions différentes. Une préférence exprimée en conversation relève de chat ; une tâche terminée avec des résultats d'outils relève de working ; une modification de code dont une révision antérieure pourrait compter relève de coding. C'est une distinction de routage documentée, pas un test de performance de BIG CHANGE.

Un parcours documenté avec le SDK

La séquence suivante s'appuie sur le guide de démarrage rapide du dépôt et le guide de configuration du SDK de MemHub. BIG CHANGE n'a pas exécuté le paquet ni effectué d'appels aux modèles.

Utilisez Python 3.9 ou une version plus récente et installez la version fixée du SDK :

Terminal
pip install hy-memory==2.0.1

ChromaDB et Kuzu font partie des dépendances principales ; Qdrant, FAISS, Neo4j, le cache MySQL et un reclasseur local ont des extensions distinctes. L'environnement de développement du code source de MemHub est différent : il exige Node.js 24, pnpm 11, Python 3.12 et uv.

Configurez un point d'accès LLM et un point d'accès aux embeddings avant d'initialiser le client. Le README énumère MEMORY_LLM_API_KEY, MEMORY_LLM_BASE_URL, MEMORY_LLM_MODEL, les variables correspondantes MEMORY_EMBEDDER_* et MEMORY_EMBEDDING_DIMS ; il documente aussi l'utilisation par défaut de OPENAI_API_KEY. Fournissez vos propres URL de points d'accès, noms de modèles, clés et dimensions d'embeddings compatibles. Ces interfaces sont compatibles avec OpenAI ; elles n'imposent pas le modèle distinct Hy-Memory-30B de Tencent. Gardez les identifiants d'accès hors des traces stockées.

L'exemple de conversation suivant utilise les API documentées MemoryConfig.from_env(), HyMemoryClient, add() et search(). L'application appelante doit fournir authorized_messages sous forme de texte brut ou de messages au format OpenAI, un identifiant user_id stable et autorisé, ainsi que query. L'exemple affiche la valeur renvoyée sans revendiquer de résultat particulier :

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()

Pour le travail ou la programmation, transmettez une trace de messages contenant un appel d'outil ou une entrée role="tool" et définissez scene explicitement. Définissez workspace_id pour isoler le contenu du projet ; branch l'exige. Définissez source lors des écritures et include_sources ou exclude_sources lors des recherches lorsque les limites de l'application appelante comptent. La recherche de conversation renvoie des canaux de mémoire ; celle de travail ou de programmation renvoie facts et experiences, avec chain_block pour la programmation. Inspectez les enregistrements renvoyés avant de les transmettre à l'hôte de l'agent. list_memories, get, update et delete permettent de gérer les enregistrements individuellement.

Une intégration réussie disposerait d'un enregistrement sauvegardé à partir d'une entrée autorisée et d'un résultat de recherche circonscrit répondant à la question de récupération visée. Le README documente les champs renvoyés, mais nous n'avons pas observé d'exécution permettant d'affirmer que l'extraction ou la récupération a réussi. Si une recherche de travail ou de programmation est vide, vérifiez d'abord que l'écriture incluait des résultats d'outils et utilisait pro ou ultra, puis vérifiez les mêmes valeurs de user_id, workspace_id, branch et les filtres de source. Si vous changez le modèle d'embeddings ou ses dimensions, le guide de configuration de MemHub avertit qu'une collection existante ne peut pas simplement être réutilisée avec une largeur de vecteur différente.

MemHub et le modèle sont des choix distincts

MemHub est le produit de bureau et CLI proposé sur la base du SDK. Son README décrit un environnement d'exécution local géré, des connecteurs de sources et des intégrations avec les hôtes. Son journal des modifications précise davantage la disponibilité : la version source 1.0.0, build 4, existe, mais la publication npm et les artefacts de distribution GitHub restent en attente. Le guide d'installation indique Linux et macOS comme plateformes visées et précise que Windows n'est pas pris en charge ; sa séquence d'installation npm dépend de la publication de ces artefacts. Considérez-la pour l'instant comme un parcours d'installation prévu.

Le stockage local ne signifie pas non plus que toutes les étapes de traitement restent locales. Le document de confidentialité de MemHub distingue l'autorisation de lire une source de conversation, celle d'envoyer du contenu autorisé à un service de modèles tiers choisi et celle, pour l'hôte d'un agent, de récupérer de la mémoire. Il indique que les éléments sources bruts sont stockés dans le répertoire de données local et que, lorsqu'un service externe de modèles est choisi, il reçoit le contenu autorisé nécessaire à la tâche sélectionnée. L'intégrateur qui utilise directement le SDK doit mettre en œuvre ses propres contrôles de consentement des sources, d'accès aux modèles et de récupération par l'hôte ; le guide d'intégration de MemHub explique que sa passerelle produit ajoute ces étapes de gouvernance au lieu de simplement appeler le SDK.

Tencent a aussi publié Hy-Memory-30B-A3B, un modèle entraîné à écrire des mémoires, avec un rapport technique soumis le 15 octobre. Le rapport revendique une avance sur les systèmes comparés dans des sous-échantillons fixes de benchmarks. Il s'agit d'une évaluation du modèle rapportée par le fournisseur, pas d'une preuve indépendante que ce SDK ou MemHub améliore les réponses d'un agent déployé. Le SDK accepte d'autres services de modèles compatibles.

Le fichier de licence actuel du dépôt et les métadonnées du projet indiquent Apache-2.0. Le journal des modifications précise que cette licence a été adoptée après le dépôt de la version 2.0.1, dont les métadonnées PyPI immuables indiquent toujours MIT. Le paquet se télécharge gratuitement, mais un service de modèles ou d'embeddings choisi peut facturer les requêtes ; la publication ne documente aucun tarif de fonctionnement universel. La décision pratique consiste donc à choisir le chemin de mémoire et la limite d'autorisation à intégrer, en mesurant les frais du fournisseur et la qualité de récupération dans l'environnement du développeur lui-même.

Sources et lectures complémentaires