Háttér-workerek irányítása

Ez az útmutató megmutatja, hogyan futtathat egy beszélgetést irányítóként, nem pedig workerként: a munkamenet olvas és ellenőriz, a szerkesztést pedig a háttér-ügynökök végzik.

Mi változik, amikor beírja a /vibe parancsot

Két dolog változik, és ebből csak az elsőt kényszeríti ki a gépezet:

1. A munkamenet saját eszközei csak olvashatóvá válnak, kiegészülve az öt worker-igével. A repóra kizárólag egy workeren keresztül hathat, és csak úgy tudhatja meg, mi történt, ha elolvassa azokat a fájlokat, amelyekhez egy worker hozzányúlt.
2. Arra kap utasítást, hogy ne elhiggye, hanem olvassa el és ellenőrizze. Egy worker jelentése állítás arról, hogy mit tett, nem pedig bizonyíték arra, hogy sikerült.

Az első a döntő. Az az irányító, amelyik még mindig tud grep-elni és szerkeszteni, nyomás alatt maga végzi el a munkát — éppen ez az a hibaeset, amelyet ez az egész hivatott megelőzni.

/vibe migrate the auth module to the new session API

A workerek a nulláról indulnak

Egy worker soha nem látta a beszélgetését, és soha nem is fogja. A feladatkiírás a teljes kontextusa.

Ez tartja olcsón a mintát — húsz worker, amelyek mindegyike az irányító előzményeit hordozná, az irányító kontextusának hússzorosába kerülne —, ugyanakkor ez az egyetlen dolog, ami megnehezíti a feladatkiírások megírását. A „Most csináld meg a másikat is” az irányítónak teljes utasításként hat, egy friss munkamenetnek viszont semmit sem mond.

A jó feladatkiírás megnevezi a fájlokat, a parancsokat és azt, hogy mi számít késznek:

A lib/features/auth/ könyvtárban cserélje le a SessionStore.read(key) minden hívását SessionStore.get(key)-re. Az új metódus Future<String?> értéket ad vissza, ahol a régi String?-t adott vissza, ezért a hívóknak await-re van szükségük. Ha kész, futtassa a fvm flutter analyze lib/features/auth parancsot, és jelentse azokat a hibákat, amelyeket nem tudott kijavítani.

Az öt ige

Ige	Mit tesz
vibe_spawn	Elindít egy workert egy feladatkiírással. Azonnal visszatér.
vibe_list	Minden worker szintje, állapota, eltelt ideje és utolsó eredménye
vibe_send	Egy következő kör egy már befejezett workernek
vibe_wait	Addig blokkol, amíg egy worker be nem fejeződik
vibe_kill	Leállít egyet

Az indítás szándékosan aszinkron. Az az irányító, amelyik minden indításnál blokkol, egyszerre egy workert futtat — ez lassabb módja annak, amit addig is maga végzett. A vibe_wait-et csak akkor használja, ha egy konkrét válasz nélkül valóban nem tud továbblépni.

Két szint

Szint	Mire való
fast	Mechanikus munka világos specifikációval — szerkesztések, átnevezések, vázlatok, parancsok futtatása
good	Tervezés, mérlegelés, vagy egy fast worker kimenetének átnézése

Gyakori minta, hogy fast workereket osztunk szét egymástól független fájlokra, majd indítunk egy good workert, amely átnézi, amit együtt elvégeztek.

Az ellenőrzés

Ez az a rész, amely eldönti, hogy a minta egyáltalán ér-e valamit.

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

Ezután olvassa el azokat a fájlokat, amelyeket megnevezett. Az irányítónak read, search, lsp és ast_grep áll rendelkezésére; éppen ezért tartottuk meg őket. Az az irányító, amelyik készpénznek veszi a jelentést, valójában más ügynökök optimizmusát összegzi.

A lsp(action: "diagnostics", file: "*") egy worker-kör után általában a leggyorsabb egyszeri ellenőrzés.

Amikor egy worker elveszíti a fonalat

Állítsa le, és írjon új feladatkiírást. Egy friss, javított feladatkiírás olcsóbb, mint egy vita, a vibe_send pedig csak olyan workernél működik, amely már befejezte a körét.

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

Korlátok

• Nyolc egyidejű worker. A kiadások felső korlátja, nem technikai megkötés: mindegyik egy teljes modell-munkamenet, és az az irányító, amelyik húszat oszt szét, már nem követi, hogy azok éppen mit csinálnak.
• Egyetlen worker sem éli túl a módot. Amikor a futtatás véget ér, mindegyikük leáll, és az átirat megmondja, hány volt. Az az egyetlen hiba, amit ez nem engedhet meg magának, hogy egy háttér-ügynök még azután is fájlokat szerkeszt, hogy a beszélgetés továbblépett.
• A workerek valójában hétköznapi alügynökök. Ugyanaz a mélységi korlát, ugyanaz a korlátszabályzat, ugyanaz a gyermek a futtatási naplóban. A vibe mód azt változtatja meg, hogy ki vezeti őket, nem azt, hogy mit tehetnek — ezért egy worker írási és exec-hívásainál továbbra is megjelennek a jóváhagyási kérések.

Amikor nem érdemes használni

A vibe mód az olyan munkára való, amely független feladatkiírásokra bontható. Ha a következő lépés az előző lépés kimenetétől függ, akkor valójában pipeline-t vagy orchestrációt ír le, és mindkettő rendesen kifejezi a függőségeket ahelyett, hogy az irányítóval szimuláltatná azokat a vibe_wait segítségével.

Kapcsolódó

• Ügynökök párhuzamos futtatása — a szétosztás további módjai
• Orchestráció — amikor a munkának szerkezete van
• Beépített ügynökeszközök — az igék és argumentumaik