Comment utiliser Apidog CLI dans DeepSeek Harness

DeepSeek Harness est une boucle : l’agent lit votre espace de travail, modifie des fichiers, exécute des commandes via son outil bash, puis choisit la prochaine étape selon le résultat. Alors, pourquoi vos tests d’API restent-ils hors de cette boucle ? Ils sont stockés dans Apidog derrière une interface graphique et ne s’exécutent que lorsqu’une personne pense à cliquer. L’agent ne les utilise jamais.

Essayez Apidog dès aujourd’hui

La solution tient dans un bloc de configuration. L’interface de ligne de commande Apidog, le package npm apidog-cli, exécute les scénarios créés dans Apidog depuis un terminal. Une fois la CLI installée et déclarée dans les instructions de DeepSeek Harness, l’agent exécute un scénario Apidog comme vos tests unitaires : il lance la commande, lit le code de sortie et corrige le code si le test échoue.

Un agent qui relit vos gestionnaires et raisonne sur les réponses API consomme du contexte à chaque passage. Un agent qui lance une commande obtient un résultat concret en quelques lignes. La CLI transforme la question « l’API est-elle correcte ? » en code de sortie ; l’agent peut alors consacrer son contexte à la correction.

Ce guide couvre la partie spécifique à DeepSeek Harness : quel fichier d’instructions il lit, comment son outil bash exécute apidog run, et comment vérifier que la boucle est réellement exécutée. Installez d’abord la CLI si ce n’est pas déjà fait. Le guide 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 cette commande fonctionne déjà :

apidog --version

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, disponible sur github.com/deepseek-ai/deepseek-harness et avait dépassé les 169 000 étoiles au 20 août.

Démarrez-le avec :

npx @deepseek-ai/dsh web

L’interface web locale est servie sur :

http://127.0.0.1:3080

Vous choisissez un espace de travail, puis l’agent travaille dans ce répertoire : il lit et modifie des fichiers, exécute des commandes et demande une approbation lorsque la politique de permissions l’exige.

Deux éléments sont importants :

1. DeepSeek Harness est une version préliminaire pour développeurs. Son README avertit que des changements cassants sont possibles. Vérifiez donc les noms de fichiers et les clés de configuration dans la documentation du dépôt si une configuration ne se charge pas.
2. Tout dans dsh est un plugin, construit sur l’architecture Cordis. La question pratique est donc : quel plugin lit les règles du projet, et quels fichiers recherche-t-il ?

Pour plus de contexte, consultez ce qu’est DeepSeek Harness et DeepSeek Harness vs Claude Code.

Étape 1 : Ajouter la CLI dans AGENTS.md

DeepSeek Harness lit les instructions du workspace avec le plugin @deepseek-ai/dsh-agent-instructions.

D’après le plugin et le catalogue de configuration, le chargeur :

• remonte depuis le répertoire de travail de la session jusqu’à la racine du projet marquée par .git ;
• charge AGENTS.md ;
• utilise CLAUDE.md comme solution de repli ;
• charge les fichiers trouvés dans chaque répertoire du chemin ;
• charge ensuite les surcharges AGENTS.local.md ou CLAUDE.local.md ;
• applique aussi un fichier global $DSH_HOME/AGENTS.md, où $DSH_HOME vaut par défaut ~/.dsh.

Les fichiers de plus de 1 Mio sont ignorés.

Si votre dépôt possède déjà un AGENTS.md utilisé par Codex, ou un CLAUDE.md utilisé par Claude Code, DeepSeek Harness le détecte sans configuration supplémentaire.

Ajoutez ce bloc au fichier de règles du dépôt :

## 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.

Le fichier de règles est plus fiable qu’une instruction saisie dans le chat :

• une consigne de session disparaît à la fin de la session ;
• une commande dans AGENTS.md est rechargée à chaque nouvelle session ;
• tous les membres de l’équipe qui clonent le dépôt disposent de la même instruction.

Si vous gérez plusieurs projets, utilisez ~/.dsh/AGENTS.md pour une règle globale, par exemple :

Toujours vérifier les changements d'API avec la commande apidog run définie dans le projet.

Conservez les identifiants réels du scénario et de l’environnement dans le AGENTS.md propre à chaque dépôt.

Étape 2 : Copier la commande Apidog générée

Ne devinez pas les identifiants de scénario et d’environnement.

Dans Apidog :

1. Ouvrez le scénario de test.
2. Accédez à l’onglet CI/CD.
3. Copiez la commande générée.

Elle ressemble à ceci :

apidog run -t 123456 -e 789012 -r cli

Les options sont les suivantes :

Option	Rôle
-t	ID du scénario de test
-e	ID de l’environnement
-r cli	Rapporteur CLI avec une sortie lisible dans le terminal

