Üretim Ortamında Çoklu Ajan Mimarisi

Çoklu ajan mimarisi, bir işi tek bir dil modeline bütün araçlarla birlikte yüklemek yerine, rolleri ayrılmış birden fazla ajana bölen ve ajanlar arasındaki bağlam akışını bilinçli olarak sınırlayan bir tasarım biçimidir. Üretim ortamında bu yapının değeri “daha çok ajan, daha çok zekâ” denkleminden gelmez; asıl kazanç, her ajanın yalnızca kendi görevi kadar veri ve yetki görmesi sayesinde bir hatanın yayılma alanının daralmasıdır. Bu rehberde çoklu ajan mimarisinin ne olduğunu, hangi desenlerle kurulduğunu, Model Context Protocol'ün bu tabloda nereye oturduğunu, otonom ajan akışının adım adım nasıl kurulacağını, çalışılmış bir örnekle önce ve sonra farkını, kararlılığı hangi ölçümlerle doğrulayacağınızı ve en sık tekrarlanan hataları uçtan uca anlatıyorum.

Çoklu Ajan Mimarisi Nedir?

Çoklu ajan mimarisi, her biri dar bir görev tanımına, kendi araç setine ve kendi bağlam penceresine sahip ajanların ortak bir yönlendirme mantığı altında birlikte çalıştığı yapıdır. Tek ajanlı kurulumda bir model hem planlar hem araştırır hem yazar hem de dış sistemleri çağırır; çoklu ajan kurulumunda bu sorumluluklar ayrı ayrı tanımlanır ve aralarındaki geçiş noktaları açıkça belirlenir.

Bu noktada iki kavramı ayırmak gerekir. Deterministik iş akışı, adımların sırasının kodla sabitlendiği yapıdır: hangi adımın ne zaman çalışacağını model değil siz belirlersiniz. Ajan ise hedefi verilen, hangi aracı hangi sırayla çağıracağına kendi karar veren bileşendir. Üretimde kararlı çalışan sistemlerin çoğu ne saf ajan ne de saf iş akışıdır; iskelet deterministiktir, yalnızca gerçekten muhakeme gerektiren adımlar ajana bırakılır.

Bir kurulumun “çoklu ajan” sayılması için ajan sayısının büyük olması gerekmez. İki ajan bile, aralarında net bir görev sınırı ve kontrol edilen bir veri geçişi varsa çoklu ajan mimarisidir. Ajan sayısını artırmak tek başına bir iyileştirme değildir; her yeni ajan bir devir teslim noktası, dolayısıyla yeni bir hata yüzeyi ekler.

Üretim Ortamında Çoklu Ajan Mimarisi Neden Gerekir?

Çoklu ajan mimarisi üretimde, tek bir modelin taşıyamayacağı kadar geniş araç yüzeyi, birbirinden farklı yetki seviyeleri veya denetlenebilir rol ayrımı gerektiğinde gerekir. Prototipte tek modele on beş aracı birden vermek çalışıyor görünür; aynı kurulum üretimde araç seçim hatalarına, bağlam şişmesine ve maliyet artışına dönüşür.

Bunun temel nedeni bağlam ekonomisidir. Tek bir ajana verilen her yeni araç tanımı, her yeni doküman ve her ara çıktı aynı bağlam penceresinde birikir. Pencere büyüdükçe modelin ilgili bilgiyi seçme işi zorlaşır ve önceki adımlardan kalan artıklar sonraki kararları kirletir. Bağlamı görev bazında bölmek, bu birikimi kaynağında keser. Bağlam yönetiminin ayrıntılı yöntemleri için bağlam mühendisliği rehberine bakabilirsiniz.

