Qu’est-ce que le mode de plan GitHub Copilot

Terminée

Tip

Pour plus d’informations, consultez l’onglet Texte et images !

GitHub Copilot dans Visual Studio Code fournit trois agents intégrés, chacun fonctionnant sous un niveau d’autonomie différent et avec une relation différente avec votre espace de travail :

• Agent : agent d’implémentation entièrement autonome. Il décompose un objectif en tâches subordonnées, exécute des appels d’outils (lectures de fichiers, écritures, commandes de terminal, appels de serveur MCP) et applique des modifications directement à votre espace de travail. La boucle Agent s’exécute jusqu’à ce que l’objectif soit atteint ou qu’elle atteigne une ambiguïté qu’elle ne peut pas résoudre.
• Poser : un agent de questions-réponses sans état avec un accès en lecture seule à l'espace de travail. Il peut raisonner sur votre code, expliquer les concepts et suggérer des approches, mais il n’écrit ni n’exécute rien.
• Plan : un agent de raisonnement qui fonctionne dans un modèle délibéré à deux phases. La recherche et la synthèse viennent d’abord, puis la mise en œuvre, avec une porte de révision humaine obligatoire entre les deux phases.

La distinction qui importe pour le travail des opérations n’est pas seulement à propos de la sécurité. C’est à propos de l’endroit où se trouve dans la boucle agentique le jugement humain. Avec l’Agent, vous passez en revue la sortie après coup. Avec l’agent de planification, vous examinez et approuvez l’approche avant qu’un seul appel d’outil ne modifie l’état.

Comment fonctionne l’agent Plan en interne

L’agent de plan est une instance d’un modèle agentique plus large appelé plan-and-execute, où le raisonnement sur ce qu’il faut faire est séparé de le faire. Comprendre comment l’agent collecte des informations à chaque étape vous aide à écrire de meilleures invites et à interpréter son résultat de façon plus critique.

Phase 1 : Collecte de contexte

Lorsque vous envoyez une invite, l’agent de plan ne génère pas immédiatement un plan. Il génère d’abord un modèle de contexte de votre environnement en appelant un ensemble d’outils en lecture seule dans la séquence :

• Énumération de fichier d’espace de travail : l’agent analyse votre arborescence de fichiers d’espace de travail pour comprendre la structure du projet. Quels langages, frameworks et fichiers de configuration sont présents.
• Lectures de fichiers ciblées : en fonction de l’arborescence de fichiers, l’agent lit les fichiers pertinents pour votre demande. Pour une invite d’infrastructure, il lit les modules Bicep existants, les fichiers de paramètres et toutes les bicepconfig.json. Pour une invite PowerShell, elle lit les scripts existants, les manifestes de module et la PSScriptAnalyzer configuration.
• Instructions personnalisées: L’agent lit .github/copilot-instructions.md s’il existe à la racine de l’espace de travail. Ce fichier est traité comme un contexte faisant autorité qui forme chaque plan généré par l’agent dans cet espace de travail.
• Mémoire de session : l’agent lit /memories/session/ pour récupérer n’importe quel contexte antérieur dans la même conversation. Plans précédents, réponses à des questions précises ou des faits que vous avez déclarés précédemment.

Aucun appel réseau externe n’est effectué vers des sites de documentation ou des API pendant cette phase. La connaissance de l'agent des services Azure, des API PowerShell ou de la syntaxe Bicep provient de ses données d'apprentissage, et non de recherches actives.

Phase 2 : Clarification des questions

Si le contexte collecté dans la phase 1 est insuffisant pour produire un plan sans ambiguïté, l'agent pose des questions clarificatrices. Ces questions ne sont pas générées de manière aléatoire. Ils correspondent aux points de décision dans la mise en œuvre où différentes réponses mènent à des plans différents de manière significative.

Pour une demande d’opérations, les principaux points de décision sont les suivants :

