Was ist der GitHub Copilot Plan-Modus?

  • 7 Minuten

GitHub Copilot in Visual Studio Code bietet drei integrierte Agents, die jeweils unter einer anderen Autonomieebene und mit einer anderen Beziehung zu Ihrem Arbeitsbereich arbeiten:

  • Agent: Ein vollständig autonomer Implementierungs-Agent. Es dekompiliert ein Ziel in Teilvorgänge, führt Toolaufrufe aus (Dateilesevorgänge, Schreibvorgänge, Terminalbefehle, MCP-Serveraufrufe) und wendet Änderungen direkt auf Ihren Arbeitsbereich an. Die Agent-Schleife wird ausgeführt, bis das Ziel erreicht ist oder eine Mehrdeutigkeit auftritt, die nicht aufgelöst werden kann.
  • Fragen: Ein zustandsloser Fragebeantwortungs-Agent mit schreibgeschütztem Zugriff auf den Arbeitsbereich. Es kann Gründe für Ihren Code geben, Konzepte erläutern und Ansätze vorschlagen, aber es schreibt oder führt niemals etwas aus.
  • Plan: Ein primär auf Schlussfolgerung ausgerichteter Agent, der in einem bewussten, zweistufigen Modell arbeitet. Forschung und Synthese kommen zuerst, dann die Implementierung, mit einer obligatorischen menschlichen Überprüfung zwischen den beiden Phasen.

Der Unterschied, der für Betriebsarbeiten wichtig ist, ist nicht nur die Sicherheit. Es geht darum, wo in der agentischen Schleife das menschliche Urteil sitzt. Mit dem Agenten überprüfen Sie die Ausgabe im Nachhinein. Mit dem Plan-Agent überprüfen und genehmigen Sie den Ansatz, bevor ein einzelner Toolaufruf ausgeführt wird, der den Status ändert.

Wie der Planungs-Agent intern funktioniert

Der Plan-Agent ist eine Instanz eines umfassenderen agentischen Musters namens "Plan-and-Execute", bei dem das Überlegen, was zu tun ist, vom tatsächlichen Tun getrennt ist. Wenn Sie wissen, wie der Agent Informationen in jeder Phase sammelt, können Sie bessere Eingabeaufforderungen schreiben und die Ausgabe kritischer interpretieren.

Phase 1: Kontexterfassung

Wenn Sie eine Eingabeaufforderung übermitteln, generiert der Plan-Agent nicht sofort einen Plan. Zunächst wird durch Aufrufen einer Reihe schreibgeschützter Tools in Folge ein Kontextmodell Ihrer Umgebung erstellt:

  • Enumeration der Arbeitsbereichsdatei: Der Agent scannt die Arbeitsbereichsdateistruktur, um die Projektstruktur zu verstehen. Welche Sprachen, Frameworks und Konfigurationsdateien vorhanden sind.
  • Gezielte Dateiauslese: Basierend auf der Dateistruktur liest der Agent Dateien, die für Ihre Anforderung relevant sind. Bei einem Infrastruktur-Prompt liest er vorhandene Bicep-Module, Parameterdateien und alle bicepconfig.json. Bei einer PowerShell-Eingabeaufforderung werden vorhandene Skripts, Modulmanifeste und PSScriptAnalyzer Konfigurationen gelesen.
  • Benutzerdefinierte Anweisungen: Der Agent liest .github/copilot-instructions.md, sofern im Arbeitsbereichstamm vorhanden. Diese Datei wird als autoritativer Kontext behandelt, der jeden Plan bildet, den der Agent in diesem Arbeitsbereich generiert.
  • Sitzungsspeicher: Der Agent liest /memories/session/, um jeden Kontext aus früheren Teilen derselben Unterhaltung aufzunehmen. Frühere Pläne, Antworten auf die Klärung von Fragen oder Fakten, die Sie zuvor angegeben haben.

Während dieser Phase werden keine externen Netzwerkaufrufe an Dokumentationswebsites oder APIs ausgeführt. Das Wissen des Agenten über Azure-Dienste, PowerShell-APIs oder Bicep-Syntax stammt aus seinen Schulungsdaten, nicht aus Live-Abfragen.

Phase 2: Klären von Fragen

Wenn der in Phase 1 gesammelte Kontext nicht ausreicht, um einen eindeutigen Plan zu erstellen, stellt der Agent klärende Fragen. Diese Fragen werden nicht zufällig generiert. Sie entsprechen Entscheidungspunkten in der Implementierung, bei denen verschiedene Antworten zu sinnvoll unterschiedlichen Plänen führen.

