Afzonderlijke planning, redenering en uitvoering

In deze les leert u het volgende:

• Waarom het scheiden van planning, uitvoering en validatie de betrouwbaarheid verbetert

• Inzicht in het verschil tussen een plan-first en een plan + uitvoeringswerkstroom.

• Planningsgrenzen afdwingen met behulp van capabiliteitslimieten en tooltoegang.

Waarom scheiding de betrouwbaarheid verbetert

Betrouwbare agentsystemen scheiden zich:

• Planning: wat zal er gebeuren en waarom.

• Uitvoering: de concrete wijzigingen in de opslagplaats.

• Validatie: bewijs dat het resultaat voldoet aan succescriteria.

Wanneer de planning en uitvoering worden gecombineerd, zien revisoren alleen de laatste verschillen. Ze verliezen de mogelijkheid om intentie vroeg te valideren, misverstanden snel te detecteren en het bereik te beheersen voordat het invloed heeft.

Hoe vertaling van scheiding naar GitHub plaatsvindt

GitHub ondersteunt natuurlijk deze scheiding:

• Planning wordt weergegeven in een pr-beschrijving, een opmerking over problemen of een Github/pull_request_template.md-artefact.

• Uitvoering wordt weergegeven als doorvoeringen in een vertakking.

• Validatie verschijnt als controles, scans, artefacten en beoordelingsresultaten.

Inzicht in het verschil tussen een plan-first werkstroom en een werkstroom voor plan en uitvoering

Wanneer u met agents werkt, moeten teams bepalen wanneer een plan zichtbaar wordt en wanneer codewijzigingen mogen beginnen. In GitHub kan planning en uitvoering beginnen vanaf verschillende toegangspunten, zoals een GitHub probleem (bijvoorbeeld het toewijzen van een Copilot Cloud Agent) of via het tabblad Agents waar een plan interactief wordt gegenereerd.

Dit zijn afzonderlijke manieren om met de agent te communiceren, maar ze convergeren op hetzelfde governancemodel: uiteindelijk wordt al het werk weergegeven en beoordeeld in een pull-aanvraag (PR)

De belangrijkste ontwerpkeuze is dus niet waar het plan begint, maar wanneer menselijke validatie vereist is ten opzichte van codewijzigingen.

Optie A: Plan-first pull-aanvraag

In deze benadering wordt de planning voltooid en goedgekeurd voordat er codewijzigingen worden geïntroduceerd.

Hoe het werkt in de praktijk:

• Er wordt een plan gegenereerd (bijvoorbeeld door een agent toe te wijzen aan een GitHub probleem of het maken ervan op het tabblad Agents).

• De agent opent een pull-aanvraag die alleen het plan bevat (nog geen codewijzigingen).

• Revisoren bespreken, verfijnen en goedkeuren het plan rechtstreeks in de pull-aanvraag.

• Na goedkeuring gaat de agent over tot het implementeren van het plan in vervolgcommits of een nieuwe pull request.

Hiermee maakt u een duidelijke scheiding tussen intentie (plan) en uitvoering (code).

Optie B: Plannen en uitvoeren in dezelfde pull-aanvraag

In deze aanpak worden planning en uitvoering gecombineerd binnen één pull request.

Hoe het werkt in de praktijk:

• De agent opent een pull-verzoek waarin beide elementen zijn opgenomen:

  • een gestructureerd plan (in de beschrijving)

  • initiële codewijzigingen (doorvoeringen)

• De agent kan de pull request blijven bijwerken terwijl het plan zich verder ontwikkelt.

• Standaard GitHub-controles, CODEOWNERS-beoordelingen en vertakkingbescherming voorkomen samenvoegen totdat aan alle vereisten is voldaan.

Hier is het plan nog steeds zichtbaar, maar het wordt naast actieve wijzigingen weergegeven in plaats van vóór ze.

Belangrijk verschil: Timing van validatie

Beide opties gebruiken dezelfde GitHub besturingselementen. Het verschil is wanneer deze besturingselementen worden toegepast ten opzichte van de uitvoering:

• Optie A (plan-first): Menselijke validatie vindt plaats voordat code wordt geschreven.

• Optie B (Plan + uitvoering): Code wordt onmiddellijk gegenereerd, maar de validatie is nog steeds vereist voordat de samenvoegbewerking wordt uitgevoerd.

Risicooverwegingen

Beide methoden kunnen veilig zijn wanneer GitHub beveiliging correct is geconfigureerd. Het verschil ligt in wanneer risico's in het systeem worden geïntroduceerd:

• Optie A vermindert vroege blootstelling. Omdat er vóór goedkeuring geen code wordt gegenereerd, valideren revisoren eerst de intentie. Dit minimaliseert onnodige of onveilige wijzigingen en heeft de voorkeur in omgevingen met een hoog risico (bijvoorbeeld productiesystemen of beveiligingsgevoelige gebieden).

• Optie B introduceert vroegere blootstelling aan verandering. Code wordt weergegeven in de pull-aanvraag voordat het plan volledig wordt gevalideerd. Hoewel deze code niet kan worden samengevoegd zonder goedkeuring, kan deze het volgende doen:

  • onnodige of onjuiste wijzigingen introduceren die moeten worden beoordeeld en afgewezen

  • de inspanning van de beoordelaar verhogen

  • tijdelijke misalignment tussen plan en implementatie creëren

Belangrijk is dat dit risico bestaat tijdens de voorstelfase, niet na de samenvoeging. de afdwingingsmechanismen van GitHub verhinderen nog steeds dat onveilige code wordt geïmplementeerd.

Wanneer moet u elke optie gebruiken

• Gebruik de werkstroom Plan-first wanneer:

  • wijzigingen zijn hoog risico of moeilijk om te keren

  • afstemming op intentie is essentieel voordat de uitvoering wordt uitgevoerd

  • u strikte scheiding tussen planning en implementatie wilt

• Gebruik de werkstroom Plannen en uitvoeren wanneer:

  • snelheid en iteratie zijn belangrijker

  • wijzigingen zijn laag risico of gemakkelijk omkeerbaar

  • revisoren zijn vertrouwd met het evalueren van het plan en de code samen

Belangrijkste bevinding

De keuze is niet of het werk wordt beoordeeld - dat wordt het altijd. De keuze is wanneer het systeem toestaat dat code wordt gegenereerd ten opzichte van menselijke validatie en hoe vroeg u wijzigingen in de werkstroom wilt introduceren.

Planningsgrenzen afdwingen met behulp van capaciteitslimieten en tool gating

1. Capabiliteitsgrens (planningsagenten zijn alleen-lezen) Een planningsagent moet zich beperken tot alleen-lezen tools, zodat hij geen bestanden kan wijzigen tijdens de planning.
2. Expliciete overgang (of overdracht) naar een implementatieagent. Uitvoering moet pas plaatsvinden na goedkeuring van het plan, met behulp van een opzettelijke overdracht.
3. Tool gating in orchestrators in geautomatiseerde orkestraties, kunt u afdwingen dat de planning wordt uitgevoerd zonder tool-uitvoering en vervolgens de tools pas inschakelen nadat het plan is geaccepteerd.
4. Werkstromen 'Planmodus': sommige interfaces ondersteunen een planning-first-ervaring die een planartefact genereert en pauzeert voordat wijzigingen worden toegepast.

Richtlijnen voor beslissingen

• Plan-first gebruiken voor werk met een hoog risico (werkstromen, infra, verificatie, productie).

• Gebruik plan en uitvoering voor werk met gemiddeld/laag risico, maar houd controles/beoordelingen noodzakelijk.

• "instructies die niet moeten worden bewerkt" behandelen als richtlijn; allowlists en poorten van hulpprogramma's behandelen als afdwinging.

Belangrijke leerpunten: Scheiding creëert een mogelijkheid om de intentie te controleren voordat de impact wordt geaccepteerd.

Vervolgens dwingt u zichtbaarheid en validatie van plannen af via goedkeuringspoorten voor pull-aanvragen.