Hintergrund-Worker steuern

Diese Anleitung zeigt, wie du eine Unterhaltung als Leitung führst statt selbst als Worker zu arbeiten: die Sitzung liest und prüft, Hintergrund-Agenten übernehmen das Bearbeiten.

Was sich ändert, wenn du /vibe eingibst

Zwei Dinge, und nur das Erste setzt die Mechanik durch:

1. Die eigenen Werkzeuge der Sitzung fallen auf Nur-Lesen, plus fünf Worker-Verben. Auf das Repo wirkt sie nur über einen Worker, und was geschehen ist, weiß sie nur, indem sie die Dateien liest, die ein Worker angefasst hat.
2. Die Sitzung soll durch Lesen prüfen, nicht durch Glauben. Der Bericht eines Workers ist eine Behauptung über das, was er getan hat, kein Beleg, dass es funktioniert hat.

Tragend ist das Erste. Eine Leitung, die weiterhin suchen und bearbeiten kann, erledigt die Arbeit unter Druck selbst, und genau diesen Fehlermodus soll das verhindern.

/vibe migrate the auth module to the new session API

Worker starten leer

Ein Worker hat deine Unterhaltung nie gesehen und wird sie nie sehen. Das Briefing ist sein ganzer Kontext.

Genau das hält das Muster billig — zwanzig Worker, die jeweils den Verlauf der Leitung halten, würden das Zwanzigfache ihres Kontexts kosten — und genau das macht Briefings schwer zu schreiben. „Mach jetzt auch das andere“ liest sich für die Leitung als vollständige Anweisung und für eine frische Sitzung als gar nichts.

Ein gutes Briefing nennt Dateien, Befehle und das Kriterium für fertig:

Ersetze in lib/features/auth/ jeden Aufruf von SessionStore.read(key) durch SessionStore.get(key). Die neue Methode liefert Future<String?>, wo die alte String? lieferte, Aufrufer brauchen also await. Führe fvm flutter analyze lib/features/auth aus, wenn du fertig bist, und melde Fehler, die du nicht beheben konntest.

Die fünf Verben

Verb	Wirkung
vibe_spawn	Startet einen Worker mit einem Briefing. Kehrt sofort zurück.
vibe_list	Stufe, Status, verstrichene Zeit und letztes Ergebnis für alle
vibe_send	Ein Folgeturn für einen Worker, der fertig ist
vibe_wait	Blockiert, bis ein Worker abgeschlossen ist
vibe_kill	Beendet einen

Das Starten ist absichtlich asynchron. Eine Leitung, die bei jedem Start blockiert, lässt die Worker nacheinander laufen, also langsamer dasselbe, was sie vorher selbst getan hat. Nimm vibe_wait nur, wenn du ohne eine bestimmte Antwort wirklich nicht weiterkommst.

Zwei Stufen

Stufe	Wofür
fast	Mechanische Arbeit mit klarer Vorgabe — Änderungen, Umbenennungen, Entwürfe, Befehle ausführen
good	Entwurf, Einschätzung oder die Prüfung dessen, was ein fast-Worker erzeugt hat

Üblich ist, fast-Worker über unabhängige Dateien aufzufächern und danach einen good-Worker zu starten, der prüft, was sie zusammen getan haben.

Prüfen

Hier entscheidet sich, ob das Muster etwas taugt.

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

Lies danach die Dateien, die er genannt hat. Die Leitung hat read, search, lsp und ast_grep; genau dafür bleiben sie. Eine Leitung, die den Bericht für bare Münze nimmt, fasst nur den Optimismus anderer Agenten zusammen.

lsp(action: "diagnostics", file: "*") nach einer Runde Worker ist meist die schnellste einzelne Prüfung.

Wenn ein Worker den Faden verliert

Beende ihn und gib ein neues Briefing. Ein frisches, korrigiertes Briefing ist billiger als eine Diskussion, und vibe_send geht nur an einen Worker, der seinen Turn schon beendet hat.

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

Grenzen

• Acht gleichzeitige Worker. Eine Obergrenze für die Kosten, keine technische Grenze: jeder ist eine volle Modellsitzung, und eine Leitung, die zwanzig auffächert, verfolgt nicht mehr, was sie alle tun.
• Kein Worker überlebt den Modus. Endet der Lauf, wird jeder gestoppt, und das Transkript nennt, wie viele. Ein Hintergrund-Agent, der Dateien noch bearbeitet, nachdem die Unterhaltung weitergezogen ist, ist der eine Fehler, den das nicht haben darf.
• Worker sind darunter gewöhnliche Subagenten. Dieselbe Verschachtelungsobergrenze, dieselbe Richtlinie der Schutzregeln, dasselbe Kind im Laufprotokoll. Vibe ändert, wer sie steuert, nicht, was sie dürfen — Freigabeaufforderungen erscheinen also weiter bei Schreib- und Ausführungsaufrufen eines Workers.

Wann er nicht passt

Der Vibe-Modus ist für Arbeit, die sich in unabhängige Briefings zerlegen lässt. Hängt der nächste Schritt am Ergebnis des vorigen, beschreibst du eine Pipeline oder eine Orchestrierung, und beide drücken Abhängigkeiten richtig aus, statt die Leitung sie mit vibe_wait nachzustellen.

Verwandt

• Agenten parallel ausführen – die anderen Wege zum Auffächern
• Orchestrierung – wenn die Arbeit eine Form hat
• Eingebaute Agenten-Tools – die Verben und ihre Argumente