TokenLab

Outils de code

DeepSeek Harness

Configurer un modèle TokenLab dans Harness, vérifier une requête et choisir MCP, Skills ou le bundle de fournisseur

Choisir la connexion adaptée

Pour utiliser TokenLab comme modèle principal de l'agent, ajoutez un custom provider dans l'interface Web de Harness. Cette configuration fonctionne indépendamment du bundle TokenLab facultatif. Ajoutez des outils MCP pour les médias et d'autres API, ou un Skill pour obtenir des instructions d'utilisation des API ; ni l'un ni l'autre ne change le modèle principal à lui seul.

Harness est une préversion destinée aux développeurs. Ces étapes pour l’interface Web ont été vérifiées le 27 septembre 2026 à partir de la documentation officielle et du paquet publié @deepseek-ai/dsh 0.1.5-rc.3. Les instructions du bundle ci-dessous ciblent aussi cette version ; vérifiez séparément la compatibilité avec les autres versions de Harness.

Confier cette tâche à votre agent

Lis https://tokenlab.sh/docs/fr/integrations/deepseek-harness et vérifie ma version installée ainsi que mon système d'exploitation.
Confirme si j'ai besoin de TokenLab comme modèle principal, d'outils MCP ou de Skills pour les API.
Conserve les comptes, la configuration des fournisseurs et les autorisations existants ; explique comment restaurer les paramètres modifiés.
Ne me demande pas de coller des clés API dans le chat. Je saisirai la clé localement et effectuerai les étapes nécessaires dans l'interface.
Explique le coût d'une petite requête de vérification. Seulement après mon choix explicite d'effectuer ce test, aide-moi à l'exécuter et à retrouver l'enregistrement correspondant dans TokenLab Requests.

Démarrer Harness

Utilisez la CLI Node sous macOS, Linux ou Windows avec une version de Node prise en charge ; Node 24 LTS constitue un bon point de départ. Depuis le répertoire de votre projet, exécutez ces commandes dans un terminal ou PowerShell :

node --version
npx @deepseek-ai/dsh@0.1.5-rc.3 web

Ouvrez l'URL locale affichée par la commande. Lors de la première utilisation de l'interface Web, utilisez Choose workspace pour ajouter et sélectionner le répertoire de votre projet avant d'envoyer un message. Ces commandes utilisent le profil web ; le profil desktop de l'application Electron n'est pas géré par cette procédure CLI. Consultez le guide de démarrage et le guide de l'interface Web officiels.

Configurer un fournisseur TokenLab

  1. Ouvrez Settings → Models → Add a custom provider. Conservez les fournisseurs et les autorisations existants.
  2. Saisissez un Provider ID en minuscules, par exemple tokenlab-chat, puis choisissez un protocole et la Base URL correspondante dans le tableau ci-dessous. Chaque fournisseur utilise un seul protocole.
  3. Saisissez votre clé API TokenLab dans le formulaire local. Harness enregistre les clés gérées par l'interface dans $DSH_HOME/.credentials.yaml ; le document de configuration contient une référence. N'envoyez pas la clé dans le chat et ne l'incluez pas dans un commit.
  4. Ajoutez un identifiant de modèle actuel du catalogue TokenLab. Vérifiez son champ tokenlab.accepted_request_formats dans l'API de détail des modèles, sans déduire les formats pris en charge de son nom.
  5. Enregistrez le fournisseur, sélectionnez son modèle et démarrez une nouvelle session. Une session existante ayant déjà envoyé une requête conserve le modèle enregistré pour cette session.
Exemple de Provider IDProtocole API HarnessBase URLFormat de requête requis
tokenlab-chatopenai-completionshttps://api.tokenlab.sh/v1openai_chat_completions
tokenlab-responsesopenai-responseshttps://api.tokenlab.sh/v1openai_responses
tokenlab-messagesanthropic-messageshttps://api.tokenlab.shanthropic_messages

