Acontext : la mémoire d'agent rangée dans des fichiers Markdown
Agent Skills as a Memory Layer
En bref
- De quoi s’agit-il ?
- Acontext capture les apprentissages d'un run d'agent et les écrit dans des fichiers de compétences lisibles et versionnables. Le pari est clair : remplacer la recherche sémantique par une divulgation progressive pilotée par l'agent lui-même.
- À qui s’adresse-t-il ?
- Acontext convient aux équipes qui veulent une mémoire d'agent inspectable, versionnable et portable, et qui acceptent de concevoir elles-mêmes le schéma via SKILL.md. Il ne convient pas à celles qui cherchent une mémoire automatique sans travail de structuration, ni à celles dont l'infrastructure refuse un backend Docker plus une clé OpenAI.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 64 jours.
- En quel langage est-il écrit ?
- Principalement JavaScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 16 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : une mémoire d'agent que personne ne peut relire
La mémoire d'agent est devenue difficile à comprendre, à déboguer et à corriger, constate le README. Le mécanisme habituel, un index vectoriel alimenté par embeddings, produit un état opaque : on ne sait pas exactement ce qui a été retenu, ni pourquoi une requête remonte tel fragment plutôt que tel autre. Acontext prend le contre-pied en stockant la mémoire dans le format des compétences d'agent, c'est-à-dire des fichiers Markdown. Le README résume la position du projet par une formule courte : « Skill is Memory, Memory is Skill ». Le public visé est l'équipe qui construit un agent et veut qu'il réutilise ce qui a fonctionné lors des exécutions précédentes, sans introduire dans son contexte un bloc de données qu'elle ne peut ni lire ni éditer. La promesse porte sur la lisibilité et la réversibilité, pas sur la performance brute de récupération.
De la session à l'écriture : le chemin d'une compétence
Le pipeline de mémorisation comporte cinq étapes. Les messages de session, éventuellement accompagnés des appels d'outils et des artefacts, constituent l'entrée brute. Les tâches sont extraites du flux de messages, ou déduites d'un signalement explicite de résultat. La fin d'une tâche, réussie ou échouée, déclenche l'apprentissage. Une passe de distillation confie à un LLM le soin d'inférer ce qui a marché, ce qui a échoué et les préférences de l'utilisateur. Un Skill Agent décide ensuite de la destination, compétence existante ou nouvelle, et écrit en respectant le schéma défini dans SKILL.md. La dernière étape met à jour les fichiers. Le point à retenir est le suivant : c'est vous qui fixez la structure, le système se charge de l'extraction, du routage et de l'écriture. Le déclencheur est donc un événement de fin de tâche, pas un intervalle de temps. Un agent qui n'annonce jamais la fin ou l'échec d'une tâche ne produit aucun apprentissage, sauf si la détection automatique y supplée.
Le rappel se fait par outil, pas par similarité
Côté lecture, le flux tient en deux flèches : l'agent appelle list_skills ou get_skill, et le contenu apparaît dans son contexte. Le README ajoute get_skill_file pour récupérer un fichier précis. Il n'y a pas de recherche par similarité : la récupération repose sur l'usage d'outils et le raisonnement de l'agent, ce que le projet appelle la divulgation progressive. La conséquence pratique est double. D'abord, l'agent doit être capable d'appeler des outils, ce que le README rappelle explicitement à propos du LLM utilisé pour l'auto-hébergement. Ensuite, la qualité du rappel dépend de la capacité de l'agent à juger ce dont il a besoin. Un agent qui n'appelle jamais get_skill aura une mémoire parfaitement constituée et jamais consultée. La surface de débogage reste néanmoins simple : on peut ouvrir les fichiers et lire ce que l'agent aurait pu voir.
Installation : SDK, CLI et serveur local
Le SDK Python s'installe avec pip install acontext, et un SDK TypeScript est publié sur npm sous @acontext/acontext. L'initialisation se fait par AcontextClient avec une clé lue dans la variable d'environnement ACONTEXT_API_KEY, du type sk-ac. Pour l'auto-hébergement, le README donne une commande d'installation : curl -fsSL https://install.acontext.io | sh. Il faut ensuite Docker et une clé OpenAI, puis, dans un répertoire dédié, acontext server up. Cette commande crée ou réutilise un fichier .env et un fichier config.yaml, et crée un dossier db pour la persistance. Les points d'accès exposés sont l'API sur http://localhost:8029/api/v1 et le tableau de bord sur http://localhost:3000/. Par défaut, le modèle utilisé est gpt-4.1. Le projet publie aussi une voie d'installation assistée par agent, sous forme d'une instruction à lire depuis https://acontext.io/SKILL.md, pour Claude Code et pour OpenClaw.
Ce que le projet ne résout pas
Le schéma est votre responsabilité. Le README le dit sans détour : vous définissez la structure dans SKILL.md, le système fait le reste. Une équipe qui attend une organisation automatique des connaissances se heurtera à ce partage des rôles. Le coût par exécution mérite aussi d'être posé : la distillation est une passe LLM, et l'auto-hébergement suppose une clé OpenAI en plus du conteneur Docker. Sur une base de compétences volumineuse, l'absence de recherche sémantique devient un choix assumé, pas une optimisation : l'agent doit savoir quoi demander. Enfin, la documentation fournie reste mince sur plusieurs points. Le contenu exact attendu dans SKILL.md, la gestion des conflits entre deux écritures concurrentes sur la même compétence et la politique de purge des compétences obsolètes ne sont pas décrits dans le matériel disponible. Ces zones sont à vérifier dans les sources avant tout déploiement en production.
Face à une mémoire vectorielle classique
L'alternative la plus directe est un magasin vectoriel avec recherche top-k : on découpe les échanges en segments, on les projette en embeddings, et on réinjecte les k voisins les plus proches de la requête. La différence d'approche est nette. La recherche vectorielle sélectionne le contexte par similarité, sans que l'agent intervienne. Acontext supprime l'étape d'embedding et la remplace par un appel d'outil déclenché par le raisonnement de l'agent. Le compromis est réel : la recherche vectorielle demande moins de discipline de la part de l'agent, tandis que la divulgation progressive donne un contenu inspectable et un export en ZIP réutilisable ailleurs, sans ré-embedding ni migration. Le README mentionne les cadres LangGraph, Claude et AI SDK comme cibles, puisque les compétences sont des fichiers Markdown. Une équipe qui a déjà un index vectoriel en production n'a donc pas forcément intérêt à le remplacer : les deux mécanismes peuvent cohabiter, l'un traitant la masse documentaire, l'autre les apprentissages d'exécution.
Maintenance, licence et portabilité
Le dépôt n'est pas archivé et le dernier push est daté du 14 juillet 2026. Les versions publiées sont séparées par composant, ce qui indique des cycles distincts : ui/v0.1.14, sdk-ts/v0.1.21 et package-claude-code/v0.1.3 datent tous du 8 avril 2026. Concrètement, une mise à jour du SDK TypeScript n'entraîne pas celle de l'interface, et il faut suivre chaque composant séparément. Le projet est sous licence Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des changements. Ce paragraphe décrit la licence, il ne constitue pas un avis juridique : faites valider votre cas par votre service compétent. La portabilité, elle, est un argument structurel du projet : les compétences sont des fichiers Markdown, exportables en ZIP, utilisables avec Git, grep ou un montage dans un bac à sable. La dépendance restante se situe au niveau du service de distillation, qui consomme un LLM.
Conclusion éditoriale
Acontext convient aux équipes qui veulent une mémoire d'agent inspectable, versionnable et portable, et qui acceptent de concevoir elles-mêmes le schéma via SKILL.md. Il ne convient pas à celles qui cherchent une mémoire automatique sans travail de structuration, ni à celles dont l'infrastructure refuse un backend Docker plus une clé OpenAI. Avant d'adopter, vérifiez le contenu réel de SKILL.md, le fichier config.yaml généré par acontext server up, et la licence Apache-2.0 pour l'usage que vous prévoyez.
Notes de la communauté