İkinci neden yetki ayrımıdır. Veriyi okuyan ajanla veriyi değiştiren ajanın aynı kimlik ve aynı yetki setiyle çalışması, en küçük muhakeme hatasını geri alınamaz bir işleme çevirir. Rolleri ayırmak, yetkiyi de ayırmayı mümkün kılar. Üçüncü neden denetlenebilirliktir: her adımın hangi ajan tarafından, hangi girdiyle ve hangi çıktıyla yapıldığı ayrı ayrı kaydedilebilir hale gelir.

Buna karşılık çoklu ajan mimarisi her iş için doğru cevap değildir. Tek bir kaynaktan veri çekip sabit bir şablona yazan bir süreçte ajan katmanı eklemek, çözülen problemden daha fazla belirsizlik üretir. Kural nettir: rol ayrımı, farklı yetki seviyeleri veya denetim zorunluluğu yoksa daha basit yapı tercih edilir.

Supervisor-Specialist Ajan Yönlendirme Modeli Nasıl Çalışır?

Supervisor-specialist modelinde, yönlendirici bir lider ajan (supervisor) gelen isteği analiz eder ve işi yalnızca o alana uzmanlaşmış bir alt ajana (specialist) devreder; böylece tek bir modelin tüm araçlarla boğulması önlenir. Karmaşık bir kurumsal iş akışında tek bir LLM modeline tüm araçları teslim etmek, modelin kafa karışıklığı yaşamasına ve yanlış araçları tetiklemesine neden olur. Bunun yerine LangGraph veya benzeri kütüphaneler kullanarak yönlendirici bir lider (supervisor) ve sadece kendi alanında uzmanlaşmış alt ajanlar (specialists) kurgulanmalıdır. Supervisor, kullanıcının sorusunu analiz eder, planlama yapar ve ilgili işi sadece o alana atanmış alt ajana (örneğin SQL veritabanı uzmanı veya PDF RAG asistanı) yönlendirir. Uzmanlaşmış ajanlara görev bölmek bazı karmaşık işlerde kapsama avantajı sağlayabilir; gerçek kazanım ancak aynı görev seti üzerinde tek ajanlı ve çok ajanlı tasarım karşılaştırılarak ölçülmelidir. Ancak bu yapıda her ajanın bağlam penceresini izole tutmak ve aralarındaki veri akışını sınırlamak, maliyetlerin kontrolden çıkmasını engellemenin tek yoludur.

Multi-Agent Architecture Türleri ve Hangisi Hangi İşe Uygun?

Multi-agent architecture desenleri, ajanlar arasındaki kontrol akışının kimde olduğuna göre ayrışır: sırayı kod mu belirler, merkezi bir yönlendirici mi belirler, yoksa ajanlar birbirini doğrudan mı çağırır? Bu soru mimarinin hem maliyetini hem de hata davranışını belirlediği için araç seçiminden önce yanıtlanmalıdır.

Zincir (sequential) deseninde adımların sırası kodla sabittir ve her ajan bir öncekinin çıktısını alır; en öngörülebilir ve en ucuz desendir. Supervisor deseninde merkezi bir yönlendirici gelen isteği sınıflandırır ve yalnızca ilgili uzmana devreder. Hiyerarşik desende yönlendiricilerin kendi alt ekipleri olur; alan alan ayrılmış büyük işlerde kullanılır. Ağ (network) deseninde her ajan her ajanı çağırabilir; en esnek, buna karşılık en zor denetlenen ve maliyeti en hızlı büyüyen desendir.

Pratikte doğru başlangıç neredeyse her zaman zincir veya supervisor desenidir. Ağ desenine ancak ölçülmüş bir ihtiyaç varsa geçilmelidir; “ajanlar birbiriyle konuşsun” fikri cazip görünse de kontrolsüz devir teslim en pahalı hata türüdür.

Model Context Protocol (MCP) Nedir, MCP Entegrasyon Neyi Standartlaştırır?

