Chaîner des agents avec des transferts pour les tâches en plusieurs étapes
Les agents personnalisés individuels sont puissants eux-mêmes, mais leur plein potentiel apparaît lorsque vous les connectez en séquence pour gérer des tâches de développement complexes et multi-étapes. Les remises permettent à un agent de suggérer l’étape suivante avec un autre agent, de transférer le contexte de conversation et de fournir une transition transparente entre les rôles spécialisés.
Qu’est-ce que les remises ?
Un transfert est un mécanisme qui permet à un agent personnalisé de proposer une transition vers un autre agent après avoir terminé sa partie d’une tâche. Lorsqu’un agent termine sa réponse, il peut présenter un bouton de transfert ( une « action suivante » suggérée) qui, lorsqu’il est sélectionné, bascule la conversation vers un agent cible et préremplit éventuellement une invite pour continuer le flux de travail.
Par exemple, un agent planificateur peut produire un plan d’implémentation détaillé, puis afficher un bouton « Démarrer l’implémentation ». Lorsque le développeur sélectionne ce bouton, GitHub Copilot Chat bascule vers un agent Implementer qui reçoit le plan en tant que contexte, ainsi qu’une invite telle que « Implémenter maintenant votre plan suggéré ». Le développeur passe en revue le plan avant de sélectionner le bouton, en maintenant le contrôle sur le flux de travail pendant que les agents gèrent le travail spécialisé.
Cette approche crée un workflow multi-agent structuré dans lequel chaque agent gère une phase spécifique du processus de développement. Le développeur supervise chaque transition, en garantissant la qualité et l’exactitude à chaque étape. Les transferts ne s’exécutent pas automatiquement par défaut : ils nécessitent que le développeur choisisse le bouton de transfert, ce qui assure la participation continue de l’humain.
Configuration des transferts
Pour configurer un transfert, ajoutez une section handoffs au frontmatter YAML du fichier .agent.md d’un agent personnalisé. Chaque entrée de transfert spécifie la connexion entre l’agent actuel et l’agent cible.
Une entrée de transfert contient les champs suivants :
étiquette : texte affiché sur le bouton de remise (par exemple, « Démarrer l’implémentation » ou « Exécuter des tests »).
agent : nom ou identificateur de l’agent cible vers qui basculer. Ce nom doit correspondre au nom de fichier (sans l’extension
.agent.md) ou aunamechamp de l’agent cible.invite : message facultatif à envoyer à l’agent suivant. Cette invite fournit un contexte ou des instructions pour l’agent cible, telles que « Implémenter maintenant votre plan suggéré » ou « Passer en revue les modifications apportées au code à l’étape précédente ».
send : valeur booléenne qui contrôle si l’invite est envoyée automatiquement. Lorsque la valeur est définie
false(valeur par défaut), l’invite est préremplie dans l’entrée de conversation pour que le développeur passe en revue et modifie avant l’envoi. Lorsque la valeur est définietrue, l’invite est envoyée immédiatement et l’agent cible commence à fonctionner immédiatement.modèle : champ facultatif qui spécifie un modèle IA particulier à utiliser lors de l’exécution du transfert. Le format est
Model Name (vendor), tel queGPT-4.1 (OpenAI)ouClaude Sonnet 4 (Anthropic). Ce champ est utile lorsque différentes étapes d’un flux de travail bénéficient de différentes fonctionnalités de modèle, par exemple en utilisant un modèle de raisonnement pour la planification et un modèle plus rapide pour l’implémentation.
L’extrait de code YAML suivant montre un agent planificateur configuré avec un transfert à un agent Implementer :
---
description: Generates high-level implementation plans without writing code
tools: ['search', 'read', 'fetch']
handoffs:
- label: Start Implementation
agent: implementer
prompt: Now implement the plan outlined above.
send: false
---
Lorsque l’agent planificateur termine sa réponse, un bouton « Démarrer l’implémentation » s’affiche dans la conversation. La sélection de ce bouton bascule vers l’agent Implementer transfère l'historique des conversations (y compris le plan) et préremplit le texte d’invite que le développeur doit passer en revue.
Un agent peut définir plusieurs passages de relais afin de proposer différentes étapes suivantes. Par exemple, un agent planificateur peut proposer des boutons « Démarrer l’implémentation » et « Écrire des tests en premier », permettant au développeur de choisir le chemin approprié en fonction de la situation.
Examen et acceptation des remises
Les remises impliquent toujours une action explicite de l’utilisateur, en sélectionnant le bouton de remise, sauf si le champ send est défini à true. Cette conception garantit que le développeur reste en contrôle du flux de travail et peut passer en revue la sortie de chaque agent avant de passer à l’étape suivante.
Chaque agent d’une chaîne fonctionne dans son propre jeu d’outils défini et son jeu d’instructions. Cet environnement fournit des garde-fous à chaque étape du flux de travail. Par exemple:
- Un agent de planification avec uniquement
readetsearchdes outils peut collecter des informations et proposer des plans, mais ne peut pas modifier accidentellement le code. - Un agent d’implémentation avec
read,editetterminaldes outils peuvent écrire du code et exécuter des commandes de build, mais suit les instructions de codage spécifiques dans ses instructions. - Un agent de révision avec uniquement
readetsearchdes outils peuvent analyser le code généré, mais ne peut pas le modifier, ce qui garantit que son examen est purement consultatif.
Ces contraintes spécifiques au rôle rendent les processus multi-étapes plus fiables en empêchant les actions involontaires à chaque phase. Le développeur passe en revue le résultat produit à chaque point de transfert et ne poursuit le travail que lorsqu’il est satisfait du résultat.
Flux de travail multi-étapes courants
Les scénarios suivants montrent comment le chaînage des agents personnalisés peut améliorer la productivité entre différentes activités de développement.
Planification → Mise en œuvre
Utilisez un agent planificateur pour analyser les exigences et produire un plan d’implémentation détaillé pour une nouvelle fonctionnalité. Le plan identifie les fichiers qui ont besoin de modifications, décrit les étapes d’implémentation et met en évidence les risques potentiels. Un transfert est ensuite effectué vers un agent implémentateur qui écrit le code selon le plan, en suivant les fichiers d’instructions personnalisés du projet pour respecter les normes de codage.
Ce flux de travail reflète le fonctionnement des ingénieurs supérieurs avant le début de l’implémentation, en utilisant l’IA pour les deux phases tout en conservant le développeur dans le contrôle de la transition.
Implémentation → révision du code
Une fois le code généré, qu’il s’agisse d’un développeur humain ou d’un agent IA, le transfert peut se faire vers un agent de révision de code. L’agent de révision évalue la qualité du nouveau code, vérifie les bogues, les problèmes de sécurité, les violations de style et les cas de périphérie manquants. L’agent de révision peut ensuite fournir des commentaires pour les correctifs manuels ou remettre à un agent « Fixer » qui applique des corrections, sous réserve de l’approbation du développeur.
Écrire des tests défaillants → écrire du code pour réussir
Appliquer le développement piloté par les tests (TDD) en utilisant une chaîne à deux agents. Tout d’abord, un agent générateur de tests crée des tests unitaires défaillants pour une exigence spécifiée. Le développeur passe en revue les tests pour confirmer qu’ils capturent le comportement prévu. Ensuite, un transfert s'opère vers un agent Implementer qui écrit le code minimal nécessaire pour valider ces tests. Cette chaîne applique un cycle de test rouge-vert avec l’aide de l’IA, produisant à la fois les tests et l’implémentation.
Débogage et mise à jour corrective
Pour les scénarios de résolution de bogues, un agent de débogage lit les journaux d’erreurs, examine les tests défaillants et analyse le code approprié pour hypothésiser la cause du problème. Une fois le diagnostic terminé, la main est passée à un agent de correctif avec des autorisations d’édition pour appliquer le correctif. Un transfert final peut appeler un agent de tests afin de lancer la suite de tests et de vérifier que le problème a été résolu.
Refactorisation ou mise à niveau
Utilisez un agent de planification pour analyser une base de code existante et décrire un plan de refactorisation ou de migration, par exemple, mettre à niveau un projet C# d’une version .NET antérieure vers .NET 8. Le plan identifie les fichiers, API et modèles à modifier. Un transfert bascule vers un agent de mise à niveau qui effectue les modifications de code entre les fichiers en fonction du plan. Un transfert final à un agent de révision vérifie le code mis à jour pour les problèmes introduits lors de la migration.
Note
Ces flux de travail reflètent la façon dont les équipes de développement peuvent déléguer une séquence de tâches (plan, code, test, révision) à différentes assistances d’IA spécialisées lors de la supervision de chaque étape. Le résultat est un flux de travail plus efficace où les tâches répétitives ou complexes sont gérées par l’IA, ce qui permet au développeur de se concentrer sur la prise de décision et la vérification.
Environnements d’exécution d’agent
Par défaut, les agents personnalisés s’exécutent sur le client (à l’intérieur de Visual Studio Code). Toutefois, les agents peuvent également être configurés pour s’exécuter dans le cloud en définissant target: cloud le frontmatter YAML de l’agent. Les agents cloud s’exécutent à distance et sont mieux adaptés aux tâches de longue durée, telles que la création d’une fonctionnalité entière ou l’exécution d’une suite de tests complète, qui conserverait autrement votre instance Visual Studio Code locale occupée. Les agents en arrière-plan sont un concept connexe : ils s’exécutent indépendamment sans bloquer l’interface de conversation, ce qui vous permet de continuer à travailler pendant que l’agent traite une tâche.
Hooks de GitHub Copilot
Les hooks GitHub Copilot vous permettent d’exécuter des commandes shell personnalisées à des points stratégiques dans le flux de travail d’un agent. Les hooks sont définis dans vos paramètres Visual Studio Code (et non dans les fichiers de l’agent) et se déclenchent avant ou après des événements spécifiques, comme avant que GitHub Copilot enregistre un fichier ou après l’exécution d’une commande de terminal. Par exemple, vous pouvez configurer un hook pour exécuter un linter automatiquement après que GitHub Copilot modifie un fichier, en garantissant que le code généré par l’IA répond toujours à vos normes de mise en forme avant d’être enregistrés.
Les hooks étendent les fonctionnalités d’automatisation des workflows multi-agents en ajoutant des actions basées sur le cycle de vie qui complètent les propres instructions et outils de l’agent.
Note
Les hooks sont une fonctionnalité d’aperçu et leur format de configuration peut changer. Ils sont configurés dans les paramètres Visual Studio Code sous github.copilot.chat.hooks et prennent en charge les événements tels que postSaveFile, preRunTerminalCommandet postRunTerminalCommand.
Résumé
Les handoffs connectent plusieurs agents personnalisés à des flux de travail séquentiels guidés, ce qui permet de réaliser des tâches de développement multi-étapes où chaque agent prend en charge une phase spécifique. En configurant les transferts dans le frontmatter YAML des fichiers d’agent, vous pouvez créer des chaînes qui passent de la planification à l'implémentation, de l'implémentation à la révision, ou toute autre séquence qui correspond au processus de développement de votre équipe. Chaque transfert conserve le développeur en contrôle, avec la possibilité d’examiner et d’approuver avant de passer à l’étape suivante. D’autres fonctionnalités telles que les agents cloud, l’exécution en arrière-plan et les hooks GitHub Copilot étendent ces workflows avec le traitement à distance et l’automatisation du cycle de vie.