Zu einer Betriebsaufforderung gehören typische Entscheidungspunkte:

  • Bereich: Welches Abonnement, welche Ressourcengruppe oder welcher Server ist gezielt?
  • Abhängigkeiten: Muss die neue Ressource auf etwas verweisen, das bereits vorhanden ist, oder sollten sie eigene Abhängigkeiten erstellen?
  • Einschränkungen: Gibt es Benennungskonventionen, Complianceanforderungen oder Budgetbeschränkungen, die bestimmte Ansätze ausschließen?
  • Teststrategie: Sollte der Plan einen Trockenlauf- oder Was-wäre-wenn-Validierungsschritt enthalten, und wenn ja, für welche Umgebung?

Die Qualität der Fragen, die der Agent stellt, ist ein nützliches Signal. Wenn der Agent keine klärenden Fragen stellt und sofort einen Plan für eine komplexe, nicht genau spezifizierte Eingabeaufforderung erstellt, behandeln Sie den resultierenden Plan mit besonderer Sorgfalt. Es wurden Annahmen getroffen, die ihrer Umgebung möglicherweise nicht entsprechen.

Phase 3: Syntheseplanung

Mit ausreichendem Kontext synthetisiert der Agent einen strukturierten Plan. Dies beinhaltet Überlegungen zu Folgendem:

  • Abhängigkeitsreihenfolge: Welche Ressourcen oder Konfigurationsschritte müssen erstellt werden, bevor andere darauf verweisen können.
  • Risikooberfläche: Welche Schritte umkehrbar sind und welche nicht, und wo Prüftore platziert werden sollen.
  • Toolabstimmung: Welche Azure CLI-Befehle, PowerShell-Cmdlets oder Bicep-Konstrukte entsprechend den Einschränkungen und vorhandenen Mustern im Arbeitsbereich geeignet sind.
  • Überprüfungsschließung: Welche Beweise bestätigen würden, dass jeder Schritt erfolgreich war und wie diese Beweise ohne menschliche Intervention gesammelt werden können.

Die Planausgabe wird automatisch zu /memories/session/plan.md geschrieben, sodass sie während der restlichen Unterhaltung zur Referenz bereitgestellt werden kann.

Phase 4: Iteration

Der Plan ist nach der ersten Generation nicht abgeschlossen. Jede von Ihnen übermittelte Nachverfolgungsaufforderung bewirkt, dass der Agent die Synthesephase mit dem aktualisierten Kontext erneut eingibt. Es werden der vorherige Plan, Ihr Feedback und alle neuen Einschränkungen, die Sie eingeführt haben, berücksichtigt. Der Agent startet nicht von Grund auf neu; er behandelt den vorherigen Plan als vorgegebene Grundlage, die geändert werden kann.

In dieser iterativen Schleife erzielt der Planmodus den größten Nutzen für Betriebsvorgänge. Anforderungen, die sich in der Mitte der Unterhaltung ergeben, können integriert werden, ohne den in früheren Wendungen festgelegten Kontext zu verlieren.

Diagramm eines typischen GitHub Plan-Agenten-Planungsablaufs.

Zugriff auf den Plan-Agent

Sie können auf zwei Arten auf den Plan-Agent zugreifen:

  • Agentauswahl: Öffnen Sie die Chatansicht (Ctrl+Alt+I), und wählen Sie " Plan" aus der Dropdownliste "Agents" aus.
  • Schrägstrichbefehl: Geben Sie /plan gefolgt von Ihrer Aufgabenbeschreibung in das Chateingabefeld ein. Beispiel:
/plan Create a PowerShell script to audit all expired user accounts in Active Directory

Wie ein Plan aussieht

Wenn der Plan-Agent einen Plan generiert, erzeugt er in der Regel drei Abschnitte:

  • Zusammenfassung: Eine allgemeine Übersicht darüber, was der Plan erreicht, und den Ansatz, den sie verfolgt. Geschrieben, um sowohl von technischen Implementierern als auch von nicht technischen Stakeholdern verständlich zu sein.
  • Implementierungsschritte: Sortierte Aufgaben, die beschreiben, welche Dateien erstellt oder geändert werden sollen, welcher Code geschrieben werden soll und wie Komponenten miteinander verbunden sind. Schritte werden sequenziert, um Abhängigkeiten zu beachten. Beispielsweise muss ein Subnetz vorhanden sein, bevor ein NSG darauf verweisen kann.
  • Überprüfungsschritte: Aktionen, um zu bestätigen, dass die Implementierung ordnungsgemäß funktioniert, z. B. Ausführen az deployment what-if, Überprüfen der DSC-Compliance mit Test-DscConfigurationoder Überprüfen der Ressourcenintegrität nach der Bereitstellung. Die Überprüfungsschritte sind so erweitert, dass sie ohne Produktionszugriff ausgeführt werden können.

Wenn Sie beispielsweise den Plan-Agent bitten, eine richtlinie für Azure Ressourcengruppentagging zu erstellen, enthält der Plan möglicherweise Schritte zum Erstellen einer JSON-Datei für richtliniendefinitionen, zum Zuweisen der Richtlinie zu einer Verwaltungsgruppe und zum Überprüfen der Compliance durch Ausführen eines Azure CLI Befehls.

