Explorer le design du Super-agent : vers un système d'agents plus autonome

1. Super-agent

Sur l'année écoulée, les agents à tâche unique — les coding agents en tête — ont prouvé que les modèles savent utiliser des outils pour résoudre des problèmes complexes, avec de moins en moins de surveillance humaine continue et d'intervention pas à pas. En parallèle, la capacité à coordonner plusieurs agents progresse, rendant envisageables l'organisation et la répartition entre sessions. À mesure que la participation humaine à l'exécution diminue, le rôle de la personne remonte vers les décisions et la validation de plus haut niveau.

Ce gain de capacité a engendré de nouvelles formes d'usage. Récemment, les agents personnels ont éclos en nombre : branchés en direct sur la messagerie, l'agenda, le courriel et les plateformes de travail, ils observent le flux d'informations et aident à traiter les affaires. Ce mode de travail en ligne permanent et piloté par les événements ne se limite pas au scénario personnel — l'assistant personnel n'est qu'une classe d'application ; dans des scénarios commerciaux comme le développement logiciel, il vaut tout autant.

Les designs dominants peinent pourtant à porter ce mode à l'échelle du multitâche et de la collaboration d'équipe. Le travail des agents reste organisé autour de la session unique ; les sessions sont indépendantes entre elles. Qui mène plusieurs fronts en parallèle doit basculer à la main et retenir le contexte de chacune — et l'équipe observe qu'une personne suit en pratique 3 à 5 sessions actives. Dans ce design, le plafond de la tâche unique tient à la capacité du modèle ; le plafond du multitâche tient à l'attention humaine.

Étendre un agent local mono-session par CLI, MCP ou connecteurs externes lui fait bien recevoir des messages, mais il reste enchaîné au blocage synchrone de l'unique session, au contexte multitâche embrouillé et à l'arrêt dès que la machine se déconnecte — avec beaucoup d'entretien manuel.

Pour franchir ces limites, il faut délier l'agent de la session manuelle unique et en faire une entité continue qui garde son contexte d'une session à l'autre et mène plusieurs tâches complexes en parallèle sans interférence. L'équipe nomme cette forme d'agent — et son architecture — Super-agent.

Sur l'instance interne propulsée par DeepSeek Harness, une même tâche de développement avance sans rupture entre la messagerie et GitHub ; l'instance surveille aussi les retours des groupes publics et, sans être mentionnée, localise la cause racine et dépose une pull request de correctif.

Concrètement, le Super-agent a quatre propriétés fondatrices :

• Continu : l'utilisateur interagit dans ses surfaces habituelles — chats, commentaires GitHub — et sent un agent unique toujours présent, sans se demander « l'information Y était-elle dans le contexte de la session X ? ». Il peut proposer le plan A en messagerie puis passer au plan B dans un commentaire de PR : l'agent comprend et s'ajuste.
• Efficace : interactions réactives pendant que plusieurs tâches complexes avancent en parallèle avec qualité ; l'instruction suivante est acceptée sans attendre la fin de la précédente.
• Proactif : pas d'attente d'instructions au compte-goutte ; l'agent observe en continu les événements de l'environnement et fait avancer ce qui le mérite, silencieux quand aucune intervention n'est requise.
• Persistant : toujours en ligne, branché sur les vrais environnements de travail, auto-récupéré des anomalies en exécution longue.

Une seule boucle ReAct ne soutient pas les quatre propriétés à la fois ; il faut une architecture en dessous. Des contraintes semblables mènent à des choix semblables : assistant personnel ou agent commercial de développement, un système en ligne permanent et concurrent sur les événements convergera vers des fondations proches. Et beaucoup de problèmes ici ressemblent fort aux classiques des systèmes distribués : la pensée systémique classique s'applique telle quelle.

L'implémentation a des variantes, mais cinq modules forment l'ossature : l'architecture à deux niveaux (§2) pour continuité et efficacité ; le pilotage événementiel (§3) pour la proactivité ; l'interaction orientée humain (§4) continue et efficace dans l'interface même ; la séparation calcul/état/environnement (§5) et un Watchdog (§6) pour la persistance multi-appareils et l'auto-guérison.

2. L'architecture à deux niveaux

Pour obtenir ensemble l'interaction continue multi-canal et la concurrence multitâche efficace, l'organisation des sessions affronte un arbitrage fondamental entre continuité et débit.