• Étendue : Quel est l’abonnement, le groupe de ressources ou le serveur ciblé ?
• Dépendances : la nouvelle ressource doit-elle référencer quelque chose qui existe déjà ou doit-elle créer ses propres dépendances ?
• Contraintes : Existe-t-il des conventions d’affectation de noms, des exigences de conformité ou des limites budgétaires qui excluent certaines approches ?
• Stratégie de test : le plan doit-il inclure une étape de validation à sec ou de scénario, et le cas échéant, par rapport à quel environnement ?

La qualité des questions posées par l’agent est un signal utile. Si l'agent ne pose aucune question de clarification et élabore immédiatement un plan pour une sollicitation complexe et mal définie, traitez le plan obtenu avec un examen plus rigoureux. Il a fait des hypothèses qui peuvent ne pas correspondre à votre environnement.

Phase 3 : Planifier la synthèse

Avec un contexte suffisant, l’agent synthétise un plan structuré. Ce qui implique le raisonnement sur :

• Classement des dépendances : quelles ressources ou étapes de configuration doivent être créées avant que d’autres puissent les référencer.
• Surface de risque : quelles étapes sont réversibles et qui ne sont pas, et où les portes de vérification doivent être placées.
• Alignement de l'outillage : quels commandes CLI Azure, cmdlets PowerShell, ou constructs Bicep conviennent en fonction des contraintes et des modèles de l'espace de travail.
• Fermeture de la vérification : quelle preuve confirmerait que chaque étape a réussi et comment ces preuves peuvent être recueillies sans intervention humaine.

La sortie du plan est écrite /memories/session/plan.md automatiquement, la rendant disponible pour référence tout au long de la conversation.

Phase 4 : itération

Le plan n’est pas final après la première génération. Chaque invite de suivi que vous envoyez entraîne la réentration de la phase de synthèse avec le contexte mis à jour. Y compris le plan précédent, vos commentaires et toutes les nouvelles contraintes que vous avez introduites, sont prises en compte. L’agent ne redémarre pas à partir de zéro ; Il traite le plan précédent comme un plan antérieur qui peut être modifié.

Cette boucle itérative est l’endroit où le mode Plan gagne la plupart de sa valeur pour le travail des opérations. Les exigences qui émergent au milieu de la conversation peuvent être incorporées sans perdre le contexte établi à des tours précédents.

Accéder à l’agent du plan

Vous pouvez accéder à l'agent Plan de deux façons :

• Sélecteur d’agent : ouvrez la vue Conversation (Ctrl+Alt+I), puis sélectionnez Plan dans la liste déroulante des agents.
• Commande barre oblique : tapez /plan la description de votre tâche dans la zone d’entrée de conversation. Par exemple:

/plan Create a PowerShell script to audit all expired user accounts in Active Directory

À quoi ressemble un plan

Lorsque l’agent de plan génère un plan, il produit généralement trois sections :

• Résumé : Vue d’ensemble de ce que le plan accomplit et de l’approche qu’il adopte. Écrit pour être compréhensible par les implémenteurs techniques et les parties prenantes non techniques.
• Étapes d’implémentation : tâches ordonnées qui décrivent les fichiers à créer ou modifier, le code à écrire et la façon dont les composants se connectent les uns aux autres. Les étapes sont séquencées pour respecter les dépendances. Par exemple, un sous-réseau doit exister avant qu’un groupe de sécurité réseau puisse le référencer.
• Étapes de vérification : actions pour confirmer que l’implémentation fonctionne correctement, comme l’exécution az deployment what-if, la validation de la conformité DSC avec Test-DscConfigurationou la vérification de l’intégrité des ressources après le déploiement. Les étapes de vérification sont limitées afin qu’elles puissent être exécutées sans avoir besoin d’un accès en production.

Par exemple, si vous demandez à l’agent de plan de créer une stratégie de balisage de groupe de ressources Azure, le plan peut inclure des étapes pour créer un fichier JSON de définition de stratégie, affecter la stratégie à un groupe d’administration et vérifier la conformité en exécutant une commande Azure CLI.

