Utiliser efficacement les sous-agents

Quand les sous-agents excellent

Les sous-agents fonctionnent le mieux lorsque l'exploration est distincte de l'exécution. Si chaque étape d'une tâche dépend de ce que l'étape précédente a découvert, vous voulez que ce travail se déroule dans votre fil principal. Mais si vous avez simplement besoin d'une réponse et que le cheminement ne vous importe pas, déléguez-la.

Les sous-agents excellent dans les tâches où :

• Vous avez besoin d'un résultat, pas d'un compte-rendu détaillé de la façon dont il a été trouvé
• Le travail exploratoire encombrerait le contexte de votre fil principal
• La tâche bénéficie d'un regard neuf ou d'une invite système personnalisée

Tâches de recherche

La recherche est le cas d'usage classique des sous-agents. Prenons l'exemple d'une investigation sur le fonctionnement de l'authentification dans une base de code inconnue. Votre fil principal a besoin de savoir où le JWT est validé, mais il n'a pas besoin de voir chaque fichier qui a été parcouru en chemin.

Un sous-agent de recherche peut lire des dizaines de fichiers, retracer des appels de fonctions et explorer différents chemins de code. Toute cette exploration reste dans le contexte du sous-agent. Votre fil principal reçoit un résumé clair comme celui-ci :

JWT validation happens in middleware/auth.js line 42,
called from the Express router in route/api.js

Le sous-agent a fait le gros du travail. Votre fil principal obtient exactement ce dont il a besoin pour avancer.

Revues de code

Claude effectue des revues de code plus efficacement lorsque le code est présenté comme ayant été rédigé par quelqu'un d'autre. Si vous avez construit une fonctionnalité sur plusieurs tours avec votre fil principal, demander à ce même fil de la relire produit souvent un retour peu pertinent. Claude a participé à sa création, il a donc du mal à la regarder avec un œil neuf.

Un sous-agent de revue voit les modifications dans un contexte distinct. Il exécute git diff, lit les fichiers modifiés et applique ses critères de revue spécialisés sans connaître l'historique de la façon dont le code a été écrit. Cette séparation vous permet également d'encoder des standards de revue spécifiques au projet dans l'invite système du sous-agent, garantissant des critères de revue cohérents au sein de l'équipe.

Invites système personnalisées

L'invite système par défaut de Claude Code privilégie des réponses concises et centrées sur le code. Cela fonctionne très bien pour le codage, mais pas pour tout.

Voici deux cas où une invite système personnalisée rend le sous-agent véritablement meilleur que le fil principal :

• Sous-agent de rédaction publicitaire -- Donnez-lui des instructions sur le ton, le public et le style. L'invite par défaut de Claude Code tend vers une rédaction technique concise, ce qui n'est vraiment pas ce que vous voulez pour une page d'atterrissage ou une campagne d'e-mails. Un sous-agent de rédaction publicitaire peut avoir des instructions complètement différentes sur la voix et la structure.
• Sous-agent de mise en forme -- Indiquez-lui dans son invite système de lire d'abord vos fichiers de système de design, afin qu'il connaisse vos variables de couleur, vos conventions d'espacement et vos modèles de composants avant de commencer à écrire du CSS.

Quand les sous-agents nuisent

Le coût de lancement d'un sous-agent -- masquer son travail au fil principal et compresser ses découvertes en un résumé -- n'a de sens que lorsque le sous-agent fait quelque chose que le fil principal ne peut pas faire. Il existe trois anti-modèles courants à surveiller.

Revendications d'expertise

Les sous-agents qui revendiquent une expertise aident rarement. Des requêtes comme « vous êtes un expert Python » ou « vous êtes un spécialiste Kubernetes » n'apportent aucune valeur ajoutée, car Claude possède déjà ces connaissances. Il n'y a rien qu'un sous-agent soi-disant expert puisse faire que votre fil principal ne puisse faire directement.

Pipelines séquentiels

Les pipelines séquentiels de sous-agents créent des problèmes. Prenons un flux à trois agents : un pour reproduire un bug, un pour le déboguer, et un pour le corriger. Les pipelines fonctionnent lorsque les tâches sont véritablement indépendantes. Ils échouent lorsque chaque étape dépend des découvertes de l'étape précédente -- et la correction de bugs en dépend presque toujours. Des informations se perdent lors du transfert entre agents.

Exécuteurs de tests

Les sous-agents exécuteurs de tests ont tendance à masquer des informations dont vous avez besoin. Lorsque les tests échouent, vous voulez la sortie complète pour diagnostiquer les problèmes. Un sous-agent qui renvoie « les tests ont échoué » vous oblige à créer des scripts de débogage supplémentaires pour obtenir des détails qui auraient été visibles dans une sortie directe. Les tests ont montré que le modèle d'exécuteur de tests a obtenu les pires performances parmi toutes les configurations.

La règle de décision

Lorsque vous décidez d'utiliser ou non un sous-agent, posez-vous une seule question : le travail intermédiaire compte-t-il ?

Si la réponse est non -- vous avez simplement besoin du résultat final -- déléguez-le à un sous-agent. Si la réponse est oui -- vous devez voir et réagir à ce qui se passe en cours de route -- gardez-le dans votre fil principal.

Utilisez les sous-agents pour :

• La recherche et l'exploration
• Les revues de code
• Les tâches nécessitant une invite système personnalisée

Évitez les sous-agents pour :

• Les personas « experts » qui n'apportent pas de capacité réelle
• Les pipelines à plusieurs étapes où chaque étape dépend de la précédente
• L'exécution de tests où vous avez besoin de la sortie complète pour le débogage