DeepSeek dévoile son plan d'auto-évolution : Harness permet à l'IA de développer comme un jeu de Lego

Titre original : « Le plan d'auto-évolution de DeepSeek dévoilé »

Jay de Aofeisi Quantum  | Compte officiel QbitAI

Le dernier article de DeepSeek en collaboration avec l'Université de Pékin a levé le voile sur la version Harness de la baleine.

Intitulé « A Programming Paradigm for Spatiotemporal Composability », traduit en chinois par « Une méthode de programmation pour la composition spatiotemporelle ».

Cela peut sembler un peu compliqué, mais vous n'avez besoin de retenir qu'une seule phrase ------

Tout l'article tourne autour de Cordis, le cœur de la baleine noire, une « base Lego » interchangeable.

Ici, tout est un plugin, tout peut être réorganisé.

Cela explique également pourquoi le niveau d'ouverture de la « baleine noire » est si élevé, et pourquoi l'équipe encourage tout le monde à créer des plugins et à modifier Harness.

Un article riche en informations, qui est également le fruit de plusieurs mois de travail de l'équipe DeepSeek Harness, qui a finalement remporté une belle victoire sous la forme de la grande baleine noire.

Il est à noter que c'est le septième article de DeepSeek cette année, et aussi la Nème collaboration avec l'Université de Pékin.

Au total, plus de quatre-vingts pages, j'ai parcouru l'article de A à Z et j'ai réussi à en tirer quelques points clés ------

1. Cordis fournit un ensemble de sémantiques de composition dynamique universelles. 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 bases 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. Ce design fonctionne déjà sur le cadre du robot de chat Koishi depuis quatre ans, avec plus de 4000 plugins communautaires validés en environnement de production.

Et tout cela sert un même objectif ------

L'auto-évolution.

01 Temps et espace, les deux obstacles à l'auto-évolution de Harness

Il existe une réalité contre-intuitive dans le monde des logiciels : la plupart des systèmes de plugins nécessitent un redémarrage complet du processus hôte après la désinstallation d'un plugin.

Cela signifie que ce qui est supprimé n'est peut-être qu'un plugin, mais tous les plugins déjà chargés doivent également être redémarrés.

Oui, un « plugin », une fois inséré, ne peut pas être retiré.

VSCode est un exemple typique.

L'article indique qu'à partir du 9 juin 2026, parmi les 100 extensions les mieux classées sur le marché de VSCode, 87 contiennent du code exécutable, et une fois activées, elles ne peuvent pas être désinstallées individuellement à l'exécution ; il faut redémarrer l'hôte de l'extension après les avoir désactivées ou supprimées.

Ce n'est pas un problème propre à VSCode. L'article souligne que presque toutes les architectures de plugins présentent ce type de défaut, bien que dans des degrés divers.

Cela serait déjà assez problématique dans un système de plugins ordinaire, mais si le coût n'est que de redémarrer, cela peut encore être acceptable.

Mais dans le contexte des Agents, c'est un tout autre problème.

Un saddle ordinaire est généralement rempli de nombreuses choses : ensembles d'outils, environnements d'exécution, contrôle des permissions, sandbox, état de session, systèmes de mémoire... c'est déjà un système d'ingénierie extrêmement complexe.

Et maintenant, avec l'« IA auto-évolutive », un Sun Wukong, il est facile de se retrouver à se modifier soi-même sans s'en rendre compte.

C'est aussi l'angle d'attaque de DeepSeek sur l'auto-évolution :

Les futurs Agents pourraient générer eux-mêmes un outil en fonction de la tâche, l'intégrer dans le runtime, et s'ils rencontrent des problèmes, le remplacer eux-mêmes.

Si chaque fois qu'une ligne de code est modifiée, il faut redémarrer tout le processus, alors tout le contexte et le cache accumulés pourraient s'effondrer.

C'est ce qu'on appelle la composition temporelle.

Si les dépendances entre les modules dépendent de chaque module pour se corriger, aujourd'hui on vérifie s'il y a A, demain on devine B... un faux pas pourrait introduire une dépendance circulaire, et au moment du rechargement, cela pourrait exploser.

C'est ce qu'on appelle la composition spatiale.

