DeepSeek Super-agent : configuration et rôles Router/Worker

Commencez l’essai de DeepSeek Super-agent avec un dépôt, une seule personne autorisée à demander du travail et un compte système dédié. Son Router transforme les demandes autorisées en Tickets, tandis que les Workers utilisent des sessions et des répertoires distincts. Gardez observe activé au départ, mais sachez que les demandes explicites peuvent tout de même s’exécuter.

Au 2026-11-09, dsh-superagent-prototype est du code de recherche, pas un produit officiel de DeepSeek ni un service prêt pour la production. Son manifeste de paquet indique la version 0.1.0 et une licence MIT. L’implémentation publique diffère aussi du système interne de l’équipe et de celle décrite dans son article de conception.

À quoi servent Router, Ticket et Worker ?

La différence principale est la réception continue de tâches, plutôt qu’un nouveau modèle ou une autre interface de programmation. Ce paquet d’extensions s’exécute dans DeepSeek Harness, surveille un dépôt GitHub et peut aussi recevoir des messages Feishu.

Le modèle de domaine sépare les événements reçus du travail autorisé. Le mécanisme d’évaluation, appelé Eval, décide si une tâche potentielle justifie un nouveau Ticket. Chaque Ticket accepté porte un Mandate, qui consigne son autorisation et son périmètre.

Router est la session principale de l’agent : il décide comment orienter les demandes. Worker exécute la tâche acceptée. Les pages de configuration désignent ce Worker par le nom Executor.

Chaque Worker dispose de sa propre session et de son répertoire de travail. Les résultats reviennent dans la conversation d’origine, par exemple dans un commentaire GitHub contenant un lien vers une pull request. Un répertoire sépare les copies de travail ; il ne limite pas les fichiers que le processus peut lire.

Par exemple, deux signalements de bugs indépendants peuvent devenir des Tickets distincts au lieu de partager une même conversation de programmation. C’est utile lorsque coordonner les demandes mobilise plus d’attention que lancer une tâche individuelle.

Pour une seule modification interactive, gardez votre agent de programmation habituel. Pour déléguer un travail bien délimité, commencez par des sous-agents Claude Code en lecture seule avec choix explicite du modèle.

Pourquoi observe n’est pas un bac à sable de sécurité

observe limite le travail déduit du contexte, pas toute exécution. Les règles d’autorisation permettent les demandes explicites dans tous les modes d’acceptation.

Dans observe, une évaluation positive d’une tâche déduite du contexte produit un enregistrement « would accept », sans créer de travail. Dans auto, une évaluation positive peut conduire à accepter ce travail. Une personne autorisée qui mentionne l’agent peut lui demander une tâche dans n’importe quel mode.

La liste des personnes autorisées n’est pas le seul contrôle d’admission. Une cellule du tableau d’admission peut aussi accorder une autorisation explicite aux personnes absentes de la liste. Appliquez donc la politique à un seul demandeur décrite plus bas, au lieu de vous reposer uniquement sur observe.

Ce que signifie danger-full-access

Utilisez un compte système contenant uniquement les identifiants de l’agent. L’avertissement sur l’isolation du guide de déploiement concerne dsh-superagent-router et dsh-superagent-worker. Ces deux préréglages s’exécutent sous le compte système de l’opérateur avec danger-full-access.

Les programmes intermédiaires d’authentification sélectionnent les comptes ; ils n’isolent pas les processus. Les Workers peuvent lancer des programmes par leur chemin absolu et lire le répertoire personnel de l’opérateur. Le guide d’implémentation donne aussi au Router des outils de shell et de lecture de fichiers.

Pour un premier essai, utilisez une machine temporaire ou virtuelle avec un compte d’agent sans droits administrateur. N’y placez pas vos identifiants personnels, vos secrets de production ni des dépôts sans rapport avec l’essai. Ce sont des précautions de déploiement, pas des protections fournies par le prototype.

Gardez aussi un profil Harness distinct. Le plugin modifie PATH et la configuration de git pour tout le processus. Laissez le panneau à l’écoute sur 127.0.0.1 ; n’exposez pas cet essai comme un service web public.

Mettre en place un essai limité à GitHub

Suivez la procédure manuelle ci-dessous avec un compte et un profil neufs. Le dépôt fournit aussi un SETUP.md pour une installation accompagnée par un agent.

Vérifier les prérequis

Installez Node.js 22.19+ ou 24+, pnpm, git 2.32+, Python 3.8+, tmux et GitHub CLI 2.48+. Ce sont les prérequis documentés.

Il vous faut aussi un dépôt sur github.com et un fournisseur de modèles pour DeepSeek Harness. GitHub Enterprise Server n’est pas pris en charge. Installez git-lfs si le dépôt cible utilise Git LFS.

Choisissez un dépôt d’essai non vide contenant README.md. Pour la première vérification, préférez un dépôt privé auquel seuls vous et l’agent avez accès.

Feishu est facultatif et reste hors de cet essai. Son installation documentée nécessite aussi une application Feishu ou Lark avec un bot et lark-cli. Le projet indique l’avoir testé avec la version 1.0.90.

Se connecter uniquement avec le compte de l’agent

Créez un compte utilisateur GitHub dédié et donnez-lui les droits d’écriture sur le dépôt d’essai. Exécutez ces commandes dans Bash, sous le compte système dédié.

unset GH_TOKEN GITHUB_TOKEN
gh auth login --hostname github.com --git-protocol https
gh api user --jq .login
gh auth setup-git --hostname github.com

Terminez la connexion interactive de GitHub CLI avec le compte de l’agent. La commande gh api doit afficher son nom de connexion. La suppression des deux variables empêche les identifiants de l’environnement de remplacer la connexion enregistrée.

L’étape distincte gh auth setup-git configure Git pour utiliser GitHub CLI comme assistant d’authentification. C’est important, car la préparation et l’envoi des branches utilisent Git directement.

Créez le clone local avec la syntaxe documentée de GitHub CLI :

read -r -p "Repository (owner/name): " TARGET_REPOSITORY
mkdir -p "$HOME/src"
gh repo clone "$TARGET_REPOSITORY" "$HOME/src/superagent-target"

Vérifiez ensuite l’accès HTTPS indépendamment de gh api :

GIT_TERMINAL_PROMPT=0 git ls-remote \
  "https://github.com/$TARGET_REPOSITORY.git" HEAD

GIT_TERMINAL_PROMPT=0 git -C "$HOME/src/superagent-target" push --dry-run \
  "https://github.com/$TARGET_REPOSITORY.git" \
  HEAD:refs/heads/agent-auth-check

git ls-remote doit renvoyer le HEAD distant. Sur un dépôt public, cette lecture peut réussir sans authentification. La vérification avec push --dry-run teste la connexion d’envoi sans modifier les références distantes.

Les deux commandes doivent réussir. Gardez toutefois l’envoi réel de la branche pour la PR comme vérification finale de la livraison.

Cet exemple utilise directement gh, car tout le compte système est réservé à l’agent. Ne réutilisez pas la configuration d’un compte personnel contenant plusieurs connexions GitHub.

Installer un profil Harness dédié

Utilisez la version de Harness fixée dans le guide de déploiement : 0.2.1-rc.3. Le manifeste du paquet impose à engines.dsh de respecter ^0.2.1-alpha.2.

Définissez DSH_HOME avant toute commande dsh. La référence CLI de cette version place les profils nommés sous $DSH_HOME/profiles/<name>. Ici, $HOME/.dsh est l’emplacement choisi explicitement pour cet essai.

Les commandes Bash suivantes sont réservées à une nouvelle installation :

export DSH_HOME="$HOME/.dsh"

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype
pnpm install
pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

Ne relancez pas la commande de création du profil sur une installation existante. Elle remplace le profil et supprime son cordis.patch.yml. Pour une mise à niveau, suivez la procédure du guide de déploiement.

Vérifiez que le manifeste du profil existe avant d’écrire la configuration de la machine. Continuez dans le même shell Bash :

test -f "$DSH_HOME/profiles/superagent/package.json" || exit 1

cat > "$DSH_HOME/profiles/superagent/cordis.patch.yml" <<EOF
- id: webserver
  config:
    host: 127.0.0.1
    port: 3082
- id: dsh-superagent
  config:
    stateDir: "$DSH_HOME/state/superagent"
EOF

if tmux list-sessions >/dev/null 2>&1; then
  tmux set-environment -g DSH_HOME "$DSH_HOME"
  if tmux has-session -t '=dsh-superagent' 2>/dev/null; then
    tmux set-environment -t '=dsh-superagent' DSH_HOME "$DSH_HOME"
  fi
fi

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

Le script du service lance dsh --profile superagent dans tmux. Un nouveau serveur tmux hérite de l’environnement exporté. Le bloc actualise aussi l’environnement tmux d’un serveur ou d’une session déjà présents.

