En Bref

Le 31 octobre 2026, l’équipe DeepSeek Harness a publié un essai de conception, Exploring Super-agent Design: Towards a More Autonomous Agent System, accompagné d’un prototype de recherche sous licence MIT, dsh-superagent-prototype. Ce n’est pas un nouveau modèle. C’est une proposition pour le système qui entoure le modèle.

• La thèse : la limite du développement agentique n’est plus le modèle. C’est l’humain qui doit surveiller trois à cinq sessions d’agents en parallèle.
• La réponse : un Router permanent qui parle aux humains et distribue le travail, et des Workers isolés qui portent chacun une seule tâche.
• Le résultat le plus utile : demander à un agent de déléguer ne marche pas de façon fiable. La délégation doit être inscrite dans la structure.
• Les chiffres : encourageants mais synthétiques. Temps médian de 12,4 minutes contre 20,4 pour une session unique, pour environ 3,8 fois plus de lectures en cache.
• Le prototype : honnête sur lui-même. Code de recherche, accès complet au compte système, un seul dépôt GitHub, Feishu en option, travail proactif en mode « observe » par défaut.

Mon verdict en une ligne : l’architecture mérite d’être copiée, le code mérite d’être lu, et personne dans une banque ne devrait le faire tourner tel quel.

https://open.spotify.com/episode/5n1ioVax4xtuV4TPQR9Xyd?si=jRipVpC5SBmfRf1BkKnz1A

D’abord, remettre les noms à leur place

La moitié des posts que j’ai lus cette semaine mélangent trois choses différentes. « DeepSeek SuperAgent Harness » est l’étiquette que la communauté a collée sur l’ensemble, mais il faut séparer les couches pour évaluer quoi que ce soit.

Nom	Ce que c’est	Sortie
DeepSeek Harness (DSH)	Runtime d’agent de code open source, licence MIT. Tout est plugin, y compris la boucle de l’agent, au-dessus d’un framework de composition appelé Cordis. Compatible avec d’autres fournisseurs et les endpoints compatibles OpenAI.	13 août 2026, avec DeepSeek V4 Pro
Essai Super-agent	Une proposition d’architecture pour un système d’agents permanent et multitâche. Signé Yujia Qiao pour l’équipe Harness.	31 octobre 2026 (WeChat et X)
dsh-superagent-prototype	Bundle TypeScript v0.1.0 qui tourne comme un profil DSH dédié. Un dépôt GitHub, Feishu en option, un panneau web local.	31 octobre 2026

Le prototype n’est pas un fork. C’est un ensemble de plugins DSH : un plugin Super Agent central, un observateur GitHub et un observateur Feishu, branchés via un fichier de patch Cordis, plus des presets Router et Worker allégés.

Une réserve sur laquelle je reviendrai souvent. Le README précise que le code public diffère du système interne de DeepSeek, et que certaines idées de l’essai sont des pistes futures, pas des fonctionnalités. Dans cet article, « la conception » désigne l’ambition et « le prototype » désigne le code.

Le vrai goulot d’étranglement, c’est vous

Le point de départ de DeepSeek, tous les gros utilisateurs de Claude Code, Codex ou du mode agent de Copilot le ressentent déjà. Un agent qui corrige un bug, c’est réglé. Dix agents sur dix tickets, c’est un autre métier, et ce métier retombe sur vous.

L’équipe observe qu’une personne suit environ trois à cinq sessions actives avant de décrocher. On oublie quelle session attend une validation, laquelle tourne en boucle, et lesquelles modifient en silence la même pull request. C’est une observation de terrain, pas une loi mesurée, mais je n’ai jamais rencontré un développeur qui la contredise.

L’essai fixe quatre objectifs pour un système qui enlève cette charge :

• Continu : un changement de cap dans une revue de PR atteint le travail qui a commencé dans une discussion de chat.
• Productif : plusieurs tâches avancent, et de nouvelles consignes arrivent pendant que d’anciennes commandes tournent encore.
• Proactif : l’agent réagit aux événements pertinents selon une politique, et se tait quand il n’a rien d’utile à dire.
• Persistant : il survit aux redémarrages et aux coupures réseau, et se remet des incidents.

Le principe affiché dans le README le résume bien : consommer le moins d’attention humaine possible et apporter le plus de valeur possible. Je l’afficherais au mur de toute équipe qui construit des agents internes.

L’architecture : un Router, plusieurs Workers

