LongMemory : mémoire persistante locale pour agents LLM

Le problème que la recherche vectorielle ne règle pas

Un pipeline RAG classique découpe un texte, calcule des embeddings et renvoie les vecteurs les plus proches. Le README de LongMemory résume cette approche en trois étapes et note qu'elle n'établit ni ce qui était vrai à un moment donné, ni si un fait en a remplacé un autre, ni quelle source fait autorité, ni qui a le droit de voir le résultat. C'est le point de départ du projet : traiter ces questions comme des données du système, pas comme des conventions laissées à l'appelant. Le public visé est donc précis. D'un côté, les développeurs qui construisent des agents sur Claude Desktop, GitHub Copilot, Codex ou Gemini CLI et qui veulent que l'agent se souvienne d'un projet d'une session à l'autre. De l'autre, les équipes qui ont besoin de justifier pourquoi un fait se trouve dans le contexte envoyé au modèle. Si votre besoin se limite à retrouver des passages similaires dans une documentation, le projet vise plus large que nécessaire.

Nodes immuables, arêtes exécutables et temps à deux axes

L'architecture décrite dans le README repose sur un substrat appelé hydrograph memory, composé de nodes immuables, d'arêtes typées, de mondes, d'entités, de facettes et de traces. Deux notions de temps coexistent : le temps d'enregistrement et le temps de validité. Un fait révisé n'est pas effacé, il est remplacé, ce qui permet au mode historical de répondre à une question sur l'état d'une information en janvier alors que la valeur courante a changé depuis. Le contenu, les vecteurs, les hachages et la provenance ne sont pas réécrits par le rappel ni par la décroissance. La gouvernance est également modélisée dans le système : portée projet, tenant, utilisateur, équipe, rôle, agent, tâche et framework. Les arêtes typées participent au rappel et à l'explication, ce qui distingue ce graphe d'un index de voisinage purement sémantique. Le cycle de vie est déterministe : décroissance, renforcement explicite, consolidation, compression, reconsolidation. Ces mécanismes sont documentés, mais leur comportement exact en production dépend de la configuration que vous choisissez, et le README ne détaille pas les valeurs par défaut.

Quatre modes de rappel aux règles différentes

Le rappel n'est pas une fonction unique. Le README montre quatre appels. Le mode strict applique des filtres temporels, de contradiction, de contrat, de confiance et d'ancrage. Le mode historical prend un paramètre valid_time, ici Date.UTC(2026, 0, 15), et restitue une vérité dépassée. Le mode associative suit des signaux sémantiques, lexicaux, d'entité, d'activation et de graphe, ce qui convient aux questions du type incidents liés à une migration de paiement. Le mode world_grounded exige une preuve externe actuelle, donc une source hors de la base locale. Ce découpage a une conséquence pratique : le même texte de requête peut donner des résultats différents selon le mode, et le choix du mode est un choix de politique, pas un réglage de performance. Le README ne donne pas de tableau comparant les latences ou les taux de réussite entre modes. Il mentionne des benchmarks auditables (LongMemEval, LoCoMo, BEAM, qualité de retrieval, comportement temporel, latence) sans publier de chiffres dans le texte fourni.

Installation et mise en service

En bibliothèque, l'installation se fait avec npm install longmemory. L'exemple du README crée une instance via createMemory(), ingère un texte avec un user_id, puis appelle recall() en mode strict et ferme avec close(). Aucun service ni base externe n'est requis pour un usage en mémoire. Pour persister, on passe un objet de configuration : store: 'sqlite', db_path: './longmemory.db', tenant_id et user_id. Rouvrir la même base restaure les nodes, mondes, entités, arêtes, historique temporel, ancrage et état de cycle de vie. En ligne de commande : npm install --global longmemory, puis longmemory init et longmemory recall "current project priorities" --mode associative. Pour lancer le service depuis les sources, le README indique git clone, corepack enable, pnpm install --frozen-lockfile, pnpm build, pnpm start, avec une écoute par défaut sur http://127.0.0.1:7331. En conteneur, l'image ghcr.io/caviraoss/longmemory:latest s'exécute avec -p 7331:7331, un volume longmemory-data:/data et la variable LONGMEMORY_API_KEY. Le profil ui de Docker Compose ajoute un tableau de bord sur le port 3000, et /health sert de sonde.

MCP : ce que le serveur accepte et ce qu'il refuse

