Accueil / Étendre : compétences, MCP, sous-agents, hooks, plugins

Sous-agents : déléguer dans un contexte isolé

Un sous-agent traite une tâche dans une fenêtre de contexte isolée et n'en renvoie que la conclusion, ce qui garde la conversation principale propre et permet d'en lancer plusieurs en parallèle.

Un sous-agent exécute une tâche dans sa propre fenêtre de contexte, séparée de la conversation principale. Quand il termine, seule sa conclusion revient dans le fil que vous suivez : les fichiers qu'il a lus, les journaux qu'il a parcourus et les impasses qu'il a explorées restent dans son contexte à lui, jamais dans le vôtre. C'est ce qui permet de déléguer une recherche volumineuse sans noyer la conversation principale sous des résultats que vous ne reconsulterez plus.

Ce qui charge au démarrage, et ce qui n'y arrive pas

Un sous-agent standard ne repart pas de rien : il reçoit son propre prompt système, distinct de celui de Claude Code, le message de délégation que vous avez écrit, la hiérarchie complète des fichiers CLAUDE.md du dépôt et un instantané du statut git pris au début de la session principale, sauf pour les agents Explore et Plan qui en sont privés, le contenu intégral de chaque skill nommée dans son champ skills, et la liste des agents frères lancés dans le même lot. Trois choses en revanche ne l'atteignent pas : le style de sortie choisi pour la session principale, la mémoire automatique, et la taille de la fenêtre de contexte de la conversation qui l'a lancé, puisque la sienne est dimensionnée par son propre modèle.

Les limites de concurrence et le filet de sécurité

Une session ne fait pas tourner un nombre illimité de sous-agents à la fois : la limite par défaut est de vingt sous-agents simultanés, réglable par CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, et un sous-agent ne peut en engendrer un autre qu'à trois niveaux de profondeur par défaut sous la conversation principale, réglable par CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH. Au delà, une nouvelle délégation échoue avec un message de limite atteinte plutôt que de dégrader silencieusement la session.

Objectif : lister les fichiers de configuration d'un dépôt fictif
et résumer en une ligne le rôle de chacun.
Périmètre d'écriture autorisé : aucun.
Interdiction explicite : aucun commit, aucun push, aucune commande destructive.
Modèle : sonnet.

Une invite de délégation bien construite ressemble à cet exemple : un objectif complet, un périmètre d'écriture nommé, des interdictions explicites, et un modèle choisi plutôt qu'hérité par défaut. Rien ne doit dépendre d'un échange ultérieur, puisqu'un sous-agent ne peut pas revenir vous poser une question à mi-tâche.

Le rapport final d'un sous-agent n'est pas lu tel quel par le modèle principal : Claude Code le scanne d'abord, parce qu'un sous-agent a pu lire un fichier, une page web ou une sortie de commande que vous n'avez jamais relue vous même, et que le texte de cette source peut porter une instruction adressée à la conversation principale plutôt qu'à vous. Ce contrôle s'applique à chaque rapport, sans exception déclarée pour un sous-agent de confiance.

Le fork, une variante qui n'isole rien

Une variante distincte, le fork, invoquée par /subtask, ne repart pas d'un contexte vide : elle hérite de toute la conversation en cours jusqu'à l'instant de l'appel. Seul son résultat final rejoint ensuite le fil principal, comme pour un sous-agent standard, mais tout ce qui précédait l'appel était déjà connu du fork dès le départ. Le choix entre les deux dépend de ce que la tâche doit savoir : une recherche autonome n'a besoin d'aucun historique, une continuation d'un raisonnement déjà engagé en a besoin de tout.

La déclaration explicite du modèle n'est pas un détail cosmétique : un hook, contrairement à un sous-agent, ne choisit jamais d'appeler le modèle, il réagit à un événement du cycle de vie décidé par le harnais.