Tout confier à une session : contexte au plus continu, mais la vitesse série de la boucle ReAct plafonne — temps longs, débit faible, et les détails intermédiaires des tâches mêlés dégradent la qualité.

Une session neuve par événement : débit concurrent maximal, mais hors tâches totalement indépendantes, l'absence de contexte global fragmente les résultats, et plusieurs sessions répondant chacune de son côté sèment le chaos.

Pour équilibrer, on scinde « maintenir la continuité globale » et « exécuter en haute concurrence » sur deux niveaux : un niveau Router résident (2.1) qui reçoit toute l'interaction humaine et la coordination globale, et un niveau Worker à contexte isolé (2.2) qui exécute les tâches en concurrence.

Avec cette séparation, le système prend en charge en bas la gestion du contexte et de la concurrence, estompant la session pour l'utilisateur, qui n'a devant lui qu'un seul Super-agent. Vu ainsi, faire gérer les sessions à la main relève largement de l'inertie héritée des API de LLM ; la session est un détail d'implémentation, pas un fardeau cognitif.

« Deux niveaux » est un découpage logique de responsabilités ; aucun niveau ne se réduit à une session unique et chacun peut avoir sa structure interne. Suivent les deux niveaux.

2.1 Le niveau Router

Le Router est le niveau de routage global résident qui reçoit toute interaction humaine de tous les points d'entrée. Toutes les informations et décisions inter-tâches y convergent : point de séquence global, point de coordination et mémoire. Pour ne pas devenir le goulot, le Router n'exécute pas — seulement interaction et répartition ; il peut même aller sans outil Bash.

Un répartiteur central au-dessus d'exécutants ressemble en surface à un Agent Team, mais l'accent diffère. L'Agent Team décompose les étapes d'une tâche complexe ; les sous-étapes sont couplées, le lead doit comprendre le détail, planifier, coordonner sans relâche — lourde charge de raisonnement. Dans le Super-agent, le Router ne traite que les liens de haut niveau entre tâches et la répartition. Inversement, contraindre par prompt la session principale d'un Agent Team à ne jamais exécuter elle-même — seulement interface externe et distribution — en fait aussi cette architecture. En pratique, les tâches du Router sont souvent moins complexes que prévu, et un modèle léger équilibre vitesse et qualité.

En interne non plus, le Router n'est pas tenu à une session unique ; des pans de logique peuvent se passer de LLM. L'équipe a choisi le noyau le plus direct — une session LLM résidente — et a constaté qu'elle se goulotte bien moins qu'il n'y paraît : les événements (les Triggers de la §3) arrivés pendant un tour d'inférence s'accumulent et se traitent ensemble au tour suivant, formant le batching, au surcoût faible :

• Flux d'événements calme : les Triggers entrent un à un, la latence unitaire reste basse.
• Afflux dense et file d'attente : les Triggers accumulés fusionnent d'eux-mêmes et sont injectés ensemble à l'appel suivant. Les pas du Router sont typiquement entrée longue, sortie courte ; fusionner les Triggers en un appel parallélise le préfill, et la latence par requête croît bien plus lentement que la taille de lot. Dans une certaine plage, plus d'arriéré, moins de temps d'inférence par décision — borné par la longueur de contexte et le nombre de Triggers traités avec exactitude en un tour.

La §7.2 quantifie ce batching. Avec l'abonnement/pass-through et la chaîne de rappel (3.2, 3.3), une session Router résidente unique suffit à l'échelle actuelle de l'équipe.

Au-delà, le Router peut se structurer en filtres multi-étages ou se sharder horizontalement en plusieurs sessions. Le design interne du Router devient lui-même l'arbitrage continuité/débit : shards plus fins, plus de concurrence, moins de continuité de mémoire entre fragments. Tant que la mémoire globale n'est pas résolue, l'arbitrage demeure.

2.2 Le niveau Worker

Les Workers sont les sessions d'exécution : contexte mutuellement isolé, outillage complet, concentration sur une tâche unique. Parce qu'ils déterminent résultats et qualité du code, les Workers veulent le modèle le plus fort.

Les Workers ne parlent pas aux humains ; raisonnements et appels d'outils ne sortent pas sur les canaux externes. Ils rendent compte au Router, qui répond à l'utilisateur pour tous — concurrence et qualité sans chaos de réponses multiples.

