Une implémentation de code pour concevoir un moteur de compétences auto-évolutif avec OpenSpace : apprentissage de compétences, efficacité des tokens et intelligence collective

EverOS : runtime de mémoire open source pour agents, récupération hybride BM25/vectorielle et compétences auto-évolutives

EverMind a publié EverOS, un moteur de mémoire open source pour agents IA, sous licence Apache 2.0. Le projet s'attaque à un problème fondamental des grands modèles de langage : leur absence d'état persistant. Dès qu'une conversation se termine, le contexte disparaît. EverOS propose une approche différente : plutôt que d'enfermer la mémoire dans une base de données vectorielle opaque, il stocke chaque souvenir sous forme de fichiers Markdown ordinaires. Ces fichiers deviennent la source de vérité que les agents lisent, modifient et interrogent entre les sessions. La bibliothèque Python s'appuie sur une pile de stockage en trois couches : Markdown comme source canonique, SQLite pour la gestion des états et des files d'attente, et LanceDB pour les vecteurs et les index. La récupération est hybride : une seule requête LanceDB combine la recherche par mots-clés BM25, la recherche vectorielle dense et un filtrage scalaire, ce que l'équipe nomme mRAG. Les performances annoncées par EverMind sont de 93,05 % sur le benchmark LoCoMo, 83,00 % sur LongMemEval, et une latence p95 inférieure à 500 ms. Ce que change EverOS pour les développeurs d'agents, c'est avant tout l'inspectabilité et la portabilité. Les fichiers .md peuvent être ouverts dans n'importe quel éditeur, versionnés avec Git, ou consultés dans Obsidian. Il n'y a pas besoin de MongoDB, Elasticsearch, Milvus, Redis ou Kafka, ce qui réduit considérablement le coût opérationnel pour les développeurs indépendants et les petites équipes. L'architecture distingue deux pistes mémoire : côté utilisateur, des Profils, Épisodes, Faits et Prévisions ; côté agent, des Cas et des Compétences. Cette séparation est rare dans les bibliothèques concurrentes qui se concentrent généralement sur l'historique de chat. La mémoire procédurale est la fonctionnalité la plus distinctive : EverOS enregistre chaque tâche complétée comme un Cas, puis distille offline les patterns réussis en Compétences réutilisables partagées entre agents, sans curation manuelle. Le runtime est compatible avec le protocole OpenAI et se connecte à OpenRouter, vLLM, Ollama ou DeepInfra via un simple changement d'URL. EverOS s'inscrit dans une tendance plus large de recherche d'alternatives aux architectures mémoire complexes et coûteuses pour les systèmes agentiques. La version 1.1.0 a introduit des APIs de Knowledge pour des pages Markdown adossées à des sources taxonomiques, ainsi qu'un processus de Réflexion offline qui fusionne des clusters d'épisodes et affine les profils entre sessions. EverMind propose également EverOS Cloud pour les équipes qui préfèrent ne pas gérer l'infrastructure, avec parité complète du SDK et du format mémoire avec la version auto-hébergée. Les scores de benchmark sont prometteurs mais proviennent d'EverMind eux-mêmes, ce qui appelle une vérification sur des charges de travail réelles avant adoption en production.

Les agents IA auto-évolutifs avec OpenSpace : skills, MCP, lignage et réutilisation à faible coût