Pour une première requête texte, une entrée gpt-4.1-mini actuellement disponible peut utiliser la ligne Chat. Fetch available models → Add selected peut faciliter la configuration d'un custom provider, mais une liste de modèles obtenue avec succès ne valide ni la prise en charge du protocole ni l'exécution d'une requête facturable ; enregistrez ensuite le fournisseur. Saisissez l'identifiant manuellement si la découverte n'est pas disponible.

Harness ne propose pas ici de protocole Gemini natif pour les custom providers. Utilisez Chat uniquement si les détails du modèle indiquent Chat Completions comme format de requête accepté. Les entrées d'image et les réglages de raisonnement peuvent nécessiter des champs supplémentaires dans settings.yaml ; consultez la configuration des fournisseurs Harness et les champs pris en charge par le modèle sélectionné avant de les activer.

Vérifier une petite requête

Dans la nouvelle session, envoyez :

Reply only with TOKENLAB_CONNECTION_OK. Do not use tools or modify files.

Cette requête est facturable. Vérifiez la réponse ainsi que le modèle, l'heure et le statut correspondants dans TokenLab Requests. Arrêtez-vous après ce test texte : il n'est pas nécessaire de tester les trois protocoles ni de générer des médias payants pour établir la première connexion. La liste des modèles ou la découverte MCP ne suffit pas à valider les droits de génération de la clé.

Facultatif : le bundle TokenLab

@tokenlabai/dsh-provider@0.1.5 cible Harness 0.1.5-rc.3. Utilisez les étapes natives ci-dessus pour configurer un seul modèle, ou installez le bundle pour ses routes de modèles et ses outils préconfigurés.

Le bundle contient un instantané fixe de 136 modèles de chat publics, vérifié le 27 septembre 2026 : Responses 27, Messages 10 et Chat 99. Chaque modèle figure sur une seule route. Il utilise la version fixe @tokenlabai/mcp-server@0.6.24 et inclut l’outil distinct tokenlab_wait_task. L’installation de cette version n’actualise pas le catalogue. Vérifiez les identifiants dans le catalogue actuel et ajoutez les modèles plus récents via un custom provider si nécessaire.

Pour une installation Harness existante et compatible, vérifiez d'abord que pnpm est disponible dans PATH. Utilisez le même exécutable dsh, la même version et le même profil pour l'installation et le démarrage. Si vous lancez Harness via npx, remplacez dsh ci-dessous par cette même commande de lancement avec sa version :

dsh --version
pnpm --version
dsh plugin --profile web add --workspace-root @tokenlabai/dsh-provider@0.1.5

Avant de démarrer ce profil, définissez la clé dans l'environnement de lancement ou dans le fichier .env qu'il lit :

TOKENLAB_API_KEY=sk-your-tokenlab-key

Harness lit .env dans le répertoire depuis lequel vous le lancez et dans $DSH_HOME (généralement ~/.dsh) ; une variable d'environnement héritée est prioritaire. Sélectionner un espace de travail par la suite ne sélectionne pas un autre .env. Excluez ce fichier de Git et redémarrez après toute modification. Une clé enregistrée dans l'interface pour un custom provider ne fournit pas automatiquement le TOKENLAB_API_KEY requis par le bundle.

Redémarrez le même profil, puis examinez ses listes de modèles et d'outils. Pour headless, effectuez l'installation et le lancement avec headless plutôt qu'avec web ; installer le bundle dans un profil ne configure pas l'autre.

Harness 0.1.5-rc.3 fusionne les llm-pi-ai.providers enregistrés par clé de fournisseur. Les fournisseurs dont les clés diffèrent coexistent. Les entrées enregistrées tokenlab-responses, tokenlab-messages ou tokenlab-chat remplacent la route homonyme du bundle ; vérifiez-les lors de la mise à jour d’un ancien catalogue. Conservez les autres fournisseurs et modèles dans $DSH_HOME/settings.yaml ; ne remplacez pas tout le document de configuration par le patch Cordis.

Les détails publics des modèles indiquent leur capacité de raisonnement, mais n’énumèrent pas les valeurs d’effort prises en charge par modèle. Le bundle ne déclare donc pas reasoningEfforts. Harness ne propose pas de niveaux d’effort pour ces routes personnalisées ; cela ne désactive pas le raisonnement côté serveur. Pour configurer vous-même reasoningEfforts, utilisez uniquement des valeurs vérifiées séparément dans l’entrée du modèle de la liste models du fournisseur, en conservant les autres modèles. La capacité de raisonnement seule ne prouve pas la prise en charge de xhigh ou max.

