Single Agent mı Multi Agent mı Tercih Edilmeli?

Bir sistem tasarlarken karşınıza şu ikilem çıkıyor: her işi ayrı bir ajana mı yaptırayım, yoksa tek bir ajanın etrafında toplanan araçlarla mı ilerleyeyim? Özellikle son dönemde "multi agent" mimarilerin popülerleşmesiyle birlikte, herkesin aklında aynı soru dönüyor. Peki gerçekten her senaryoda birden fazla ajana ihtiyacınız var mı, yoksa iyi tanımlanmış tek bir ajan da işi görür mü?

Kısa cevap şu: Bu tercih tamamen amaca bağlı. Neyi başarmaya çalıştığınız, yani sistemin "goal"i, kaç ajanla çalışacağınızı belirler. Bazen tek bir ajan, iyi tanımlanmış araç çağrıları (tool call) ile bir orduyu tek başına idare edebilir; bazen de işi parçalara bölmeden altından kalkamazsınız.

Soruyu Ajana Değil, Amaca Sorun

Multi agent tartışmasının en sık atlanan noktası şu: Mimari kararı, teknolojiye duyduğunuz heyecana göre değil, çözmeye çalıştığınız probleme göre vermeniz gerekiyor. Yapmak istediğiniz iş neyse, önce onu net biçimde tarif edin. Ondan sonra ajan sayısı zaten kendiliğinden ortaya çıkar.

Bir workflow'u ajanlara bölmek, üzerinde düşünülmüş bir karar olmalı. Yoksa "herkes multi agent yapıyor, ben de yapayım" refleksiyle kurulan sistemler, çoğu zaman tek bir ajanın yapabileceği işi gereksiz karmaşıklıkla sarmalıyor.

Tek Ajan Ne Zaman Yeter?

Burada seyahat teknolojileri üzerinden düşünelim. Diyelim ki bir müşteri uçak bileti almak istiyor ya da mevcut biletinde değişiklik yapmak istiyor. İlk refleks şu olabilir: Bir rezervasyon ajanı, bir satış ajanı, bir ödeme (payment) ajanı, bir bilet basma ajanı… Hepsinin başına da bir supervisor ajan koyalım.

Kulağa güzel geliyor, değil mi? Ama biraz durup düşünün. Bu ajanların her birinin yaptığı şey aslında bir fonksiyon çalıştırmak. Rezervasyon oluştur, ödeme al, bilet bas. Peki bunları tek bir ajanın altında birer araç (tool) olarak tanımlasanız ne olur?

Cevap oldukça sade: Aynı işi çok daha az karmaşıklıkla yaparsınız. Tek bir dil modeli (LLM) konuşmanın bağlamını (context) anlar, hangi fonksiyonun ne zaman çağrılması gerektiğine karar verir, dönen sonucu tekrar bağlama besler ve bir sonraki adımı belirler. Ortada beş tane ajan yaratmak yerine, iyi yazılmış fonksiyonlarla donatılmış tek bir ajan, aynı senaryoyu rahatlıkla götürür.

Tool Call'un Sessiz Gücü

Çoğu "multi agent" senaryosunun aslında birer "tool call" senaryosu olduğunu fark ettiğiniz an, mimari tercihleriniz değişmeye başlıyor. Fonksiyonlarınızı net tanımladığınızda, model onlara hangi sırayla ihtiyaç duyacağını kendi çıkarabiliyor. Bu da hem daha az token, hem daha az gecikme, hem de daha kolay debug edilebilen bir sistem demek.

Yani şu soruyu kendinize dürüstçe sormanız gerek: Buradaki her ajan gerçekten kendi başına muhakeme yapan, kendi kararlarını veren bir varlık mı? Yoksa aslında sadece bir fonksiyonu tetikleyen aracıdan mı ibaret? Cevap ikincisiyse, ajan yaratmaya gerek yok.

Peki Multi Agent'ın Sırası Ne Zaman Gelir?

Burada işin ilginç kısmı başlıyor. Tek ajan bu kadar güçlüyken, multi agent mimariler neden var? Çünkü bazı işler var ki, gerçekten farklı uzmanlık alanlarına, farklı bağlamlara ve farklı karar mekanizmalarına ihtiyaç duyuyor. Bir ajanın belleğinin, prompt'unun ve yeteneklerinin başka bir ajanınkiyle karışması, işin kalitesini düşürüyor.

