Styr bakgrundsworkers

Den här guiden visar hur du kör ett samtal som regissör i stället för som worker: sessionen läser och verifierar, och bakgrundsagenter gör redigeringarna.

Vad som ändras när du skriver /vibe

Två saker, och bara den första framtvingas av maskineriet:

1. Sessionens egna verktyg degraderas till skrivskyddat, plus fem verb för att styra workers. Det enda sättet den kan påverka repot på är genom en worker, och det enda sättet den kan veta vad som hände är att läsa filerna som en worker rörde.
2. Den får instruktionen att verifiera genom att läsa, inte genom att tro. En workers rapport är ett påstående om vad den gjorde, inte bevis för att det fungerade.

Det första är det som bär. En regissör som fortfarande kan söka och redigera kommer att göra jobbet själv under press, och det är precis det felläget som det här finns för att förhindra.

/vibe migrate the auth module to the new session API

Workers börjar tomma

En worker har aldrig sett ditt samtal och kommer aldrig att göra det. Briefen är hela dess kontext.

Det är det som håller mönstret billigt – tjugo workers som var och en bär regissörens historik skulle kosta tjugo gånger regissörens kontext – och det är också det som gör briefar svåra att skriva. ”Gör den andra också nu” är en komplett instruktion för regissören och ingenting alls för en färsk session.

En bra brief namnger filer, kommandon och definitionen av klart:

I lib/features/auth/, ersätt varje anrop till SessionStore.read(key) med SessionStore.get(key). Den nya metoden returnerar Future<String?> där den gamla returnerade String?, så anropare behöver await. Kör fvm flutter analyze lib/features/auth när du är klar och rapportera alla fel du inte kunde åtgärda.

De fem verben

Verb	Vad det gör
vibe_spawn	Startar en worker på en brief. Återvänder omedelbart.
vibe_list	Nivå, status, förfluten tid och senaste resultat för alla
vibe_send	En uppföljande tur för en worker som har avslutat
vibe_wait	Blockerar tills en worker blir klar
vibe_kill	Stoppar en

Spawnandet är asynkront, och det är meningen. En regissör som blockerar vid varje spawn kör workers en i taget, vilket är ett långsammare sätt att göra det den redan gjorde själv. Använd vibe_wait bara när du verkligen inte kan gå vidare utan ett specifikt svar.

Två nivåer

Nivå	För
fast	Mekaniskt arbete med en tydlig specifikation – redigeringar, namnbyten, utkast, köra kommandon
good	Design, omdöme eller granskning av det en fast-worker har producerat

Ett vanligt upplägg är att sprida ut fast-workers över oberoende filer och sedan spawna en good-worker som granskar vad de gjorde tillsammans.

Verifiering

Det här är delen som avgör om mönstret är värt något.

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

Läs sedan filerna den namngav. Regissören har read, search, lsp och ast_grep; det är hela poängen med att behålla dem. En regissör som tar rapporten för vad den säger är en sammanfattare av andra agenters optimism.

lsp(action: "diagnostics", file: "*") efter en omgång workers är oftast den snabbaste enskilda kontrollen.

När en worker tappar tråden

Döda den och brieffa om. En färsk, korrigerad brief är billigare än en diskussion, och vibe_send fungerar bara på en worker som redan har avslutat sin tur.

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

Gränser

• Åtta samtidiga workers. Ett tak för kostnaden, inte en teknisk gräns: var och en är en full modelsession, och en regissör som sprider ut tjugo har slutat hålla koll på vad de alla gör.
• Ingen worker överlever läget. När körningen tar slut stoppas var och en av dem, och transkriptet anger hur många. En bakgrundsagent som fortfarande redigerar filer efter att samtalet har gått vidare är det enda felet som inte får inträffa här.
• Under huven är workers vanliga subagenter. Samma djupgräns, samma policy för räcken, samma underordnade körningslogg. Vibe ändrar vem som driver dem, inte vad de får göra – så godkännandeförfrågningar visas fortfarande för en workers skriv- och exec-anrop.

När du inte ska använda det

Vibe-läget är för arbete som delas upp i oberoende briefar. Om nästa steg beror på föregående stegs utdata beskriver du en pipeline eller en orkestrering, och båda uttrycker beroenden ordentligt i stället för att låta regissören simulera dem med vibe_wait.

Relaterat

• Kör agenter parallellt — de andra sätten att sprida ut arbetet
• Orkestrering — när arbetet har en form
• Inbyggda agentverktyg — verben och deras argument