Özet
Yapay zekâ ajan sürüleri (AI agent swarms), tek bir hedefi üç role böler: işi görevlere ayıran bir planlayıcı (planner), bu görevleri yalıtılmış çalışma alanlarında paralel olarak geliştiren çalışanlar (workers) ve her değişikliği geçerli sayılmadan önce test eden doğrulayıcılar (verifiers). Planlayıcı ve doğrulayıcı için en güçlü modelinizi, çalışanlar içinse daha ucuz ve daha hızlı olanları kullanırsınız. Çalışanlar aynı dosyaları paylaştığında, doğrulayıcılar işi körü körüne onayladığında veya maliyetlere kimse bir üst sınır koymadığında bu model çöker.
Yapay zekâ ajan sürüleri neden yeniden gündemde?
Google, Gemini 4 Carbon sürümünü genel kullanıma sundu ve tek bir istemi (prompt) koordineli bir ajan ekibine dönüştüren Google Antigravity içindeki /swarm özelliğini önizlemeye açtı. Google’ın ifadesiyle Carbon; “paralel yalıtılmış çalışma alanlarında çalışan daha hızlı ve hafif modeller ile her değişikliği test eden çekişmeli (adversarial) doğrulayıcılarla” eşleştirilerek “mimari tasarım, koordinasyon ve denetimi” üstleniyor.
Bu cümle, hâlihazırda sahip olduğunuz modellerle de uygulayabileceğiniz bir mimari modeli tanımlıyor. Bu rehberde üç temel rolü, bütçenin neden planlama ve doğrulamaya ayrılması gerektiğini, sürülerin nerede aksadığını ve ortak bir pano üzerinde bir sürünün nasıl yönetileceğini ele alıyoruz. Zaten birden fazla kodlama ajanı çalıştırıyorsanız Sharkly her birine bir Görev (Task), bir çalıştırma günlüğü ve bir inceleme adımı sunar; bu da bir sürünün ihtiyaç duyduğu altyapının büyük kısmını karşılar.
Yapay zekâ ajan sürüsü nedir?
Yapay zekâ ajan sürüsü (AI agent swarm), tek bir hedefi bağımsız görevlere bölerek bunlar üzerinde eş zamanlı çalışan bir yapay zekâ ajanları grubudur. Bir ajan işi planlayıp atar, birden fazla ajan işi paralel olarak yürütür ve bir veya daha fazla ajan her sonucu ana dala birleştirmeden önce kontrol eder. Her rolün net ve sınırlı bir görevi ile belirgin bir devir teslim süreci vardır.
Anthropic, 2024 yılında bu yapıyı orkestratör-çalışan modeli (orchestrator-workers pattern) olarak tanımlamıştı: Merkezi bir model görevi alt parçalara ayırır, bu parçaları devreder ve sonuçları birleştirir. Doğrulayıcı ise yapıya sonradan eklenen ve çoğu ekibin atladığı en yeni roldür.
Bir sürü, “aynı işi yapan çok sayıda ajan” demek değildir. Aynı kod deposu (repository) üzerinde aynı istemle çalışan beş ajan bir takım değil, yalnızca bir yarış durumu (race condition) yaratır. Bir yapıyı sürü yapan şey rollerin ayrımıdır. Ajanların nasıl koordine edildiğine dair daha kapsamlı bir bakış için yapay zekâ ajan orkestrasyonunun ne olduğunu inceleyebilirsiniz.
Üç temel rol: Planlayıcı, çalışanlar ve doğrulayıcılar
Her rol farklı bir soruya yanıt verir ve her birinin farklı bir bağlama (context) ihtiyacı vardır.
| Rol | Yanıtladığı soru | Tipik model | Okur | Yazar |
|---|---|---|---|---|
| Planlayıcı | Parçalar neler ve her birini kim yapacak? | Mevcut en güçlü model | Hedef, kod tabanı haritası | Görev listesi, kabul kriterleri |
| Çalışan | Bu tek parçayı nasıl inşa ederim? | Daha ucuz, daha hızlı | Tek bir görev, ilgili dosyaları | Kendi çalışma alanında bir diff |
| Doğrulayıcı | Bu değişiklik görevde belirtilen işi yapıyor mu? | Mevcut en güçlü model | Görev, diff, test çıktıları | Onay veya gerekçeli bir ret |
Planlayıcı ne yapar?
Planlayıcı, ucu açık bir hedefi birbiriyle çakışmayan somut görevlere dönüştürür. İyi bir plan; her bir görevin değiştirebileceği dosyaları, görevin tamamlandığını kanıtlayan testi ve bir görevin diğerine bağımlı olduğu durumdaki işlem sırasını belirler. İki görevin aynı dosyaya ihtiyacı varsa planlayıcı bunları tek bir görevde birleştirir veya sırayla çalıştırır.
Çalışanlar ne yapar?
Çalışanlar, paralel olarak yalnızca kendilerine verilen tek bir görevi inşa eder; başka hiçbir şeye karışmazlar. Her çalışana genellikle bir git worktree şeklinde kendi çalışma alanı verilir: bu, aynı kod deposunun kendi dalı (branch) üzerinde ayrı bir kopyasıdır. Üç çalışanın birbirinin yazdıklarının üzerine yazmadan aynı anda kod düzenlemesini sağlayan şey işte bu yalıtımdır. Ayrıntılar için yalıtılmış worktree'lerde paralel ajanlar yazısına göz atabilirsiniz.
Doğrulayıcılar ne yapar?
Doğrulayıcılar yapılan bir değişikliğin hatalı olduğunu kanıtlamaya çalışır. Google’ın kullandığı “çekişmeli” (adversarial) ifadesi tam da buna uygundur: Doğrulayıcı testleri çalıştırır, göreve kıyasla diff'i inceler ve çalışanın kolaya kaçıp kaçmadığını araştırır. Yalnızca “testler geçiyor mu?” diye soran bir doğrulayıcı, testleri geçsin diye değiştiren bir kodlama ajanını gözden kaçıracaktır.
Pahalı model neden planlama ve denetim yapar?
Planlama ve doğrulama, yüksek risk taşıyan ancak kısa okumalardan ibarettir. Kod inşa etmek ise satır başına riski düşük, fakat uzun çıktılar gerektiren bir süreçtir. Hangi modelin nerede konumlandırılacağını belirleyen de bu asimetridir.
Planlayıcı birkaç yüz satırlık görev tanımı yazar. Doğrulayıcı ise bir karar metni üretir. İkisi de fazla çıktı üretmediğinden, token başına yüksek maliyet genel toplamda pek bir ağırlık oluşturmaz. Token'ların büyük kısmını çalışanlar ürettiği için, o aşamada ucuz modeller kullanmak en büyük tasarrufu sağlar.
Hataların yarattığı etki de aynı ölçekte değildir. Kötü bir plan tüm çalışanları yanlış yönlendirir; özensiz bir doğrulayıcı ise her hatalı değişikliği onaylar. Zayıf bir çalışan yalnızca tek bir hatalı diff üretir ve bunu da doğrulayıcı yakalar. Muhakeme gücünüzü, hatanın katlanarak büyüdüğü noktalara ayırın.
Google’ın kendi konumlandırması da bu ayrımı destekliyor. Şirket, Gemini 4 Argon’un “yazılım mühendisliği ve bilgi odaklı çalışmaların büyük bölümü için ideal tercih olmayı sürdürdüğünü” belirtirken Carbon’un “kapsamlı keşif yapmak, derinlemesine akıl yürütmek ve genişletilmiş doğrulama döngüleri çalıştırmak” için daha fazla token kullandığını ifade ediyor. Carbon, 30 Kasım 2026’ya kadar bir milyon girdi token’ı için 2 dolar ve bir milyon çıktı token’ı için 10 dolar; sonrasında ise 4 dolar ve 20 dolar olarak ücretlendiriliyor. Model ayrıntıları için kodlama ajanları için Gemini 4 Carbon ve kodlama ajanları için Gemini 4 Argon yazılarını okuyabilirsiniz. Aynı mantık tüm model eşleşmeleri için geçerlidir; ayrıntılar için ucuz çalışanlar ve pahalı denetçiden oluşan karma modelli Ekipler (Crews) içeriğine bakabilirsiniz.
Yapay zekâ ajan sürüleri nerede başarısız olur?
Sürü başarısızlıklarının çoğu üç temel eksikten kaynaklanır: paylaşılan durum (shared state), yetersiz kontroller ve bütçe sınırının olmaması.
Ajanlar neden birbirlerinin yazdıklarının üzerine yazar?
İki çalışan aynı dosyayı düzenler, çünkü planda bunu yapamayacakları belirtilmemiştir. Yalıtılmış çalışma alanları olmadığında son yazan kazanır ve ilk çalışanın yaptığı değişiklik kaybolur. Yalıtım olduğunda ise her iki değişiklik de birleştirme (merge) anına kadar korunur ve orada çakışma çıkar. Çözüm planda gizlidir: Görev başına dosya sahipliği atayın ve aynı dosyaları paylaşan görevleri sıraya koyun.
Doğrulayıcılar neden incelemeden onay verir?
Diff yerine çalışanın hazırladığı özeti okuyan bir doğrulayıcı, yapılan işi değil, sadece bir iddiayı değerlendirir. “Tüm testler geçti” ifadesini görür ve onaylar. Doğrulayıcıya çalışanın kendi raporunu asla vermeyin; yalnızca ham diff'i ve test çıktılarını iletin. Ayrıca çalışanların kör noktalarını paylaşmaması için doğrulayıcıyı çalışanlardan farklı bir modelde çalıştırın. Yapay zekâ kod inceleme ajanları yazısı, inceleme yapan bir ajanın neleri doğrulayıp neleri doğrulayamayacağını ele alıyor.
Sürü maliyetleri nasıl kontrolden çıkar?
Her ret, yeni bir geliştirme ve yeni bir inceleme döngüsünü tetikler; dolayısıyla üç kez başarısız olan bir görev, her iki aşamanın da dörder kez tekrarlanmasına mal olur. Bir gecede ret döngüsüne giren on çalışan, bir haftalık bütçeyi tüketebilir. Görev başına yeniden deneme sayısına üst sınır getirin (iki makul bir varsayılandır), eş zamanlı çalışan sayısını sınırlayın ve son deneme de başarısız olduğunda görevi bir insana yönlendirin.
Dördüncü bir başarısızlık sebebi de diğerlerinin altında gizlidir: Plan, çalıştırmalar ve kararlar tek bir bağlam penceresinde (context window) bulunuyorsa sonucu kimse denetleyemez. Sürünün dışındaki birinin süreci yine de izlemesi gerekir.
Ortak bir panoda yapay zekâ ajan sürüsü nasıl çalıştırılır?
Bir sürü çalıştırmak için özel bir sürü aracına ihtiyacınız yoktur. İhtiyacınız olan şeyler görevler, yalıtılmış çalışma alanları ve bir onay kapısıdır (gate). Ortak bir pano bu üçünü de sunar ve tüm kayıtları insanların rahatça inceleyebileceği bir yerde tutar.
- Hedef için tek bir ana görev (parent task) oluşturun. Planlayıcı bunu okur ve her biri kendi dosyalarına ve kabul testine sahip alt görevler hâlinde planı çıkarır.
- Her çalışana tam olarak bir görev verin. Bir görev, bir ajan, bir dal (branch). İki alt görev aynı dosyayı paylaşıyorsa kimse işe başlamadan önce bunları birleştirin.
- Her görevi kendi dizininde çalıştırın. Çalıştırma başına bir worktree kullanmak, paralel düzenlemeleri birbirinden ayrı tutar.
- Done (Tamamlandı) aşamasından önce bir Review (İnceleme) durumu ekleyin. Hiçbir görev yalnızca çalışanın beyanına güvenilerek Done durumuna geçirilemez.
- İncelemeyi daha güçlü bir modeldeki bir doğrulayıcı ajana atayın. Bu ajan diff'i ve test çıktılarını inceler, ardından görevi onaylar veya bir gerekçe belirterek geri gönderir.
- Son adıma bir insan yerleştirin. Doğrulayıcı listeyi daraltır; nihai sonucu ise bir insan onaylar.
Bunun Sharkly’deki karşılığı şöyledir: Bir Ekip (Crew), tek bir lider Ajan tarafından koordine edilen, İnsanlar ve Ajanlardan oluşan yeniden kullanılabilir bir gruptur. Ana Görevi (Task) Ekibe atadığınızda önce lider başlar: Görevi okur, ardından belirli parçalar için üye Ajanları devreye sokar ve sonuçları birleştirir. Liderin öncelikli olduğu bu işleyiş, plan hazır olmadan hiçbir çalışanın işe başlamamasını sağlar.
Geçici çalışma dizini modundaki (working-directory mode) Ajanlar, Görev başına yalıtılmış bir dizin alır ve kod deposu tabanlı çalıştırmalar yeni bir worktree hazırlayabilir; böylece paralel çalışanlar aynı dosyaları paylaşmaz. Her Ajan yapılandırdığınız Çalışma Zamanı (Runtime) üzerinde çalışır; bu sayede lider ve incelemeci, çalışanlara kıyasla daha güçlü bir modelde görev alabilir.
İnceleme kapısı, Görev iş akışınızdaki bir durumdur. Bir Ajan, bir Görevi insan incelemesi bekleyecek şekilde bırakabilir ve Ajan görev yürütme belgelerinde açıklandığı gibi bu devir işlemi ana kenar çubuğundaki Görev Sohbetleri (Task Chats) modülünde görünür. Başarısız olan veya engellenen çalıştırmalar yine Gelen Kutusu'na (Inbox) düşer. Ajanlar araştırır, yürütür, test eder ve raporlar. İnsanlar yönü belirler, yetki verir ve sonucu onaylar. Sharkly'yi kullanmaya başlamak ücretsizdir: Tek bir Bilgisayar bağlayın, iki Ajan oluşturun ve bir Ekibe küçük bir görev atayın. İnsan faktörü hakkında daha fazla bilgi için paralel ajanlar için inceleme süreçlerini tasarlama yazısını okuyabilirsiniz.
Yapay zekâ ajan sürüsüne ne zaman ihtiyacınız olmaz?
İş parçalara ayrılamıyorsa sürü modelini atlayın. Tek bir hata düzeltmesi, tek dosyalık bir yeniden düzenleme (refactoring) veya uzun bir mantıksal akıl yürütme zinciri; tek bir güçlü ajan ve tek bir incelemeciyle daha hızlı tamamlanır. Üçten az bağımsız görev söz konusu olduğunda, koordinasyon maliyeti genellikle paralelliğin sağlayacağı kazançtan daha yüksek olur.
Hedef farklı dosyalara dokunan parçalara ayrılabiliyorsa sürü kullanın: çok paketli bir geçiş (multi-package migration), modüller arası geriye dönük test yazımı (test backfill) veya on farklı servise uygulanan tek bir API değişikliği gibi. Google, çoklu ajan kurgularında Carbon'un başarıyla yürüttüğü işler arasında “çok paketli geçişleri” ve “alt sistemler arası kök neden araştırmalarını” sayıyor.
Sonuç
Bir yapay zekâ ajan sürüsü devasa tek bir istemden ibaret değildir; üç ayrı işten oluşur: planla, inşa et, doğrula. En iyi modelinizi plan ve karar için, ekonomik modelleri inşa süreci için kullanın ve her sonucu bir insanın inceleyebileceği bir yerde tutun. İşe bir ana görev, üç çalışan ve bir doğrulayıcı ile başlayın. Bu yapıyı hâlihazırda kullandığınız ajanlarla çalıştırmak için Sharkly platformuna bir Bilgisayar bağlayın ve ilk Ekibinizi atayın.
Sıkça Sorulan Sorular
Ajan sürüsü ile çoklu ajan orkestrasyonu arasındaki fark nedir?
Orkestrasyon, birden fazla ajanı koordine etmeye yönelik genel uygulamanın adıdır. Sürü ise belirli rollere sahip bir orkestrasyon modelidir: bir planlayıcı, paralel çalışanlar ve doğrulayıcılar. Her sürü orkestre edilir; ancak her orkestrasyon bir sürü değildir.
Bir yapay zekâ ajan sürüsünde kaç ajan olmalıdır?
Bir planlayıcı, üç çalışan ve bir doğrulayıcıyla başlayın. Yalnızca görevler bağımsız kaldığı ve inceleme kuyruğunuz tempoya ayak uydurabildiği sürece yeni çalışanlar ekleyin. İncelenebilecek sonuç sayısından daha fazla çalışan eklemek, darboğazı yalnızca doğrulayıcıya taşır.
Planlayıcı ve doğrulayıcı aynı ajan olabilir mi?
Aynı modeli paylaşabilirler ancak bunları ayrı bağlamlara (context) sahip farklı çalıştırmalar olarak tutun. Kendi planının çıktısını inceleyen bir planlayıcı bunu onaylama eğilimindedir. Sıfır bağlamlı bağımsız bir doğrulayıcı ise diff'i planlayıcının önyargıları olmadan inceler.
Ajan sürüsü çalıştırmak için Google Antigravity'ye ihtiyacım var mı?
Hayır. /swarm, Antigravity içindeki bir önizleme özelliğidir; ancak bu modelin çalışması için yalnızca görev bölme, yalıtılmış çalışma alanları ve bir inceleme adımı gerekir. Bunu git worktree'leri ve bir pano kullanarak, hâlihazırda kullandığınız herhangi bir kodlama ajanıyla kurabilirsiniz.
Sürü çalışanlarının aynı dosyayı düzenlemesini ne engeller?
Plan, görevlerin birbiriyle çakışmaması için dosya sahipliklerini tanımlar; yalıtılmış çalışma alanları da birleştirme (merge) aşamasına kadar her çalışanın düzenlemesini kendi dalında tutar. Bir CODEOWNERS kuralı ise inceleme anında ek bir kontrol katmanı sağlar.
