DeepSeek Harness, plongée dans l'architecture : les effets réversibles et les co-effets réactifs de Cordis, et les détails mécaniques des quatre modes d'exécution

En bref : le « tout est un plugin » de DeepSeek Harness (DSH) n'est pas un slogan — il repose sur un runtime de plugins avec des années d'historique, un article scientifique derrière lui et des preuves formelles. Ce runtime s'appelle Cordis. DSH le « vend » (copie au niveau du code source) dans son monorepo, le renomme @deepseek-ai/cordis, version 4.0.0-rc.7. Il existe pour résoudre le problème le plus contre-intuitif des systèmes de plugins : charger est facile, décharger est un enfer. La plupart des frameworks savent attacher les fonctionnalités d'un plugin ; très peu savent le retirer proprement sans redémarrer l'hôte. Cordis répond avec deux concepts — et ces deux concepts sont exactement les « effets réversibles » et les « co-effets réactifs » du titre. Tous les faits sont datés du 14 août 2026 et tirés du dépôt DSH (deepseek-ai/deepseek-harness) : docs/cordis-primer.md, docs/architecture.md, les quatre fichiers de configuration des presets, et l'article Cordis.

D'abord une note de discipline sur les sources, car elle décide de ce qui compte comme « écrit dans le code » par opposition à « inféré ». Confirmé (textuellement dans le dépôt) : les cinq concepts fondamentaux de Cordis, la sémantique du cycle de vie effect/disposer/fiber, la stratification profile/bundle/patch de DSH, les clés ctx des paquets cœur, et le contenu ligne par ligne des preset.yml et agent.cordis.yml des quatre presets. Issu de l'article, cité avec attribution : les définitions précises des « effets réversibles » et des « co-effets réactifs » (elles viennent du preprint A Programming Paradigm for Spatiotemporal Composability, une collaboration entre l'université de Pékin et l'équipe DeepSeek-AI Harness, brouillon daté du 13 août 2026, ~88 pages). Signalé comme incertain là où c'est le cas. Comme toujours sur ce site : mieux vaut écrire « non vérifié » qu'inventer un détail qui a l'air plausible.

1. Pourquoi « tout est un plugin » mérite encore un cran

Notre article précédent définissait « tout est un plugin » ainsi : dans DSH, l'adaptateur de modèle, le registre d'outils, le journal de session, la sandbox, le stockage, l'ordonnanceur, l'UI, et même la boucle d'agent elle-même sont tous des plugins montés sur Cordis — et pour étendre DSH, on ne touche pas au code source, on « monte de nouveaux plugins à côté des autres ». C'est exact, mais cela ne répond qu'au « quoi », pas au « pourquoi ». La question qui suit naturellement : pourquoi les plugins peuvent-ils être échangés, débranchés à chaud et ordonnés automatiquement par dépendance ? S'il s'agissait juste de « découper le code en modules puis de les require un par un », ce ne serait pas différent des systèmes de plugins d'il y a dix ans, et DeepSeek n'aurait aucune raison de citer Cordis nommément.

La réponse est que Cordis n'offre pas de la « modularité » mais de la composabilité — selon deux dimensions orthogonales : temporelle (quand un composant est retiré, toute trace qu'il a laissée peut être précisément annulée) et spatiale (un composant privé de ses dépendances reste en attente jusqu'à ce qu'elles soient prêtes). Tenez les deux dimensions, et vous pouvez faire du modèle lui-même un plugin interchangeable — échanger l'adaptateur de modèle sous les mêmes sessions, outils et système de permissions, sans redémarrage ni reconstruction du contexte. C'est la différence la plus profonde avec Claude Code / Codex et leur approche « modèle + produit » intégrée verticalement.

2. Ce qu'est Cordis : filiation, l'article, et le vendoring dans DSH

D'abord, une correction à une lecture probablement erronée : Cordis n'est pas une roue que DeepSeek aurait montée pour DSH. Son auteur est shigma, créateur de Koishi, le framework de chatbot multiplateforme open source (nommé d'après un personnage de Touhou Project, ~6 000 étoiles GitHub). Cordis tourne en production depuis environ quatre ans comme socle de Koishi, éprouvé par plus de 4 000 plugins communautaires. Koishi tournait sur Cordis v3 ; l'aperçu développeur de DSH embarque Cordis v4 — le jour même de la publication de l'article. Autrement dit, DeepSeek a choisi un framework malmené par de vrais utilisateurs pendant quatre ans, pas un prototype de laboratoire — un point que la documentation et l'article soulignent tous deux comme preuve que Cordis est éprouvé, pas expérimental.

L'article s'appelle A Programming Paradigm for Spatiotemporal Composability. Sa question centrale : les systèmes de plugins modernes ne savent pour la plupart pas vraiment débrancher un plugin. Il cite nommément VSCode — 87 des 100 premières extensions du marketplace contiennent du code exécutable impossible à désinstaller à l'exécution sans redémarrer l'hôte d'extensions. Pour un harness d'agents auto-évolutif, la douleur est amplifiée : un agent peut générer, installer et remplacer ses propres outils à l'exécution, et un redémarrage détruit le contexte et le cache accumulés. Cordis vise exactement cela.

Regardez ensuite comment DSH « acquiert » Cordis — c'est très révélateur de l'attitude de DeepSeek. Plutôt que de dépendre de Cordis via npm, DSH vend au niveau du code source Cordis et ses bibliothèques de base (cosmokit, schemastery, loader, include, group, timer, hmr, etc.) dans son monorepo, en les renommant dans le scope @deepseek-ai (cordis → @deepseek-ai/cordis, @cordisjs/plugin-* → @deepseek-ai/cordis-plugin-*). La raison officielle est brutale : « pour que le harness possède entièrement sa couche framework (auditable, patchable, épinglée) ». Le répertoire vendor tient aussi un « journal des modifications locales » consignant chaque divergence avec l'amont — par exemple, trois correctifs de durcissement de la réentrance du cycle de vie des fibers, et un rechargement à chaud transactionnel pour le Loader/Include. Cette posture « tenir aussi la couche framework » correspond à l'habitude de DeepSeek : « d'abord faire tourner en interne, ensuite publier ».

3. Les cinq concepts fondamentaux de Cordis

Le primer officiel (docs/cordis-primer.md) condense Cordis en cinq idées. Elles fondent tout ce qui suit et méritent d'être dépliées une à une, car elles correspondent à cinq verbes : monter, trouver, attendre, signaler et annuler.

• Un plugin est un objet qui implémente Service. Ce peut être une fonction avec des champs optionnels inject et apply(ctx), ou une sous-classe Service dont Cordis monte le cycle de vie dans le contexte courant. Notez la forme « objet/fonction » : aucune classe de base requise, donc un plugin peut être une ligne de config YAML ou une fonction inline dans le code.
• Un contexte est un référentiel de services. Un service occupe un emplacement stable ctx.<key> comme ctx.tools, ctx.llm ou ctx.sessions ; les autres plugins trouvent les services par clé au lieu d'importer une implémentation concrète. C'est la racine des « modèles interchangeables » — un consommateur sait seulement qu'il y a un ctx.llm, jamais si c'est DeepSeek ou OpenAI derrière.
• Déclarer la dépendance de service via inject. Un plugin qui nomme les services requis attend qu'ils existent, donc l'ordre de chargement s'exprime par les besoins de service plutôt que par un séquençage manuel du démarrage. Cela mène directement aux « co-effets réactifs » de la section suivante.
• Des événements typés pour communiquer. Les services déclarent des noms d'événements par fusion de déclarations TypeScript, puis les distribuent en emit (observer), waterfall (envelopper), parallel (répartir) ou serial (exécuter dans l'ordre). Les événements sont les points d'extension — la source technique du « les événements sont des points d'extension » de DSH.
• Les enregistrements sont des effets réversibles. Sections de prompt, schémas d'outils, adaptateurs, fournisseurs et écouteurs sont installés via ctx.effect() ou ctx.on() afin que le rechargement et le démontage les défont de façon prévisible. Celui-ci est l'âme du framework — les deux sections suivantes lui sont consacrées.

4. Les deux termes clés : effets réversibles et co-effets réactifs

Une correction terminologique s'impose ici, car ces deux mots sont malmenés en traduction alors qu'ils sont la contribution centrale de l'article. Les deux concepts du titre correspondent aux originaux anglais de l'article comme suit :

Chinois	Original anglais	Problème résolu
可逆效应	Revertible Effects	Composabilité temporelle
反应式余效应	Reactive Coeffects	Composabilité spatiale

Commençons par les effets réversibles (Revertible Effects). L'article les définit strictement : chaque transformation d'un contexte doit porter une fonction inverse explicite suivie par le runtime ; décharger un plugin exécute cette « chaîne d'annulation » dans l'ordre inverse d'enregistrement, restaurant le système précisément à son état d'avant chargement. En termes de code quotidien : chaque enregistrement renvoie un disposer, et le framework l'exécute pour vous au déchargement. « Réversible » n'est pas de la rhétorique — c'est une promesse adossée à une sémantique opérationnelle, et l'article prouve une propriété de confluence : l'état final ne dépend pas de l'ordre des chargements et déchargements.

Passons au plus intéressant : les co-effets réactifs (Reactive Coeffects). C'est là que les traductions se trompent le plus souvent : ce n'est pas « reactive effects », mais coeffect — le dual de l'« effect » des systèmes d'effets de la théorie des types. Un système d'effets demande « quels effets de bord ce code produit-il ? » ; un système de coeffets demande l'inverse : « de quoi ce code a-t-il besoin de la part de son environnement ? » Reporté sur Cordis : un composant déclare les dépendances dont il a besoin (disons qu'un plugin de chat a besoin d'un adaptateur de messages et d'une base de données) ; tant qu'elles ne sont pas toutes satisfaites, il reste INACTIF ; une fois prêtes, son cycle de vie (activate / deactivate / neutral) est piloté réactivement par le changement d'environnement. Voilà d'où vient le « réactif » — et c'est la base théorique des déclarations inject de la section précédente.

L'élégance de l'article est d'unifier ces deux notions — normalement issues de deux corpus théoriques distincts — en un seul type de contexte, formant ce qu'il appelle le « paradigme du contexte ». Il donne une sémantique opérationnelle à 10 règles et prouve quatre propriétés métathéoriques : préservation, composabilité spatiotemporelle globale, progression et confluence. Cet article relaie ces termes sans les redériver — ils appartiennent à la moitié formelle du preprint de 88 pages. La leçon pour un lecteur général tient en une phrase : Cordis est un mécanisme où « le déchargement est totalement annulable » et « n'activer que lorsque les dépendances sont prêtes » sont vrais en même temps.

5. La mécanique des effets : disposer, fiber, démontage en ordre inverse

À quoi ressemble la théorie dans le code ? Le chapitre 2 du tutoriel Cordis (docs/cordis-tutorial/02-lifecycle-and-effects.md) donne la réponse la plus directe : un plugin peut être déchargé par une modification de config, un rechargement à chaud, une libération explicite ou la perte d'un service requis. Les enregistrements faits via les API Cordis sont des effets et sont défaits quand leur plugin propriétaire se décharge ; les ressources gérées hors de ces API (un timer, une connexion, un watcher de fichiers) doivent être enveloppées dans ctx.effect() et renvoyer un disposer. L'extrait canonique :

ctx.effect(() => {
  const timer = setInterval(() => console.log('tick'), 200)
  return () => {            // ← voici le disposer
    clearInterval(timer)
    console.log('cleaned up')
  }
})

Cela révèle les deux mouvements clés du modèle d'effets : le corps de l'effet s'exécute pendant le chargement ; le disposer qu'il renvoie s'exécute pendant le déchargement ; et pour une ressource à durée de vie de plugin, vous n'appelez jamais le disposer vous-même — le framework l'exécute au déchargement. De plus, les API d'enregistrement intégrées sont déjà des effets : ctx.on(event, listener) retire l'écouteur au déchargement, ctx.plugin(child) libère l'enfant avec son parent, et les enregistrements de service (comme ctx.tools.register(...)) attachent leurs disposers retournés au plugin appelant automatiquement. Les cas où vous écrivez vraiment ctx.effect() à la main sont donc rares — la plupart du temps vous enregistrez, et l'annulation est gratuite.

Il y a un piège d'ordre à signaler, et la doc le met en gras : les disposers démarrent dans l'ordre inverse d'enregistrement, mais plusieurs disposers asynchrones s'exécutent en parallèle. Si vos étapes de démontage doivent s'exécuter en séquence stricte, mettez-les dans un seul disposer et attendez-les là. C'est le visage ingénierie de la « chaîne d'annulation » : dernier enregistré, premier démonté, comme une pile d'assiettes qu'on prend par le haut — l'atterrissage concret du « réversible ».

Un cran plus bas se trouve la fiber. Chaque instance de plugin chargée possède une fiber (un handle d'exécution) qui traverse cette machine à états :

PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED
                 ↘ FAILED

• PENDING — déclaré, mais un service injecté n'est pas encore disponible. C'est le visage à l'exécution des « co-effets réactifs » : un plugin qui attend ses dépendances.
• LOADING / ACTIVE — apply est en cours / a fini.
• FAILED — apply ou la validation de config a levé une exception.
• UNLOADING / DISPOSED — les disposers s'exécutent / tout est démonté.

Le tutoriel ajoute un diagnostic pratique : si un plugin « n'imprime rien », la réponse est généralement qu'il est coincé en PENDING — à attendre une dépendance qui n'est jamais venue. Et fiber.dispose() ne se résout qu'après que tout le nettoyage du plugin (y compris les disposers asynchrones) est terminé, déchargeant récursivement chaque plugin enfant qu'il a monté. Ensemble, ces deux points referment la boucle du « débrancher à tout moment » : le chargement est une attente déclarative, le déchargement est récursif, en ordre inverse et attendable.

6. Comment DSH utilise Cordis : arbre de plugins, seams, « pas de noyau privilégié »

Avec cette base, le document d'architecture de DSH (docs/architecture.md) se lit sans heurts. Sa phrase d'ouverture : Cordis est le framework sous dsh — « les plugins contribuent des services, des événements typés et des effets de bord réversibles à un contexte partagé », et chaque partie du produit est un plugin — l'adaptateur de modèle, le registre d'outils, le journal de session et la boucle d'agent elle-même — donc chaque partie peut être remplacée depuis la config. Il n'existe aucun noyau privilégié à patcher : étendre dsh signifie monter des plugins à côté d'autres plugins.

Un dsh en cours d'exécution est un arbre de plugins, composé de couches appliquées dans l'ordre au démarrage :

Concept	Rôle
Profile	Un assemblage nommé dans le home du Harness : liste ses bundles, contient les plugins hors-arbre, garde le cordis.patch.yml de l'utilisateur ; web et headless sont livrés comme modèles
Bundle	Le format de distribution d'une entrée de config Cordis plus son code de montage ; les couches supérieures peuvent toujours le patcher
dsh-base	La première couche de chaque profile : adaptateurs de modèle, outils, persistance, sandbox & politique d'approbation, réglages, identifiants, télémétrie
Couches de patch	patch du profile → patch du home → tout overlay --patch, appliqués dans l'ordre

Les couches s'appliquent sur une liste d'entrées vide dans cet ordre : chaque bundle dans l'ordre listé par le profile, puis le cordis.patch.yml du profile, puis celui du home, puis tout overlay --patch. Un patch localise une entrée par id et remplace sa config entière, ou insère une nouvelle entrée. Vous pouvez imprimer l'arbre de config exact que votre machine démarrerait via dsh --profile web --dump-config — et toute entrée qu'il imprime peut être remplacée par votre propre patch. C'est ce que « composable » veut dire côté utilisateur : pas « modifier le source », mais « empiler un patch de plus ».

Les paquets cœur contribuent des services (clés ctx) à cet arbre, selon le tableau du document d'architecture :

Paquet	Responsabilité	clé ctx
core/session	Journal append-only de SessionEvent et stockage en mémoire	ctx.sessions
core/system-prompt	Assemblage des sections de prompt et des schémas d'outils	ctx.systemPrompt
core/tools	Registre d'outils scopé + pipeline d'exécution gardé	ctx.tools
core/agent	L'interface Agent, le registre des agents actifs et les événements agent/*	ctx.agents
core/agent-loop	Le pilote par défaut implémentant l'interface Agent	ctx.agentLoop
llm/llm	Vocabulaire message/streaming et le seam d'adaptateurs	ctx.llm

Le mot le plus éclairant de ce tableau est seam. DSH définit un seam comme « une capacité interchangeable » à trois rôles : une Service Definition (déclare l'interface, possède son propre ctx.<key> et son type de vocabulaire), un ou plusieurs Service Providers (l'implémentent), et un ou plusieurs Consumers (typiquement des outils orientés modèle) qui l'injectent. Prenons packages/shell : dsh-shell est la Service Definition, dsh-bash-local / dsh-bash-sandbox sont les fournisseurs, et dsh-tool-bash est le Consumer. Les fournisseurs de système de fichiers et de processus partagent le même « monde d'exécution », donc pointer leur seam vers une sandbox distante y déplace aussi Bash, PTY et LSP — sans fork spécifique au fournisseur. C'est le mécanisme par lequel « échanger un fournisseur change tout le produit », et pourquoi DSH peut dire « le modèle est un plugin » si naturellement.

Les événements sont de trois sortes — le document d'architecture insiste : « les événements sont des points d'extension » : les événements de session sont des faits persistants ajoutés au journal et diffusés via session/event ; les événements d'agent (agent/*) portent l'Agent actif, pour observer ou intercepter le travail en cours ; les événements de capacité attachent politiques et adaptateurs aux seams comme fs/*, tools/*, telemetry/* sans cycles d'import. Et un invariant est martelé : « visible par le modèle ⇔ enregistré » — tout ce qui atteint une requête modèle doit être reconstituable depuis le journal de session, imposé par une assertion à l'exécution. La compaction de contexte utilise des événements de remplacement ; l'historique original n'est jamais supprimé. L'intérêt de l'invariant : il rend le « réversible » applicable non seulement à l'assemblage des plugins, mais à chaque pas du comportement de l'agent — débogage, audit et relecture partagent le même flux d'événements.

7. Les quatre modes en détail : Standard / PTC(Code) / Minimal / Création

Avec la base « tout est un plugin » de Cordis, les « modes d'exécution » découlent naturellement : ce ne sont pas des branches codées en dur mais quatre presets d'agent livrés. L'article précédent définissait un preset comme « l'assemblage de plugins qu'un agent exécute » ; celui-ci plonge dans les fichiers de config de chaque preset (apps/cli/config/agent-presets/*/preset.yml et agent.cordis.yml) pour voir exactement ce que chacun active et désactive. D'abord un tableau récapitulatif, puis un par un.

Répertoire	Nom affiché	Description (textuelle depuis preset.yml)
standard	Standard	L'agent de code complet : édition de fichiers, shell, recherche fichier & web, skills, plan, objectifs, sous-agents et workflows.
code	PTC / Code	Tout le mode standard, plus une présentation des outils via le Code Mode SDK pour que le modèle compose des opérations multi-étapes avec un programme TypeScript.
minimal	Minimal	Un agent de code à deux outils : bash persistant et str_replace_editor uniquement.
cordis	Création	Pour créer des presets d'agent personnalisés : tout le mode standard, plus inspection à l'exécution, expérimentation de plugins et guide de création de presets.

Notez un détail facile à manquer mais riche d'information : les noms de répertoire des quatre presets sont standard / code / minimal / cordis, tandis que les noms affichés sont « Standard / PTC / Minimal / Création ». « PTC » est donc le nom d'affichage côté chinois ; son id de répertoire est code et son nom de mécanisme anglais est Code Mode. Le dépôt ne développe pas lui-même l'abréviation « PTC » (aucun nom complet nulle part), donc cet article décrit le mécanisme et se refuse à inventer une expansion. De même, l'id de répertoire du mode « Création » est cordis — nommé d'après le framework lui-même, ce qui est en soi un indice.

Standard : un agent de code complet « monté une fois, rejoint plusieurs fois »

Le agent.cordis.yml du preset standard s'ouvre sur : c'est l'agent de code complet, « monté une fois par processus ». Ce « une fois » est délibéré — c'est un scope permanent (standing scope) : le roster le monte une fois, et chaque session qui le nomme le rejoint par parenté de scope, de sorte que les outils et sections de prompt enregistrés ici couvrent chaque agent rejoint, tandis que l'état propre d'une session reste isolé par Session/Agent à l'intérieur des plugins. C'est la primitive scope de tout à l'heure : une contribution est soit globale (visible par tous les agents), soit scopée (appartenant à exactement une clé de scope).

Ce qu'il active, d'après les lignes de config : shells bash / pwsh, système de fichiers (fs + fs-search), tâches d'arrière-plan, skills, objectifs, mode plan, compaction de contexte, délégation et workflows (subagent / subagent_fork / workflow / ralph), ask_user, todo et recherche web. Deux lignes marquées disabled: true sont particulièrement révélatrices : tool-subagent-codex et tool-subagent-claude-code. DSH embarque donc des fournisseurs de produit « déléguer un sous-agent à Codex / Claude Code », mais désactivés par défaut ; copiez le preset, retirez disabled d'une ligne, et seul votre agent gagne la capacité de « sous-traiter un sous-agent à un produit concurrent ». La note de bas de page la plus concrète du « tout est un plugin » : même « sous-traiter à un concurrent » est une ligne de plugin activable.

PTC / Code : laisser le modèle écrire un programme TypeScript et réduire N allers-retours à un

Le mode Code est le plus « mécanisme » des quatre. Son agent.cordis.yml s'ouvre clairement : tout le mode standard est inchangé ; le seul ajout est une ligne tool-presentation (@deepseek-ai/dsh-agent-tool-presentation, mode: code). L'effet : au lieu d'un appel d'outil par action, le modèle écrit un programme TypeScript contre un SDK généré et run_code l'exécute — ainsi une séquence qui aurait pris cinq allers-retours n'en prend qu'un.

Un détail très « Cordis » mérite d'être isolé : le commentaire de config souligne que le registre lui-même reste sur le plan host — le planificateur de la boucle d'agent et les presenters du proxy API en sont les consommateurs ; ce que ce preset possède, c'est seulement la présentation de ce registre pour ce seul agent. Des sessions natives tournent à côté de lui dans le même processus, chacune voyant son propre catalogue. Autrement dit, le mode Code ne change pas la « capacité » ; il change la « présentation de la capacité » — représenter N appels d'outils fins comme une interface de « composition programmable ». Il recoupe la façon dont Claude Code appelle les outils un par un et dont Codex laisse le modèle écrire des scripts, mais DSH en fait un interrupteur de preset plutôt qu'une forme intrinsèque du produit.

Minimal : deux outils, construit pour « mesurer le modèle équitablement »

Minimal est le plus dense des quatre, car sa raison d'être n'a rien à voir avec le « poli du produit » et tout à voir avec un benchmarking équitable. Sa première ligne de commentaire : a fixed-prompt, two-tool coding-agent composition. Sa persona est le prompt système complet (complete: true) — l'identité globale, l'orientation Web, le guidage des outils et tout écouteur d'assemblage ultérieur ne peuvent pas ajouter de texte de prompt ; les instantanés de contexte d'exécution sont supprimés (includeRuntimeContext: false) ; le modèle ne compose que deux outils — bash persistant et str_replace_editor ; et la compaction de contexte est absente.

Pourquoi cette combinaison est-elle « pour le benchmarking » ? Parce que quand on compare la capacité d'agent de deux modèles, toute différence d'ingénierie de prompt, de richesse d'outils ou de stratégie de compaction devient un facteur de confusion. Minimal épingle tout : le même prompt en deux phrases, les deux mêmes outils, le même contexte sans compaction — la seule différence restante est le modèle lui-même. L'article précédent notait que « DeepSeek-V4-Flash GA utilise le mode minimal de DeepSeek Harness comme framework de test » ; le mécanisme est désormais clair : DeepSeek l'utilise pour garder la variable « environnement d'exécution » sous contrôle dans ses propres benchmarks d'agents — ce qui signifie aussi que les scores officiels mesurent toujours « le modèle dans cet environnement contrôlé », pas la capacité brute du modèle. Ce site a déjà signalé cela comme « à relayer mais à traiter comme non vérifié » ; cet article en ajoute le « pourquoi » au niveau mécanique.

Création (cordis) : un agent capable de lire et écrire son propre runtime

La Création est le plus radical et autoréférentiel des quatre. Son agent.cordis.yml s'ouvre : the standard coding agent, plus the ability to read and write the runtime it is running in. Son but déclaré, selon les mots mêmes de la doc : pour qu'une personne puisse demander à un agent d'en créer un autre. Tout le mode standard est inchangé ; s'y ajoutent une boîte à outils Cordis autoréférentielle (dsh-tool-cordis, dont cordis_mount évalue du JavaScript écrit par le modèle contre le runtime vivant), une skill qui enseigne la création de compositions (editing-cordis-compositions), et une persona expliquant les « deux plans ».

« Deux plans » mérite un développement, car c'est le modèle mental clé de toute l'architecture DSH : le plan HOST détient les registres eux-mêmes et tout ce qui est partagé entre sessions — la persistance, la sandbox et la pile d'approbation, la route du modèle, le registre de sous-agents et ses backends ; le plan AGENT PRESET détient ce qu'une session contribue à ces registres — ses outils, sa persona, ses sections de prompt. Une ligne qui publie un service appartient au plan host, ou à l'intérieur d'un realm isolate quand le preset possède réellement ce service et que rien hors d'un agent ne le lit. Cette distinction « quelle ligne va sur quel plan » est exactement ce que la skill enseigne au modèle.

Le plus sérieux est la frontière de sécurité. L'en-tête de config du preset Création porte un avertissement TRUST en majuscules : cordis_mount évalue du JavaScript écrit par le modèle contre le runtime vivant, et une composition écrite par cet agent devient un preset que d'autres sessions montent — « traitez une session sur ce preset comme un accès shell ». Autrement dit, le mode Création n'est pas une sandbox ; c'est une frontière de confiance. Laisser un modèle modifier son propre assemblage de runtime dans des conditions contrôlées, dans un v0.1 fraîchement publié, est agressif — et c'est l'extension naturelle de la ligne « l'agent comme infrastructure » ; la doc prévient aussi explicitement de changements cassant la compatibilité à venir, donc traitez-le avec prudence en production.

8. Conclusion : ce que tout cela veut vraiment dire

Assemblez les quatre modes avec la mécanique de Cordis et l'image complète de DSH se met au point : ce n'est pas « un produit agent avec un système de plugins » — c'est « un runtime qui assemble des produits agents à partir d'un système de plugins ». Standard / PTC / Minimal / Création sont quatre presets du même assemblage Cordis : Standard est la forme complète, PTC échange la présentation des outils, Minimal épingle toutes les variables pour mesurer le modèle, et Création transforme « modifier le runtime » en un outil. Les quatre ne diffèrent que par les lignes de plugin activées / désactivées / échangées — pas une seule branche codée en dur.

Pour les lecteurs de ce site, trois enseignements pratiques. D'abord, le modèle est un plugin, un seam — vous pouvez donc pointer le ctx.llm de DSH vers l'endpoint compatible OpenAI d'un relais en Chine continentale et le piloter avec DeepSeek V4 Pro / V4 Flash. C'est la même chose que le câblage DEEPSEEK_BASE_URL / interface Web / settings.yaml de l'article précédent, sauf que vous savez maintenant pourquoi c'est si fluide : vous n'échangez pas un « modèle » codé en dur mais un plugin adaptateur enregistré de façon réversible. Ensuite, le mode minimal est la « variable contrôlée » des benchmarks officiels — quand vous voyez un titre « DeepSeek écrase X », demandez d'abord : dans quel mode, sous quel harness ? Enfin, le mode Création est une frontière de confiance, pas une sandbox — en v0.1, ne le laissez pas tourner en liberté dans un environnement de production qui détient de vrais identifiants.

Une note d'honnêteté pour finir : les définitions formelles des « effets réversibles / co-effets réactifs » sont relayées depuis l'article et le primer officiel, pas une revérification formelle indépendante par ce site ; et les modifications locales de DSH à Cordis (durcissement des fibers, rechargement à chaud transactionnel) proviennent du « journal des modifications locales » du répertoire vendor, c'est-à-dire le récit officiel. Les deux méritent d'être vérifiés à la source avant de s'y appuyer. Au-delà, chaque description des quatre presets de cet article est tirée directement du texte et des commentaires des preset.yml et agent.cordis.yml du dépôt — sans risque à traiter comme « les faits de la version actuelle ».