DeepSeek Harness (dsh) en 2026 : architecture, modes, versions et évaluation sûre

Mis à jour le 13 septembre 2026 ; ce guide s’appuie sur dsh-v0.1.5-rc.2.

DeepSeek Harness (dsh) mérite d’être évalué comme runtime d’agent, mais la réponse actuelle à « est-il assez stable pour la production ? » est non. DeepSeek le qualifie de logiciel en préversion pour développeurs, avertit que des changements incompatibles se produiront et indique qu’il n’a pas subi d’audit de sécurité ni reçu la désignation prêt pour la production. Cela ne rend pas dsh inintéressant. Cela indique comment l’utiliser : épinglez ce que vous évaluez, isolez ce qu’il peut atteindre et mesurez votre propre charge avant de lui confier des fichiers ou identifiants de valeur.

Ce guide explique l’architecture, sépare les modes visibles par l’utilisateur des profils CLI et montre un parcours d’évaluation reproductible. Il reflète le tag de dépôt et la page de version dsh-v0.1.5-rc.2, vérifiés le 13 septembre 2026. La documentation d’une branche mobile peut contenir du travail absent de la version que vous installez.

Qu’est-ce que DeepSeek Harness ?

Le dépôt officiel présente dsh comme un harness d’agent open source développé par DeepSeek AI. Un modèle fournit le raisonnement ; le harness fournit le runtime autour de lui : adaptateurs de modèles, outils, sessions, accès au système de fichiers et aux sous-processus, politique d’approbation, réglages et boucle d’agent.

La conception repose sur Cordis et son modèle « tout est plugin ». Dans la documentation d’architecture de ce tag, les plugins ajoutent des services, événements typés et effets réversibles à un contexte partagé. L’adaptateur de modèle, le registre d’outils, le journal de session et la boucle d’agent sont tous remplaçables. Un profil compose ensuite des bundles et fichiers de patch dans un ordre défini.

Cette distinction est concrète. Vous pouvez changer de fournisseur ou ajouter une capacité via le profil et ses patchs plutôt que de forker tout le runtime. Cela ne signifie pas que chaque composant peut être échangé sans risque pendant toute tâche, ni qu’une défaillance de plugin est isolée de toutes les données accessibles au processus. L’avis de sécurité de ce tag indique que les commandes générées par le modèle et les plugins tiers peuvent atteindre les fichiers, processus, réseau et identifiants mis à leur disposition.

Pourquoi le journal de session importe

dsh enregistre des événements de session durables dans un journal ajout-only. Les documents d’architecture désignent le journal comme la source dont est dérivé l’historique du modèle et précisent que l’entrée visible du modèle doit pouvoir être reconstruite depuis lui. La page officielle de DeepSeek décrit aussi replay, reprise, recherche et fork comme des opérations sur le même flux d’événements.

Cela donne au développeur davantage qu’une vague fonction de « mémoire » : une trace de ce qui a été montré au modèle et des événements d’outil validés. Cela ne garantit toujours pas un résultat déterministe. Le modèle, la réponse du fournisseur, l’environnement des outils, l’ensemble des plugins et les systèmes externes peuvent tous influencer l’exécution suivante. Considérez le journal comme une aide d’audit et de débogage, puis validez le comportement nécessaire.

Les changements de format de session affectent aussi la planification des mises à niveau. Les notes de version v0.1.5-rc.1 décrivent une migration vers le format V3. Les anciens journaux pris en charge sont migrés dans une nouvelle version en conservant l’original, mais les notes précisent qu’une session mise à niveau ne peut pas être lue par une version rétrogradée. Autrement dit, revenir en arrière sur l’exécutable ne revient pas à revenir en arrière sur les données de session. Copiez le répertoire Harness et testez la migration sur des sessions jetables avant de mettre à niveau un espace de travail précieux.

Les quatre modes visibles par l’utilisateur

La page Harness officielle de DeepSeek nomme quatre modes. Ils décrivent la manière dont l’agent est présenté à l’utilisateur :

Mode	Ce que dit la description officielle	Bonne question d’évaluation
Standard	Agent de codage complet avec édition de fichiers, Shell, récupération de fichiers et Web, Skills, plans, objectifs, sous-agents et workflows.	La politique d’approbation et d’outils peut-elle contenir les tâches prévues ?
PTC	Capacités Standard exposées via le SDK Code Mode, afin que le modèle compose plusieurs opérations d’outil dans un programme TypeScript.	Le traitement par lots améliore-t-il votre workflow sans rendre la revue plus difficile ?
Minimal	L’aperçu produit officiel décrit bash persistant et `str_replace_editor`.	Une surface d’outils petite et explicite peut-elle accomplir la tâche à benchmarker ?
Creator	Mode pour inspecter le runtime, expérimenter des plugins Cordis en mémoire et créer des préréglages d’agent personnalisés.	Pouvez-vous prototyper un préréglage sans le traiter comme une politique de production ?

