Dans la soirée du 31 octobre, l'équipe DeepSeek Harness a publié un long article intitulé « Exploration de conception du Super-agent : vers des systèmes d'agents plus autonomes », qui propose une architecture d'agents à deux couches et met en accès public sur GitHub le prototype dsh-superagent-prototype. L'équipe précise dans le texte que ce prototype sert à valider la piste technique et n'est pas un produit officiel de DeepSeek.
Le point de départ de l'article est une observation toute simple : pour qu'un modèle mène seul une tâche à bien, il faut de moins en moins d'intervention humaine, et ce qui freine désormais la productivité, c'est l'attention des personnes. Selon l'équipe, un humain ne peut généralement suivre que 3 à 5 Sessions actives en même temps ; dès que les tâches se multiplient, il doit basculer à la main de l'une à l'autre et garder lui-même le contexte en tête.
La Session devrait être un détail d'implémentation du système, pas une charge cognitive pour l'utilisateur.
Le Router gère la conversation, le Worker le travail
L'architecture se compose de deux couches. La couche Router, résidente, reçoit les messages des humains, tient le contexte global et répartit les tâches ; elle n'embarque pas d'outils d'exécution comme Bash et peut donc être pilotée par un modèle léger. La couche Worker réunit plusieurs sessions aux contextes isolés les uns des autres, dotées de la panoplie complète d'outils et du modèle le plus puissant, chacune concentrée sur une seule chose et toutes s'exécutant en parallèle. Les Workers ne répondent pas directement à l'utilisateur : état et résultats sont d'abord remontés au Router, qui s'exprime seul vers l'extérieur.
Plusieurs autres briques de conception s'articulent autour de l'idée de « garder l'agent toujours en ligne » :
- Piloté par les événements : messages de groupes de discussion, e-mails, rappels d'agenda, commentaires de revue de code et résultats de CI sont tous traités comme des Triggers. Des règles programmées éliminent d'abord l'essentiel du bruit, et seul le reste est confié au modèle pour décider s'il faut agir. Pour les Threads déjà attribués, les événements suivants sont transmis directement par le programme au Worker concerné, sans repasser par le Router.
- ReAct Loop asynchrone : les appels d'outils longs sont scindés en start() et stop(). Une tâche d'arrière-plan renvoie Started dès son lancement, l'avant-plan continue d'écouter l'utilisateur, et le résultat revient dans la session sous forme de nouvel événement.
- Séparation du calcul, de l'état et de l'environnement : l'Agent Loop et l'état résident dans le cloud, l'environnement d'exécution peut rester sur la machine de l'utilisateur, où ne tourne qu'un daemon léger, avec prise en charge de l'apport de sa propre machine (BYOM).
- Watchdog : une session indépendante se réveille à intervalles réguliers et, au-delà de vérifier que les processus sont vivants, demande au modèle d'apprécier si chaque Worker progresse réellement et s'il n'a pas dévié de sa trajectoire.
Le texte cite aussi l'exemple de l'« exécution spéculative » : quand quelqu'un signale un bug dans le groupe, l'agent tente d'abord de le reproduire et de le corriger en arrière-plan, et ne prend la parole qu'une fois le correctif réussi ; s'il n'y parvient pas, il ne dérange personne.
Les chiffres viennent uniquement d'une charge synthétique
L'équipe a mené une expérience comparative : chaque tour comptait environ 300 messages, dont une vingtaine de demandes de travail, le reste étant du bavardage et du bruit ; chaque variante a été répétée 5 fois. Le temps d'exécution des tâches du Super-agent atteint 12,4 minutes au p50 et 15,7 minutes au p95 ; le groupe témoin « Session unique plus Subagent » affiche, avec un prompt neutre, un p95 de 29,5 minutes. Sans le mécanisme de transmission directe des événements, le nombre de décisions du Router augmente d'environ 30 % et les tokens lus en cache d'environ 37 %.
Lors du test de charge du Router, les Triggers sont passés d'environ 1 à environ 40 par minute, la taille moyenne des lots est montée de 1,0 à 2,8 et la durée par requête de 2,5 à 3,9 secondes, tandis que le temps d'inférence réparti sur chaque décision a au contraire baissé de 6,4 à 1,6 seconde.
Les limites sont énoncées sans détour : l'expérience repose sur une charge synthétique et un environnement simplifié, elle ne mesure que l'ordonnancement et la collaboration, pas la qualité d'exécution de chaque tâche prise isolément ; la consommation de tokens du Super-agent dépasse celle de la solution à session unique, mais le total n'est pas communiqué. Le prototype open source ne vise pour l'instant qu'un seul dépôt GitHub ; le fonctionnement multi-appareils, la résidence permanente dans le cloud et le Watchdog ne sont pas entièrement implémentés.
De dsh au Super-agent
Si l'on remet la chronologie en ordre, sur le terrain des agents, DeepSeek a d'abord publié le framework, puis ses réflexions sur l'orchestration. Vers août cette année, la société a ouvert sous licence MIT le framework d'agents DeepSeek Harness (nom en ligne de commande : dsh), dont le système de fichiers, le Shell, l'adaptation des modèles, l'interface Web et les sous-agents sont conçus comme des plugins remplaçables ; dans les mois qui ont suivi, des modèles comme V4.1 Flash sont arrivés les uns après les autres, et des outils de programmation tiers ont aussi commencé à l'adopter comme modèle principal.
Ce nouvel article monte d'un cran et traite de la façon dont une instance d'agent peut surveiller des dizaines de sujets à la fois. L'équipe indique que le mécanisme de tâches asynchrones décrit dans le texte a déjà été intégré à DeepSeek Harness, simplement désactivé par défaut ; des instances internes fondées sur la même idée tournent depuis un moment, servant à reproduire et corriger des problèmes, à répondre aux revues de code, et aussi à faire évoluer Harness lui-même.
Parmi les questions ouvertes listées par l'équipe figurent la manière de faire passer la couche Router à l'échelle quand les tâches augmentent, la mémoire longue portant sur plusieurs mois et la communication entre plusieurs instances d'agents. Le volet sécurité est le plus précis : si l'Agent Loop dans le cloud subit une injection de prompt, les appareils locaux raccordés pourraient être pris en main, et les identifiants placés dans le contexte du modèle pourraient fuiter lors d'une exécution normale. Comment se prémunir contre ces risques, le texte n'apporte pas de solution complète.
Sources : long article technique de l'équipe DeepSeek Harness et description du dépôt dsh-superagent-prototype, ITHome, CocoLoop, Ifeng Tech ; les durées d'exécution et les données du test de charge s'appuient sur les résultats de charge synthétique publiés par l'équipe.