Tencent Cloud publie en open source TencentDB Agent Memory v2.0, une mémoire d'équipe pour agents de codage IA

Tencent open-source TencentDB Agent Memory : un pipeline mémoire local à 4 niveaux pour agents IA

Tencent a publié en open source TencentDB Agent Memory, un système de mémoire pour agents IA conçu pour résoudre deux problèmes chroniques des agents de longue durée : l'explosion du contexte et l'échec de rappel. Distribué sous licence MIT, le projet repose sur une architecture à quatre niveaux et une mémoire symbolique court terme, sans nécessiter d'API externe grâce à un backend SQLite local via l'extension sqlite-vec. Le système s'intègre à OpenClaw comme plugin npm (@tencentdb-agent-memory/memory-tencentdb, Node.js 22.16+) et à l'agent Hermes via une image Docker avec passerelle TDAI. La mémoire long terme est organisée en pyramide sémantique à quatre couches : L0 Conversation (dialogues bruts), L1 Atom (faits atomiques), L2 Scenario (blocs de scènes), et L3 Persona (profil utilisateur en Markdown). Les couches hautes sont interrogées en premier ; on ne descend vers les faits bruts que si le détail est nécessaire. Les logs d'outils sont déchargés dans des fichiers externes sous refs/*.md, et les transitions d'état sont encodées en syntaxe Mermaid dans un canvas léger, permettant à l'agent de raisonner sur un graphe symbolique plutôt que sur des logs verbeux. Les gains de performance mesurés par Tencent sur des sessions continues sont significatifs. Sur WideSearch, le taux de réussite passe de 33 % à 50 % (amélioration relative de 51,52 %) et la consommation de tokens chute de 221,31 millions à 85,64 millions, soit une réduction de 61,38 %. Sur SWE-bench, testé en sessions de 50 tâches consécutives pour simuler l'accumulation de contexte, le taux de succès monte de 58,4 % à 64,2 % pendant que les tokens passent de 3 474 millions à 2 375 millions (-33 %). Sur le benchmark de mémoire personnalisée PersonaMem, la précision bondit de 48 % à 76 %. La récupération combine par défaut recherche BM25 et embeddings vectoriels via Reciprocal Rank Fusion, avec support du chinois (jieba) et de l'anglais. Une extraction de mémoire L1 se déclenche toutes les cinq interactions, un persona utilisateur est généré tous les 50 nouveaux souvenirs, et un timeout de cinq secondes évite de bloquer la conversation en cas d'échec de rappel. Ces résultats s'inscrivent dans une course plus large à la résolution du problème de mémoire pour les agents IA autonomes. La plupart des systèmes actuels fragmentent les données dans des stores vectoriels plats, rendant le rappel aveugle et peu structuré. L'approche de Tencent, qui sépare structure symbolique et texte brut tout en maintenant une hiérarchie sémantique, représente une alternative architecturale concrète. Le projet étant open source sous MIT et autosuffisant localement, il s'adresse directement aux développeurs qui construisent des agents de production sans vouloir dépendre d'une API mémoire tierce. Le modèle par défaut est DeepSeek-V3.2 de Tencent Cloud, mais tout modèle compatible OpenAI peut être substitué, ce qui élargit considérablement le périmètre d'adoption potentielle.

💬 La réduction de 61% des tokens sur WideSearch, ça ne s'invente pas. Tencent a fait ce que la plupart des frameworks négligent encore : séparer la structure symbolique du texte brut et organiser la mémoire en hiérarchie, plutôt que de tout jeter dans un store vectoriel plat et prier pour que le rappel fonctionne. Open source MIT, autosuffisant en local, compatible n'importe quel modèle OpenAI-compatible, les ingrédients sont là.

Tencent lance Team Memory pour partager la mémoire des agents IA en équipe, sans garde-fou en cas d'erreur