İşi ajanlara bölmek, aslında bir tür "görev tanımı" yapmakla eşdeğer. Her ajanın kendi sorumluluğu, kendi bilgi alanı ve kendi karar sınırları oluyor. Bu, tek ajanla çözülemeyecek kadar geniş kapsamlı, birbirinden bağımsız uzmanlıklar gerektiren senaryolarda anlam kazanıyor.

Karar Verirken Kendinize Sormanız Gerekenler

Bir mimariye karar vermeden önce, birkaç soruyu masaya yatırmak faydalı olur:

• Yapmak istediğim iş, birbirinden gerçekten bağımsız uzmanlıklar mı içeriyor, yoksa birbirini tamamlayan fonksiyonlar mı?
• Her bir ajanın kendi başına bir karar verme (reasoning) sürecine ihtiyacı var mı, yoksa sadece bir fonksiyonu mu çağıracak?
• Konuşmanın bağlamını tek bir ajanın taşıması yeterli mi, yoksa bağlamları ayırmam gerekiyor mu?
• Sistem büyüdüğünde hangi mimari daha az bakım (maintenance) yükü getirir?

Bu soruların cevapları, size ajan sayısının kaç olması gerektiğini net biçimde söyleyecektir. "Trend böyle" diye multi agent kurmak yerine, ihtiyaç böyle olduğu için kurmak, çok daha sağlıklı sistemler doğurur.

Aynı Senaryo, İki Farklı Mimari

Seyahat teknolojisi örneğine geri dönelim. Müşteri uçak bileti almak istiyor. Klasik multi agent yaklaşımında; supervisor ajan konuşmayı yönlendirir, rezervasyon ajanı uygun uçuşları bulur, satış ajanı fiyat hesaplar, payment ajanı ödemeyi alır, bilet basma ajanı da PNR üretir. Beş ajan, bir supervisor ve aralarındaki tüm mesajlaşma yükü.

Aynı senaryoyu tek ajanla kurduğunuzda ise; tek bir ajan konuşmayı dinler, uygun anda search_flights fonksiyonunu çağırır, dönen sonucu bağlama ekler, sonra calculate_price, ardından process_payment ve en sonunda issue_ticket fonksiyonunu tetikler. Her fonksiyonun dönüşü tekrar bağlama besleniyor ve model bir sonraki adımı buna göre planlıyor.

İkisi de aynı sonucu üretir. Ama ikincisi çok daha az hareketli parça içerir, hata ayıklaması kolaydır ve maliyeti düşüktür. "Öyleyse neden ajan yaratayım?" sorusu, bu noktada oldukça meşrudur.

Merak Edilenler

Multi agent her zaman daha güçlü bir mimari midir?

Hayır. Multi agent, daha fazla ajan olduğu için daha "akıllı" bir sistem değildir. Aksine, gereksiz yere bölünmüş bir sistem, hem daha yavaş hem de daha kırılgan olabilir. Güç, ajan sayısında değil, problem-mimarisi uyumunda gizlidir.

Tool call ile ajanı nasıl ayırt ederim?

Bir bileşen sadece bir fonksiyonu tetikliyor ve sonucu döndürüyorsa, o bir araç (tool). Kendi başına muhakeme yapıyor, karar veriyor ve bağlamı yönetiyorsa, o bir ajan. Bu ayrımı net tuttuğunuzda mimariniz de sadeleşir.

Başlangıçta hangisiyle başlamalıyım?

Genellikle tek bir ajan ve iyi tanımlanmış araçlarla başlamak, sağlıklı bir yaklaşımdır. İhtiyaç duydukça, gerçekten farklı bir muhakemeye ihtiyaç olduğu noktalarda ajanları bölmek, hem daha temiz hem de daha esnek bir mimariye götürür sizi.

Supervisor ajan gerekli mi?

Ancak birden fazla ajanınız varsa ve aralarında bir koordinasyon ihtiyacı doğuyorsa. Tek ajanlı sistemlerde supervisor kavramı bile fazlalıktır.

Sadelik, Genellikle Daha Zekicedir

Bir sistemi tasarlarken "kaç ajan koyayım?" sorusundan önce, "bu iş gerçekten bölünmeye ihtiyaç duyuyor mu?" sorusunu sormak, daha olgun bir yaklaşım. Multi agent mimariler heyecan verici, ama her problemin çözümü değiller. Bazen bir ajanın altında dizilmiş iyi tanımlanmış fonksiyonlar, en zarif çözümdür.

Yani mesele ajan sayısı değil; problemin gerçek şeklini görebilmek. O şekli gördükten sonra mimari kararı vermek, hem sisteminizin ömrünü uzatır, hem de sizi gereksiz karmaşıklıktan korur.