L’ancien libellé « Code Mode » est facile à mal interpréter. La description produit officielle appelle ce mode PTC et explique qu’il utilise le SDK Code Mode. Ce n’est pas un profil runtime distinct et largement documenté appelé code.

L’aperçu produit et les profils rc.2 fournis utilisent « Minimal » à des niveaux différents. Dans la référence du comportement CLI rc.2, le préréglage Web minimal ne compose que le shell persistant de la plateforme ; les autres plugins visibles par le modèle sont absents. str_replace_editor exige donc une activation explicite dans ce profil Web. Les notes de version rc.1 indiquent le même défaut pour Web minimal et Python sdk-minimal. La note existante du guide Python ci-dessous couvre son arbre sdk-minimal distinct et son éditeur facultatif. N’inférez pas l’éditeur de la seule présentation des quatre modes.

Les modes et profils CLI sont des couches différentes

La ligne de commande possède son propre modèle de profils. La référence CLI @deepseek-ai/dsh pour rc.2 indique que dsh est le lanceur d’application Node pris en charge et liste ces profils fournis :

Entrée CLI	Rôle
`dsh web`	Interface Web ; alias de `dsh --profile web`.
`dsh --profile headless "job"`	Une session fraîche persistée qui imprime sa réponse finale puis quitte.
`dsh --profile sdk`	Serveur JSON-RPC pour clients SDK sur stdio.
`dsh --profile sdk-minimal`	Serveur SDK avec l’arbre d’agent minimal autonome.
`dsh --profile acp`	Clients d’automatisation sur ACP stdio.

Les profils sont des couches ordonnées de bundles de plugins. Le profil Web peut utiliser le rechargement à chaud des patchs ; headless, SDK, SDK-minimal et ACP appliquent leurs couches au démarrage car remplacer des dépendances après qu’une application one-shot ou stdio possède le travail invaliderait son cycle de vie. Un nom de profil indique donc comment dsh démarre et compose son runtime. Il ne correspond pas un-pour-un aux quatre modes produit.

Le guide Python SDK rc.2 rend la distinction encore plus importante. Son exemple sdk-minimal utilise un arbre autonome avec shell persistant, sans contexte runtime ni compaction, et des journaux de session JSONL non compressés. str_replace_editor est facultatif pour ce profil. Le guide qualifie aussi le profil de danger-full-access pour les chemins visibles, d’où son appel à un espace isolé ou conteneur. Une liste d’outils plus courte n’est pas automatiquement une frontière de sécurité plus forte.

Ce qui a changé dans les dernières versions

Sur la page de version vérifiée, le candidat est v0.1.5-rc.2, tagué dsh-v0.1.5-rc.2 et marqué Pre-release. GitHub l’affiche comme publié le 10 septembre à 15:09. Les notes rc.2 contiennent des améliorations d’interface pour la soumission de feedback et les cartes de fichiers livrés.

Le candidat précédent v0.1.5-rc.1, publié le 10 septembre à 03:09, contient l’ensemble de changements plus important. Ses notes comprennent une nouvelle entrée d’adaptateur de modèle DeepSeek, les chargements de fichiers arbitraires, des contrôles de sous-agents poursuivables, les mises à jour dynamiques du prompt système lorsque le modèle déclare les prendre en charge, les améliorations de découverte de modèles, la gestion de l’environnement proxy, le format V3 de session, le verrouillage de session, les changements d’outils par défaut et de nombreuses corrections, dont la continuation d’appel d’outil en flux et le comportement de reconnexion Web.

Ces notes indiquent ce qui a changé. Elles ne fournissent ni pourcentage de disponibilité, ni taux d’échec, ni temps moyen de rétablissement, ni résultat de fiabilité de production. Une longue liste de corrections est une raison de lire les notes et d’exécuter des tâches de régression, pas une statistique de stabilité. Séparez aussi trois éléments dans votre test : la version et le tag GitHub sélectionnés, le commit master que vous avez pu inspecter et la version réellement installée dans votre environnement.

Une première évaluation sûre et reproductible

Utilisez un chemin source épinglé pour l’évaluation. Les commandes ci-dessous suivent le README rc.2 et la référence CLI rc.2. Ce sont des points d’entrée documentés, pas des commandes exécutées pour cet article.

