Kör agenter parallellt

Den här guiden visar hur du kör flera agenter samtidigt utan att de skriver över varandra.

Isoleringsenheten är ytan, inte agenten

När arbete startar i en yta etablerar Control Center en copy-on-write-utcheckning per registrerat repo under ytans egen rot, på en gren som härleds från arbetsytans mall för grenamn. Varje agent i ytan får sedan en egen arbetskatalog i sitt överlägg — men överläggen delar ytans repos/-katalog.

Alltså:

Två agenter i olika ytor arbetar i olika utcheckningar, på olika grenar. Det är riktig isolering.
Två agenter i samma yta arbetar i samma utcheckning, på samma gren. Deras överläggsvägar skiljer sig åt, så dispatchens sökvägslås (som bara serialiserar körningar när de begär exakt samma arbetskatalog) serialiserar dem inte heller. De kan skriva samma filer samtidigt.

Regeln som följer: en yta per parallell uppgift.

Kör uppgifter parallellt — separata ytor

Öppna en yta med agent A och skicka en uppgift till den.
Öppna en andra yta med agent B och skicka en annan uppgift till den.
Båda skickas ut direkt, var och en i sin egen ytas utcheckning på sin egen gren.

Använd det här receptet när agenterna ska redigera filer.

Samarbeta i en yta — flera omnämnanden

I en och samma yta kan du @-nämna fler än en agent:

@alice refactor the auth module. @bob review what alice lands.

Båda agenterna skickas ut parallellt och strömmar in i samma yta, märkta med avsändare. Eftersom de delar ytans utcheckning använder du det här för samarbete — en som skriver, en som läser, eller två agenter som resonerar om samma träd — inte för två oberoende redigeringar.

Utskick från en pipeline

Den inbyggda mallen pr_review är det medföljande exemplet på ett utskick: flera granskarnoder körs samtidigt från en enda trigger och en Consolidate (join)-nod samlar deras fynd i en rapport. Kör den från pipelines-skärmen så skickas varje granskare ut parallellt.

Pipelineeditorn döljer terminalmarkören och kopplar om den så att den väntar på varje aktiv mottagarnod när du lägger till eller ansluter ett steg, så grenar du ritar själv körs faktiskt.

Se dem köra

Observability → Live (sidofältets sidfot → Observability, sedan fliken Live) visar arbetsytans agentlista och uppdateras varje sekund: status (körs / overksam / parkerad / avbruten), vad var och en gör, tokens och kostnad för dess senaste körning samt en kontroll för att avsluta en körande process. Att välja en rad fäster en panel med livetranskriptet.

Inställningar → Arbetsyta → Agenter visar samma lista med en annan statusvokabulär där uppmärksamhet går först, härledd ur varje agents körningshistorik — körs, blockerad, misslyckades, overksam, aldrig körd — sorterad så att allt som kräver uppmärksamhet flyter uppåt. Varje agents flik Loggar innehåller dess egen körningshistorik.

Båda vyerna gäller bara den aktiva arbetsytan.

Hantera konflikter

Mellan ytor ligger varje yta på sin egen gren, så en kollision visar sig som en vanlig Git-mergekonflikt när du slår ihop den andra pull requesten. Lös den som du skulle lösa vilken mergekonflikt som helst.

Inom en och samma yta finns ingen grengräns och inget lås: agenterna skriver samma filer live och den som förlorar skrivs helt enkelt över. Om du kommer på att du vill att två agenter ska redigera i en yta, dela upp arbetet i två ytor i stället.

För att minska kollisioner i båda fallen:

Ge varje agent ett eget område — olika filer, olika moduler.
Använd kodgrafen för att kontrollera vad en ändring rör innan du skickar ut. Se Sök kod med kodgrafen.
Granska och slå ihop varje agents pull request i tid.

Resursöverväganden

Varje körande agent kostar:

En utcheckning per yta — försumbar på disken så länge copy-on-write är tillgängligt; på Windows en git worktree. Om filsystemet inte kan reflinka misslyckas etableringen i stället för att kopiera.
En process på servervärden
Modelltokens, som ackumuleras per agent

Kostnaderna hamnar i Observability → Insikter. Observera att en vanlig interaktiv tur inte har någon utgiftsgräns; se Hantera kostnader för de två kommandon som har det.