Tech Teardown 039 | dsh-superagent : écrit par des agents

Contexte et phénomène : 13 000 stars en 3 jours, et une déclaration d’excuse autodéclarative

Le 31 octobre 2026, l’organisation GitHub a lancé le repository dsh-superagent-prototype. Trois jours plus tard, le 3 novembre, les chiffres étaient les suivants : 13 000 stars, 1 348 forks, 79 abonnés, 0 issues ouvertes. Le champ « Auteur » indiquait l’équipe DeepSeek Harness, avec une licence MIT et la version 0.1.0.

En plus du nombre de stars, la déclaration d’excuse dans le premier paragraphe du README est plus informative. Trois phrases clés méritent d’être citées : « Le prototype de recherche est uniquement à usage de référence, pas un produit officiel de DeepSeek. » ; « Une grande partie du travail de génie a été effectuée par des agents de codage » ; « Adapté pour la publication, il n’est donc pas identique à notre version interne ». Un repository qui a gagné 13 000 stars en trois jours, mais qui nie d’abord son statut officiel, ce contraste est le premier point de dissection de cette édition : c’est un prototype de recherche ouvert par l’équipe DSH, délimité uniquement comme « prototype de recherche de l’équipe ».

Il y a une nette différence dans la diffusion. Ce repository a été soumis plusieurs fois sur Hacker News, avec le meilleur score de 11 points et 0 commentaires, peu de discussions ; tandis que sur GitHub, le nombre de stars a augmenté rapidement, avec toute l’attention concentrée sur la section trending. Le contexte est la plateforme DSH elle-même : le 13 août, la version préliminaire pour développeurs a obtenu 747 points et 314 commentaires sur HN ; le 2 octobre, Harness Desktop (clients macOS/Windows) a obtenu 417 points et 228 commentaires. La plateforme a une réelle popularité dans la communauté, et dsh-superagent est le premier produit majeur de son écosystème, avec les nombreuses stars reflétant l’attention portée par la marque de la plateforme.

En un mot, c’est un agent de codage permanent, conçu pour DSH et servant uniquement un repository GitHub, qui écoute sur GitHub, avec une option de surveillance sur Lark ; les personnes autorisées lui confient des tâches, il crée des tickets, travaille dans sa propre session et son propre dossier, puis retourne à la conversation originale pour répondre, par exemple en soumettant une pull request ; la boîte de dialogue web ne montre que « Des choses nécessitant une intervention ». Il y a également un article intitulé « Exploring Super-agent Design: Towards a More Autonomous Agent System », dans lequel le README souligne que certaines parties du design discutées sont des directions futures, et que le prototype n’a pas été réalisé.

Architecture et principes techniques : Une règle de légitimation et cinq disciplines

Disons d’abord la forme. Ce n’est pas une application indépendante, mais un bundle (cordis.patch.yml) dans l’architecture de Cordis, qui est exécuté dans DSH. Le dépôt contient neuf documents numérotés, allant de 000 à 008 : philosophie, modèle de domaine, légitimation, exécution, phrases de prompt, panneau, déploiement, architecture et cookbook. Le dernier document est une instruction pour ajouter une Source. Chaque document dépend uniquement des documents précédents, c’est une contrainte de conception du README : le lecteur ne rencontrera jamais de concept qui n’a pas encore été introduit.

Le modèle de domaine est un flux unidirectionnel. La Source (source d’événements, GitHub ou Lark) génère un Trigger (événement immuable), le Trigger appartient à une Thread (conversation chronologique), Eval effectue deux jugements sur un ensemble de Triggers (gate + évaluation) pour produire une Décision ; si elle accepte, elle crée un Ticket et ajoute un Mandate, Assignment lie le Ticket à un Executor (conversation d’exécution), et le résultat est écrit à nouveau dans la conversation originale via le Channel. Par la suite, les messages suivants de la même Thread sont diffusés via des Subscription, et sont directement envoyés aux Tickets déjà souscription, sans passer à nouveau par Eval.