En multitâche, les Workers avancent indépendamment et ne communiquent généralement pas entre pairs. Les conflits naissent surtout en environnement partagé, la même PR par exemple ; dès lors que les deux souscrivent au même Thread (3.2), ils reçoivent les mêmes événements et peuvent découvrir et dénouer le conflit eux-mêmes, le Router relayant les rares coordinations inter-tâches.

Comme le Router, un Worker peut n'être pas une session unique à l'intérieur : sur une tâche complexe il peut engendrer des subagents ou être lui-même un Agent Team, en transparence pour le Router. Cela vaut pour la collaboration de code — reproductions, revues et fonctionnalités en parallèle sans blocage — comme pour l'assistant personnel : une seule fenêtre de chat en surface, dessous un Worker par sujet, avançant en parallèle et rédigeant les réponses.

3. Piloté par les événements

La proactivité commence par changer ce qui conduit le système. L'entrée principale n'est plus les prompts tapés par l'humain en session, mais des événements semi-structurés de l'environnement. Messages de groupe, rappels d'agenda et de courriel, commentaires de revue, résultats de CI : autant de Triggers. En écoutant et répondant aux Triggers, l'agent n'exécute plus une fois par commande comme en mono-session.

Autour du cycle de vie d'un événement, quatre questions progressives : filtrer le bruit par une politique à deux niveaux programme+modèle (3.1) ; router vers les workers par abonnement et pass-through (3.2) ; injecter et rappeler le contexte en haute densité avec Inline & Spill et la chaîne de rappel (3.3) ; agir en avance par exécution spéculative (3.4).

3.1 Filtrage des événements

Branchés sur de vraies conversations et plateformes de code, les flux d'événements sont spectaculairement « bruit fort, taux de déclenchement faible » : l'immense majorité des messages n'exige pas l'agent. Juger chaque événement par appel modèle neuf ruine latence et coût. Empruntant le Fast Path / Slow Path des systèmes, l'inférence LLM est une Slow Path souple mais coûteuse ; figer en code déterministe les jugements clairs, stables et fréquents constitue une Fast Path bon marché.

Première étape après entrée : le filtrage — écrémer le bruit par politique déterministe avant tout appel au modèle, ne lui passer que les candidats exigeant de la sémantique. Filtre à deux niveaux :

• Niveau programme (Fast Path) : contrôles d'admission déterministes en code — source, périmètre de groupe, listes blanches d'utilisateurs/bots ; par source par exemple « répondre aux seules demandes explicites », « candidat » ou « ignorer » — l'essentiel du non pertinent part avant le modèle.
• Niveau sémantique (Slow Path) : les candidats passés vont au LLM, qui décide d'agir ou non selon les politiques écrites en prompt et le contexte. Ce niveau est aussi le point d'extension en langage naturel : activer ou ajouter une politique est une modification de prompt.

3.2 Routage des événements

Le Router maintient la continuité multi-canal, mais si chaque événement suivant d'une tâche déjà assignée repassait par lui, le nœud global chargerait lourd et la latence grimperait. Fast/Slow vaut donc aussi pour le routage : le Router ne gère que le démarrage à froid des nouvelles tâches et la coordination inter-tâches ; les événements suivants d'appartenance connue partent par code directement vers la session worker.

Dans les workflows réels, les événements consécutifs sous une même PR, un même sujet de messagerie ou un même fil de courriel forment un flux — un Thread. Le Router ayant créé une session worker pour l'événement initial d'un Thread, le worker souscrit directement au Thread, et le routage se dédouble :

• Souscrit (Fast Path) : les événements suivants du même Thread vont tout droit au worker abonné, sans retransmission par le Router. Si un événement excède le périmètre de la tâche, le worker peut se désabonner ou rendre la main.
• Non souscrit (Slow Path) : le Router observe tout pour la vision globale, mais ne juge et ne distribue que ce qui n'est pas encore souscrit.

L'abonnement Thread-worker est plusieurs-à-plusieurs : un worker suit plusieurs Threads liés, un Thread est suivi par plusieurs workers. Quand des workers se croisent dans un même environnement, les nouveaux événements parviennent à tous les abonnés, qui connaissent les actions d'autrui et dénouent les conflits sans messages point à point. En sortie, les workers remontent les conclusions clés au Router, qui répond à l'utilisateur et met à jour la mémoire globale.

