Comment les données de configuration des sous-agents sont utilisées

Maintenant que vous savez comment créer des sous-agents, examinons les modèles qui les rendent réellement efficaces. Un sous-agent mal configuré errera, s'exécutera trop longtemps ou produira un résultat que l'agent principal ne peut pas utiliser. Les solutions se résument à quatre choses : écrire de bonnes descriptions, définir un format de sortie, signaler les obstacles et limiter l'accès aux outils.

Comment les données de configuration des sous-agents sont utilisées

Lorsque vous envoyez un message à l'agent de la fenêtre de contexte principale, le nom et la description de chaque sous-agent disponible sont inclus dans le prompt système. C'est ainsi que l'agent principal décide quel sous-agent lancer et quand. Si vous voulez un meilleur contrôle sur le moment où un sous-agent est déclenché automatiquement, le nom et la description sont ce que vous devriez ajuster.

La description joue également un deuxième rôle. Lorsque l'agent principal lance un sous-agent, il écrit un prompt d'entrée pour lancer la tâche. Il utilise la description comme guide pour écrire ce prompt. Donc la description ne contrôle pas seulement quand un sous-agent s'exécute -- elle façonne ce que le sous-agent est invité à faire.

Écrire des descriptions qui façonnent les prompts d'entrée

Considérez un sous-agent d'examen de code. Avec une description générique, l'agent principal pourrait écrire un prompt d'entrée comme « utiliser get diff pour trouver les modifications actuelles ». C'est vague. Le sous-agent doit déterminer par lui-même quels fichiers sont importants.

Si vous mettez à jour la description pour inclure quelque chose comme « Vous devez dire précisément à l'agent quels fichiers vous voulez qu'il examine », l'agent principal écrira maintenant un prompt d'entrée beaucoup plus spécifique qui énumère les fichiers réels à examiner.

Cette même technique fonctionne pour différents types de sous-agents. Par exemple, ajouter « retourner des sources qui peuvent être citées » à la description d'un sous-agent 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 sous-agent est de définir un format de sortie dans son prompt système. Cela fait deux choses :

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

Voici un exemple de format de sortie structuré pour un sous-agent d'examen de code :

Fournissez votre examen dans un format structuré :

Résumé : Aperçu bref de ce que vous avez examiné et évaluation globale
Problèmes critiques : Toute vulnérabilité de sécurité, risque d'intégrité des données,

ou erreur logique qui doit être corrigée immédiatement

Problèmes majeurs : Problèmes de qualité, désalignement architectural, ou

préoccupations de performance significatives

Problèmes mineurs : Incohérences de style, lacunes de documentation, ou

optimisations mineures

Recommandations : Suggestions d'amélioration, opportunités de refactorisation,

ou meilleures pratiques à appliquer

Statut d'approbation : Déclaration claire indiquant si le code est prêt

à fusionner/déployer ou nécessite des modifications

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

Signaler les obstacles

Lorsqu'un sous-agent découvre une solution de contournement pendant son travail -- comme résoudre un problème de dépendance ou découvrir qu'une certaine commande nécessite des drapeaux particuliers -- ces détails doivent apparaître dans le résumé qu'il retourne. S'ils ne le font pas, le thread principal doit redécouvrir les mêmes solutions par lui-même, ce qui gaspille du temps et des tokens.

Les types de choses que vous voulez mettre en avant incluent :

Les problèmes de configuration ou les particularités de l'environnement
Les solutions de contournement découvertes pendant la tâche
Les commandes qui nécessitaient des drapeaux ou une configuration spéciale
Les dépendances ou les imports qui ont 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 met en avant cette information de manière fiable.

Obstacles rencontrés : Signalez tous les obstacles rencontrés pendant le

processus d'examen. Cela peut être : des problèmes de configuration, des solutions de contournement découvertes ou des particularités de l'environnement. Signalez les commandes qui nécessitaient un drapeau ou une configuration spéciale. Signalez les dépendances ou les imports qui ont causé des problèmes.

Limiter l'accès aux outils

Chaque sous-agent n'a pas besoin d'accès à chaque outil. Réfléchissez à ce qu'un sous-agent doit réellement faire, et donnez-lui uniquement les outils nécessaires pour ce travail. Cela fait deux choses : cela prévient les effets secondaires involontaires, et cela rend le rôle de chaque sous-agent plus clair quand vous en avez plusieurs.

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

Sous-agent de recherche / lecture seule \-- N'a besoin que de Glob, Grep, et Read. Ne peut pas accidentellement modifier les fichiers.
Examinateur de code \-- Doit avoir 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 là que vous donnez accès à Edit et Write, car le travail du sous-agent est de réellement modifier votre code.

Tout mettre ensemble

Les sous-agents efficaces partagent quatre caractéristiques :

Descriptions spécifiques \-- La description contrôle quand le sous-agent est lancé et quelles instructions il reçoit. Écrivez-la pour diriger les deux.
Sortie structurée \-- Définissez un format de sortie dans le prompt système pour que le sous-agent sache quand il a terminé et retourne des informations que le thread principal peut utiliser.
Signalement des obstacles \-- Incluez une section dans le format de sortie pour les solutions de contournement, les particularités et les problèmes pour que le thread principal n'ait pas à les redécouvrir.
Accès aux outils limité \-- Donnez à un sous-agent uniquement les outils dont il a réellement besoin. Lecture seule pour la recherche, bash pour les examinateurs, édition/écriture uniquement pour les agents qui doivent modifier le code.

Chacun de ces modèles est simple en soi, mais ensemble ils transforment un sous-agent de quelque chose qui essaie vaguement d'aider en un travailleur ciblé et prévisible qui termine à temps et rend compte clairement.