DeepSeek Harness est une boucle. L'agent lit votre espace de travail, modifie des fichiers, exécute des commandes via son outil bash, et décide de la prochaine étape en fonction du résultat. Alors pourquoi vos tests d'API ne sont-ils pas inclus dans cette boucle ? Ils sont stockés dans Apidog derrière une interface graphique et ne s'exécutent que lorsque quelqu'un pense à cliquer. L'agent ne les touche jamais.
La solution tient en un bloc de configuration. L'interface de ligne de commande (CLI) d'Apidog est un package npm, apidog-cli, qui exécute les scénarios de test que vous avez créés dans Apidog directement depuis un terminal. Une fois la CLI installée et que DeepSeek Harness sait qu'elle existe, l'agent exécute un scénario Apidog de la même manière qu'il exécute vos tests unitaires : il lance la commande, lit le code de sortie, corrige le code s'il est rouge.
Il existe également un argument de jeton pour cela. Un agent qui confirme que votre API fonctionne toujours en relisant le code du gestionnaire et en raisonnant sur les formes de réponse consomme du contexte à chaque passage. Un agent qui exécute une seule commande obtient une vérité de terrain en quelques lignes. La CLI compresse la question "l'API est-elle correcte ?" en un code de sortie, et l'agent consacre son contexte à la correction.
Ce guide couvre la partie spécifique au harnais que le guide d'installation générique ignore : quel fichier d'instructions DeepSeek Harness lit réellement, comment son outil bash exécute apidog run, et comment maintenir la boucle honnête. Si vous n'avez pas encore installé la CLI, faites-le d'abord. Comment installer la CLI Apidog avec un agent de codage IA détaille l'installation npm, l'authentification et la première exécution. Cet article suppose que apidog --version affiche un nombre et que votre machine est authentifiée.
De quel DeepSeek Harness s'agit-il ?
DeepSeek Harness, dsh en ligne de commande, est le harnais d'agent open source que DeepSeek a lancé le 13 août 2026, aux côtés de V4-Pro sur l'API. Il est sous licence MIT, se trouve sur github.com/deepseek-ai/deepseek-harness et avait dépassé les 169 000 étoiles au 20 août. Vous le démarrez avec npx @deepseek-ai/dsh web, qui sert une interface utilisateur web locale à l'adresse http://127.0.0.1:3080. Là, vous choisissez un espace de travail, le répertoire de projet depuis lequel vous l'avez lancé, et l'agent y travaille : il lit et modifie des fichiers, exécute des commandes et demande l'approbation avant les opérations qui la requièrent selon la politique de permissions active.
Deux éléments influencent tout ce qui suit. Premièrement, le harnais est une version préliminaire pour développeurs. Le README avertit, en majuscules, qu'il y aura des changements cassants, alors traitez les noms de fichiers et les clés de configuration ici comme précis pour fin août 2026 et vérifiez-les à nouveau par rapport à la documentation du dépôt si quelque chose ne charge pas. Deuxièmement, tout dans dsh est un plugin, construit sur l'architecture Cordis, ce qui rend la question pratique ci-dessous répondable : quel plugin lit vos règles de projet, et que recherche-t-il ? Pour un aperçu plus large, voir ce qu'est DeepSeek Harness ; pour savoir comment il se compare à l'existant, voir DeepSeek Harness vs Claude Code.
Étape 1 : Placer la CLI dans AGENTS.md
DeepSeek Harness lit les instructions de l'espace de travail via son plugin @deepseek-ai/dsh-agent-instructions, et les valeurs par défaut sont familières si vous avez utilisé d'autres agents. Selon la source du plugin et le catalogue de configuration, le chargeur remonte depuis le répertoire de travail de la session jusqu'à la racine de votre projet (marquée par .git) et charge AGENTS.md, avec un repli sur CLAUDE.md, dans chaque répertoire sur son chemin. Des superpositions locales nommées AGENTS.local.md ou CLAUDE.local.md se chargent après les fichiers de base, et un AGENTS.md utilisateur-global fixe dans $DSH_HOME (par défaut ~/.dsh) s'applique à tous les projets. Les fichiers de plus de 1 Mio sont ignorés, ce que votre fichier de règles n'atteindra jamais.
En pratique : si votre dépôt contient déjà un fichier AGENTS.md pour Codex ou un CLAUDE.md pour Claude Code, DeepSeek Harness le détecte sans configuration supplémentaire. Ajoutez-y un court bloc Apidog :
## Test d'API avec la CLI Apidog
- Pour tester l'API, exécutez le scénario Apidog. Ne pas naviguer via l'interface graphique.
- Commande : apidog run -t <scenario_id> -e <env_id> -r cli
- Le code de sortie 0 signifie que toutes les assertions ont réussi. Non-zéro signifie un échec ; lisez le rapport et corrigez le code.
- La machine est déjà authentifiée. N'ajoutez jamais d'indicateur --access-token et ne placez jamais de jeton dans ce fichier.
C'est pourquoi le fichier de règles l'emporte sur le chat. Un ID de scénario tapé dans le compositeur de session disparaît à la fin de la session. Un ID écrit dans AGENTS.md se charge dans chaque nouvelle session, pour chaque membre de l'équipe, sur chaque machine qui clone le dépôt. Si vous travaillez sur plusieurs projets, le fichier ~/.dsh/AGENTS.md global à l'utilisateur maintient l'habitude ("toujours vérifier les changements d'API avec la commande apidog run du projet") tandis que le fichier propre à chaque dépôt contient les ID réels.
Étape 2 : Obtenir la commande d'Apidog
Vous n'avez pas à deviner les ID de scénario et d'environnement. Ouvrez le scénario de test dans Apidog, allez dans l'onglet CI/CD et copiez la commande générée. Elle ressemble à ceci :
apidog run -t 123456 -e 789012 -r cli
L'indicateur -t est l'ID du scénario de test, -e est l'ID de l'environnement, et -r cli sélectionne le rapporteur qui affiche les résultats en ligne, ce qui est exactement ce dont un agent a besoin pour lire. Collez les ID réels dans votre bloc AGENTS.md afin que l'agent exécute la commande générée par Apidog, et non une supposition.
Étape 3 : Demander à l'agent d'exécuter le test
Démarrez une session dans l'interface web de dsh avec votre espace de travail sélectionné. Le chargeur d'instructions a déjà alimenté le contexte de l'agent avec votre AGENTS.md, il sait donc que la CLI existe. Effectuez un changement qui affecte votre API, ou demandez simplement :
Exécutez le scénario de test Apidog et dites-moi le code de sortie.
L'agent l'exécute via son outil bash, et savoir comment cet outil se comporte vous évitera une session de débogage plus tard. Selon le catalogue d'outils, l'outil bash par défaut exécute chaque commande dans un shell frais : aucun répertoire de travail, variable ou fonction ne persiste entre les appels, et les commandes s'exécutent depuis l'espace de travail de la session à moins qu'un workdir ne soit passé. Cela convient pour apidog run, une commande unique et autonome, mais l'agent ne peut pas `cd` quelque part d'abord et exécuter le test comme deuxième étape. Si votre scénario doit s'exécuter depuis un sous-répertoire, mettez l'invocation complète sur une seule ligne dans votre fichier de règles.
Deux autres comportements à connaître. Les sorties non nulles sont signalées par un marqueur explicite [exit code: N], de sorte que le signal de réussite/échec subsiste même lorsque les sorties longues sont tronquées à leur fin. Et les commandes peuvent s'exécuter sous un bac à sable de fichiers : une opération bloquée est signalée comme un refus de politique, et non comme un échec de commande. Un test en lecture seule déclenche rarement cela, mais le rapporteur HTML écrivant dans ./apidog-reports pourrait le faire, selon la politique active.
Le fait que l'exécution nécessite votre clic dépend de la même politique de permissions. L'interface utilisateur web demande avant les opérations qui nécessitent une approbation, selon le guide utilisateur. Lorsqu'elle vous invite pour apidog run, approuvez-la : un scénario de test contre un environnement de staging est exactement le genre de commande sûre, principalement en lecture, que le processus d'approbation est censé laisser passer.
Étape 4 : Lire le rapport
Lorsqu'une exécution devient rouge, le rapport contient la réponse. Avec -r cli, l'agent obtient une ventilation lisible en ligne : chaque requête, chaque assertion, et laquelle a échoué avec la valeur attendue par rapport à la valeur réelle. L'assertion échouée nomme le champ exact ou le code de statut, ce qui est généralement suffisant pour que l'agent localise la correction sans que vous ayez à traduire.
Pour un rapport que vous pouvez ouvrir dans un navigateur ou transmettre à un coéquipier, ajoutez le rapporteur HTML :
apidog run -t 123456 -e 789012 -r cli,html
Le rapporteur html écrit un fichier autonome dans ./apidog-reports. Gardez cli dans la liste afin que l'agent reçoive toujours la sortie en ligne qu'il lit pour décider de sa prochaine étape.
La boucle, de bout en bout
Voici ce que cette configuration vous apporte. Supposons que l'agent modifie un gestionnaire de commande. Sans la CLI, sa boucle se termine à « le code semble correct ». Avec le bloc dans AGENTS.md, la boucle s'étend : il modifie le gestionnaire, exécute apidog run -t 123456 -e 789012 -r cli et lit le résultat. Vert, il passe à autre chose. Rouge, il voit [exit code: 1], lit quelle assertion a échoué (un 500 là où un 200 était attendu, un champ total manquant, un code de devise incorrect), corrige le gestionnaire et réexécute. La vérification du contrat d'API devient une partie du même cycle d'édition-test-correction que l'agent utilise déjà pour vos tests unitaires.
Remarquez ce que l'agent n'a pas fait : relire chaque fichier de route pour se convaincre que l'API fonctionne. Le scénario encode déjà le comportement attendu, construit visuellement dans Apidog par le propriétaire de l'API. L'agent délègue la vérification à un outil déterministe et dépense ses jetons là où le jugement est nécessaire. Cette division du travail est le schéma complet : dsh écrit le code, la CLI vérifie la couche API, et vous créez des scénarios dans Apidog sans écrire de code de test.
Vérifier que dsh l'a réellement exécuté
Les agents rapportent des succès qu'ils n'ont pas mérités, et un harnais en pré-version développeur n'est pas l'endroit pour prendre la prose pour argent comptant. Trois vérifications, dans l'ordre où elles attrapent les problèmes.
Premièrement, confirmez que la commande a été exécutée. L'interface web de dsh affiche les appels d'outils de l'agent et leur sortie dans la session. Recherchez l'appel bash littéral apidog run ... et son résultat. Si l'agent dit qu'il a exécuté les tests mais qu'aucun appel de ce type n'apparaît, il a résumé quelque chose qu'il n'a jamais fait. Demandez-lui de réexécuter et de montrer la sortie brute.
Deuxièmement, confirmez le code de sortie. Demandez directement : "quel était le code de sortie de cette commande apidog run ?" Le harnais transmet à l'agent un marqueur explicite [exit code: N] en cas d'échec, il n'y a donc aucune ambiguïté pour se cacher. Si le résumé de l'agent dit "tests passés" mais que le marqueur indiquait un nombre non nul, le marqueur a raison.
Troisièmement, vérifiez qu'il a utilisé le scénario réel. Un échec de "scénario introuvable" signifie généralement que l'agent a inventé ou mal mémorisé un ID. Vérifiez à nouveau les valeurs -t et -e par rapport à votre bloc AGENTS.md et à la commande dans l'onglet CI/CD d'Apidog. Les ID dans le fichier de règles sont la vérité ; tout ce que l'agent a tapé d'autre est une supposition.
Optionnel : ajouter le serveur Apidog MCP pour l'accès aux spécifications
L'exécution de scénarios couvre la vérification. Si vous souhaitez également que l'agent lise votre spécification API pendant qu'il écrit du code, c'est un travail pour MCP, et là, la vérité est importante : à fin août 2026, la prise en charge de MCP n'est pas documentée dans le README ou le guide de l'utilisateur du cœur de DeepSeek Harness. Ce qui existe est un plugin communautaire, hyqhyq3/dsh-mcp-manager, découvert via le sujet GitHub dsh-plugin comme le reste de l'écosystème. Il ajoute une page MCP sous Paramètres, prend en charge les serveurs HTTP distants et stdio locaux, enregistre les outils sous mcp__<name>__* et lit les définitions de serveur par projet à partir de <workspace>/.dsh/dshmm/mcp.json.
Grâce à lui, vous pouvez connecter le serveur Apidog MCP, qui expose vos spécifications API via MCP afin que l'agent puisse vérifier le schéma réel d'un point d'accès avant d'écrire le gestionnaire, au lieu d'attendre que le scénario échoue. Plugin communautaire plus hôte en préversion développeur signifie que cette combinaison peut se briser lors d'une mise à jour de l'un ou l'autre côté, alors traitez cela comme une couche bonus. Le chemin CLI ci-dessus est le plus important : il n'a besoin de rien d'autre qu'un shell.
Mises en garde de la préversion et perspectives
DeepSeek Harness évolue rapidement et vous avertit qu'il peut casser des choses. Les éléments les plus susceptibles de changer sont ceux mentionnés ici : les candidats de fichiers du plugin d'instructions, le rapport de bac à sable de l'outil bash, et tout ce que le plugin communautaire MCP touche. Le schéma, cependant, est portable. Un fichier de règles qui dit "vérifiez l'API avec cette seule commande" plus une CLI qui renvoie un code de sortie propre fonctionne dans dsh aujourd'hui pour la même raison qu'il fonctionne dans Claude Code et tous les autres harnais de cette série : les agents sont doués pour lire la sortie de commande et mauvais pour être fiables sans elle.
Alors : téléchargez Apidog, construisez un scénario de test visuellement, copiez sa commande apidog run depuis l'onglet CI/CD, et déposez le bloc dans le fichier AGENTS.md que votre dépôt possède probablement déjà. La prochaine fois que DeepSeek Harness touchera votre code API, il vérifiera son propre travail avant de vous dire que c'est terminé.
FAQ
DeepSeek Harness lit-il nativement AGENTS.md ? Oui. Le plugin @deepseek-ai/dsh-agent-instructions charge AGENTS.md (ou CLAUDE.md en tant que solution de repli) depuis la racine de votre projet et les répertoires au-dessus du répertoire de travail de votre session, plus les superpositions AGENTS.local.md/CLAUDE.local.md et un AGENTS.md global à l'utilisateur dans ~/.dsh. Si vous conservez déjà un AGENTS.md pour d'autres agents, dsh le détecte tel quel.
Ai-je besoin d'un plan payant DeepSeek pour utiliser la CLI Apidog dans dsh ? Non. Le harnais est un logiciel open-source sous licence MIT, et vous apportez votre propre modèle : les fournisseurs de catalogue couvrent Anthropic, OpenAI, Bedrock, Vertex et Azure, et les passerelles personnalisées fonctionnent via settings.yaml, comme expliqué dans comment exécuter n'importe quel modèle dans DeepSeek Harness. La CLI Apidog elle-même est un package npm gratuit ; elle nécessite un scénario de test Apidog et une authentification, pas un modèle spécifique.
Pourquoi la deuxième commande de l'agent oublie-t-elle le répertoire dans lequel la première commande a changé ? Par conception. L'outil bash dsh par défaut exécute chaque appel dans un shell frais, donc cd ne persiste pas entre les commandes. Passez le paramètre workdir de l'outil ou, plus simplement, conservez l'invocation complète de apidog run sur une seule ligne dans votre fichier de règles afin de ne rien oublier.
dsh peut-il exécuter le scénario sans me le demander à chaque fois ? Cela dépend de la politique de permission active. L'interface utilisateur web demande avant les opérations qui nécessitent une approbation ; le guide de l'utilisateur n'énumère pas les niveaux de politique, alors vérifiez les paramètres dans votre build pour voir ce que votre déploiement autorise. Lorsqu'il y a une demande, approuver un apidog run contre un environnement de staging est un oui sûr.