MemoryOS : une hiérarchie de mémoire pour agents, et ce qu'elle coûte à mettre en place

Le problème : un agent qui oublie tout entre deux sessions

Un agent conversationnel sans mémoire repart de zéro à chaque session. Le contexte fourni au modèle se limite à la fenêtre courante, et tout ce qui a été dit la semaine précédente disparaît. Les solutions habituelles consistent à empiler les tours de conversation dans le prompt, ce qui consomme des jetons et finit par saturer, ou à brancher une base vectorielle qui restitue des fragments de texte sans structure. MemoryOS prend un autre angle : il traite la mémoire comme une ressource à gérer, avec des niveaux de stockage distincts et des politiques de déplacement entre ces niveaux. La cible est l'agent personnalisé, celui qui doit se souvenir des préférences d'un utilisateur précis sur la durée. Le README résume l'intention en une phrase : fournir un système d'exploitation de la mémoire pour agents IA personnalisés, afin d'obtenir des interactions plus cohérentes et conscientes du contexte.

Quatre modules et trois horizons de stockage

L'architecture revendiquée s'inspire de la gestion mémoire des systèmes d'exploitation. Le README décrit une hiérarchie à quatre modules : Storage, Updating, Retrieval, Generation. Le papier associé (arXiv 2506.06326) précise que la mémoire personnelle est répartie sur trois horizons : court terme, moyen terme et long terme. Le principe est celui d'une mémoire courte qui reçoit les échanges récents, d'une mémoire moyenne qui consolide, et d'une mémoire longue qui conserve le profil utilisateur et les connaissances durables. Les modules Updating et Retrieval font le travail de tri : ce qui mérite de monter d'un niveau y monte, le reste s'efface. C'est une différence de fond avec une base vectorielle classique, où tous les fragments ont le même statut et où rien ne décide qu'un souvenir est devenu obsolète. Le point faible de cette description est son niveau d'abstraction : le README annonce les modules, mais ne détaille pas les seuils ni les règles exactes de promotion entre niveaux. Pour les connaître, il faut consulter le papier ou le code.

Ce que la documentation annonce comme résultats

Le README indique que sur le benchmark LoCoMo, MemoryOS obtient des gains moyens de 49,11 % en F1 et 46,18 % en BLEU-1. Ces chiffres proviennent du projet lui-même et portent sur un jeu de données de conversations longues. Ils ne disent rien de votre cas d'usage : un agent de support client et un compagnon de discussion n'ont pas la même définition d'un bon souvenir. Le README mentionne aussi une optimisation de parallélisation présentée comme un gain de latence d'un facteur cinq sur l'implémentation PyPI. Là encore, il s'agit d'une affirmation du projet, non d'une mesure indépendante. Le dépôt publie une section de reproduction des évaluations, ce qui permet en principe de refaire la mesure soi-même, mais je n'ai pas exécuté cette procédure et ne peux donc pas confirmer les valeurs annoncées.

Installation et configuration : ce que le dépôt expose

Le projet est écrit en Python et publié sur PyPI. Le README oriente vers trois points d'entrée : le paquet Python, le serveur MCP, et un déploiement Docker annoncé le 15 juillet 2025. Les sections du README portent des ancres explicites, par exemple memoryos_chromadb-getting-started pour la variante ChromaDB et docker-getting-started pour la variante conteneurisée, ce qui indique que la configuration diffère selon le mode choisi. Côté modèles, le README liste le support d'OpenAI, Deepseek et Qwen, ainsi que les embeddings BGE-M3 et Qwen3 sur PyPI et MCP. Un paramètre de configuration est nommé explicitement : similarity_threshold, ajouté le 8 juillet 2025, dont le README renvoie la description à la page de documentation hébergée sur bai-lab.github.io/MemoryOS/docs. C'est un point à noter : le paramètre qui contrôle probablement la sélection des souvenirs pertinents n'est pas documenté dans le README lui-même, il faut sortir du dépôt pour le comprendre. La version V1.2, datée du 18 juillet 2025, ajoute le support de ChromaDB et corrige un problème d'appels LLM figés dans cette intégration. Un détail à surveiller si vous partez sur ChromaDB : la correction est récente, et la note de version la présente comme un correctif, pas comme une refonte.

Le serveur MCP comme voie d'intégration