Model Context Protocol (MCP), dil modeli uygulamaları ile dış veri kaynakları ve araçlar arasındaki bağlantıyı standartlaştıran açık bir protokoldür; MCP entegrasyon ise her araç için ayrı ve özel bir bağlayıcı yazmak yerine ortak bir sözleşme üzerinden bağlanmak demektir. Resmî spesifikasyona göre protokol JSON-RPC 2.0 mesaj biçimini kullanır ve durum taşıyan (stateful) oturumlar üzerinden çalışır.

Spesifikasyonun 2025-11-25 sürümü rolleri üçe ayırır: bağlantıyı başlatan host uygulaması, host içinde çalışan client bileşenleri ve bağlam ile yetenek sunan server'lar. Sunucular üç yetenek sunabilir: resources (veri ve bağlam), prompts (şablon mesaj ve akışlar) ve tools (modelin çalıştırabileceği fonksiyonlar). İstemciler ise sampling, roots ve elicitation yeteneklerini sunucuya açabilir.

Çoklu ajan mimarisi açısından MCP'nin en kritik tarafı, protokolün mimari bölümünde tanımlanan izolasyon ilkesidir. Her client bir sunucuyla 1:1 ilişki kurar ve spesifikasyonun dört tasarım ilkesinden biri açıkça şunu söyler: sunucular konuşmanın tamamını okuyamamalı ve diğer sunucuların içini görememelidir. Tam konuşma geçmişi host tarafında kalır, sınırları host uygular. Bu ilke, “her ajan her şeyi görsün” kurulumunun neden protokol düzeyinde bile reddedildiğini gösterir.

Araç katmanında sınır aynı biçimde çizilir. Araçlar bölümü, araç tanımlarının JSON Schema ile verilmesini (belirtilmediğinde 2020-12 sürümü varsayılır), araç adlarının 1 ile 128 karakter arasında olmasını ve istemcilerin araç açıklamalarını güvenilir sunuculardan gelmedikçe güvenilmez saymasını şart koşar. Aynı bölüm, araç çağrılarını reddedebilecek bir insanın döngüde bulunmasını da açıkça tavsiye eder. Veri kaynaklarını bu sözleşmeyle bağlamanın uygulamalı anlatımı için MCP ile veritabanı ve LLM entegrasyonu rehberine bakabilirsiniz.

Ajanlar Arası Durum Yönetimi Neden Filesystem-As-State ile Yapılır?

Ajanlar arası durum, verileri prompt içinde taşımak yerine dosya referanslarıyla iletildiğinde kararlı olur; çünkü bu yaklaşım prompt içinde taşınan bağlam yükünü azaltır ve hata anında sürecin kaldığı yerden devam etmesini sağlar. Ajanlar arası iletişimde en büyük hata, ara çıktıların tamamını sürekli prompt içinde taşımaktır. Bu durum hem bağlam birikimine (context residue) yol açar hem de modellerin halüsinasyon görme sıklığını artırır. Kararlı üretim sistemlerinde, veriler ajanlar arasında ham metin olarak değil, dosya referansları şeklinde iletilmelidir. Ajanlar ara çıktılarını yerel diskteki belirli çalışma alanlarına (worktrees) yazar ve bir sonraki ajana sadece dosya yolunu bildirir. Bu yaklaşım, sistemin hem hafıza yükünü azaltır hem de herhangi bir adımda hata oluştuğunda sürecin kaldığı yerden (checkpoint) kolayca devam etmesini (retry) sağlar. Kurulan bu dosya tabanlı mimariyi destekleyen veri bağlantı standartlarını incelemek için Model Context Protocol (MCP) rehberimizi inceleyebilirsiniz.

Otonom Ajan Akışı Adım Adım Nasıl Kurulur?

Otonom ajan akışı, hedefi tanımlanmış bir görevin ajan tarafından planlanıp yürütüldüğü ve her adımının kayıt altına alındığı kontrollü bir döngüdür; kurulum sırası, ajanı yazmakla değil işin sınırlarını yazmakla başlar. Aşağıdaki sıra, geri alınabilirliği ve doğrulanabilirliği en başa koyar.

