← Retour aux pratiques techniques

AIAgent

DeepSeek Harness (dsh) : 10 plugins utiles, scènes AI Coding, piles et coût

Environ 14 min

Trois personnes regardent un MacBook sur une table de réunion

Vérifié le 18 septembre 2026 d’après le dépôt officiel DeepSeek Harness, le Plugin Config Catalog, la doc d’empaquetage et d’installation et la grille tarifaire de l’API DeepSeek.

Le catalogue liste des dizaines de paquets @deepseek-ai/dsh-*. Le réflexe courant : tout installer, l’Agent écrira mieux. En vrai, c’est l’inverse. Les noms d’outils saturent la fenêtre, les processus MCP tournent à nu hors sandbox, le journal de session gonfle, la facture sonne avant que la qualité des rustines ne suive.

D’emblée : DeepSeek Harness (dsh) affiche Everything is a Plugin. Pour écrire du code, ce n’est pas le nombre de paquets que vous achetez. C’est six métiers : lire le dépôt, modifier des fichiers, lancer les tests, charger un mode d’emploi à la demande, rejouer une session, compter les jetons. Les dix paquets ci-dessous couvrent ces six points. Le reste est interface, démo ou backend remplaçable — on l’ajoute quand la scène l’exige, pas avant.

En août, l’analyse d’architecture a découpé les coutures. En septembre, le texte Harness / Skill / Sandbox a montré pourquoi la couche d’exécution se sépare. Ici, la question est plus terre à terre : vous avez choisi dsh pour coder — quels paquets mettre dans le profil, comment les empiler, et combien coûte à peu près un mois.

Pas le pack complet : les plugins se composent

Côté officiel, adaptateurs de modèle, registre d’outils, journal de session et boucle Agent partent en paquets remplaçables, empilés par Cordis dans un Profile. L’entrée d’installation est dsh plugin --profile web add <paquet> : la commande est déléguée au pnpm du répertoire de profil et n’empile que les paquets qui déclarent dsh.bundle. Ensuite, le bundle le plus récent, le cordis.patch.yml du profil, les rustines du répertoire home et --patch écrasent dans cet ordre.

Pour quelqu’un qui écrit du code, ça donne trois règles.

  • Chargé ne veut pas dire exposé au modèle. Le client MCP enregistre les outils externes en mcp__server__tool, du genre mcp__github__create_issue. La doc est nette : chaque serveur MCP est du code de confiance hors sandbox. Par défaut, aucun n’est ouvert.
  • L’ordre des couches décide qui gagne. Pour changer de modèle, de sandbox ou couper un outil, on patche. On ne copie pas un paquet cœur. dsh --profile web --dump-config affiche l’arbre réellement démarré, plus fiable qu’un inventaire lu dans la doc.
  • Le dépôt reste en aperçu développeur. Des ruptures peuvent arriver. S’en servir comme couche d’exécution à vérifier, oui. Le traiter comme une plateforme déjà certifiée production, non.

Ces dix paquets ne sont donc pas « tout le catalogue officiel ». C’est le minimum qui revient assez souvent en AI Coding. Quand la boucle d’outils dérape, les noms de champs changent, le mode de panne presque pas. D’abord arrêter la boucle, ensuite seulement parler de plugins.

Dix plugins vraiment utiles pour l’AI Coding

Pour chaque paquet, on ne dit que quelle famille d’accidents il porte. Les noms suivent le catalogue. Les paires ferment la même couture — définition, fournisseur ou consommateur. N’installer qu’un côté laisse la couture ouverte.

1. dsh-tool-fs + dsh-tool-fs-search : voir le dépôt avant de toucher

Le modèle « refacto » sans avoir lu l’arborescence. Lire un fichier et chercher un symbole ou un texte est le prérequis de toute édition. Sans cette paire, le remplacement précis s’applique avec assurance sur le mauvais chemin.

2. dsh-tool-str-replace-editor : remplacer un bloc, pas réécrire le fichier

L’échec le plus cher n’est pas « rien n’a bougé ». C’est un appel qui réécrit tout le fichier avec la version que le modèle a en tête. L’éditeur par remplacement de chaînes exige l’ancien fragment et le nouveau, et échoue en cas de conflit au lieu d’écraser en silence. Sur un refactor multi-fichiers, c’est moins cher que « générer le fichier entier », et plus simple à revenir en arrière.

3. dsh-tool-bash + dsh-bash-sandbox : les tests doivent tourner, et pouvoir s’arrêter

