Subagents (Sous-agents et délégation)

1. Vue d'ensemble du concept et problème systémique

Dans les tâches de développement complexes, une part significative du temps est consacrée au travail exploratoire « sale » : recherche par mots-clés dans des centaines de fichiers, lecture de documentation, examen des logs système ou vérification de dizaines de dépendances.

Si toutes ces opérations sont exécutées par un seul agent principal au sein d'un unique dialogue :

1. Pollution catastrophique du contexte (Context Pollution) : Des milliers de lignes de code brut et de logs évincent les instructions système initiales de l'utilisateur.
2. Dégradation de l'attention (Lost-in-the-Middle) : L'agent commence à se perdre dans ses propres brouillons intermédiaires, perdant la finalité première.
3. Goulot d'étranglement séquentiel (Sequential Bottleneck) : L'agent est contraint d'examiner chaque source l'une après l'autre, gaspillant des minutes là où le parallélisme permettrait de gagner des secondes.

Le pattern des Subagents introduit le principe d'isolation du contexte d'exécution : l'agent parent spawn des exécuteurs enfants distincts avec une fenêtre d'attention vierge, leur délègue les tâches routinières et ne récupère que des conclusions raffinées et structurées.

2. Taxonomie architecturale et modèle mental

Selon l'organisation du travail des subagents, on distingue trois topologies principales :

• 1. Fork-Join (Pattern Map-Reduce) : L'agent parent divise une grande tâche en $N$ parties indépendantes (par exemple, l'analyse de 4 microservices distincts), lance simultanément 4 subagents parallèles (Fork), attend leur achèvement et fusionne les résultats en un rapport unique (Join).
• 2. Transient Deep-Dive Worker (Explorateur jetable) : Un subagent est généré pour une opération spécifique unique : par exemple, accéder au site de documentation, s'authentifier, trouver un exemple d'utilisation d'un endpoint et retourner uniquement 5 lignes de code. Le conteneur du subagent est ensuite supprimé.
• 3. Arborescence hiérarchique à profondeur bornée (Bounded Delegation Tree) : Le processus parent gère les subagents de premier niveau, qui peuvent, si nécessaire, spawn des workers de second niveau. Pour éviter une consommation incontrôlée des ressources, la profondeur de récursion est strictement limitée (max_depth = 2).

3. Pipeline technique et mécanique interne

Cycle de vie d'un subagent :

1. Delegation Call (Initiation de la délégation) : L'agent principal appelle un outil de lancement spécifique : invoke_subagent(task_name="grep_auth_logs", prompt="...", tools=["grep", "cat"]).
2. Context Sandbox Isolation (Création d'un thread isolé) : Le runtime démarre une nouvelle session LLM avec un contexte vierge. On y injecte uniquement l'instruction pour la sous-tâche et une liste restreinte d'outils autorisés.
3. Autonomous Execution (Boucle interne autonome) : Le subagent exécute son propre cycle ReAct, commet des erreurs, teste des hypothèses et forme le résultat final sans perturber l'agent parent avec des messages intermédiaires.
4. Synthesis & Garbage Collection (Agrégation et retour) : Le log brut du dialogue du subagent est archivé ou détruit. L'agent principal reçoit un message de l'outil contenant un résumé concis (par exemple : « Trouvé 2 fuites mémoire dans le fichier worker.ts : lignes 14 et 89 »).

4. Scénarios d'ingénierie pratiques en production

01. Audit de sécurité parallèle d'un grand monorepo

L'architecte principal spawn trois subagents simultanément :

• Worker 1 : scanne le backend pour détecter les injections SQL et les requêtes brutes non sécurisées.
• Worker 2 : vérifie le frontend pour les vulnérabilités XSS et les appels dangereux à dangerouslySetInnerHTML.
• Worker 3 : analyse les fichiers de configuration Docker et CI/CD pour repérer les ports ouverts et les images non durcies. Chaque subagent lit des centaines de fichiers, mais l'architecte principal reçoit un tableau récapitulatif compact avec trois points critiques.

02. Analyse en arrière-plan de logs serveur massifs

Au lieu de transmettre 50 mégaoctets de logs Nginx dans le contexte principal, on lance un subagent analyste. Il filtre localement les logs via grep/awk, identifie une anomalie soudaine de codes statut 500 et ne retourne à l'agent principal que la stack trace mise en évidence.

03. Exploration de bibliothèques externes sans perte de focus

Pendant que l'agent de code conçoit l'architecture du service, il envoie un subagent lire la documentation officielle de l'API Stripe. Le subagent maîtrise la syntaxe des checkouts et retourne un exemple de code minimal prêt à l'emploi.

5. Pièges, erreurs courantes et sécurité

• Tempête de tokens et Rate Limits (TPM Spikes) : Le lancement de 10 subagents simultanés crée un pic massif de requêtes vers le fournisseur, entraînant des erreurs en cascade 429 Too Many Requests. Utilisez toujours des files d'attente de tâches avec limitation du pool (par exemple, maximum 3 workers concurrents).
• Conflits d'écriture parallèle (Race Conditions) : Si deux subagents tentent simultanément de modifier le même fichier dans le repository, cela entraînera une écrasement ou une corruption du code. Accordez aux subagents de recherche des droits strictement Read-Only.
• Récursion infinie de délégation (Fork Bomb) : Un subagent juge la tâche trop complexe et spawn 5 autres subagents, chacun faisant de même. Interdisez toujours aux agents enfants l'appel à l'outil invoke_subagent.