Tek Ajandan Orkestratöre

Alt Ajanlar, Ajan Sürüleri ve Koordineli Çalışma.

Tek bir yapay zekâ ajanı planlama yapabilir, araştırabilir, yazabilir, kontrol edebilir ve araç kullanabilir. Ancak aynı iş akışına birden fazla ajan girdiği anda farklı bir problem sınıfı ortaya çıkar. Soru artık yalnızca "Bu ajan görevi yapabilir mi?" değildir. Asıl soru şudur: Birden fazla özerk çalışma birimi sorumluluğu, bağlamı, zamanı, maliyeti ve kararları nasıl paylaşmalı ki paralellik koordinasyon kaosuna dönüşmesin?

Orkestrasyon tam burada başlar.

Çok ajanlı sistemler ilk bakışta doğal bir yükseltme gibi görünür: Bir ajan faydalıysa on ajan on kat faydalı olmalıdır. Pratikte bu denklem doğru değildir. Daha fazla ajan önce kaliteyi değil, olası etkileşimlerin sayısını artırır. Aynı araştırmayı tekrar edebilir, aynı belgenin farklı sürümleriyle çalışabilir, birbirleriyle çelişebilir, birbirlerini bekleyebilir, maliyeti katlayabilir veya erken bir hatayı birçok iş koluna taşıyabilirler.

Bu nedenle profesyonel bir çok ajanlı sistem yalnızca iyi tanımlanmış bireysel rollerden oluşamaz. Bir koordinasyon mimarisine ihtiyaç duyar. Görevi kim bölecek? Kim kimi başlatabilir? Hangi ajan hangi bağlamı görecek? Hangi işler güvenli biçimde paralel yürüyebilir? Sonuçlar nerede tekrar birleşecek? Çelişen bulgular nasıl çözülecek? Bir alt ajan hata verirse, geç kalırsa veya beklenmedik bir yöne giderse ne olacak? Ve hangi durumda tek bir ajan aslında daha iyi tasarımdır?

Bu makalenin temel tezi şudur:

Gerçek performans sıçraması daha fazla ajandan değil, daha iyi orkestrasyondan doğar.

Daha fazla ajan kalite kanıtı değildir

"Daha fazla ajan = daha fazla zekâ" şeklindeki sezgisel denklem aşırı mimariye davetiye çıkarır. Bir sistem teknik olarak etkileyici görünebilir ve yine de dikkatle yönetilen tek bir ajandan daha kötü sonuç verebilir.

Sebep basittir: Her yeni birim yeni koordinasyon maliyeti getirir. Ek bir ajan için görev, bağlam, yetki, çıktı biçimi, geri dönüş yolu ve sonucunun ortak durumu nasıl etkileyeceğini belirleyen bir kural gerekir. Beş ajan paralel başlatıldığında yalnızca beş iş kolu değil; beş potansiyel gecikme, beş hata kaynağı ve sonuçlar arasında birçok olası çatışma da oluşur.

Bu nedenle doğru soru kaç ajanın mevcut olduğu değildir. Soru şudur:

Görevin hangi parçaları gerçekten ayrı yürütülebilecek kadar bağımsızdır ve sonuçları daha sonra güvenilir biçimde nasıl yeniden birleştirilecektir?

Çok ajanlı tasarım ile kontrolsüz ajan çoğaltma arasındaki sınır burada başlar.

Rolden orkestrasyona geçiş

Önceki makalede tekil rol merkezdeydi: Orkestratör, uzman, inceleyici, dokümantasyon işlevi ve insan karar yetkisi. Bu katman bir birimin neden sorumlu olduğunu açıklar.

Orkestrasyon ise başka bir soruya cevap verir: İş, bağlam, durum ve kontrol bu birimler arasında nasıl hareket eder?

Bir rol mükemmel tanımlanmış olabilir ve yine de kötü bir çok ajanlı sistemin içinde çalışabilir. Örneğin bir araştırma ajanı kusursuz bir rol sözleşmesine sahip olabilir. Fakat üç başka ajanla aynı görevi yapıyorsa, eski bir proje sürümünü kullanıyorsa veya ürettiği sonuç hiçbir zaman nihai senteze ulaşmıyorsa toplam mimari zayıf kalır.

Bu yüzden çok ajanlı orkestrasyon iyi promptların bir koleksiyonu değildir. Özerk veya yarı özerk bileşenler arasındaki iş akışının tasarımıdır.

En az beş akış koordine edilmelidir:

Görev akışı — hangi iş nereye gider?

Bağlam akışı — hangi bilgi iş ile birlikte taşınır?

Kontrol akışı — sonraki adıma kim karar verir?

Durum akışı — hangi sürüm geçerlidir?