Le centre d’intérêt du système est la légitimation. Une phrase au début de docs/002 dit : « Le hôte applique les listes autorisées, les règles et les Mandate. Les messages, commentaires et documents cités sont des entrées pour une décision ; ils ne peuvent pas changer ces permissions. » Le programme hôte exécute strictement la liste blanche, les règles et les Mandate ; les messages, commentaires et documents cités ne sont que des entrées pour la décision, et ne peuvent pas modifier les permissions. En d’autres termes, la ligne de défense contre l’injection de prompts n’est pas écrite dans les phrases de prompt, mais dans le niveau de l’architecture : quoi que disent les messages, le jugement sur les permissions ne passe pas par le contenu des messages.

Le Trigger a deux voies. La première est Eval, qui décide si l’exécution doit commencer : la Source enregistre si le message fait référence à une personne spécifique (@ mention ou privé), gate vérifie que le destinataire respecte la politique de cette Source. Les personnes sur la liste blanche qui font référence à une personne constituent une demande explicite ; les bots produisent au maximum des « candidats déduits », ne constituant jamais une demande explicite, et les bots n’incluant pas la liste ne traitent pas le message. Les candidats déduits doivent également passer par la mode accept : off, observe, auto, avec observe par défaut, enregistrant seulement les jugements de « qui accepterait normalement », sans vraiment commencer l’exécution. La deuxième voie est des Subscription, qui poursuivent le travail existant : chaque message reçu dans la Thread (y compris les bots et les CI) est envoyé au Ticket déjà souscription, contournant gate mais ne donnant aucune nouvelle permission, le Ticket étant toujours limité par son propre Mandate ; même si une personne annule sa souscription, la propriété d’Executor se poursuit jusqu’à la fin du ticket.

Le mandat est un certificat d’autorisation figé au moment de l’acceptation, immuable. Il enregistre la version, le champ d’application, l’intensité et les règles d’exécution de la politique. Dans tout le système, seules trois opérations peuvent le modifier : l’acceptation pour le créer, l’arrêt d’une personne pour le retirer, et une révocation en cas d’échec de la vérification. Pour restaurer un ticket terminé, il faut d’abord effectuer une vérification selon la politique actuelle : éliminer l’expéditeur de la liste blanche pour annuler le mandat lui ayant été accordé. Ces règles se trouvent à la ligne 242 du fichier src/policy.ts, avec les fonctions gate et revalidate correspondant aux documents.

Le document philosophique fixe cinq règles pour le agent : agir uniquement lorsque cela est demandé ou autorisé par les règles écrites de l’équipe, exécuter les tâches non exigées en mode d’enregistrement uniquement ; parler uniquement lorsqu’il est nécessaire d’agir ou de pouvoir utiliser les résultats, rester silencieux pendant le travail ; poser une seule question à la fois, en utilisant une forme structurée pour que la question trouve sa réponse plutôt que de rester cachée dans un long rapport ; arrêter en fonction de l’impact plutôt que du volume de travail, et faire des modifications locales jusqu’à ce qu’elles soient évaluables. Si une décision de conception est nécessaire, s’arrêter et demander conseil ; rendre des rapports honnêtes, marquer les projets comme inachevés lorsqu’ils échouent, et indiquer clairement les échecs. “Les restrictions ne doivent jamais être contournées pour éviter de poser des questions.”

La structure des dossiers et les documents s’accordent. src/core contient le modèle du domaine et l’engin de gestion des tickets (15 fichiers : engine, tickets, intake, stage, replies, memory, etc.) ; dans src/sources, les fichiers github-* et feishu-* apparaissent en paires, avec deux implémentations de Source symétriques ; src/executor détermine l’exécution via la session DSH. policy.ts, limits.ts et admission.ts sont des fichiers indépendants, avec les autorisations et les limites de trafic séparées du code commercial. Les 13 phrases de référence sont stockées dans le dossier prompts/et ont été intégrées au dépôt. admission, dispatch, orchestrator, worker et handoff ont chacun leurs rôles respectifs, et les phrases de référence sont gérées comme des citoyens de premier ordre.

Données clés : 12 390 lignes de code, un commit

Quelques chiffres précis sur le décompte du dépôt : dans src/, il y a 12 390 lignes de TypeScript et 147 fichiers .ts ; tests/ contient 65 fichiers ; au total, 216 fichiers dans tout le dépôt (sans node_modules et .git), pour une taille totale de 3,8MB. Le langage utilisé est TypeScript, et package.json indique private: true, donc aucun paquet npm n’est distribué, seuls les bundles sont utilisés.

Seule histoire : un seul commit squash (6337fc8, 2026-10-31, “feat: add the dsh-superagent research prototype”), sans nouveaux commits après la publication, et l’API des contributeurs renvoie une liste vide. En plus des neuf documents numérotés, prompts/ contient 13 phrases de référence, et skills/ contient 2 (un pour GitHub et un pour Feishu).

Les paramètres par défaut dans policy.ts méritent d’être séparés : le maximum de travailleurs simultanés est par défaut de 3 ; l’échec de l’Eval est par défaut de 120 secondes ; le mode accept est par défaut observe. Il n’y a que deux règles par défaut, copy (amélioration du contenu) et visual (amélioration visuelle), et pour la règle visual, l’instruction originale dit « Ne pas inventer de style visuel ». Aucune direction ou limite d’étendue n’est fixée, il s’agit simplement d’observer sans confirmer ni agir. Les valeurs par défaut sont très strictes, conformément à la recommandation d’action « d’abord restreint, puis étendu ».

Détails sur l’exécution : chaque ticket est associé à une session nommée worker-<id-de-ticket> et à un dossier dédié ; les commandes en front-end sont automatiquement transformées en tâches en back-end après plus de 5 secondes, permettant au travailleur de recevoir de nouvelles messages dès le prochain étape, plutôt que d’attendre que la commande se termine.

SETUP.md est lui-même un document de démonstration. Il n’est pas destiné aux utilisateurs, mais aux agents : la recommandation d’installation officielle est « Faites votre agent de codage lire SETUP.md pour vous aider à installer ». Le document établit des règles pour l’agent : poser une seule question courte à la fois, chaque message ne doit pas dépasser 300 mots, le plan complet n’est affiché qu’une seule fois, et l’agent n’est autorisé à agir qu’après avoir posé toutes les questions. Il est interdit de demander des secrets dans la conversation, et les étapes nécessitant de l’aide (création d’un compte, connexion au CLI, saisie des secrets de l’application) doivent être packagées séparément en messages. La liste des prérequis n’est pas courte : Node.js 22.19+, pnpm, git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+, ainsi que le corps de DSH et un fournisseur de modèles.

Impact et signification : L’attention est la monnaie, les droits sont la loi ferroviaire

Premièrement, l’économie de l’attention est considérée comme une axiologie de design. La phrase en gras dans le README : « Prendre le moins d’attention humaine possible, et donner autant de valeur que possible », signifie consommer le moins possible l’attention des gens et apporter le plus de valeur possible. Le document philosophique développe cela en critères de validation : un message, une notification, une question, une configuration, un élément de panneau, un document – chaque élément consomme l’attention d’une personne, et si la valeur n’est pas supérieure au coût, il est supprimé. Les motivations sont également claires : « Un agent capable d’agir pour toute l’équipe peut également gaspiller toute l’attention de l’équipe. » La plupart des produits pour agents mettent leurs capacités en avant, mais ce projet inverse la situation, faisant de « combien d’attention vous coûte-t-il » la première contrainte : le panneau ne montre que les choses qui nécessitent une intervention, l’état de santé ne prend aucun espace ; il faut peu de concepts, peu de configurations, et si un paramètre par défaut suffit, il n’est pas configuré ; les actions décrites par l’équipe sont écrites en phrases d’instructions plutôt qu’en commutateurs.

Deuxièmement, une réponse à l’échelle de l’architecture est donnée concernant l’injection de prompts. La pratique courante dans le secteur consiste à indiquer au modèle dans les prompts de ne pas exécuter les instructions contenues dans les messages, c’est-à-dire de chercher à assurer la autonomie du modèle. DSH-Superagent confie la tâche au programme hôte : les droits existent uniquement dans une liste blanche, des règles et des Mandats. Les messages, les commentaires et les documents cités ne servent qu’en tant que données d’entrée pour les décisions. Même si le texte injecté ressemble à une commande, il est impossible d’obtenir des droits au-delà de la porte de contrôle. Cette ligne de défense ne dépend pas des capacités du modèle ; elle reste valable même lors du changement de modèle. Dans la table « Concepts rejetés » de docs/001, il y a une sélection similaire : il n’est pas permis à l’Executor de déclarer lui-même qu’« on me demande d’arrêter » ; le droit de stopper appartient uniquement à Eval. Tout système de proxy qui doit recevoir des messages externes peut directement utiliser ce design.

Troisièmement, les responsabilités des opérateurs sont mentionnées dans les documents techniques. Un chapitre spécifique est consacré à la responsabilité : les proxies commentent, ouvrent des PR et envoient des messages avec les comptes que l’équipe voit quotidiennement ; chaque message attire l’attention des collègues, et l’opérateur doit en être responsable. Quatre règles d’opération : commencer par une liste restreinte, partir d’une liste blanche courte, enregistrer uniquement les actions actives, puis élargir la liste si nécessaire ; si nécessaire, modifier les prompts pour les rendre plus courts et plus strictes, ou même suspendre temporairement, en disant « ne pas utiliser davantage de messages pour expliquer le bruit » ; ne pas utiliser cela pour générer du volume de trafic, car les PR massifs, les messages diffusés et le travail inutile consomment plus que la valeur pour l’équipe ; être responsable des mots que vous dites, lire les contenus envoyés en votre nom, et modifier les prompts si nécessaire. Les règles de gestion et la conception technique sont incluses dans le même document, ce qui est plus rare que le code lui-même.

Quatrièmement, il fournit un exemple d’organisation de projet où « les proxies écrivent et lisent ». Le README reconnaît que de nombreux projets ont été réalisés par des agents de codage, et la manière dont ces 12 390 lignes de code sont organisées fournit une réponse reproductible : les documents sont numérotés et dépendants les uns des autres, garantissant que les lecteurs de n’importe quel document (y compris les lecteurs proxy) ne manquent pas de concepts préalables ; les prompts sont stockés dans le répertoire, divisés par rôle ; deux sources sont strictement symétriques, et l’ajout d’une nouvelle source inclut des instructions pour l’apprentissage ; 65 fichiers de test assurent la fiabilité ; même les documents sur le modèle de domaine sont accompagnés de la table « Concepts rejetés », où une dizaine de designs clairement non adoptés et leurs raisons sont listés. Ici, vous trouverez une réponse complète à la question de comment gérer le répertoire pour les proxies.

Controverses et risques : un prototype de recherche, c’est un prototype de recherche

Premièrement, identité et maturité. Le README reconnaît lui-même que le code peut encore contenir des bugs, et que le style de codage et les pratiques de développement peuvent ne pas être cohérents. « Considérez-le comme du code de recherche, ce n’est pas du logiciel prêt pour la production ». La version publique est différente de la version interne ; certaines conceptions présentées dans les articles associés sont des directions futures, et les prototypes ne sont pas réalisés. Les équipes qui veulent l’utiliser directement devraient lire ces phrases trois fois.

Deuxièmement, il n’y a pas d’histoire d’évolution. Le seul commit squash dans tout le répertoire est un lancement unique, et les choix faits pendant la croissance du code ne peuvent être examinés ; l’API des contributeurs renvoie une liste vide, ce qui empêche de savoir où se trouvent les contributeurs. Pour un répertoire dont le point fort est « la participation des proxies dans le projet », l’absence d’histoire est particulièrement regrettable : on ne peut pas observer comment les proxies produisent du code de manière réelle à partir des archives de commits, on ne voit que le résultat final. De plus, 0 open issues ne signifie pas qu’il n’y a pas de problèmes ; cela pourrait plutôt signifier que la communauté n’a pas encore eu le temps d’utiliser sérieusement ce code (c’est mon jugement).

