Guide · Mis à jour le 10 novembre 2026 · Par Cameron Voss et West Mao

Configurer DeepSeek SuperAgent sur GitHub : de l’Issue à la Pull Request (novembre 2026)

Un chemin pratique depuis un compte d'agent dédié vers une petite Pull Request révisable.

Réponse rapide

Exécutez le prototype dans un environnement dédié, connectez un dépôt et un compte GitHub distinct pour l’agent, puis autorisez uniquement un demandeur de confiance. Confiez-lui une petite Issue et examinez le ticket, la branche, les tests et la Pull Request. Le mode Observe n’empêche pas une demande explicite de lancer le travail.

DeepSeek SuperAgent est un prototype de recherche construit sur DeepSeek Harness, et non un produit DeepSeek officiel ou un logiciel prêt pour la production. Il nécessite un fournisseur de modèles configuré séparément. Ce guide suit la documentation publiée ; nous n'avons pas exécuté de déploiement de bout en bout pour cet article.

Une première tâche utile est suffisamment petite pour être révisée en quelques minutes : corriger une commande obsolète dans le README d'un référentiel de test. L'exemple ci-dessous est un plan d'essai et non une exécution enregistrée. L'agent peut poser des questions, échouer à une vérification ou ne produire aucune Pull Request.

De quoi avez-vous besoin avant de connecter GitHub ?

Le guide de déploiement publié nécessite Node.js 22.19+ ou 24+, pnpm, Git 2.32+, Python 3.8+, tmux, GitHub CLI 2.48+, une installation DeepSeek Harness compatible et un fournisseur de modèles configuré. La documentation épingle @deepseek-ai/dsh@0.2.1-rc.3 pour son exemple ; vérifiez la gamme engines.dsh actuelle du prototype avant de choisir une autre version. Le projet cible un référentiel sur github.com ; GitHub Enterprise Server n'est pas pris en charge par la source documentée.

PréparerPourquoi c'est important
Compte de système d'exploitation séparé ou hôte isoléLes travailleurs s'exécutent avec les autorisations de système d'exploitation du compte de service. Gardez les informations d'identification personnelles et les fichiers non liés hors de portée.
Référentiel de testUtilisez un petit référentiel sans secrets de production ni privilèges de déploiement. Conservez un clone local pour les arbres de travail par ticket.
Utilisateur GitHub dédiéL'agent a besoin de sa propre identité utilisateur et de son propre accès au référentiel. La source documentée lit les notifications de ce compte.
Demandeur de confianceCommencez avec votre propre connexion GitHub dans la liste autorisée. Conservez la fusion automatique et utilisez la protection des branches.
Fournisseur de modèlesConfigurez un fournisseur fonctionnel dans Harness. Les frais de modèle et d'hébergement sont distincts du code sous licence MIT.

L'identité GitHub et le compte du système d'exploitation résolvent différents problèmes. Des informations d'identification GitHub distinctes n'empêchent pas un travailleur de lire les fichiers auxquels son compte de système d'exploitation peut accéder.

Comment préparer le runtime et le compte d'agent ?

  1. Installez les outils requis dans l'environnement qui exécutera le service. Vérifiez leurs versions avec node -v, pnpm -v, git --version, python3 --version, tmux -V, gh --version et dsh --version.
  2. Accordez à l'utilisateur GitHub dédié de l'agent un accès au référentiel de test. Connectez le wrapper GitHub CLI de l'agent à ce compte, et non à votre compte personnel, et confirmez la connexion qu'il renvoie.
  3. Clonez et créez le référentiel deepseek-ai/dsh-superagent-prototype dans l'environnement de service. Le SETUP.md du projet décrit une configuration assistée par un agent ; son guide de déploiement fournit des étapes manuelles.
  4. Créez un profil SuperAgent Harness distinct uniquement pour une nouvelle installation, installez le bundle et configurez le répertoire d'état et le panneau du profil. Ne recréez pas un profil existant : la commande de création de profil documentée remplace sa configuration.
  5. Démarrez le service et vérifiez scripts/dsh-superagent status. Lors d'un premier démarrage, on peut s'attendre à des informations de configuration manquantes ; résolvez-le avant d'envoyer une tâche.

Pour un nouveau profil, l'exemple de déploiement publié utilise la séquence suivante. Exécutez-le dans l’environnement de service isolé après avoir examiné le référentiel et les conditions préalables. Remplacez REPOSITORY_URL par l'URL du référentiel public deepseek-ai/dsh-superagent-prototype.

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone REPOSITORY_URL dsh-superagent
cd dsh-superagent
pnpm install && pnpm build
# New profile only: this replaces an existing superagent profile.
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