Kanıt akışı — bulgular, kaynaklar, testler ve belirsizlikler nasıl aktarılır?

Bu beş akış görünür değilse ortada çok ajanlı bir sistem değil, aynı anda çalışan birden fazla kara kutu vardır.

Her çok ajanlı sistemden önce beş soru

Bir mimari birden fazla ajan kullanmadan önce beş sınamadan geçmelidir.

Bu soruların birkaçına "hayır" cevabı veriliyorsa, iyi araçlara sahip tek bir ajan çoğu zaman daha güçlü mimaridir.

Bu geriye gidiş değildir. Mimari disiplindir.

Mimari harita: Bir grafik olarak ajanlar

Çok ajanlı sistemi bir grafik olarak düşünmek yararlıdır. Ajanlar yalnızca "ekip arkadaşları" değil, bir çalışma ağındaki düğümlerdir. Düğümler arasında görev, bağlam, kontrol, durum veya sonuç taşıyan kenarlar bulunur.

Düğümler

Bir düğüm ajan, deterministik servis, inceleyici, veri erişim katmanı veya insan karar noktası olabilir. Adından çok işlevi önemlidir.

Kenarlar

Bir kenar bir geçişi temsil eder. En az şu soruları cevaplamalıdır: Ne aktarılıyor, hangi formatta, hangi sürüm geçerli, geçişi kim tetikleyebilir ve hata olursa ne olur.

Durum

Grafiğin ayrıca izlenebilir bir proje durumuna ihtiyacı vardır. Aksi halde iki ajan aynı anda iki farklı gerçeklik üzerinde çalışabilir. Bu nedenle açık durum bilgileri gerekir: Hangi görev açık? Hangi sürüm onaylı? Hangi sonuç yalnızca taslak? Hangi bağımlılık ilerlemeyi engelliyor?

Grafik bakışı kritik bir gerçeği görünür yapar: Çok ajanlı orkestrasyon öncelikle bir model problemi değildir; durum, arayüz ve koordinasyon problemidir.

Örüntü 1: Yönetici ve alt ajanlar

Yönetici/alt ajan örüntüsü en sezgisel mimarilerden biridir. Merkezdeki birim genel görevi tutar, işi alt parçalara böler, uzman alt ajanları çağırır ve sonuçlarını sentezler.

Yöneticinin alanın en iyi uzmanı olması gerekmez. Asıl görevi koordinasyondur: hedefi ve genel durumu korumak, işi anlamlı biçimde parçalamak, gereksiz tekrar yaratmadan delege etmek, sonuçları geri almak, boşluk ve çelişkileri tanımak, gerektiğinde yeni alt görevler üretmek ve nihai çıktının bütünlüğünü üstlenmek.

Bu örüntü özellikle tek ses ve tek sonuç sorumluluğu gereken ürünlerde güçlüdür. Örneğin bir uzman raporu piyasa, teknik, regülasyon ve risk ajanları tarafından paralel hazırlanabilir; yönetici ortak soruyu ve nihai sentezi korur.

Zayıflık darboğazdır. Her karar, her alt ajan ve her sonuç merkezden geçiyorsa yönetici throughput sınırına dönüşebilir. Aynı zamanda tek hata noktasıdır: Yönetici hedefi yanlış anlarsa yanlış işi çok verimli biçimde dağıtabilir.

Bu nedenle yöneticinin maksimum bağlama değil, güvenilir bir genel duruma ve güçlü delegasyon kurallarına ihtiyacı vardır.

Örüntü 2: Uzmanlar arasında handoff

Handoff, yani devir, bir birimin aktif sorumluluğu başka bir birime aktarmasıdır. Bu, yöneticinin bir uzmanı kısa süreli araç gibi çağırmasından farklıdır.

Tipik bir zincir şöyle olabilir:

Triyaj → uzman analizi → inceleme → tamamlama

Triyaj vakayı tanır ve kontrolü doğru uzmana devreder. Uzman sonraki aşamanın sahibi olur ve daha sonra işi inceleyiciye ya da başka bir role aktarabilir.

Handoff, her aşamanın farklı talimatlara ve odaklanmış bağlama ihtiyaç duyduğu durumlarda etkilidir. Merkezi birimin yükünü azaltır ve uzmanların daha dar bağlamla çalışmasını sağlar.

Ancak devir noktalarında klasik bir organizasyon problemi ortaya çıkar: sınırda sorumluluk kaybı. Ne aktarıldığı, hangi varsayımların geçerli olduğu ve hangi konuların açık kaldığı net değilse yeni ajan eksik gerçeklikle başlar.

Bu nedenle handoff yalnızca "buradan devam et" olamaz. Yapılandırılmış bir devir sözleşmesi gerekir.