L'intégration aux hôtes d'agents passe par MCP. Le README donne deux commandes : longmemory mcp --db .longmemory/project.db --project current pour un serveur stdio local, et LONGMEMORY_API_KEY=change-me longmemory serve --mcp-http pour exposer MCP en Streamable HTTP authentifié. Le projet annonce 13 outils gouvernés de haut niveau, plus des ressources lisibles et des prompts de workflow. Un détail mérite l'attention : les arguments d'un outil ne peuvent pas remplacer l'identité d'exécution liée au serveur. Autrement dit, un agent ne peut pas se déclarer sous un autre tenant ou un autre utilisateur en passant un paramètre. C'est une décision de conception défendable pour un déploiement multi-utilisateur, mais elle implique que le cloisonnement se joue au moment du lancement du serveur, pas à l'appel. Les intégrations citées incluent un plugin Claude Code, Codex et ChatGPT, une extension VS Code, n8n, et des clients MCP natifs de frameworks. Le README s'interrompt au milieu de cette liste, donc l'inventaire complet n'est pas vérifiable à partir du texte fourni.

Limites, coûts et cas où le projet est mal choisi

La version la plus récente listée est v1.3.0, publiée le 20 décembre 2025 et étiquetée Beta. Deux versions correctives l'ont précédée en décembre. Une API qui bouge à ce rythme impose de lire les notes de version avant chaque montée, en particulier si vous utilisez le mode world_grounded, qui dépend de sources externes et donc d'une configuration réseau. Le stockage SQLite local est un atout pour la confidentialité et un frein pour le partage : deux machines qui exécutent le même agent sur des fichiers .db distincts ne partagent rien, et le README ne décrit pas de mécanisme de synchronisation entre instances. Le mode strict, avec ses cinq filtres, peut renvoyer un résultat vide là où une recherche vectorielle aurait renvoyé quelque chose de vaguement pertinent. C'est voulu, mais cela se paie en taux de réponse. Enfin, la gouvernance par rôle et par équipe n'a d'intérêt que si vous avez réellement plusieurs consommateurs ; pour un script unique, c'est de la configuration sans contrepartie. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications. Ce paragraphe n'est pas un avis juridique.

Face à un index vectoriel ou à une base de graphes

L'alternative la plus directe est un magasin vectoriel adossé à un pipeline RAG, par exemple un index local comme LanceDB ou un service comme Qdrant, avec un découpage et un embedding gérés par votre code. La différence n'est pas la vitesse de recherche, c'est ce que le système conserve. Un index vectoriel stocke des vecteurs et des métadonnées ; il ne sait pas qu'un fait a remplacé un autre, il ne porte pas de temps de validité distinct du temps d'insertion, et il n'a pas de notion d'arête typée entre entités. Vous pouvez reconstruire tout cela au-dessus, en ajoutant des colonnes de validité et une table de relations, mais vous écrivez alors le moteur de mémoire vous-même. Une base de graphes comme Neo4j prend en charge les relations typées et les requêtes de parcours, mais pas la décroissance, la consolidation ni le rappel borné par un budget de tokens, qui sont ici des mécanismes du moteur. LongMemory se situe entre les deux et assume ce positionnement : le README écrit explicitement « Not just RAG. Not just a vector database. » Le coût de ce choix est un modèle de données plus lourd à comprendre avant le premier appel utile.

Maintenance et montée de version

Le dépôt n'est pas archivé et le dernier push date du 31 août 2026, ce qui indique une activité de développement continue à cette date. Le projet publie sur npm, sur le registre de conteneurs GitHub et sur la place de marché VS Code, donc trois canaux à suivre séparément lors d'une mise à jour. La version Beta en tête de liste suggère que les interfaces peuvent encore changer ; un déploiement qui épingle la version dans package.json et dans le tag de l'image Docker évite les surprises. Le README donne aussi une procédure de build depuis les sources avec pnpm install --frozen-lockfile, ce qui suppose un lockfile maintenu et un environnement Node avec Corepack activé. Sur le plan de la licence, Apache-2.0 inclut une concession de brevet explicite, ce qui est plus confortable qu'une licence MIT pour un composant d'infrastructure, mais impose de signaler les fichiers modifiés si vous redistribuez une version patchée. Là encore, il s'agit d'une description de la licence, pas d'un conseil juridique.

Conclusion éditoriale

LongMemory convient aux équipes qui font tourner des agents sur leur propre infrastructure et qui ont besoin de retrouver un fait daté, avec sa source et sa portée. Il ne convient pas si vous cherchez uniquement une recherche par similarité sur des documents : un index vectoriel classique suffit et coûte moins cher à exploiter. Avant d'adopter, vérifiez trois points dans le dépôt : le contenu de Why.md, l'état réel de l'API marquée Beta en v1.3.0, et la façon dont votre hôte d'agent (Claude Desktop, Copilot, Codex) est censé se connecter au serveur MCP sur le port 7331.

Sources officielles

1. CaviraOSS/LongMemory on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases