DeepSeek a publié dsh-superagent, un prototype de recherche sous licence MIT, présenté comme un agent de programmation proactif destiné à un seul dépôt GitHub. Packagé pour DeepSeek Harness, il écoute GitHub et, en option, Feishu, puis transforme les demandes autorisées en tâches parallèles, chacune dans sa propre session d’agent.
- DeepSeek publie dsh-superagent, un prototype open source d’agent de programmation pour un seul dépôt GitHub.
- Chaque demande autorisée devient un Ticket traité dans sa propre session, avec un Router qui répartit le travail entre des Workers isolés.
- Les résultats simulés affichent un p50 de 12,4 minutes, mais ils sont auto-déclarés et la qualité du code n’a pas été mesurée.
- L’agent dispose de tous les droits de l’utilisateur système, il faut donc l’isoler avant toute utilisation.
Un agent qui attend d’être sollicité
Le fonctionnement repose sur la notion de Ticket, une unité de travail ouverte lorsqu’une personne autorisée s’adresse à l’agent. Chaque Ticket s’exécute dans sa propre session et son propre répertoire, et les résultats reviennent dans la conversation d’origine, souvent sous la forme d’une pull request, c’est-à-dire une proposition de modification de code soumise à relecture. Une interface web locale ne liste que les éléments qui nécessitent l’intervention d’une personne.
Le README du projet fixe une règle simple : réduire au minimum l’attention humaine tout en apportant un maximum de valeur. Selon le document de philosophie du projet, l’agent demande une confirmation une seule fois, reste silencieux pendant son travail et ne reprend la parole qu’avec un résultat, une question ou un échec.
Une architecture Router-Worker
Selon l’équipe, les agents courants considèrent la session comme unité de base. D’après le rapport cité par ifeng, une personne ne peut suivre activement que 3 à 5 sessions à la fois, si bien que l’attention humaine, et non la capacité du modèle, devient le facteur limitant du travail en parallèle. L’architecture proposée comporte deux couches : un Router de longue durée gère les échanges et la répartition des tâches, tandis que des sessions Worker isolées effectuent le travail réel.
Le modèle de domaine décrit un enchaînement précis : GitHub ou Feishu produisent des événements, appelés Triggers ; une étape d’évaluation décide si un lot de Triggers appelle un nouveau travail ; chaque Ticket porte un Mandate immuable qui énonce pourquoi il peut être exécuté ; enfin, les commentaires ultérieurs sur une pull request sont acheminés vers le bon Worker sans nouvelle mention. Les commandes shell passent en arrière-plan au bout de 5 secondes, afin que les Workers continuent de recevoir des messages. Le travail proactif est encadré par trois modes : off, observe (par défaut) et auto. En mode observe, l’agent se contente d’enregistrer ce qu’il aurait accepté.
Des résultats issus d’une simulation
DeepSeek a testé le système sur des flux simulés de discussion de groupe et de CI GitHub, avec environ 300 messages par essai, dont environ 20 demandes de travail réelles, chaque configuration ayant été exécutée 5 fois. Le super-agent affiche un p50 de 12,4 minutes et un p95 de 15,7 minutes, contre un p95 de 29,5 minutes pour une session unique avec sous-agents et prompt neutre, pour lequel aucun p50 n’a été communiqué. Dans cette configuration de référence, le sous-agent n’a été appelé aucune fois sur 5 essais.
Selon ces mêmes données, lorsque le nombre d’arrivées est passé d’environ 1 à 40 par minute, la taille des lots est passée de 1,0 à 2,8 et la latence par requête de 2,5 à 3,9 secondes. Ces chiffres sont auto-déclarés par DeepSeek et proviennent de comptes rendus secondaires du rapport. Le projet précise par ailleurs qu’il n’a été testé que sur des messages synthétiques et des outils simulés, et que la qualité réelle du code produit n’a pas été mesurée.
Pour l’installation, le prototype nécessite Node.js 22.19+ ou 24+, git 2.32+, Python 3.8+, tmux et GitHub CLI 2.48+. Le dépôt indique enfin que l’agent s’exécute avec tous les droits de l’utilisateur du système d’exploitation, ce qui impose de l’isoler avant toute utilisation.