3.3 Organisation du contexte

Événement filtré et routé, reste à savoir combien injecter dans la fenêtre. L'entrée est passée de prompts humains bornés à un flux continu d'événements semi-structurés : la structure d'injection et d'appels d'outils compte davantage. Trop remplit la fenêtre et dilue l'attention ; trop peu multiplie les allers-retours de lecture. Gâcher la fenêtre de contexte, c'est gâcher l'intelligence du modèle.

Gérons la fenêtre finie comme un cache. De l'optimisation de compilateurs et des systèmes, deux opérations suffisent : Inline porte en fenêtre ce qui servira bientôt, épargnant les allers-retours d'outils ; Spill laisse hors fenêtre l'information complète hors budget ou rarement utilisée, ne gardant dedans qu'une référence ou un résumé à lire à la demande.

Avec la localité classique :

1. Partir du minimum : identifiant de l'objet et condensé du contenu.
2. Inliner par localité : d'abord les identifiants des objets étroitement liés, puis les contenus voisins dans le temps et l'espace — les premiers 50 caractères, les messages adjacents et celui auquel on répond, les commentaires voisins du fil de revue.
3. Spiller au-delà du plafond : petit plafond de longueur pour ce qui ne se inline pas en entier ; l'excédent sort avec une reprise de lecture que le modèle lira par outil au besoin.

Avec les nombreux événements passés directement aux workers et l'historique qui s'accumule au fil du temps, le Router ne peut garder en fenêtre l'histoire entière de chaque tâche, mais doit retrouver le contexte quand l'utilisateur ressaisit une vieille tâche sur un autre canal. Appliquer Inline & Spill uniformément aux objets du système donne le rappel multi-sauts à la demande — la chaîne de rappel — qui atténue la perte d'informations lointaines du Router.

Concrètement : Triggers, Threads et sessions workers reçoivent des identifiants uniques, et les injections incluent ceux des objets étroitement liés, formant en dessous un graphe de références. Chaque objet rappelé par outil suit lui-même Inline & Spill, donc son résultat inclut résumé et identifiant du saut suivant : du message courant on lit le Thread, du Thread on remonte à la session worker liée, et de là à l'autre Thread de revue.

3.4 Agir en avance

Avec l'exécution spéculative des systèmes, l'agent peut tenter en arrière-plan avant de savoir si le résultat servira : du calcul d'appoint en arrière-plan contre l'attente et l'intervention humaines. Utile, on livre ; inutile, on jette.

Assistant personnel : à l'invitation ou au pense-bête, l'agent vérifie en arrière-plan les conflits d'agenda, rassemble les éléments et prépare le brouillon de réponse — l'utilisateur survole et envoie. Ingénierie : dans le groupe interne d'utilisateurs de DeepSeek Harness court la politique « reproduire et corriger en silence » — dès qu'on signale un problème ou discute d'un changement, l'agent reproduit et cherche le correctif en arrière-plan ; il ne livre que problème confirmé et correctif simple, sinon il se tait de bout en bout.

4. Interaction tournée vers l'humain

Le deux-niveaux assure la continuité au niveau du contexte ; pour l'être aussi dans l'expérience vécue, deux problèmes restent : lever le blocage des opérations longues via une boucle ReAct asynchrone (4.1), et adapter la sortie à la bande passante et aux habitudes de chaque canal (4.2).

4.1 Interaction full-duplex

Dans la boucle ReAct classique, un appel d'outil synchrone run() bloque jusqu'au retour du résultat, et la session ne répond à rien de neuf pendant ce temps. Lever le blocage, c'est passer du half-duplex question-réponse au full duplex.

L'équipe a rendu asynchrones les commandes et sous-tâches longues via start() et stop() — la boucle ReAct asynchrone. start() rend aussitôt « Started » et la boucle n'attend plus ; l'outil fini, le système dépose le résultat en session comme nouvel événement ; et le modèle peut stop() une commande qui s'éternise.

Dialogue au premier plan et exécution en arrière-plan se découplent : l'agent répond pendant que tournent les tâches longues. La nouvelle entrée est traitée juste après le pas d'inférence courant, jamais derrière un outil en attente. Le mécanisme est dans DeepSeek Harness, non activé par défaut.

4.2 Interaction multi-canal