Tencent a lancé cette semaine, en version bêta, un nouvel outil baptisé Team Memory, qui permet à plusieurs agents IA de partager la même mémoire contextuelle au sein d'une équipe. Ce projet prolonge Agent Memory, un système open source que l'entreprise dit avoir développé pendant six mois pour résoudre un problème plus étroit : la perte de contexte des agents lors de sessions longues. Ce système repose notamment sur une couche dite "persona", une représentation stable de l'utilisateur construite progressivement au fil de nombreuses conversations plutôt que reconstruite à chaque échange. Sur le benchmark interne de Tencent mesurant la capacité d'un agent à conserver cette représentation après un usage prolongé, la précision est passée de 48 % à 76 %, soit une amélioration relative de 59 %, grâce à l'ajout de cette couche persona. Le dépôt du projet est devenu cette semaine numéro un du classement GitHub des projets tendance en TypeScript. Avec Team Memory, les agents d'une même équipe n'accèdent plus à des contextes séparés et cloisonnés mais à un hub mémoriel commun, structuré autour de quatre types de ressources réutilisables : la mémoire de conversation (préférences, faits, décisions), les compétences opérationnelles tirées de tâches accomplies, un wiki structuré généré à partir de documents et un graphe de code indexant les symboles et dépendances d'un projet logiciel. L'accès est réglé par quatre niveaux de visibilité (privé, équipe, restreint ou spécifique à un agent), les nouvelles ressources étant privées par défaut. Cette évolution répond à un problème documenté : une enquête VB Pulse menée en juin a révélé que 57 % des entreprises avaient déjà retracé une réponse erronée mais formulée avec assurance par un agent IA jusqu'à un contexte manquant ou incohérent. Jusqu'ici, la plupart des correctifs de l'industrie amélioraient la mémoire d'un agent isolé au sein d'une seule session. Team Memory change d'échelle en permettant à toute une équipe d'agents de s'appuyer sur les mêmes informations simultanément, via ce que Tencent appelle un Agent Loadout : un agent chargé de la recherche reçoit les analyses de marché pertinentes, tandis qu'un agent chargé du développement reçoit le graphe de code et la documentation produit, chacun n'étant équipé que des ressources dont il a besoin. L'enjeu est direct pour les entreprises qui déploient des flottes d'agents en production : une information fausse n'affecte plus un seul utilisateur devant la corriger localement, elle se propage potentiellement à tous les agents qui la consultent, amplifiant l'impact d'une erreur au lieu de le limiter. Cette approche s'inscrit dans une tendance plus large de l'industrie à traiter la gestion du contexte comme le facteur déterminant de la fiabilité des agents autonomes, après des mois où la recherche s'est surtout concentrée sur l'extension des fenêtres de contexte et la mémorisation individuelle. Mais le lancement de Team Memory a aussi mis en lumière une lacune que des praticiens ont signalée dès les premières heures suivant l'annonce : si la documentation de Tencent détaille précisément la propriété, le versionnage et le suivi du statut de chaque ressource mémorielle, elle ne décrit aucun mécanisme de correction ou d'expiration pour un fait erroné déjà lu et réutilisé par d'autres agents, ni aucune procédure pour trancher lorsque deux agents détiennent des souvenirs contradictoires d'un même événement. Cette question de la gouvernance des erreurs, distincte du simple contrôle d'accès, devrait devenir centrale à mesure que les entreprises multiplient les déploiements d'équipes d'agents interconnectées, et pourrait déterminer si des systèmes comme Team Memory tiennent leurs promesses en production ou reproduisent, à plus grande échelle, les erreurs de contexte qu'ils cherchaient à éliminer.

Memory OS : une architecture mémoire open source à 6 couches pour agents Hermes

