Relation avec DeepSeek Harness

论文版本948a07b (main)

L'article implémente Cordis, et DeepSeek Harness est construit sur Cordis. Mais Cordis, Koishi et DeepSeek Harness sont trois projets distincts ; ne pas les confondre.

La relation entre les trois projets

[Inference basée sur l'article et les sources officielles] :

• Cordis : un meta-framework open-source (MIT) qui implémente la spatiotemporal composability décrite dans l'article. Dépôt github.com/cordiverse/cordis ; le paquet cœur cordis est actuellement en version 4.0.0-rc.x (correspondant à Cordis v4 décrit dans l'article §5). Il est indépendant de DeepSeek et maintenu par l'organisation cordiverse (Shigma en est un auteur central).
• Koishi : un framework d'application de chatbot open-source (MIT) construit sur Cordis. Étude de cas §5.3 de l'article : Koishi utilise actuellement Cordis v3, et l'article décrit Cordis v4 ; "the core compositional model is shared across both versions". Koishi a 4000+ plugins communautaires et est le cas de production de l'article.
• DeepSeek Harness (DSH) : un Agent Harness open-source (MIT) de DeepSeek, construit sur le cœur de Cordis. Dépôt github.com/deepseek-ai/deepseek-harness. La documentation officielle est explicite : le cœur de Cordis gère le montage/déchargement/dépendances des plugins ; le Harness est construit sur le système de plugins de Cordis, "Everything is a plugin".

Note sur les auteurs de l'article : Tianyi Cui (DeepSeek-AI), c.-à-d. Shigma, est l'auteur du framework Koishi. Donc Cordis / Koishi / Harness partagent tous la même lignée (tous liés à Shigma), mais l'article n'est pas une production exclusivement DeepSeek — la première institution est l'Université de Pékin ; la seconde est DeepSeek-AI.

Pourquoi ce mécanisme convient à DeepSeek Harness

[Inference basée sur l'article] DSH fait de Tools / Skills / Sessions / Sandboxes / Storage / Loops / Sub-agent scheduling / UI des plugins Cordis, donc :

1. Remplacement à chaud d'un Tool Provider : remplacer un outil pendant que l'Agent tourne (p. ex. mettre à niveau la version de l'outil de recherche de fichiers) → Cordis décharge l'ancien fiber, installe le nouveau, et les Sessions et sous-Agents qui dépendent de cet outil se re-résolvent automatiquement. Le processus entier est garanti par le théorème d'Ordering : l'ancien provider se décharge après ses consumers, donc il n'y a pas de "utilisation d'un outil déjà libéré".
2. Environnement indépendant pour les sous-Agents : chaque sous-Agent utilise ctx.isolate pour dériver un contexte indépendant, et la même key (p. ex. 'filesystem') se résout en instances différentes dans différents sous-Agents. Les sous-Agents ne se polluent pas entre eux ; l'Agent parent peut appliquer des realms différents à différents sous-Agents.
3. Contrôle des permissions du Sandbox : appliquer des politiques d'accès plus strictes aux plugins communautaires (p. ex. filesystem en lecture seule) via ctx.intercept, restreignant leurs capacités sans modifier le code du plugin.
4. Traçabilité de Trajectory : le log de session append-only de DSH et l'accumulator d'effects de Cordis sont dans le même esprit — tous deux sont des "traces d'exécution reproductibles". Mais notez la distinction : le log de session de DSH enregistre au niveau emission (§6.1) et ne peut être réverti automatiquement ; l'accumulator de Cordis est au niveau acquisition et peut être récupéré automatiquement. Le premier est un log de "ce qui s'est passé" ; le second est une chaîne d'opérations inverses "comment réverter les effets de bord qui se sont produits".

État actuel de DeepSeek Harness

[Vérifié d'après les sources officielles, 2026-08-15] À ce jour, DSH est encore en Developer Preview, et les plugins cœur et les APIs continueront d'évoluer. Déclaration officielle : "core plugins and APIs are expected to continue evolving".

Quatre modes d'exécution :

• Standard : agent de codage complet, exposant tout le jeu d'outils ;
• Code : expose le Code Mode SDK ; le modèle génère du TypeScript pour orchestrer les appels d'outils ;
• Minimal : uniquement les outils bash + str_replace_editor, pour le benchmarking ;
• Creator : construit des presets personnalisés, inspecte le runtime, teste des plugins, écrit des presets.

La vue Trajectory supporte resume / fork / search / replay, toutes basées sur le log de session append-only — ce qui fait écho à la description §1.2.2 d'un harness d'agent auto-évolutif (forkable, reproductible, capable de servir des requêtes en continu).

Implications pour les autres Agent Runtimes

[Évaluation personnelle] Les implications de cette architecture pour des Agent Runtimes comme DeepSeek Harness, Claude Code, Codex, OpenClaw, etc. :

• Remplacement à chaud des Tools : remplacer un outil pendant que l'Agent tourne, sans redémarrer la session ;
• Isolation des sous-Agents : ctx.isolate donne à chaque sous-Agent une vue de dépendances indépendante ;
• Déclaration de capacité = permission : fiber.inject est la liste de demande de capabilities et peut être auditée au chargement ;
• Trajectory = Emission : le log de session append-only est une emission (§6.1) et ne peut être réverti automatiquement ; supporter resume/fork/replay exige encore un design de compensation au niveau emission ;
• Plugins non fiables : ont toujours besoin d'un sandbox processus/conteneur/WASM ; Cordis ne fournit que l'isolation au niveau langage.

Mais notez : l'article est le modèle théorique de Cordis v4, et DeepSeek Harness est un produit en Developer Preview construit sur Cordis. La relation est "DSH est construit sur Cordis, et Cordis implémente le modèle du papier", et non "DSH a déjà prouvé toutes les conclusions du papier". Voir Limites et force de l'évidence.