Emplacement où les plans sont stockés

L’agent de plan enregistre automatiquement son plan d’implémentation dans un fichier mémoire de session à l’adresse /memories/session/plan.md. Vous pouvez accéder à ce fichier en exécutant la commande Chat : Afficher les fichiers mémoire dans la palette de commandes et en sélectionnant plan.md. Étant donné que la mémoire de session est effacée lorsque la conversation se termine, le plan n’est pas disponible dans les sessions ultérieures. Si vous devez conserver un plan, copiez-le dans un fichier de votre référentiel avant de fermer la session.

Mode Plan et Mode Agent

La différence entre le mode Plan et le mode Agent n’est pas principalement à propos de la fonctionnalité. Les deux ont accès au même modèle sous-jacent. La différence concerne la position de la porte de révision humaine dans la boucle agentique et le contrat d’effet secondaire sous lequel chaque mode fonctionne.

Dimension	Agent de planification	Agent
Effets secondaires pendant le raisonnement	Aucun; lit uniquement	Écrit des fichiers, exécute des commandes, appelle des outils
Porte de révision humaine	Avant le début d’une implémentation	Une fois l’implémentation terminée (ou pendant, si des erreurs se produisent)
Réversibilité de l’état de la tâche intermédiaire	Toujours réversible ; aucune modification apportée	Dépend de ce qui a été exécuté
Adapté aux workflows de gestion du changement	Oui; le plan est l’artefact envoyé pour approbation	Non; la sortie est l’artefact, qui peut déjà être appliqué
Utilisation de la fenêtre de contexte	Réduit; aucun résultat d'appel d'outil issu des étapes d'implémentation	Plus élevé; recueille les résultats des appels d’outils exécutés
Gestion des ambiguïtés	Clarifiez les ambiguïtés en les formulant sous forme de questions avant de continuer.	Fait des hypothèses et poursuit l'action ; peut échouer ou nécessiter un retour en arrière

L’implication pratique pour les équipes d’opérations est la suivante : lorsqu’une tâche implique plusieurs ressources interdépendantes, des étapes irréversibles (telles que des modifications de schéma de base de données ou des modifications de règle de pare-feu) ou nécessite une piste d’approbation documentée, le mode Plan est le choix structurellement correct, pas seulement le plus sûr.

Utilisez le mode Agent lorsque la tâche est limitée, l’état de l’espace de travail est facilement réversible et l’itération rapide compte plus qu’une approche préapprobée.

Passer à l’implémentation

Une fois que vous avez finalisé un plan, vous disposez de plusieurs options pour continuer :

• Implémenter dans la même session : sélectionnez Démarrer l’implémentation pour permettre à l’agent d’implémenter le plan directement dans votre espace de travail. L’agent reçoit le document de plan en tant que contexte initial et commence à exécuter les étapes d’implémentation.
• Continue dans Copilot CLI : Sélectionnez Start Implementation>Continue dans Copilot CLI pour exécuter l’implémentation en tant que session en arrière-plan. Copilot CLI crée une arborescence de travail Git : une copie isolée de votre référentiel à la validation en cours. Ainsi, l’implémentation s’exécute sur un état propre sans affecter votre arborescence de travail.
• Continuez avec Copilot dans le cloud : transférez à Copilot dans le cloud, qui s’exécute sur l’infrastructure GitHub. Il implémente le plan, ouvre une pull request, crée un pipeline CI/CD et établit un enregistrement d’approbation auditable.

Le mécanisme de transfert est important d'un point de vue architectural : le document de plan écrit pour /memories/session/plan.md devient la spécification de tâche de l’agent d’implémentation. La qualité et la spécificité du plan contrôlent directement la qualité de l’implémentation. Un plan vague produit une exécution vague, et un plan avec des portes de vérification explicites amène l’agent d’implémentation à s'arrêter et à vérifier à chaque porte avant de continuer.