La conception rejette les deux options évidentes. Tout envoyer dans une seule grosse session donne un contexte partagé, mais une seule chose à la fois et des tâches qui se contaminent. Ouvrir une session neuve par événement donne de la vitesse, mais aucune continuité, et plusieurs agents qui vous répondent en même temps.

Le compromis tient en deux couches.

• Le Router est une session unique et durable. Il reçoit les interactions, garde une vue d’ensemble des tâches et de leurs liens, distribue le travail et répond aux humains. Il n’écrit pas de code. Les auteurs suggèrent même de le priver de shell, ce qui supprime la tentation de faire le travail lui-même. Un modèle plus léger et moins cher lui suffit.
• Les Workers portent chacun une tâche dans un contexte et un répertoire isolés. Le modèle le plus fort va ici, parce que ce sont eux qui produisent ce qu’on juge. Un Worker complexe peut ouvrir ses propres sous-agents, invisibles pour le Router.

Flux du Super-agent · filtre, Router, Workers

Chaque événement passe un filtre de code avant qu’un modèle ne le voie. Dès qu’un Worker possède un fil, les événements suivants contournent le Router.

Cela inverse un réflexe que je vois dans la plupart des pilotes d’agents en entreprise, où l’« orchestrateur » reçoit le modèle premium. Le Router de DeepSeek ne décompose pas les problèmes. Il affecte et il suit. C’est un travail moins cher.

Du bruit au travail : déclencheurs, filtre et fils

Un agent permanent reçoit bien plus que des demandes directes. Messages de chat, commentaires de PR, résultats de CI, rappels de calendrier : tout devient un Trigger, et la plupart ne méritent rien.

1. Un filtre déterministe passe en premier. Du code simple vérifie la source, l’expéditeur contre une liste autorisée, la liste des bots, et si l’agent a été interpellé. Aucun appel de modèle n’est dépensé sur le bruit évident.
2. Un modèle évalue ce qui passe. Les candidats sont jugés selon des règles rédigées en langage naturel par l’équipe.
3. Le travail accepté devient un Ticket avec un Mandat. Le Mandat enregistre qui a demandé, sous quelles règles et quelle version de politique, et jusqu’où le travail peut aller.

Les événements liés sont regroupés en Threads : une PR et ses commentaires de revue, un sujet de chat et ses réponses. Dès qu’un Worker possède un Ticket, il s’abonne au Thread, et les événements suivants lui arrivent directement par du code, sans nouvelle décision de routage. DeepSeek appelle cela le pass-through. Les abonnements sont multiples dans les deux sens : deux Workers sur la même PR voient les mêmes événements. Cela leur donne une chance de repérer un conflit. Ce n’est pas un verrou.

Le contexte comme un cache, et la chaîne de rappel

L’essai emprunte deux idées aux systèmes informatiques. Inline place directement dans le contexte ce qui sera probablement utile : messages voisins, message parent, commentaires de revue adjacents. Spill garde le reste à l’extérieur, derrière un court résumé et un identifiant qu’on peut déplier plus tard.

Comme événements, Threads et sessions se référencent par identifiant, le Router peut remonter d’un nouveau commentaire à son Thread, du Thread à une session de Worker, puis à une discussion vieille de plusieurs semaines. DeepSeek appelle cela la chaîne de rappel (chain of recall). C’est un chemin d’accès, pas la garantie que le modèle choisira le bon historique. L’équipe classe elle-même la mémoire longue parmi les problèmes non résolus.

Proactif, mais avec une raison de se taire

C’est la partie la plus mûre à mes yeux, et c’est là que le prototype est plus prudent que le buzz qui l’entoure.

Le contexte n’est pas une autorisation. Dans le modèle d’autorisation du prototype, c’est l’hôte qui applique les listes autorisées, les règles et les Mandats. Messages, commentaires et documents cités sont des entrées pour une décision. Ils ne peuvent pas modifier les permissions. Un commentaire qui arrive sur un Thread suivi atteint le Worker comme contexte et ne lui donne aucun droit nouveau.

Trois modes d’acceptation pour le travail proactif :

Mode	Ce qui arrive au travail inféré (messages non adressés, messages de bots, relances de personnes hors liste)
off	Rien d’inféré ne devient candidat
observe (par défaut)	Les candidats sont évalués, un avis positif est journalisé en « aurait accepté ». Rien ne s’exécute.
auto	Une évaluation positive accepte le travail

Les demandes explicites des personnes autorisées fonctionnent dans tous les modes. La documentation conseille de démarrer en observe, de relire les décisions journalisées, puis seulement de passer en auto. DeepSeek aurait déployé son système interne de la même façon. Si vous ne retenez qu’une idée de cette publication pour votre plateforme d’agents, retenez celle-là.

