Pourquoi DeepSeek l’appelle Super-agent : les choix derrière le prototype
Un chef de produit DeepSeek explique le nom, les raisons d’une architecture à deux couches et les problèmes que l’équipe doit encore résoudre.
En bref : Le Super-agent de DeepSeek place une couche de coordination au-dessus de l’agent qui exécute le travail. Dans une explication distincte, le chef de produit Cui Tianyi indique que cette conception répond à une tension entre la continuité d’une tâche à l’autre et la capacité à traiter plusieurs travaux en parallèle. L’implémentation publique est un premier prototype de recherche ; plusieurs idées de la conception restent inachevées.
À propos de cet article : Ce texte reformule une explication en chinois de Cui Tianyi, qui se présente comme membre du département produit de DeepSeek et comme l’un des réviseurs finaux de l’article de conception de Super-agent. Il attribue les idées, la conception, le code et les expériences à l’équipe DeepSeek Harness, en particulier à Yujia Qiao, première personne créditée comme auteur de l’article original. Cameron Voss et Marcus Bell ont préparé ce récit indépendant : ce n’est ni une citation directe ni un article rédigé par DeepSeek.
Pourquoi le nom Super-agent ?
Le nom décrit la position de l’agent supplémentaire. Selon Cui Tianyi, « super » signifie ici « au-dessus » : une couche de coordination se situe au-dessus de l’agent principal qui exécute le travail. Elle s’oppose ainsi à un sous-agent placé sous un agent principal. Le nom ne prétend pas que le système est intrinsèquement supérieur ou doté d’une intelligence particulière.
La distinction tient à l’architecture. Au lieu de traiter chaque demande comme une conversation isolée, la conception explore une couche supérieure capable de suivre le travail entrant pendant que l’exécution se déroule dans des tâches distinctes.
Envie d’essayer DeepSeek dès maintenant ? Découvrez notre abonnement DeepSeek.
L’idée des deux couches est-elle une nouvelle théorie ?
Non. Cui Tianyi explique que l’équipe ne l’a pas présentée comme une nouvelle théorie et que d’autres équipes avaient déjà expérimenté des approches similaires. Selon lui, la difficulté consiste à choisir une direction qui reste pertinente dans la durée et optimise le système dans son ensemble, plutôt qu’à essayer toutes les combinaisons possibles d’agents.
Le dsh-superagent-prototype publié est une première exploration. Le dépôt public le décrit comme du code de recherche, et non comme un produit officiel DeepSeek ou un logiciel prêt pour la production. Il précise aussi que le prototype publié diffère de la version interne et de l’article de conception ; certaines idées présentées dans l’article sont des pistes de travail futures.
Pourquoi ajouter une couche au-dessus de l’agent qui travaille ?
La mémoire à long terme est l’une des motivations. Cui Tianyi indique qu’il n’existe toujours pas de solution consensuelle pour assurer la continuité des agents dans les travaux de longue durée. Au moment de son explication, DeepSeek Harness ne disposait pas de mémoire à long terme intégrée entre les sessions ; il a suggéré que cela pourrait changer, sans annoncer de lancement.
Il présente un compromis : un agent a besoin de continuité entre les tâches, mais doit aussi pouvoir traiter suffisamment de travail. Une session continue peut conserver le contexte, tandis que des sessions de travail distinctes peuvent faciliter l’exécution simultanée. La conception à deux couches cherche à examiner cette tension ; elle ne prouve pas que l’équipe a trouvé la meilleure implémentation.
| Question de conception | Ce que suggère l’explication |
|---|---|
| Continuité | Suivre le travail d’une tâche à l’autre sans dépendre uniquement d’une interaction brève. |
| Capacité de traitement | Permettre l’exécution des tâches pendant qu’une couche supérieure assure la coordination. |
| Question ouverte | Comment conserver le contexte utile sans que la coordination ou la mémoire deviennent un goulot d’étranglement ? |
La dernière ligne est une interprétation éditoriale du compromis, pas un résultat mesuré. Les captures d’écran ne fournissent pas de benchmark et ne démontrent pas que cette architecture résout le problème de mémoire.
Qu’est-ce qui reste à terminer ?
Cui Tianyi explique que l’équipe a simplifié l’ingénierie et les scénarios d’utilisation afin de garder son système interne gérable. Un déploiement plus large dans des situations réelles nécessiterait de répondre à plusieurs questions ouvertes dans la section 8 de l’article de conception :
- Comment étendre l’architecture à deux couches.
- Comment les personnes et les agents collaborent au-delà d’une seule session.
- Où se situent les limites du contexte et comment les agents communiquent entre eux (A2A).
- Comment traiter la sécurité et la confidentialité.
Il remarque aussi que séparer le calcul, l’état et l’environnement demanderait encore un travail considérable dans DeepSeek Harness. Le prototype a été utilisé dans un environnement interne relativement restreint et de confiance. Les déploiements réels présentent des conditions plus variées et des problèmes encore non résolus.
Que peuvent en retenir les équipes ?
Considérez cette conception comme un moyen d’examiner la continuité, la coordination et la charge de travail, plutôt que comme un modèle achevé. Avant de l’appliquer à un contexte plus large, déterminez qui peut autoriser le travail, quel contexte chaque tâche reçoit, comment l’exécution est isolée et ce qui se passe lorsqu’une tâche échoue. Ce sont des questions d’évaluation, pas des affirmations selon lesquelles le prototype y a déjà répondu.
Pour mieux comprendre l’implémentation publique, consultez notre guide de configuration et des coûts de SuperAgent et notre présentation de SuperAgent (en anglais).