Concevoir un runtime d'agents style OpenHarness : outils, mémoire, permissions, compétences et coordination multi-agents

Créer un agent IA style nanobot dans Google Colab : appel d'outils, mémoire de session, compétences et serveurs MCP

Un tutoriel publié récemment décrit comment construire de zéro un agent IA personnel dans Google Colab, en s'inspirant de l'architecture de Nanobot, un framework d'agents léger. Le projet reconstruit brique par brique les composants fondamentaux d'un agent moderne : abstraction du fournisseur LLM, enregistrement d'outils (tool calling), mémoire de session, hooks de cycle de vie, compétences modulaires (skills) et un serveur d'outils au format MCP (Model Context Protocol). L'intégralité du code tourne dans un notebook Colab, sans clé API obligatoire grâce à un fournisseur simulé (MockProvider) qui reproduit le comportement d'un vrai modèle de langage de façon déterministe, permettant d'observer la boucle agentique en fonctionnement réel sans dépense ni connexion réseau. L'intérêt pédagogique est considérable pour les développeurs qui veulent comprendre ce qui se passe réellement sous le capot des frameworks populaires comme LangChain ou LlamaIndex. Au lieu d'utiliser une boîte noire externe, ce tutoriel expose comment les messages, les appels d'outils, les résultats et les réponses du modèle s'articulent dans une boucle d'inférence concrète. Le fait de pouvoir s'y connecter à n'importe quel fournisseur compatible OpenAI (OpenRouter, DeepSeek, Together AI, vLLM, LM Studio, Ollama) via une couche d'abstraction unique le rend immédiatement opérationnel en production. Pour les équipes qui construisent des agents internes sans vouloir dépendre d'un SDK propriétaire, ce type d'architecture minimaliste représente une alternative solide, maintenable et compréhensible. Ce tutoriel s'inscrit dans une dynamique plus large autour de la standardisation des agents IA. Le protocole MCP (Model Context Protocol), popularisé par Anthropic fin 2024, s'est imposé comme référence pour exposer des outils à un agent de façon modulaire, et de nombreux projets cherchent aujourd'hui à l'implémenter sans dépendre des SDK officiels. Nanobot lui-même est conçu pour rester léger et portable, à l'opposé des frameworks lourds qui accumulent les dépendances. La tendance va clairement vers des agents plus petits, plus explicites, plus faciles à auditer : les développeurs indépendants et les petites équipes veulent pouvoir lire et comprendre chaque ligne de la boucle d'inférence plutôt que de faire confiance à des abstractions opaques. Ce genre de ressource pédagogique, qui reconstruit l'essentiel en quelques centaines de lignes de Python pur, répond directement à ce besoin croissant de maîtrise et de transparence dans les systèmes d'IA autonomes.

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.

Construire un runtime d'agents local-first sécurisé avec OpenClaw Gateway, skills et exécution contrôlée des outils

OpenClaw Gateway s'impose progressivement comme une solution de référence pour les développeurs souhaitant déployer des agents IA en environnement local, sans dépendance à une infrastructure cloud tierce. Le projet, distribué via npm sous le nom openclaw, s'installe en quelques commandes sur Node.js 22 et expose un serveur de contrôle sur le port 18789 en mode loopback, c'est-à-dire uniquement accessible depuis la machine locale. L'agent communique avec des modèles de langage via une couche de routage configurable, dans les exemples fournis, OpenAI GPT-4o-mini est utilisé comme modèle principal, et orchestre l'exécution d'outils et de compétences personnalisées (appelées « skills ») au travers d'un plan de contrôle centralisé. L'authentification aux APIs de modèles passe par des variables d'environnement, jamais par des secrets codés en dur, et le runtime dispose d'une interface de contrôle web optionnelle accessible via le chemin /openclaw. Ce type d'architecture répond à un besoin croissant dans l'industrie : faire fonctionner des agents autonomes dans des environnements contraints, isolés du réseau public, où la confidentialité des données et la maîtrise des appels aux modèles sont non négociables. Le binding en loopback empêche toute exposition accidentelle du gateway sur le réseau local ou internet, tandis que le mécanisme de timeout configurable sur l'outil exec (1 800 secondes par défaut) et la gestion propre des processus en arrière-plan permettent d'encadrer précisément ce que l'agent est autorisé à faire. Pour les équipes travaillant sur des workflows d'automatisation sensibles, traitement de documents confidentiels, pipelines DevOps internes, assistants métier, cette approche offre un cadre de sécurité que les solutions SaaS ne peuvent garantir par construction. La capacité à définir des skills structurées, découvrables et invocables de manière déterministe par l'agent constitue également un avantage notable pour la reproductibilité des comportements en production. OpenClaw s'inscrit dans une tendance plus large de «local-first AI», portée par des projets comme Ollama pour l'inférence locale ou LM Studio pour la gestion de modèles. Face aux préoccupations réglementaires croissantes autour du traitement des données personnelles, RGPD en Europe, diverses lois sectorielles aux États-Unis, et à la méfiance envers les dépendances cloud critiques, plusieurs startups et équipes d'ingénierie cherchent à rapatrier le cycle complet de raisonnement des agents sur leur propre infrastructure. OpenClaw se positionne sur ce segment en proposant une couche d'abstraction entre le code applicatif Python ou JavaScript et les runtimes de modèles, avec une configuration déclarative en JSON. La prochaine étape logique sera probablement l'intégration native de modèles open source via des backends comme Ollama, pour s'affranchir totalement des API propriétaires tout en conservant la rigueur du contrôle d'exécution.