Quelques détails utiles :

• Les bots ne donnent pas d’ordres. Un bot listé comme Dependabot peut produire un candidat inféré, jamais une demande explicite, et il ne peut pas arrêter un Ticket.
• Les Mandats sont revalidés. Changez la politique, retirez quelqu’un de la liste, et un Ticket en attente peut perdre son Mandat avant de reprendre.
• Arrêter est un acte humain. Quelqu’un qui écrit « stop » dans un fil passe par l’évaluation. Un arrêt depuis le panneau est une commande directe. Un Worker ne peut pas déclarer de lui-même qu’on lui a demandé d’arrêter.

Reproduire et corriger en silence. En interne, DeepSeek applique une politique où un bug signalé dans un chat est reproduit en arrière-plan. Si l’agent confirme le bug et trouve un correctif, une pull request apparaît pendant que la discussion continue. Sinon, personne n’en entend parler. Le travail spéculatif coûte du calcul, mais il se jette facilement. Un commentaire publié ou un merge, non. C’est pour ça que la frontière d’autorisation se trouve là.

Le runtime : full-duplex, vos propres machines, un Watchdog

Une commande longue ne doit pas prendre la conversation en otage. Dans la conception, un outil peut lancer une tâche de fond, rendre la main à la boucle de l’agent et livrer son résultat plus tard sous forme d’événement. L’équipe parle de full-duplex : vous envoyez une correction pendant qu’un build de dix minutes tourne. Dans le prototype, toute commande shell qui dépasse cinq secondes passe en arrière-plan, pour que le Worker continue à recevoir des messages. L’essai précise que le mécanisme asynchrone général existe dans DSH mais n’était pas activé par défaut.

Séparer l’agent de ses machines. Un agent local lie trois choses : le calcul qui fait tourner la boucle, l’état de la session et l’environnement où les commandes s’exécutent. Fermez le portable, les trois disparaissent. La conception les découple en deux temps. L’état vit dans un stockage persistant, donc la boucle peut redémarrer n’importe où. Ensuite, la boucle atteint les environnements d’exécution via de petits démons. DeepSeek appelle cela Bring Your Own Machine : votre poste, avec ses modifications non commitées, son GPU et son accès intranet, devient un point d’exécution parmi des sandboxes cloud. L’équipe cite le travail d’Anthropic sur les managed agents pour la séparation cerveau / mains, et met l’accent sur les machines personnelles à connexion intermittente. Précision : c’est de la conception, pas une fonctionnalité du prototype.

Un Watchdog pour les agents vivants mais bloqués. Un processus peut tourner sans avancer : il relance la même commande en échec, perd le fil de sa tâche, attend une dépendance morte. La conception propose une session d’agent séparée, réveillée sur planning, qui vérifie l’infrastructure, juge si les Workers progressent et tente des réparations. Aucun taux de détection ou de réparation n’est fourni. Le prototype documente seulement un contrôle horaire externe d’état et de reprise, bien plus limité.

Discipline de communication. L’équipe indique qu’une limite d’environ 100 mots pour les réponses en messagerie instantanée a bien fonctionné chez elle, tandis que les PR portent tout le contexte. Le détail va là où il a sa place, le chat reste pour les décisions.

Les chiffres, et ce qu’ils ne mesurent pas

Le Super-agent a terminé des tâches simulées environ 39 % plus vite en médiane qu’une session unique, pour environ 3,8 fois plus de lectures en cache. Lisez le protocole avant de citer ce chiffre.

Chaque run envoyait environ 300 messages de chat et de CI, dont une vingtaine de vraies demandes de travail, le reste étant du bavardage, des relances et des annulations. Quatre conceptions, cinq runs chacune. Le code lui-même était simulé par un outil qui consommait du temps, et les intervalles de messages et durées de travail ont été réduits, pas les appels de modèle. On mesure de l’ordonnancement, pas la qualité du code.

Conception	Temps médian (p50)	p95	Lectures en cache par run
Super-agent	12,4 min	15,7 min	23,2 M
Super-agent sans pass-through	12,6 min	15,5 min	31,8 M
Session unique, outil sous-agent, prompt neutre	20,4 min	29,5 min	6,1 M
Session unique, outil sous-agent, prompt pro-délégation	13,8 min	29,0 min	10,8 M