Collez les ID réels dans AGENTS.md. L’agent doit exécuter la commande générée par Apidog, et non inventer ou mémoriser des valeurs.

Étape 3 : Demander à l’agent d’exécuter le test

Démarrez une session dsh avec votre workspace sélectionné. Les instructions contenues dans AGENTS.md sont déjà présentes dans le contexte de l’agent.

Après une modification qui touche l’API, demandez simplement :

Exécutez le scénario de test Apidog et dites-moi le code de sortie.

L’agent lance la commande via son outil bash.

D’après le catalogue d’outils, chaque appel bash s’exécute dans un shell frais :

• le répertoire courant ne persiste pas ;
• les variables d’environnement définies pendant une commande ne persistent pas ;
• les fonctions shell ne persistent pas ;
• la commande s’exécute depuis le workspace de session, sauf si un workdir est fourni.

Cela fonctionne bien pour une commande autonome comme :

apidog run -t 123456 -e 789012 -r cli

En revanche, l’agent ne peut pas faire ceci dans deux appels distincts :

cd packages/api

Puis :

apidog run -t 123456 -e 789012 -r cli

Si votre test doit être lancé depuis un sous-répertoire, utilisez une seule commande complète dans les règles du projet :

cd packages/api && apidog run -t 123456 -e 789012 -r cli

Deux autres comportements sont utiles à connaître :

• Une sortie non nulle est signalée avec un marqueur explicite, par exemple [exit code: 1].
• Une commande bloquée par le bac à sable de fichiers est signalée comme un refus de politique, pas comme un échec de test.

Un scénario en lecture seule déclenche rarement ce problème. En revanche, le rapporteur HTML peut écrire dans ./apidog-reports, selon la politique active.

L’exécution peut aussi demander votre approbation dans l’interface dsh. Le guide utilisateur indique que l’interface demande une validation pour les opérations concernées par la politique de permissions. Lorsqu’elle apparaît pour apidog run, approuvez-la si le scénario cible un environnement de staging adapté.

Étape 4 : Lire le rapport et corriger

Avec -r cli, l’agent reçoit une sortie détaillée dans le terminal :

• chaque requête ;
• chaque assertion ;
• l’assertion en échec ;
• la valeur attendue ;
• la valeur réellement reçue.

Par exemple, le test peut signaler :

• un code 500 reçu au lieu de 200 ;
• un champ total absent ;
• un code devise incorrect ;
• une réponse qui ne correspond plus au contrat attendu.

L’agent peut utiliser cette sortie pour localiser le gestionnaire, corriger le code et relancer exactement le même scénario.

Pour produire aussi un rapport consultable dans un navigateur, ajoutez le rapporteur HTML :

apidog run -t 123456 -e 789012 -r cli,html

Le rapporteur html écrit un fichier autonome dans :

./apidog-reports

Gardez toujours cli dans la liste des rapporteurs : l’agent a besoin de cette sortie en ligne pour décider de l’étape suivante.

La boucle complète

Sans la CLI, la boucle de l’agent se termine souvent par :

Le code semble correct.

Avec une commande Apidog dans AGENTS.md, la boucle devient :

1. L’agent modifie un gestionnaire ou une route.
2. Il exécute le scénario :

   apidog run -t 123456 -e 789012 -r cli

1. Il lit le résultat.
2. Si le code de sortie est 0, il continue.
3. Si le résultat contient [exit code: 1], il lit l’assertion en échec.
4. Il corrige le code.
5. Il relance le scénario.

La vérification du contrat API devient alors une étape du même cycle édition-test-correction que les tests unitaires.

L’agent n’a pas besoin de relire chaque route pour estimer si l’API fonctionne. Le scénario encode déjà le comportement attendu, créé visuellement dans Apidog par le propriétaire de l’API.

La répartition est simple :

• dsh écrit ou modifie le code ;
• la CLI Apidog vérifie l’API ;
• vous maintenez les scénarios dans Apidog sans écrire de code de test.

Vérifier que dsh a réellement exécuté le test

Ne vous fiez pas uniquement au résumé de l’agent. Vérifiez trois éléments.

1. Vérifier l’appel bash

L’interface web de dsh affiche les appels d’outils et leurs sorties.

Recherchez l’appel bash exact :

apidog run ...

Si l’agent affirme avoir exécuté les tests mais qu’aucun appel bash correspondant n’apparaît, demandez-lui de relancer la commande et d’afficher la sortie brute.

2. Vérifier le code de sortie

Demandez explicitement :

Quel était le code de sortie de cette commande apidog run ?

En cas d’échec, le harnais transmet un marqueur tel que :

[exit code: 1]

Si l’agent écrit « les tests sont passés » alors que la sortie indique un code non nul, le code de sortie fait foi.

