Agentroller

Coroid använder inte en enda agent för alla ändamål. Varje steg i vägen från beskrivning till pull request hanteras av en agent med ett avgränsat uppdrag och en medvetet begränsad uppsättning verktyg.

Begränsningarna är själva poängen. En agent som inte kan skriva kod kan inte råka skriva kod.

Rollerna#

Roll	Steg	Kan ändra din kod
Arkitekt	Specifikation och plan	Nej
Utvecklare	Bygg	Ja
QA	Verifiering	Nej
Granskare	Granskning	Nej
Webbtestare	Verifiering, webbläsarflöden	Nej
Utforskare	Research, valfritt steg	Nej
Beroendeanalytiker	Analys	Nej

De första fyra är leveransagenterna du ser i varje uppgift. I standardläget körs de i den här ordningen:

Arkitekt → Utvecklare → QA → Granskare

I samordnarläget beslutar en samordnare om ordningen medan uppgiften pågår. Båda beskrivs nedan.

Exakt en roll – utvecklaren – kan ändra filer i din källkod. Alla andra agenter läser, kör, rapporterar eller skapar uppföljningsarbete.

Två sätt att köra en uppgift#

En uppgift körs i ett av två lägen. Dess Profil för AI och din driftsättning avgör vilket läge som används.

Läge med samordnare. Arkitekten lämnar inte över sin plan och går vidare. Den stannar kvar i uppgiften som samordnare. Efter planeringen ger samordnaren utvecklaren instruktioner och väntar på rapporten. Sedan ber den QA att verifiera det som byggts och granskaren att granska det som QA har godkänt. Efter varje rapport avgör samordnaren vad som ska hända härnäst: skicka tillbaka iakttagelserna till utvecklaren, besvara en fråga, revidera planen eller slutföra uppgiften. Omarbete är ytterligare ett steg för samordnaren, inte en ny körning.

Standardläge. Plattformen tar uppgiften genom de fyra agenterna i en fast ordning, och om en kontroll misslyckas skickas uppgiften tillbaka till utvecklaren. En del arbete utförs alltid på det här sättet, till exempel att lösa en mergekonflikt, och standardläget används som reserv när läget med samordnare inte är tillgängligt.

I båda lägena utför samma agenter arbetet, med samma begränsningar och kontrollpunkter. Det som skiljer sig är vem som väljer nästa steg: plattformen i standardläget, samordnaren i läget med samordnare.

Samordnaren#

Samordnaren är planeringsagenten som stannar kvar i uppgiften. Den läser din källkod men kan inte ändra den, så allt den gör handlar om att styra arbetet.

Vad samordnaren gör#

• Planerar. Samordnaren utforskar repot och sparar sedan planen med acceptanskriterierna som avgör om arbetet lyckades.
• Delegerar. Samordnaren arbetar med en agent i taget. Instruktionerna anger målet, eventuella acceptanskriterier som behöver extra uppmärksamhet och, när arbetet skickas tillbaka, exakt vad som ska rättas. Medan agenten arbetar väntar samordnaren och använder ingen modelltid.
• Besvarar frågor. Om en agent behöver fatta ett beslut kan den fråga samordnaren. Samordnaren svarar med beslutet och motiveringen. Frågan lämnas inte obesvarad i väntan på en person.
• Agerar. Om QA underkänner arbetet eller granskaren begär ändringar skickar samordnaren rättningarna till utvecklaren, och QA verifierar den nya versionen.
• Avslutar uppgiften. Samordnaren slutför uppgiften eller underkänner den och förklarar varför.

Vad samordnaren inte kan göra#

Samordnaren styr, men gör ingen bedömning. Plattformen upprätthåller de här begränsningarna, så de beror inte på samordnarens beslut:

1. QA och granskaren ansvarar för bedömningarna. Endast QA och granskaren gör bedömningar, var och en genom sitt eget resultat. Samordnarens instruktioner innehåller inget utrymme för en bedömning, och samordnaren kan inte markera en kontroll som godkänd.
2. Uppgiften slutförs först när alla spärrar är passerade. En uppgift kan slutföras först när QA har godkänt exakt den version som ska levereras (eller koden som den ser ut, om inget ändras) och, när uppgiften kräver granskning, granskaren har godkänt den versionen. Om branchen ändras efter att QA har kört sina kontroller nekas slutförandet, och den nya versionen skickas tillbaka till QA.
3. Omarbete har tydliga gränser. Varje agent kan startas ett begränsat antal gånger per uppgift, och en plan kan bara revideras några gånger. Även antalet steg och den totala körtiden är begränsade. När en gräns nås kan samordnaren bara slutföra eller misslyckas med uppgiften.
4. Väntetiden är begränsad. Varje väntan har en tidsgräns.

En uppgift som styrs av en samordnare slutar alltså på ett av tre sätt: en pull request som du kan godkänna; QA:s bekräftelse på att koden redan gör det uppgiften kräver, så inget behöver ändras; eller en misslyckad uppgift som förklarar varför. Den slutar inte för att agenten som ansvarar för den har förklarat den klar.

Vägar samordnaren kan välja#

Samordnaren väljer hur uppgiften tar sig fram till kontrollpunkterna. Kontrollpunkterna ovan är desamma på alla vägar.