MemoryOS-MCP est la brique qui rend le projet utilisable depuis un client d'agent existant. Le README indique que le serveur MCP expose des outils modulaires, et que Claude Desktop figure parmi les clients pris en charge avec un champ Configuration associé dans le tableau de support. L'intérêt est pratique : au lieu d'intégrer une bibliothèque Python dans votre application, vous laissez un client compatible MCP appeler les outils de mémoire. Le README mentionne aussi une accélération de la parallélisation MCP au 14 juillet 2025, ce qui suggère que les appels d'outils étaient auparavant séquentiels et pouvaient devenir un goulot d'étranglement. Cette architecture a un coût : chaque opération de mémoire passe par un aller-retour d'outil, avec la latence que cela implique, là où un appel de fonction en processus serait immédiat. Pour un agent à faible trafic, c'est acceptable. Pour une boucle serrée, cela se paie.

Les limites que le dépôt ne masque pas

La première limite est celle du démarrage à froid. Une mémoire hiérarchique a besoin d'être alimentée. À la première exécution, le profil utilisateur et les connaissances à long terme sont vides, et l'agent se comporte comme n'importe quel agent sans mémoire jusqu'à ce que suffisamment d'échanges aient eu lieu. Le projet ne propose pas, d'après le README, d'amorçage à partir d'un historique existant. La deuxième limite tient à la dépendance à un LLM externe : les modules Updating et Generation s'appuient sur un modèle, et le correctif de la V1.2 concernait précisément des appels LLM figés dans l'intégration ChromaDB. Une panne ou une lenteur du fournisseur se répercute donc sur l'écriture en mémoire, pas seulement sur la réponse. La troisième limite est le périmètre : MemoryOS gère de la mémoire personnalisée pour un agent conversationnel. Si votre besoin est de retrouver un document précis dans une base technique, un index vectoriel simple avec un bon découpage suffit, et la machinerie de niveaux n'apporte rien. Le README positionne d'ailleurs le projet dans une famille de travaux de recherche, avec une survey et un autre projet, LightSearcher, ce qui indique une orientation académique plutôt qu'un outil d'infrastructure mature.

Face à une pile RAG classique

L'alternative la plus directe est une pile RAG standard : un découpage de documents, un modèle d'embeddings, une base vectorielle, et une recherche par similarité au moment de la requête. La différence d'approche est nette. Une pile RAG traite tous les fragments comme équivalents et se contente de les classer par proximité avec la question posée. MemoryOS ajoute une dimension temporelle et une politique de mise à jour : un souvenir peut être renforcé, consolidé ou abandonné selon son usage. En contrepartie, vous héritez d'un système qui prend des décisions à votre place, avec des seuils que vous devez régler. Si votre agent doit citer des sources vérifiables, la traçabilité d'un fragment RAG est plus simple à expliquer qu'un profil utilisateur reconstruit par un LLM. Si votre agent doit se souvenir qu'un utilisateur préfère les réponses courtes depuis trois mois, la pile RAG ne le fera pas sans que vous écriviez vous-même la logique.

Maintenance, versionnement et licence

Le rythme de publication est rapide : v1.0 le 12 juillet 2025, V1.1 le 13 juillet, V1.2 le 18 juillet, avec des entrées de journal presque quotidiennes en juillet 2025. Un tel rythme signifie que les interfaces peuvent bouger entre deux versions mineures, et que le code lu aujourd'hui ne sera pas identique dans un mois. Le dépôt n'est pas archivé et le dernier envoi de code date du 7 juillet 2026, ce qui indique une maintenance active. Prévoyez donc de figer une version plutôt que de suivre la branche principale. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de copyright et du fichier de licence, ainsi qu'une clause de brevets. Le README ne signale aucune restriction supplémentaire, mais il ne s'agit pas d'un avis juridique : faites relire le fichier LICENSE par qui de droit si votre contexte l'exige. Un point à vérifier avant tout déploiement : la politique de conservation des données de mémoire, car un profil utilisateur persistant est une donnée personnelle dans la plupart des juridictions.

Conclusion éditoriale

MemoryOS convient aux équipes qui construisent un agent conversationnel personnalisé sur plusieurs sessions et qui veulent une mémoire structurée en trois niveaux plutôt qu'un simple journal de conversation. Il ne convient pas à qui a besoin d'une mémoire déjà peuplée : le profil utilisateur et les connaissances s'accumulent à l'usage, pas à l'installation. Avant d'adopter, vérifiez trois choses dans la documentation : la valeur par défaut de similarity_threshold, le fournisseur d'embeddings retenu (OpenAI, BGE-M3 ou Qwen3 selon les notes de version) et le chemin de persistance des données dans votre configuration Docker, car c'est ce chemin qui déterminera ce que vous pourrez sauvegarder ou migrer plus tard.

Sources officielles

1. BAI-LAB/MemoryOS on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases