Çoklu Ajan Sistemleri: 15 Kat Token, %90 Kazanç — Hangisi Sizin Durumunuz?

Çoklu ajan mimarisi hakkında iki sağlam mühendislik yazısı var ve ikisi tam ters şey söylüyor gibi görünüyor: biri çoklu ajanın tek ajanı %90 geçtiğini, diğeri çoklu ajan kurmamanız gerektiğini savunuyor. Aslında çelişmiyorlar — farklı iş türlerinden bahsediyorlar. Bu yazı, o uzlaşmayı ve kararı verdirecek sayıları anlatıyor. Türkçe kaynaklarda bu maliyet patlaması hiç sayısallaştırılmamış.

Kazanç tarafındaki sayı#

Anthropic’in çoklu ajan araştırma sistemi üzerine yazdığı mühendislik notu (13 Haziran 2025), bir yönetici-çalışan (orchestrator-worker) kurgusunun iç değerlendirmelerde tek ajanlı Opus 4’ü %90,2 geçtiğini bildiriyor. Etkileyici bir sayı — ama aynı yazının içindeki ikinci bulgu, birincisini yeniden yorumlatıyor:

Performans varyansının %80’ini tek başına token kullanımı açıklıyor.

Yani çoklu ajan mimarisi büyük ölçüde yeterince token harcamayı sağladığı için çalışıyor. Bu, mimariyi değersizleştirmiyor; ama neyi satın aldığınızı netleştiriyor. Aynı işi tek ajanla ve daha yüksek bir bütçeyle yapmak da bir seçenek — ve genellikle daha basit bir seçenek.

Maliyet tarafındaki sayı#

Aynı kaynaktan gelen ikinci sayı, kararın diğer yarısı: tek bir ajan, sıradan bir sohbet etkileşiminin yaklaşık 4 katı token kullanıyor; çoklu ajan sistemi ise yaklaşık 15 katı.

Bu çarpanın pratik anlamını görmek için tabloyu kendi rakamlarınızla doldurun:

Yani çoklu ajana geçmek, aynı işi yaklaşık dört kat pahalıya yapmak demektir (4× → 15×). Bu kararı vermeden önce sorulacak soru şu: bu işte doğruluk, dört kat maliyet farkını haklı çıkaracak kadar değerli mi?

Karşı argüman: neden çoğu iş için yanlış#

Cognition’ın “Don’t Build Multi-Agents” yazısı (12 Haziran 2025) meseleye tamamen farklı bir yerden bakıyor ve teknik argümanı güçlü: alt ajanlar bağımsız çalıştığında, eylemler örtük kararlar taşır ve bu kararlar birbiriyle çelişir.

Verdikleri örnek meseleyi anlatıyor: bir Flappy Bird klonu isteyen görevde bir alt ajan Mario tarzı varlıklar üretirken, diğeri onunla uyuşmayan bir kuş çiziyor. Hiçbir alt ajan hata yapmıyor; yalnızca ikisi de kendi örtük tasarım kararını veriyor ve kimse bu kararları paylaşmıyor.

Buradan çıkan öneri iki maddeli: alt ajanlara yalnızca mesajları değil tam izleri (trace) aktarın — çünkü karar mesajda değil eylemde saklıdır — ve varsayılan mimari olarak tek iş parçacıklı, doğrusal bir ajan artı bağlam sıkıştırma kullanın.

Uzlaşma: tek cümlelik kural#

İki kaynağı yan yana koyunca çelişki kayboluyor. Anthropic’in kazandığı iş türü genişlik odaklı araştırma: birbirinden bağımsız çok sayıda kaynağı paralel taramak. Cognition’ın kaybettiğini gösterdiği iş türü birbirine bağımlı üretim: bir dosyanın diğerini etkilediği kod yazımı.

Çoklu ajan, paralelleştirilebilir ve okuma ağırlıklı işlerde kazanır; birbirine bağımlı ve yazma ağırlıklı işlerde kaybeder.

Anthropic’in kendi yazısı da bunu doğruluyor: paylaşılan bağlam gerektiren, yüksek bağımlılıklı ve paralelleştirilmesi zor alanları kötü uyum olarak listeliyor — ve bu listeye kodlama işlerinin çoğunu açıkça dâhil ediyor.

Hata modları ve maliyet tavanı#

Çoklu ajan kurmaya karar verdiyseniz, bilinen hata modlarını baştan kapatın. Birincil kaynaklarda sayılanlar:

• Aşırı alt ajan üretimi: yönetici, gereğinden fazla çalışan başlatır. Kontrol: sert bir üst sınır.
• Bitmeyen arama: çalışan “yeterli” kavramına sahip değilse aramaya devam eder. Kontrol: adım ve token bütçesi artı açık bir durma ölçütü.
• Yinelenen iş: iki çalışan aynı şeyi yapar. Kontrol: görev tanımlarını çakışmayacak biçimde bölün ve sonuçları paylaşılan bir dosyaya yazdırın.
• Belirsiz görev tanımı: en pahalı hata. Kontrol: her alt göreve girdi, beklenen çıktı biçimi ve başarı ölçütü yazın.
• Sıralı darboğaz: paralel görünen kurgu aslında bir adımda beklemektedir; paralelliğin gerçekten var olduğunu izlerden doğrulayın.

Güvenlik tarafı da ihmal edilmemeli: OWASP’ın 2026 ajan çerçevesi güvensiz ajanlar arası iletişimi (ASI07) ve zincirleme hataları (ASI08) ayrı riskler olarak adlandırdı. Bir alt ajanın diğerine gönderdiği metin, alan taraf için hâlâ güvenilmeyen girdidir; ve bir alt ajanın hatası, üst ajanı sonsuz yeniden denemeye sokabilir.

Bu yüzden çoklu ajan sistemlerinde global token bütçesi bir güvenlik önlemidir, bir optimizasyon değil:

class GorevButcesi:
    """Tum agac icin tek bir tavan: yonetici + tum alt ajanlar."""
    def __init__(self, azami_token: int, azami_alt_ajan: int = 5):
        self.azami_token = azami_token
        self.azami_alt_ajan = azami_alt_ajan
        self.harcanan = 0
        self.acilan = 0

    def alt_ajan_ac(self):
        if self.acilan >= self.azami_alt_ajan:
            raise RuntimeError("alt ajan ust siniri asildi")
        self.acilan += 1

    def harca(self, token: int):
        self.harcanan += token
        if self.harcanan > self.azami_token:
            raise RuntimeError(
                f"gorev butcesi asildi: {self.harcanan}/{self.azami_token}")

Karar tablosu#

Son bir pratik öneri: çoklu ajana geçmeden önce tek ajanı daha yüksek bütçeyle deneyin. Kazanç varyansının büyük kısmını token harcaması açıklıyorsa, bu deney genellikle mimari karmaşıklığa gerek olup olmadığını tek başına cevaplar — ve çok daha ucuza.

Çoklu ajan bir yetenek değil bir takas; doğru soru “kurabilir miyim” değil, “bu iş buna değer mi”. Mimari seçenekler için otonom ajan mimarileri, maliyet kaldıraçlarının tamamı için LLM maliyet optimizasyonu, ve işi doğru modele göndermenin daha ucuz yolu için model yönlendirme ve kademeleme yazılarına bakabilirsiniz.