Source : essai de DeepSeek, repris par Kingy AI et Dataconomy. Chiffres de l’équipe, non reproduits indépendamment.

Trois résultats me frappent.

1. Les prompts ne produisent pas la délégation. Avec un prompt neutre du type « utilise des sous-agents si c’est pertinent », la session unique n’a jamais délégué en cinq runs. Avec un prompt qui pousse à déléguer, elle l’a fait quatre fois, puis a jugé la cinquième tâche trop petite et l’a faite seule, ce qui a fait exploser sa latence de queue. La structure bat la formulation.
2. Le pass-through se rentabilise en tokens. Sans livraison directe aux Workers abonnés, le Router prend environ 30 % de décisions en plus et les lectures en cache augmentent d’environ 37 %. La latence bouge à peine.
3. Le Router devient plus efficace sous charge. Dans un test de stress séparé, quand les décisions par minute passent d’environ 1 à environ 40, la taille moyenne des lots passe de 1,0 à 2,8. Chaque appel ralentit de 2,5 à 3,9 secondes, mais le temps amorti par décision tombe de 6,4 à 1,6 seconde. Un seul Router peut vraisemblablement servir une équipe avant qu’il faille le découper.

Côté coût, l’argument de DeepSeek est que cette conception n’a de sens économique qu’avec des modèles rapides et bon marché. Les lectures en cache se multiplient, ce qui reste abordable au tarif « flash » et devient cher au tarif des modèles de pointe. Ce qui manque à l’évaluation : des tâches réelles, la justesse du code, les PR acceptées, le temps de revue humaine, la charge de notifications et des tests adverses. Ce sont pourtant les chiffres dont une banque aurait besoin.

Ce que le prototype open source apporte vraiment

Le dépôt a dépassé 17 000 étoiles GitHub en moins de quatre jours. Des étoiles ne sont pas des déploiements, alors voici ce que vous obtenez en le clonant.

Ce qu’il fait. Il surveille un dépôt GitHub et, en option, Feishu. Quand une personne autorisée demande du travail, il ouvre un Ticket, le traite dans sa propre session DSH et son propre répertoire, et répond dans la conversation d’origine, souvent par une pull request. Un panneau web local montre ce qui attend un humain. L’installation est assez longue pour que le README recommande de se faire guider par un agent de code via SETUP.md. La documentation est numérotée de 000 à 008, de la philosophie à un guide pour ajouter une nouvelle source, et c’est la meilleure partie de la publication.

Prérequis. Node.js 22.19+ ou 24+, Git 2.32+, Python 3.8+, tmux et GitHub CLI 2.48+, plus une version compatible de DSH (^0.2.1-alpha.2). En pratique, c’est POSIX uniquement. Des retours de la communauté montrent que Windows natif demande des correctifs, ou WSL.

Les avertissements qui comptent :

• Pas de sandbox. Les deux presets tournent en danger-full-access sous votre compte système. Des répertoires séparés ne sont pas une isolation. Le guide de déploiement recommande un compte système dédié. J’ajouterais une VM dédiée.
• L’état est local. Une base SQLite et un verrou de répertoire. Le système cloud « bring your own machine » de l’essai n’est pas là.
• Le circuit de réponse diffère de l’essai. Dans le prototype, les Workers peuvent accuser réception et traiter eux-mêmes les relances dans leur périmètre. Le Router ne relaie pas tout.
• Les validations, c’est votre affaire. Les consignes données à l’agent sur les merges ne remplacent pas la protection de branche GitHub.
• Attendez-vous à des angles vifs. Les issues et PR du dépôt sont désactivées, donc les bugs sont signalés dans les Discussions de DeepSeek Harness. En une semaine, des utilisateurs ont documenté un flux de polling GitHub qui cale après 100 événements au même horodatage, des mentions tardives perdues, et des conditions de course où une relance atteint un Worker après le changement de son autorisation.

Rien de scandaleux. DeepSeek a dit clairement qu’une grande partie de ce code a été écrite par des agents et qu’il s’agit de code de recherche. C’est une référence à lire et dont s’inspirer, pas un produit à installer lundi matin.

Mon avis : le harness engineering vient de trouver son architecture de référence

Si vous avez suivi ma série sur le prompt, le context et le harness engineering, cette publication est la troisième couche rendue concrète. Le modèle est une matière première. Ce qui décide de la vitesse, du coût et de la sécurité, c’est le système autour.

Ce que DeepSeek a bien vu

