Styr bakgrunnsworkere

Denne veiledningen viser deg hvordan du kjører en samtale som regissør i stedet for som worker: økten leser og verifiserer, og bakgrunnsagenter gjør redigeringene.

Hva som endres når du skriver /vibe

To ting, og bare den første håndheves av maskineriet:

1. Øktens egne verktøy nedgraderes til skrivebeskyttet, i tillegg til fem worker-verb. Den eneste måten den kan påvirke repoet på, er gjennom en worker, og den eneste måten den kan vite hva som skjedde på, er ved å lese filene en worker har berørt.
2. Den får beskjed om å verifisere ved å lese, ikke ved å tro. En workers rapport er en påstand om hva den gjorde, ikke et bevis på at det virket.

Den første er den bærende. En regissør som fortsatt kan bruke grep og redigere, vil gjøre arbeidet selv under press, og det er nettopp feilmodusen dette finnes for å forhindre.

/vibe migrate the auth module to the new session API

Workere starter tomme

En worker har aldri sett samtalen din og kommer aldri til å gjøre det. Oppdragsbeskrivelsen er hele konteksten dens.

Det er dette som gjør mønsteret billig — tjue workere som hver bærer på regissørens historikk, ville koste tjue ganger regissørens kontekst — og det er samtidig det som gjør oppdragsbeskrivelser vanskelige å skrive. «Nå gjør du den andre også» leser som en fullstendig instruks for regissøren og som ingenting for en fersk økt.

En god oppdragsbeskrivelse navngir filer, kommandoer og definisjonen på ferdig:

I lib/features/auth/ skal du erstatte hvert kall til SessionStore.read(key) med SessionStore.get(key). Den nye metoden returnerer Future<String?> der den gamle returnerte String?, så kallere trenger await. Kjør fvm flutter analyze lib/features/auth når du er ferdig, og rapporter eventuelle feil du ikke klarte å rette.

De fem verbene

Verb	Hva det gjør
vibe_spawn	Starter en worker på en oppdragsbeskrivelse. Returnerer umiddelbart.
vibe_list	Nivå, status, medgått tid og siste resultat for alle
vibe_send	En oppfølgende runde for en worker som er ferdig
vibe_wait	Blokkerer til én worker er ferdig
vibe_kill	Stopper én

Å starte workere er asynkront av design. En regissør som blokkerer ved hver oppstart, kjører workere én om gangen, som er en langsommere måte å gjøre det den allerede gjorde selv på. Bruk vibe_wait bare når du virkelig ikke kan komme videre uten et bestemt svar.

To nivåer

Nivå	For
fast	Mekanisk arbeid med en klar spesifikasjon — redigeringer, omdøpinger, utkast, kjøring av kommandoer
good	Design, skjønn eller gjennomgang av det en fast-worker har produsert

En vanlig form er å spre fast-workere utover uavhengige filer og deretter starte én good-worker som går gjennom det de gjorde samlet.

Verifisering

Dette er delen som avgjør om mønsteret er verdt noe i det hele tatt.

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

Les så filene den navnga. Regissøren har read, search, lsp og ast_grep; det er hele poenget med å beholde dem. En regissør som tar rapporten for god fisk, er en oppsummerer av andre agenters optimisme.

lsp(action: "diagnostics", file: "*") etter en runde med workere er vanligvis den raskeste enkeltkontrollen.

Når en worker mister tråden

Drep den og skriv en ny oppdragsbeskrivelse. En fersk, korrigert oppdragsbeskrivelse er billigere enn en diskusjon, og vibe_send virker bare på en worker som allerede har fullført runden sin.

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

Grenser

• Åtte samtidige workere. Et tak på forbruket, ikke en teknisk grense: hver av dem er en full modelløkt, og en regissør som sprer ut tjue, har sluttet å følge med på hva de alle gjør.
• Ingen worker overlever modusen. Når kjøringen avsluttes, stoppes hver og én av dem, og transkripsjonen sier hvor mange. En bakgrunnsagent som fortsatt redigerer filer etter at samtalen har gått videre, er den ene feilen dette ikke kan ha.
• Workere er vanlige underagenter under panseret. Samme dybdegrense, samme tillatelsesregler, samme barn i kjøringsloggen. Vibe endrer hvem som driver dem, ikke hva de har lov til å gjøre — så godkjenningsforespørsler dukker fortsatt opp for en workers skrive- og eksekveringskall.

Når du ikke bør bruke det

Vibe-modus er for arbeid som lar seg dele opp i uavhengige oppdragsbeskrivelser. Hvis neste steg avhenger av forrige stegs utdata, beskriver du en pipeline eller en orkestrering, og begge uttrykker avhengigheter på riktig måte i stedet for å la regissøren simulere dem med vibe_wait.

Se også

• Kjør agenter parallelt — de andre måtene å fordele arbeid på
• Orkestrering — når arbeidet har en form
• Innebygde agentverktøy — verbene og argumentene deres