Et ces deux difficultés sont précisément les deux problèmes que Cordis doit résoudre.

La solution de DeepSeek

D'abord, il faut ajouter deux points mathématiques, qui sont les deux grands piliers théoriques de cet article ------

Effets et co-effets.

En termes simples, les effets décrivent « l'impact du programme sur le monde » ; les co-effets décrivent « les contraintes du monde sur le programme ». Les deux sont en relation d'adéquation : le système des effets enrichit les types, le système des co-effets enrichit le contexte.

Mais il y a un problème, dans le contexte de l'IA auto-évolutive, le cadre est chargé dynamiquement.

Les effets/co-effets classiques sont des outils de systèmes de types statiques.

Pour surmonter simultanément les deux obstacles temporels et spatiaux, l'équipe a adapté et mis à niveau ces deux concepts pour le runtime des Agents ------ « effets réversibles » et « co-effets réactifs ».

Effets réversibles (revertible effects), ciblent la dimension temporelle.

La définition clé se résume en une phrase : 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 en une « chaîne d'annulation ».

Lors de la désinstallation d'un plugin, cette chaîne est exécutée à l'envers, permettant à l'état du système de revenir exactement à l'état avant le chargement du plugin.

On peut comprendre cela comme une pile d'assiettes, la dernière placée étant la première à être retirée.

Ainsi, l'ordre temporel ne sera pas perturbé.

Co-effets réactifs (reactive coeffects) s'occupent de la dimension spatiale.

Dans Cordis, les composants peuvent déclarer quelles dépendances ils nécessitent, permettant ainsi aux dépendances d'être résolues.

Par exemple, un plugin de chat peut dire qu'il a besoin d'un adaptateur de message 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, sans se précipiter pour démarrer, et ne se met pas en marche pour ensuite échouer à cause d'une référence nulle.

Lorsque le fournisseur apparaît, le dépendant s'active automatiquement. Lorsque le fournisseur se retire, le dépendant s'arrête d'abord, attendant que son effet soit annulé avant que le fournisseur ne termine la désinstallation.

Si le fournisseur de dépendance est désinstallé, le dépendant est automatiquement désactivé ; si la dépendance est remise en ligne, le dépendant se réactive automatiquement. Cette orchestration topologique ne dépend pas de l'écriture manuelle par le développeur, mais est automatiquement déduite des déclarations.

La combinaison des deux constitue le cœur de Cordis.

Le sens intuitif de « composition spatiotemporelle » dans le titre de l'article réside ici.

02 Koishi

Alors, tout ce qui vient d'être dit a-t-il été vérifié par la pratique ?

Oui.

Et en plus, c'est d'une taille considérable.

L'article utilise un cadre de robot de chat appelé Koishi pour valider les expériences.

Koishi est construit sur Cordis, accumulant plus de 4000 plugins communautaires en quatre ans, couvrant des adaptateurs de messagerie instantanée, des pilotes de base de données, des consoles de gestion et diverses fonctionnalités utilisateur.

GitHub indique que Koishi est un cadre de robot de chat multiplateforme, extensible et performant.

Son nom et son design d'icône proviennent du personnage Komeiji Koishi de la série Touhou Project.

Komeiji Koishi est un personnage qui agit de manière inconsciente, et ce nom symbolise à la fois le thème du robot de chat et l'amour que les développeurs lui portent.

C'est aussi une README assez intéressante.

Alors, qu'est-ce que Cordis ?

L'auteur de Koishi indique que le nom Cordis vient du latin pour « cœur », tout dans Koishi commence par Cordis.

En tant que méta-cadre, Cordis n'est pas couplé à un domaine ou un scénario spécifique.

Les capacités qu'il offre sont assez banales pour la plupart des cadres ------ un système de plugins, mais derrière ce système se cache un objectif que la plupart des cadres n'ont pas atteint : la réversibilité.

Il a également laissé cette phrase :

J'espère qu'il pourra devenir le cœur des logiciels futurs (du moins des logiciels que je développe).

Quatre ans plus tard, cet article de DeepSeek a fourni une 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 sera annulé sur place, et les autres plugins continueront de fonctionner.

Lors du développement, après avoir modifié et enregistré un plugin, celui-ci sera réappliqué, le cache et les connexions restant inchangés.