Le bundle utilise par défaut TOKENLAB_MCP_TOOL_PROFILE=core, avec 32 outils MCP, et TOKENLAB_MCP_SCHEMA_MODE=portable. Choisissez catalog pour la découverte seule (6 outils), ou full pour les 89 outils, avec notamment les opérations supplémentaires de cycle de vie des réponses, de batch, d’assets et groupes Seedance, et de worlds. L’outil de suivi distinct tokenlab_wait_task reste disponible dans chaque profil et n’est pas compris dans ces nombres d’outils MCP. TOKENLAB_API_BASE et TOKENLAB_ANTHROPIC_BASE_URL valent par défaut https://api.tokenlab.sh ; TOKENLAB_OPENAI_BASE_URL vaut https://api.tokenlab.sh/v1.

Pour les outils multimédias du bundle, examinez delivery.mode : utilisez directement la sortie complete ; pour un résultat async, transmettez delivery.task_id à tokenlab_wait_task, puis lisez le status terminal, la response et les result_urls. Un délai d'attente expiré ne signifie pas que la tâche est terminée. Conservez les approbations pour les outils facturables ou destructifs. Consultez les tâches asynchrones.

Pour retirer le bundle, utilisez la même commande de lancement et le même profil, puis redémarrez :

dsh plugin --profile web remove --workspace-root @tokenlabai/dsh-provider

En cas de problème

  • La zone de saisie est désactivée : sélectionnez à la fois un espace de travail et un modèle.
  • MISSING_CREDENTIAL ou 401 : vérifiez les identifiants du fournisseur sélectionné. Pour les outils du bundle, vérifiez TOKENLAB_API_KEY dans l'environnement de lancement ; la clé de modèle enregistrée dans l'interface est un paramètre distinct.
  • UNKNOWN_MODEL ou un identifiant retiré : consultez le catalogue actuel, configurez l'identifiant exact disponible, puis créez une nouvelle session. Réinstaller le bundle 0.1.5 n'actualise pas son instantané.
  • L'URL est accessible, mais la génération échoue : comparez le protocole, la Base URL et les formats acceptés par le modèle. Ne supprimez pas l'historique, les outils ou les entrées d'image uniquement pour transformer un échec en test réussi.
  • dsh ou pnpm est introuvable : utilisez la commande npx avec version indiquée ci-dessus pour Harness ; installez pnpm avant d'utiliser les commandes de plugin. Un échec d'installation du plugin n'est pas un problème de clé API.

MCP et Skills sont des choix distincts

Un custom provider ajouté manuellement n'installe pas d'outils. Suivez le guide MCP TokenLab si vous avez besoin d'outils API appelables sans le bundle, et vérifiez leur découverte avant toute génération.

Pour les TokenLab Skills, conservez le dossier complet du Skill dans .dsh/skills/tokenlab-api-integration/ à la racine du projet, y compris SKILL.md et les fichiers référencés. Harness découvre également .agents/skills/. Ces instructions n'installent ni fournisseur, ni serveur MCP, ni clé. La référence officielle des Skills sur le système de fichiers définit les emplacements pris en charge.

Jev / System One & Webhooks

Pour Jev (POST /v1/systemone), utilisez mcp__tokenlab__evaluate_decisions dans core ou full. Vérifiez category=decision et les détails du modèle. Ces décisions synchrones ne sont ni des modèles de chat ni des tâches asynchrones : n’utilisez pas le sélecteur ou tokenlab_wait_task.

Les webhooks exigent full et un TOKENLAB_MANAGEMENT_TOKEN=mt-... distinct dans l’environnement de lancement, transmis explicitement à MCP. La clé d’inférence ne le remplace pas. Ce token autorise aussi d’autres opérations de gestion ; l’enregistrement ne transforme pas Harness en récepteur.

Sur cette page