La configuration manuelle publiée nécessite ensuite une configuration machine basée sur examples/profile.cordis.patch.yml. Définissez un stateDir absolu et les paramètres de liaison locaux du panneau avant de démarrer le service. Consultez l'exemple et le guide de déploiement actuel dans le référentiel extrait plutôt que de copier les espaces réservés dans une configuration en cours d'exécution.

scripts/dsh-superagent start
scripts/dsh-superagent status

Gardez les secrets du problème, de la transcription du chat et du référentiel. Définissez les informations d'identification via le flux de connexion prévu, puis vérifiez le compte et les autorisations dans votre propre environnement.

Quels réglages transforment une Issue en ticket ?

Dans le panneau SuperAgent, configurez la source GitHub avec le référentiel et le wrapper CLI de l'agent. Sous stratégie, ajoutez la connexion GitHub du demandeur à la liste autorisée. Configurez l'exécution avec une source de paiement et une commande de préparation qui donne à chaque ticket son propre arbre de travail. Un arbre de travail permet d'organiser les modifications ; ce n'est pas un bac à sable de sécurité.

Commencez avec observe comme mode d'acceptation pour l'activité déduite et laissez la fusion automatique désactivée. Vérifiez que la source signale qu'elle est prête et que l'état ne signale plus une configuration manquante. Le panel pourra utiliser une formulation différente dans une version ultérieure ; enregistrez vos versions installées avant le dépannage.

Que faut-il écrire dans la première Issue GitHub ?

À partir du compte demandeur autorisé, ajoutez un commentaire qui s'adresse à l'agent. Remplacez le nom par le login réel de votre agent :

@agent-login Please update the README installation example to match the current package name. Limit the change to the README, run the relevant documentation check, and open a pull request for human review. Do not merge.

Il s'agit d'une demande explicite. S'il est accepté, il peut s'exécuter même si le travail déduit se trouve dans observe. L'intervalle d'interrogation par défaut documenté est d'une minute, mais un ticket ou un PR n'est pas garanti. Si le corps d'un problème a été modifié pour ajouter une mention et que rien ne se passe, publiez plutôt la mention sous forme de commentaire.

Comment examiner le ticket et la Pull Request ?

  1. Ouvrez l'aperçu et recherchez le ticket. Confirmez que le problème, le demandeur et la description de la tâche correspondent à ce que vous souhaitiez.
  2. Inspectez si le ticket est en file d'attente, fonctionne, bloqué ou en attente d'examen. Une question ou un statut bloqué a besoin d'une personne ; cela ne constitue pas une preuve d'un correctif terminé.
  3. Ouvrez la branche proposée et le PR. Vérifiez les fichiers modifiés, validez l'identité et la différence exacte. Confirmez qu'aucun secret ou modification sans rapport n'a été ajouté.
  4. Exécutez ou inspectez les vérifications pertinentes de manière indépendante. Demandez une correction dans le fil de discussion existant si nécessaire ; conserver la demande dans le cadre de la tâche d'origine.
  5. Seule une personne disposant de l'autorité de référentiel appropriée doit approuver et fusionner le résultat examiné lors de ce premier essai.

Que faire si aucun ticket n'apparaît ?

SymptômePremière vérification
Aucune réponse à une mentionVérifiez que la source est activée, que le traitement n'est pas suspendu et que le demandeur est autorisé. Utilisez un nouveau commentaire plutôt qu'un corps de problème modifié.
L'agent CLI ne peut pas lire son compteVérifiez le wrapper configuré et signez ce wrapper dans le compte d'agent dédié.
L'agent ne peut pas lire ou pousserConfirmez le nom du référentiel et l'accès réel du compte de l'agent.
Préparer la commande échecErreur de lecture du ticket ; vérifiez le chemin du clone, la destination de l'arbre de travail et la configuration Git.
Le statut renvoie 3Le service est en attente d'installation. Lisez l'exigence manquante au lieu de redémarrer à plusieurs reprises.

Un Coding Plan peut-il exécuter ce prototype ?

SuperAgent utilise le fournisseur de modèles configuré dans Harness. Nous n'avons pas vérifié que ce prototype fonctionne avec les Coding Plans de ce site, alors vérifiez la compatibilité du point de terminaison, du modèle et de l'authentification avant d'acheter un plan pour ce flux de travail. Commencez par le guide de configuration et de coûts ou comparez les Coding Plans disponibles.

Questions fréquemment posées

Le mode observation arrête-t-il la demande d'une personne autorisée ?

Non. Il enregistre les décisions positives pour les candidats déduits sans les accepter ; les demandes explicites restent possibles.

Une instance peut-elle couvrir plusieurs référentiels ?

Le prototype public est documenté pour un référentiel GitHub. Traitez toute adaptation multi-dépôt comme un projet distinct à évaluer.

Une Pull Request prouve-t-elle que la tâche a réussi ?

Non. Examinez les résultats des différences et des tests, et vérifiez la modification par rapport au problème avant de fusionner.

Voir les tarifs des Coding Plans