Un nouveau framework open source baptisé OpenSpace, développé par l'équipe de recherche HKUDS, propose de construire des agents IA capables de faire évoluer et de réutiliser leurs propres compétences au fil du temps. Le projet, hébergé sur GitHub, nécessite Python 3.12 ou supérieur et s'installe via un clonage du dépôt suivi d'une installation en mode éditable. Un tutoriel détaillé montre comment configurer l'environnement : définir les clés d'API Anthropic ou OpenAI, choisir un modèle comme Claude Sonnet 4.5, puis créer un espace de travail dédié et un dossier de compétences, ou "skills". Une fois la configuration terminée, l'agent peut exécuter des tâches concrètes, par exemple écrire une fonction Python qui analyse un fichier CSV d'heures travaillées et calcule une paie hebdomadaire incluant les heures supplémentaires majorées à 1,5 fois le taux normal, avec un test sur un jeu de données synthétique. Chaque compétence développée par l'agent est enregistrée dans une base SQLite locale, avec un système de versionnage et de traçabilité qui indique son origine : corrigée (FIX), dérivée d'une compétence existante (DERIVED) ou capturée directement lors d'une exécution (CAPTURED). Cette approche répond à un problème central des agents IA actuels : la réinvention permanente de solutions déjà trouvées, qui gonfle les coûts en tokens et en temps de calcul à chaque nouvelle tâche similaire. En stockant et en réutilisant les compétences déjà validées plutôt qu'en régénérant du code ou des raisonnements depuis zéro, OpenSpace promet de réduire les coûts d'exécution pour les tâches répétitives ou proches de celles déjà rencontrées, un enjeu important pour les équipes techniques qui déploient des agents IA en production sur de gros volumes de requêtes. Le fait que ces compétences soient formalisées sous forme de fichiers SKILL.md et connectables à des agents hôtes via le protocole MCP les rend également portables d'un projet à l'autre. Cette architecture transforme potentiellement un agent IA d'un outil sans mémoire, qui recommence chaque tâche depuis zéro, en un système capable d'accumuler une expertise réutilisable, réduisant latence et facture des appels aux modèles de langage. OpenSpace s'inscrit dans une tendance plus large de l'écosystème des agents IA, où le protocole MCP, popularisé par Anthropic, s'impose progressivement comme standard pour connecter les modèles de langage à des outils et des sources de données externes. Le projet intègre un serveur MCP en streaming HTTP, permettant à d'autres agents ou applications de puiser directement dans la bibliothèque de compétences accumulées, ainsi qu'un tableau de bord baptisé "openspace-dashboard" pour visualiser et analyser cette base évolutive. Cette capacité à conserver des compétences dans une base structurée, avec traçabilité complète de leur lignée, s'inscrit dans les efforts de la communauté open source pour rendre les agents IA plus autonomes et plus économiques, à un moment où les coûts d'inférence des grands modèles restent un frein majeur à leur déploiement à grande échelle. Le projet, publié sous l'organisation HKUDS sur GitHub, laisse entrevoir de futures itérations où plusieurs agents pourraient partager et affiner collectivement leurs capacités.

💬 Reste à voir si ça tient en prod, mais l'idée de base est juste : arrêter de payer en tokens pour réinventer la même fonction Python trois fois par semaine. Le vrai signal, c'est le versionnage FIX/DERIVED/CAPTURED, ça veut dire qu'on sort enfin du "l'agent oublie tout" pour aller vers un truc qui capitalise. Selon Le Fil IA, le prochain terrain de bataille des agents IA ne sera plus la puissance des modèles mais la mémoire des compétences qu'on arrive à leur faire garder.

Une implémentation de code illustrant l'orchestration multi-agents en essaim de ClawTeam avec les appels de fonctions OpenAI

ClawTeam, un framework open-source d'intelligence en essaim développé par HKUDS, propose une architecture multi-agents capable de décomposer des objectifs complexes en sous-tâches distribuées, exécutées de façon autonome par des agents spécialisés. Un tutoriel complet illustre son fonctionnement en s'appuyant sur les appels de fonctions de l'API OpenAI, rendant l'expérience accessible directement depuis Google Colab sans infrastructure locale. L'orchestration multi-agents représente une évolution majeure dans la conception des systèmes d'IA : plutôt qu'un seul modèle centralisé, plusieurs agents collaborent en parallèle, chacun prenant en charge une partie du problème. Cette approche améliore la scalabilité, réduit les goulots d'étranglement et permet une spécialisation fine des rôles, un paradigme de plus en plus adopté dans les systèmes d'IA production comme AutoGen, CrewAI ou LangGraph. L'architecture repose sur quatre composants fondamentaux : un agent leader qui décompose les objectifs, des agents workers spécialisés, un tableau de tâches partagé avec résolution automatique des dépendances, et un système de messagerie inter-agents pour la coordination en temps réel. Le code utilise threading pour la concurrence, dataclasses pour la modélisation des données, et la bibliothèque Rich pour le rendu visuel. Le modèle retenu est gpt-4o-mini, choisi pour son rapport coût/performance dans les exécutions en essaim. La classe TaskBoard implémente un verrou (threading.Lock) garantissant la cohérence des états entre agents concurrents. En rendant ce tutoriel opérationnel sans configuration locale (pas de tmux, pas de worktrees Git, pas de files de messages sur le système de fichiers), HKUDS abaisse considérablement la barrière d'entrée à l'orchestration multi-agents. Cette démocratisation pourrait accélérer l'adoption du paradigme "swarm intelligence" auprès des développeurs qui souhaitent expérimenter des architectures agentiques avancées sans contraintes d'infrastructure.