Wo Pläne gespeichert werden

Der Plan-Agent speichert seinen Implementierungsplan automatisch in einer Sitzungsspeicherdatei unter /memories/session/plan.md. Sie können auf diese Datei zugreifen, indem Sie den Befehl "Chat: Speicherdateien anzeigen " in der Befehlspalette ausführen und auswählen plan.md. Da der Sitzungsspeicher gelöscht wird, wenn die Unterhaltung endet, ist der Plan in späteren Sitzungen nicht verfügbar. Wenn Sie einen Plan beibehalten müssen, kopieren Sie ihn in eine Datei in Ihrem Repository, bevor Sie die Sitzung schließen.

Planmodus im Vergleich zum Agentmodus

Der Unterschied zwischen dem Planmodus und dem Agentmodus ist nicht in erster Linie mit der Funktion verbunden. Beide haben Zugriff auf dasselbe zugrunde liegende Modell. Der Unterschied liegt in der Position der menschlichen Kontrollinstanz innerhalb der agentischen Schleife und in den Nebenwirkungsbestimmungen, denen die einzelnen Modi unterliegen.

Abmessung Plan-Agent Agent
Nebenwirkungen während der Begründung Keine; Nur lesen Schreibt Dateien, führt Befehle aus, ruft Tools auf.
Prüftor für menschliche Überprüfung Bevor eine Implementierung beginnt Nach Abschluss der Implementierung (oder bei Auftreten von Fehlern)
Umkehrbarkeit des Zwischenzustands einer Aufgabe Immer umkehrbar; keine vorgenommenen Änderungen Es hängt davon ab, was ausgeführt wurde
Geeignet für Änderungsmanagement-Workflows Ja; der Plan ist das artefakt, das zur Genehmigung übermittelt wurde. Nein; die Ausgabe ist das Artefakt, das möglicherweise bereits angewendet worden ist
Kontextfensterverwendung Niedriger; keine Ergebnisse des Toolaufrufs aus Implementierungsschritten Höher; kumuliert Ergebnisse von ausgeführten Toolaufrufen
Mehrdeutigkeitsbehandlung Macht Mehrdeutigkeiten als Fragen sichtbar, bevor man fortfährt Geht von Annahmen aus und fährt fort; es kann fehlschlagen oder ein Rollback erfordern

Die praktische Auswirkung für Betriebsteams ist dies: Wenn ein Vorgang mehrere zusammenhängende Ressourcen umfasst, unwiderrufliche Schritte (z. B. Datenbankschemaänderungen oder Firewallregeländerungen) oder einen dokumentierten Genehmigungspfad erfordert, ist der Planmodus die strukturell richtige Wahl, nicht nur die sicherere.

Verwenden Sie den Agent-Modus, wenn die Aufgabe gebunden ist, der Arbeitsbereichszustand leicht umkehrbar ist, und eine schnelle Iteration ist wichtiger als ein vorab genehmigter Ansatz.

Übergabe an Implementierung

Nachdem Sie einen Plan abgeschlossen haben, haben Sie mehrere Optionen, um fortzufahren:

  • Implementieren Sie in derselben Sitzung: Wählen Sie "Implementierung starten " aus, damit der Agent den Plan direkt in Ihrem Arbeitsbereich implementieren kann. Der Agent empfängt das Plandokument als anfänglichen Kontext und beginnt mit der Ausführung der Implementierungsschritte.
  • Continue in Copilot CLI: Wählen Sie Start Implementation>Continue in Copilot CLI, um die Implementierung als Hintergrundsitzung auszuführen. Copilot CLI erstellt eine Git-Arbeitsstruktur; eine isolierte Kopie Ihres Repositorys auf dem aktuellen Commit. Daher wird die Implementierung mit einem einwandfreien Zustand ausgeführt, ohne dass sich dies auf Ihre Arbeitsstruktur auswirkt.
  • In einem Cloud-Agent fortfahren: Übergeben Sie an einen Copilot-Cloud-Agent, der auf der GitHub-Infrastruktur ausgeführt wird. Der Cloud-Agent implementiert den tatsächlichen Plan, öffnet eine Pull-Anforderung, erstellt CI/CD-Pipeline und richtet einen auditierbaren Genehmigungsdatensatz ein.

Der Übergabemechanismus ist von wesentlicher Bedeutung für die Architektur: Das Plandokument, das an /memories/session/plan.md geschrieben wird, wird zur Aufgabenspezifikation des Implementierungs-Agents. Die Qualität und Spezifität des Plans steuert die Qualität der Umsetzung direkt. Ein vage Plan erzeugt eine vage Umsetzung, und ein Plan mit expliziten Überprüfungsgaten bewirkt, dass der Implementierungsmitarbeiter an jedem Gate angehalten und überprüft wird, bevor er fortfahren kann.