Örüntü 3: Sıralı zincir

Her çok ajanlı mimari dinamik olmak zorunda değildir. Basit bir zincir son derece sağlam olabilir:

Araştırma → taslak → inceleme → revizyon → dokümantasyon

Her birim önceki çıktıyı işler ve açık tanımlı yeni bir durum üretir.

Avantajları yüksek izlenebilirlik ve düşük koordinasyon karmaşıklığıdır. Dezavantajı gecikmedir: Her adım bir öncekini bekler. Ayrıca erken bir hata tüm zincire taşınabilir.

Sıralı zincirler gerçek bağımlılıklar olduğunda doğrudur. İnceleyicinin anlamlı çalışabilmesi için taslak gerekiyorsa yapay paralellik fayda sağlamaz.

Ana ders şudur: Paralellik bir kalite özelliği değildir. Bağımlılık sıralıysa mimari bunu kabul etmelidir.

Örüntü 4: Fan-out/fan-in ile paralelleştirme

Paralellik, birden fazla alt problem birbirinden bağımsız ele alınabildiğinde değer yaratır.

Fan-out aşamasında ana problem paralel kollara ayrılır. Fan-in aşamasında sonuçlar toplanır ve yeniden birleştirilir.

Bir pazar analizi düşünelim:

Ajan A müşteri segmentlerini inceler, Ajan B rakipleri analiz eder, Ajan C regülasyon çerçevesini kontrol eder ve Ajan D teknik uygulanabilirliği değerlendirir.

Aynı onaylı baseline'ı kullanıyor ve birbirlerinin ara sonuçlarına bağımlı değillerse dört ajan aynı anda çalışabilir. Sonrasında sentez birimi fan-in işlemini yapar.

Asıl tasarım işi fan-out değil fan-in tarafındadır. Çelişkiler, farklı derinlik seviyeleri, uyumsuz formatlar ve rakip öneriler burada yönetilmelidir.

Bu nedenle iyi bir paralel mimari, başlamadan önce sonuçların nasıl birleştirileceğini tanımlar.

Fan-out'tan önce fan-in'i tasarlamak

Birçok çok ajanlı sistem görünen taraftan kurulur: Önce kaç ajanın paralel çalışacağına karar verilir, daha sonra sonuçların nasıl entegre edileceği düşünülür. Bu sıralama entegrasyon borcu yaratır.

Daha profesyonel ilke şudur: Önce fan-in, sonra fan-out. Bir kol başlatılmadan önce hangi tür sonucu döndüreceği ve bu sonucun daha sonra nasıl karşılaştırılacağı, birleştirileceği, sorgulanacağı veya reddedileceği bilinmelidir.

Dört karar özellikle önemlidir:

1. Ortak şema: Paralel ajanlar uyumlu yapıda çıktı verir.

2. Ortak referans: Aynı onaylı baseline üzerinde çalışırlar ve sapmaları açıkça belirtirler.

3. Entegrasyon kuralı: Çıktıların merge, ağırlıklandırma, inceleme veya eskalasyon ile ele alınacağı önceden bellidir.

4. Eksiklik kuralı: Geç kalan veya eksik bir kol sessizce "bulgu yok" olarak yorumlanmaz.

Bu araştırmada özellikle önemlidir. Dört ajan serbest metin döndürürse sentez birimi önce ortak yapıyı yeniden kurmak zorunda kalır. Buna karşılık her biri iddia, kanıt, kaynak, belirsizlik ve sonuç alanlarını ayrı döndürürse sentez çok daha güvenilir olur.

Fark küçük görünür ama mimari etkisi büyüktür: Fan-out artık rastgele metin değil, birleştirilebilir iş ürünleri üretir.

Örüntü 5: Evaluator-optimizer ve bağımsız karşı kontrol

Güçlü bir tasarım üretim ile değerlendirmeyi bilinçli olarak ayırır.

Bir ajan çıktı üretir. İkinci ajan bunu açık kriterlere göre değerlendirir. Uygun değilse sonuç revizyon döngüsüne geri gider. Kriterler karşılanana veya stop koşuluna ulaşılana kadar süreç devam eder.

Aynı mantık farklı sistemlere de dağıtılabilir: Bir model planı hazırlar, başka bir model yapıyı eleştirir, üçüncüsü blindspot arar, son birim bulguları konsolide eder.

Değer model markalarının farklılığından değil, farklı değerlendirme işlevlerinden ve mümkün olduğunca bağımsız perspektiflerden gelir.

Tüm ajanlar aynı promptu, aynı bağlamı ve aynı gizli varsayımları alırsa etkileyici bir "ajan tartışması" aynı hatayı çoğaltabilir.

Örüntü 6: Dinamik sürü

