1 novembre 2026
DeepSeek SuperAgent expliqué : un agent de codage qui fonctionne au-delà d'une seule conversation
DeepSeek SuperAgent est un système d'agent de codage expérimental conçu pour suivre le travail dans un référentiel GitHub. Il peut recevoir des demandes autorisées, créer un travail séparé éléments, effectuer des tâches dans leurs propres sessions et renvoyer les résultats à la conversation d'origine. Son idée principale est la continuité : l'agent participe au flux de travail d'une équipe au lieu de mettre fin à son implication lorsqu'une réponse de chat est terminée.
Pourquoi l'idée SuperAgent est importante
La plupart des agents de codage sont bons dans une interaction limitée : confiez-leur une tâche, laissez-les inspecter un projet et examiner la réponse ou le correctif. Le vrai travail logiciel est moins ordonné. Un rapport de bogue peut démarrer dans une conversation, passer à un problème, produire une demande d'extraction et revenir quelques jours plus tard lorsqu'un test échoue ou qu'un réviseur demande une modification.
SuperAgent explore ce qu'il faut pour maintenir ce fil de travail en mouvement. Sa conception traite l'activité entrante, l'autorisation, la propriété des tâches, l'exécution et la communication comme des éléments d'un seul système. Le modèle est toujours important, mais le flux de travail environnant détermine quand il doit agir, quel contexte il reçoit et quand une personne doit intervenir.
Il s'agit d'une direction architecturale, et non d'une preuve qu'un agent peut gérer seul une organisation d'ingénierie entière en toute sécurité.
Comment fonctionne DeepSeek SuperAgent ?
Le prototype public se concentre sur un référentiel GitHub. GitHub est une source de travail ; Feishu peut éventuellement fournir un autre point d'entrée. Le projet décrit un flux dans lequel les demandes éligibles deviennent des éléments de travail, chacun géré par une session d'agent dans son propre répertoire. Un panneau Web fait apparaître un travail qui nécessite une attention humaine.
La séparation est importante lorsque plusieurs choses se produisent en même temps. Une session de routage peut gérer les activités entrantes pendant que les travailleurs se concentrent sur des tâches individuelles. La documentation d'exécution décrit également les limites de concurrence et donne au suivi ou à la demande de statut d'une personne un accès prioritaire à un emplacement supplémentaire. Il s'agit d'un moyen pratique d'empêcher un nouveau travail d'évincer un humain essayant de poursuivre une tâche existante.
Un exemple concret
Imaginez qu'un coéquipier autorisé demande à l'agent dans un problème GitHub d'enquêter sur un test ayant échoué. Le système peut ouvrir un élément de travail, préparer un répertoire de travail distinct, inspecter l'échec et proposer un correctif dans une demande d'extraction. Un commentaire de révision ultérieur peut fournir un contexte pour poursuivre le travail. La réussite dépend de l'environnement, des autorisations, de la tâche et de l'implémentation ; il s'agit d'un flux de travail illustratif, et non d'une garantie démontrée.
En quoi est-il différent d'un assistant de codage classique ?
| Question | Assistant monotâche | Prototype SuperAgent |
|---|---|---|
| Où commence le travail ? | Généralement une invite ou une tâche interactive. | Activité du référentiel connecté et demandes éligibles. |
| Comment s’organise le travail ? | Souvent autour d’une séance. | Éléments de travail avec des sessions d'exécution et des répertoires séparés. |
| Que se passe-t-il après ? | Une personne commence généralement la prochaine interaction. | Le système est conçu pour acheminer les suivis et faire rapport dans la conversation d'origine. |
| Qu’est-ce qui rend l’activité utile ? | Instructions et révision dans la tâche. | Autorisation, règles écrites, routage, panneau d'attention humaine et surveillance de l'opérateur. |
Il s’agit de grandes différences de flux de travail, et non d’un classement. D'autres agents de codage peuvent également s'exécuter de manière asynchrone, gérer les demandes d'extraction ou utiliser plusieurs sessions. Ce qui se distingue ici, c'est la combinaison particulière et l'objectif explicite de réduire l'attention qu'une équipe consacre à la gestion de l'agent.
L'autonomie commence par l'autorisation
La philosophie du projet est directe : l’agent doit agir lorsqu’une personne autorisée le lui demande, ou lorsqu’une règle écrite par l’équipe autorise le travail. Pour un travail que personne n'a explicitement demandé, la documentation indique de démarrer dans un mode qui enregistre ce que l'agent aurait fait. Cela rend visible le comportement proposé avant qu’un opérateur n’étende son autorité.
Il y a deux questions différentes ici : cet événement devrait-il devenir un travail ? et que peut faire le travailleur une fois que cela a commencé ? Une demande légitime ne rend pas chaque commande ou action externe appropriée. Les équipes doivent toujours examiner les informations d'identification, l'accès au référentiel, les limites d'exécution et les conséquences des outils qu'elles activent.
Des répertoires de travail séparés permettent d'organiser les modifications simultanées, mais un répertoire ou une arborescence de travail Git ne constitue pas à lui seul un bac à sable de sécurité. Traitez le texte du problème, les commentaires, les journaux et le contenu du référentiel comme des entrées non fiables, et conservez une étape de révision humaine pour les modifications ayant un impact réel.
Où cela pourrait-il être utile ?
- Enquête sur les problèmes : reproduire un échec signalé et préparer un diagnostic concis ou un correctif proposé.
- Suivi des demandes de tirage : répondre aux commentaires d'examen pertinents et enquêter sur les contrôles ayant échoué.
- Tâches de maintenance : gérer des mises à jour clairement définies où une équipe peut définir des critères d'acceptation et vérifier le résultat.
- Recherche sur les opérations des agents : examiner le routage, les autorisations, l'état et les résultats. le coût des interruptions sur un flux de travail plus long.
Il s'agit d'applications possibles de la conception, et non d'une affirmation selon laquelle chaque flux de travail est implémenté ou fiable dès le départ. La propre documentation du prototype doit être le point de départ pour évaluer une intégration spécifique.
Quelles sont les limites ?
Il s'agit d'un code de recherche. Les responsables mettent en garde contre les bugs et les pratiques d'ingénierie incohérentes et demandent aux utilisateurs de le réviser et de l'adapter. Les fonctionnalités décrites dans la recherche plus large ne doivent pas être supposées exister dans le prototype public.
Il a une portée définie. Le README décrit un agent de codage proactif pour un référentiel GitHub, avec une entrée Feishu facultative. Il ne doit pas être présenté comme un agent à usage général capable de gérer n'importe quel processus métier.
Une plus grande autonomie crée des coûts opérationnels. Un agent mal défini peut produire des messages bruyants, des demandes d'extraction inutiles, des modifications dangereuses ou des coûts de modèle et d'infrastructure inattendus. Les tests peuvent détecter certains échecs, mais ils ne peuvent pas établir qu'un agent a compris l'intention d'une équipe.
Les performances dépendent du contexte. L'architecture est intéressante, mais les résultats réels d'une équipe dépendent de sa base de code, de ses tâches, de son modèle, de sa configuration et de son processus de révision. Ne considérez pas une petite expérience ou une démo comme un gain de productivité garanti.
Comment l'évaluer de manière responsable
- Lisez le référentiel et le guide de configuration. Comprenez ce que le code public implémente et quels services et informations d'identification il nécessite avant d'installer quoi que ce soit.
- Choisissez un référentiel de test à faible risque. Commencez avec une petite liste blanche et des autorisations limitées, en utilisant des données non sensibles et une limite de dépenses appropriée à l'expérience.
- Définissez une tâche précise. Par exemple, demandez un diagnostic d'échec d'un test, avec une définition claire de terminé et non automatique. fusion ou déploiement.
- Examinez ses décisions et ses résultats. Inspectez la différence proposée, les résultats des tests, les messages externes et l'utilisation des ressources. Mesurez si cela permet d'économiser de l'attention et du temps.
- Développez uniquement après preuve. Ajoutez progressivement des autorisations, des sources d'événements ou des règles proactives, en fonction du comportement observé et de la tolérance de l'équipe aux erreurs.
Le projet propose un chemin de configuration assisté par agent dans son guide de configuration. Puisqu'il s'agit d'un prototype de recherche, examinez les instructions et l'environnement avant de permettre à un agent de les exécuter.
À l'intérieur de l'architecture : de l'événement au travail révisable
Un agent persistant doit faire plus que générer du code. Il doit distinguer une nouvelle tâche d'un suivi, décider à qui elle appartient, conserver suffisamment de contexte pour continuer et progresser sans bloquer les autres demandes. Le prototype public organise cela autour de sources, d'éléments de travail et de sessions d'exécution.
Les sources transforment l'activité en contexte
Une source connecte le système à un endroit où le travail se déroule. GitHub fournit une activité de référentiel ; Feishu est facultatif. Un événement entrant n'est pas automatiquement une commande. Le système doit interpréter le message dans son contexte, déterminer s'il est éligible et décider s'il appartient à un élément de travail existant ou s'il en justifie un nouveau. Cette distinction est importante lorsqu'une discussion contient une conversation ordinaire accompagnée d'une demande directe à l'agent.
Le routage sépare la coordination de la mise en œuvre
La session principale gère les décisions de routage, tandis qu'un exécuteur travaille sur un ticket individuel. Cette séparation donne au système un moyen de recevoir de nouveaux événements pendant qu'un travailleur est occupé avec du code. Un travailleur peut effectuer une enquête plus longue sans que la session de routage ait besoin de conserver l'intégralité de l'implémentation dans son propre contexte actif.
Cela ne rend pas les limites des tâches évidentes. Deux rapports peuvent décrire le même défaut, et un commentaire de révision peut modifier la portée d'une tâche. Un système utile doit attacher soigneusement le contexte associé et éviter de transformer chaque message en une tâche distincte. La qualité de ce routage mérite sa propre évaluation, ainsi que la qualité du code résultant.
L'exécution nécessite un état ainsi que des outils
Le projet prépare un répertoire pour un ticket avant le début du travail ; sa documentation donne un arbre de travail Git comme méthode de préparation typique. Un répertoire séparé permet d'éviter que des tâches simultanées n'empiètent sur les modifications non validées des autres. Il donne également à chaque tâche un emplacement pour effectuer des vérifications et préparer une branche. La préparation peut échouer, et l'échec lui-même doit être visible plutôt que traité silencieusement comme un travail terminé.
L'exécuteur peut signaler la progression ou un résultat et associer une pull request à l'élément de travail selon les règles du projet. La pull request est un transfert utile car elle donne aux réviseurs une différence concrète, des résultats de test et un endroit pour discuter des modifications. Le résultat important n’est pas simplement que l’agent était actif ; il s'agit de savoir si l'équipe peut comprendre et vérifier ce qu'elle a produit.
Décision : L'événement était-il éligible et acheminé vers la bonne tâche ?
Exécution : Le travailleur a-t-il apporté une modification appropriée et testée dans le cadre de ses autorisations ?
Transfert : Une personne peut-elle examiner le résultat et comprendre toute incertitude ou toute incertitude restante travail ?
Que devrait signifier « proactif » dans la pratique ?
La proactivité est souvent confondue avec une initiative sans restriction. Dans cette conception, un agent peut être prêt à répondre à de nouvelles informations au fil du temps, mais la décision d’agir reste limitée par les demandes et les règles écrites par l’équipe. Par exemple, une règle peut permettre à l'agent d'examiner une vérification ayant échoué sur une demande d'extraction existante créée par l'agent. La règle doit spécifier le déclencheur, les actions autorisées et le moment où l'agent doit s'arrêter et demander à une personne.
Commencez par enregistrer les actions prospectives avant de permettre une exécution autonome. Vérifiez si les actions proposées sont pertinentes, correctement définies et valent leur coût. Une règle qui capture trop d’événements peut créer du bruit même si chaque action individuelle semble raisonnable. À l’inverse, une règle trop restrictive peut passer à côté de suivis utiles. Ajustez-le à l'aide d'exemples réels plutôt que d'une vague instruction « d'être proactif ».
Une bonne escalade fait partie du système
Un agent ne doit pas deviner quand le choix modifie le comportement du produit, l'accès, les dépenses ou les données. Une escalade utile énonce la décision, explique les conséquences pratiques de chaque option et inclut les preuves déjà recueillies. Pour les détails de mise en œuvre de routine, le travailleur peut souvent procéder à un résultat révisable. L'objectif est de réserver les interruptions aux décisions qui nécessitent un propriétaire.
Un exemple concret : échec de la vérification d'une pull request
- Événement : Une vérification échoue sur une pull request associée à une tâche existante. L'événement entre via la source du référentiel.
- Contexte : le système associe l'échec à l'élément de travail concerné et donne au travailleur le résultat de la vérification et le contexte de la tâche environnante.
- Enquête : le travailleur inspecte l'échec et décide s'il provient de ses modifications, d'un test irrégulier sans rapport ou d'informations manquantes. Les journaux et les commentaires sont des données, et non une autorité pour modifier la tâche.
- Action : Si la correction est conforme aux règles de l'équipe, l'employé prépare un changement ciblé et effectue les vérifications pertinentes. Si la modification requise modifie le contrat de produit, il s'arrête pour prendre une décision.
- Transfert : le travailleur signale la modification, les contrôles réellement effectués et les problèmes non résolus dans la conversation concernée. Un réviseur reste responsable de l'acceptation de la demande d'extraction.
Cet exemple illustre une politique de fonctionnement sensée ; il ne s’agit pas de prétendre que chaque déploiement gérera automatiquement chaque étape. La configuration, les autorisations et la mise en œuvre du prototype déterminent le comportement réel.
Comment une équipe doit-elle mesurer une expérience ?
Mesurez l'ensemble du flux de travail, et pas seulement la rapidité avec laquelle un correctif apparaît. Commencez par un petit ensemble de tâches représentatives et comparez-les avec le processus normal de votre équipe. Gardez les tâches et les critères d'acceptation comparables et enregistrez les cas où l'agent a eu besoin d'une nouvelle tentative ou d'une intervention humaine.
| Mesurez | Ce que cela révèle | Question à poser |
|---|---|---|
| Délai d'obtention d'un résultat révisable | Combien de temps il faut pour produire un transfert utile. | Le résultat a-t-il été obtenu ? inclure suffisamment de contexte et de vérification ? |
| Attention humaine | Effort de révision, de clarification et de nettoyage. | L'équipe a-t-elle gagné du temps après avoir corrigé les erreurs ? |
| Exactement et remaniement | Les modifications satisfont-elles à la tâche et survivent-elles à l'examen. | À quelle fréquence les personnes ont-elles dû réviser substantiellement le document fonctionnent ? |
| Bruit et routage | Messages inutiles, tâches en double et suivis manqués. | L'agent a-t-il agi lors des bons événements ? |
| Coût et limites | Utilisation du modèle, dépenses d'infrastructure et comportement en matière d'autorisations. | Le résultat valait-il le coût et les actions sont-elles restées dans les limites ? |
Suivez les tâches ayant échoué et abandonnées ainsi que celles qui ont réussi. Un résultat rapide qui nécessite un examen approfondi peut avoir moins de valeur qu'un résultat plus lent auquel un évaluateur peut se fier. Enregistrez la taille de l'échantillon et la composition des tâches avant de tirer des conclusions.
DeepSeek Harness, le modèle et SuperAgent
Ces noms décrivent différentes couches. Le modèle génère et raisonne à partir d'informations ; DeepSeek Harness fournit un environnement d'agent avec des outils et des sessions ; dsh-superagent ajoute un workflow pour recevoir et coordonner le travail du référentiel. Remplacer ou améliorer une couche ne résout pas automatiquement les problèmes des autres. Un modèle plus puissant peut toujours être acheminé vers la mauvaise tâche, recevoir des autorisations excessives ou produire une modification qui nécessite un examen.
Pour les développeurs explorant les workflows de codage basés sur DeepSeek, les limites d'accès et d'utilisation doivent être évaluées séparément de ce prototype de recherche. Les plans de codage disponibles s'appuient sur un inventaire et leurs conditions sont indiquées sur la page de tarification.
Consultez les options disponibles et leurs conditions actuelles avant de choisir un plan.
Afficher les prix →Foire aux questions
Le DeepSeek SuperAgent est-il un nouveau Modèle d'IA ?
Non. Le projet public est un système d'agent de codage conditionné pour DeepSeek Harness. Un modèle fournit le raisonnement et la génération, tandis que le système environnant gère les tâches, les outils, les autorisations et la communication.
Est-il open source ?
Oui. Le référentiel public est disponible sous la licence MIT. Vérifiez le référentiel pour connaître les termes de la licence et toute modification apportée au projet.
Est-il prêt pour la production ?
Le référentiel indique qu'il n'est pas prêt pour la production. Les équipes doivent le traiter comme du code de recherche, l'inspecter et l'évaluer dans un environnement contrôlé avant d'envisager une utilisation plus large.
Peut-il fonctionner sans supervision humaine ?
La conception vise à réduire les interruptions de routine, mais elle dépend toujours de l'autorisation explicite, de la configuration de l'opérateur et du jugement humain. Réduire les interruptions n'est pas la même chose qu'éliminer la responsabilité.