💬 C'est le genre de projet qui arrive au bon moment, quand les DPO commencent à bloquer systématiquement les intégrations SaaS IA dans les grandes boîtes. Le binding loopback par défaut et la définition des skills en JSON déclaratif, c'est exactement ce qu'il faut pour convaincre une équipe sécu que ton agent ne va pas exfiltrer des données sensibles par accident. Reste à voir si l'écosystème grossit assez vite avant qu'un acteur plus connu ne sorte la même chose avec dix fois les ressources derrière.

Concevoir un système multi-agents CAMEL de production : planification, outils, cohérence et affinement critique

Un tutoriel publié récemment détaille comment concevoir un système multi-agents de niveau production à l'aide du framework CAMEL, une bibliothèque Python open source dédiée à l'orchestration d'agents LLM. Le pipeline décrit met en scène cinq agents spécialisés aux rôles clairement délimités : un planificateur, un chercheur, un rédacteur, un critique et un rééditeur. L'ensemble repose sur GPT-4o d'OpenAI (via l'API), la validation de schémas avec Pydantic 2.7, et l'affichage structuré via Rich 13.7. Concrètement, le système génère des synthèses techniques documentées de façon autonome, en combinant recherche web en temps réel, échantillonnage par auto-cohérence et raffinement itératif piloté par critique interne. Ce type d'architecture multi-agents représente une évolution significative par rapport aux approches LLM classiques en pipeline simple. En distribuant les responsabilités entre agents distincts, chacun doté de contraintes de sortie précises (schémas JSON validés par Pydantic), le système réduit les hallucinations et améliore la cohérence des résultats. L'ajout d'un agent critique qui évalue la production de l'agent rédacteur, puis déclenche un agent rééditeur si le score est insuffisant, introduit une boucle de contrôle qualité autonome : le système s'auto-corrige sans intervention humaine. Pour les équipes produit ou data qui cherchent à industrialiser des workflows de génération de contenu ou d'analyse, cette approche offre un cadre reproductible, modulaire et extensible. CAMEL (Communicative Agents for "Mind" Exploration of Large Language Model Society) est un framework open source initié en 2023, qui a gagné en maturité avec des versions stables permettant l'intégration native d'outils web, de modèles multi-plateformes et de mécanismes de validation structurée. Le tutoriel s'inscrit dans un mouvement plus large d'industrialisation des agents LLM, où des acteurs comme LangChain, AutoGen de Microsoft ou CrewAI cherchent à standardiser la façon dont on compose des agents spécialisés. L'enjeu central est de passer du prototype expérimental au système fiable en production, ce qui exige précisément les mécanismes décrits ici : contrôle de schéma, gestion des erreurs, logique de retry et traçabilité des sorties. Les prochaines évolutions de ces frameworks devraient intégrer davantage de mémoire persistante entre agents et des mécanismes de délégation dynamique des tâches, rapprochant ces systèmes des premières formes d'automatisation cognitive véritablement autonome.