Separate Planung, Begründung und Ausführung

  • 5 Minuten

In dieser Lektion lernen Sie:

  • Warum die Trennung von Planung, Ausführung und Validierung die Zuverlässigkeit verbessert

  • Grundlegendes zum Unterschied zwischen einem Workflow des Typs „Plan zuerst” und einem des Typs „Plan und Ausführung”

  • So legen Sie Planungsgrenzen mithilfe von Leistungsgrenzen und Tool-Sperrung fest.

Warum Die Trennung die Zuverlässigkeit verbessert

Zuverlässige Agentensysteme unterscheiden sich:

  • Planung: Was geschieht und warum.

  • Ausführung: die konkreten Änderungen, die am Repository vorgenommen wurden.

  • Validierung: Nachweis, dass das Ergebnis erfolgskriterien erfüllt.

Wenn Planung und Ausführung zusammen vermischt werden, sehen Prüfer nur den abschließenden Unterschied. Sie verlieren die Fähigkeit, Absichten frühzeitig zu validieren, Missverständnisse schnell zu erkennen und den Umfang vor dem Eintreten der Auswirkungen zu kontrollieren.

Wie die Zuordnung zur Trennung auf GitHub erfolgt

GitHub unterstützt diese Trennung natürlich:

  • Die Planung wird in einer PR-Beschreibung, einem Problemkommentar oder einem Github/pull_request_template.md-Artefakt angezeigt.

  • Die Ausführung wird als Commit für eine Verzweigung angezeigt.

  • Validierung erscheint als Kontrollen, Scans, Artefakte und Überprüfungsergebnisse.

Grundlegendes zum Unterschied zwischen einem Workflow des Typs „Plan zuerst” und einem des Typs „Plan und Ausführung”

Beim Arbeiten mit Agents müssen Teams entscheiden, wann ein Plan sichtbar wird und wann Codeänderungen beginnen dürfen. In GitHub können Planung und Ausführung von verschiedenen Einstiegspunkten wie einem GitHub Problem (z. B. dem Zuweisen eines Copilot Cloud-Agents) oder über die Registerkarte "Agents" beginnen, auf der ein Plan interaktiv generiert wird.

Dies sind separate Möglichkeiten der Interaktion mit dem Agenten, aber sie konvergieren auf dasselbe Governance-Modell: Alle Arbeiten werden letztendlich in einem Pull-Request (PR) angezeigt und überprüft.

Die wichtigste Designauswahl ist daher nicht der Anfang des Plans, sondern wenn eine menschliche Validierung im Verhältnis zu Codeänderungen erforderlich ist.

Option A: Plan-first-Pull-Anforderung

Bei diesem Ansatz wird die Planung abgeschlossen und genehmigt, bevor Codeänderungen eingeführt werden.

Funktionsweise in der Praxis:

  • Ein Plan wird generiert (z. B. durch das Zuweisen eines Agenten zu einem GitHub-Issue oder durch dessen Erstellung auf der Registerkarte "Agents").

  • Der Agent öffnet eine Pull-Anforderung, die nur den Plan enthält (noch keine Codeänderungen).

  • Prüfer diskutieren, verfeinern und genehmigen den Plan direkt in der PR.

  • Nach der Genehmigung beginnt der Agent, den Plan in Folge-Commits oder eine neue PR zu implementieren.

Dadurch wird eine klare Trennung zwischen Absicht (Plan) und Ausführung (Code) erstellt.

Option B: Planen und Ausführen in derselben Pullanforderung

Bei diesem Ansatz werden Planung und Ausführung in einer einzigen PR kombiniert.

Funktionsweise in der Praxis:

  • Der Agent öffnet eine PR, die beide umfasst:

    • ein strukturierter Plan (in der Beschreibung)

    • Anfängliche Codeänderungen (Commits)

  • Der Agent kann die PR weiterhin aktualisieren, wenn sich der Plan weiterentwickelt.

  • Standardmäßige erforderliche Prüfungen der GitHub-Steuerelemente, CODEOWNERS-Überprüfungen und der Verzweigungsschutz verhindern die Zusammenführung, bis alle Anforderungen erfüllt sind.

Hier ist der Plan noch sichtbar, aber er wird zusammen mit aktiven Änderungen und nicht vor ihnen dargestellt.

Wichtiger Unterschied: Überprüfungszeitpunkt

