DeepSeek Harness : démarrage, modes et limites des plugins

En bref : DeepSeek Harness n’est pas un simple chat auquel on aurait ajouté un bouton « agent ». C’est un environnement open source où l’agent est composé de pièces remplaçables : modèle, outils, skills, session, sandbox, stockage, boucle d’agent, planification et interface. DeepSeek le présente comme un Developer Preview. Le bon premier objectif n’est donc ni d’ouvrir un dépôt de production ni d’installer beaucoup de plugins, mais d’obtenir une exécution observable, limitée et en lecture seule dans un dossier jetable.

DeepSeek résume la conception ainsi : Agent = Model + Harness. Le modèle raisonne et génère du texte ; le harness lui apporte le contexte d’exécution, les outils et la boucle qui continue après une réponse. Lorsqu’un agent lit le mauvais fichier, ignore la sortie d’une commande ou modifie un mauvais emplacement, le problème peut venir du runtime et de son contexte, pas seulement du modèle.

Si vous allez relier un modèle à un endpoint API personnalisé, vérifiez d’abord le protocole, la Base URL et l’authentification du provider choisi. BetterToken fournit des interfaces OpenAI-compatible et Anthropic-compatible aux outils qui acceptent une Base URL personnalisée ; cela ne prouve pas que tous les plugins Harness sont compatibles. Consultez la configuration de votre clé et le schéma du provider dans la documentation API BetterToken, puis n’exécutez qu’une petite tâche en lecture seule dans une copie de test.

Ce que DeepSeek a publié, et ce que cela n’implique pas

Le dépôt officiel DeepSeek Harness est sous licence MIT. Son principe est que « tout est plugin » : le projet s’appuie sur Cordis pour charger, décharger et relier des plugins. Cordis ne donne pas à lui seul des capacités d’agent ; ce sont les plugins de modèle, d’outils, de session, de sandbox, de stockage ou d’interface qui les fournissent.

Cette séparation est utile pour expérimenter une variable à la fois. Vous pouvez comparer un modèle sans remplacer en même temps la couche d’outils, ou observer un plugin de session sans reconstruire le runtime entier. La contrepartie est concrète : un plugin de plus peut modifier les données accessibles, les permissions, les dépendances installées et les services externes qu’un agent peut appeler.

Le statut Developer Preview compte autant que l’architecture. Le projet évolue rapidement et DeepSeek prévient que des changements incompatibles peuvent arriver. Ne figez donc pas une commande, une option ou un preset trouvé dans un ancien article comme s’il s’agissait d’une API stable. Avant une session sur des données réelles, relisez le quickstart officiel et le README du dépôt.

Premier lancement : un environnement réversible avant toute vraie tâche

Après avoir installé la version de Node.js demandée par la documentation actuelle, le lancement Web officiel est :

npx @deepseek-ai/dsh web

Cette commande lance par défaut une interface locale ; utilisez l’option —no-open lorsque vous souhaitez démarrer le serveur sans ouvrir automatiquement le navigateur. Le dépôt documente aussi le démarrage depuis les sources, mais il n’est pas nécessaire pour vérifier le comportement de base.

Pour un premier passage, suivez un protocole simple :

1. Créez un dossier vide ou un clone propre, sans secret, cookie, fichier .env ni modification non commitée.
2. Lancez l’interface et choisissez Standard. N’ajoutez pas de plugin communautaire pendant cette première observation.
3. Demandez une tâche minuscule et sans écriture : identifier le point d’entrée, décrire l’arborescence, ou préparer un plan de modification.
4. Comparez la réponse avec les fichiers réels et avec les événements de la session. Autorisez seulement ensuite une modification limitée, avec un diff à relire.

L’isolement n’est pas une promesse que chaque commande shell devient inoffensive. C’est un contrôle d’ingénierie : il limite le rayon d’action d’une mauvaise configuration et permet de distinguer un problème de contexte d’un risque pour le dépôt principal. Si un test demande des identifiants, arrêtez-vous : une première validation utile ne doit pas dépendre d’une clé de production.

Les quatre modes : choisir le plus petit runtime qui répond au besoin

Mode	Ce qu’il apporte	Bon point de départ	Première vérification
Standard	Agent de code complet : édition de fichiers, shell, recherche de fichiers et Web, skills, plans, objectifs, sous-agents et workflows	Une tâche de développement ordinaire	Les outils effectivement disponibles et les actions réellement exécutées
PTC	Les capacités Standard et le Code Mode SDK, qui compose des appels d’outils dans un programme TypeScript	Une procédure répétée dont l’orchestration doit être lisible	Le TypeScript généré, ses entrées et la frontière de chaque appel
Minimal	Un bash persistant et str_replace_editor	Une baseline de diagnostic ou de benchmark	Ce qui change lorsque la surcouche d’orchestration disparaît
Creation	Standard, inspection du runtime, essais de plugins Cordis en mémoire et création de presets	La conception d’un preset personnalisé	Les plugins, dépendances et permissions ajoutés par le preset

Standard est le choix raisonnable pour la première tâche réelle. Il montre le cycle complet sans demander de comprendre immédiatement la programmation de l’orchestration. Vérifiez néanmoins que les outils exposés correspondent à ce que vous aviez prévu : la présence d’un outil n’autorise pas son emploi sur des données sensibles.

