28  Çok Ajanlı Örüntüler

Bölüm durumu: çevrildi. Kaynak metin: İngilizce 28. bölüm. Maliyet modeli aritmetiktir ve sabitleri tahminlerden değil kitabın önceki ölçümlerinden alınmıştır — Bölüm 27’nin araç tanımı başına 89 token’ı ve Bölüm 23’ün döngü muhasebesi. Model bir token sorusunu cevaplıyor; doğruluk sorusunu ise bilerek dışarıda bırakıyor. Aradaki fark, Bölüm 28.4’ün konusu. Yazılım: Python 3.14.5.

Öğrenme hedefleri. Bu bölümün sonunda:

• topolojiyi modadan değil işin biçiminden seçebilirsiniz;
• işi ajanlara bölmenin bağlam kazandırıp kazandırmadığını hesaplayabilirsiniz;
• bu sistemleri bozan paylaşılan durum problemlerini tanıyabilirsiniz;
• tek ajanın lehine olan argümanı kurabilir, yeni bir ajan eklemeden önce sistemi tek ajana karşı ölçebilirsiniz.

28.1 Tek ajan baseline’dır

Çok ajanlı mimariler, ajan tabanlı sistemlerde gereğinden sık başvurulan fikirlerin başında gelir; nedeni de ilginç olmalarıdır. Uzmanlara iş dağıtan bir koordinatör, çizildiğinde insanı tatmin eden bir şemadır. Bir while döngüsü öyle değildir.

Bu yüzden bu bölüm, Bölüm 23’ün bittiği yerden başlıyor: iyi araçları olan tek bir ajan, yenilmesi gereken baseline’dır (taban model) ve ikinci bir ajan eklemek bir şemayla değil bir ölçümle gerekçelendirilmelidir. Üretimde ayakta kalan yalnızca üç gerekçe var ve üçü de estetik değil yapısaldır:

1. Bağlam. İş, tek bir pencerenin tutması gerekenden fazla malzeme üretir. Bu aritmetiktir ve Bölüm 28.3 onu hesaplıyor.
2. Paralellik. Bağımsız alt görevler gerçekten aynı anda çalışabilir ve wall-clock süresindeki (gerçekte geçen süre) kazanç hayalî değil gerçektir.
3. Yalıtım. Farklı alt görevler farklı araçlar, farklı izinler ya da farklı modeller ister — ve onları karıştırmak her birini kötüleştirir.

Başka her şey — “görev karmaşık”, “aşamaları var”, “farklı uzmanlık” — genellikle tek bir ajanın daha uzun bir prompt (istem) ve birkaç araç daha ile hallettiği bir görevi tarif eder. Genellikle, her zaman değil: farklı bir model, farklı bir araç kümesi ya da farklı bir izin kümesi diye karşılığı olan bir uzmanlık savı, başka bir adla anılan 3. gerekçedir ve o gerçektir. Ayakta kalmayan şey, çalışma zamanını değil işi tarif eden bir uzmanlıktır. Tek ajanı kurun, ölçün; bölme ancak yerini hak ederse gelsin.

Neye bakacağız. Önce bir bölmenin alabileceği dört biçim ve aralarında seçim yapan tek sezgisel kural: salt okunur alt görevleri paralelleştirmek kolaydır, eşzamanlı yazmalar ise açık sahiplik, yalıtım ya da çakışma çözümü ister. Sonra çoğu zaman açık bir maliyet modeli olmadan öne sürülen birinci gerekçenin aritmetiği — üç ajan bir ajandan ucuza gelmeden önce işin ne kadar malzeme üretmesi gerektiği. Sonra o kazancın neyle ödendiği; parayla değil bilgiyle. Sonra bu sistemlerin gerçekte bozulduğu yer olan paylaşılan durum ve başarısız bir görevin size sonsuza kadar fatura kesmesini durduran kuyruk disiplini. Son olarak çatılar: her biri sizi bir denetim akışına bağlar, çoğu zaman da hangisine ihtiyacınız olduğunu bilmeden önce.

28.2 Topolojiler ve her birinin ne işe yaradığı

Üç gerekçeden birinin geçerli olduğunu varsayalım. Bölmenin alabileceği dört biçim var ve birbirlerinin yerine geçmezler — her biri farklı türde bir işte iyidir ve farklı biçimde bozulur.

Dört topoloji

topoloji	biçim	ne zaman uyar	neye mal olur
Merkez ve uçlar (supervisor ya da orchestrator-worker da denir)	bir koordinatör, N uzman, yanal bağlantı yok	bölecekseniz varsayılan seçenek. Koordinatör bir bağlam güvenlik duvarıdır: ham gözlemler ona ancak bir uzmanın raporu üzerinden ulaşır	koordinatör bir darboğaz ve tek arıza noktası hâline gelir — ve güvenlik duvarı, o raporun biçimindeki disiplin kadar güçlüdür: raporuna ham bir stack trace (hata yığını dökümü) yapıştıran uzman duvarı yıkmış olur
Sıralı	her biri bir öncekinin çıktısını alan bir ajan hattı	gerçekten farklı gereksinimleri olan aşamalar — çıkar, sonra doğrula, sonra yaz	bu bir hattır. Ajanlara hiç ihtiyacı olup olmadığını sorun
Paralel dağılım	bağımsız dilimlerde N uzman, sonuçlar birleştirilir	ayrılabilir girdiler üzerinde okuma ağırlıklı iş: çok belge, çok depo	birleştirme bir join değil gerçek bir tasarım problemidir
Döngü / tartışma	ajanlar birbirinin çıktısını eleştirir ya da iyileştirir	dar: bağımsız bir kontrolün gerçekten bir şey yakaladığı yer	pahalıdır ve yeni hiçbir şey görmeyen bir eleştirmen nadiren işe yarar: Bölüm 24.2, yeni bilgi taşımayan geri bildirimden toparlanmayı %1,7 olarak ölçtü

İşe yarar sezgisel kural tek cümledir: salt okunur alt görevleri paralelleştirmek genellikle kolaydır; eşzamanlı yazmalar açık sahiplik ve çakışma yönetimi ister. On belgeyi okuyan on ajan on kat hıza yaklaşır — yaklaşır, çünkü bu eşit büyüklükte iş, sağlayıcıda yeterli eşzamanlılık ve saymadığınız bir birleştirme adımı varsayar. Tek bir kod tabanını düzenleyen on ajan ise üstlenmeye niyetli olmadığınız bir dağıtık sistem problemidir; nedenini Bölüm 28.5 anlatıyor. Yazmalar da bölünebilir, ama yalnızca sahiplik ayrıksa — dosya başına, kayıt başına, bölüntü (partition) başına bir ajan. Bu, bir veri tabanının size uygulatacağı düzeltmenin aynısıdır.

Paralellik gerekçesi için bir aritmetik daha: bir paralel dağılım, en yavaş uzmanı bittiğinde biter; koordinatörün kendi çağrıları da bunun üstüne eklenir. Biri diğerlerinden beş kat büyük olan on dilim, on kat hızlanmanın yanına bile yaklaşmaz.

