Le dernier article de recherche en collaboration entre DeepSeek et l'Université de Pékin a levé le voile sur la version Harness de la baleine noire.
Il s'intitule « A Programming Paradigm for Spatiotemporal Composability », traduit en chinois par 《一套处理时空可组合性的编程范式》 (Un paradigme de programmation pour la composabilité spatio-temporelle).
Cela semble un peu alambiqué, retenez simplement cette phrase :
L'article entier tourne autour de Cordis, le noyau de la baleine noire, une « plaque de base Lego » qui peut être branchée et débranchée à volonté.
Ici, tout est un plugin, tout peut être réorganisé.
Cela explique aussi pourquoi le degré d'ouverture de la « Baleine Noire » est si élevé et pourquoi l'équipe officielle encourage tant la création de plugins et la modification de Harness.
Un article riche en informations, et sans doute le travail de synthèse sur lequel l'équipe Harness de DeepSeek planchait depuis si longtemps, remportant finalement une belle victoire sous la forme de la grande baleine noire.
Il est à noter qu'il s'agit du septième article de DeepSeek cette année, et de la N-ième collaboration avec l'Université de Pékin.
Plus de quatre-vingts pages au total. J'ai dévoré l'article du début à la fin et en ai tiré quelques points clés :
1. Cordis fournit une sémantique générique de composition dynamique. Les composants gérés par le Contexte peuvent être chargés et déchargés dynamiquement, et leurs effets secondaires gérés sont automatiquement récupérés.
2. Les fondements mathématiques proviennent de deux concepts classiques de la théorie des types : les effets et les co-effets.
3. Ce n'est pas un jouet de laboratoire. Cette conception fonctionne depuis quatre ans sur le framework de chatbot Koishi, avec plus de 4000 plugins communautaires validés en environnement de production.
Et tout cela sert une seule et même ambition :
L'auto-évolution.
Temps et espace, les deux obstacles à l'auto-évolution de Harness
Le monde du logiciel présente une réalité contre-intuitive : la plupart des systèmes supportant des plugins nécessitent un redémarrage du processus hôte après le déchargement d'un plugin.
Cela signifie que si vous supprimez un seul plugin, tous les plugins déjà chargés doivent redémarrer avec lui.
Oui, un « plug-in » est en réalité branché pour ne plus être débranché.
VSCode en est un cas typique.
L'article indique qu'au 9 juin 2026, sur les 100 premières extensions du VSCode Marketplace, 87 contenaient du code exécutable. Une fois activées, elles ne peuvent pas être déchargées individuellement à l'exécution ; après désactivation ou suppression, tout l'hôte d'extensions doit redémarrer.
Ce problème n'est pas propre à VSCode. L'article souligne que presque toutes les architectures de plugins présentent ce type de défaut, à des degrés divers.
Dans un système de plugins classique, c'est déjà assez gênant, mais si le coût n'est qu'un redémarrage, c'est acceptable.
Mais dans le contexte des Agents, c'est un problème totalement différent.
Un harnais classique est généralement rempli de nombreuses choses : ensembles d'outils, environnement d'exécution, contrôle des permissions, bac à sable, état des sessions, système de mémoire... C'est déjà un système d'ingénierie extrêmement complexe.
Et aujourd'hui, il rencontre ce « Sun Wukong » qu'est l'IA auto-évolutive, qui pourrait, en un instant, se modifier elle-même jusqu'à disparaître.
C'est aussi l'angle sous lequel l'article de DeepSeek aborde l'auto-évolution :
À l'avenir, un Agent pourrait, selon la tâche, générer lui-même un outil, l'installer dans son environnement d'exécution, et s'il découvre un problème, le remplacer lui-même.
Si chaque modification d'une ligne de code nécessite un redémarrage complet du processus, tout le contexte accumulé, le cache, risque de s'effondrer.
C'est ce qu'on appelle la composabilité temporelle.
Si les dépendances entre modules reposent sur des rustines faites par chaque module, vérifiant aujourd'hui la présence de A, devinant demain celle de B... on risque d'introduire des dépendances circulaires sans s'en rendre compte, qui exploseront au moment du rechargement.
C'est ce qu'on appelle la composabilité spatiale.
Ces deux difficultés sont précisément les problèmes que Cordis vise à résoudre.
La solution de DeepSeek
Il faut d'abord ajouter deux points de connaissance mathématique, qui sont aussi les deux piliers théoriques de cet article :
Les effets et les co-effets.
En simplifiant, les effets caractérisent « l'influence du programme sur le monde » ; les co-effets caractérisent « les contraintes du monde sur le programme ». Les deux sont en relation de dualité : un système d'effets enrichit les types, un système de co-effets enrichit le contexte.
Mais il y a un problème : dans le contexte de l'IA auto-évolutive, le framework est chargé dynamiquement.
Les effets/co-effets classiques sont des outils de systèmes de types statiques.
Pour franchir simultanément les obstacles du temps et de l'espace, l'équipe a adapté et mis à niveau ces deux concepts pour l'environnement d'exécution des Agents : les « effets réversibles » et les « co-effets réactifs ».
Les effets réversibles (revertible effects) ciblent la dimension temporelle.
La définition centrale est simple : chaque modification du contexte doit être accompagnée d'une fonction inverse explicite, de sorte que les effets secondaires soient réversibles.
Lors du chargement d'un plugin, chaque modification d'état enregistre la fonction inverse correspondante, s'accumulant séquentiellement pour former une « chaîne d'annulation ».
Lors du déchargement du plugin, cette chaîne est exécutée en sens inverse, permettant au système de revenir précisément à l'état précédant le chargement du plugin.
On peut imaginer une pile d'assiettes : la dernière posée est la première retirée.
Ainsi, l'ordre chronologique ne sera pas perturbé.
Les co-effets réactifs (reactive coeffects) sont responsables de la dimension spatiale.
Dans Cordis, un composant peut déclarer les dépendances dont il a besoin, rendant ces dépendances résolubles.
Par exemple, un plugin de discussion dit qu'il a besoin d'un adaptateur de messages et d'une base de données. Si les deux dépendances sont satisfaites, il passe à l'état ACTIF. S'il en manque une, il reste INACTIF, ne démarre pas précipitamment et n'échoue pas plus tard à cause d'une référence nulle.
Lorsqu'un fournisseur apparaît, le dépendant s'active automatiquement. Si le fournisseur se retire, le dépendant s'arrête d'abord, puis après avoir annulé ses propres effets, le fournisseur peut terminer son déchargement.
Si le fournisseur d'une dépendance est déchargé, le dépendant se désactive automatiquement ; si la dépendance revient en ligne, le dépendant se réactive. Cette orchestration topologique ne repose pas sur du code écrit manuellement par les développeurs, mais est déduite automatiquement des déclarations.
La combinaison des deux constitue le cœur de Cordis.
C'est la signification intuitive de la « composabilité spatio-temporelle » dans le titre de l'article.
Koishi
Alors, tout ce qui vient d'être dit a-t-il été validé par la pratique ?
Oui.
Et à une échelle non négligeable.
Le projet utilisé pour la validation expérimentale dans l'article est un framework de chatbot appelé Koishi.
Koishi est construit sur Cordis. En quatre ans, il a accumulé plus de 4000 plugins communautaires, couvrant des adaptateurs de messagerie instantanée, des pilotes de base de données, des consoles d'administration et diverses fonctions utilisateur.
GitHub indique que Koishi est un framework de chatbot multiplateforme, extensible et haute performance.
Son nom et son icône sont inspirés du personnage Komeiji Koishi de l'univers d'東方Project (Touhou Project).
Komeiji Koishi est un personnage qui fait des gestes inconscients. Ce nom symbolise à la fois le thème du chatbot et l'amour que les développeurs y ont investi.
Un fichier README plutôt intéressant.
Qu'est-ce que Cordis alors ?
L'auteur de Koishi indique que le nom Cordis vient du latin « cœur » (cor, cordis), et que tout dans Koishi commence avec Cordis.
En tant que méta-framework, Cordis n'est couplé à aucun domaine ou scénario concret.
La capacité qu'il fournit est quelque chose que la plupart des frameworks offrent sans grande originalité — un système de plugins. Mais derrière ce système se cache un objectif que la plupart des frameworks n'atteignent pas : la réversibilité.
Il a même laissé cette phrase :
J'espère qu'il deviendra le cœur du logiciel futur (au moins du logiciel que je développerai).
Quatre ans plus tard, cet article de DeepSeek apporte la validation.
D'abord, la validation de la dimension temporelle.
Dans Koishi, un administrateur peut désactiver un plugin depuis la console. L'impact du plugin sur le système est annulé sur place, les autres plugins continuant de fonctionner.
Pendant le développement, lorsqu'un plugin est modifié et sauvegardé, le plugin modifié est réappliqué, tandis que le cache et les connexions restent inchangés.
Ensuite, la validation de la dimension spatiale.
Dans l'écosystème Koishi, les adaptateurs de messagerie instantanée (IM) fournissent l'accès aux plateformes de messages, les pilotes de base de données fournissent le stockage persistant, et les plugins fonctionnels déclarent ces éléments comme dépendances pour y accéder directement.
En cours d'exécution, lors du changement de backend de stockage ou de la reconnexion d'un adaptateur, seuls les plugins dont les dépendances ont effectivement changé sont réactivés. Les plugins dont les dépendances n'ont pas changé restent immobiles.
Il faut savoir que ces plugins sont généralement développés indépendamment par différents auteurs. La seule coordination entre eux est ce co-effet réactif que Cordis met en avant.
Cela montre qu'un ensemble de règles de composition dynamique peut effectivement fonctionner dans un écosystème ouvert de plugins contribués par différents auteurs.
Mais l'article ne présente pas non plus ce cas comme une démo parfaite.
L'équipe reconnaît qu'il n'existe actuellement que des données de validation provenant d'un seul écosystème (Koishi) et d'un seul langage (TypeScript), et qu'il manque des comparaisons contrôlées avec des architectures alternatives...
Mais le plus important est sans doute d'avoir indiqué une nouvelle direction : une infrastructure de base pour le harnais des Agents, au service de l'auto-évolution.
Et aujourd'hui, la version publiée de DeepSeek Harness est précisément une version améliorée de Koishi Cordis.
Présentation des auteurs de l'article
Pour finir, parlons comme d'habitude des auteurs.
Ils sont trois, répartis entre l'Université de Pékin et DeepSeek.
Le premier auteur est Yifan Shi, de l'Université de Pékin, et également membre de DeepSeek.
Une recherche approfondie révèle que son nom était déjà apparu dans le Technical Report de DeepSeek V3.
Le projet utilisé pour la validation dans ce nouvel article — Koishi — est aussi son œuvre.
On dirait qu'il a une forte attirance pour « shi » : son vrai nom est Yifan Shi, son projet s'appelle Koishi, son pseudo GitHub est Shigma.
(doge)
Revenons au sujet.
Koishi est un dépôt créé il y a quatre ans, comptant aujourd'hui 5,7K étoiles. On peut dire que c'est l'origine de tout.
Car le concept de Cordis a également été proposé au sein de Koishi.
En 2023, Shigma a écrit un article de conception pour la documentation officielle de Koishi, intitulé « Système de plugins réversible », qui est quasiment l'ancêtre de ce nouvel article.
Wei Zhang, également de l'Université de Pékin, est professeur associé à l'Institut de recherche en logiciels de la Faculté d'informatique de l'Université de Pékin.
Le site de la faculté indique que ses domaines de recherche couvrent principalement l'ingénierie logicielle et les langages de programmation.
En 1999, il est diplômé de licence en ingénierie thermophysique de l'Université de l'aéronautique et de l'astronautique de Nanjing. Il s'est ensuite orienté vers l'informatique, obtenant une maîtrise en sciences informatiques de la même université en 2002.
Après sa maîtrise, Zhang Wei a poursuivi un doctorat à l'Université de Pékin, obtenant son Ph.D. en logiciel et théorie informatique en 2006.
Après son doctorat, il est resté directement à l'Université de Pékin, où il a depuis mené des recherches et enseigné dans les domaines de l'ingénierie logicielle et des langages de programmation.
Il est à noter qu'en 2021, lors de l'ASE, Zhang Wei avait déjà collaboré avec Yifan Shi.
En 2024, ils ont à nouveau co-publié un article ICSME intitulé « Focused: An Approach to Framework-oriented Cross-language Link Specification and Detection ».
Et enfin, une connaissance de longue date.
Tianyi Cui, responsable de l'équipe DeepSeek Harness. Diplômé de licence du département d'informatique de l'Université du Zhejiang, et camarade junior de Wenfeng Liang.
Pendant ses études, Tianyi Cui a été admis à l'Université du Zhejiang via l'exemption du NOIP/concours d'informatique, et a également remporté 6 fois la médaille d'or du concours international de programmation pour étudiants ACM en Asie.
Après l'obtention de son diplôme, il a travaillé pendant 9 ans chez Jane Street, dans les bureaux de Hong Kong et de New York.
Lien vers l'article : https://github.com/cordiverse/paperKoishi : https://github.com/koishijs/koishi
Cet article provient du compte public WeChat « Quantum Bit », auteur : Jay