• L’attention comme ressource rare. La plupart des métriques d’agents comptent des tokens ou des taux de réussite. Celle-ci compte combien de fois on interrompt un humain. C’est la bonne métrique pour une équipe, et presque personne ne la mesure.
• La délégation comme structure, pas comme consigne. Leur propre expérience montre qu’un modèle à qui on demande de déléguer refuse parfois. Si votre orchestration dépend du bon vouloir du modèle, vous avez écrit une suggestion, pas une architecture. Retirez les outils au Router et le problème disparaît.
• Des événements plutôt que des prompts. L’agent n’est plus une fenêtre de chat qu’on visite. Il devient un collègue qui vit dans GitHub et dans le chat d’équipe. Un filtre déterministe bon marché devant un filtre sémantique coûteux, c’est simplement de la bonne ingénierie.
• Le contexte n’est pas une autorisation. Séparer ce qu’un agent peut lire de ce qu’il peut faire est l’idée de sécurité la plus importante des systèmes agentiques. La voir écrite sous forme de modèle de domaine, avec Mandats, revalidation et versions de politique, a de la valeur même si vous ne lancez jamais le code.
• Observer avant d’automatiser. Journaliser ce que l’agent aurait fait, le relire, puis accorder l’autonomie. C’est ainsi qu’on déploie tout contrôle automatisé dans une banque. Voir un labo d’IA arriver au même endroit fait plaisir.

Ce qui m’inquiète

• Les preuves portent sur l’ordonnancement. Coordonner plus vite du travail simulé ne dit encore rien sur la justesse du code, les PR acceptées ou la charge de revue. Je veux ces chiffres avant de croire au discours sur la productivité.
• La surface d’attaque est énorme. Un agent permanent qui lit des fils de chat et des commentaires de PR, tourne avec tous les droits de l’utilisateur et peut ouvrir des PR, c’est une cible d’injection de prompt. Le Mandat limite le travail autorisé. Il n’empêche pas un commentaire piégé sur une PR suivie d’orienter ce que fait le Worker dans son périmètre, par exemple lire un fichier .env. L’essai reconnaît lui-même que des identifiants peuvent atterrir dans le contexte du modèle en fonctionnement normal.
• Des sessions invisibles peuvent devenir du travail invisible. Une seule voix face aux humains, c’est parfait jusqu’au jour où il faut auditer qui a fait quoi et pourquoi. Le panneau est un début, pas une piste d’audit.
• La mémoire sur plusieurs mois n’est pas résolue, et l’équipe le dit. La chaîne de rappel donne un chemin vers l’historique. Elle ne garantit pas que le modèle choisisse le bon.
• L’économie dépend de modèles bon marché. Presque quatre fois plus de lectures en cache, ça passe au tarif flash. Avec un modèle de pointe sur les Workers, faites vos propres calculs.

Est-ce une idée nouvelle ?

Pas vraiment, et ce n’est pas grave. Les schémas superviseur / exécutant, l’event sourcing, les tâches de fond et les watchdogs ont des décennies. Anthropic a publié la séparation cerveau / mains, et DeepSeek le cite. Des agents de code hébergés transforment déjà une issue en PR. Ce qui est nouveau, c’est un labo qui publie tout le modèle opérationnel en clair : le modèle de domaine, les règles d’autorisation, l’expérience, les échecs, sous licence MIT. C’est le document de référence le plus utile sur l’exploitation multi-agents que j’ai lu cette année.

À quoi ça ressemblerait dans une banque

Le schéma convient bien à une équipe de développement régulée, à condition de placer les contrôles là où la conception leur laisse déjà de la place. Voici un scénario fictif mais réaliste.

Le contexte. Une équipe de douze personnes maintient le service de reporting de portefeuilles d’une banque privée. Un système de type Super-agent surveille leur dépôt Git et le canal de support interne utilisé par le helpdesk des banquiers privés.

1. Un message arrive. Une analyste du helpdesk signale dans le canal de support que les relevés trimestriels affichent un mauvais taux de change sur les positions en CHF. Elle ne mentionne pas l’agent.
2. Le filtre décide. Le canal est configuré, l’analyste est sur la liste, le message n’est pas adressé : il devient un candidat inféré. La politique contient une règle active : reproduire les bugs de reporting sur des données synthétiques, ne jamais toucher à la production.
3. Observer, puis automatiser. Pendant les premières semaines, le système se contentait de journaliser « aurait accepté ». Le lead technique relisait ces décisions chaque vendredi avant de passer cette règle en auto.
4. Un Worker reproduit le bug. Dans une VM dédiée, avec des portefeuilles de test masqués et sans accès réseau à la production, le Worker écrit un test qui échoue, trouve un arrondi appliqué avant la conversion, le corrige et ouvre une PR.
5. Les humains valident. La protection de branche exige deux approbations, dont un code owner. L’agent n’a aucun droit de merge. Un commentaire de revue arrive directement au Worker abonné, qui pousse une révision.
6. Une réponse courte. Le Router répond à l’analyste en moins de 100 mots, avec le lien de la PR et la fenêtre de livraison prévue. Personne d’autre n’a été interrompu.