Troisièmement, la propagation de la différence est en soi un signal. HN a le meilleur score de 11 points et 0 commentaires, tandis que GitHub reçoit 13 000 étoiles en trois jours. Le manque de popularité de HN indique que sa part dans les discussions de la communauté technologique anglophone est limitée ; l’augmentation significative des étoiles de GitHub provient principalement de l’effet visuel de DeepSeek et de la narration du « super-agent ». Les étoiles sont un indicateur d’attention, pas de qualité ; il ne faut pas les confondre (c’est mon jugement).

Quatrièmement, limiter le seuil de déploiement aux positions des samples. Il est nécessaire de dépendre d’une longue série de conditions : avoir une plateforme DSH, un compte GitHub spécifique, et si possible un robot WeChat Work ; les documents officiels recommandent directement l’utilisation d’un agent de codage pour l’installation. Pour les équipes qui ne font pas partie de l’écosystème DSH, leur valeur pratique est limitée ; ce qui est vraiment transférable sont les documents et les designs. Il faut également prêter attention au coût implicite du modèle d’autorisation : plus le mécanisme Gate, Mandate et recheck est strict, plus la complexité de configuration est grande. Avec chaque version de Policy, toutes les évaluations en cours sont annulées et réorganisées, et il y a de nombreuses règles à retenir pour l’opération.

Conclusion et perspectives : Les documents valent plus que le code

Le titre de l’article correspond à cette déclaration : « Exploring Super-agent Design: Towards a More Autonomous Agent System », vers un système d’agent plus autonome. L’article et le prototype sont complémentaires : l’article traite du design, dont une partie concerne les directions futures ; le prototype ne présente que la partie déjà réalisée, affirmant que les deux ne sont pas identiques. Deux choses méritent attention : si un deuxième ou un troisième bundle important émerge dans l’écosystème DSH ; et si l’équipe DeepSeek met en œuvre les directions futures mentionnées dans l’article dans les versions suivantes.

Pour les lecteurs, la valeur de ce repository est clairement hiérarchisée. Le niveau le plus bas contient le modèle d’autorisation qui peut être directement transféré : le hôte détient les droits, les messages ne sont que des entrées, Mandate est immuable, et il y a un recheck avant la restauration. Le niveau intermédiaire concerne les axiomes du design économique de l’attention et les obligations des opérateurs. Le niveau le plus haut contient les 12 390 lignes de code TypeScript, qui selon le README ne constitue qu’un exemple potentiel avec des bugs. Ma conclusion en une phrase : dsh-superagent mérite d’être lu, les documents valent plus que le code pour être étudiés en profondeur ; il prouve que la difficulté du système d’agent ne réside pas dans ses capacités, mais dans l’autorisation et l’attention, deux problèmes pour lesquels il existe des solutions ingénieuses.

Sources de référence

• Références et README : https://github.com/deepseek-ai/dsh-superagent-prototype (13,000★ / 1,348 forks / 0 problèmes ouverts / 79 abonnés, date de mise à jour : 2026-11-03)
• Vérification du clone local (2026-11-03) : README.md, SETUP.md, docs/000-philosophy.md, docs/001-domain.md, docs/002-authorization.md, docs/003-execution.md, src/policy.ts, package.json, prompts/, skills/
• Articles associés : “Exploring Super-agent Design: Towards a More Autonomous Agent System” (référence dans le README, les déclarations du prototype ne correspondent pas exactement aux articles)
• Discussions HN sur la plateforme DSH : developer preview 747▲/314c (2026-08-13) ; Harness Desktop 417▲/228c (2026-10-02)
• Contributions HN pour ce répertoire : plus haut score 11▲/0 évaluations (2026-10-31)

Auteur : Yongliang