3. Vérifier les identifiants utilisés

Une erreur du type « scénario introuvable » indique généralement que l’agent a utilisé un ID inventé ou incorrect.

Comparez les valeurs utilisées avec :

• le bloc AGENTS.md ;
• la commande générée dans l’onglet CI/CD d’Apidog.

Les identifiants présents dans le fichier de règles sont la source de vérité.

Optionnel : ajouter le serveur Apidog MCP pour lire les spécifications

L’exécution de scénarios couvre la vérification. Si vous voulez aussi que l’agent lise la spécification API pendant qu’il écrit le code, vous pouvez utiliser MCP.

À fin août 2026, la prise en charge MCP n’est pas documentée dans le README ou le guide utilisateur du cœur de DeepSeek Harness. Il existe toutefois un plugin communautaire, hyqhyq3/dsh-mcp-manager, découvert via le sujet GitHub dsh-plugin.

Ce plugin :

• ajoute une page MCP dans les paramètres ;
• prend en charge les serveurs HTTP distants et stdio locaux ;
• enregistre les outils sous mcp__<name>__* ;
• lit les définitions de serveur par projet depuis :

  <workspace>/.dsh/dshmm/mcp.json

Vous pouvez l’utiliser pour connecter le serveur Apidog MCP, qui expose vos spécifications API via MCP.

L’agent peut alors vérifier le schéma réel d’un endpoint avant d’écrire ou de modifier son gestionnaire.

Considérez toutefois cette intégration comme une couche supplémentaire : le plugin est communautaire et DeepSeek Harness est en préversion. La CLI reste le chemin le plus direct, car elle ne nécessite qu’un shell et une commande fiable.

Mises en garde et perspective

DeepSeek Harness évolue rapidement. Les éléments les plus susceptibles de changer sont :

• les fichiers recherchés par le plugin d’instructions ;
• le comportement du bac à sable de l’outil bash ;
• les intégrations du plugin MCP communautaire.

Le schéma reste portable :

1. Définir une commande de vérification API dans un fichier de règles.
2. Exécuter cette commande depuis l’agent.
3. Utiliser le code de sortie et la sortie CLI comme signal fiable.

Cette approche fonctionne dans dsh pour la même raison qu’elle fonctionne dans Claude Code et dans les autres harnais : les agents lisent bien les sorties de commandes, mais ne sont pas fiables lorsqu’ils doivent déduire seuls qu’une API fonctionne.

Téléchargez Apidog, créez un scénario visuellement, copiez la commande apidog run depuis l’onglet CI/CD et ajoutez-la au AGENTS.md du dépôt. Lors de la prochaine modification de votre code API, DeepSeek Harness pourra vérifier son propre travail avant de déclarer la tâche terminée.

FAQ

DeepSeek Harness lit-il nativement AGENTS.md ?

Oui. Le plugin @deepseek-ai/dsh-agent-instructions charge AGENTS.md, ou CLAUDE.md comme solution de repli, depuis la racine du projet et les répertoires situés au-dessus du répertoire de travail de la session.

Il charge aussi :

• AGENTS.local.md ;
• CLAUDE.local.md ;
• un AGENTS.md global dans ~/.dsh.

Si vous utilisez déjà AGENTS.md pour d’autres agents, dsh peut le lire tel quel.

Ai-je besoin d’un plan payant DeepSeek pour utiliser la CLI Apidog dans dsh ?

Non. DeepSeek Harness est open source sous licence MIT et vous apportez votre propre modèle. Les fournisseurs du catalogue couvrent Anthropic, OpenAI, Bedrock, Vertex et Azure. Des passerelles personnalisées sont aussi possibles via settings.yaml, comme expliqué dans comment exécuter n’importe quel modèle dans DeepSeek Harness.

La CLI Apidog est un package npm gratuit. Elle nécessite un scénario de test Apidog et une authentification, mais pas un modèle spécifique.

Pourquoi la deuxième commande de l’agent oublie-t-elle le répertoire défini par la première ?

C’est le comportement prévu. L’outil bash de dsh exécute chaque appel dans un shell frais, donc un cd ne persiste pas entre deux commandes.

Utilisez le paramètre workdir de l’outil lorsque disponible, ou placez toute l’invocation sur une seule ligne :

cd packages/api && apidog run -t 123456 -e 789012 -r cli

dsh peut-il exécuter le scénario sans me demander une approbation à chaque fois ?

Cela dépend de la politique de permissions active. L’interface web demande une validation pour les opérations qui nécessitent une approbation. Le guide utilisateur ne liste pas les niveaux de politique : vérifiez donc les paramètres de votre build.

Lorsqu’une demande apparaît, un apidog run contre un environnement de staging est généralement une commande appropriée à approuver.