1. İşi ve bitiş koşulunu tanımlayın. Ajanın ne zaman “bitti” diyeceği ölçülebilir olmalıdır. Bitiş koşulu yoksa döngü ya erken durur ya da maliyet üretmeye devam eder.
2. Eylemleri geri alınabilir ve geri alınamaz diye ayırın. Taslak üretmek, sınıflandırmak ve okumak geri alınabilir; e-posta göndermek, kayıt silmek ve ödeme başlatmak geri alınamaz.
3. Rolleri ve yetkileri eşleştirin. Her ajan yalnızca kendi görevinin gerektirdiği araçlara ve verilere erişsin; okuma yetkisiyle yazma yetkisi aynı ajanda toplanmasın.
4. Devir teslim sözleşmesini yazın. Ajanlar arasında hangi alanların hangi biçimde geçeceği şemayla sabitlensin; serbest metin devri en sık görülen bozulma noktasıdır.
5. Durumu akışın dışına taşıyın. Ara çıktılar prompt içinde değil dosya veya kayıt olarak tutulsun; böylece hata anında baştan başlamak gerekmez.
6. Onay kapılarını yerleştirin. Geri alınamaz her adımın önüne insan onayı koyun; onay verilmeden akış ilerlemesin.
7. Gözlemlenebilirliği açın. Her adımın girdisi, seçtiği araç, çıktısı ve süresi tek bir iz kimliğiyle kaydedilsin.
8. Küçük ve gerçek veriyle koşun. Sentetik örnek yerine gerçek ama düşük riskli bir örneklem üzerinde çalıştırın ve çıktıyı hedef sistemde doğrulayın.

Bu sıralamanın en çok atlanan maddesi dördüncüsüdür. Ajanlar arasında serbest metin devretmek ilk denemede işe yarar, çünkü model karşı tarafın ne demek istediğini tahmin edebilir. Aynı devir, girdi biçimi biraz değiştiğinde sessizce yanlış alanı taşımaya başlar ve hata ancak son çıktıda görünür.

Çalışılmış Örnek: Tek Ajanlı Rapor Akışının Supervisor Modeline Taşınması

Aşağıdaki örnek, tek ajanlı bir haftalık rapor akışının supervisor desenine taşınmasını somut girdi ve çıktıyla gösterir. Amaç deseni bir şema olarak değil, gerçek bir devir teslim sorunu üzerinden anlatmaktır.

Başlangıç durumu. Tek bir ajana üç araç verilmişti: veri kaynağından kayıt çekmek, metin özeti üretmek ve sonucu rapor sayfasına yazmak. Girdi, “geçen haftanın taleplerini özetle ve rapora yaz” biçiminde tek cümlelik bir hedefti.

Gözlenen sorun. Ajan bazı koşularda veriyi çekmeden özet üretiyor, bazı koşularda ise özet adımını atlayıp ham kayıtları doğrudan rapora yazıyordu. Üç işin de aynı bağlamda olması, modelin hangi adımın tamamlandığını kendi ürettiği metinden anlamaya çalışmasına yol açıyordu; tamamlanma bilgisi hiçbir yerde açıkça tutulmuyordu.

Uygulanan değişiklik. Akış üç role bölündü. Toplayıcı ajan yalnız veri kaynağına erişir ve sonucu rapor/hafta-27/kayitlar.json yoluna yazar. Özetleyici ajan yalnız bu dosyayı okur, yazma yetkisi yoktur ve çıktısını rapor/hafta-27/ozet.md olarak bırakır. Yayıncı ajan yalnız özet dosyasını okur ve rapor sayfasına yazar. Supervisor bu üç ajanı sırayla çağırır ve her adımda beklenen dosyanın gerçekten oluşup oluşmadığını kontrol eder.