Ouvrez http://127.0.0.1:3082 dans un navigateur sur la machine du serveur. Dans les paramètres de Harness, Open configuration file doit ouvrir le chemin superagent/cordis.patch.yml indiqué plus haut. Arrêtez-vous si le chemin est différent. N’écrasez plus ce fichier de surcharge après avoir ajouté les paramètres du fournisseur.

Sélectionnez Superagent dans la barre latérale. Un avertissement de configuration incomplète est normal tant que les paramètres du dépôt et du compte ne sont pas renseignés. Avant de configurer la réception des demandes, terminez la section sur le choix du modèle ci-dessous.

Configurer la réception et les arbres de travail par Ticket

Utilisez Superagent → Settings et ses groupes documentés.

Dans Sources → GitHub, renseignez votre dépôt sous la forme owner/name et définissez la CLI de l’agent sur gh. Laissez désactivés les interrupteurs de réception de tous les Issues, pull requests, commentaires et événements CI de la branche par défaut. Gardez Feishu désactivé.

Dans Eval → On each Source → GitHub, GitHub accounts that may originate work doit contenir uniquement votre nom de connexion personnel. Supprimez les autres entrées et laissez la liste des bots vide. Réglez sur ignore chaque cellule visible d’admission des personnes non répertoriées, y compris celles qui s’adressent à l’agent. Enregistrez avec le mode d’acceptation observe.

Ces valeurs par défaut sont définies dans la matrice d’admission. Elles limitent les nouvelles demandes de travail. Elles n’empêchent pas les messages des discussions suivies d’atteindre les Tickets existants comme contexte. Limitez la conversation d’essai à vous et à l’agent.

Dans Execution, commencez avec une concurrence de 1 pour l’essai. Conservez la racine des répertoires par défaut. Collez le code suivant dans le champ de la commande de préparation. Il s’exécute sous sh et sa syntaxe est également valide dans Bash.

git -C "$HOME/src/superagent-target" fetch --no-tags \
  "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C "$HOME/src/superagent-target" worktree add \
  -b "agent/$DSH_SUPERAGENT_NAME" \
  "$DSH_SUPERAGENT_DIR" \
  "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"

Cet exemple adapte la création d’arbres de travail du guide de déploiement au clone préparé plus haut. Il récupère la révision concernée, puis crée la branche et la copie de travail du Ticket. Sans commande de préparation, le Worker démarre dans un répertoire vide.

Dans Prompts, définissez l’identité de l’auteur des commits et le texte signalant l’intervention de l’agent. Exigez une fusion par une personne et ne fournissez pas de compte de fusion distinct. Les instructions du prompt orientent l’agent ; elles n’imposent pas de protection au dépôt.

Peut-on utiliser un autre modèle ?

Oui, par l’intermédiaire des fournisseurs configurés dans DeepSeek Harness. Le guide des fournisseurs au tag dsh-v0.2.1-rc.3 décrit la procédure suivante pour la version installée.

Ouvrez Settings → Models dans Harness. Saisissez et enregistrez la clé API dans la carte DeepSeek, ou choisissez Add model provider pour un autre fournisseur pris en charge. Entrez les identifiants localement dans cette interface, pas dans une discussion GitHub.

Pour Custom model API, indiquez un Provider ID en minuscules, l’URL de base, le protocole API correspondant, les données d’authentification et au moins un modèle. Utilisez les valeurs documentées par votre fournisseur. L’enregistrement d’un fournisseur ne prouve pas que son modèle sait effectuer les appels d’outils requis.

Ensuite, utilisez Choose workspace pour ajouter et sélectionner $HOME/src/superagent-target, conformément au guide de l’interface web de cette version. Lancez une session ordinaire et sélectionnez un modèle configuré dans son sélecteur de modèles. Ce choix devient la valeur par défaut des nouvelles sessions.

Ouvrez une deuxième nouvelle session et vérifiez qu’elle affiche le même fournisseur et le même modèle avant d’envoyer une demande. Demandez-lui de lire README.md et d’en renvoyer le premier titre sans rien modifier. Comparez la réponse au fichier. N’utilisez aucun des deux préréglages gérés dsh-superagent-* pour ce test.

Sélectionnez ensuite explicitement ce fournisseur et ce modèle vérifiés dans Superagent → Settings → Eval et Execution. Eval fournit le modèle du Router et de l’évaluation ; Execution fournit celui du Worker. Cet essai ne dépend donc pas d’une valeur par défaut non vérifiée. Ne laissez l’un de ces choix vide qu’après avoir confirmé le modèle par défaut du profil.

