Memory OS : une architecture mémoire open source à 6 couches pour agents Hermes

Tencent open-source TencentDB Agent Memory : un pipeline mémoire local à 4 niveaux pour agents IA

Tencent a publié en open source TencentDB Agent Memory, un système de mémoire pour agents IA conçu pour résoudre deux problèmes chroniques des agents de longue durée : l'explosion du contexte et l'échec de rappel. Distribué sous licence MIT, le projet repose sur une architecture à quatre niveaux et une mémoire symbolique court terme, sans nécessiter d'API externe grâce à un backend SQLite local via l'extension sqlite-vec. Le système s'intègre à OpenClaw comme plugin npm (@tencentdb-agent-memory/memory-tencentdb, Node.js 22.16+) et à l'agent Hermes via une image Docker avec passerelle TDAI. La mémoire long terme est organisée en pyramide sémantique à quatre couches : L0 Conversation (dialogues bruts), L1 Atom (faits atomiques), L2 Scenario (blocs de scènes), et L3 Persona (profil utilisateur en Markdown). Les couches hautes sont interrogées en premier ; on ne descend vers les faits bruts que si le détail est nécessaire. Les logs d'outils sont déchargés dans des fichiers externes sous refs/*.md, et les transitions d'état sont encodées en syntaxe Mermaid dans un canvas léger, permettant à l'agent de raisonner sur un graphe symbolique plutôt que sur des logs verbeux. Les gains de performance mesurés par Tencent sur des sessions continues sont significatifs. Sur WideSearch, le taux de réussite passe de 33 % à 50 % (amélioration relative de 51,52 %) et la consommation de tokens chute de 221,31 millions à 85,64 millions, soit une réduction de 61,38 %. Sur SWE-bench, testé en sessions de 50 tâches consécutives pour simuler l'accumulation de contexte, le taux de succès monte de 58,4 % à 64,2 % pendant que les tokens passent de 3 474 millions à 2 375 millions (-33 %). Sur le benchmark de mémoire personnalisée PersonaMem, la précision bondit de 48 % à 76 %. La récupération combine par défaut recherche BM25 et embeddings vectoriels via Reciprocal Rank Fusion, avec support du chinois (jieba) et de l'anglais. Une extraction de mémoire L1 se déclenche toutes les cinq interactions, un persona utilisateur est généré tous les 50 nouveaux souvenirs, et un timeout de cinq secondes évite de bloquer la conversation en cas d'échec de rappel. Ces résultats s'inscrivent dans une course plus large à la résolution du problème de mémoire pour les agents IA autonomes. La plupart des systèmes actuels fragmentent les données dans des stores vectoriels plats, rendant le rappel aveugle et peu structuré. L'approche de Tencent, qui sépare structure symbolique et texte brut tout en maintenant une hiérarchie sémantique, représente une alternative architecturale concrète. Le projet étant open source sous MIT et autosuffisant localement, il s'adresse directement aux développeurs qui construisent des agents de production sans vouloir dépendre d'une API mémoire tierce. Le modèle par défaut est DeepSeek-V3.2 de Tencent Cloud, mais tout modèle compatible OpenAI peut être substitué, ce qui élargit considérablement le périmètre d'adoption potentielle.

💬 La réduction de 61% des tokens sur WideSearch, ça ne s'invente pas. Tencent a fait ce que la plupart des frameworks négligent encore : séparer la structure symbolique du texte brut et organiser la mémoire en hiérarchie, plutôt que de tout jeter dans un store vectoriel plat et prier pour que le rappel fonctionne. Open source MIT, autosuffisant en local, compatible n'importe quel modèle OpenAI-compatible, les ingrédients sont là.

Créer une couche de mémoire à long terme universelle pour les agents IA avec Mem0 et OpenAI