Girdi ve çıktı. Girdi aynı kaldı: “geçen haftanın taleplerini özetle ve rapora yaz”. Çıktı artık üç ayrı ve denetlenebilir eserdir: ham kayıt dosyası, özet dosyası ve yayınlanan rapor. Bir adım başarısız olduğunda hangi eserin eksik olduğu doğrudan görülür ve akış yalnız o adımdan devam ettirilir; önceki adımlar yeniden çalıştırılmaz.

Kazanılan şey. Buradaki asıl kazanım daha iyi bir özet değil, tamamlanma bilgisinin modelin yorumundan çıkıp dosya sisteminin doğrulanabilir gerçeğine taşınmasıdır. “Özet üretildi mi?” sorusunun cevabı artık bir tahmin değil, bir dosyanın varlığıdır. Benzer bir çok rollü kurulumun uçtan uca yapısını çoklu ajan işletim sistemi projesinde inceleyebilirsiniz.

Çoklu Ajan Sistemlerinde İnsan Onayı (Human-in-the-Loop) Neden Kritiktir?

İnsan onayı, yüksek hata maliyeti olan alanlarda ajanların ürettiği çıktının dışarıya gitmeden önce bir insan tarafından denetlenmesini zorunlu kıldığı için kritiktir; deterministik onay kapıları yüksek riskli hataların dışarı çıkma olasılığını azaltır. Çoklu ajan sistemlerinde her adımı tamamen otonom bırakmak, özellikle finans, sağlık veya veri yönetimi gibi yüksek hata maliyeti olan alanlarda kabul edilemez riskler doğurur. Bu sebeple mimarimize deterministik onay kapıları (Human-in-the-Loop) entegre ediyoruz. Örneğin, alt ajanların hazırladığı raporlar veya veritabanı değişiklik teklifleri doğrudan kullanıcının önüne bir onay ekranı olarak düşer. İnsan gözüyle denetim sağlanıp tek tıkla onay verilmeden akış bir sonraki adıma geçemez. Bu disiplin, geliştirdiğimiz klinik kalite ve otomasyon projelerinde de başarıyla uyguladığımız, hata riskini azaltan ana unsurlardan biridir. Üretim ortamında çalışan ajan sistemlerimizde deterministik kurallar ile esnek LLM gücünü bu şekilde dengeleyerek operasyonel kararlılığı test ve izleme ile güçlendiriyoruz.

Kararlılığı Hangi Veri ve Ölçümlerle Doğrularsınız?

Bir çoklu ajan sisteminin kararlı olduğu iddiası ancak her koşudan toplanan ölçümlerle doğrulanabilir; “daha iyi çalışıyor” gözlemi tek başına kanıt değildir. Ölçümü akıştan sonra eklenen bir rapor katmanı olarak değil, akışın kendisinin ürettiği veri olarak kurmak gerekir.

Burada bir yayın kuralına dikkat etmek gerekir: bir mimarinin ne kadar iyileştirdiğine dair sayı, ancak aynı görev seti üzerinde önce ve sonra ölçüldüğünde anlamlıdır. Başka bir ekibin kendi değerlendirme setinde aldığı sonuç sizin akışınız için bir vaat değildir. Bu yüzden aşağıdaki tablo hazır sayılar değil, kendi sisteminizde toplamanız gereken ölçümleri tanımlar.

Bu ölçümlerin dördüncüsü çoğu ekipte hiç toplanmaz, oysa en bilgilendirici olanıdır. İnsan onayının hangi çıktı türünde sürekli düzeltme yaptığı, sistemin bir sonraki adımda nereyi otomatikleştirmemesi gerektiğini doğrudan söyler.

Agentic AI ve Coklu Ajan Mimarisinde Risk Kontrolu

Agentic AI sistemlerinde hedef, modele sinirsiz serbestlik vermek degil; gorev bolumu, arac erisimi, kayit, geri alma ve insan onayi ile guvenilir bir calisma alani kurmaktir. MCP entegrasyon gibi baglanti katmanlari da ancak bu sinirlar net oldugunda deger uretir.

