Architecture de DeepSeek SuperAgent : comment fonctionne son agent de programmation open source

Mis à jour le 2 novembre 2026 · Analyse de la recherche et de la documentation

Le prototype SuperAgent de DeepSeek transforme l’activité d’un dépôt en travail de programmation continu. Ses choix de conception les plus intéressants ne concernent pas seulement l’écriture du code : ils portent aussi sur les événements qui méritent une action, la conservation du contexte d’une tâche et le moment où une personne doit reprendre la main.

Un assistant de programmation peut corriger un bug en une session. Une équipe a besoin de davantage : une issue est créée, une correction est examinée, une vérification échoue et un commentaire apparaît le lendemain. Il faut relier ces événements et décider de la suite. SuperAgent cherche à intégrer cette coordination au système d’agents lui-même.

Cet article examine le prototype public et sa documentation, puis propose une méthode pratique pour l’évaluer. Les exemples sont illustratifs : nous n’avons pas déployé le système ni mesuré ses performances pour cet article.

Qu’est-ce que DeepSeek a exactement publié en open source ?

Le projet public dsh-superagent-prototype est un agent de programmation proactif qui travaille sur un seul dépôt GitHub. GitHub fournit une source de demandes et d’activités ; Feishu peut être ajouté comme autre source. Le système peut créer un élément de travail pour une demande autorisée, l’exécuter dans une session d’agent et un répertoire distincts, puis répondre dans la conversation d’origine, par exemple avec une pull request.

Le projet se présente comme du code de recherche, et non comme un produit officiel. Son README précise que la version publiée est adaptée de travaux internes et diffère à la fois de cette implémentation et de celle décrite dans la recherche associée. Certaines idées de recherche restent des pistes futures. Cette distinction compte : une idée d’architecture décrite dans un article n’est pas nécessairement une fonctionnalité présente dans cette version.

Comment une demande devient-elle une tâche de programmation ?

Le modèle de domaine du projet distingue l’origine d’un événement du travail qu’il peut déclencher. Une Source fait entrer une activité dans le système. Un Trigger représente un événement. Un Ticket représente une tâche ; son Mandate (mandat) consigne la raison pour laquelle elle a été acceptée. Un Executor traite le ticket dans sa propre session.

Le routeur décide si un candidat doit créer une tâche, être associé à un travail existant, être ignoré ou, lorsque cela convient, arrêter un travail. L’exécuteur réalise la tâche acceptée et en communique l’état. Cette séparation permet au système de recevoir de nouvelles activités pendant qu’une tâche d’implémentation se poursuit.

Exemple : une issue suivie d’un commentaire de revue

Supposons qu’un membre autorisé de l’équipe mentionne l’agent dans une issue GitHub et lui demande d’enquêter sur l’échec d’un test. L’agent accepte la demande, prépare le répertoire du ticket et mène l’enquête. S’il ouvre une pull request, les échanges ultérieurs peuvent parvenir au ticket concerné. Une demande de suivi qui reste dans le périmètre peut être traitée par l’exécuteur existant ; une demande hors périmètre peut être renvoyée pour routage. Cet exemple illustre le modèle documenté, sans garantir la réussite de chaque correction.

Qui peut autoriser l’agent à agir ?

Le mécanisme d’autorisation distingue une demande explicite d’un candidat inféré. Une personne autorisée qui s’adresse à l’agent peut formuler une demande explicite. D’autres activités, notamment certains messages qui ne s’adressent pas à l’agent ou des messages de bots inscrits sur une liste, peuvent devenir des candidats inférés selon la politique de la source. Avant leur acceptation, ils doivent être évalués au regard des règles actives de l’équipe.

Les demandes explicites fonctionnent dans les trois modes. Le projet recommande de commencer par observe, afin que les opérateurs puissent examiner les décisions avant d’activer l’acceptation proactive. Cela aide à repérer les règles trop bruyantes : un déclencheur peut être techniquement valide tout en mobilisant inutilement l’attention de l’équipe.