Des chercheurs et développeurs s'appuient désormais sur Mem0, une bibliothèque open source compatible avec les modèles OpenAI et la base de données vectorielle ChromaDB, pour construire une couche de mémoire persistante destinée aux agents d'intelligence artificielle. Le principe repose sur une architecture en plusieurs modules : extraction automatique de souvenirs structurés à partir de conversations naturelles, stockage sémantique dans ChromaDB via les embeddings text-embedding-3-small, récupération contextuelle par recherche vectorielle, et intégration directe dans les réponses générées par GPT-4.1-nano. Concrètement, le système segmente les échanges conversationnels en faits durables associés à un identifiant utilisateur, comme les préférences techniques, les projets en cours ou les informations personnelles, puis les rend disponibles lors des interactions futures via une API CRUD complète permettant d'ajouter, modifier, supprimer ou interroger ces souvenirs. Cette approche résout un problème fondamental des agents IA actuels : leur amnésie entre les sessions. Sans mémoire persistante, chaque conversation repart de zéro, obligeant l'utilisateur à reformuler son contexte à chaque échange. Avec ce type d'architecture, un agent peut se souvenir qu'un utilisateur est ingénieur logiciel, qu'il travaille sur un pipeline RAG pour une fintech, et qu'il préfère VS Code en mode sombre, sans que ces informations aient été répétées. Pour les entreprises qui déploient des assistants IA internes, des copilotes de code ou des outils de support client, cela représente un gain de personnalisation et d'efficacité considérable. L'isolation multi-utilisateurs intégrée dans Mem0 garantit par ailleurs que les souvenirs d'un profil ne contaminent pas ceux d'un autre. La mémoire à long terme est l'un des chantiers prioritaires de l'IA générative en 2025-2026, aux côtés du raisonnement et de l'utilisation d'outils. Des acteurs comme OpenAI avec la mémoire de ChatGPT, ou des startups spécialisées telles que Mem0 (anciennement EmbedChain), se positionnent sur ce marché en pleine expansion. L'approche présentée ici est dite "production-ready" : elle exploite ChromaDB en local pour réduire les coûts et la latence, mais reste compatible avec des backends cloud. La tendance de fond est de faire évoluer les agents d'un mode sans état vers une continuité contextuelle, condition nécessaire pour des assistants véritablement utiles sur la durée. Les prochaines étapes probables incluent la gestion de la decay mémorielle (oublier les informations obsolètes) et l'intégration dans des frameworks multi-agents comme LangGraph ou AutoGen.

💬 Le problème de l'amnésie entre sessions, c'est le truc qui rend les agents inutilisables en vrai. Mem0 propose une architecture propre pour ça, avec ChromaDB en local et une isolation multi-utilisateurs qui tient la route, ce qui évite les bricolages maison qu'on voit partout. Bon, "production-ready" ça se vérifie, mais l'approche est solide.

Memori : une mémoire persistante pour agents LLM