Sürü, statik bir ajan listesinin ötesine geçer. Bir birim görev sırasında yeni ajanlar oluşturabilir, yeni paralel alt problemler açabilir ve aktif işçi sayısını dinamik biçimde değiştirebilir.

Bu güçlüdür; çünkü mimarinin tüm alt problemleri önceden bilmesi gerekmez. İş sırasında yeni eksikler fark edebilir ve bunlara tepki verebilir.

Aynı özellik risk de yaratır. Sınırlar yoksa küçük bir görev onlarca hatta yüzlerce alt ajana dönüşebilir. Her kol bağlam, model çağrısı, araç ve entegrasyon kapasitesi tüketir. Sürü büyüdükçe sonradan değerlendirilmesi gereken çıktı miktarı da büyür.

Bu nedenle sürünün açık bir spawn bütçesi olmalıdır: aynı anda aktif olabilecek maksimum ajan sayısı, maksimum spawn derinliği, toplam alt görev sınırı, token veya maliyet bütçesi, zaman bütçesi ve azalan marjinal değer için durdurma kuralı.

Bu sınırlar olmadan özerklik kaynak tüketimiyle karıştırılır.

Dikey mi yatay mı orkestrasyon?

Özellikle yararlı bir ayrım dikey ve yatay orkestrasyondur.

Dikey orkestrasyonda ana ajan genel görevi tutar ve altında kısa ömürlü alt ajanlar çağırır. Alt ajanlar sınırlı işleri bitirip sonuçlarını geri verir. Kalıcı bir proje çalışma alanına sahip değildirler.

Yatay orkestrasyonda birden fazla ajan veya oturum bağımsız ve daha uzun süre yaşayan iş kolları olarak çalışır. Her birinin kendi bağlamı, rolü ve sorumluluk alanı vardır. Araştırma ajanı sürekli kaynakları güncellerken risk ajanı riskleri izleyebilir, delivery ajanı uygulama durumunu takip edebilir.

Dikey model daha kolay kontrol edilir. Yatay model uzmanlaşmayı ve paralelliği daha güçlü ölçekler, ancak senkronizasyon ihtiyacı büyür.

Olgun sistemler çoğu zaman ikisini birleştirir: Gerektiğinde alt ajan çağıran merkezi bir iş kolu ve buna ek birkaç kalıcı uzman bağlamı.

Orkestrasyon için bir olgunluk merdiveni

Her proje en karmaşık çok ajanlı yapıyla başlamamalıdır. Daha yararlı yaklaşım bir olgunluk merdivenidir: Her yeni seviye ancak bir önceki güvenilir çalışıyorsa eklenir.

Bu merdiven bir zekâ sıralaması değildir. Sıkı bağımlı bir görev için Seviye 1, Seviye 5'ten daha profesyonel olabilir. Olgunluk, gereken çalışma biçimini güvenilir taşıyan en düşük mimari karmaşıklığı seçebilmek demektir.

Bu yaklaşım başka bir yanlışı da önler: Platform teknik olarak izin veriyor diye görkemli bir ajan mimarisi kurmak. Gerçek görev tek ajan, iki araç ve bağımsız bir inceleyiciyle daha güvenli çözülebilir.

Handoff sözleşmesi

İş ajanlar arasında hareket ettiğinde geçişin sabit bir formatı olmalıdır. Minimal bir handoff şöyle tanımlanabilir:

Bu sözleşme iki sık hatayı önler: context dumping ve context starvation.

Context dumping, alıcı ajana yalnızca küçük bir kısmı gerekli olduğu halde tüm projeyi verir. Context starvation ise çok az bağlam verip ajanın eksikleri varsayımla doldurmasına yol açar.

İyi handoff mümkün olan en büyük bağlamı değil, en küçük yeterli bağlamı ve gerektiğinde ek bilginin nereden alınacağını taşır.

Bağlam ortak bir veri çöplüğü değildir

Çok ajanlı sistem bilinçli bir bağlam topolojisine ihtiyaç duyar. Üç temel biçim özellikle önemlidir.

Ortak durum

İlgili ajanlar kontrollü bir ortak proje durumuna erişir. Baseline'lar, onaylı kararlar, terminoloji ve geçerli sürümler için uygundur.

İzole çalışma bağlamı

Ajan yalnızca kendi görevi için gerekli dilimi alır. Bu hem dikkat dağınıklığını azaltır hem de alakasız veya hassas bilgilerin gereksiz yayılmasını önler.

Seçici çoğaltma

Bazı bilgiler bilinçli olarak birden fazla bağlama kopyalanır: hedef, kalite kriterleri veya bağlayıcı terminoloji. Kaynak ve sürüm görünür kalmalıdır.