Les canaux diffèrent en densité et en habitudes ; la sortie doit s'y conformer. Transplanter tel quel l'interaction mono-terminal dans un groupe — raisonnements verbeux et salves d'appels d'outils en flux brut — noie la collaboration.

Le deux-niveaux isole déjà l'essentiel : raisonnements et appels restent dans les workers ; seul le Router parle dehors. Par-dessus, le système se branche sur les environnements réels et règle par prompt les normes par canal :

• Messageries instantanées : échanges légers, peu intrusifs — comme un collègue qui ne prévient que pour décider ou valider, questionne direct, répond court. Règle dure simple et validée : jamais plus de 100 mots par réponse.
• GitHub, courriel, documents (canaux asynchrones) : livraisons structurées, denses — PR rédigées aux normes du projet avec contexte, description et vérification ; pour l'assistant, brouillons de courriels et résumés structurés.

5. Séparer calcul, état et environnement

Les agents locaux lient par défaut au même appareil le calcul qui pousse la boucle, l'état de session à persister, et l'environnement d'exécution — dépôts et chaînes d'outils. L'appareil s'endort ou se coupe, l'agent s'arrête, et les environnements des autres machines restent inaccessibles. Pour la présence permanente et l'accès souple aux vrais environnements, on emprunte la séparation calcul-stockage en deux temps : d'abord délier le calcul de boucle de l'état persistant, affranchissant l'agent du cycle de vie de la machine unique (5.1) ; puis délier la boucle nuagée de l'environnement lourd, laissant les environnements réels sur place avec accès multi-appareils (5.2).

5.1 Calcul et état

Le calcul de boucle peut être sans état ; ce qui persiste, c'est l'état de session. Première séparation : le calcul en conteneurs élastiques nuagiques sans état, les sessions en base. Les conteneurs montent, redémarrent, se remplacent ; le stockage persistant garantit la continuité — l'agent échappe au cycle de vie d'une machine.

5.2 Calcul et environnement d'exécution

Boucle et état installés au nuage, reste l'accès aux environnements. Une grande partie du contexte nécessaire au modèle arrive par outils depuis dépôts, fichiers locaux et services — au sens large, l'environnement même est contexte.

Deux voies habituelles : sandbox nuagique qui tire le code et tente de reconstruire l'environnement — coûteux et fuyard, car les vrais environnements portent modifications non commitées, identifiants privés, dépendances intranet, matériel ou chaînes d'outils spécifiques ; ou demander à l'utilisateur d'abandonner le local pour le nuage — migration trop chère pour beaucoup.

Puisque c'est l'environnement qu'on ne peut copier, ne le montons pas au nuage. Seconde séparation : la boucle tourne au nuage, l'environnement lourd reste où il est, et sur l'appareil ne vit qu'un daemon léger, sans état de session, qui exécute des commandes et rend des résultats — l'environnement hors du nuage, lu par l'agent à la demande.

Cela rejoint le « découpler le cerveau des mains » d'Anthropic : harness sans état, journaux de session au-dehors, environnements rattachés par interface unifiée. La différence est le scénario — ce texte décrit des services gérés, sandbox à la demande et ressources dans le VPC client ; ici, on raccorde d'abord les machines personnelles du quotidien, parfois en ligne par intermittence, avec modifications non commitées et identifiants locaux. D'où le soutien au BYOM (Bring Your Own Machine), à côté des machines gérées et du calcul à la demande.

L'agent n'est plus rivé à une machine : il choisit son appareil d'exécution selon la tâche, commande là où il faut et y puise le contexte. Il soutient même les appareils intermittents : la machine personnelle revient en ligne, l'agent nuagé déclenche et achève ce qui devait y tourner.

6. Watchdog

À la séparation s'ajoute la guérison : un système longue durée ne tient pas sur sa seule logique interne ; il lui faut une boucle de contrôle externe — le Control Loop.

Et pour les systèmes d'agents, sondes de process et scripts de supervision ne suffisent pas : nombre d'anomalies ne sont pas des crashs mais des boucles stériles ou des dérives du modèle. Un agent longue durée surveille la vie de l'infrastructure et la progression des tâches.

Hors du système principal vit une Watchdog Session indépendante, pilotée par messages horlogés. Elle traite les pannes d'infrastructure — erreurs d'API, récupérations ratées — et fait juger par le modèle chaque worker sur ses progrès réels et son cap par rapport à l'objectif ; elle intervient et répare, et réexamine les pannes passagères jusqu'au rétablissement. Étant elle-même une session d'agent outillée, on peut l'interroger en langue naturelle sur une panne ou lui faire retoucher le système en ligne — prompts ajoutés ou retirés, règles de déclenchement ajustées.