Tests rouges, linter, journaux de build finissent dans un shell. Le Process Sandbox officiel ne couvre que les effets fichiers d’un sous-processus sur la même machine : read-only refuse l’écriture, workspace-write n’autorise que l’espace de travail de la session, danger-full-access saute l’isolement. Si vous avez demandé un confinement et qu’aucun backend ne peut le tenir, il faut lever SANDBOX_UNAVAILABLE — pas de passage à nu. L’isolement réseau n’est pas dans ce vocabulaire. N’attendez pas de read-only qu’il coupe le trafic sortant.

4. dsh-tool-lsp + dsh-lsp-stdio : brancher la bouche du compilateur dans la boucle

« Les types ont l’air justes » et un diagnostic du language server ne sont pas la même information. Le LSP en stdio transforme aller à la définition, diagnostics et recherche de symboles en outils. Ça vaut le coup en TypeScript, Go, Rust. Un dépôt de scripts ou une tâche purement documentaire peut s’en passer et économiser une ronde de noms d’outils.

5. dsh-tool-skill + dsh-skill-filesystem : le mode d’emploi apparaît à la demande

Style, checklist de livraison, entrée des tests : on les écrit en Skill. Le modèle voit surtout le catalogue, puis appelle skill({ name }) quand il s’y met. À la racine du projet, .dsh/skills passe avant .agents/skills. Un Skill n’est pas un système de droits : plus le manuel est clair, plus c’est dangereux sans sandbox. Le détail est dans l’article pratique ; ici, on retient seulement que, pour coder, cette paire remplace le tas de « vous devez respecter » dans le prompt système.

6. dsh-mcp-client : accrocher GitHub et le même genre d’outils externes

Une instance, un serveur MCP. En stdio on peut tirer @modelcontextprotocol/server-github ; le modèle voit des noms bornés du type mcp__github__create_issue. Utile pour commenter une PR, lister des issues, lire les checks. Mauvais outil par défaut pour chaque édition. Les secrets vont dans des variables d’environnement. Le processus tourne hors sandbox. Un serveur de plus, c’est une surface de confiance de plus.

7. dsh-plan-mode : écrire le plan avant de toucher l’espace de travail

Refactor transversal, API publique, scripts de migration : le modèle ne doit pas écrire en réfléchissant. Plan mode transforme « lister les étapes et attendre un avis » en comportement de plugin, pas en prière dans le prompt. Un correctif de test unique peut s’en passer. Dès que trois répertoires ou plus sont concernés, on l’ouvre d’abord.

8. dsh-tool-todo : clouer une tâche en plusieurs pas dans la session

« Réparer le flaky, ajouter la régression, mettre à jour le README » livré à la seule mémoire du chat oublie souvent la dernière étape. L’outil todo fait de la liste un objet que la session peut mettre à jour. Ça ne remplace ni le Skill (comment faire) ni le Plan (faut-il le faire, dans quel ordre).

9. dsh-compaction-tool-result-pruner + dsh-token-meter : d’abord couper les résultats, ensuite changer de modèle

La facture AI Coding meurt rarement au premier tour. Elle meurt au dixième, parce que les journaux de test complets, le diff entier et la page HTML entière sont encore dans la fenêtre. Le pruner jette les sorties d’outils que plus personne ne cite. Le compteur de jetons montre ce que chaque tour a coûté. Sans mesure, on ne sait pas si le modèle est cher ou si les plugins ont gavé la fenêtre.

10. dsh-session-persistence-sqlite : une session qu’on rejoue, pas seulement de la RAM

Redémarrage, changement d’onglet, un autre débogue : le tour suivant doit se reconstruire depuis le journal disque. Le JSONL sait noter ; SQLite convient mieux pour interroger par session et comprendre après coup pourquoi cette ligne-là a bougé. Sans cette couche, les neuf plugins du dessus ne laissent que des captures d’écran.

Pile de plugins AI Coding : lire et modifier, exécuter isolé, plan et liste, MCP et mesure
D’abord lecture, édition et isolement. Plan, MCP et mesure viennent avec la scène. Le coût est dans les jetons et le contexte, pas dans le nombre de plugins.

Quatre scènes de code, quels plugins ouvrir

Les mêmes dix paquets n’ont pas à rester tous ouverts. Choisir selon la tâche coûte moins cher que choisir selon « ça fait pro ».

Scène A : réparer un test rouge. Le minimum, c’est fs / search, str-replace, bash+sandbox. Lire le journal d’échec, limiter le correctif, relancer le même test. Un Skill ne vaut que si le dépôt a une règle fixe « cette commande d’abord ». Plan et MCP sont du bruit.

Scène B : refactor qui traverse les fichiers. Sur A, on ajoute plan-mode, todo, LSP. Le modèle écrit quels symboles bougent et quels tests doivent rester verts, puis on autorise l’écriture. Sans plan, le nom public change à moitié et les appelants gardent l’ancien.