Yanlış mimari şudur: Herkes her şeyi her zaman görür.

Bu işbirlikçi gibi görünür; fakat sıklıkla bağlam aşırı yükü, sürüm belirsizliği ve zor izlenen kararlar üretir.

Durum sahipliği ve yazma çatışmaları

Aynı proje durumunu değiştirebilen ajan sayısı arttıkça şu soru önem kazanır: Hangi gerçeğin sahibi kim?

Ortak klasör veya veritabanı problemi tek başına çözmez. İki ajan aynı spesifikasyonu eşzamanlı değiştirirse son yazan ilk değişikliği sessizce ezebilir. Ayrı sürümler tutarlarsa proje iki uyumsuz gerçekliğe ayrılabilir.

Üç örüntü yardımcı olur:

Single writer: Kritik duruma yalnızca bir birim yazabilir; diğer ajanlar değişiklik önerisi üretir. Daha yavaştır ama çok sağlamdır.

Branch and merge: Ajanlar ayrı durum kollarında çalışır; tanımlı bir entegrasyon birimi değişiklikleri daha sonra birleştirir. Paralelliği artırır fakat çatışma çözümü gerekir.

Event sourcing: Ajanlar otoritatif durumu doğrudan değiştirmez; izlenebilir olaylar veya değişiklik talepleri üretir. Geçerli durum kabul edilen olaylardan oluşturulur.

Birçok bilgi ve proje sistemi için basit bir kural yeterlidir: Kritik baseline'lar read-only'dir; değişiklikler entegrasyon adımı yeni baseline olarak kabul edene kadar öneri statüsünde kalır. Böylece paralellik ortak gerçeği sessizce bozmaz.

Paralelleştirmek bağımlılıkları anlamaktır

Birden fazla ajan aynı anda başlamadan önce görev bir bağımlılık grafiği olarak düşünülmelidir.

B, A'nın çıktısına ihtiyaç duyuyorsa A ve B tamamen paralel çalışamaz. C ve D bağımsızsa paralel olabilir. E her iki sonucu da istiyorsa doğal fan-in noktası oluşur.

Böylece paralellik çok somut bir soruya dönüşür:

Hangi kenar gerçek bağımlılık, hangisi yalnızca alışkanlıktır?

İyi orkestrasyon işi yapay biçimde parçalamadan bağımsız kolları bulur. Kötü orkestrasyon her şeyi paralelleştirir ve senkronizasyon maliyetini daha sonra öder.

Orkestratörün yalnızca hedefe değil bütçelere ihtiyacı vardır

Yalnızca hedef verilen özerk bir yönetici teorik olarak sürekli yeni iş üretebilir. Bu nedenle profesyonel sistemler sonuç hedeflerinin yanında kaynak bütçeleri de tanımlar.

Bütçeler yalnızca maliyet kısıtı değildir. Sistemi önceliklendirmeye zorlar.

Sınırlı bütçe içinde iyi karar veren mimari, sonsuza kadar çalışma izni verilen bir sistemden çoğu zaman daha dayanıklıdır.

Spawn bütçesi: Kaç ajan oluşabilir?

Evrensel doğru bir ajan sayısı yoktur. Görevin genişliği, bağımsızlık derecesi, bağlam, maliyet ve entegrasyon yükü belirleyicidir.

Yararlı bir sezgisel kural şudur:

Gerçek işlevsel ayrım oluşturan en küçük ajan sayısıyla başla. Yalnızca somut bir darboğaz veya açıkça bağımsız yeni görev görünür olduğunda genişlet.

Dinamik spawning'e "gerektiği kadar ajan oluştur" izni vermek yerine daha güçlü bir kural kullanılabilir:

Yeni ajan yalnızca alt görev yeterince bağımsızsa, net bir çıktıya sahipse, mevcut bir rol tarafından zaten karşılanmıyorsa ve beklenen değer kalan bütçeyi haklı çıkarıyorsa oluşturulsun.

Böylece sürü gösteriden kontrollü kaynak mekanizmasına dönüşür.

Backpressure: Sistem işleyebileceğinden fazla iş ürettiğinde

Ajanik sistemler, insanların veya sonraki ajanların inceleyebileceğinden daha hızlı iş üretebilir. Bu klasik bir backpressure problemidir: Bir aşamanın çıktı hızı sonraki aşamanın işleme kapasitesini aşar.

Örneğin araştırma yöneticisi yirmi alt ajan başlatıyor fakat sonuçları yalnızca tek sentez ajanı okuyabiliyorsa araştırma hızla bitebilir; gerçek darboğaz yalnızca ileri taşınır. Daha fazla paralellik kuyruğu ortadan kaldırmaz.

