Kieruj workerami w tle

Ten poradnik pokazuje, jak prowadzić rozmowę jako dyrektor, a nie jako worker: sesja czyta i weryfikuje, a edycją zajmują się agenci działający w tle.

Co się zmienia, gdy wpisujesz /vibe

Dwie rzeczy, i tylko pierwsza jest egzekwowana przez mechanizm:

1. Własne narzędzia sesji zostają ograniczone do tylko do odczytu, plus pięć czasowników workera. Jedyny sposób, w jaki sesja może wpłynąć na repozytorium, to worker, a jedyny sposób, w jaki może się dowiedzieć, co się stało, to odczytanie plików, których worker dotknął.
2. Dostaje polecenie weryfikowania przez czytanie, a nie przez wiarę. Raport workera to twierdzenie o tym, co zrobił, a nie dowód, że zadziałało.

To pierwsze jest kluczowe. Dyrektor, który wciąż może greppować i edytować, pod presją wykona tę pracę sam — a to właśnie tryb awarii, któremu to rozwiązanie ma zapobiegać.

/vibe migrate the auth module to the new session API

Workery zaczynają od zera

Worker nigdy nie widział Twojej rozmowy i nigdy jej nie zobaczy. Zlecenie to cały jego kontekst.

To właśnie czyni ten wzorzec tanim — dwadzieścia workerów, z których każdy trzymałby historię dyrektora, kosztowałoby dwadzieścia razy więcej kontekstu niż sam dyrektor — i to zarazem jedyna rzecz, przez którą zlecenia trudno się pisze. „A teraz zrób też to drugie” brzmi dla dyrektora jak kompletne polecenie, a dla świeżej sesji jak nic.

Dobre zlecenie wymienia pliki, polecenia i definicję ukończenia:

W lib/features/auth/ zastąp każde wywołanie SessionStore.read(key) wywołaniem SessionStore.get(key). Nowa metoda zwraca Future<String?>, a stara zwracała String?, więc wywołujący potrzebują await. Po zakończeniu uruchom fvm flutter analyze lib/features/auth i zgłoś błędy, których nie udało Ci się poprawić.

Pięć czasowników

Czasownik	Co robi
vibe_spawn	Uruchamia workera na podstawie zlecenia. Zwraca wynik natychmiast.
vibe_list	Poziom, status, czas i ostatni wynik dla wszystkich
vibe_send	Kolejna tura dla workera, który zakończył pracę
vibe_wait	Blokuje, aż jeden worker zakończy pracę
vibe_kill	Zatrzymuje jednego

Uruchamianie workerów jest asynchroniczne z założenia. Dyrektor, który blokuje się przy każdym uruchomieniu, wykonuje pracę workerów pojedynczo, czyli w wolniejszy sposób robi to, co i tak robiłby sam. Używaj vibe_wait tylko wtedy, gdy naprawdę nie możesz kontynuować bez konkretnej odpowiedzi.

Dwa poziomy

Poziom	Dla
fast	Praca mechaniczna o jasnej specyfikacji — edycje, zmiany nazw, szkice, uruchamianie poleceń
good	Projektowanie, osąd albo recenzowanie tego, co wytworzył worker fast

Częsty schemat to rozdzielenie workerów fast po niezależnych plikach, a potem uruchomienie jednego workera good, który zrecenzuje ich wspólny wynik.

Weryfikowanie

To jest ta część, która decyduje, czy ten wzorzec jest czegokolwiek wart.

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

Następnie odczytaj pliki, które wymienił. Dyrektor ma read, search, lsp i ast_grep; po to je zachowano. Dyrektor, który przyjmuje raport za dobrą monetę, jest streszczaczem optymizmu innych agentów.

lsp(action: "diagnostics", file: "*") po rundzie workerów to zwykle najszybsza pojedyncza kontrola.

Gdy worker traci wątek

Zabij go i przygotuj nowe zlecenie. Świeże, poprawione zlecenie jest tańsze niż sprzeczka, a vibe_send działa tylko na workerze, który już zakończył swoją turę.

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

Ograniczenia

• Osiem równoczesnych workerów. Pułap wydatków, a nie limit techniczny: każdy z nich to pełna sesja modelu, a dyrektor, który rozdziela pracę na dwudziestu, przestaje śledzić, co wszyscy robią.
• Żaden worker nie przeżyje trybu. Gdy uruchomienie się kończy, każdy z nich zostaje zatrzymany, a zapis rozmowy podaje, ilu ich było. Agent działający w tle, który wciąż edytuje pliki po tym, jak rozmowa poszła dalej, to jedyna awaria, do jakiej nie może tu dojść.
• Pod spodem workery to zwykli podagenci. Ten sam limit głębokości, ta sama polityka guardraili, ten sam podrzędny dziennik uruchomienia. Vibe zmienia to, kto nimi kieruje, a nie to, na co im wolno — więc prośby o zatwierdzenie nadal pojawiają się przy wywołaniach zapisu i exec workera.

Kiedy tego nie używać

Tryb vibe służy do pracy, którą można rozłożyć na niezależne zlecenia. Jeśli następny krok zależy od wyniku poprzedniego, opisujesz potok albo orkiestrację, a oba wyrażają zależności w należyty sposób, zamiast kazać dyrektorowi symulować je za pomocą vibe_wait.

Powiązane

• Uruchamiaj agentów równolegle — inne sposoby rozdzielania pracy
• Orkiestracja — gdy praca ma swój kształt
• Wbudowane narzędzia agentów — czasowniki i ich argumenty