Tartışma üzerine bir not. En bilinen döngü, çok ajanlı tartışmadır (debate): birkaç ajan aynı soruyu cevaplar, birbirinin cevabını okur ve birkaç tur boyunca cevabını düzeltir (Du vd., 2023). Bunun bedelini ödemeden önce Bölüm 10.4’teki ucuz kontrolü çalıştırın: aynı modelden aynı sayıda örnek alıp çoğunluk oyuna bakın, aynı token bütçesiyle. Choi vd. (2025), genellikle tartışmaya yazılan kazancın büyük kısmını tek başına oylamanın açıkladığını buldu.

28.2.1 Handoff mu delegation mı: devir mi, görevlendirme mi?

İki farklı şeye aynı ad veriliyor ve ikisi farklı biçimlerde bozuluyor.

Delegation (görevlendirme: bir alt görevi başka bir ajana gönderme) — koordinatör konuşmayı elinde tutar, bir alt görev gönderir, bir sonuç geri alır. Uzman, içinde bir model olan bir işlev çağrısıdır ve durumsuz olmalıdır: ihtiyaç duyduğu her şey istekle gelir. Düzgün davranan örüntü budur.

Handoff (devir: konuşmanın ve kontrolün başka bir ajana geçmesi) — koordinatör konuşmanın kendisini, artık ona sahip olan başka bir ajana geçirir. Daha ucuzdur, çünkü ikisinin arasına bir koordinatör çağrısı girmez; ama güvenlik duvarını kaybeder: ikinci ajanın yaptığı her şey artık aynı transkriptte ve onu özetleyecek ya da reddedecek bir koordinatör kalmamıştır.

Handoff — koordinatörün konuşmanın kendisini başka bir ajana devretmesi; artık konuşmanın sahibi o ajan. Delegation’dan farkı: ikinci ajanın yaptığını özetleyecek ya da reddedecek kimse kalmıyor. ↩︎

Durumsuz uzmanlarla delegation’ı tercih edin. Önceki çağrıları hatırlayan bir uzman, kayıtlarının ne zaman geçersiz sayılacağına dair kuralı olmayan bir dağıtık önbellektir: eskimiş bir hafızadan cevap verebilir ve o hafızanın ne zaman atılacağına hiçbir şey karar vermez. Handoff’un tek meşru kullanımı, sıradaki ajanın doğrudan kullanıcıyla konuşması gerektiği durumdur; örneğin bir yönlendirme (triage) ajanının müşteriyi fatura ajanına aktarması. Orada iş konuşmanın kendisidir ve onu devretmek zaten amaçtır.

28.3 Bölmek gerçekten bağlam kazandırıyor mu?

Birinci gerekçe — bağlam — aritmetiktir; öyleyse genellikle eksik olan maliyet modeli işte burada.

Adım sayısına (her adım bir model çağrısı) n, her çağrının taşıdığı sabit ön eke (sistem prompt’u artı araç tanımları) F, bir gözlemin eklediği token sayısına o diyelim. Tek bir ajan her model çağrısında bütün transkriptini yeniden gönderir; dolayısıyla i. çağrı F + i·o’ya mal olur ve toplamda karesel bir terim vardır: n·F + o·n(n−1)/2. Doğrusal kısım çağrı başına bir kez ödenen sabit ön ek, karesel kısım ise biriken gözlemlerdir. Bölmenin küçük sonuçlu kısa işte neden kaybettiğini de bu açıklar: orada doğrusal terim hâlâ baskındır.

Uzmanlarla çalışan bir koordinatör bu karesel büyümeyle şöyle başa çıkar: her ajanda sabit bir bedel öder (sistem prompt’u artı araç tanımları; Bölüm 27 bunu araç başına 89 token olarak ölçtü) ve karşılığında iki şey alır: her uzman temiz bir pencereden başlar ve koordinatör ham sonuçlar yerine özetler görür.

Sabit maliyeti 1.450 token alalım — tanesi 89 token’dan on dört araç tanımı yaklaşık 1.250 eder, üstüne yaklaşık 200 token’lık bir sistem prompt’u — ve bir uzmanın koordinatöre döndürdüğü raporu 120 token. Modelin tamamını aşağıya yazıyoruz; çünkü her sonuç bazı varsayımlara dayanıyor ve varsayımlar yazıya döküldüğünde tartışılması kolaylaşıyor:

tüm maliyetler prompt token'ıdır; çıktı token'ları sayılmaz

  F = 1.450   ajan başına sabit ön ek (sistem prompt'u + 14 araç tanımı)
  R =   120   bir uzmanın koordinatöre döndürdüğü rapor
  o           bir gözlemin döndürdüğü token sayısı
  n           işin toplam adım sayısı

  tek = sum_{i=0}^{n-1} (F + i*o)       = n*F + o*n(n-1)/2
  üç  = 3 * sum_{i=0}^{n/3-1} (F + i*o) + sum_{i=0}^{2} (F + i*R)

Beş varsayım var ve beşi de bölmenin lehine:
  - her çağrıda transkriptin tamamı yeniden gönderilir; kırpma, sıkıştırma yok
  - prompt önbellekleme yok (aşağıda: dokuz hücrenin üçünü değiştiriyor)
  - n adım, tekrarlanan iş olmadan üç ayrık üçte bire bölünür
  - koordinatör n ne olursa olsun tam üç çağrı yapar, yeniden plan yapmaz,
    son sentez çalıştırmaz — her hücrede sabit 4.710 token
  - çıktı token'ları bedavadır ve her ajan aynı ücretle faturalanır

İki formülü somut bir hücreyle okuyalım: 200 token’lık gözlemlerle 6 adım. Tek ajan 6 × 1.450 + 200 × 15 = 11.700 token öder (15 = 6·5/2). Üç uzmanın her biri 2 adım atar ve 2 × 1.450 + 200 = 3.100 öder, üçü birlikte 9.300; koordinatörün sabit 4.710 token’ı eklenince toplam 14.010 olur.

Aşağıdaki üç gözlem boyutu, araçların gerçekte döndürdüğü aralığı kapsıyor: ~200 token bir arama sonucu listesi, ~800 bir fonksiyon gövdesi ya da küçük bir API yanıtı, ~3.000 bir dosya okuması ya da çekilmiş bir sayfa.

Tablodan alıntıladığınız her oranı o beş varsayımla birlikte aktarın. Özellikle iki tanesi önemli: koordinatör hiç son sentez çalıştırmıyor ve çıktı token’ları bedava. Gerçek bir sistem ikisinin de bedelini öder ve sentez üç raporu okur; yani bölmenin gerçek maliyeti tabloda basılı olanın üstündedir. Bunlar modellenmiş sayılar, ölçülmüş uçtan uca bir tasarruf değil.

Bir varsayım daha adım sözcüğünün içinde saklı: her adım ayrı bir model çağrısıdır. Bölüm 23, bir modelin beş bağımsız aramayı 2,0 model çağrısına topladığını ölçtü. Böyle olduğunda n aramaları değil model çağrılarını sayar, tek ajanın karesel terimi küçülür ve bölmenin lehindeki gerekçe daha da zayıflar. Tablo, adımları gerçekten sıralı olan işler içindir.

Bu alt bölümdeki sayı blokları maliyet betiğinin çıktısıdır ve İngilizce sayı biçimini korur: 11,700 = 11.700 token, 1.20x = 1,20 kat. Sütunlar sırasıyla adım sayısı, gözlem boyutu, tek ajanın maliyeti, üç uzmanın maliyeti ve üç uzmanın tek ajana oranıdır; oran 1’in altındaysa bölmek ucuzdur.

 steps  obs size   single agent   3 specialists    ratio
     6       200         11,700          14,010    1.20x
     6       800         20,700          15,810    0.76x
     6     3,000         53,700          22,410    0.42x
    12       200         30,600          25,710    0.84x
    12       800         70,200          36,510    0.52x
    12     3,000        215,400          76,110    0.35x
    24       200         90,000          56,310    0.63x
    24       800        255,600         106,710    0.42x
    24     3,000        862,800         291,510    0.34x

Ve geçiş noktası — üç uzmanın bir ajandan ucuz hâle gelmesi için bir gözlemin ne kadar büyük olması gerektiği:

    6 steps  ->    393 tokens per observation
   12 steps  ->     98 tokens per observation
   24 steps  ->     25 tokens per observation

Bölmek hacimde kazandırır, zorlukta değil

Yalnızca bir hücre kırmızı ve o da işin kendisinin ucuz olduğu köşe: küçük sonuçlu kısa iş. Çok ajanlı sistemlerin birçoğu tam da burada kuruluyor. İki eksen de önemli, ama adım ekseni göründüğünden daha önemli: başa baş gözlem boyutu kabaca adım sayısının karesiyle düşüyor, yani adımları ikiye katlamak onu yaklaşık dörde bölüyor (393 → 98 → 25). Aynı toplam malzemede — 4.800 token — 200’er token’lık yirmi dört adım 0,63 kata inerken 800’er token’lık altı adım yalnızca 0,76 kata iniyor.

Tablo iki biçimde okunabilir ve iki okuma da önemli.

Küçük sonuçlu kısa işte bölmek daha pahalıdır. Her biri 200 token döndüren altı adım, üç ajanlı bir sistem olarak 1,20 kata mal oluyor; çünkü hiç biriktirmediğiniz bir transkriptten tasarruf etmek için ajan başına sabit bedeli üç kez fazladan ödediniz. İnsanların yine de kurduğu sistem budur; burada kararı ölçüm değil şema veriyor.

Büyük sonuçlu uzun işte bölmek muazzam kazandırır. Her biri 3.000 token döndüren yirmi dört adım, tek ajan olarak 862.800 token ve üç ajan olarak 291.510 — 0,34 kat, üçte iki tasarruf. Mekanizma karesel terimdir: tek ajan her gözlemi sonraki her çağrıya taşır, uzmanlar taşımaz.

Belirleyici değişken görevinizin ne kadar karmaşık olduğu değil. Ne kadar malzeme ürettiğidir. Daha doğrusu: malzeme çarpı onu sonradan taşımak zorunda kalan çağrı sayısı. Büyük gözlemli uzun transkriptler bölmenin var olma nedenidir. Kısa olanlar değil.

28.3.1 Bütün tabloyu belirleyen iki varsayım

Asıl yükü taşıyan varsayım, n adımın birbiriyle örtüşmeyen üç eşit parçaya bölündüğüdür. Gerçek uzmanlar aynı belgeyi iki kez okur, bir koordinatör görevi kötü böler, bir uzman diğerinin bulduğunu yeniden bulur. Tekrar katsayısına d diyelim; her uzman d·n/3 adım atsın. Tablonun manşet hücresi şöyle değişiyor:

  24 steps, 3,000-token observations

    d = 1.0 (printed)     291,510 against 862,800      0.34x
    d = 1.5                650,910 against 862,800      0.75x
    d = 2.0              1,154,310 against 862,800      1.34x

d = 2’de — her uzman adil payının iki katını yaparken — hiçbir adım sayısında hiçbir gözlem boyutu bölmeyi ucuzlatmıyor. d = 1,5 bile dokuz hücrenin dördünü bölmenin aleyhine çeviriyor; basılı tablodakinden üç fazla. Orana güvenmeden önce tekrar oranınızı ölçün; sonucu asıl belirleyen parametre o ve tabloda yok.

İkincisi prompt önbellekleme (prompt caching) ve bu bir dipnot değil. Bir ajan döngüsünün her turu, bir önceki turun prompt’unu birebir aynı ön ek olarak yeniden gönderip sonuna biraz ekliyor. Önbellekleme tam da bu örüntü için tasarlandı ve en uzun tekrarlanan ön eki taşıyan tek ajan, bundan en çok yararlanan taraf. Aşağıdaki modelde her çağrı, bir önceki çağrının gönderdiği her şeyi önbellekten okuyor ve önbelleğe yalnızca yeni token’larını yazıyor. Önbellekten okumayı taban ücretin 0,1 katı, önbelleğe yazmayı 1,25 katı sayarsak (yayımlanmış tarifelerde yaygın bir düzen):

  steps / obs      raw ratio    with caching
     6 /   200        1.20x        2.27x
     6 /   800        0.76x        1.35x   <- flips
     6 / 3,000        0.42x        0.80x
    12 /   200        0.84x        1.60x   <- flips
    12 /   800        0.52x        1.00x   <- level (1.004x)
    12 / 3,000        0.35x        0.75x
    24 /   200        0.63x        1.09x   <- flips
    24 /   800        0.42x        0.76x
    24 / 3,000        0.34x        0.65x

Geçiş noktaları gözlem başına 393 / 98 / 25 token’dan 1.643 / 810 / 268’e taşınıyor — dört ila on bir kat ileri. Dokuz hücrenin üçü açıkça tersine dönüyor, dördüncüsü ise başa baş, ama kıl payı yanlış tarafta kalıyor. Önbellekleme kazancı törpülemekle kalmıyor; kısa işte onu ortadan kaldırıyor. Bölüm 27 aynı noktayı öbür uçtan söylüyor: araç tanımları bir bağlamdaki en önbelleklenebilir şey. Sağlayıcınız önbellekleme yapıyorsa tek ajan, ilk tablonun kabul ettiğinden çok daha güçlü bir baseline’dır — yeter ki çağrılar arasındaki boşluk kısa olsun, çünkü önbelleğe alınmış ön ekler genellikle birkaç dakika boşta kaldıktan sonra silinir.

28.4 Kazanç bilgiyle ödenir

O tablo bir token sorusunu cevaplıyor. Cevabın hâlâ doğru olup olmadığı hakkında hiçbir şey söylemiyor ve çok ajanlı mimarilerin gerçekte bozulduğu yer burası.

Koordinatör gözlemleri değil bir özeti görür. Kazancın bütün mekanizması budur — ve koordinatörün, uzmanın gördüğünün kayıplı bir sıkıştırması üzerine akıl yürüttüğü anlamına gelir. Uzmanın raporlamaya değer görmediği ne varsa gitmiştir ve sonraki hiçbir adım onu geri getiremez. Bölüm 14 özetlemenin sadakate ne yaptığını ölçtü; özetleyici kendi alt ajanınız ve okur kendi koordinatörünüz olduğunda da aynısı geçerli.

Hatalar, ötesini göremediğiniz bir sınırda birikir. %90 doğru olan bir uzman, onu doğrulama imkânı olmayan bir koordinatöre kendinden emin bir rapor verir. Böyle üç uzman birlikte 0,9³ doğruluk verir — yaklaşık %73 — hataları bağımsızsa ve sistemin doğru olması için üçünün de doğru olması gerekiyorsa. İkisi de garanti değil: aynı modeli aynı derlem üzerinde çalıştıran üç uzman korele biçimde yanılır ve tamamen örtüşen hatalar sistemi %90’a geri götürür. Hiç çakışmayan hatalar ise oranı öbür yöne, 1 − 3 × %10 = %70’e çeker; bağımlılık ne olursa olsun alt sınır budur. Yani gerçekçi rakam bir nokta değil, [%70, %90] bandı; bağımsızlık bu bandın içinde %72,9’da duruyor. Sisteminizin bantta nerede durduğu hesaplanamaz, ölçülmelidir — ve bant, kararın tamamını belirleyecek kadar geniş. Üstelik bütün bunlar koordinatörün kendi sentezinden önceki durum. Bölüm 23’teki tek ajan da tam bu türden bir adımda bozulmuştu: araç kullanımı her adım sayısında kusursuzken doğruluk %100’den %40’a düştü; yani kusur çağrılarda değil, dönen sonuçları birleştirmekteydi.

En görünür üretim sistemi ters yöndeki ödünleşimi (trade-off) ölçüyor; bu yüzden onu bölüm sonundaki bir bağlantıya bırakmıyoruz. Anthropic (2025), araştırma sisteminin kendi iç araştırma değerlendirmesinde tek ajanlı Claude Opus 4’ten %90,2 daha iyi sonuç aldığını ve bunu bir sohbetin yaklaşık 15 katı token harcayarak yaptığını raporluyor. Bir web tarama benchmark’ı (kıyaslama) olan BrowseComp’ta ise performans varyansının kabaca %80’ini tek başına token kullanımı açıklıyor. Aynı yazıya göre tek bir ajan bir sohbetin yaklaşık 4 katı token harcıyor; yani çok ajanlı sistem, tek ajanın harcadığının kabaca dört katını harcıyor. Bunu yukarıdaki aritmetikle birlikte okuyun; ikisi çelişmiyor: bölme, yapılan iş birimi başına bağlam token’ı kazandırabilir ve toplamda yine de çok daha pahalıya gelebilir, çünkü eklediğiniz ajanlar aynı işi üçe bölmüyor, daha çok iş yapıyor. Bölüm 28.3’teki kazanç transkript üzerindedir, faturada değil.

O sistemde, bu bölümün token aritmetiğinin göremediği ikinci bir kaldıraç daha var ve muhtemelen daha büyük olanı o: sistem, ucuz uzmanların (Claude Sonnet 4) üstünde pahalı bir koordinatör (Claude Opus 4) çalıştırıyor. Token başına maliyet, tek ajanda bulunmayan bir ayar düğmesidir ve karşılaştırmaya token sayılarından önce girmelidir. Buna bir gerçek daha eklenmeli: güncel fiyat listelerinde çıktı token’ları tipik olarak girdi ücretinin dört ila sekiz katıdır, oysa yukarıdaki modelde bedava sayıldılar.

Bir uzmanın raporu güvenilmeyen girdidir. Uzmanın okuduğu her şey — bir web sayfası, bir destek talebi (ticket), bir PDF — özeti üzerinden koordinatöre ulaşabilir ve koordinatörün bir bulguyu bir talimattan ayırmasının yolu yoktur. Bağlam güvenlik duvarı hacmi süzer, yetkiyi değil. Raporlara, koordinatörün okuduğu değil ayrıştırdığı sabit bir şema verin ve düşük yetkili bir uzmanın düzyazısının yüksek yetkili bir koordinatörün ne yazacağına karar vermesine asla izin vermeyin. Bu, içinde bir dil modeli olan bir confused deputy’dir (şaşkın vekil: yüksek yetkili bir programın, daha az yetkili bir tarafça kandırılıp yetkisini onun adına kullanması) ve Bölüm 36 bunu ciddiye alan yer.

Hata ayıklama niteliksel olarak zorlaşır. Tek ajan tek transkript üretir. Beş ajan beş tane üretir, artı aralarındaki delegation kararları ve “bunu neden böyle cevapladı” sorusu artık dağıtık bir izi (trace) yeniden kurmayı gerektirir. Bölüm 23’teki argüman — ajanın, açık uçluluk kazanmak için hata ayıklanabilirlikten vazgeçtiği — burada bir üst düzeyde ve daha keskin biçimde yine geçerli.

Yani bölmeden önceki test iki taraflıdır:

  token kazandırıyor mu?   hesaplayın. Yukarıdaki tablo biçimini gösteriyor.
  doğru kalıyor mu?        ölçün: tek ajana karşı, kendi görevinizde.

İkincisini cevaplayamıyorsanız bir mimariyi değerlendirmiş olmazsınız; bir şema seçmiş olursunuz.

28.5 En zor kısım paylaşılan durumdur

Yukarıdakilerin hepsi uzmanların yalnızca okuduğunu varsayıyor. İki ajan aynı şeye yazabildiği anda bir dağıtık sisteminiz olur ve sıradan dağıtık sistem problemleri, sıradan dağıtık sistem disiplini olmadan gelir.

Paylaşılan durumun bozulmasının dört yolu

problem	burada nasıl görünür
Kayıp güncelleme	iki ajan bir dosyayı okur, ikisi de düzenler, ikinci yazma birincisini siler. İkisi de fark etmez ve ikisi de hata bildirmez
Tutarsız okuma	bir uzman, bir diğerinin değiştirmekte olduğu durumu okur ve yarı yazılmış bir değerden kendinden emin akıl yürütür
Çelişen sonuçlar	iki ajan aynı veriden zıt cevaplara varır ve koordinatörün seçim kuralı yoktur — Bölüm 26 bir modelin çelişkilerle ne yaptığını ölçtü: model çoğunlukla kaçamak cevap veriyor
Belirlenimsizlik	çalıştırma yeniden üretilemez, dolayısıyla dün gördüğünüz hata bugün yeniden yaratılamaz

Bu dördü klasik dağıtık sistem sorunlarıdır; dağıtık sistemler eğitimi sizi tam da bunlara hazırlar. Pratikte baskın olanlar ise hiç bu türden değil. Cemri vd. (2025), uzmanlarca etiketlenmiş 150 izden, on dört kusur biçimini üç kategoride toplayan bir taksonomi kurdu (etiketleyiciler arasında \(\kappa\) = 0,88); sonra bir LLM hakemiyle yedi çok ajanlı çatıdan 1.600’den fazla izi etiketledi. Onların sayımında en sık görülen biçimlerin hiçbiri yukarıdaki tabloda yok:

Ajanların kendi kusurlarının en sık beş biçimi ve etiketlenen tüm kusurlar içindeki payları (Cemri vd. 2025)

problem	burada nasıl görünür
Adım tekrarı (%15,7)	bir ajan zaten yapılmış işi yeniden yapar — Bölüm 28.3’teki tekrar katsayısı d’nin gözlenmiş hâli
Akıl yürütme–eylem uyumsuzluğu (%13,2)	ajanın akıl yürütmesi bir şey söyler, bir sonraki eylemi başka bir şey yapar
Durma koşullarının farkında olmama (%12,4)	ajanlar görevin bittiğini fark etmez ve durmaları gereken noktayı çoktan geçip devam eder
Görev tanımına uymama (%11,8)	bir ajan, görevin belirttiği bir kısıtı — bir biçimi, bir kapsamı, bir sınırı — yok sayar
Eksik ya da yanlış doğrulama (%8,2 + %9,1)	sentezi hiçbir şey kontrol etmez ya da kontrol yanlış bir cevabı geçirir — ve sentez, Bölüm 23’ün bozulduğunu bulduğu türden bir adımdır

Bu bölümün argümanını birebir tarif eden iki biçim ise o sayımlarda nadir: bilgi saklama (%0,85) — bir uzmanın bildiği bir şeyi raporuna koymaması — ve diğer ajanın girdisini yok sayma (%1,9). Bunu dikkatle okuyun: bir iz, ajanın ne söylediğini gösterir, neyi söylemediğini değil; dolayısıyla bir ihmal kusurunu etiketlemek zordur ve düşük bir sayı, sorunun nadir olduğu anlamına gelmeyebilir.

İkinci tablonun düzgün bir çaresi yok; makalenin kendi vardığı sonuç, bu kusurları gidermenin prompt’ta birkaç rötuştan fazlasını gerektirdiği. İlk tablodaki sorunların önlemleri ise sıkıcıdır; sıkıcıdırlar, çünkü işe yararlar:

• Her ajana kendi çalışma alanını verin. Bir dal, bir karalama dizini, bir veri tabanı işlemi (transaction). Seçtiğiniz bir noktada, bilerek birleştirin.
• İşlem sınırına açıkça karar verin. Bir uzmana gönderilen alt görev atomik mi, yoksa yarı yarıya başarılı olabilir mi? Olabiliyorsa her yan etkinin bir telafi eylemine ihtiyacı var — saga örüntüsü — çünkü sizin yerinize geri alacak dağıtık bir işlem yok. Saga, uzun bir işlemi adımlara bölüp her adım için bir geri alma adımı tanımlamaktır: örneğin “ödemeyi al” başarılı olup “rezervasyon yap” başarısız olursa “ödemeyi iade et” çalışır. Aşağıdaki idempotent araçlar kuralı bunun öteki yarısıdır.
• Yazmaları tek iş parçacıklı yapın. Bir ajan — genellikle koordinatör — her değişikliğin sahibidir. Uzmanlar önerir; sahip uygular.
• Araçları idempotent (aynı istek tekrarlandığında ek etki doğurmayan) yapın, Bölüm 24’e göre, çünkü yeniden denemeler kaçınılmazdır ve ikinci bir create_invoice bir yuvarlama hatası değildir.
• Yalnızca eklemeyi (append-only) tercih edin. Birinin sonradan uzlaştırdığı bir öneri log’u, paylaşılan durumu eşzamanlı değiştirmekten iyidir ve hata ayıklayabileceğiniz bir iz bırakır.
• Ne yaptığınızın adını koyun. Durumu, önerilerin yalnızca eklenen bir log’u olarak tutmak event sourcing’e (olay kaynaklama) yakındır; her değişikliği tek bir sahibin yapması single-writer (tek yazar) ilkesidir; her ajanın kendi kopyası üzerinde çalışması ve çakışmaların yalnızca birleştirme anında denetlenmesi iyimser eşzamanlılıktır (optimistic concurrency) — karşıtı, yazmadan önce kaynağa kilit (lock) almaktır. Üçünün de literatürü onlarca yıllık ve bir ajan çatısının size vereceği her şeyden iyi.

28.6 Kuyruklar ve zehirli bir mesajla ne yapılacağı

Önceki alt bölüm, iki ajanın aynı duruma uzanmasıyla ilgiliydi. Bu alt bölüm ise aralarındaki iletişim kanalıyla ilgili; bu da, fark etmemiş olsanız bile zaten verdiğiniz bir karardır.

Doğrudan çağrılar varsayılandır ve basittirler, ama çağıranın ömrünü çağrılanınkine bağlarlar: uzman çökerse ya da takılırsa koordinatör de onunla birlikte bekler ya da düşer. Bir kuyruk ikisini birbirinden ayırır ve kuyrukların her zaman sağladığı şeyleri sağlar: geri basınç (backpressure: yavaş tüketici, işe boğulmak yerine üreticileri bekletir), yeniden denemeler ve bir tarafı diğerine dokunmadan yeniden başlatma imkânı.

Aşağıdaki üç kural sıradan altyapı pratiğidir; ama burada payload’lar (iletilen verinin kendisi) mesajdan çok konuşmaya benzediği için çoğu zaman atlanır:

• Yeniden denemeleri sınırlayın. Bir zaman aşımı ya da hız sınırı yeniden denemede geçebilir; ama gerçek bir nedenle — bozuk bir girdi, modelin karşılayamayacağı bir istek — başarısız olan bir ajan görevi genellikle yine başarısız olur, çoğu zaman birebir aynı biçimde ve her zaman pahalıya: her yeniden deneme taze bir model faturasıdır. Bölüm 23’ün adım bütçesi, bir üst düzeyde.
• Bir dead-letter queue’nüz (tekrar denemelere rağmen işlenemeyen mesajların incelemeye ayrıldığı kuyruk) olsun ve onu okuyun. İşlenemeyen bir görev, bir insanın baktığı bir yere gider. Bu olmadan zehirli mesajlar (poison message: her denemede yine işlenemeyip kuyruğa geri dönen mesaj) ya sonsuza kadar döner ya da yok olur; ikisi de bir uyarı almaktan kötüdür.
• Payload’u kendi kendine yeten yapın. Başka yerdeki bir duruma atıfta bulunan bir mesaj — yaptığımız analize devam et — yeniden denenemez ya da tekrar oynatılamaz. Bu, Bölüm 28.2’deki durumsuz uzman kuralının taşıma katmanınca dayatılan hâlidir.

Dead-letter queue — tekrar denemelere rağmen işlenemeyen bir görevin, sonsuza dek yeniden denenmek ya da kaybolmak yerine bir insanın okuması için düştüğü yer. ↩︎

28.7 Çatılar, 2026 itibarıyla

Buradaki her çatı sizi bir denetim akışı modeline sokar ve o tercih API’den daha önemlidir. Bu alt bölüm eskiyecek; sürümleri kontrol edin.

Altı çatı ve taahhütleri

çatı	sizi neye sokar
LangGraph	açık bir durum makinesi olarak döngü. Ayrıntılıdır ve denetim akışı inceleyebileceğiniz bir şema olmayı hak ettiğinde doğru tercihtir
OpenAI Agents SDK	handoff’ları ve korkulukları (guardrail) olan küçük bir döngü; Bölüm 23’teki on dört ifadelik döngünün, üretim için gereken eklerle donatılmış hâline en yakın şey. Bir ajanı araç olarak sunarak delegation’ı da destekler
Pydantic AI	tipli araçlar ve tipli sonuçlar; ajanlar arasındaki sınır düzyazı değil doğrulama gerektirdiğinde en güçlüsü
CrewAI	birinci sınıf kavramlar olarak roller ve görevler. Sizi çalışan bir demoya hızla ulaştırır; ama soyutlaması, istemeyebileceğiniz bir topolojiyi dayatır
AutoGen	ajanların birbiriyle konuştuğu, konuşmalı çok ajanlılık. Güçlüdür ve Bölüm 28.4’teki kusurları üretmeye en yatkın örüntüdür. Artık bakım modunda: Microsoft yeni projeleri halefi Microsoft Agent Framework’e yönlendiriyor
Google ADK	dağıtılabilir servisler olarak ajanlar; prototiplemeye değil işletmeye yönelmiş

Hepsinden uzun ömürlü tavsiye: önce tek ajanı, çatısız kurun. O zaman bunlar arasındaki seçimi, denetim akışınızın neye ihtiyaç duyduğunu bilerek yaparsınız; henüz sorunuz yokken başkasının cevabını benimsemiş olmazsınız.

28.8 Sezgi kontrolleri

Her birini açmadan önce cevaplayın. İkisi bu bölümdeki aritmetikle çözülüyor — token modeli ve hataların birikme biçimi — diğer dördü ise bölümün savunduğu tasarım kararları. Bu kararların hepsini sistemi kurmadan önce değiştirmek, kurduktan sonra değiştirmekten ucuzdur.

Not1. Bir görev ne zaman birden çok ajana ihtiyaç duyar?

Üç yapısal gerekçeden biri geçerli olduğunda: iş bir pencerenin tutması gerekenden fazla malzeme üretiyor, bağımsız alt görevler gerçekten aynı anda çalışabiliyor ya da farklı alt görevler farklı araçlar, izinler veya modeller istiyor. “Görev karmaşık” o listede yok — karmaşıklık daha uzun bir prompt ve daha iyi araçlarla hallolur. Tek ajan baseline’dır ve ikinci ajanın onu bir ölçümde yenmesi gerekir.

Not2. İşi ajanlara bölmek token kazandırır mı?

İşin ne kadar malzeme ürettiğine bağlıdır ve aritmetik bunu gösterir. 200 token’lık gözlemlerle altı adım, üç ajan olarak 1,20 kata mal oluyor — bölmek daha pahalı, çünkü ajan başına sabit bedeli üç kez fazladan ödüyorsunuz. 3.000 token’lık gözlemlerle yirmi dört adım 0,34 kata mal oluyor — üçte iki tasarruf, çünkü tek bir ajan her gözlemi sonraki her çağrıya taşır. Belirleyici olan üretilen malzemedir; zorluk değil. Sonra aritmetiğin ne varsaydığını söyleyin: prompt önbellekleme yok ve uzmanlar arasında tekrar yok. İkisinden birini gevşetin, bölme tümüyle kazandırmayı bırakabilir.

Not3. Token kazancı size neye mal oluyor?

Bilgiye. Kazanç tam da koordinatörün gözlemler yerine bir özet görmesi nedeniyle vardır, dolayısıyla uzmanın gördüğünün kayıplı bir sıkıştırması üzerine akıl yürütür. Hatalar da koordinatörün kontrol edemeyeceği bir sınır boyunca birikir: %90 doğrulukta üç uzman, hataları bağımsızsa ve sistemin doğru olması için üçünün de doğru olması gerekiyorsa yaklaşık %73 verir; hataların ne kadar örtüştüğüne göre sonuç %70 ile %90 arasında herhangi bir yerde olabilir. Bunların hepsi koordinatörün kendi sentezinden önce — yani dönenleri birleştirme adımından; Bölüm 23’teki ajan da tam orada bozulmuştu.

Not4. Yazma ağırlıklı iş neden paralelleşmez?

Çünkü eşzamanlı yazmalar onu bir dağıtık sistem yapar: ikinci yazmanın birincisini hatasızca sildiği kayıp güncellemeler, yarı yazılmış durumun tutarsız okumaları, koordinatörün çözecek kuralı olmadığı çelişen sonuçlar ve dünkü hatayı yeniden üretilemez kılan belirlenimsizlik. On belgeyi okuyan on ajan on kat hıza yaklaşabilir; tek bir kod tabanını düzenleyen on ajan ise — her biri ayrık bir parçanın sahibi değilse — üstlenmeye niyetli olmadığınız bir problemdir.

Not5. Handoff mu delegation mı?

Delegation, durumsuz uzmanlarla. Koordinatör konuşmayı elinde tutar, kendi kendine yeten bir alt görev gönderir ve bir sonuç alır — bu da bağlam güvenlik duvarını korur ve her uzmanı yeniden denenebilir kılar. Bir handoff, konuşmanın kendisini geçirir; dolayısıyla ikinci ajanın çıktısı aynı transkripte iner ve onu özetleyecek ya da reddedecek bir koordinatör kalmaz. Önceki çağrıları hatırlayan bir uzman ise kayıtlarının ne zaman geçersiz sayılacağına dair kuralı olmayan bir dağıtık önbellektir.

Not6. Hangi çatıyı kullanmalısınız?

Önce tek ajanı çatısız kurun. Bunların her biri sizi bir denetim akışı modeline sokar — açık bir durum makinesi, roller ve görevler, konuşmalı ajanlar — ve o taahhüt API’den daha önemlidir. Denetim akışınızın neye ihtiyacı olduğunu bildikten sonra seçmek, sorunuz olmadan başkasının cevabını benimsemekten farklı bir faaliyettir.

28.9 Mülakat soruları

Kaynak konusunda — Bölüm 2’deki çekincenin aynısı. Bu sorular, kitabın kullandığı iki güvenilir açık kaynakta tekrar tekrar karşımıza çıkıyor; ayrıca bu bölümün aritmetiğinin cevaplanabilir kıldığı sorular da var.

28.9.1 Ödünleşimi anlayıp anlamadığınızı sınayanlar

S: Ne zaman çok ajanlı bir mimari kullanırsınız?

Üç yapısal gerekçeyi adlandırın — bağlam hacmi, gerçek paralellik, farklı araç ya da izinler — ve görev karmaşıklığının bunlardan biri olmadığını açıkça söyleyin. Sonra maliyetlendirdiğinizi gösterin: bölmek iş çok malzeme ürettiğinde kazandırır, çünkü tek bir ajanın maliyeti adım sayısının karesiyle büyür ve kısa işte kaybettirir, çünkü ajan başına sabit bedel her ajanda ödenir. En güçlü cevap kazancın neye mal olduğunu adlandırır: koordinatör gözlemleri değil özetleri görür.

S: Yazma ağırlıklı iş neden paralelleşmez?

Çünkü alışıldık garantilerin hiçbiri olmadan bir dağıtık sisteme dönüşür. Somut kusurları verin — hata vermeyen kayıp güncellemeler, tutarsız okumalar, koordinatörün çözemediği çelişen sonuçlar — ve sonra gösterişsiz önlemleri: tek yazar, bilerek birleştirilen ajan başına çalışma alanları, idempotent araçlar, yalnızca eklenen öneriler.

28.9.2 Bir tane yayına alıp almadığınızı sınayanlar

S: Çok ajanlı sisteminiz, yerini aldığı tek ajandan daha az doğru. Ne oldu?

İki aday var ve onları transkriptlerden ayırt edebilirsiniz. Ya özetler bir şey kaybetti — uzman pencerelerinde bulunduğu hâlde rapora girmemiş bilgi arayın — ya da hatalar birikti. Bunu, her uzmanı tek başına ölçüp çarpımı (bağımsızlık varsayımı) ve [%70, %90] bandıyla karşılaştırarak, sonra sistemi uçtan uca ölçerek kontrol edersiniz; çarpım tek başına cevap değildir. Bu karşılaştırmanın geçişten önce var olması gerektiğini ve tek ajanın tam da bu nedenle baseline olduğunu söyleyin.

S: Beş ajanlı bir sistemde nasıl hata ayıklarsınız?

Bunun bir dağıtık izleme problemi olduğunu kabul ederek ve önceden ona göre kurarak: her delegation’dan geçen bir korelasyon kimliği (aynı kullanıcı isteğine ait her mesajın taşıdığı tek bir tanımlayıcı), kalıcılaştırılmış her uzman transkripti ve birinci sınıf olay olarak kaydedilmiş koordinatör delegation kararları. Şunu da ekleyin: bu, mimarinin gerçek bir maliyetidir — tek ajan tek transkript üretir ve bu, bilerek vazgeçtiğiniz bir hata ayıklama özelliğidir.

28.10 2026 alet çantası

Burada hiçbir şey bir modele karşı çalıştırılmadı. Maliyet modeli, önceki bölümlerde ölçülmüş sabitler üzerinde aritmetiktir, dolayısıyla yığın tek satır — ve aşağıdaki çatılar, aritmetik bölmeyi söyledikten sonra uzanacağınız şeylerdir, öncesinde değil.

Bu sayıların çıktığı yığın

kütüphane	kullanılan sürüm	burada ne işe yarıyor
Python	3.14.5	Bölüm 28.3’teki maliyet modeli aritmetiktir ve başka bir şeye ihtiyaç duymaz

Bilmeye değer, yukarıda kullanılmadı:

Daha geniş ekosistem, yazıldığı andaki sürümler

kütüphane	güncel sürüm	ne zaman kullanılır
langgraph	1.2.11	açık çizgeler, checkpoint’ler (kontrol noktası) ve insanın araya girdiği (human-in-the-loop) kesintiler
openai-agents	0.22.0	çok az makineyle handoff’lar ve korkuluklar
pydantic-ai	2.35.3	ajanlar arasında tipli sınırlar
crewai	1.15.18	roller ve görevler, demoya en hızlısı
autogen-agentchat	0.7.5	konuşmalı çok ajanlı araştırma; bakım modunda, yeni üretim işine onunla başlamayın
google-adk	2.8.0	dağıtılabilir servisler olarak paketlenmiş ajanlar

28.11 Lab: ikinci ajanı hak edin

Buradaki asıl mesele sıralama: bölmeyi kurmadan önce hesaplıyorsunuz; bu da labı 2. adımda bitirmenize izin verildiği anlamına geliyor.

28.11.1 Adım 1 — tek ajanı kurun

Bir döngü, görevin ihtiyaç duyduğu araçlar, bir adım bütçesi. Yirmi gerçek görevde puanı, token’ları ve wall-clock süresini ölçün. Yenilecek sayı budur.

28.11.2 Adım 2 — bölmeyi kurmadan önce hesaplayın

Gözlemlediğiniz adım sayısını ve gözlem boyutunu alıp Bölüm 28.3’ün aritmetiğini çalıştırın. Model bölmenin daha pahalı olduğunu söylüyorsa bunu yazın — gerçek bir sonuçtur ve cevabın çoğudur. Orada durmak, yalnızca kararın tamamı maliyetse doğrudur. 2. ya da 3. gerekçe için bölüyorsanız aritmetiğin lehinize çıkması zaten beklenmiyordu: paralellik wall-clock süresi kazandırır, yalıtım bir izin sınırı sağlar; ikisi de token harcamaya değer. Üçünden hangisini satın aldığınızı söyleyin ve fiyatı ona göre değerlendirin.

28.11.3 Adım 3 — koordinatörü ve üç uzmanı kurun

Handoff değil, delegation. Durumsuz uzmanlar. Koordinatör özetleri görür. Her uzman, Bölüm 23’teki döngünün kendi sistem prompt’u ve araç kümesiyle çağrılan bir kopyasıdır: girdisi kendi kendine yeten bir görev tanımı, çıktısı koordinatörün ayrıştırdığı sabit şemalı bir rapor.

28.11.4 Adım 4 — aynı yirmi görevi ölçün

Puan, token, wall-clock süresi. Üçünü de raporlayın; tek ajan kazandıysa bile.

28.11.5 Adım 5 — özetlerin ne kaybettiğini bulun

Çok ajanlı sistemin yanlış bildiği beş görevi alın ve uzman transkriptlerini okuyun. Bilgi ne sıklıkla bir uzmanın penceresinde mevcut ve raporunda yoktu?

28.11.6 Adım 6 — bir yazma ekleyin

İki uzmana aynı kaynağı değiştirme yeteneği verin. Yirmi görev çalıştırın ve tutarsızlıkları sayın. Mimarinizin bir dağıtık sistem olup olmadığına karar veren adım budur.

28.11.7 Neyi teslim edeceksiniz

Üç sütunlu (puan, token, wall-clock) iki sonuç tablosunu, 5. adımdaki sayımı, 6. adımdaki tutarsızlık sayımını ve tek bir cümleyi: ikinci ajan yerini hak etti mi?

28.12 Alıştırmalar

1. Baseline’ı yenin. Birden çok ajana ihtiyaç duyduğunu varsaydığınız bir görev alın. Onu tek ajanla uygulayın. Puanı, maliyeti ve gecikmeyi karşılaştırın ve tek ajan kazandığında bile sonucu raporlayın.
2. Aritmetiği çalıştırın. Gerçek adım sayınızı ve gözlem boyutunuzu ölçün, sonra sisteminiz için geçiş noktasını hesaplayın. Ondan ne kadar uzaktasınız?
3. Kaybolan bilgiyi bulun. Başarısız beş çalıştırma için uzman transkriptlerini okuyun ve cevabın bir uzmanın penceresinde mevcut olup raporunda eksik olma sıklığını sayın.
4. Yarış koşulunu yaratın. İkisi de yazabilen iki ajan için paylaşılan bir durum düzeni tasarlayın. Sonra az önce yarattığınız yarış koşulunu (race condition) ve onu kaldıran en küçük değişikliği tarif edin.
5. Bir kuyruğu zehirleyin. Ajanınızın işleyemeyeceği bir mesaj gönderin. Ne olduğunu izleyin: döngüye mi giriyor, yok mu oluyor, yoksa birinin okuduğu bir dead-letter queue’ya mı ulaşıyor?
6. Hataları biriktirin. Bir uzmanın doğruluğunu yalıtılmış hâlde ölçün, sonra üç uzmanlı sistemin doğruluğunu ölçmeden önce öngörün. Öngörünüzü sonuçla karşılaştırın.
7. Bir ajanı silin. Çalışan bir çok ajanlı sistem alın ve bir ajanı, işini bir komşusuna katarak kaldırın. Ölçün. Kaldırma deneyleri (ablation çalışması) eklemeler kadar bilgi vericidir, ama nadiren çalıştırılır.

28.13 Daha derine

Okumadan önce: tek ajanı kurun ve ölçün. Aşağıdaki her argümanı bir baseline elinizde olduğunda değerlendirmek daha kolay.

Makalelerin ötesi

kaynak	ne olduğu
Building effective agents — Anthropic	işleyen en basit şeyi savunur ve bu bölümün konusuna en iyi karşı ağırlıktır
How we built our multi-agent research system — Anthropic	diğer taraf, üretimden: dağılımın bedelini nerede hak ettiği ve neyi bozduğu
langgraph	incelenebilir bir durum makinesi olarak denetim akışı
openai-agents	küçük ve okunabilir bir döngüde handoff’lar ve korkuluklar
autogen	konuşmalı çok ajanlılık ve kusur biçimlerini kendiniz görmenin en net yolu
crewAI / adk-python	roller ve görevler; servis olarak ajanlar

Birincil kaynaklar

konu	kaynak
her ajanın çalıştırdığı döngü	Yao, Zhao, vd. (2023)
kendini eleştirmenin yanlış bir cevabı neden kurtarmadığı	Huang vd. (2024); Madaan vd. (2023)
ayrı bir arama olarak planlama	Yao, Yu, vd. (2023)
uzun paylaşılan bir bağlamın erişime ne yaptığı	Hsieh vd. (2024)
bu sistemlerin pratikte neden bozulduğu: uzmanlarca etiketlenmiş 150 izden kurulan ve 1.600+ ize uygulanan bir taksonomi	Cemri vd. (2025)
dağılımın üretimdeki savunması ve 15 katlık token faturası	Anthropic (2025)

28.14 Akılda kalması gerekenler

• Tek ajan baseline’dır ve ikinci ajan onu bir ölçümde yenmelidir. Üç yapısal gerekçe geçerlidir — bağlam hacmi, gerçek paralellik, farklı araç ya da izinler. “Karmaşık” değildir.
• Bölmeyi kurmadan önce hesaplayın. 200 token’lık sonuçlarla altı adım, üç ajan olarak 1,20 kata mal olur; 3.000 token’lık sonuçlarla yirmi dört adım 0,34 kata. Belirleyici olan işin ne kadar malzeme ürettiğidir, ne kadar zor olduğu değil. İki sayı da prompt önbelleklemenin olmadığını ve uzmanlar arasında tekrar bulunmadığını varsayıyor: önbelleklemeyi açın, 0,34 kat 0,65 kata çıkıyor ve dokuz hücrenin üçü tersine dönüyor; her uzmanın adil payının iki katını yapmasına (d = 2) izin verin, hiçbir hücre kazandırmıyor.
• Kazanç bilgiyle ödenir. Koordinatör özetleri görür, çünkü mekanizma budur; dolayısıyla kayıplı bir sıkıştırma üzerine akıl yürütür. %90 doğrulukta üç uzman, sistemi [%70, %90] arasında bir yere taşır: hataları hiç çakışmıyorsa %70, bağımsızsa %72,9, tamamen örtüşüyorsa %90. Sisteminizin bu bantta nerede durduğu hesaplanamaz, ölçülmelidir. Hepsi de koordinatörün kendi sentezinden önce; Bölüm 23’teki ajanın bozulduğu adım da bu türdendi.
• Okuma ağırlıklı iş paralelleşir; yazma ağırlıklı iş paralelleşmez. Eşzamanlı yazmalar bir mimariyi, hata vermeyen kayıp güncellemeleri ve yeniden üretilemeyen hataları olan bir dağıtık sisteme çevirir.
• Tek yazar, ajan başına çalışma alanı, idempotent araçlar, yalnızca eklenen öneriler. Bu önlemler sıkıcıdır, çünkü işe yarayanlar onlardır.
• Durumsuz uzmanlara görev verin; konuşmayı devretmeyin. Kendi kendine yeten bir alt görev yeniden denenebilir ve bağlam güvenlik duvarını korur.
• Hata ayıklama, bilerek ödediğiniz bir bedeldir. Tek ajan, tek transkript. Beş ajan korelasyon kimlikleri, kalıcılaştırılmış uzman transkriptleri ve kaydedilmiş delegation kararları ister — ilk olaydan sonra değil önceden kurulmuş.

Anthropic. 2025. How We Built Our Multi-Agent Research System. Anthropic Engineering. https://www.anthropic.com/engineering/multi-agent-research-system.

Cemri, Mert, Melissa Z. Pan, Shuyi Yang, vd. 2025. Why Do Multi-Agent LLM Systems Fail? https://arxiv.org/abs/2503.13657.

Hsieh, Cheng-Ping, Simeng Sun, Samuel Kriman, vd. 2024. “RULER: What’s the Real Context Size of Your Long-Context Language Models?” Proceedings of COLM.

Huang, Jie, Xinyun Chen, Swaroop Mishra, vd. 2024. “Large Language Models Cannot Self-Correct Reasoning Yet”. Proceedings of ICLR.

Madaan, Aman, Niket Tandon, Prakhar Gupta, vd. 2023. “Self-Refine: Iterative Refinement with Self-Feedback”. Advances in Neural Information Processing Systems.

Yao, Shunyu, Dian Yu, Jeffrey Zhao, vd. 2023. “Tree of Thoughts: Deliberate Problem Solving with Large Language Models”. Advances in Neural Information Processing Systems.

Yao, Shunyu, Jeffrey Zhao, Dian Yu, vd. 2023. “ReAct: Synergizing Reasoning and Acting in Language Models”. Proceedings of ICLR.