• Hela flödet. Planera, bygga, verifiera, granska, slutföra. Så här körs en uppgift om inte samordnaren har en anledning att välja en annan väg.
• Skicka tillbaka arbetet. När QA underkänner arbetet eller granskaren ber om ändringar skickas korrigeringarna tillbaka till utvecklaren. Den nya versionen måste sedan klara QA innan uppgiften kan slutföras. Ett godkänt resultat för den tidigare versionen gäller inte för den nya.
• Redan klart. Koden kanske redan gör det uppgiften kräver. Då kan samordnaren låta QA verifiera den oförändrade koden mot acceptanskriterierna i stället för att bygga något. När QA godkänner den och granskaren godkänner den när granskning krävs, slutförs uppgiften utan en pull request, eftersom det inte finns något att sammanfoga. QA:s verifiering är resultatet. Den här vägen stängs när körningen har skapat en egen ändring, e eftersom QA annars skulle godkänna kod som inte är den som levereras.

Två kortare vägar är valfria. Coroid använder dem inte som standard. De ändrar samordnarens väg, aldrig kontrollpunkterna:

• En snabb ändring. För en liten korrigering på en känd plats skriver samordnaren en kortare plan och ger utvecklaren en avgränsad instruktion som anger vilka filer ändringen hör hemma i. Utvecklaren arbetar med en mindre stegbudget, och allt som ändras utanför dessa filer rapporteras till QA och granskaren.
• En mer avgränsad ny kontroll. Efter en mindre korrigering av något som QA eller granskaren har hittat börjar QA med iakttagelsen och projektets tester. QA ger ändå sitt utlåtande om hela den nya versionen.

När granskning krävs#

Som standard går en uppgift som du kör separat alltid genom granskaren. Oavsett vilken väg samordnaren väljer, även när inget behövde ändras, kan uppgiften inte slutföras förrän granskaren har godkänt den version som QA godkände. QA verifierar alltid, med eller utan granskning, och en granskning ersätter aldrig QA:s godkännande. Uppgifter som ingår i en plan följer reglerna för sitt arbetsflöde.

Coroid har också en valfri, riskbaserad policy. Den är inte aktiverad som standard. Enligt den kan en uppgift som du kör separat slutföras utan granskare när ändringen är liten och vanlig. Granskare krävs fortfarande när:

• en granskare redan har börjat granska uppgiften, eller projektets granskningsregler eller organisationens Quality Graph kräver det;
• ändringen berör autentisering, sessioner, behörigheter, hemligheter eller kryptografi, databasmigreringar, konfiguration för bygge och driftsättning, beroendefiler eller kod som kommunicerar med externa tjänster;
• ändringen är stor (som standard innebär det mer än 80 ändrade rader) eller innehåller binärfiler, symboliska länkar eller submoduler;
• Coroid kan inte läsa policyn eller själva ändringen. Om du är osäker krävs en granskare.

En ändring som inte ändrar något behöver aldrig granskas. Koden fattar det här beslutet, inte samordnaren, och samordnaren kan inte prata sig förbi det. En rad i slutet av beskrivningen av pull request anger vilket beslut som fattades och varför. Den börjar med "Granskning krävs" eller "Granskning krävs inte".

Arkitekt#

Omvandlar din beskrivning till en specifikation och specifikationen till en plan. Agenten läser källkoden för att förankra planen i det som faktiskt finns, men skriver ingen kod.

Resultatet är det du godkänner innan bygget startar. I samordnarläget fortsätter agenten sedan som samordnare.

Utvecklare#

Utför arbetet: läser relevant kod, gör ändringen, skriver eller uppdaterar tester och kör dem lokalt i arbetsytan tills de passerar.

När Granskare skickar tillbaka iakttagelser är det Utvecklaren som åtgärdar dem. I samordnarläget vidarebefordrar samordnaren iakttagelserna tillsammans med de ändringar som behöver göras.

QA#

Kör verifiering oberoende av agenten som skrev koden: din testsvit, projektets konfigurerade kvalitetsgrindar och acceptanskriterierna i specifikationen.

QA rapporterar ett utlåtande. QA åtgärdar inte det som hittas; fel skickas tillbaka till Utvecklaren för omarbete.

Granskare#

Läser den färdiga diffen och sammanställer iakttagelser enligt de granskningsregler som organisationen har konfigurerat. Iakttagelser skickas antingen tillbaka till utvecklaren för omarbete eller bifogas till din pull request.

Webbtestare#

Använder en riktig webbläsare mot en körande förhandsversion av din app för att testa användarflöden från början till slut. Används när ett påstående om beteende inte kan fastställas enbart utifrån koden.

Utforskare#

En skrivskyddad roll för research. Andra agenter använder den för att få svar på frågor om en källkod utan att läsa in allt i sin egen kontext – ”var hanteras autentisering”, ”vad anropar den här funktionen”.

Beroendeanalytiker#

Undersöker beroenden och hur ändringar får följdeffekter i en källkod, även mellan projekt när beroenden mellan projekt har konfigurerats.

Därför spelar uppdelningen roll#

Fyra egenskaper följer av att arbetet delas upp på det här sättet:

1. Verifieringen är oberoende. Agenten som kontrollerar arbetet är inte agenten som skrev det och har därför inget egenintresse i resultatet.
2. Konsekvenserna är begränsade. Endast utvecklarrollen har verktyg för att skriva kod, så ett misslyckande i granskning eller analys kan inte skada ditt repo.
3. Varje roll använder en modell som passar för den. Planering gynnas av breda världskunskaper; att skriva kod som kompilerar kräver något helt annat. En Profil för AI har en modell per roll, just av det skälet.
4. Det är kontrollerna, inte agenten med ansvaret, som avgör när arbetet är klart. I läget med samordnare kan agenten som styr arbetet inte avsluta det utan utlåtanden från QA och granskaren.

Nästa#

Tillbaka till Så blir en uppgift till en pull request för stegen som de här rollerna motsvarar, eller Vad är Coroid för en kortare översikt.