7. Expériences préliminaires

Pour évaluer la conception de l'ordonnancement et du routage, deux plans d'expériences : bout en bout, le deux-niveaux avec abonnement/pass-through contre les schémas mono-session (7.1) ; puis un stress isolé du batching du Router (7.2). Charges synthétiques, environnements simplifiés : résultats préliminaires.

7.1 Ablation

Des flux de discussions et de CI GitHub conduisent quatre schémas : ~300 messages par essai, dont ~20 requêtes de travail, le reste bavardage, relances, annulations et CI. Le travail de codage est remplacé par un outil qui ne consomme que du temps : on mesure l'ordonnancement et la coordination, non l'exécution d'une tâche. Cinq essais par schéma.

Les quatre : le Super-agent ; le Super-agent sans pass-through ; et la session unique + outil subagent sous deux prompts. Neutre : "Use a subagent for a piece of work when appropriate...". Délégation d'abord : "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..."

Temps d'achèvement : p50 et p95 du Super-agent à 12,4 et 15,7 minutes, nettement devant la session unique à subagent. Celle-ci est très sensible au prompt : la session principale exécute souvent elle-même — temps longs, instables. Prompt neutre : aucun appel au subagent en cinq essais ; tout dans la principale, haché par les messages, p95 à 29,5 minutes. Délégation d'abord : délègue quatre fois sur cinq — mieux, encore devant le Super-agent — et à la cinquième juge le travail « petit », l'exécute, d'où la longue traîne violette. Plutôt que de laisser prompt engineering et jugement à la volée décider de diviser ou non, le deux-niveaux tranche structurellement : le Router n'exécute pas ; les workers ne reçoivent que les messages du Thread souscrit.

Coûts : tenir plusieurs sessions fait monter les tokens de lecture cache par essai au-dessus de la session unique — plus de tokens contre des temps plus courts et plus stables. Sans le pass-through, les temps restent quasi identiques, mais les décisions du Router grimpent d'environ 30 % et les tokens lus en cache passent de 23,23 M à 31,77 M (+37 %). Sous cette charge, le pass-through n'améliore ni qualité ni vitesse : il épargne au Router des tokens et de l'inférence substantiels.

7.2 Batching du Router

Pour sonder le plafond de la session Router résidente, un stress dédié : vrai modèle côté Router, mock côté workers, le débit de Triggers à décider monté de ~1 à ~40 par minute, en observant lot moyen, latence par requête et inférence par décision.

De ~1 à ~40 par minute, le lot moyen passe de 1,0 à 2,8 tandis que la latence ne grimpe que de 2,5 s à 3,9 s — plus lentement que le lot —, et l'inférence par décision descend de 6,4 s à 1,6 s. Sous afflux, le Router hausse son débit effectif en fusionnant l'arriéré. Cela explique qu'en 7.1, sans pass-through et malgré le pic de charge sur le Router, le plafond n'ait jamais été touché — d'où l'absence de sharding prématuré qui sacrifierait la continuité du contexte global.

8. Questions ouvertes

Les §2–6 composent l'ossature ; la §7 a validé ordonnancement et routage sous charge. Le système reste simple grâce à des simplifications délibérées. Au-delà restent ouvertes : faire grandir le deux-niveaux (8.1), collaborer après les sessions (8.2), frontières de contexte et A2A (8.3), sécurité et vie privée (8.4).

8.1 Faire grandir le deux-niveaux

« Un Router résident + pass-through + pas de communication directe entre workers » couvre l'essentiel du quotidien à faible coût. Au-delà du seuil, pas de doctrine : quand sharder, à quelle granularité ; quand introduire la communication directe entre workers, sous quelle topologie. Le co-design système-modèle mérite exploration : entraîner spécifiquement la discrimination d'événements, la répartition en lot et le rappel de contexte du Router pourrait accroître débit et qualité de décision.

Et le Router résident avec chaîne de rappel sur graphe de références résout surtout le rappel du proche. Sur des mois et plus, la mémoire longue devient le goulot de l'extensibilité.

8.2 Collaborer après les sessions