Un développeur de la communauté open-source, ClaudioDrews, vient de publier Memory OS, une bibliothèque sous licence MIT qui superpose six couches de mémoire à Hermes Agent, l'agent conversationnel de Nous Research. Là où Hermes propose déjà des fichiers de workspace et une base de données de sessions avec recherche plein texte, Memory OS y ajoute une base vectorielle Qdrant, des faits structurés avec scoring de confiance, un wiki de concepts auto-curé, et un système de rappel chirurgical à chaque appel LLM. L'ensemble tourne en local via Docker, Qdrant, Redis et Python 3.11+, et fonctionne avec n'importe quel fournisseur LLM supporté par Hermes : OpenRouter, OpenAI, Anthropic ou Ollama. Les six couches vont du simple fichier MEMORY.md injecté dans le prompt système (couche 1) jusqu'à un wiki LLM continuellement réingéré dans Qdrant (couche 6), en passant par une base SQLite avec FTS5, des vecteurs Cosine en 4096 dimensions combinés à une recherche BM25, et une version fortement remaniée du plugin Icarus gérant le rappel inter-sessions via 16 outils dédiés. L'intérêt concret de cette architecture réside dans son mécanisme de récupération : à chaque appel LLM, le système interroge simultanément quatre sources (Fabric, Qdrant, Sessions, Facts), filtre les résultats par seuil de pertinence, déduplique par session et ignore les messages triviaux. En sortie de session, il extrait et capitalise automatiquement les nouveaux apprentissages. Un scanner hebdomadaire fait vieillir les entrées obsolètes, et une déduplication sémantique fusionne les souvenirs quasi-identiques dès que la similarité cosinus dépasse 0,92. L'objectif affiché est l'efficacité en tokens : ne charger dans le contexte que ce qui est réellement utile, pas saturer la fenêtre. Pour les équipes soumises à des règles de résidence des données, le fait que rien ne quitte la machine locale représente un avantage réel que les services cloud comme mem0, Zep ou Letta ne peuvent pas offrir. Memory OS s'inscrit dans un débat plus large sur la mémoire des agents IA : jusqu'où peut-on aller avec une mémoire embarquée dans l'agent lui-même, sans passer par une infrastructure cloud payante ? Hermes Agent propose déjà huit fournisseurs de mémoire externes officiels, dont mem0 et Honcho, mais Memory OS n'en fait pas partie, c'est une surcouche communautaire indépendante, ce qui dit quelque chose sur l'appétit des développeurs pour des solutions souveraines. Le projet est récent et sa maturité reste à prouver à l'usage, mais son architecture en cascade de fallback (hybride, puis vectoriel dense, puis lexical, puis SQLite) montre une réflexion sérieuse sur la robustesse. Si l'adoption suit, ce type de stack mémoire locale pourrait devenir un modèle de référence pour les agents à usage intensif en entreprise.

OpenAI publie Symphony en open source : un SPEC.md pour l'orchestration d'agents de codage autonomes

OpenAI a publié en open source Symphony, un orchestrateur d'agents de codage autonomes accompagné d'une spécification formelle baptisée SPEC.md. Le système utilise des outils de gestion de projet, comme les gestionnaires de tickets, comme plan de contrôle pour coordonner plusieurs agents travaillant en parallèle. Concrètement, Symphony découpe le travail en "tâches" distinctes, chacune confiée à un agent dédié qui progresse jusqu'à l'achèvement sans intervention humaine continue. Une fois la tâche terminée, un développeur humain examine le résultat avant de valider ou corriger. Ce modèle rompt avec l'approche actuelle où les développeurs supervisent activement chaque session de codage assistée par IA. Avec Symphony, un ingénieur peut déléguer simultanément plusieurs blocs de travail à une flotte d'agents autonomes, ce qui multiplie potentiellement la capacité de production d'une équipe sans augmenter ses effectifs. Pour les entreprises tech, cela annonce des pipelines de développement logiciel beaucoup plus automatisés, où l'humain intervient surtout en phase de validation plutôt qu'en pilotage continu. Symphony émerge dans un contexte de compétition intense autour des agents de codage autonomes. OpenAI affronte Anthropic et son assistant Claude, Google avec Gemini Code Assist, ainsi que des startups comme Cognition AI dont l'agent Devin cible explicitement ce marché. En diffusant Symphony sous forme de spécification ouverte, OpenAI tente d'influencer les standards de l'industrie et d'encourager l'adoption de son approche d'orchestration par d'autres équipes et plateformes. La prochaine étape sera de voir si SPEC.md s'impose comme référence, ou si chaque acteur développe son propre modèle propriétaire.

💬 OpenAI publie une spec ouverte, pas juste du code, et c'est exactement la stratégie qu'on adopte quand on veut que l'industrie entière s'aligne sur ton modèle d'orchestration plutôt que sur celui du voisin. Le truc intéressant dans Symphony, c'est ce glissement : le dev ne pilote plus en continu, il valide à la fin, comme un lead qui fait des code reviews plutôt que du pair-programming permanent. Ça ressemble à du vrai changement de workflow, pas du gadget.