Bu nedenle orkestratör yalnızca spawn limitlerini değil fan-in kapasitesini de bilmelidir. Faydalı kurallar şunlardır: yeterli entegrasyon kapasitesi olmadan yeni kol başlatmamak, tüm sonuçları aynı derinlikte incelemek yerine önceliklendirmek, ek ajanların bilgi getirisi düşüyorsa keşfi durdurmak, yeni kollar açmadan önce ara durumu sıkıştırmak ve entegrasyon kuyruğu dolduğunda yeni işi bekletmek.

Böylece önemli bir operasyonel ölçü ortaya çıkar: ek ajan başına marjinal bilgi kazanımı. Beş yeni ajan yalnızca bilinen bulguların varyasyonlarını getiriyorsa bütçeyi bitirmek yerine durmak daha profesyoneldir.

Sonuçları birleştirmek: Merge, vote ve adjudication

Paralel çalışmadan sonra en zor soru gelir: Farklı sonuçlar tek bir karara nasıl dönüşür?

Birden fazla yaklaşım vardır.

Merge: Birbiriyle rekabet etmeyen bilgiler birleştirilir. Tamamlayıcı araştırma için uygundur.

Vote: Birden fazla ajan karar verir ve çoğunluk kazanır. Basittir ama hepsi aynı yanlış varsayımı paylaşıyorsa tehlikelidir.

Adjudication: Bağımsız bir inceleyici veya yönetici rakip sonuçları kriterlere ve kanıta göre değerlendirir.

Kanıt ağırlıklı sentez: İddialar oy sayısına göre değil; kaynak kalitesi, testler ve kanıt gücüne göre ağırlıklandırılır.

Eskalasyon: Çatışma güvenilir biçimde çözülemiyorsa sessizce ortalama alınmaz; açık karar olarak üst seviyeye taşınır.

Kararın riski yükseldikçe yalnızca çoğunluk mantığı daha az yeterli hale gelir.

Konsensüs doğruluk kanıtı değildir

Birden fazla ajan aynı fikirde olabilir ve yine de yanlış olabilir. Özellikle aynı temel modeli, aynı bağlamı ve aynı kaynakları kullanıyorlarsa bu risk büyür.

Bu nedenle çok ajanlı sistem otomatik olarak bağımsız kanıt üretmez. Gerçek karşı kontrol en az bir önemli faktörde çeşitlilik ister: farklı kaynaklar, farklı değerlendirme kriterleri, farklı roller, farklı model ailesi, farklı arama stratejisi, farklı veri tabanı veya deterministik bir test.

En önemli kural:

Ajan çoğulluğu kanıt çoğulluğu değildir.

Aynı hatanın on kopyasını oylatmak yalnızca çok kendinden emin bir hata üretir.

Straggler, race condition ve kaskad hataları

Ajanlar paralel çalıştığında dağıtık sistemlerden bilinen problemler ortaya çıkar.

Straggler, tüm fan-in'in beklediği yavaş iş koludur.

Race condition, iki ajanın aynı durumu eşzamanlı değiştirmesi ve sonucun zamanlamaya bağlı olmasıdır.

Stale state, bir ajanın diğerleri ilerlemişken eski sürümde çalışmaya devam etmesidir.

Kaskad hata, yanlış ara sonucun birçok aşağı akış ajanına dağıtılması ve sonraki kararları etkilemesidir.

Dairesel handoff, A'nın B'ye, B'nin C'ye, C'nin tekrar A'ya anlamlı yeni durum oluşturmadan devretmesidir.

Bu problemler çok ajanlı sistemlerin yalnızca prompt engineering olmadığını gösterir. Sürümleme, idempotency, lock veya yazma yetkisi, timeout, retry, dead-letter yolları ve açık durum geçişleri gibi yazılım ve süreç mimarisi mekanizmalarına ihtiyaç vardır.

Hata alanlarını izole etmek

Yerel bir hatanın tüm çalışmayı otomatik kirletemediği mimari daha dayanıklıdır. İş kolları bu nedenle hata alanları olarak düşünülmelidir.

Bir araştırma ajanı aynı anda nihai baseline'ı yazma hakkına sahip olmamalıdır. Bir kod ajanı başarısız test yüzünden tüm önceki artefaktları silememelidir. Hatalı bir uzman yalnızca gerçekten ona bağlı sonuçları geçersiz kılmalıdır.

Üç özellik yardımcı olur:

Sınırlı yazma yetkisi: Hata yalnızca kontrol edilen durum alanını etkiler.

Bağımlılık izi: Aşağı akış çıktıları hangi üst akış sonuçlarına bağlı olduğunu bilir.

Rollback noktaları: Onaylı durumlar tüm çalışmayı yeniden başlatmadan geri yüklenebilir.