Créez le checkout, un espace de travail unique et un nouveau répertoire Harness avant le premier lancement. L’exemple utilise la syntaxe shell POSIX et suppose Git, Node.js et pnpm déjà disponibles comme l’exige le README rc.2 ; il ne prescrit aucune version runtime non vérifiée :

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
git checkout dsh-v0.1.5-rc.2
pnpm install
pnpm run build
export DSH_HOME="$(mktemp -d)"
EVAL_WORKSPACE="$(mktemp -d)"
printf '%s\n' 'Disposable dsh evaluation workspace.' > "$EVAL_WORKSPACE/README.md"
printf 'DSH_HOME=%s\nEVAL_WORKSPACE=%s\n' "$DSH_HOME" "$EVAL_WORKSPACE"

Enregistrez les deux chemins absolus affichés dans vos notes d’exécution. Utilisez le chemin EVAL_WORKSPACE affiché dans le sélecteur de fichiers de l’interface Web, et collez le chemin DSH_HOME affiché dans tout second shell plutôt que d’attendre que ce shell hérite de la variable. Conservez DSH_HOME uniquement pour cette évaluation. C’est là que rc.2 crée fichiers de profil, réglages, références d’identifiants et sessions. L’espace temporaire est distinct du checkout source. N’y placez pas d’identifiants et retirez les fichiers sensibles de tout ce que le processus peut voir avant le démarrage. Si la tâche exige une isolation au niveau OS, placez ce checkout, ce répertoire et cet espace dans une VM ou un conteneur jetable ; un sélecteur d’espace dsh et une invite d’approbation ne fournissent pas cette frontière OS.

Démarrez l’interface Web depuis la racine source, en conservant le point d’entrée source :

pnpm dsh web --no-open

Le README rc.2 documente http://127.0.0.1:3080 comme adresse locale par défaut. Dans le navigateur, ouvrez Choose workspace et sélectionnez le chemin exact affiché plus haut. Ne laissez pas le checkout source devenir l’espace de tâche seulement parce qu’il était le répertoire d’invocation. Ouvrez ensuite Settings → Models, configurez un modèle et exécutez une tâche inoffensive qui ne touche ni secrets ni fichiers de production.

Une seconde frontière est à comprendre durant ce premier essai. En rc.2, les nouvelles sessions des profils appuyés sur base utilisent par défaut workspace-write : les mutations Bash et système de fichiers sont limitées à l’espace de session et aux racines temporaires de plateforme, tandis que les lectures et l’accès réseau ne sont pas confinés par ce préréglage. Les récupérations HTTP publiques activées s’exécutent sans invite d’approbation par appel. Les réglages de permission General enregistrés s’appliquent aux sessions Web ultérieures, pas à celle déjà ouverte. Vérifiez le réglage dans une nouvelle session après l’avoir changé. Ce sont des détails de politique dsh, pas une isolation OS ; gardez les ressources sensibles hors d’atteinte avant lancement.

Avant de démarrer un autre profil ou comparer un patch, inspectez la même composition avec le même checkout source et répertoire :

pnpm dsh --profile web --dump-config

Le processus Web occupe le premier terminal. Arrêtez le service et toute session active avant de copier le répertoire ou d’inspecter un état final ; si vous ouvrez plutôt un autre shell, exportez explicitement le chemin $DSH_HOME enregistré et revenez au checkout source avant d’exécuter la commande. La référence CLI rc.2 indique que ceci initialise les fichiers de profil manquants, imprime l’arbre composé et ne démarre pas l’application Web. Notez le tag, checkout source, profil, fichiers de patch, identifiant de modèle, $EVAL_WORKSPACE, $DSH_HOME et résultat de tâche. La CLI/l’aide et les notes de version décrivent le comportement ; elles ne prouvent pas que votre commande locale a réussi.

Configurez un modèle ou une passerelle avec soin

La page Models de l’interface Web prend en charge les fournisseurs intégrés et personnalisés. Le guide fournisseur rc.2 exige pour un fournisseur personnalisé un ID, une URL de base, un protocole API, un identifiant et au moins un modèle. Les noms de protocoles pris en charge sont openai-completions, openai-responses et anthropic-messages. La découverte de modèles n’est qu’une commodité : si un endpoint n’expose pas une forme de liste prise en charge, saisissez l’ID du modèle manuellement.

Une passerelle compatible OpenAI peut toujours rejeter une requête si sa forme diffère de celle envoyée par dsh. Le guide fournisseur souligne la compatibilité du rôle du prompt système et du champ de jetons de sortie, et précise que les déclarations d’image ou de raisonnement décrivent votre endpoint sans le tester. Considérez l’enregistrement réussi d’une clé comme un progrès de configuration, pas comme la preuve qu’une tâche réelle fonctionne.