Uygulama tarafindaki hizmet yaklasimi icin AI otomasyon cozumunu, veri ve baglam yonetimi icin ikinci beyin sistemi rehberini okuyabilirsiniz.

Çoklu Ajan Kurulumunda Sık Yapılan Hatalar ve Tuzaklar

Çoklu ajan sistemlerinde en pahalı hatalar model kalitesinden değil, sınırların gevşek çizilmesinden doğar. Aşağıdaki maddelerin bir bölümü doğrudan MCP'nin güvenlik en iyi uygulamaları bölümünde tanımlanan saldırı sınıflarına karşılık gelir.

• Token'ı olduğu gibi geçirmek. Spesifikasyon bunu açık bir anti-desen sayar: bir sunucu, kendisi için düzenlenmemiş bir erişim token'ını kabul edip alt servise iletmemelidir. Aksi halde hız sınırı, istek doğrulama ve denetim izi devre dışı kalır.
• Oturumu kimlik doğrulama aracı sanmak. Aynı kaynak, sunucuların oturumları kimlik doğrulama için kullanmamasını ve oturum kimliklerini kullanıcıya bağlamasını (örneğin <user_id>:<session_id> biçiminde) şart koşar. Tahmin edilebilir oturum kimlikleri doğrudan taklit riskidir.
• Geniş yetki paketleri vermek. Her aracı kapsayan tek bir yetki seti, çalınan bir kimlik bilgisinin etki alanını gereksiz büyütür ve denetim kaydını okunamaz hale getirir. Asgari yetkiyle başlayıp gerektiğinde yükseltmek doğru yaklaşımdır.
• Araç açıklamalarına güvenmek. Araç tanımı ve açıklaması güvenilir bir sunucudan gelmiyorsa girdi kadar şüpheyle karşılanmalıdır; bu metinler modelin davranışını yönlendirebilir.
• Ajanları birbirine serbest metinle bağlamak. Şemasız devir teslim, biçim değiştiğinde sessizce yanlış alanı taşır ve sorun ancak son çıktıda görünür.
• Ajan sayısını çözüm sanmak. Her yeni ajan bir devir teslim noktası ekler; sorun bağlam yönetimindeyse ajan eklemek sorunu çoğaltır.
• Yeniden denemeyi geri alınamaz adımlara uygulamak. Otomatik tekrar, gönderim ve silme gibi adımlarda aynı işlemi ikinci kez yürütebilir; bu adımlar tekilleştirme anahtarı olmadan asla otomatik tekrarlanmamalıdır.

Hangi Katmanlar Gerekir ve Sonraki Adım Nedir?

Üretimde çalışan bir çoklu ajan kurulumu dört katmandan oluşur: ajanların sırasını ve devrini yöneten orkestrasyon katmanı, araç ve veri bağlantılarını standartlaştıran protokol katmanı, ara çıktıların tutulduğu durum katmanı ve her adımı izlenebilir kılan gözlemlenebilirlik katmanı. Bunlara geri alınamaz adımları kesen onay kapısı eklendiğinde iskelet tamamlanır.

Araç seçimi bu katmanlardan sonra gelir ve göründüğünden daha az belirleyicidir. Orkestrasyon için durum makinesi kurmanıza izin veren bir grafik kütüphanesi, araç bağlantısı için MCP uyumlu sunucular, durum için sürümlenebilir bir dosya veya kayıt deposu, gözlemlenebilirlik için iz kimliği taşıyan yapılandırılmış log yeterlidir. Hangi ürünü seçtiğinizden bağımsız olarak, yukarıdaki sınırları uygulamayan bir kurulum kararlı olmaz.

Başlamak için mevcut akışınızdaki tek bir geri alınamaz adımı seçin ve önüne onay kapısı koyun; ardından ajanlar arasındaki en kırılgan devri şemaya bağlayın. Onay kapısı tasarımının ayrıntıları için otonom ajanlarda insan onayı rehberine bakabilirsiniz.