Ajanları paralel çalıştırma

Bu kılavuz, birkaç ajanı birbirlerinin üzerine yazmadan aynı anda nasıl çalıştıracağınızı gösterir.

Yalıtımın birimi ajan değil, alandır

Bir alanda iş başladığında Control Center, o alanın kendi kökü altında, kayıtlı her depo için çalışma alanının dal şablonundan türetilen bir dal üzerinde bir copy-on-write checkout hazırlar. Alandaki her ajan daha sonra kendi overlay çalışma dizinini alır — ama overlay’ler o alanın repos/ dizinini paylaşır.

Yani:

Farklı alanlardaki iki ajan, farklı checkout’larda, farklı dallarda çalışır. Gerçek yalıtım budur.
Aynı alandaki iki ajan, aynı checkout’ta, aynı dalda çalışır. Overlay yolları farklı olduğundan, gönderim yolu kilidi (çalıştırmaları yalnızca özdeş çalışma dizinini istediklerinde sıraya sokan) onları da sıraya sokmaz. Aynı dosyalara aynı anda yazabilirler.

Bundan çıkan kural: her paralel görev için bir alan.

Görevleri paralel çalıştırma — ayrı alanlar

A ajanıyla bir alan açın ve ona bir görev gönderin.
B ajanıyla ikinci bir alan açın ve ona farklı bir görev gönderin.
İkisi de hemen gönderilir; her biri kendi alan checkout’unda, kendi dalında çalışır.

Ajanlar dosya düzenleyecekse her zaman bu tarifi kullanın.

Tek alanda birlikte çalışma — birden çok anma

Tek bir alanda birden fazla ajanı @ ile anın:

@alice refactor the auth module. @bob review what alice lands.

İki ajan da paralel gönderilir ve gönderene göre etiketlenerek aynı alana akar. Alanın checkout’unu paylaştıkları için bunu işbirliği amacıyla kullanın — biri yazarken diğeri okurken ya da iki ajan aynı ağaç üzerinde akıl yürütürken — birbirinden bağımsız iki düzenleme için değil.

Bir pipeline’dan yelpaze şeklinde dağıtma

Yerleşik pr_review şablonu, bir fan-out’un ürünle birlikte gelen örneğidir: tek bir tetikleyiciyle birkaç inceleyici düğümü eşzamanlı çalışır ve bir Consolidate (join) düğümü bulgularını tek bir raporda toplar. Bunu pipeline’lar ekranından çalıştırın; her inceleyici paralel gönderilir.

Pipeline düzenleyici, terminal nöbetçisini gizler ve bir adım eklediğinizde ya da bağladığınızda onu her canlı çıkışı bekleyecek şekilde yeniden bağlar; böylece kendi çizdiğiniz dallar gerçekten çalışır.

Çalışmalarını izleme

Gözlemlenebilirlik → Canlı (kenar çubuğunun alt kısmı → Gözlemlenebilirlik, ardından Canlı sekmesi) bu çalışma alanının ajan kadrosunu gösterir ve her saniye yenilenir: durum (Çalışıyor / Boşta / Park edildi / İptal edildi), her birinin ne yaptığı, son çalıştırmasının token’ları ve maliyeti, ayrıca çalışan bir süreç için bir sonlandırma denetimi. Bir satır seçmek canlı bir transkript çekmecesini yerleştirir.

Ayarlar → Çalışma alanı → Ajanlar aynı kadroyu, her ajanın çalıştırma geçmişinden türetilen farklı, dikkat öncelikli bir durum dağarcığıyla gösterir — Çalışıyor, Engellendi, Başarısız, Boşta, Henüz çalıştırma yok — ilgi gerektiren her şey en üste çıkacak şekilde sıralanır. Her ajanın Loglar sekmesi kendi çalıştırma geçmişini barındırır.

Her iki yüzey de etkin çalışma alanıyla sınırlıdır.

Çakışmaları ele alma

Alanlar arasında her alan kendi dalındadır; bu yüzden ikinci pull request’i birleştirdiğinizde çarpışma sıradan bir Git birleştirme çakışması olarak ortaya çıkar. Onu, herhangi bir birleştirme çakışmasını çözer gibi çözün.

Tek bir alanın içinde ne bir dal sınırı ne de bir kilit vardır: ajanlar aynı dosyalara canlı canlı yazar ve kaybedenin üzerine basitçe yazılır. İki ajanın tek bir alanda düzenleme yapmasını istediğinizi fark ederseniz, işi bunun yerine iki alana bölün.

Her iki durumda da çarpışmaları azaltmak için:

Her ajana belirgin bir kapsam verin — farklı dosyalar, farklı modüller.
Göndermeden önce bir değişikliğin nelere dokunduğunu kod grafiğiyle kontrol edin. Bkz. Kod grafiğiyle kod arama.
Her ajanın pull request’ini zamanında inceleyip birleştirin.

Kaynak değerlendirmeleri

Çalışan her ajan şunlara mal olur:

Bir alan checkout’u — copy-on-write kullanılabilirken diskte ihmal edilebilir; Windows’ta bir git worktree. reflink yapamayan bir dosya sistemi, kopyalamak yerine hazırlığı başarısız kılar.
Sunucu ana makinesinde bir süreç
Ajan başına biriken model token’ları

Maliyetler Gözlemlenebilirlik → İçgörüler altında birikir. Normal bir etkileşimli turun harcama üst sınırı olmadığını unutmayın; üst sınırı olan iki komut için bkz. Maliyetleri yönetme.