Böylece hata toleransı retry'dan fazlası olur. Retry yalnızca işi tekrar eder; iyi tasarlanmış hata alanı yerel hatanın sistem hatasına dönüşmesini engeller.

Observability: Kim, neyi, ne zaman ve neden yaptı?

Ajan sayısı arttıkça tek bir sohbet geçmişi kanıt olarak yetersiz hale gelir.

Dayanıklı bir sistem en az şunları kaydetmelidir: run ID ve task ID, ajanlar arasındaki parent/child ilişkisi, ajan rolü ve sürümü, geçerli bağlam veya veri sürümü, kullanılan araçlar, kritik durum değişiklikleri, üretilen artefaktlar, kanıt ve testler, maliyet ve çalışma süresi ile durdurma ve eskalasyon nedenleri.

Observability yalnızca hata ayıklama değildir. Sistemin neden belirli sonuca vardığını ve sapmanın nerede oluştuğunu anlamayı sağlar.

Sürülerde izlenebilirlik özellikle önemlidir. Aksi halde paradoks oluşur: Sistem insandan daha hızlı çalışır ama hangi alt birimin hangi kararı etkilediğini kimse açıklayamaz.

Tekrarlanabilirlik ile uyarlanabilirliği dengelemek

Orkestrasyonda verimli bir gerilim vardır. Tamamen deterministik bir akış kolay tekrarlanır ama yeni bilgiye kötü uyum sağlayabilir. Tamamen dinamik bir sistem çok iyi uyarlanabilir ama test edilmesi ve izlenmesi daha zordur.

Bu nedenle tüm katmanlar eşit derecede esnek olmamalıdır. Dayanıklı bir tasarım sabit durum ve handoff şemaları kullanırken uzman seçimini dinamik bırakabilir. Sert bütçeler koyup bütçe içinde keşif serbestliği verebilir. Analizi dağıtırken nihai yazma hakkını merkezileştirebilir.

Hedef kontrollü değişkenliktir: Uyarlanmanın değer yarattığı yerde dinamik; izlenebilirlik, güvenlik veya tekrarın daha önemli olduğu yerde deterministik olmak.

Bu ayrım değerlendirmeyi de iyileştirir. Hatanın ajan düşünme mantığından mı yoksa istikrarsız koordinasyon arayüzünden mi kaynaklandığı ayrıştırılabilir.

Maliyet ve token ekonomisi

Çok ajanlı sistemler yalnızca işi değil tüketimi de ölçekler.

Her ek ajanın kendi bağlamı vardır, kendi tokenlarını üretir ve araç çağırabilir. Paralellik gerçek zamanı ciddi biçimde azaltırken toplam hesaplama maliyetini artırabilir.

Bu çelişki değildir: Daha hızlı ve daha ucuz farklı optimizasyon hedefleridir.

Bu nedenle mimari en az üç boyutu ayrı ölçmelidir:

1. Wall-clock time: Kullanıcı ne kadar bekler?

2. Hesaplama/token maliyeti: Toplam ne kadar iş üretilir?

3. Kalite artışı: Ek kanıt, kapsama veya güvenilirlik ne kadar yükselir?

Çok ajanlı tasarımın ekonomik olarak anlamlı olup olmadığını ancak bu üç değer arasındaki ilişki gösterir.

Tek ajan ne zaman daha iyidir?

Tek ajan çoğu zaman görev güçlü biçimde sıralıysa, neredeyse tüm adımlar aynı geniş bağlama ihtiyaç duyuyorsa, alt görevler birbirine sıkı bağlıysa, perspektif çeşitliliğinden çok tek biçimli düşünme ve yazma önemliyse, paralelliğin getirisi küçükse, koordinasyon maliyeti beklenen getiriyi aşıyorsa veya çok ajanlı sistemi değerlendirmek asıl görevden daha zor hale geliyorsa daha iyi seçimdir.

En olgun çok ajanlı karar bazen şudur: Çok ajanlı akış kurma.

Pratik örnek: Stratejik uzman raporu

Bir kurumun yeni ürün fikri için güvenilir bir karar raporuna ihtiyacı olduğunu düşünelim.

Kötü mimari hemen yirmi ajanı "her şeyi analiz edin" talimatıyla başlatır.

Daha iyi mimari problemi dört büyük ölçüde bağımsız kola ayıran bir yöneticiyle başlar:

Pazar ajanı: talep, segmentler, rakipler.

Teknik ajan: uygulanabilirlik, bağımlılıklar, entegrasyon riskleri.

Regülasyon/risk ajanı: gereklilikler, belirsizlikler, dışlama kriterleri.

Finans ajanı: maliyet varsayımları, hassasiyetler, ekonomik riskler.