Comment construire une intelligence de code au niveau dépôt avec Repowise : analyse de graphe, détection de code mort et contexte IA

Repowise est un outil d'analyse de code qui propose une approche nouvelle pour comprendre la structure interne d'un dépôt logiciel à l'échelle du projet entier. Dans ce tutoriel pratique, les auteurs l'appliquent à itsdangerous, une bibliothèque Python de référence maintenue par Pallets, afin de démontrer comment configurer l'outil, connecter un modèle de langage (Claude Sonnet 4.5 d'Anthropic ou GPT-4o mini d'OpenAI selon les clés API disponibles), puis lancer le pipeline d'indexation qui génère un ensemble d'artefacts dans un répertoire .repowise/. L'outil peut également fonctionner en mode --index-only, sans LLM, pour les environnements sans accès à une API externe. Une fois initialisé, Repowise produit un graphe de dépendances entre fichiers et modules, qu'il analyse ensuite avec des algorithmes de théorie des graphes issus de la bibliothèque NetworkX, dont PageRank pour identifier les nœuds les plus influents et la détection de communautés pour regrouper les fichiers par cluster fonctionnel. Ce type d'intelligence repository-level répond à un problème concret que rencontrent les équipes de développement sur les bases de code volumineuses : savoir quels fichiers sont critiques, lesquels sont obsolètes, et comment les modifications en cascade se propagent. La détection de code mort, paramétrée ici avec un seuil de confiance à 0,7, permet d'identifier automatiquement les fichiers supprimables sans risque. La fonctionnalité de maintenance cascade_budget limite à 10 le nombre de fichiers touchés en cascade lors d'une modification, ce qui aide à estimer l'effort réel d'un refactoring avant de le commencer. La génération automatique d'un fichier CLAUDE.md, format de documentation structurée utilisé nativement par Claude Code d'Anthropic, facilite l'intégration du contexte architectural dans les workflows assistés par IA, en donnant au modèle une carte du projet plutôt qu'un tas de fichiers bruts. L'émergence d'outils comme Repowise s'inscrit dans une tendance plus large : donner aux LLMs une compréhension structurelle du code plutôt qu'une lecture séquentielle naïve. Là où les assistants classiques lisent fichier par fichier, une approche par graphes permet de raisonner sur les dépendances, la centralité et les clusters de responsabilité. Le protocole MCP (Model Context Protocol), sur lequel s'appuie Repowise pour exposer ses outils en CLI, est l'un des standards en cours d'adoption dans l'écosystème des agents de code. Le fait que l'outil génère directement un CLAUDE.md exploitable par Claude Code suggère une intégration croissante entre les outils d'analyse statique et les agents IA, une convergence qui pourrait redéfinir la façon dont les développeurs documentent et maintiennent les grandes bases de code à l'ère des assistants intelligents.

💬 Analyser un dépôt via un graphe de dépendances pour repérer le code mort et estimer l'impact d'un refactoring avant de le lancer, c'est exactement ce qu'il manque sur les grandes codebases. Ce qui m'intéresse le plus, c'est la génération auto du CLAUDE.md : si tu travailles avec Claude Code au quotidien, avoir une carte architecturale du projet plutôt qu'un tas de fichiers à parcourir un par un, ça change vraiment la façon dont le modèle raisonne. Reste à voir si ça tient sur 500k lignes, mais le concept est là.