Concevoir des subagents efficaces

Comment les données de configuration des subagents sont utilisées

Lorsque vous envoyez un message à l'agent de la fenêtre de contexte principale, le nom et la description de chaque subagent disponible sont inclus dans l'invite système. C'est ainsi que l'agent principal décide quel subagent lancer et quand. Si vous souhaitez mieux contrôler le moment où un subagent est déclenché automatiquement, ce sont le nom et la description que vous devez ajuster.

La description joue également un second rôle. Lorsque l'agent principal lance un subagent, il rédige une requête d'entrée pour démarrer la tâche. Il utilise la description comme guide pour rédiger cette requête. Ainsi, la description ne contrôle pas seulement quand un subagent s'exécute -- elle façonne également ce qu'on demande au subagent de faire.



Rédiger des descriptions qui façonnent les requêtes d'entrée

Prenons l'exemple d'un subagent de revue de code. Avec une description générique, l'agent principal pourrait rédiger une requête d'entrée du type « utilise git diff pour trouver les modifications actuelles ». C'est vague. Le subagent doit déterminer lui-même quels fichiers sont importants.

Si vous mettez à jour la description pour y inclure quelque chose comme « Vous devez indiquer précisément à l'agent quels fichiers vous souhaitez qu'il examine », l'agent principal rédigera désormais une requête d'entrée beaucoup plus précise qui énumère les fichiers réels à examiner.

Cette même technique fonctionne pour différents types de subagents. Par exemple, ajouter « renvoyer des sources pouvant être citées » à la description d'un subagent de recherche web amène l'agent principal à inclure cette instruction lors de la délégation de la tâche.



Définir un format de sortie

L'amélioration la plus importante que vous puissiez apporter à un subagent est de définir un format de sortie dans son invite système. Cela a deux effets :

• Cela crée des points d'arrêt naturels -- le subagent sait qu'il a terminé lorsqu'il a rempli chaque section du format.
• Cela empêche le subagent de s'exécuter trop longtemps. Sans sortie définie, les subagents ont du mal à décider quand suffisamment de recherches ont été effectuées et ont tendance à s'exécuter bien plus longtemps que nécessaire.

Voici un exemple de format de sortie structuré pour un subagent de revue de code :

Ce format donne au subagent une liste de contrôle claire à suivre. Une fois que chaque section est remplie, le subagent sait qu'il peut s'arrêter.

Signaler les obstacles

Lorsqu'un subagent découvre une solution de contournement pendant son travail -- comme résoudre un problème de dépendance ou constater qu'une certaine commande nécessite des indicateurs particuliers -- ces détails doivent apparaître dans le résumé qu'il renvoie. Si ce n'est pas le cas, le fil principal doit redécouvrir les mêmes solutions par lui-même, ce qui gaspille du temps et des jetons.

Les types d'éléments que vous souhaitez faire remonter incluent :

• Problèmes de configuration ou particularités de l'environnement
• Solutions de contournement découvertes pendant la tâche
• Commandes nécessitant des indicateurs ou une configuration spéciale
• Dépendances ou importations ayant causé des problèmes

La façon d'obtenir ces informations est de les demander explicitement dans le format de sortie. Ajouter une section « Obstacles rencontrés » à votre modèle de sortie fait remonter ces informations de manière fiable.



Limiter l'accès aux outils

Tous les subagents n'ont pas besoin d'accéder à tous les outils. Réfléchissez à ce qu'un subagent doit réellement faire, et ne lui donnez que les outils nécessaires à cette tâche. Cela a deux effets : cela évite les effets secondaires involontaires, et cela clarifie le rôle de chaque subagent lorsque vous en avez plusieurs.

Voici comment réfléchir à l'accès aux outils pour les types de subagents courants :

• Subagent de recherche / lecture seule -- N'a besoin que de Glob, Grep et Read. Ne peut pas modifier accidentellement des fichiers.
• Réviseur de code -- A besoin d'un accès Bash pour exécuter git diff et voir ce qui a changé, mais n'a toujours pas besoin de Edit ou Write.
• Agent de style / modification de code -- C'est ici que vous accordez l'accès à Edit et Write, car le rôle du subagent est de réellement modifier votre code.

Pour résumer

Les subagents efficaces partagent quatre caractéristiques :

1. Descriptions précises -- La description contrôle le moment où le subagent est lancé et les instructions qu'il reçoit. Rédigez-la pour orienter les deux.
2. Sortie structurée -- Définissez un format de sortie dans l'invite système afin que le subagent sache quand il a terminé et renvoie des informations que le fil principal peut utiliser.
3. Signalement des obstacles -- Incluez une section dans le format de sortie pour les solutions de contournement, les particularités et les problèmes, afin que le fil principal n'ait pas à les redécouvrir.
4. Accès limité aux outils -- Ne donnez à un subagent que les outils dont il a réellement besoin. Lecture seule pour la recherche, bash pour les réviseurs, edit/write uniquement pour les agents censés modifier le code.

Chacun de ces modèles est simple en soi, mais ensemble, ils transforment un subagent d'une entité qui tente vaguement d'aider en un exécutant concentré et prévisible, qui termine à temps et rend compte clairement.