Scène C : relecture ou rustine face à GitHub. Client MCP, un seul serveur. S’en servir pour le diff de PR, les checks et les commentaires. Les fichiers, eux, passent toujours par editor + sandbox. Créer une issue, merger, supprimer une branche n’ont rien à faire sur la même liste par défaut que l’éditeur du quotidien.

Scène D : longue session, beaucoup de tours d’exploration. Compaction et token-meter, session vers SQLite. Après vingt fichiers lus, si on ne coupe pas les résultats d’outils, chaque tour suivant paie encore des journaux déjà périmés. Une modèle plus fort ne sauve pas une fenêtre gonflée.

Trois piles : quotidien, équipe, maîtrise des coûts

On range les scènes en trois Profiles reproductibles. Ça tient mieux que de tordre cordis.yml à chaque tâche.

PileOuvert par défautLaisser ferméPour qui
Code du quotidienfs / search, editor, bash+sandbox, skillMCP, sous-agents, recherche Web complèteUne personne, bugs, petites fonctions
Équipequotidien + plan + todo + SQLite + un MCP GitHubdeuxième MCP, danger-full-accessRejeu et travail sur une PR
Maîtrise des coûtsquotidien + token-meter + coupe des résultats + FlashPro par défaut, longs journaux non coupésDes dizaines de boucles par jour

Recherche Web et sous-agents ne sont pas interdits. Ils sont chers par défaut, et la surface de panne est large. Le catalogue officiel a dsh-web-search-deepseek, dsh-tool-web et plusieurs implémentations de subagent. Pour consulter de la doc ou détacher une enquête en lecture seule, on ouvre par Patch. On ne les écrit pas dans le bundle du quotidien.

À l’installation, garder l’ordre des couches : @deepseek-ai/dsh-base d’abord, puis dsh plugin --profile <nom> add pour vos paquets, enfin le patch du profil pour cacher les outils que le modèle ne doit pas voir. Un plugin source hébergé sur GitHub avec un script prepare sera bloqué par pnpm 10 ; suivre l’indication officielle pour l’autoriser, plutôt que d’accorder des droits globaux dangereux.

Coût de déploiement : jetons, machine, taxe

Les plugins eux-mêmes n’ont presque pas de licence. Ce que vous payez, ce sont les jetons du modèle, une machine qui ne s’endort pas, et chaque processus externe hors sandbox.

Les jetons sont le gros poste. La carte officielle de septembre 2026 compte par million de tokens : deepseek-flash (V4.1-Flash) cache touché environ 0,003 / 0,006 dollar, cache manqué 0,15 / 0,30, sortie 0,60 / 1,20 (heures creuses / pointe) ; deepseek-v4-pro manqué 0,66 / 1,32, sortie 1,98 / 3,96. La pointe, c’est du lundi au vendredi UTC 01:00–04:00 et 06:00–10:00 — à Paris, grosso modo la nuit puis la matinée, à Pékin les deux blocs de bureau. Les heures creuses sont à moitié prix. Un passage « lire 8 fichiers + deux journaux de test + un petit correctif » avale facilement des dizaines de milliers de tokens d’entrée. Sans coupe, le dixième tour paie encore les journaux des neuf premiers.

Ordre de grandeur quotidien : 30 boucles, en moyenne 20 000 tokens d’entrée (cache manqué) plus 1 000 en sortie. En Flash heures creuses, environ 0,11 dollar par jour, autour de 3 dollars par mois. La même cadence avec Pro par défaut et les sorties de test entières dans la fenêtre grimpe facilement à quelques dizaines de dollars. L’ordre pour économiser : d’abord couper les résultats d’outils et réutiliser le cache, ensuite seulement décider si ce travail-là mérite Pro — pas l’inverse.

La machine est le deuxième poste. npx @deepseek-ai/dsh web n’ouvre l’interface que sur 127.0.0.1:3080 par défaut. Développer le jour, éteindre le soir, ça va. Si les sessions SQLite, les répertoires Skill et la politique sandbox doivent rester joignables 24/7, il faut un nœud qui ne dort pas. Couvercle fermé, NAT domestique qui bouge : un collègue à distance ne revoit pas la même session. Un Mac mini cloud ne rend pas le Harness plus malin que l’API. Il l’ôte de la machine qui livre les builds. Seatbelt, outillage Unix et cwd fixe sont plus prévisibles qu’un portable Windows qui s’endort.