La gestion multi-sessions cachée, la session cesse d'être la question produit première ; mais quand les sessions d'exécution ne correspondent plus aux conversations visibles, présenter les tâches et offrir interaction et gestion naturelles devient la nouvelle question. La centralité de la fenêtre de chat tient en partie de la dépendance au chemin. L'interaction peut migrer vers des surfaces spécialisées — comme dans les exemples du texte, le Super-agent travaillant dans les issues et pull requests. La session peut rester pour l'habitude, mais une conversation vue ne vaut pas une session en dessous.

Le texte a traité l'humain au départ et à la réception ; en transition, bien des tâches veulent une participation à mi-course — entrer, reprendre, coopérer en direct pendant l'exécution en arrière-plan : à explorer. La forme finale d'interaction et de gestion sera sans doute très personnalisée au domaine et au style ; l'architecture ouverte de DeepSeek Harness la sert aisément.

8.3 Frontières de contexte et A2A

Le texte a traité une instance, supposant tout son périmètre fondu dans un contexte global. De l'individu à l'organisation, décider du nombre d'instances revient à tracer les frontières de partage et d'isolement du contexte : qui partage, partage l'instance ; qui isole, a la sienne.

Et avec plusieurs instances isolées — les assistants personnels et le Super-agent d'équipe — la coopération transfrontalière devient de la communication agent-à-agent (A2A, sans protocole précis). Une A2A sûre et fiable entre parties sans contexte commun et aux permissions distinctes demeure à explorer.

8.4 Sécurité et vie privée

L'événementiel expose l'agent à des entrées non fiables. Sans bonnes réponses, le Super-agent ne vit que dans un périmètre restreint et de confiance.

La §5 — boucle au nuage, daemons légers sur les appareils — suppose une confiance mutuelle. Mais une boucle qui avale des événements externes, adossée à des machines portant code privé, données sensibles et identifiants locaux, introduit des risques réels : compromission serveur ou injection de prompt dans la boucle, et c'est le contrôle de tous les appareils raccordés qui est en jeu.

Et même sans compromission, si des identifiants entrent au contexte du modèle, la fuite guette en cours d'exploitation normale ; il faut des mécanismes pour utiliser des identifiants sans jamais les toucher. Pour l'adoption large, l'architecture doit rappeler le contexte d'environnements divers et résoudre ensemble ces problèmes.

9. Conclusion

En relisant l'ensemble, l'équipe n'a pas produit de théorie neuve : elle a appliqué l'ingénierie systémique classique aux agents. Les implémentations évolueront ; la pensée de design conservera sa valeur de référence. L'instance interne bâtie sur ces idées et DeepSeek Harness tourne toujours, participant chaque jour à la reproduction et au correctif, à la réponse aux revues et à l'itération de Harness lui-même.

Comme en ouverture : à mesure que le modèle réclame moins d'intervention par tâche, le goulot de la productivité se déplace vers l'attention humaine. Par le deux-niveaux, l'événementiel, l'interaction asynchrone multi-canal, la séparation calcul-stockage et le Watchdog externe, le système prend en bas la gestion des sessions et la synchronisation des contextes, et l'humain monte vers décision et validation.

Sous cette forme, l'agent n'est plus la fenêtre qui attend des instructions, mais un collaborateur autonome en ligne permanente dans l'environnement numérique : pour l'individu, un assistant inter-appareils ; pour l'équipe, un participant inscrit au flux de développement qui prend et porte des tâches concrètes. À mesure que capacité des modèles et architecture progressent ensemble, ce mode plus autonome pourrait devenir la norme de la collaboration homme-machine.

Comme l'original : une partie du design vit dans dsh-superagent-prototype ; le plugin est un prototype de validation de trajectoire, pas un produit officiel DeepSeek. Auteur et remerciements : le texte naît de la pratique partagée de l'équipe DeepSeek Harness ; Yujia Qiao a réalisé le système et le texte, avec Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, Hanxiang Xu, C.C. Yu, Ziya Zhang et F. Zhou en relecture et discussion.

Sources

• DeepSeek 产品部 (WeChat officiel) — le texte original chinois, 1ᵉʳ nov. 2026
• deepseek-ai/dsh-superagent-prototype — le prototype sous MIT (README, docs 000–008)
• Renvois internes : traduction anglaise intégrale · original chinois · couverture dsh-superagent