Les messages transmis à un ticket abonné à une conversation apportent du contexte ; ils n’accordent pas automatiquement de nouvelle autorisation. La politique, les listes d’autorisation et le mandat régissent les permissions. Le texte des issues, les commentaires et les documents cités restent des données utilisées pour prendre une décision. Un changement de politique ne révoque pas non plus immédiatement tous les mandats actifs : la documentation décrit des notifications et une nouvelle validation avant certaines reprises. Il faut comprendre ces détails avant de supposer qu’un changement de réglage arrête immédiatement tout travail en cours.

Que se passe-t-il dans une session de travail ?

Chaque ticket reçoit une session d’exécuteur et un répertoire placé sous la racine d’exécution configurée. Une commande de préparation peut créer un worktree Git ; sans commande de préparation, l’exécuteur démarre dans un répertoire vide. Un échec de préparation est enregistré comme un échec du ticket. Le guide d’exécution du projet décrit le cycle complet.

Les exécuteurs occupent des emplacements de concurrence configurés pendant leur lancement ou leur travail actif. Le système prévoit un emplacement supplémentaire pour un message humain ou une demande d’état lorsque la capacité normale est pleine. Les autres entrées, notamment les résultats de CI, attendent un emplacement normal. Le but est qu’une file chargée n’empêche pas une personne de poursuivre un ticket existant.

Le panneau distingue notamment les travaux en file d’attente, en cours, en attente, à examiner, bloqués ou en échec. La distinction est utile : un agent arrêté parce qu’il attend une décision ne devrait pas ressembler à celui qui exécute encore un test.

Comment SuperAgent gère-t-il les interruptions et la reprise ?

Un travail d’agent de longue durée doit prévoir les incidents. Le prototype enregistre les opérations avant d’effectuer des actions telles que le lancement d’une affectation ou la transmission d’une entrée. Les transmissions échouées sont retentées avec des délais croissants ; les erreurs temporaires du fournisseur de modèle ou du réseau donnent lieu à un nombre limité de nouvelles tentatives. Un ticket bloqué ou en échec cesse de recevoir des entrées automatiques jusqu’à une intervention humaine, un rapport répondant aux conditions prévues ou une nouvelle tentative lancée par un opérateur.

Après le redémarrage de l’hôte, les affectations interrompues reprennent avec une note demandant à l’exécuteur de vérifier son répertoire, l’historique Git et GitHub avant de répéter des actions externes. La documentation indique que les sessions, répertoires, abonnements et messages en attente font partie des éléments conservés après un redémarrage. Une nouvelle tentative crée une affectation dans la même session d’exécuteur, le même répertoire, la même branche et la même pull request.

Ces mécanismes réduisent le risque de perdre le fil du travail. Ils ne rendent pas automatiquement sûres les actions externes et ne garantissent pas qu’une opération n’a lieu qu’une seule fois dans tous les scénarios de panne. Avant de répéter une action susceptible d’envoyer un message, de modifier des données ou de déclencher un déploiement, l’opérateur doit vérifier ce qui s’est réellement passé.

Que faut-il pour essayer le prototype ?

Le dépôt fournit un guide de configuration assistée par un agent et des instructions de déploiement manuel. Le guide demande notamment Node.js 22.19+ ou 24+, pnpm, Git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+, une version compatible de DeepSeek Harness et un fournisseur de modèle configuré. Consultez les fichiers actuels pour connaître les éventuels changements de version et les exigences de plateforme.

Le guide recommande un compte GitHub dédié à l’agent, une liste initiale courte de personnes autorisées, le mode observe et la fusion des changements par des humains. Il décrit aussi un profil Harness distinct et une commande de préparation pour créer des copies de travail par ticket. Feishu est facultatif. Examinez chaque étape et les permissions des identifiants ; la liste ci-dessous ne remplace pas les instructions de déploiement du projet.

Une première expérience que nous mènerions

