Créer un petit plugin avec DeepSeek Harness Creator
DeepSeek-V4 Team · 8 octobre 2026 · 7 min read
Un premier plugin Harness utile a un rôle bien délimité et un résultat visible. Un panneau qui affiche une liste de contrôle de projet fixe est un meilleur exercice d'apprentissage qu'une extension qui modifie des fichiers, appelle des services externes et gère des identifiants en même temps. Lorsque la petite version fonctionne, vous avez une base pour des changements ultérieurs.
Harness dsh-v0.2.1-alpha.1, publié le 3 octobre 2026, ajoute une entrée du gestionnaire de plugins qui ouvre le mode Creator avec une ébauche préparée. Ce tutoriel utilise ce flux de travail pour concevoir et inspecter un plugin local. Les étapes suivent la documentation de la version concernée ; l'exemple est un exercice de validation, et non une affirmation qu'un package généré a déjà passé un test dans une installation de Harness.
Préparer un espace de travail inspectable
Utilisez une installation dont vous avez vérifié la version, un fournisseur de modèle configuré et un répertoire vide pour cet exercice. Si vous débutez avec Harness, terminez d'abord le démarrage rapide local. Gardez l'exercice séparé de l'unique copie d'un projet important.
Le résultat devrait être un répertoire source de plugin plus une brève explication de la façon dont cette version de Harness le charge. Demandez à l'agent d'identifier l'entrée du package, les dépendances et la configuration du bundle plutôt que de supposer qu'un seul fichier TypeScript est installable via le gestionnaire de plugins.
Choisissez un objectif de validation concrète : un panneau intitulé Liste de contrôle du projet avec trois lignes fixes. La première version ne doit pas découvrir automatiquement les fichiers ni enregistrer l'état. Ce sont des fonctionnalités ultérieures raisonnables, mais chacune ajoute un comportement qui doit être examiné et testé.
Ouvrir Creator et inspecter l'ébauche
Dans la barre latérale, ouvrez Plugins. Utilisez la flèche à côté de Add plugin, puis sélectionnez Let the agent create a plugin. La référence du gestionnaire de plugins documente cette action lorsque le module d'interface du préréglage correspondant fournit cette entrée.
L'action ouvre le mode Creator. Elle ne démarre pas la génération tant que vous n'avez pas envoyé la demande. Vérifiez l'espace de travail sélectionné et toute référence de fichier, de dossier ou de session reportée. Une ancienne référence peut modifier discrètement le projet que l'agent pense qu'il doit modifier.
Utilisez une demande avec un résultat que vous pouvez compter et inspecter :
Créez un plugin Harness local pour cet espace de travail vide. Ciblez la version de Harness installée ici et inspectez sa documentation disponible avant de choisir les API. Ajoutez un panneau Liste de contrôle du projet avec exactement trois lignes statiques : Examiner les entrées, Inspecter la sortie, Enregistrer le résultat. N'utilisez aucune demande réseau, identifiants, écritures automatiques de fichiers ou minuteurs en arrière-plan. Avant de modifier, identifiez les fichiers que vous créerez. Par la suite, expliquez comment charger le bundle local et comment le désactiver. Signalez toute validation que vous n'avez pas pu exécuter.
Les contraintes gardent l'exercice simple. Elles rendent également les dépendances inattendues plus faciles à repérer. Un package pour un panneau statique a peu de raisons d'introduire un client HTTP ou un service de planification.
Lire la structure générée avant de l'installer
Le tutoriel premier-plugin officiel explique le modèle Cordis de base : un plugin exporte une fonction apply, et le contexte qui lui est passé est l'endroit où les contributions sont enregistrées. Le contexte est donc un point de départ utile pour tracer ce que le code généré fera.
Cet exemple introductif n'est pas une recette complète pour un bundle d'interface utilisateur distribuable. Pour le panneau généré, demandez à l'agent de tracer le point d'entrée réel vers son code d'enregistrement et de rendu. Il devrait être possible d'expliquer pourquoi chaque fichier source existe sans lire un tutoriel de framework d'application non pertinent.
Inspectez également le manifeste du package et les scripts d'installation. Confirmez que les dépendances appartiennent à l'implémentation prévue, que les fichiers référencés existent et que les commandes utilisent le répertoire de projet réel. Si l'agent dit qu'une compilation a réussi, conservez la commande et son résultat de sortie. Une explication plausible d'une compilation n'est pas la sortie de la compilation.
| Élément à inspecter | Preuves à rechercher |
|---|---|
| Point d'entrée | Le manifeste ou la configuration du bundle résout vers un fichier réel |
| Enregistrement du panneau | Un appel spécifique connecte le plugin à son interface utilisateur visible |
| Dépendances | Chaque package ajouté a un objectif expliqué |
| Cycle de vie | La désactivation du plugin supprime sa contribution proprement |
| Validation | Les commandes, les résultats et les comportements restants non testés sont indiqués |
Installer le bundle local et vérifier la version chargée
Retournez à Plugins → Add plugin. Le gestionnaire accepte un répertoire local absolu ainsi que les packages du registre et les sources Git. Utilisez le répertoire que les instructions d'installation générées identifient comme la racine du bundle, et non le dossier imbriqué qui contient fortuitement un fichier source.
Lisez l'aperçu d'installation et l'avis de confiance, puis installez et activez les lignes de bundle ou de plugin pertinentes. Le gestionnaire distingue les bundles installés de l'inventaire intégré affiché dans les Paramètres. Si le panneau est absent, vérifiez que la ligne prévue est activée avant de modifier le code source.
Conservez l'identité du package et la version affichée avec vos notes de test. La version d'octobre améliore le rapport de version et la visibilité de la source du code. Un package installé plus ancien peut sinon faire paraître une modification correcte comme inefficace. La surveillance du répertoire de développement et le remplacement d'une version de package installée sont des chemins différents ; ce dernier nécessite toujours un redémarrage.
Tester un cycle complet d'activation et de désactivation
Activez d'abord le plugin et inspectez le panneau. Comptez les lignes, vérifiez leur ordre et assurez-vous que le texte correspond à la demande. Désactivez ensuite le plugin et confirmez que le panneau disparaît. Activez-le à nouveau et vérifiez qu'il apparaît une fois, sans entrée dupliquée ni élément restant.
Ensuite, modifiez une ligne de texte dans la source, en utilisant le flux de travail de développement documenté pour le bundle généré. Vérifiez si le panneau visible reflète la modification. Si ce n'est pas le cas, établissez le chemin de la source chargée et les exigences de redémarrage avant de demander à l'agent de réécrire le composant.
Enfin, rouvrez l'application et répétez les vérifications visibles. Enregistrez les étapes qui ont réussi et celles qui nécessitaient un redémarrage. Ces observations vous en disent plus sur le cycle de vie réel du plugin qu'une seule capture d'écran réussie.
Diagnostiquer les échecs au bon niveau
Un panneau manquant peut signifier plusieurs choses : le chemin du package n'a pas pu être résolu, le bundle n'a pas été activé, l'enregistrement a échoué ou le rendu a échoué. Vérifiez ces étapes dans cet ordre. La documentation Cordis introductive note spécifiquement qu'un échec de résolution peut être moins évident lors du démarrage initial, donc vérifiez l'orthographe du chemin lorsqu'une nouvelle entrée semble ne rien faire.
Pour les anciens exemples, surveillez les exports invariant supprimés et le changement de la ligne stats de la zone de saisie de message vers activity et usage. Ce sont des problèmes de migration spécifiques à la version décrits dans les notes de version 0.2.1. Ce ne sont pas des raisons pour désactiver largement les vérifications de compatibilité.
Une fois le panneau statique validé, ajoutez une capacité à la fois. La lecture d'un fichier local choisi est une prochaine étape gérable si le chemin et le comportement d'échec sont explicites. Laissez la persistance et les demandes externes pour des itérations séparées. Conservez la version minimale fonctionnelle afin qu'un échec ultérieur puisse être comparé à quelque chose que vous avez effectivement observé fonctionner.
Pour le contexte de mise à jour plus large, consultez la revue Harness 0.2.1. Si votre plugin prévu existe uniquement pour déclencher un rappel, vérifiez d'abord le flux de travail d'automatisation intégré ; l'application hôte peut déjà fournir le comportement de planification dont vous avez besoin.