Si vous évaluez Tokenhot comme route fournisseur, son Quick Start enregistré documente https://api.tokenhot.ai/v1 et l’authentification Bearer Token/API key pour la configuration API. Dans l’interface Web, utilisez Settings → Models → Add a custom provider, entrez cette URL documentée, choisissez le protocole que votre route Tokenhot sélectionnée expose réellement et ajoutez un ID de modèle vérifié. Les réglages fournisseur appartiennent à $DSH_HOME/settings.yaml de cette évaluation ; l’interface Web conserve l’identifiant dans $DSH_HOME/.credentials.yaml et seulement sa référence dans les réglages. Saisissez la clé par l’interface ou le mécanisme d’environnement documenté, jamais dans l’espace jetable ou le contrôle de source.

Utilisez openai-completions seulement lorsque la route Tokenhot sélectionnée documente ou confirme ce protocole. Vérifiez ID de modèle et forme de requête avec votre compte et votre charge. Les documents Tokenhot disponibles pour cet article n’établissent pas disponibilité actuelle des modèles, prix, latence, disponibilité ni requête dsh réussie ; cet exemple ne fait donc aucune telle promesse.

Vérifications de mise à niveau et retour arrière

Avant de passer d’un candidat à un autre, arrêtez le processus Web et toute session active, puis copiez le $DSH_HOME exact utilisé ci-dessus et l’espace jetable, en gardant les copies près de l’enregistrement de version. Ce répertoire contient profil, réglages, références d’identifiants et sessions qui rendent la comparaison reproductible. Lisez les notes de version pour les changements de format de session, outils par défaut, adaptateurs de fournisseurs et API de plugins. Exécutez la même petite tâche dans les environnements ancien et nouveau, puis comparez :

L’interface Web ou le profil headless peut-il démarrer avec l’espace et le modèle prévus ?
Les approbations d’outils apparaissent-elles là où votre politique les attend ?
La tâche peut-elle reprendre, et le journal contient-il les entrées visibles au modèle et résultats d’outil à inspecter ?
Vos plugins et patchs se chargent-ils sans erreurs de configuration ?
Pouvez-vous restaurer le répertoire copié et continuer à utiliser les anciens fichiers de session si la nouvelle exécution échoue ?

N’écrasez pas la seule copie d’une session durant une migration. Si la nouvelle version écrit un format plus récent, conservez l’original à côté et testez le comportement de rétrogradation sur une copie. Restaurez ensemble le $DSH_HOME et l’espace copiés si le nouveau checkout source échoue ; ne revenir qu’à l’exécutable peut laisser des sessions dans un format illisible par l’ancienne version. Ne promouvez une version vers un environnement précieux qu’après succès de ces vérifications pour vos propres fichiers, fournisseurs, outils et politique d’approbation.

Questions fréquentes

DeepSeek Harness est-il un logiciel officiel ?

Le projet est publié dans l’organisation deepseek-ai/deepseek-harness, lié depuis la page Harness officielle de DeepSeek et publié sous licence MIT. Le dépôt et la page officielle sont les sources appropriées pour le comportement actuel et le statut de version.

dsh est-il un LLM ?

Non. C’est le runtime autour d’un modèle : fournisseurs, outils, sessions, boucles d’agent, politiques et profils d’application. Vous avez toujours besoin d’un endpoint de modèle compatible et d’un identifiant.

Quelle entrée utiliser pour CI ?

Commencez avec le profil documenté headless pour une commande ponctuelle. Donnez-lui un espace jetable et un répertoire Harness explicite, épinglez la version et testez le fournisseur et la tâche exacts à automatiser. L’exécution headless est un point d’entrée, non une garantie de comportement déterministe ou sûr en production.

Une liste de correctifs de version prouve-t-elle la stabilité ?

Non. Les notes de version décrivent les comportements modifiés et correctifs. Elles ne mesurent pas la fiabilité sur une population ou charge. Utilisez-les pour sélectionner des cas de régression, puis collectez vos propres résultats.

Puis-je faire passer dsh par Tokenhot ?

Potentiellement, si votre endpoint Tokenhot sélectionné expose l’un des protocoles pris en charge par dsh et si l’ID de modèle et la forme de requête sont compatibles. La configuration API documentée de Tokenhot fournit l’URL de base et le modèle Bearer Token ; un résultat de compatibilité réel nécessite une requête avec identifiant et sort du cadre de ce guide.

Par où commencer ?

Lisez le README du dépôt rc.2, choisissez un espace isolé et exécutez l’interface Web ou le profil headless sur une tâche inoffensive. Si vous avez besoin des champs API Tokenhot documentés pour une expérience fournisseur, suivez le Quick Start et vérifiez modèle et protocole avant de conclure.