1. Utilisez un dépôt jetable ou à faible risque, sans données sensibles, et accordez au compte dédié de l’agent uniquement les accès nécessaires au test.
2. Gardez l’acceptation proactive en mode observe, choisissez un opérateur autorisé et exigez une fusion par une personne.
3. Demandez une tâche limitée, par exemple diagnostiquer un test dont l’échec est reproductible, avec des critères d’acceptation clairs et sans déploiement.
4. Examinez la décision de routage, le diff proposé, les résultats réels des tests, les messages et l’utilisation du modèle. Consignez les échecs comme les réussites.
5. Examinez les décisions proactives observées avant d’ajouter une règle ou d’élargir les permissions.

Ces étapes sont des recommandations éditoriales, pas les résultats d’un test réel. Choisissez un isolement d’exécution et des contrôles réseau adaptés à votre environnement ; les répertoires du prototype ne les fournissent pas à eux seuls.

Peut-il fusionner ses propres pull requests ?

Le guide de configuration recommande que les humains effectuent la fusion jusqu’à ce que les pull requests de l’agent aient démontré leur fiabilité dans la durée. La documentation d’exécution décrit des instructions facultatives de fusion automatique sous certaines conditions, notamment les approbations requises, mais distingue deux mécanismes : les instructions orientent l’agent, tandis que la protection des branches GitHub impose les règles du dépôt. L’hôte ne dispose pas d’une logique de décision distincte propre à la fusion. Si des approbations sont nécessaires, imposez-les dans GitHub et envisagez d’invalider les approbations devenues obsolètes. Pour un essai entièrement manuel, suivez les instructions de configuration afin de supprimer le paragraphe sur la fusion automatique.

Comment une équipe peut-elle déterminer si l’agent lui est utile ?

Mesurez l’ensemble du travail autour d’une modification, et pas seulement le délai avant l’apparition d’une pull request. Comparez un petit ensemble de tâches similaires à votre processus habituel et conservez les exécutions échouées ou abandonnées dans l’analyse.

Une pull request rapide qui demande des heures de correction n’est pas nécessairement un gain de productivité. De même, un agent qui sait rester silencieux peut être plus utile qu’un agent qui ouvre un ticket pour chaque événement. Notez la difficulté des tâches et la taille de l’échantillon avant de tirer des conclusions.

Quelles sont les limites de la version publique ?

Elle cible un seul dépôt, dépend du Harness et des intégrations associées, et est explicitement décrite comme un logiciel de recherche. Ses responsables signalent de possibles bugs et des pratiques d’ingénierie parfois incohérentes. Certains concepts de recherche ne sont pas implémentés dans le code public. Nous n’avons pas trouvé dans la documentation du projet de fondement permettant d’annoncer un pourcentage général de gain de productivité ou de garantir une gestion autonome d’un dépôt de production.

L’apport architectural est plus précis : le projet traite la responsabilité des tâches, l’autorisation, la continuité et l’attention humaine comme des problèmes d’ingénierie. Une équipe peut étudier ces choix même si elle décide de ne pas déployer ce prototype.

Questions fréquentes

DeepSeek SuperAgent est-il un nouveau modèle ?

Non. Le projet publié est un prototype de système d’agents fourni sous forme de paquet pour DeepSeek Harness. Il nécessite un fournisseur de modèle configuré ; le modèle et le système d’orchestration sont deux couches distinctes.

SuperAgent est-il open source ?

Oui. Le dépôt public est sous licence MIT. Le code publié a été adapté de l’implémentation interne de l’équipe et ne lui est pas identique.

Le mode observe empêche-t-il tout travail ?

Non. Il empêche l’acceptation des candidats inférés comme travail proactif et enregistre les évaluations positives ; les demandes explicites peuvent toujours être acceptées.

SuperAgent peut-il travailler sur plusieurs dépôts ?

Le README public décrit le prototype comme un agent de programmation pour un seul dépôt GitHub. Il ne faut pas présumer qu’une orchestration de plusieurs dépôts est incluse.

Un worktree séparé suffit-il à le sécuriser ?

Non. Le guide d’exécution précise que les répertoires et les enveloppes de commande ne constituent pas une frontière de sécurité. Les exécuteurs lancent les commandes avec le compte du système d’exploitation de l’opérateur ; l’isolement et les permissions doivent donc être examinés séparément.