Ce que l’agent n’obtient jamais dans cette histoire : des identifiants de production, des données clients réelles, un droit de merge ou une validation de gestion du changement. Tout cela reste humain.

Checklist d’adoption pour les équipes régulées

• ☐ Traiter dsh-superagent-prototype comme une conception de référence. Reconstruire le schéma sur votre plateforme d’agents validée, ou durcir un fork après une revue de sécurité complète.
• ☐ Faire tourner les Workers sous un compte système dédié, dans une VM ou un conteneur, sans route vers la production et avec une liste blanche de sortie réseau.
• ☐ Aucun secret longue durée dans l’environnement de l’agent. Des jetons courts, au moindre privilège, et un scan de secrets sur chaque PR d’agent.
• ☐ Données synthétiques ou masquées uniquement. Les données clients n’entrent jamais dans un prompt, conformément au secret bancaire et aux règles de protection des données.
• ☐ Décider où tourne l’inférence. L’adaptateur DSH par défaut pointe vers l’API de DeepSeek : évaluer le fournisseur, ou router vers un endpoint validé ou auto-hébergé. Pour les groupes régulés dans l’UE, les règles DORA sur les prestataires TIC tiers s’appliquent.
• ☐ Limiter la liste autorisée à des personnes nommées, et laisser sur ignore les cellules d’admission pour les expéditeurs hors liste. Ne jamais ouvrir une cellule de demande explicite sur un canal large.
• ☐ Démarrer chaque règle proactive en observe. Passer en auto règle par règle, seulement après avoir relu un vrai échantillon de décisions journalisées.
• ☐ Imposer les validations dans la plateforme : protection de branche, code owners, principe des quatre yeux. Une consigne dans un prompt n’est pas un contrôle.
• ☐ Exporter Mandats, décisions et versions de politique vers le SIEM et les relier aux tickets de changement, pour qu’un auditeur sache qui a autorisé quoi.
• ☐ Faire un red team des canaux d’événements avec des issues, commentaires et logs de CI piégés avant la mise en service.
• ☐ Mesurer ce qui compte : interruptions humaines par semaine, taux de PR acceptées, temps de revue, reprises et incidents.
• ☐ Mettre un modèle bon marché sur le Router, le plus fort sur les Workers, et faire vos propres calculs de coût avant de passer à l’échelle.

Conclusion

DeepSeek n’a pas livré un produit. Il a livré un modèle opérationnel pour les agents, avec ses compromis, ses chiffres et ses problèmes ouverts sur la table. La leçon pour quiconque construit une plateforme d’agents interne est simple : arrêtez d’optimiser la conversation avec un agent, et concevez le système qui évite à vos équipes d’avoir beaucoup de conversations.

Lisez l’essai. Lisez les documents numérotés du dépôt, dans l’ordre. Puis reprenez les quatre idées qui comptent, dans cet ordre : un filtre déterministe, des Mandats qui séparent contexte et autorisation, l’observation avant l’automatisation, et un Router incapable de faire le travail lui-même.

J’aimerais beaucoup entendre les équipes qui testent ce schéma en environnement régulé. Que mettriez-vous devant le filtre ?

Sources

• Exploring Super-agent Design: Towards a More Autonomous Agent System, équipe DeepSeek Harness (version anglaise sur X)
• README de dsh-superagent-prototype et 002 Authorization, DeepSeek sur GitHub
• DeepSeek’s Super-agent Design Explained, Kingy AI, 1er novembre 2026
• DeepSeek releases open-source dsh-superagent coding agent, Dataconomy, 2 novembre 2026
• DeepSeek’s Super Agent Harness: Fixing the Attention Bottleneck, MindStudio, 3 novembre 2026
• DeepSeek Harness Explained: The Plugin Architecture Behind Super Agent, MindStudio, 4 novembre 2026
• DeepSeek Superagent Tutorial, DataCamp
• Signalements de la communauté : #11700, #11774, #11801, Discussions DeepSeek Harness