Choisissez PTC seulement lorsque la séquence d’appels est elle-même l’objet de la revue. Le modèle produit alors un programme TypeScript qui enchaîne des outils. Cela peut rendre une procédure plus inspectable et reproductible ; cela ne garantit ni une meilleure réponse ni une exécution sûre. Lisez le programme comme vous reliriez un script d’automatisation : paramètres, fichiers touchés, appels réseau éventuels et conditions d’arrêt.

Minimal n’est pas un Standard « plus léger » à utiliser par défaut. C’est une référence pour comprendre l’effet des skills, de la recherche, de l’interface et de l’orchestration. Creation vient après cette compréhension : il sert à expérimenter un runtime ou à fabriquer un preset, pas à contourner l’étape de validation du comportement existant.

Trajectory : contrôler ce que l’agent a vu et fait, pas seulement sa réponse

DeepSeek décrit Trajectory comme un journal de session append-only. Il peut contenir le prompt système, le contexte visible du modèle, les appels d’outils et leurs résultats, la planification de sous-agents et les injections de contexte. La récupération, le branchement, la recherche et le replay s’appuient sur ce même flux d’événements.

Après la première tâche, ne vous contentez pas du texte final. Répondez à ces questions dans le journal :

• Quels fichiers et quelles sorties de commande l’agent a-t-il réellement vus ?
• Un appel d’outil ou un contexte inattendu a-t-il été injecté ?
• L’exécution s’est-elle arrêtée par manque d’accès, d’outil, d’instruction ou de contexte ?
• La trajectoire qui a réussi peut-elle être reprise sans recommencer une conversation vierge ?

Un test pratique consiste à demander l’emplacement où une configuration est construite, tout en interdisant les écritures. Vérifiez ensuite le chemin, la commande et sa sortie dans Trajectory. S’ils ne correspondent pas au dépôt, ne réécrivez pas immédiatement le prompt : corrigez d’abord l’accès à l’outil ou le contexte fourni. Trajectory est un moyen d’audit, pas une raison de placer dans le runtime des secrets, des prompts confidentiels ou des journaux complets de production.

Plugins, permissions et configuration : ajouter une capacité avec un plan de retrait

Un plugin n’est pas une simple case à cocher. Il est du code, avec ses dépendances et une surface d’accès. Avant d’en installer un, consignez :

1. la capacité précise qui manque aujourd’hui ;
2. les fichiers, données, services externes et permissions qu’il peut atteindre ;
3. le signal qui révélera une régression ;
4. le moyen de revenir à la configuration précédente.

Pour découvrir des extensions, DeepSeek renvoie notamment au topic communautaire dsh-plugin. Commencez par le code source et les dépendances, pas par un bundle entier. Pendant le Preview, ne changez qu’un composant par exécution : sans cette discipline, Trajectory ne peut pas montrer quel changement a déplacé le comportement.

Gardez les permissions minimales. Un dossier de test ne rend ni le shell ni un plugin externe sûrs par magie. N’autorisez pas un déploiement, une migration, l’accès à un gestionnaire de secrets ou une écriture large simplement parce que la tâche initiale est anodine. Ne placez jamais une API key, un cookie ou un fichier .env dans un preset, un prompt ou la trajectoire. Si un plugin exige une configuration de provider, utilisez votre propre compte et votre propre clé, limitez-la au test autorisé et retirez-la du dossier de test après vérification.

Validation, dépannage et décision d’adoption

Une validation minimale comporte trois preuves : la tâche demandée a été comprise, les actions tracées correspondent aux fichiers réels, et le diff ou la sortie est relu par une personne. Ensuite seulement, augmentez une seule dimension à la fois : autoriser une écriture dans une branche jetable, ajouter un outil, puis éventuellement tester un plugin.

En cas de résultat inhabituel, classez le problème avant de modifier la configuration :

• Le bon fichier n’apparaît pas dans le résultat : contrôlez le répertoire de travail, les permissions de lecture et le contexte transmis.
• Une commande a un résultat différent de celui annoncé : vérifiez l’événement Trajectory, la version de l’outil et la sortie réelle avant de conclure à une erreur du modèle.
• Le provider ne répond pas : revalidez le protocole, la Base URL, la méthode d’authentification et le modèle configuré selon la documentation du provider ; ne déduisez pas l’incompatibilité d’un plugin d’une seule erreur.
• Un plugin élargit trop la surface d’accès : désactivez-le, revenez au preset précédent et reproduisez la tâche sans lui.

Harness mérite un essai si vous devez séparer le comportement du modèle de celui des outils, déboguer un processus multi-étapes à partir d’événements, ou construire un preset réellement reproductible. Différez l’usage sur des données réelles si vous n’avez ni environnement jetable, ni revue de diff, ni processus de lecture des logs.

Pour séparer l’accès API de vos abonnements et vérifier le statut ainsi que la consommation d’un test autorisé, créez votre propre clé dans BetterToken, suivez la documentation API BetterToken, puis commencez par une tâche Harness courte et en lecture seule. Conservez les URL de documentation et de configuration sans paramètres UTM.

• Dépôt officiel DeepSeek Harness
• Quickstart DeepSeek Harness