Memori s'impose comme une couche d'infrastructure mémoire native pour les agents LLM, permettant aux applications d'intelligence artificielle de conserver et d'isoler le contexte utilisateur à travers plusieurs sessions et identités. Un tutoriel publié cette semaine détaille son implémentation concrète dans un environnement Google Colab, en connectant Memori à des clients OpenAI synchrones et asynchrones via le modèle gpt-4o-mini. La bibliothèque, disponible dès la version 3.3.0, s'installe en quelques lignes aux côtés du SDK OpenAI et de Nest AsyncIO. Le principe central repose sur l'enregistrement des clients LLM auprès de Memori, qui intercepte alors automatiquement chaque appel de complétion pour y injecter ou y stocker des informations contextuelles. L'attribution de la mémoire se fait par paire entity\id et process\id : deux paramètres qui définissent à quel utilisateur et à quel rôle d'agent appartient chaque fragment d'information. Ce mécanisme résout un problème fondamental des applications LLM actuelles : l'amnésie entre les sessions. Sans infrastructure mémoire, chaque conversation repart de zéro, forçant l'utilisateur à répéter son contexte à chaque interaction. Avec Memori, un assistant personnel se souvient qu'Alice est allergique aux cacahuètes, aime la cuisine italienne et pratique la randonnée, même si la session a été fermée puis rouverte. Plus crucial encore, le système garantit l'isolation des données entre utilisateurs : les informations de Bob, développeur Rust basé à Berlin et végétarien, ne fuient pas dans la mémoire d'Alice, et inversement. Cette séparation multi-tenant est essentielle pour tout service IA destiné à plusieurs clients ou utilisateurs distincts, que ce soit un chatbot de support client, un assistant professionnel ou une application grand public. Le tutoriel illustre également des cas d'usage plus avancés : réponses en streaming, appels asynchrones et simulation d'un agent de support client multi-tours, autant de scénarios qui testent la robustesse de la couche mémoire dans des conditions proches de la production. Memori propose un niveau gratuit avec limitation de débit, ainsi qu'un accès authentifié via clé API pour les usages intensifs. Cette approche s'inscrit dans une tendance plus large de l'écosystème IA : doter les agents de capacités de persistance et de personnalisation sans que les développeurs aient à construire eux-mêmes des systèmes de stockage et de récupération vectorielle. Des projets comme LangMem, Zep ou MemGPT explorent le même territoire, mais Memori mise sur une intégration transparente via simple enregistrement du client OpenAI, réduisant la friction d'adoption pour les équipes déjà familiarisées avec le SDK standard d'OpenAI.

Créer un agent autonome à mémoire hybride avec architecture modulaire et appel d'outils via OpenAI

Un tutoriel technique récemment publié décrit la construction pas à pas d'un agent autonome à mémoire hybride, en s'appuyant sur l'API OpenAI et quelques bibliothèques Python open source. Le système combine deux mécanismes de recherche en mémoire : la recherche sémantique par vecteurs, via le modèle d'embedding text-embedding-3-small d'OpenAI, et la recherche par mots-clés via l'algorithme BM25, implémenté par la bibliothèque rank_bm25. Pour le raisonnement et la génération de texte, l'agent s'appuie sur gpt-4o-mini. L'architecture repose sur des interfaces abstraites Python (MemoryBackend, LLMProvider, Tool) qui séparent strictement chaque couche du système. Les résultats des deux moteurs de recherche sont ensuite fusionnés via la méthode Reciprocal Rank Fusion (RRF), une technique qui combine les classements plutôt que les scores bruts afin de produire des résultats plus robustes et équilibrés. Ce type d'architecture représente un gain concret pour les développeurs qui souhaitent doter leurs agents d'une mémoire à long terme sans recourir à des bases de données vectorielles externes comme Pinecone ou Weaviate. En stockant les souvenirs sous forme de blocs de texte avec leurs embeddings directement en mémoire vive, et en reconstruisant l'index BM25 à chaque ajout, l'agent peut retrouver des informations pertinentes même lorsqu'une requête utilise des termes exacts absents du vocabulaire sémantique, un angle mort fréquent des systèmes purement vectoriels. Pour les équipes qui développent des assistants IA, des agents de recherche ou des chatbots d'entreprise, cette approche hybride offre un compromis entre précision sémantique et rappel lexical, deux qualités rarement réunies dans un seul système léger. La mémoire persistante des agents autonomes reste l'un des grands défis non résolus du développement IA. Les grands modèles comme GPT-4o souffrent d'une fenêtre de contexte limitée et oublient ce qui dépasse quelques dizaines de milliers de tokens. Les architectures RAG (Retrieval-Augmented Generation) ont émergé pour compenser cette limite, mais la plupart des implémentations courantes misent soit sur la recherche vectorielle, soit sur les mots-clés, rarement les deux. Ce tutoriel s'inscrit dans une tendance portée par des frameworks comme LangChain, LlamaIndex ou MemGPT, qui poussent vers des agents dotés d'une mémoire modulaire et interrogeable. La prochaine étape naturelle est l'intégration d'une base de données persistante (SQLite, PostgreSQL) pour survivre aux redémarrages, et d'un mécanisme de compression sélective pour gérer la croissance de la mémoire dans le temps.