Ensuite, la validation de la dimension spatiale.

Dans l'écosystème Koishi, les adaptateurs IM fournissent l'accès aux plateformes de messagerie, les pilotes de base de données fournissent un stockage persistant, et les plugins fonctionnels déclarent ces dépendances pour y accéder directement.

Dans le fonctionnement réel, lors du changement de backend de stockage ou de la reconnexion d'un adaptateur, seuls les plugins dont les dépendances ont réellement changé seront réactivés, tandis que les plugins dont les dépendances n'ont pas changé resteront inchangés.

Il faut savoir que ces plugins sont généralement développés indépendamment par différents auteurs, et la seule coordination entre eux est le co-effet réactif souligné par Cordis.

Cela montre qu'un ensemble de règles de composition dynamique peut effectivement fonctionner dans un écosystème de plugins ouverts contribué par différents auteurs.

Mais l'article n'a pas présenté ce cas comme un démo parfait.

L'équipe admet qu'il n'y a actuellement que des données de validation dans l'écosystème Koishi et avec le langage TypeScript, manquant de comparaisons contrôlées avec des architectures alternatives...

Mais le plus important est qu'il a indiqué une nouvelle direction, un ensemble de bases pour un Agent d'auto-évolution.

Le DeepSeek Harness publié aujourd'hui est en effet la version améliorée de Koishi Cordis.

03 Présentation des auteurs de l'article

Enfin, parlons des auteurs de l'article.

Ils sont au nombre de trois, issus de l'Université de Pékin et de DeepSeek.

Le premier auteur s'appelle Yifan Shi, de l'Université de Pékin, et est également membre de DeepSeek.

Après une recherche approfondie, il s'avère qu'il avait déjà été mentionné dans le rapport technique V3 de DeepSeek.

Le projet utilisé pour la validation dans ce nouvel article ------ Koishi ------ est également de sa main.

On peut voir qu'il a une forte obsession pour « shi », son vrai nom étant Yifan Shi, le projet s'appelant Koishi, et son nom GitHub étant Shigma.

（doge）

Revenons au sujet.

Koishi est un dépôt de quatre ans, qui compte aujourd'hui 5,7K étoiles. On peut dire que c'est la source de tout.

Car le concept de Cordis a également été proposé dans Koishi.

En 2023, Shigma a écrit un article de conception pour la documentation officielle de Koishi, intitulé « Système de plugins réversibles », qui est presque 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 l'École d'informatique de l'Université de Pékin.

Le site officiel de l'école indique que les domaines de recherche de Wei Zhang couvrent principalement l'ingénierie logicielle et les langages de programmation.

En 1999, il a obtenu son diplôme de premier cycle en thermique et physique de l'ingénierie à l'Université de l'aviation et de l'espace de Nanjing. Il s'est ensuite tourné vers l'informatique, obtenant un master en informatique à la même université en 2002.

Après avoir obtenu son master, Wei Zhang a poursuivi son doctorat à l'Université de Pékin et a obtenu son doctorat en logiciels et théories informatiques en 2006.

Après son doctorat, il est resté à l'Université de Pékin et a continué à travailler dans la recherche et l'enseignement dans les domaines de l'ingénierie logicielle et des langages de programmation.

Il est à noter qu'il a déjà collaboré avec Yifan Shi lors de l'ASE en 2021.

En 2024, ils ont à nouveau publié ensemble un article à l'ICSME intitulé « Focused: An Approach to Framework-oriented Cross-language Link Specification and Detection ».

Enfin, il y a un ancien camarade.

Cui Tianyi, responsable de l'équipe DeepSeek Harness. Il a obtenu son diplôme en informatique à l'Université de Zhejiang, un ancien élève de Liang Wenfeng.

Pendant ses études, Cui Tianyi a été recommandé à l'Université de Zhejiang en raison de ses performances au NOIP/concours d'informatique, remportant également six médailles d'or lors de la compétition régionale asiatique ACM.

Après avoir obtenu son diplôme, il a travaillé pendant neuf ans dans les bureaux de Hong Kong et de New York de Jane Street.

Lien vers l'article : https://github.com/cordiverse/paper

Koishi : https://github.com/koishijs/koishi

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.