Dört ajan aynı onaylı baseline'ı alır, fakat farklı bağlam dilimleri ve çıktı sözleşmeleriyle çalışır. Paralel yürürler. Ardından sentez ajanı fan-in yapar.

Sentez ajanı çelişkileri pürüzsüzleştiremez. Bir çatışma matrisi oluşturur: Hangi ifadeler çelişiyor? Hangileri farklı varsayımlara dayanıyor? Hangileri ek kanıt gerektiriyor?

İki açık nokta için hedefli yeni alt ajanlar başlatılır. Sonrasında bağımsız inceleyici toplam raporu başlangıçtaki karar kriterlerine göre kontrol eder.

Ortaya çıkan şey "sürü etkileyici görünüyor diye sürü" değildir; ihtiyaca göre genişleyen çalışma mimarisidir.

Orkestrasyon Canvas'ı

Birçok gerçek proje için kompakt bir mimari harita yeterlidir.

İyi bir Canvas, mimarinin gerçekten tasarlanmış mı yoksa yalnızca etkileyici ajan adlarıyla doldurulmuş mu olduğunu görünür yapar.

Üretimden önce yedi stres testi

Çok ajanlı sistem yalnızca ideal koşullarda test edilmemelidir.

1. Tekrar testi: İki ajan aynı işe başlıyor. Yönetici çakışmayı fark ediyor mu?

2. Straggler testi: Bir ajan belirgin biçimde gecikiyor. Tüm çalışma gereksiz yere bloke oluyor mu?

3. Çatışma testi: İki ajan birbirine zıt ama makul sonuçlar veriyor. Savunulabilir çözüm kuralı var mı?

4. Stale-state testi: Bir ajan eski sürümde çalışıyor. Entegrasyondan önce bu fark ediliyor mu?

5. Spawn testi: Bir ajan on yeni ajan oluşturmak istiyor. İhtiyaç ve bütçe kuralları devreye giriyor mu?

6. Bağlam kaybı testi: Handoff gerekli bilgiyi taşımıyor. Alıcı ajan soru mu soruyor, yoksa eksik durumu uyduruyor mu?

7. Kaskad testi: Erken bir ara sonuç yanlış. Hangi aşağı akış çıktılarının etkilendiği belirlenebiliyor mu?

Bu testler modelin güzel konuşmasını değil, koordinasyonun dayanıklılığını ölçer.

Yedi adımlı kurulum yolu

Pratik bir çok ajanlı sistem sürüyle başlamamalıdır.

1. Tekil rolleri stabilize et. Her rol görevini, sınırlarını, yetkilerini ve çıktısını bilmeli.

2. İki rolü sıralı bağla. Temiz bir handoff test et.

3. Yönetici ekle. Delegasyonu ve geri dönüş yolunu görünür yap.

4. İki bağımsız kolu paralelleştir. Yalnızca gerçekten bağımsız olduklarında.

5. Birleştirme ve çatışma çözümünü tanımla. Fan-out'u büyütmeden önce fan-in'i tasarla.

6. Bütçeler, observability ve hata yolları ekle. Mimari burada üretime yaklaşır.

7. Dinamik spawning'i yalnızca ihtiyaç kanıtlandığında aç. Sürü başlangıç noktası değil, ileri seviye genişlemedir.

Bu yol sistem karmaşıklığını problemle orantılı tutar.

Sonuç: Asıl ajan koordinasyon sistemidir

Çok ajanlı sistemler darboğazı değiştirir. Tek ajanlı sistemde ana soru modelin işi yapıp yapamayacağıdır. Birden fazla ajan olduğunda asıl soru sistemin onların işini güvenilir biçimde koordine edip edemeyeceği olur.

İyi yönetici işi böler ama parçalamaz. İyi handoff yeterli bağlamı taşır ama her şeyi kopyalamaz. İyi paralellik gerçek bağımsızlıktan faydalanır. İyi sürü yalnızca açık bütçeler içinde büyür. İyi sentez oyları değil kanıtı tartar. İyi observability sonucun hangi yoldan oluştuğunu görünür kılar.

Bu nedenle temel mimari kural şudur:

Hangi bağımsız değeri ürettiğini, sisteme nasıl bağlanacağını ve sonucunun o koldan çıkıp toplam akışa nasıl geri döneceğini açıklayamıyorsan yeni bir ajan birimi oluşturma.

Bir model grubunu koordine çalışma sistemine dönüştüren şey budur.

Bir sonraki adım teknik koordinasyonu organizasyon sorusuna taşır: Ajanlar yalnızca bir yöneticinin altında değil, daha dağıtık rol ve karar yapılarında çalıştığında işbirliği nasıl değişir? Serinin sonraki katmanı burada başlar.

Daha fazla okuma için açık kaynaklar