Separat planering, resonemang och utförande
I den här lektionen får du lära dig:
Därför kan du förbättra tillförlitligheten genom att separera planering, körning och validering
Förstå skillnaden mellan arbetsflöden för planering först och planering + utförande
Så här upprätthåller du planeringsgränser med hjälp av kapacitetsgränser och verktygshantering
Varför separation förbättrar tillförlitligheten
Tillförlitliga agentsystem är separata:
Planering: vad som kommer att göras och varför.
Utförande: de konkreta ändringar som gjorts i förvaret.
Validering: bevis för att resultatet uppfyller framgångskriterierna.
När planering och exekvering kombineras ser granskarna bara det slutliga diffet. De förlorar möjligheten att validera avsikten tidigt, upptäcker missförstånd snabbt och kontrollerar omfånget före påverkan.
Hur separation relaterar till GitHub
GitHub stöder naturligtvis denna separation:
Planering visas i en PR-beskrivning, en ärendekommentare eller en Github/pull_request_template.md-artefakt.
Körningen visas som commit på en branch.
Valideringen visas som kontroller, skanningar, artefakterna och granskningsresultaten.
Förstå skillnaden mellan ett arbetsflöde där planering kommer först och ett arbetsflöde som kombinerar planering och genomförande
När du arbetar med agenter måste teamen bestämma när en plan blir synlig och när kodändringar tillåts börja. I GitHub kan planering och körning börja från olika startpunkter, till exempel ett GitHub problem (till exempel tilldela en Copilot Molnagent) eller via fliken Agenter där en plan genereras interaktivt.
Det här är separata sätt att interagera med agenten, men de konvergerar på samma styrningsmodell: allt arbete till slut visas och granskas i en pull request (PR)
Det viktigaste designvalet är därför inte var planen startar, utan när mänsklig validering krävs i förhållande till kodändringar.
Alternativ A: Planera första pull-begäran
I den här metoden slutförs planeringen och godkänns innan några kodändringar introduceras.
Så här fungerar det i praktiken:
En plan genereras (till exempel genom att tilldela en agent till ett GitHub problem eller skapa den på fliken Agenter).
Agenten öppnar en pull-begäran som endast innehåller planen (inga kodändringar ännu).
Granskare diskuterar, förfinar och godkänner planen direkt i PR.
Efter godkännandet fortsätter agenten att implementera planen i uppföljande commits eller en ny PR.
Detta skapar en tydlig separation mellan avsikt (plan) och körning (kod).
Alternativ B: Planering + exekvering i samma pull request
I den här metoden kombineras planering och körning inom en enda PR.
Så här fungerar det i praktiken:
Agenten öppnar en PR som innehåller båda:
en strukturerad plan (i beskrivningen)
inledande kodändringar (incheckningar)
Agenten kan fortsätta att uppdatera PR när planen utvecklas.
Standard GitHub-kontroller, CODEOWNERS-granskningar och grenskydd förhindrar sammanslagning tills alla krav har uppfyllts.
Här är planen fortfarande synlig, men den visas tillsammans med aktiva ändringar i stället för före dem.
Nyckelskillnad: Tidsinställning för validering
Båda alternativen använder samma GitHub kontroller. Skillnaden är när dessa kontroller tillämpas i förhållande till utförandet:
Alternativ A (planera först): Mänsklig validering sker innan någon kod skrivs.
Alternativ B (plan + körning): Kod genereras omedelbart, men verifiering krävs fortfarande innan sammanfogning.
Risköverväganden
Båda metoderna kan vara säkra när GitHub skydd är korrekt konfigurerade. Skillnaden ligger i när risken införs i systemet:
Alternativ A minskar tidig exponering. Eftersom ingen kod genereras före godkännandet verifierar granskarna avsikten först. Detta minimerar onödiga eller osäkra ändringar och föredras i högriskmiljöer (till exempel produktionssystem eller säkerhetskänsliga områden).
Alternativ B introducerar tidigare exponering för förändring. Koden visas i PR innan planen verifieras fullständigt. Även om den här koden inte kan sammanfogas utan godkännande kan den:
införa onödiga eller felaktiga ändringar som måste granskas och avvisas
öka granskarens arbete
skapa tillfällig feljustering mellan plan och implementering
Det är viktigt att den här risken finns under förslagsfasen, inte efter sammanslagning. GitHub tvingande mekanismer förhindrar fortfarande att osäker kod distribueras.
När du ska använda varje alternativ
Använd Plan-first-arbetsflöde när:
ändringar är högrisk eller svåra att vända
Överenskommelse om avsikt är avgörande innan genomförande
du vill ha en strikt uppdelning mellan planering och implementering
Använd arbetsflödet Plan och Körning när:
hastighet och iteration är viktigare
ändringar är låg riskfyllda eller lätt reversibla
granskare är bekväma med att utvärdera planen och koda tillsammans
Viktig insikt
Valet är inte om arbetet granskas– det är det alltid. Valet är när systemet tillåter att kod genereras i förhållande till mänsklig validering och hur tidigt du vill införa ändringar i arbetsflödet.
Framtvinga planeringsgränser med hjälp av kapacitetsbegränsningar och verktyg
- Kapacitetsgräns (planeringsagenter är skrivskyddade) En planeringsagent bör begränsas till skrivskyddade verktyg så att den inte kan ändra filer under planeringen.
- Explicit övergång (eller överlämning) till en implementeringsagent. Genomförandet bör endast ske efter godkännande av planen, med hjälp av ett planerat överlämnande.
- Du kan använda verktygshantering i orkestratorer under automatiserade orkestrationer, där du kan tvinga planeringen att köras utan verktygskörning och sedan aktivera verktyg först när planen har godkänts.
- Arbetsflöden för planläge – Vissa gränssnitt stöder en planeringsupplevelse som genererar en planartefakt och pausar innan några ändringar tillämpas.
Beslutsvägledning
Använd plan-first för högriskarbete (arbetsflöden, infrastruktur, autentisering, produktion).
Använd plan + utförande för medel-/lågriskarbete, men se till att behåll kontroller/granskningar som krävs.
Behandla "instruktioner om att inte redigera" som vägledning; behandla verktygslistor för tillåtelse och kontroller som framtvingande.
Viktig takeaway: Separation skapar en möjlighet att granska avsikten innan påverkan accepteras.
Därefter säkerställer du plansynlighet och validering genom godkännandesteg för pull-begäranden.