Arka plan worker’larını yönetme

Bu kılavuz, bir konuşmayı worker olarak değil bir yönlendirici olarak nasıl yürüteceğinizi gösterir: oturum okur ve doğrular, düzenlemeleri ise arka plan ajanları yapar.

/vibe yazdığınızda ne değişir

İki şey değişir ve bunlardan yalnızca ilki mekanizma tarafından uygulanır:

1. Oturumun kendi araçları salt okunura düşer, artı beş worker fiili. Depoyu etkileyebilmesinin tek yolu bir worker üzerindendir ve ne olduğunu öğrenebilmesinin tek yolu da bir worker’ın dokunduğu dosyaları okumasıdır.
2. Ona inanarak değil, okuyarak doğrulaması söylenir. Bir worker’ın raporu, ne yaptığına dair bir iddiadır; işe yaradığının kanıtı değildir.

Asıl yükü taşıyan ilkidir. Hâlâ grep yapabilen ve düzenleme yapabilen bir yönlendirici, baskı altında işi kendisi yapar; bu, bu desenin önlemek için var olduğu başarısızlık modudur.

/vibe migrate the auth module to the new session API

Worker’lar boş başlar

Bir worker konuşmanızı hiç görmedi ve hiçbir zaman da görmeyecek. Brifing onun tüm bağlamıdır.

Deseni ucuz tutan şey budur — yönlendiricinin geçmişini taşıyan yirmi worker, yönlendiricinin bağlamının yirmi katına mal olurdu — ve aynı zamanda brifing yazmayı zorlaştıran tek şeydir. “Şimdi diğerini de yap” ifadesi yönlendirici için eksiksiz bir talimat gibi, yepyeni bir oturum içinse hiçbir şey ifade etmez.

İyi bir brifing dosyaları, komutları ve tamamlanma tanımını adlandırır:

lib/features/auth/ içinde, SessionStore.read(key) çağrılarının her birini SessionStore.get(key) ile değiştirin. Yeni yöntem Future<String?> döndürürken eskisi String? döndürüyordu, bu yüzden çağıranların await kullanması gerekiyor. Bitirdiğinizde fvm flutter analyze lib/features/auth çalıştırın ve düzeltemediğiniz hataları bildirin.

Beş fiil

Fiil	Ne yapar
vibe_spawn	Bir worker’ı bir brifingle başlatır. Hemen döner.
vibe_list	Herkes için kademe, durum, geçen süre ve son sonuç
vibe_send	Turunu bitirmiş bir worker için bir takip turu
vibe_wait	Bir worker sonuçlanana kadar bekler
vibe_kill	Birini durdurur

Başlatma tasarım gereği asenkron. Her başlatmada bloke olan bir yönlendirici, worker’ları tek tek çalıştırıyordur; bu da zaten kendi yaptığı işi daha yavaş yapmanın bir yoludur. vibe_wait komutunu yalnızca belirli bir yanıt olmadan gerçekten ilerleyemediğinizde kullanın.

İki kademe

Kademe	Şunun için
fast	Net bir tanımlamaya sahip mekanik iş — düzenlemeler, yeniden adlandırmalar, taslaklar, komut çalıştırma
good	Tasarım, muhakeme ya da bir fast worker’ın ürettiğini inceleme

Yaygın bir biçim, fast worker’ları birbirinden bağımsız dosyalara dağıtmak ve ardından toplu olarak yaptıklarını incelemek için bir good worker başlatmaktır.

Doğrulama

Desenin bir işe yarayıp yaramadığını belirleyen kısım burasıdır.

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

Ardından adlandırdığı dosyaları okuyun. Yönlendiricinin elinde read, search, lsp ve ast_grep var; bunları tutmanın bütün amacı bu. Raporu olduğu gibi kabul eden bir yönlendirici, diğer ajanların iyimserliğini özetleyen bir özetleyicidir.

Bir worker turundan sonra lsp(action: "diagnostics", file: "*") genellikle en hızlı tek kontrolüdür.

Bir worker ipin ucunu kaçırdığında

Onu durdurun ve yeniden brifing verin. Yeni ve düzeltilmiş bir brifing, bir tartışmadan daha ucuza gelir; vibe_send ise yalnızca turunu çoktan bitirmiş bir worker üzerinde çalışır.

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

Sınırlar

• Sekiz eşzamanlı worker. Bu bir harcama tavanıdır, teknik bir sınır değil: her biri tam bir model oturumudur ve yirmi tanesini dağıtan bir yönlendirici, hepsinin ne yaptığını takip etmeyi bırakmıştır.
• Hiçbir worker moddan daha uzun yaşamaz. Çalıştırma bittiğinde hepsi durdurulur ve transkript kaç tane olduğunu söyler. Konuşma ilerledikten sonra hâlâ dosya düzenleyen bir arka plan ajanı, bunun asla yaşayamayacağı tek arızadır.
• Worker’lar altta sıradan alt ajanlardır. Aynı derinlik sınırı, aynı koruma politikası, aynı çalıştırma günlüğü alt kaydı. Vibe, onları kimin sürdüğünü değiştirir, ne yapmalarına izin verildiğini değil — bu yüzden bir worker’ın write ve exec çağrıları için yine de onay istemleri görünür.

Ne zaman kullanmamalı

Vibe modu, bağımsız brifinglere ayrılabilen işler içindir. Sonraki adım bir önceki adımın çıktısına bağlıysa, tarif ettiğiniz şey bir pipeline ya da bir orkestrasyondur; her ikisi de bağımlılıkları düzgün biçimde ifade eder ve yönlendiriciye bunları vibe_wait ile taklit ettirmez.

İlgili

• Ajanları paralel çalıştırma — dağıtmanın diğer yolları
• Orkestrasyon — işin bir biçimi olduğunda
• Yerleşik ajan araçları — fiiller ve argümanları