Le choix du modèle Executor s’applique à la création d’une session. Les sessions Worker existantes conservent leur modèle, et Retry réutilise la même session. Pour vérifier un changement ultérieur de modèle, créez un nouveau Ticket.

Vérifier une demande et localiser la panne

Vérifiez une demande GitHub complète et sa réponse avant de demander une modification du code. Le fonctionnement du panneau ne suffit pas à confirmer l’autorisation, la préparation et les appels au modèle.

Relancez d’abord scripts/dsh-superagent status. Exigez un code de sortie 0 et aucune erreur de configuration. Publiez un nouveau commentaire dans une issue depuis le compte personnel autorisé. Remplacez @AGENT_LOGIN par le nom de connexion de l’agent :

@AGENT_LOGIN Read README.md and reply here with its first heading.
Do not edit files, push a branch, or open a pull request.

La procédure d’essai du guide de déploiement situe le Ticket créé dans Overview. Vérifiez que la réponse dans la conversation GitHub d’origine contient le titre exact.

Une fois ce test réussi, demandez une petite modification de documentation et une pull request à faire relire par une personne. Vérifiez l’envoi réel de la branche, la création de la PR par le compte de l’agent et le respect du périmètre dans le diff. Ce sont des critères d’acceptation, pas des résultats garantis par le modèle.

Si aucun Ticket n’apparaît, vérifiez le nom de connexion autorisé, les cellules d’admission, le dépôt et l’état de la source GitHub. Publiez ensuite un nouveau commentaire mentionnant l’agent.

Pour les pannes du service, le script renvoie 1 en cas de problème de processus ou d’exécution, 2 pour une erreur de composant et 3 pour une configuration incomplète. Un redémarrage peut aider pour 1 ; corrigez la cause signalée pour 2 ou 3.

Pour les pannes temporaires du modèle ou du réseau, le guide d’exécution prévoit trois nouvelles tentatives avec un délai croissant. Cela comprend les codes HTTP 408, 429 et 5xx. Les échecs de la commande de préparation sont exclus de ces tentatives automatiques.

Reprendre après un échec de préparation

Examinez l’erreur de préparation enregistrée et le répertoire du Ticket avant de sélectionner Retry. L’implémentation du lancement n’exécute la préparation que si ce répertoire n’existe pas. Un répertoire existant est considéré comme prêt, même s’il contient un travail incomplet.

Si le répertoire est absent, corrigez le problème d’identifiants ou de commande de préparation, puis sélectionnez Retry. Le nouveau lancement tente à nouveau la préparation.

Si le répertoire existe, copiez son chemin depuis les détails du Ticket et inspectez-le dans Bash :

read -r -p "Ticket directory (absolute path): " TICKET_DIR
git -C "$TICKET_DIR" rev-parse --show-toplevel
git -C "$TICKET_DIR" status --short --branch

Le répertoire racine affiché doit être celui du Ticket, pas celui d’une copie de travail parente. Vérifiez la branche et l’état de l’arbre de travail, les fichiers attendus et chaque étape de préparation qui a échoué.

Ne relancez un Ticket dans un répertoire existant qu’après avoir terminé et vérifié sa préparation. Retry ne reconstruit pas ce répertoire. Si vous ne pouvez pas restaurer une copie incomplète sans risque, conservez-la, arrêtez ce Ticket et corrigez la commande. Soumettez ensuite une demande dans une nouvelle issue. Vérifiez que le Ticket de remplacement utilise un nouveau répertoire avant de continuer.

Une fois un Ticket en échec, les messages de CI et de bots ne réactivent pas son Worker. Une personne doit intervenir. Arrêtez le service d’essai lorsque vous avez terminé :

scripts/dsh-superagent stop

Quand laisser le service fonctionner

Ne gardez le prototype en fonctionnement que si ses décisions d’aiguillage et les modifications livrées justifient le travail d’exploitation. Commencez avec un périmètre restreint. Augmentez la concurrence après avoir mesuré les résultats utiles et la consommation auprès du fournisseur.

Comparez le coût par modification acceptée, pas seulement le prix du modèle. Incluez l’aiguillage, l’évaluation, les appels Worker et la reprise après incident dans votre budget d’essai. Le guide du coût par tâche des agents de programmation propose une méthode pour comparer un modèle avec son environnement d’exécution.

N’assimilez pas une démonstration interne à ce code public. Le dépôt avertit que certaines idées de l’article de conception ne sont pas implémentées. Gardez le déploiement isolé et soumis à une revue humaine jusqu’à ce que vos propres vérifications justifient d’élargir son usage.