DeepSeek publie en open source dsh-superagent, un agent de code qui sépare le routage de l'exécution
L'équipe Harness de DeepSeek a publié dsh-superagent, un prototype de recherche sous licence MIT qui transforme un dépôt GitHub en agent de code proactif : un Router permanent reçoit les demandes et confie chacune à une session Worker isolée. Fonctionnement, mesures de DeepSeek et points de vigilance avant de l'installer.
Le 31 octobre 2026, l'équipe DeepSeek Harness a publié dsh-superagent-prototype sur GitHub sous licence MIT, accompagné d'un article de conception intitulé Exploring Super-agent Design: Towards a More Autonomous Agent System (traduction anglaise). Lundi soir, le dépôt dépassait les 12 000 étoiles. MarkTechPost le décrit comme un bundle TypeScript en version 0.1.0, publié en un seul commit.
Le README est clair sur son statut : il s'agit d'un « prototype de recherche fourni à titre de référence, pas d'un produit officiel de DeepSeek », écrit en grande partie avec des agents de code, et différent à la fois de la version interne de DeepSeek et du système décrit dans l'article. Il mérite pourtant le détour pour qui construit avec des agents de code, car il s'attaque à un problème que la plupart des outils actuels laissent à l'utilisateur : gérer plusieurs sessions d'agent en même temps.
Le problème : les sessions ne passent pas à l'échelle humaine
La plupart des agents de code considèrent la session comme l'unité de travail. Dans l'article de conception, l'équipe de DeepSeek écrit qu'« une personne ne peut généralement suivre que trois à cinq sessions actives à la fois ». La limite du travail en parallèle devient donc l'attention humaine plutôt que la capacité du modèle (traduction).
Leur réponse est ce qu'ils appellent un Super-agent : un agent unique et continu, que l'on sollicite là où l'on travaille déjà, dans un commentaire GitHub ou une messagerie, pendant que le système décide en coulisses comment répartir le travail. L'article lui fixe quatre propriétés : continuité, efficacité, proactivité et persistance.
Comment fonctionne le prototype
dsh-superagent est distribué comme un bundle pour DeepSeek Harness et surveille un dépôt GitHub, avec Feishu comme source de messagerie optionnelle. L'architecture compte deux couches :
- Un Router (la session principale) tourne en continu, lit les événements entrants et décide s'ils demandent un nouveau travail. Il utilise un preset restreint, avec moins d'outils.
- Des Workers (un par tâche, appelée Ticket) disposent chacun de leur propre session d'agent et de leur propre répertoire, écrivent le code et répondent dans la conversation d'origine, par exemple avec une pull request.
Chaque Ticket porte un Mandate immuable qui consigne pourquoi le travail peut avoir lieu. Les commentaires ultérieurs sur une pull request parviennent au bon Worker grâce à une Subscription, sans qu'il soit nécessaire de mentionner l'agent à nouveau. Selon la documentation d'exécution, les commandes shell au premier plan passent en arrière-plan au bout de cinq secondes, si bien qu'un Worker occupé par un long build peut continuer à recevoir des messages.
Un panneau web local n'affiche que ce qui demande une décision humaine. C'est l'application de la règle posée dans le document de philosophie : « Prendre le moins d'attention humaine possible, et apporter le plus de valeur possible. » L'agent confirme une demande une fois, reste silencieux pendant qu'il travaille, et ne réécrit qu'avec un résultat, une question ou un échec.
Le travail proactif, désactivé de fait par défaut
L'agent peut prendre en charge des tâches que personne n'a explicitement demandées, mais uniquement selon des règles écrites par l'équipe. Le document d'autorisation définit trois modes d'acceptation :
| Mode | Effet |
|---|---|
off | Aucune demande déduite ne devient candidate |
observe (par défaut) | Les candidates déduites sont évaluées et les avis positifs consignés comme « aurait accepté », mais rien n'est accepté |
auto | Une évaluation positive déclenche le travail |
Les demandes explicites des personnes autorisées fonctionnent dans tous les modes. La documentation recommande de démarrer en observe et de ne passer en auto qu'après avoir relu ce que l'agent aurait fait. Le même document précise que les messages, commentaires et documents cités « ne peuvent pas modifier » les permissions appliquées par l'hôte, ce qui compte face aux injections de prompt via les commentaires d'issues.
Ce que DeepSeek a mesuré
L'article de conception présente des expériences préliminaires que les auteurs eux-mêmes demandent de considérer « uniquement comme des points de référence préliminaires » (traduction). Chaque essai injectait environ 300 messages de discussion de groupe et de CI GitHub, dont une vingtaine de vraies demandes de travail, et chaque configuration a tourné cinq fois. Le travail de code était remplacé par un outil qui se contentait de consommer du temps : le test mesure donc la coordination, pas la qualité du code, une limite que MarkTechPost souligne aussi.
Dans ce cadre, le Super-agent atteint un temps de réalisation médian (p50) de 12,4 minutes et un p95 de 15,7 minutes. Une session unique avec un outil de sous-agent et un prompt neutre atteint un p95 de 29,5 minutes. L'article l'explique : avec le prompt neutre, le modèle n'a appelé aucun sous-agent sur les cinq essais, si bien que tout le travail est resté dans la session principale, sans cesse interrompue. Avec un prompt incitant à déléguer, il a délégué dans quatre essais sur cinq et a gagné en rapidité, tout en restant globalement plus lent.
Lire les notes de sécurité avant de l'installer
Le guide de déploiement est sans détour sur les risques. Les deux presets tournent en danger-full-access avec l'utilisateur système de l'opérateur. Un Worker « peut exécuter des programmes par leur chemin et lire le répertoire personnel de l'opérateur », et les wrappers de comptes choisissent les identifiants mais « n'isolent pas le processus ». DeepSeek recommande un compte système dédié, qui ne contient que les identifiants de l'agent.
Autres prérequis listés dans le même guide :
- un compte utilisateur GitHub distinct pour l'agent, avec un accès en écriture au dépôt (une GitHub App ne peut pas jouer ce rôle, car l'agent lit les notifications du compte) ;
- Node.js 22.19+ ou 24+, pnpm, git 2.32+, Python 3.8+, tmux et GitHub CLI 2.48+ ;
- un dépôt sur github.com, GitHub Enterprise Server n'étant pas pris en charge ;
- un fournisseur de modèle configuré dans DeepSeek Harness ; le bundle utilise le modèle par défaut du profil, sauf indication contraire.
Pourquoi c'est intéressant pour les builders
Les agents de code branchés sur GitHub ne sont pas nouveaux : le comparatif de MarkTechPost cite l'agent cloud de GitHub Copilot, la GitHub Action de Claude Code et OpenAI Codex. Ce qu'apporte dsh-superagent, c'est une conception publiée et lisible pour faire tourner de nombreuses tâches isolées derrière un point d'entrée conversationnel unique, en traitant l'autorisation et le bruit comme des sujets d'architecture plutôt que comme des réglages de prompt.
Trois idées restent utiles même sans l'installer :
- Garder le coordinateur léger. Un Router doté de peu d'outils et de délais courts reste réactif pendant que les Workers font le gros du travail.
- Rendre la délégation structurelle. La référence testée par DeepSeek montre qu'un modèle peut ne pas déléguer quand le prompt lui laisse le choix. Découper le travail au niveau du système a supprimé cette dépendance dans leur test.
- Limiter l'autorité à chaque tâche. Chaque Ticket reste limité par son Mandate, et les messages des fils qu'il suit lui parviennent comme contexte mais, selon le document d'autorisation, n'accordent aucune autorité supplémentaire.
Le code est une publication de recherche, en un seul commit, assortie d'un avertissement explicite contre tout usage en production. Pour l'essayer, mieux vaut commencer avec une liste d'autorisation courte, le mode observe et un compte isolé, comme le conseille la documentation du projet.