Beide Optionen verwenden dieselben GitHub-Steuerelemente. Der Unterschied besteht darin, dass diese Steuerelemente relativ zur Ausführung angewendet werden:

  • Option A (Plan-first): Die menschliche Überprüfung erfolgt vor dem Schreiben von Code.

  • Option B (Plan + Ausführung): Code wird sofort generiert, die Überprüfung ist jedoch noch vor dem Zusammenführen erforderlich.

Risikoüberlegungen

Beide Ansätze können sicher sein, wenn GitHub Schutz ordnungsgemäß konfiguriert sind. Der Unterschied liegt darin, wann das Risiko in das System eingeführt wird:

  • Option A reduziert die frühzeitige Exposition. Da vor der Genehmigung kein Code generiert wird, überprüfen Prüfer zuerst die Absicht. Dadurch werden unnötige oder unsichere Änderungen minimiert und in Umgebungen mit hohem Risiko bevorzugt (z. B. Produktionssysteme oder sicherheitsrelevante Bereiche).

  • Option B führt zu einer früheren Exposition gegenüber Veränderungen. Code wird in der PR angezeigt, bevor der Plan vollständig überprüft wird. Obwohl dieser Code ohne Genehmigung nicht zusammengeführt werden kann, kann er folgende Aufgaben ausführen:

    • unnötige oder falsche Änderungen einführen, die überprüft und abgelehnt werden müssen

    • Erhöhen des Prüferaufwands

    • vorübergehende Diskrepanz zwischen Planung und Umsetzung erzeugen

Wichtig ist, dass dieses Risiko während der Vorschlagsphase besteht, nicht nach der Zusammenführung. GitHub Erzwingungsmechanismen verhindern weiterhin, dass unsicherer Code bereitgestellt wird.

Wann jede Option verwendet werden soll

  • Plan-first-Workflow verwenden, wenn:

    • Änderungen sind mit hohem Risiko oder schwierig umzukehren

    • Ausrichtung auf Absicht ist vor der Ausführung von entscheidender Bedeutung

    • Sie möchten eine strikte Trennung zwischen Planung und Umsetzung

  • Verwenden Sie den Plan- und Ausführungsworkflow in folgenden Fällen:

    • Geschwindigkeit und Iteration sind wichtiger

    • Änderungen sind risikoarm oder leicht umkehrbar

    • Prüfer sind mit der Gemeinsamen Bewertung von Plan und Code vertraut

Wichtige Kernpunkte

Die Wahl besteht nicht darin, ob die Arbeit überprüft wird – sie wird es immer. Die Wahl ist, wenn das System das Generieren von Code relativ zur menschlichen Validierung zulässt und wie früh Sie Änderungen in den Workflow einführen möchten.

Erzwingen von Planungsgrenzen mithilfe von Kapazitätsbeschränkungen und Tool-Gating

  1. Funktionsgrenze (Planungs-Agenten sind schreibgeschützt). Ein Planungs-Agent soll auf schreibgeschützte Tools beschränkt sein, sodass Dateien während der Planung nicht geändert werden können.
  2. Expliziter Übergang (oder Übergabe) zu einem Implementierungs-Agent. Die Ausführung sollte erst nach der Plangenehmigung erfolgen, wobei eine absichtliche Übergabe erfolgt.
  3. Tool-Gating in Orchestratoren in automatisierten Orchestrierungen: Die Planung kann ohne Tool-Ausführung erzwungen werden. Tools werden erst aktiviert, nachdem der Plan angenommen wurde.
  4. „Planmodus”-Workflows – Einige Schnittstellen unterstützen eine erste Planungserfahrung, die ein Planartefakt generiert und dann angehalten wird, bevor Änderungen angewendet werden.

Entscheidungsleitfaden

  • Verwenden Sie den Plan zuerst für arbeit mit hohem Risiko (Workflows, Infrastruktur, Authentifizierung, Produktion).

  • Verwenden Sie Plan + Ausführung für Arbeiten mit mittlerem/niedrigem Risiko, aber stellen Sie sicher, dass die Überprüfungen beibehalten werden.

  • „Bearbeitungshinweise” als Leitlinien behandeln. Tool-Positivlisten und Gateways als Erzwingung. behandeln.

Wichtige Erkenntnis: Trennung schafft eine Möglichkeit, die Absicht zu überprüfen, bevor Sie Auswirkungen akzeptieren.

Als Nächstes erzwingen Sie die Sichtbarkeit und Validierung des Plans durch Genehmigungsschleusen für Pull-Anfragen.