La taxe plugins est le troisième poste. Un serveur MCP de plus, c’est un processus hors sandbox et un jeu de secrets. Le LSP garde un language server chaud. Une page Web entière se déverse dans le contexte. Rien de tout ça n’apparaît sur la carte DeepSeek, mais ça mange l’avantage tarifaire de Flash. Le quatuor du quotidien a une taxe proche de zéro. La pile équipe avec un MCP GitHub reste en général rentable. Ouvrir par défaut la recherche, les sous-agents et un second MCP fait fuir le coût des jetons vers l’exploitation.

Le dépôt est encore en aperçu. Souder Harness et le chantier client sur la même machine de build, c’est empiler boucle, manuels et isolement fichiers sur le chemin de livraison. Un nœud isolé, on peut le jeter, le rollback, le brider. C’est ça que le « coût de déploiement » doit acheter.

Quand ajouter un plugin, quand s’en passer

Votre casFairePourquoi
Une fonction, un testQuatuor du quotidienPlan, MCP et LSP sont des noms d’outils en trop
API publique ou plus de trois répertoiresAjouter plan + todo + LSPAligner les étapes, puis autoriser l’écriture
Travailler sur commentaires ou checks d’une PRUn seul MCP GitHubOutil externe = surface de confiance, ne pas empiler
Des dizaines de tours, la facture sautemeter + coupe + FlashLire la fenêtre d’abord, changer de modèle ensuite
Skill et Sandbox encore mélangésNe pas élargir les pluginsPlus le manuel est complet, plus l’écriture à nu est dangereuse

Face à un while maison et deux ou trois outils, dsh achète des coutures déjà séparées pour l’ordre des couches, la session et l’isolement. Le prix, c’est l’aperçu qui peut casser, et le devoir de ne pas vider le catalogue. Les dix paquets valent le coup si, cette année, vous allez vraiment changer de backend modèle, de sandbox, ou réutiliser le même catalogue de Skills sur plusieurs dépôts. Juste pour voir si le modèle discute, inutile de monter toute la pile.

En une phrase : en 2026, ce n’est pas celui qui installe le plus qui gagne avec DeepSeek Harness. C’est celui qui sait dire, pour cette tâche-là, de quelles couches il a besoin. Lire, modifier, exécuter, expliquer à la demande ; session rejouable, jetons mesurables. Les plugins se composent, ils ne se collectionnent pas.

Questions fréquentes

Faut-il installer les dix plugins d’un coup ?

Non. D’abord fs / search, editor, bash+sandbox et skill. Plan, LSP, MCP, coupe et SQLite viennent avec la scène. Le reste du catalogue, ce sont surtout des backends remplaçables ou de l’interface, pas un passage obligé pour coder.

Le plugin MCP est-il sûr ?

Officiellement, chaque serveur MCP est du code de confiance hors sandbox, et aucun n’est activé par défaut. N’ouvrez que celui dont vous avez besoin, secrets dans des variables d’environnement, pas sur la même liste par défaut que l’éditeur du quotidien.

Pourquoi ne pas coder par défaut avec le modèle Pro ?

Le coût vient des résultats d’outils sur beaucoup de tours, pas d’un « modèle pas assez malin ». Officiellement, la sortie Flash en heures creuses vaut environ 0,60 dollar par million de tokens, Pro environ 1,98. Couper les journaux et viser le cache, puis décider si cette tâche-là mérite Pro.

Peut-on s’en servir comme plateforme de code en production ?

Comme échantillon de couche d’exécution à vérifier et à isoler, oui. Pas comme plateforme déjà certifiée. Le dépôt officiel reste un aperçu développeur. Séparer l’aperçu de la machine qui livre les builds est plus utile que le débat « est-ce du prod ».

Un nœud dsh jetable sur un Mac mini cloud

La pile AI Coding veut un cwd fixe, des sessions SQLite qui restent, et Seatbelt sous macOS. Faire tourner un dsh en aperçu plus un MCP GitHub sur la seule machine de livraison, c’est empiler boucle, manuels et processus externes sur le chantier client. La mémoire unifiée d’un Mac mini M4 porte une voie de build stable et une boîte Harness qu’on peut brider et rollback à côté. Environ 4 W au repos, Unix natif et SSH clouent le répertoire Skill et l’espace sandbox sur une machine qui ne s’endort pas.

S’il faut séparer le nœud de code quotidien et la machine de livraison, Kvmkit Mac mini M4 cloud peut ajouter une machine isolée à la demande—voir les offres, pour que la composition de plugins et les essais de jetons aient un endroit, sans alourdir la machine qui livre.

Un nœud qui ne fait tourner que dsh ?

Gardez la pile d’aperçu hors de la machine qui livre. Offres sur les pages tarif et aide.