Temel Yapay Zeka Web Oluşturucularının Ötesinde: Gerçek Agent Özerkliğine Ulaşmak

Kullanıcı Deneyimini Anlamak ve Temel Sorunu Tanımlamak

Kullanıcının bolt.new ile mevcut deneyimi, yaygın bir zorluğu vurgulamaktadır: Yapay zeka destekli geliştirme araçları, ilk iskele ve kod üretimi için faydalı olsa da, genellikle karmaşık, uzun süreli görevler için gereken sağlamlık ve özerklikten yoksundur.¹ bolt.new, “akıllı yönlendirme” ve “biraz web geliştirme anlayışı” gerektiren “tarayıcı içi bir yapay zeka web geliştirme agent’ı” olarak tanımlanmaktadır.¹ Etkileşimler için token sınırlarına dayanması ¹ ve “son teknoloji” olması, “tutarsızlıklar ve sınırlamalar” içermesi ³, denetimsiz, uzun süreli görev yürütümü için uygun olmadığı anlamına gelir. Temel sorun, “durup bana soruyor” (durup bana soruyor) şeklindeki etkileşimli doğasıdır.

Bu durum, kullanıcının “bir yapay zeka başka bir yapay zekayı kontrol ederek uzun süreli görevleri yerine getirebilsin” (bir yapay zekanın başka bir yapay zekayı kontrol ederek uzun süreli görevleri yerine getirebilmesi) hedefiyle keskin bir tezat oluşturmaktadır. Bu, yapay zeka destekli kodlamadan gerçek çoklu agent özerk düzenlemesine bir geçişi gerektirir.

Hedefin Tanımlanması: Web Uygulamaları için Özerk Çoklu Agent Sistemleri

Bu rapor, birincil bir yapay zeka agent’ının (orkestratör/yönetici) bir web uygulaması ortamında karmaşık, uzun süreli görevleri tamamlamak için bir veya daha fazla uzmanlaşmış yapay zeka agent’ını (çalışanlar) özerk bir şekilde yönettiği ve koordine ettiği sistemlerin tasarlanmasına ve uygulanmasına odaklanacaktır. Bu, basit yönlendirme-yanıt etkileşimlerinin ötesine geçerek karmaşık, durum bilgisi olan ve dirençli agent işbirliğine geçmeyi içerir.

Bu hedef, kullanıcının bir yapay zekanın “vermiş olduğum görevi bitirinceye kadar durmasın” (verilen görevi bitirene kadar durmaması) arzusunu doğrudan ele almaktadır.

Yapay Zeka Destekli Geliştirme ve Özerk Agent Sistemleri Arasındaki Mimari Uçurum

Kullanıcının bolt.new ile yaşadığı hayal kırıklığının temelinde yatan önemli bir ayrım bulunmaktadır. bolt.new gibi araçlar, esasen yapay zeka ile güçlendirilmiş Entegre Geliştirme Ortamları (IDE’ler) olarak işlev görür. Bu tür araçlar, insan bir geliştiriciye yönlendirmelere dayalı olarak kod parçacıkları veya uygulama çerçeveleri oluşturarak yardımcı olmak üzere tasarlanmıştır.¹ Tek bir, insan odaklı geliştirme oturumu bağlamında çalışırlar. Buna karşılık, kullanıcının talep ettiği sistem, operasyonel özerklik, karmaşık iş akışı yönetimi, agent’lar arası iletişim ve genellikle doğrudan, sürekli insan denetiminden bağımsız olarak uzun vadeli durum kalıcılığı için mimarisi oluşturulmuş bir Özerk Çoklu Agent Sistemi (MAS)‘dir.

Bu ayrımın farkında olmak kritik öneme sahiptir. Çözüm, bu amaç için bolt.new‘i “düzeltmek” değil, bolt.new‘in oluşturulmasına yardımcı olabileceği web uygulamasına entegre olan farklı türde bir yapay zeka sistemi mimarisi oluşturmaktır. Kullanıcının sorgusu, bolt.new‘in sık sık durmasını, uzun görevler için diğer yapay zekaları kontrol eden bir yapay zeka arzusuyla karşılaştırır. bolt.new belgeleri ¹, sohbet tabanlı yönlendirme yoluyla “kullanıcıların tam yığın web uygulamaları oluşturmasına yardımcı olan bir araç” rolünü vurgular ve kod üretimi için bir LLM’e (Claude 3.7 Sonnet) dayanır. Token pencereleri gibi sınırlamaları vardır ve “kritik uygulamalar için üretime hazır altyapı” değildir.³ İstenen sistem, “bir yapay zeka başka bir yapay zekayı kontrol ederek” (bir yapay zekanın diğerini kontrol etmesi) içerir ki bu, genellikle bir orkestratör ile çoklu agent sisteminin tanımıdır. Uzun süreli görevler, basit kod üretimi denemelerinin ötesinde eşzamansızlık, durum yönetimi ve hata işleme anlamına gelir. Bu nedenle, temel sorun yalnızca bolt.new‘deki bir özellik eksikliği değil, yapay zeka sisteminin türü ve amaçlanan operasyonel alanı arasındaki temel bir farktır. bolt.new uygulamanın oluşturulmasına yardımcı olur; kullanıcı, karmaşık iş mantığını özerk bir şekilde gerçekleştirmek için uygulamanın bir parçası olarak çalışan bir yapay zeka sistemi istemektedir.

Kavramsal Temeller: Özerk Agent’lar ve Çoklu Agent Sistemleri (MAS)

Özerk Yapay Zeka Agent’larının Tanımlanması

Özerk bir yapay zeka agent’ı, çevresini algılayan, kararlar alan ve belirli hedeflere ulaşmak için minimum insan müdahalesiyle eylemlerde bulunan bir yazılım varlığıdır.⁴ Temel özellikleri arasında proaktiflik, reaktiflik ve sosyal yetenek (diğer agent’larla etkileşim) bulunur. Büyük Dil Modelleri (LLM’ler), bu agent’lar için “beyin” veya muhakeme motoru olarak hareket ederek planlama, araç kullanma ve geri bildirimlerden öğrenme yeteneklerini sağlar.¹⁰⁵ belgesi, Profil, Bellek, Planlama ve Eylem gibi temel bileşenleri özetlemektedir.

Çoklu Agent Sistemlerinin (MAS) İlkeleri

MAS, tek bir agent’ın yeteneklerinin ötesindeki sorunları çözmek için birden fazla özerk agent’ın işbirliği yaptığı sistemlerdir.¹³ İşbirliği yapılandırılmış (hiyerarşik) veya merkezi olmayan olabilir.¹³ Temel yönler arasında görev ayrıştırma, agent iletişimi, koordinasyon ve potansiyel olarak müzakere bulunur. Amaç, kolektif olarak ortaya çıkan akıllı davranışlar elde etmektir.

Yapay Zeka Destekli Geliştirme ile Özerk Orkestrasyonun Ayırt Edilmesi

bolt.new gibi araçlar öncelikle yapay zeka destekli geliştirme agent’larıdır. Kullanıcı yönlendirmelerine göre kod veya uygulama yapıları üretirler.¹ Özerklikleri, üretim görevinin kendisiyle sınırlıdır ve doğrulama, entegrasyon ve yinelemeli iyileştirme için kullanıcıya güvenirler.¹

Öte yandan, özerk çoklu agent orkestrasyon sistemleri, karmaşık iş akışlarını yürütmek üzere tasarlanmıştır. Uzun süreli operasyonel görevlerde hataları planlayabilen, delege edebilen, izleyebilen ve bunlardan kurtulabilen agent’ları içerirler, genellikle her adım için doğrudan insan müdahalesi olmadan.⁶

“Agentlık” Spektrumu ve Kullanıcı Beklentileri

“Yapay zeka agent’ı” terimi geniştir. bolt.new gibi araçlar, bir “agentlık spektrumunun” bir ucunu temsil eder (kod üretimi asistanı), kullanıcının talebi ise çok daha yüksek bir agentlık derecesine işaret eder (özerk görev yürütme ve kontrol). Genel yapay zeka araçlarını özel özerk agent sorunlarına uygularken beklenti ile yetenek arasındaki uyumsuzluk, yaygın bir hayal kırıklığı kaynağıdır. Kullanıcı, bir “yapay zeka web geliştirme agent’ı” olan bolt.new‘i kullanmaktadır.¹ Kullanıcı, çok fazla “durup sorduğu” için hayal kırıklığına uğramıştır, bu da daha bağımsız bir operasyon arzusunu ima eder. Talep, uzun süreli görevleri tamamlanana kadar başka bir yapay zekayı kontrol eden bir yapay zeka içindir. Araştırma materyali, basit araç kullanan agent’lardan orkestratörlü karmaşık çoklu agent sistemlerine kadar çeşitli agent türlerini tanımlamaktadır.¹⁰ Bu, bir özerklik spektrumunu düşündürür. bolt.new, operasyonel görev yürütme konusunda bu spektrumun daha altındadır ve geliştirme yardımına odaklanır. Kullanıcının spektrumda daha yüksek bir sisteme ihtiyacı vardır. Bu nedenle, raporun, kullanıcının sorunu bağlamında “özerk agent”ın ne anlama geldiğini açıkça tanımlaması ve bolt.new gibi bir aracın yeteneklerini amaçlanan tasarımının ötesine zorlamak yerine, bu daha yüksek agentlık seviyesi için tasarlanmış çerçevelere ve mimarilere yönlendirmesi gerekir.

Özerk Yapay Zeka Destekli Web Uygulamaları için Mimari Temeller

3.1. Orkestrasyon ve Görev Delegasyonu

“Süpervizör/Orkestratör-Çalışan” Modeli

Bu, merkezi bir “yönetici” veya “orkestratör” agent’ının karmaşık bir hedefi daha küçük, yönetilebilir alt görevlere ayırmaktan sorumlu olduğu yaygın ve etkili bir modeldir.¹³ Orkestratör daha sonra bu alt görevleri, her biri atanmış işlevini yerine getirmek için özel araçlar ve bilgilerle donatılmış uzmanlaşmış “çalışan” agent’lara devreder.¹³ Orkestratör ilerlemeyi izler, sonuçları entegre eder ve istisnaları veya hataları ele alarak planı gerektiği gibi uyarlar.⁴²⁵ belgesi, Kafka kullanan olay odaklı sistemler için bu modeli tanımlayarak dayanıklılığı ve basitleştirilmiş işlemleri vurgular. ²⁶, “Orkestratör-Çalışanlar”ı açıkça bir LLM agent tasarım modeli olarak listeler.

Agent’lar Arası İletişim

Etkili iletişim hayati önem taşır. Agent’ların bilgi, görev, sonuç ve durum güncellemelerini değiş tokuş etmek için standartlaştırılmış yollara ihtiyacı vardır.²⁹ Agent-to-Agent (A2A) ³¹ ve Model Context Protocol (MCP) ³² gibi protokoller bu etkileşimleri standartlaştırmayı amaçlar, ancak MCP daha çok agent-araç ve A2A agent-agent içindir. ²⁹ belgesi, W3C AI Agent Protocol Community Group’un açık, birlikte çalışabilir protokoller geliştirme çabalarını tartışır. Modeller arasında mesajlaşma (genellikle mesaj kuyrukları aracılığıyla, bkz. 3.3), işlev çağırma (bir LLM orkestratörünün çalışan agent’lara veya araçlara parametrelerle belirli işlevleri yürütme talimatı verdiği yer) ³⁴ ve paylaşılan durum/bellek mekanizmaları bulunur. ³⁰, FIPA-ACL ve KQML’yi yerleşik agent iletişim dilleri olarak ve bunları uygulayan JADE ve SPADE gibi çerçeveleri vurgular.

3.2. Uzun Süreli Görevler için Durum Yönetimi

Uzun süreli görevler, ilerlemeyi izlemek, birden fazla adım ve olası kesintiler boyunca bağlamı korumak ve kurtarmayı sağlamak için doğası gereği sağlam durum yönetimi gerektirir.³⁶ Durumun temel yönleri şunlardır: oturum verileri, uzun süreli bellek, kullanıcı profilleri, görev durumu.³⁶

Kullanılan teknikler şunlardır:

• Veritabanı Kalıcılığı: Agent durumunun (örneğin, mevcut adım, ara sonuçlar, hata sayıları) veritabanlarında ³⁶ saklanması. Örneğin CrewAI, akış kalıcılığı için varsayılan olarak SQLite kullanır.³⁹
• Vektör Veritabanları: Anlamsal bellek için, bağlam sağlamak üzere geçmiş etkileşimlerin veya ilgili bilgilerin gömülmüş temsillerinin saklanması.³⁶
• Bilgi Grafları: Karmaşık ilişkileri ve yapılandırılmış durum bilgilerini temsil etmek ve sorgulamak için.³⁶
• Durum Kalıcılığına Sahip İş Akışı Motorları: Bazı orkestrasyon araçları (AWS Step Functions ⁴⁰ veya Google Cloud Workflows ⁴² gibi) yerleşik durum yönetimi ve kontrol noktası oluşturma özellikleri sunar. ⁴², Google Cloud Workflows’un her adımı Spanner’a kontrol noktası olarak kaydettiğini vurgular.
• Çerçeveye Özgü Bellek: LangChain, CrewAI ve AutoGen gibi agent çerçeveleri kendi bellek modüllerini sağlar.¹⁰ LangGraph durum bilgisi olan grafları vurgular.³⁸³⁷, Autokitteh kullanarak dayanıklı durum için kodu İş Akışları ve Etkinlikler olarak yapılandırmayı açıklar.

3.3. Eşzamansız Görev Yürütme

Web uygulamalarında ve uzun süreli yapay zeka görevleri için gerekli olan engellemeyen işlemler için eşzamansız yürütme anahtardır.

• Mesaj Kuyrukları: RabbitMQ ⁴⁸, Apache Kafka ²⁵ veya Amazon SQS ⁴⁸ gibi bulut tabanlı seçenekler, görev gönderimini yürütmeden ayırır. Orkestratör, görevleri bir kuyruğa yerleştirebilir ve çalışan agent’lar (potansiyel olarak bağımsız olarak ölçeklendirilir) bunları alabilir. Bu, yanıt verme hızını ve dayanıklılığı artırır. ⁴⁹ ve ⁵⁰, FastAPI gibi Python web çerçevelerinde RabbitMQ/Redis ile Celery kullanarak arka plan görev işlemeyi ayrıntılı olarak açıklar. ⁴⁸, yapay zeka agent ağları için noktadan noktaya ve merkezi mesaj yönetimini tartışır.
• Olay Odaklı Mimariler: Agent’lar, katı, yoklanmış bir sıra izlemek yerine olaylara (örneğin, görev tamamlama, yeni veri gelişi, hata oluşumu) tepki verir.²⁵²⁵, Kafka kullanarak orkestratör-çalışan ve hiyerarşik modellerin nasıl olay odaklı hale getirileceğini açıklar. ²⁸, senkron orkestrasyonu, iş akışlarının kolektif agent davranışından ortaya çıktığı eşzamansız olay odaklı koreografiyle karşılaştırır.

Orkestrasyon, Durum ve Eşzamansızlığın Gerçek Özerklik İçin Karşılıklı Bağımlılığı

Kullanıcının bir yapay zekanın “bitene kadar durmadan” görevleri tamamlaması hedefine ulaşması, yalnızca iyi bireysel agent yeteneklerinden daha fazlasını gerektirir. (1) akıllı orkestrasyon (delegasyon ve yeniden planlama için), (2.1) sağlam durum yönetimi (zaman ve kesintiler boyunca bellek için) ve (2.2) dirençli eşzamansız yürütme (engellemeyen, uzun süreli işlemler ve hata toleransı için) olmak üzere derinlemesine entegre edilmiş bir üçlü sacayağı talep eder. Bu sütunlardan herhangi birindeki bir zayıflık, tüm sistemin özerkliğini tehlikeye atacak ve “durup soruyor” sorununa geri dönülmesine yol açacaktır.

Uzun süreli görevler, web bağlamında kullanıcı etkileşimini engellemekten kaçınmak ve kaynakları verimli bir şekilde yönetmek için eşzamansız işlemler gerektirir.²⁵ Eşzamansız, uzun süreli görevler, hatalardan kurtulmak veya duraklamalardan sonra devam etmek için doğal olarak durumlarını kalıcı hale getirmelidir.³⁶ Bir agent ne yaptığını veya bir kesintiden önce ne olduğunu unutursa, gerçekten “bitene kadar” çalışamaz. Bir orkestratör agent’ının, delegasyon, hata işleme ve yeniden planlama hakkında bilinçli kararlar vermek için çalışan agent’larının ve genel iş akışının durumunu bilmesi gerekir.¹³ Durum olmadan orkestrasyon reaktif ve basit hale gelir. Orkestratör, görevleri eşzamansız olarak etkili bir şekilde yönetemezse (örneğin, her alt görev için eşzamanlı olarak beklerse), bir darboğaz haline gelir ve uzun süreli işlemler için delegasyon amacını boşa çıkarır. Bu nedenle, bu üç bileşen yalnızca arzu edilen özellikler değil, temelde birbirine bağımlıdır. Gelişmiş bir orkestratör durum olmadan etkisizdir; durum bilgisi olan, uzun süreli görevler eşzamansızlık olmadan pratik değildir; ve orkestrasyon ve durum olmadan eşzamansız görevler yönetilemez hale gelir. Bu nedenle, rapor bu üç sütunun uyumlu bir şekilde tasarlanmasını vurgulamalıdır. Örneğin, mesaj kuyruğu seçimi, durumun nasıl güncelleneceğini ve orkestratörün görevleri nasıl izleyeceğini etkileyebilir. Agent çerçevesinin durum yönetimi yetenekleri, bir orkestratörün bir görevi ne kadar kolay sürdürebileceğini veya yeniden planlayabileceğini etkileyecektir.

Agent Çerçevenizi Seçmek: LangChain/LangGraph, AutoGen, CrewAI

Agent Çerçevelerine Giriş

Bu çerçeveler, çoklu agent sistemlerinin geliştirilmesini basitleştirmek için soyutlamalar ve araçlar sağlar; agent iletişimi, araç kullanımı, bellek ve orkestrasyon mantığı için önceden oluşturulmuş bileşenler sunar.¹⁰

4.1. LangChain & LangGraph

• LangChain: LLM uygulamaları oluşturmak için kapsamlı bir çerçeve olup modeller, yönlendirmeler, bellek, indeksleme, zincirler ve agent’lar için modüller sunar.¹⁷ Gücü, kapsamlı entegrasyonlarında ve özel agent mantığı oluşturma esnekliğinde yatmaktadır. LangChain’deki özerk agent’lar (AutoGPT, BabyAGI uygulamaları gibi) uzun süreli hedefler için tasarlanmıştır ve araç kullanımı ile uzun süreli belleği birleştirir.¹⁹
• LangGraph: Adımları bir grafikte düğümler ve kenarlar olarak modelleyerek durum bilgisi olan, döngüsel, çok aktörlü uygulamalar oluşturmak için özel olarak tasarlanmış bir LangChain uzantısıdır.¹⁷
  • Kullanıcı için Önemi: LangGraph’ın durum bilgisi olan grafları ve koşullu kenarları ⁴⁷, kullanıcının bir yapay zekanın başka bir yapay zekayı kontrol etme, uzun süreli görevleri yönetme ve ara sonuçlara göre potansiyel olarak yeniden planlama yapma ihtiyacı için son derece önemlidir. Döngü oluşturma yeteneği, bir orkestratör agent’ının görevleri yeniden değerlendirmesine ve yeniden devretmesine olanak tanır. ³⁸, LangGraph’ın hata toleransını ve hataları izole etme, görevleri yeniden deneme ve sorunları iletme yeteneğini vurgular; bu, uzun süreli görevler için hayati önem taşır. ⁴⁶ ve ⁴⁷, LLM’lerin niyet belirleme ve yönlendirme için düğümlerde nasıl kullanılabileceğini vurgular; bu, hata analizi ve yeniden planlama için genişletilebilir. ⁷⁸ ve ⁴⁷, LangGraph’ın döngüsel doğasının, düğümler içindeki LLM muhakemesinin ve koşullu kenarların hatalardan sonra dinamik yeniden planlama için nasıl kullanılabileceğini tartışır.

4.2. AutoGen (Microsoft)

• Agent’ların konuşmalar yoluyla işbirliği yaptığı çoklu agent uygulamaları oluşturmak için açık kaynaklı bir çerçevedir.⁷ LLM’leri, araçları ve insan girdisini entegre edebilen özelleştirilebilir, “konuşabilir” agent’lar içerir.⁷ Çeşitli konuşma modellerini destekler (örneğin, bir yönetici ile grup sohbeti, hiyerarşik sohbet).⁸³
  • Kullanıcı için Önemi: AutoGen’in GroupChatManager‘ı ⁸⁷ birden fazla agent’ı yönetebilir. Agent rollerini ve konuşma akışlarını özelleştirme yeteneği, bir yönetici agent’ının (konuşma geçmişine dayanarak) hataları analiz edebileceği ve görevleri yeniden yönlendirebileceği sistemlerin tasarlanmasına olanak tanır. ⁹¹, AutoGen agent’larının “hataları akıllıca ele alabileceğini… sorunu analiz edebileceğini, düzeltmeye çalışabileceğini ve hatta çözümünü yineleyebileceğini” belirtir. ⁷, AutoGen’in çeşitli iş akışları ve uyarlanabilir davranış için anahtar olan birleştirilebilir konuşma modelleri desteğini vurgular. ⁴⁴, esnek agent mimarisini ve gelişmiş konuşma yönetimini vurgular. ⁹⁶, GroupChatManager‘ın özel konuşmacı seçiminin ve mesaj geçmişine erişiminin hata analizi ve dinamik yeniden planlama için nasıl kullanılabileceğini tartışır.

4.3. CrewAI

• Rol oynayan özerk yapay zeka agent’larının bir “ekip” olarak işbirliği yaptığı bir orkestrasyon çerçevesidir.¹⁰ Agent’lar için net rolleri, hedefleri ve geçmiş hikayelerini vurgular. Sıralı ve hiyerarşik süreçleri destekler; burada bir yönetici agent’ı görevleri devredebilir ve sonuçları doğrulayabilir.¹⁰
  • Kullanıcı için Önemi: CrewAI’nin bir yönetici agent’ı ile hiyerarşik süreci ⁹⁹, kullanıcının bir yapay zekanın diğerlerini kontrol etme konseptiyle doğrudan uyumludur. Yönetici agent’ının iş akışını koordine etme, görevleri devretme ve sonuçları doğrulama rolü merkezidir. ¹¹², yönetici agent’ının tüm süreci denetlediğini ve iş akışını tanımladığını vurgular. ⁹⁹, yönetici agent’ının yeteneklere göre görev atayabileceğini ve çıktıları inceleyebileceğini belirtir. ¹⁰⁹, görüntü yükleme için hata işleme ve geri dönüş stratejilerinden bahseder, bu da hata işlemenin bir düşünce olduğunu ima eder. ¹⁰¹, bir görevin koruma rayının (False, error) döndürmesi durumunda hatanın agent’a geri gönderildiğini ve agent’ın ardından “sorunu düzeltmeye çalıştığını” belirtir. ¹²⁸, CrewAI’nin özel yönetici agent’ları, hiyerarşik süreçleri, koşullu görevleri ve Akışlarının bir yönetici agent’ının izlemesi, hataları belirlemesi ve iş akışlarını dinamik olarak değiştirmesi için birleştirilebileceğini gösterir.

4.4. Karşılaştırmalı Analiz ve Rehberlik

Aşağıdaki tablo, anahtar agent çerçevelerinin temel özelliklerini karşılaştırmaktadır. Bu tablo, kullanıcının bilinçli bir karar vermesi için kritik öneme sahiptir. Karmaşık bilgileri kolayca sindirilebilir bir biçimde sentezleyerek pratik uygulama rehberliği ihtiyacını doğrudan ele alır. Kullanıcının istediği sistemi oluşturmak için bir teknoloji seçmesi gerekmektedir. Birden fazla çerçeve (LangGraph, AutoGen, CrewAI) mevcuttur ve her birinin farklı güçlü yönleri ve felsefeleri vardır.⁴³ Kullanıcının sorununa (özerklik, delegasyon, uzun süreli görevler, hata işleme, web entegrasyonu, yeniden planlama) ilişkin temel özellikler arasında doğrudan bir karşılaştırma bu farklılıkları netleştirecektir. Bu yapılandırılmış karşılaştırma, çerçeve yeteneklerini belirli proje gereksinimleriyle eşleştirmeye yardımcı olarak uygun olmayan bir araç seçme riskini azaltır. Kullanıcının önemli araştırma zamanından tasarruf etmesini sağlayarak birleştirilmiş bir genel bakış sunar.

Tablo: Anahtar Agent Çerçevelerinin Özellik Karşılaştırması

Özellik	LangChain/LangGraph	AutoGen	CrewAI
Birincil Orkestrasyon Modeli	Durum bilgisi olan, döngüsel graflar; programatik kontrol akışı; LLM düğümleri aracılığıyla açık mantık 47	Konuşma odaklı işbirliği; dinamik grup sohbeti; GroupChatManager veya özel agent mantığı aracılığıyla ortaya çıkan orkestrasyon 7	Rol tabanlı delegasyon; sıralı veya hiyerarşik süreçler; özel veya otomatik oluşturulmuş yönetici agent’ı görevleri koordine eder ve doğrular 10
Durum Yönetimi	StateGraph aracılığıyla açık ve esnek durum yönetimi; bellek kalıcılığı için çeşitli entegrasyonlar 38	Konuşma geçmişi aracılığıyla örtük durum; harici bellek entegrasyonları için esneklik (örn. Zep, Mem0) 44	Görevler ve agent’lar arasında bağlam aktarımı; Flows aracılığıyla durum kalıcılığı (varsayılan olarak SQLite) 39
Hata İşleme Gelişmişliği	Düğümlerde ve koşullu kenarlarda özel hata işleme mantığı için yüksek esneklik; GraphRecursionError gibi yerleşik hata türleri 66	Agent’lar hataları analiz edebilir ve yineleyebilir; konuşma akışına dayalı olarak hata işleme programlanabilir 85	Görev düzeyinde koruma rayları; yönetici agent’ı sonuçları doğrulayabilir; özel hata işleme mantığı eklenebilir 100
Yeniden Planlama Yeteneği	LLM destekli düğümler ve koşullu kenarlar aracılığıyla son derece dinamik ve programlanabilir yeniden planlama 47	Konuşma ve agent etkileşimleri yoluyla ortaya çıkan uyarlanabilir planlama; agent’lar planları geri bildirime göre ayarlayabilir 84	Yönetici agent’ı, önceden tanımlanmış rollere/araçlara veya özel mantığa dayalı olarak görevleri yeniden devredebilir; “otonom sorgu hatası düzeltme” 99
Web Entegrasyon Kolaylığı	LangServe aracılığıyla REST API’leri olarak dağıtılabilir; Python web çerçeveleriyle (FastAPI/Flask) entegrasyon 62	Python tabanlı; web hizmetleriyle etkileşim için araçlar entegre edilebilir; AutoGen Studio bir arayüz sunar 130	Python tabanlı; web hizmetleriyle etkileşim için araçlar entegre edilebilir; CrewAI Enterprise izleme yetenekleri sunar 57
Topluluk/Belgeler	Geniş ve aktif topluluk; kapsamlı belgeler ancak LangGraph daha yeni olduğu için gelişiyor 62	Güçlü Microsoft desteği; büyüyen topluluk ve belgeler 7	Hızla büyüyen topluluk; pratik odaklı belgeler ve örnekler 10
Uzun Süreli Görevler için Uygunluk	Durum bilgisi olan ve dayanıklı yürütme için tasarlandı; karmaşık, uzun süreli iş akışları için güçlü 38	Eşzamansız mesajlaşma ve uzun süreli agent’lar oluşturma yeteneği; karmaşık görevler için uygun 22	Hiyerarşik süreçler ve görev yönetimi uzun süreli operasyonları destekler; Flows durum kalıcılığı sunar 23

Rehberlik: Proje karmaşıklığına, istenen kontrol düzeyine ve dinamik yeniden planlama için özel ihtiyaçlara göre önerilerde bulunulabilir. Örneğin, son derece özel, durum bilgisi olan mantık ve yeniden planlama döngüleri üzerinde ayrıntılı kontrol için LangGraph tercih edilebilir. CrewAI’nin hiyerarşik modeli, yönetici-çalışan kurulumları için sezgiseldir, ancak yeniden planlama mantığı agent rollerinde/görevlerinde daha örtük olabilir. AutoGen, konuşma agent’ları ve esnek grup dinamiklerinde üstündür; burada yeniden planlama agent etkileşimlerinden ortaya çıkabilir.

Çerçeve Seçimi, Özerkliğin ve Yeniden Planlamanın Doğasını Etkiler

Çerçeve seçimi (LangGraph, AutoGen, CrewAI) yalnızca özerk agent’lar oluşturmak için farklı araçlar sunmakla kalmaz; aynı zamanda özerkliğin nasıl elde edildiğini ve dinamik yeniden planlamanın nasıl uygulanabileceğini temelden şekillendirir. LangGraph, yeniden planlama için açık, programlanabilir durum makinelerini mümkün kılar. AutoGen, çoklu agent konuşması ve esnek agent rolleri aracılığıyla ortaya çıkan yeniden planlamayı teşvik eder. CrewAI, rol tanımlı sorumluluklara ve süreç odaklı (sıralı/hiyerarşik) yeniden görevlendirmeye eğilimlidir; burada yöneticinin yeniden planlaması, önemli özel mantık olmadan anında tamamen yeni planlar oluşturmaktan ziyade, önceden tanımlanmış yeteneklere dayalı olarak yeniden delegasyonla ilgili olabilir.

Kullanıcının, “durup sormadan” görevleri tamamlayan ve bir yapay zekanın diğerini kontrol ettiği bir yapay zeka istediği göz önüne alındığında, bu, sağlam hata işleme ve yeniden planlama ihtiyacını ima eder. LangGraph, döngüsel graflar, koşullu kenarlar ve durum yönetimi ile tanımlanır ³⁸, bir orkestratörün belirli düğümlerde LLM muhakemesine dayalı olarak karmaşık karar ağaçlarını ve yeniden planlama döngülerini açıkça kodlamasına olanak tanır. AutoGen, “konuşabilir” agent’lara ve dinamik grup sohbetine odaklanır.⁷ Burada yeniden planlama daha çok ortaya çıkabilir: bir agent bir hata bildirir ve GroupChatManager veya diğer agent’lar, konuşma yoluyla, potansiyel olarak farklı araçlar veya uzmanlık içeren yeni bir eylem planına karar verir. Plan, etkileşim yoluyla uyarlanır. ⁹¹, AutoGen agent’larının “sorunu analiz edebileceğini, düzeltmeye çalışabileceğini ve hatta çözümünü yineleyebileceğini” belirtir. CrewAI, “rol oynayan” agent’ları ve tanımlanmış süreçleri (sıralı/hiyerarşik) vurgular.¹⁰ Hiyerarşik bir süreçteki bir yönetici agent’ı görevleri devreder.⁹⁹ Burada yeniden planlama, yöneticinin bir görev hatasını tanımasını (belki görev çıktısı doğrulaması veya bir agent’ın bir sorun bildirmesi yoluyla) ve görevi yeniden atamasını, ilk agent uygun değilse farklı bir agent’a veya parametreleri değiştirmesini içerebilir. Ancak, belgeler ⁹⁷ yöneticinin kendisi tarafından özel uzantı olmadan anında, LLM odaklı dinamik plan üretiminden ziyade ilk görev tanımı ve yürütme akışına daha fazla odaklanır. ¹¹², yöneticinin “ilerlemeyi izlediğini ve iş akışını tanımladığını” ve sistemin “otonom sorgu hatası düzeltme yeteneğini” not eder. Bu nedenle, yeniden planlama mekanizması farklılık gösterir: LangGraph (LLM düğümleriyle açıkça programlanmış mantık), AutoGen (konuşmadan ortaya çıkan), CrewAI (yönetici gözetimi ve rollere/araçlara dayalı potansiyel yeniden delegasyon ile süreç odaklı). Kullanıcının, ihtiyaçlarına hangi tür yeniden planlamanın uygun olduğunu düşünmesi gerekir. Son derece öngörülebilir, kural tabanlı (LLM tarafından değerlendirilen kurallar olsa bile) yeniden planlama gerekiyorsa LangGraph uygun olabilir. Agent tartışması yoluyla uyarlanabilirlik anahtarsa AutoGen. Bir yönetici tarafından yapılandırılmış, rol tabanlı delegasyon ve potansiyel yeniden atama tercih ediliyorsa CrewAI. Bu aynı zamanda yeniden planlamanın ne kadar “akıllı” olabileceğini de etkiler; LangGraph’taki LLM odaklı düğümler veya CrewAI/AutoGen’deki karmaşık yönetici agent mantığı, basit geri dönüşlerin ötesinde gerçekten dinamik plan üretimi için gerekli olacaktır.

Dirençli Sistemler Oluşturma: Hata İşleme, Dinamik Yeniden Planlama ve Geri Dönüşler

5.1. Dağıtılmış Agent Görevlerinde Sağlam Hata Tespiti ve İşlenmesi

Uzun süreli, çoklu agent görevleri çeşitli hatalara (API zaman aşımları, araç hataları, LLM tutarsızlıkları, ağ sorunları) eğilimlidir. Sağlam hata işleme, özerklik için çok önemlidir.²

Kullanılacak stratejiler şunlardır:

• Try-Catch Blokları ve Özel İstisnalar: Kodda standart bir uygulamadır, ancak agent mantığı içinde bu, agent’ların araçlarından veya LLM çağrılarından hataları yakalayabilmesi ve bunları anlamlı bir şekilde bildirebilmesi anlamına gelir.¹⁰⁰
• Geri Çekilmeli Yeniden Deneme Mekanizmaları: API hız sınırları veya geçici ağ sorunları gibi geçici hatalar için üstel geri çekilmeli yeniden denemeler uygulayın.¹⁰⁰¹³³, sınırlamaları da dahil olmak üzere bu konuda ayrıntılı bir tartışma sunar.
• Zaman Aşımları: Görevlerin süresiz olarak takılı kalmasını önleyin.¹³⁴ CrewAI görevlerinde max_iter ¹¹¹ ve max_retry_limit ²³ bulunur.
• Günlük Kaydı: Bağlam içeren kapsamlı hata günlük kaydı, hata ayıklama ve bir orkestratör agent’ının neyin yanlış gittiğini anlaması için hayati önem taşır.⁹⁷
• Durum Bilgili Hata İzleme: Sistem durumu, yeniden planlamayı bilgilendirmek için hataları, hata sayılarını ve bunların meydana geldiği bağlamı kaydetmelidir.⁶⁹
• Hata Sınıflandırması: Hataları sınıflandırmak (örneğin, “TIMEOUT”, “RATE_LIMIT”, “PERMISSION”, “INVALID_INPUT”), daha hedefli işleme stratejilerine olanak tanır.⁶⁹

5.2. Orkestratör/Yönetici Agent Tarafından LLM Destekli Dinamik Yeniden Planlama

Orkestratör/yönetici agent’ı, bir çalışan agent tarafından bildirilen (veya izleme yoluyla tespit edilen) hatayı/arızayı analiz etmek ve dinamik olarak yeni bir plan oluşturmak veya mevcut planı uyarlamak için LLM muhakeme yeteneklerini kullanır.⁴ Bu, önceden tanımlanmış koşullu yolların ötesine geçer.

Mekanizma şu şekilde işler:

1. Çalışan agent başarısız olur ve hata ayrıntılarını bildirir (veya orkestratör hatayı tespit eder).
2. Orkestratör hatayı, mevcut görevi, genel hedefi ve ilgili durumu/geçmişi alır.
3. Orkestratör (LLM’ini kullanarak) hata hakkında muhakeme yürütür: Olası neden neydi? Araç uygunsuz muydu? Girdi hatalı mıydı? Alt görev bile başarılabilir mi?
4. Bu muhakemeye dayanarak orkestratör yeni bir eylem planına karar verir:
   • Aynı agent’ı yeniden yönlendirme/yeniden talimat verme: Hata bir yanlış anlaşılmadan kaynaklanıyorsa.
   • Alternatif Bir Araç Seçme: Araç başarısız olduysa veya uygun değilse.
   • Farklı Bir Agent’a Yeniden Atama: Çalışan agent’ın yeteneği yoksa veya uzmanlaşmış bir agent daha iyiyse..¹³⁹
   • Görev Sırasını Değiştirme: Başarısız görevi farklı şekilde ayrıştırma, yeni önkoşul görevleri ekleme veya isteğe bağlı görevleri atlama.²⁴
   • İnsan Müdahalesi İsteme: Hata özerk olarak kurtarılamazsa (bkz. HITL bölümü).

Çerçeve desteği şunları içerir:

• LangGraph: Koşullu kenarlar, LLM destekli bir “yeniden planlama” düğümüne yönlendirebilir. Bu düğüm, mevcut durumu (hata bilgisi dahil) alır ve sonraki akışı belirleyen yeni bir plan veya değişiklikler üretir.⁴⁶⁴⁷, LLM’in bir döngüde “hangi eylemlerin yapılacağı” hakkında muhakeme yürüttüğünü açıkça belirtir. ⁷², GraphRecursionError işleme ve bir yeniden planlama adımına beslenebilecek düğüm düzeyinde hata işleme gibi hata işleme modelleri sunar.
• AutoGen: Bir GroupChatManager veya özel olarak tasarlanmış bir “Planlayıcı Agent”, bir hataya dayalı olarak yeni bir konuşma turu başlatabilir ve agent’lardan yeniden değerlendirme yapmalarını veya yeni yaklaşımlar önermelerini isteyebilir. LLM’in “konuşma programlamasındaki” rolü ⁷ burada anahtardır. ⁹¹, agent’ların “sorunu analiz edebileceğini, düzeltmeye çalışabileceğini ve hatta çözümünü yineleyebileceğini” belirtir. ⁸⁴, agent’ların “geri bildirime ve değişen koşullara göre planları ayarlayabileceğini” belirtir.
• CrewAI: Hiyerarşik bir süreçteki bir yönetici agent’ı, görev çıktılarını analiz etmek için daha karmaşık bir mantıkla (basit delegasyonun ötesinde) programlanabilir. Bir görev başarısız olursa veya kötü sonuçlar verirse, yönetici (LLM’ini kullanarak) görevi değiştirilmiş talimatlarla yeniden atamaya veya farklı araçlara/uzmanlığa sahip farklı bir agent’a devretmeye karar verebilir.¹⁰¹¹², yönetici agent’ının iş akışını tanımladığını ve sistemin “otonom sorgu hatası düzeltme yeteneğini” vurgular. ¹⁰¹, bir görevin koruma rayının (False, error) döndürmesi durumunda hatanın agent’a geri gönderildiğini ve agent’ın ardından “sorunu düzeltmeye çalıştığını” belirtir.

5.3. Acil Durum Planlaması ve Geri Dönüş Mekanizmaları

Kritik görevler için, dinamik yeniden planlama başarısız olursa veya mümkün değilse, önceden tanımlanmış acil durum planları veya geri dönüş mekanizmaları hayati önem taşır.¹⁰⁰

Örnekler şunlardır:

• Birincil araç/agent başarısız olursa daha basit, daha güvenilir bir araç/agent kullanma.
• Varsayılan veya bilinen son iyi sonucu sağlama.
• Hizmetin zarif bir şekilde düşürülmesi.¹⁰⁰
• Son bir geri dönüş olarak insan müdahalesine başvurma (bkz. HITL).

¹⁴³ (SagaLLM), çoklu agent iş akışlarında hata durumunda geri alma ve tutarlılık için işlemsel korumaları ve telafi edici mekanizmaları tartışır. ¹³⁴, “zarif düşüş” ve görevleri yeniden atama veya insan incelemesini tetikleme gibi “kurtarma stratejilerini” vurgular.

Gerçek Özerklik, Orkestratörün Hatalar Hakkında “Meta-Öğrenici” Olmasını Gerektirir

Gerçekten sağlam, uzun süreli özerk sistemler için orkestratör/yönetici agent’ı yalnızca bireysel hatalara tek seferlik yeniden planlamayla tepki vermemelidir. İdeal olarak, hata örüntülerinden öğrenmelidir. Belirli bir çalışan agent veya araç belirli koşullar altında sürekli olarak başarısız olursa veya belirli bir yeniden planlama stratejisi tekrar tekrar etkisiz kalırsa, orkestratör gelecekteki delegasyon ve yeniden planlama mantığını uyarlamalıdır. Bu, basit hata işlemenin ötesine geçerek bir tür meta-öğrenme veya uyarlanabilir strateji iyileştirmesine geçer.

Kullanıcının, çeşitli hatalara karşı dirençli, “durmadan görevleri tamamlayan” bir yapay zeka istediği göz önüne alındığında, dinamik yeniden planlama, anlık hatalara tepki vermeye olanak tanır.¹¹ Ancak, aynı tür hatalar tekrarlanırsa ve aynı yeniden planlama girişimleri başarı olmadan yapılırsa, sistem gerçekten uyum sağlamıyordur. ¹⁰ (CrewAI agent’ları önceki eylemlerden öğrenir), ⁶ (agent, sürekli iyileştirme için sonuçlara göre iç durumunu uyarlar), ¹⁹¹ (geçmiş etkileşimlere dayalı kendi kendine yansıtıcı iyileştirme, yönlendirme geliştirme), ¹² (LLM agent’ları geçmiş eylemlere ve gözlemlere dayanarak planı yinelemeli olarak yansıtır ve iyileştirir), ⁹ (LLM’ler agent’ların uyum sağlamasını sağlar) gibi belgeler, agent’ların öğrenip geliştiğine işaret eder. Bir orkestratör için bu öğrenme, orkestrasyon stratejilerine uygulanmalıdır. Hangi yaklaşımların (agent/araç seçimleri, plan yapıları) hangi koşullar altında işe yaradığı veya başarısız olduğu hakkında bir “belleğe” veya bir mekanizmaya (belki başka bir “meta-agent” veya periyodik analiz) sahip olması gerekir. Bu, orkestratörün yalnızca bir planı yürütmekle kalmayıp, aynı zamanda zamanla kendi planlama sürecini de iyileştirdiği anlamına gelir. Bu nedenle, rapor, orkestratör agent’ının yalnızca mevcut görev için kısa süreli belleğe sahip olması değil, aynı zamanda potansiyel olarak daha uzun süreli belleğe veya (belki başka bir “meta-agent” veya periyodik analiz yoluyla) geçmiş performansa dayalı olarak delegasyon ve hata kurtarma için kendi stratejilerini iyileştirmek için bir mekanizmaya sahip olması fikrine değinmelidir. Bu daha gelişmiş bir kavramdır ancak yüksek düzeyde sürekli özerklik elde etmek için anahtardır.

Web Uygulamalarına Entegrasyon: Pratik Bir Taslak

6.1. Arka Uç Mimarisi

• Python Tabanlı Arka Uç (Flask/FastAPI): Bunlar, agent sistemiyle etkileşime giren API katmanını oluşturmak için uygun seçeneklerdir.¹⁴⁴ FastAPI’nin eşzamansız desteği, agent iş akışlarında yaygın olan G/Ç’ye bağlı işlemler (örneğin, LLM yanıtlarını beklemek, araç yürütme) için özellikle faydalıdır.¹⁴⁵ Arka uç, ön ucun görevleri başlatması, durumu sorgulaması ve potansiyel olarak insan girdisi sağlaması için API uç noktalarını ortaya çıkaracaktır.
• Görev Kuyrukları (RabbitMQ/Redis ile Celery): Web istekleri aracılığıyla başlatılan uzun süreli, eşzamansız agent görevlerini yönetmek için gereklidir.⁴⁸ Web isteği işleyicisi (örneğin, FastAPI uç noktası) kuyruğa bir görev (örneğin, “X hedefi için çoklu agent iş akışını yürüt”) yerleştirir. Ayrı işlemler olarak çalışan Celery çalışanları bu görevleri alır ve orkestratör agent’ını çağırır. Bu, web sunucusunun duyarlı kalmasını sağlar. ⁴⁹, RabbitMQ’yu bir mesaj aracısı ve Celery’yi dağıtılmış bir görev kuyruğu olarak açıklar. ⁵⁰, RabbitMQ kullanarak Celery’yi FastAPI ile entegre etme örneği sunar.
• Agent Çerçevesi Entegrasyonu: Seçilen agent çerçevesi (LangGraph, AutoGen, CrewAI), Celery görevleri tarafından başlatılan ve yönetilen arka ucun temel bir bileşeni olacaktır. LangChain’in Azure AI ile entegrasyonu ⁶¹‘te gösterilmektedir. LangServe ⁶², LangChain zincirlerini REST API’leri olarak dağıtabilir; bu, alternatif veya tamamlayıcı bir yaklaşım olabilir. AutoGen Studio ¹³⁰, agent’ları ve iş akışlarını tanımlamak için bir arayüz sağlar ve yerel LLM sunucularıyla entegre edilebilir. ¹⁹², bu tür projeler için geliştirme ortamlarının kurulması hakkında genel tavsiyeler sunar. CrewAI projeleri Python betiklerinden oluşturulabilir ve çalıştırılabilir.¹⁰⁶

6.2. Ön Uç Hususları

• Görev Başlatma: Özerk agent sistemi için üst düzey hedefi tanımlamak üzere bir kullanıcı arayüzü.⁹⁸
• İlerleme İzleme: Görev durumu hakkında gerçek zamanlı güncellemeler (örneğin, “Agent A alt görev 1’i işliyor”, “Hata oluştu, yeniden planlanıyor…”, “Görev %75 tamamlandı”).
  • WebSockets: Arka uçtan (agent’ların çalıştığı yerden) ön uca sürekli yoklama yapmadan gerçek zamanlı güncellemeler göndermek için.¹⁴⁹¹⁴⁹, düşük gecikme süresi ve verimli veri aktarımı avantajlarını tartışır. ¹⁵⁰, OpenAI’nin Gerçek Zamanlı API’sinin sunucudan sunucuya WebSockets kullandığını gösterir.
• İnsan Etkileşimli Arayüz (HITL): HITL dahil edilmişse, kullanıcı arayüzünün gerekli bağlamı sunması ve kullanıcıların girdi/karar sağlamasına olanak tanıması gerekir (bkz. bölüm 7.1). CopilotKit ⁹⁸, CrewAI ve LangGraph dahil olmak üzere agent’lar için kullanıcı arayüzleri oluşturmanın bir yolu olarak bahsedilir ve HITL’yi destekler.

6.3. Dağıtım Stratejileri

• Bulut Hizmetleri (AWS, Azure, GCP): Web uygulamasını, veritabanlarını, mesaj kuyruklarını ve potansiyel olarak yapay zeka modellerini/agent’larını barındırmak için bir dizi hizmet sunar.¹⁵²¹⁵², AWS, Azure ve GCP’yi hesaplama, depolama, yapay zeka/ML hizmetleri vb. açılarından ayrıntılı bir şekilde karşılaştırır. AWS EC2, Azure Sanal Makineler, Google Compute Engine gibi hesaplama hizmetleri arka ucu ve Celery çalışanlarını barındırabilir.¹⁵² SageMaker, Azure AI, Vertex AI gibi yönetilen yapay zeka platformları LLM’leri veya hatta agent mantığını barındırabilir.¹⁵²
• Sunucusuz İşlevler (AWS Lambda, Google Cloud Functions): Tüm uzun süreli orkestratörü barındırmak yerine ayrık, olay odaklı agent eylemleri veya araç yürütmeleri için uygundur, ancak genel mimarinin bir parçası olabilir.¹⁵⁵¹⁵⁵ ve ¹⁵⁶, API arka uçları, zamanlanmış görevler ve olay odaklı işleme için Lambda/Cloud Functions kullanımını tartışır. Bir agent aracı, sunucusuz bir işlev olarak uygulanabilir.
• Konteynerleştirme (Docker, Kubernetes): Uygulamayı ve bağımlılıklarını ortamlar arasında tutarlı bir şekilde paketlemek ve dağıtmak için. AutoGen Studio Docker ile çalıştırılabilir.¹³⁰¹⁴⁶, gunicorn ve Uvicorn çalışanlarını kullanarak Databricks Uygulamalarında React ön ucuyla bir FastAPI arka ucunun dağıtılmasından bahseder.
• İş Akışı Orkestrasyon Hizmetleri:
  • AWS Step Functions: Lambda işlevlerini, Bedrock agent’larını ve diğer AWS hizmetlerini içeren karmaşık iş akışlarını yönetebilir. Çok adımlı agent süreçlerinin durumunu ve yürütme akışını yönetmek için uygundur.⁴⁰⁴⁰, görsel iş akışı tasarımını, hata işlemeyi ve paralel yürütmeyi vurgular. ⁴¹, Bedrock’a API çağrılarını paralelleştirme örneğini gösterir.
  • Google Cloud Workflows: AWS Step Functions’a benzer şekilde, Google Cloud hizmetlerini ve HTTP tabanlı API’leri yönetmek için, yerleşik güvenilirlik ve durum yönetimi ile.⁴² Uzun süreli yürütmeleri (bir yıla kadar) destekler.
  • Google’ın Agent Geliştirme Kiti (ADK): Google Cloud için optimize edilmiş, çoklu agent sistemlerini, akışı ve Vertex AI’ye dağıtımı destekleyen yeni bir açık kaynaklı çerçevedir.¹⁵⁴

6.4. Diyagram: Özerk Çoklu Agent Sistemine Sahip Bir Web Uygulamasının Üst Düzey Mimarisi

Görsel bir diyagram, kullanıcının tüm bileşenlerin (ön uç, arka uç, API ağ geçidi, görev kuyruğu, orkestratör agent’ı, çalışan agent’lar, LLM’ler, veritabanları, harici araçlar) nasıl etkileşime girdiğine dair net, üst düzey bir anlayış kazanmasını sağlayacaktır. Bu, sistemi kavramsallaştırmak için paha biçilmezdir. Kullanıcı bir web uygulaması oluşturuyor ve karmaşık bir yapay zeka sistemini entegre etmek istiyor. Sistem, kullanıcı arayüzü, arka uç mantığı, yapay zeka agent’ları, görev yönetimi, veri depolama gibi birden fazla etkileşimli bölüm içerir. Metinsel bir açıklama, böyle dağıtılmış bir sistem için takip edilmesi zor olabilir. Bir mimari diyagramı, ilişkileri, veri akışlarını ve bileşen sorumluluklarını bir bakışta netleştiren görsel bir harita sağlar. Bu, genel yapıyı anlamada, potansiyel darboğazları veya entegrasyon noktalarını belirlemede ve tasarımı başkalarına iletmede yardımcı olur.

Dahil edilecek bileşenler şunlardır:

• Kullanıcı (Tarayıcı) -> Ön Uç (React/Next.js)
• Ön Uç -> API Ağ Geçidi -> Arka Uç (FastAPI/Flask)
• Arka Uç -> Görev Kuyruğu (Celery + RabbitMQ/Redis)
• Celery Çalışanları -> Orkestratör Agent’ı (LangGraph/AutoGen/CrewAI)
• Orkestratör Agent’ı -> Çalışan Agent 1, Çalışan Agent 2,… (her biri potansiyel olarak belirli araçlara sahip)
• Agent’lar <-> LLM Hizmetleri (OpenAI, Bedrock, vb.)
• Agent’lar <-> Veri Depoları (Vektör DB, SQL DB, Bilgi Grafı)
• Agent’lar <-> Harici API’ler/Araçlar
• Arka Uç -> WebSockets -> Ön Uç (gerçek zamanlı güncellemeler için)
• İzleme ve Günlük Kaydı Hizmeti

Eraser.io ¹⁵⁷ veya benzeri araçlar bu tür diyagramları oluşturmak için kullanılabilir veya manuel oluşturma için tanımlanabilir. ¹⁹³, bir yapay zeka agent mimarisinin kavramsal bir düzenini sunar (Algılama, Bellek, Planlama, Karar Verme, Yürütme, Geri Bildirim).

Web Uygulaması, Agent Sistemi için Hem Tetikleyici Hem de Bir Araç/Ortamdır

Bu bağlamda, web uygulaması yalnızca yapay zeka agent’ları için pasif bir kap değildir. İkili bir rol üstlenir: (1) Kullanıcıların agent sistemi için görevleri ve hedefleri başlattığı arayüzdür. (2) Web uygulamasının kendisi (veya veritabanı, kullanıcı oturum verileri gibi bölümleri, hatta agent’lar tarayıcı otomasyon araçları aracılığıyla kullanıcı arayüzü etkileşiminde bulunuyorsa belirli ön uç bileşenleri) agent’ların algıladığı ve üzerinde işlem yaptığı ortamın veya bir aracın bir parçası olabilir.

Kullanıcı, yapay zeka agent’larının görevleri yerine getirdiği bir “web uygulaması” oluşturmak istemektedir. Arka uç mimarisi (6.1), web uygulamasının (FastAPI/Flask) bir kuyruk aracılığıyla agent görevlerini nasıl tetiklediğini açıklar. Çalışan agent’lar genellikle “araçlar” kullanır.⁸ Bu araçlar harici API’ler veya dahili işlevler olabilir. Bir agent’ın görevi örneğin “platformumuzdaki kullanıcı etkinliğini analiz et ve bir rapor oluştur” ise, platformun veritabanı bir veri kaynağı (bir araç) haline gelir. “Yeni bir kullanıcıyı katılım sürecinden geçir” ise, kullanıcı arayüzünün kendisi agent’ın etkileşimde bulunduğu ortamın bir parçası olabilir (kavramsal olarak veya tarayıcı otomasyonu yoluyla). Bu, web uygulamasının tasarımının, kendi kaynaklarının agent sistemine güvenli ve verimli bir şekilde nasıl sunulacağını dikkate alması gerektiği anlamına gelir. Web uygulamasının API’lerinin ve veri modellerinin tasarımı, agent etkileşimi göz önünde bulundurularak yapılmalıdır. Bu, agent’lar için özel API uç noktaları oluşturmayı, verilerin agent dostu formatlarda bulunmasını sağlamayı ve agent’ların uygulama kaynaklarına erişmesinin güvenlik etkilerini dikkate almayı içerebilir.

Gelişmiş Uygulama ve Operasyonel En İyi Uygulamalar

7.1. İnsan Etkileşimli (HITL) Entegrasyon

• Amaç: Kritik karar noktaları, karmaşık hata kurtarma, insan yargısı/etik gerektiren görevler veya yapay zeka güveninin düşük olduğu durumlar için.⁹⁸ HITL yalnızca geri dönüşle ilgili değil, aynı zamanda sürekli öğrenme ve güven oluşturmayla da ilgilidir.
• Tasarım Desenleri:
  • İnceleme ve Onay: Agent bir eylem veya sonuç önerir, insan inceler ve onaylar/reddeder/değiştirir.¹⁶⁴¹⁶⁷, finansta yüksek riskli veriler için bundan bahseder.
  • Düşük Güven/Yüksek Risk Durumunda Yönlendirme: Yapay zeka, bir karar için güven puanı bir eşiğin altındaysa veya görev yüksek riskli olarak işaretlenmişse bir insana yönlendirir.¹⁶²
  • Etkileşimli Girdi: Agent duraklar ve ilerlemek için bir insandan belirli bilgiler veya açıklamalar ister.⁹⁹
  • Öğrenme için Geri Bildirim Döngüleri: İnsan düzeltmeleri/geri bildirimleri agent’ları yeniden eğitmek veya ince ayar yapmak için kullanılır (RLHF, tercih tabanlı öğrenme).¹⁶⁴
• Yönlendirme için Bağlamın Korunması: Etkili HITL için hayati önem taşır. Bir görev yönlendirildiğinde, insanın tam bağlama ihtiyacı vardır: agent’ın ne yapmaya çalıştığı, hangi adımları attığı, hangi verileri kullandığı, neden yönlendirdiği ve mevcut durumu.¹⁶²¹⁶², önceki etkileşimleri, yapay zeka analizini ve güven puanlarını sağlamayı vurgular.
• Araçlar: CopilotKit ⁹⁸, agent iş akışlarında HITL için kullanıcı arayüzü bileşenleri sağlar. CrewAI Enterprise, webhook’lar aracılığıyla insan girdisi için özelliklere sahiptir.⁹⁹

7.2. Çoklu Agent Sistemlerinde Güvenlik

• Temel Riskler:
  • Yönlendirme Enjeksiyonu: Agent’ları istenmeyen eylemlere, veri sızdırmaya veya talimatları atlamaya kandıran kötü amaçlı girdiler.²⁹ Bu, özellikle agent’lar harici verilerle veya diğer agent’larla etkileşime girerse önemli bir endişedir.
  • Veri Sızdırma/Sızıntısı: Hassas verilere erişimi olan agent’lar istemeden veya kötü amaçlı olarak bunları sızdırabilir.³³
  • Güvensiz Araç/API Kullanımı: Agent’ların harici araçları veya API’leri güvensiz bir şekilde çağırması.
  • Agent Taklidi/Adlandırma Saldırıları: Meşru olanları taklit eden kötü amaçlı agent’lar.³³
  • Bellek Zehirlenmesi: Bozuk bellek kötü kararlara yol açar.¹⁷⁰
  • Aşırı İzinli Erişim: Agent’ların, özellikle kullanıcılar adına hareket ederken aşırı izinleri devralması.¹⁷¹
• Azaltma Stratejileri:
  • Girdi/Çıktı Filtreleme ve Doğrulama: Yönlendirmeleri ve yanıtları temizleyin.¹⁶⁸
  • En Az Ayrıcalıklı Erişim Kontrolü: Agent’lar görevleri için minimum gerekli izinlere sahip olmalıdır.¹⁶⁸ Agent’ları doğrudan kullanıcı izinlerini devralmak yerine kendi OAuth belirteçleri/kapsamları olan ayrı istemciler olarak değerlendirin.¹⁷¹
  • Güvenli Agent’lar Arası İletişim: Kimliği doğrulanmış ve şifrelenmiş kanalları kullanın. A2A protokolü güvenli değişimi hedefler.³¹ W3C grubu standartlar üzerinde çalışıyor.²⁹
  • Araç Kullanımı Koruma Rayları: Agent’ların hangi araçları nasıl kullanabileceğine dair katı kısıtlamalar.¹⁷⁰
  • Yüksek Riskli Eylemler için İnsan Onayı:.¹⁶⁸
  • Sürekli İzleme ve Denetim: Güvenlik incelemeleri için tüm agent eylemlerini ve kararlarını günlüğe kaydedin.¹⁷⁰
  • Kriptografik Doğrulama: Bütünlük için yapay zeka istekleri/yanıtlarındaki imzalar.¹⁷²

7.3. İzleme, Günlük Kaydı ve Hata Ayıklama

• Önemi: Karmaşık, dağıtılmış sistemlerde agent davranışını anlamak, darboğazları belirlemek, hataları teşhis etmek ve güvenilirliği sağlamak için gereklidir.⁴⁰
• Neler İzlenmeli ve Günlüğe Kaydedilmeli:
  • Agent eylemleri, kararları, araç çağrıları, parametreler, sonuçlar.
  • Agent’lar arası mesajlar.
  • Durum geçişleri.
  • LLM çağrıları (yönlendirmeler, yanıtlar, token kullanımı, maliyet, gecikme).
  • Tam bağlam içeren hatalar ve istisnalar.
  • Kaynak kullanımı (CPU, bellek).
• Araçlar ve Teknikler:
  • LangSmith: LangChain/LangGraph uygulamalarını hata ayıklama, test etme, değerlendirme ve izleme için.³⁸
  • AgentOps.ai: Özerk agent’lar için izleme ve optimizasyon, AutoGen ile entegre olur.⁶⁸ Oturum tekrarlarını, metrikleri, maliyet takibini, hata tespitini sağlar.
  • Phoenix, Datadog, Helicone, Dify, Vellum Laminar: LLM uygulamaları ve agent’ları için diğer gözlemlenebilirlik araçları.⁶⁸
  • Bulut Sağlayıcı İzleme: AWS CloudWatch, Google Cloud Monitoring, Azure Monitor. ¹⁷⁵, Vertex AI Agent Engine için Google Cloud’da özel panolar oluşturmayı gösterir.
  • Özel Panolar: Temel metrikleri görselleştirme.¹⁷⁵¹⁷⁶, gecikme, token kullanımı, API çağrıları, bellek kullanımı, çıktı kalitesi, güvenilirlik gibi metrikler önerir.
  • Dağıtılmış İzleme: ²² birden fazla agent ve hizmet arasında istekleri izlemek için.
• Özerk Agent Sistemleri için Temel Performans Göstergeleri (KPI’lar): Aşağıdaki tablo, özerk agent sistemlerinin performansını, güvenilirliğini ve verimliliğini değerlendirmek için somut, ölçülebilir metrikler sunmaktadır. Bu, nitel değerlendirmeden nicel yönetime geçişi sağlar. Kullanıcı karmaşık, uzun süreli bir sistem kurmaktadır. Sistemin iyi çalışıp çalışmadığını anlamak, sorunları belirlemek ve optimize etmek için performansını ölçmesi gerekir. Genel yazılım KPI’ları faydalıdır, ancak agent’a özgü KPI’lar da gereklidir. Bu KPI’ları özetleyen bir tablo, izleme ve değerlendirme kurulumu için hızlı bir referans sağlar. Bu, agent sisteminin proaktif yönetimine ve sürekli iyileştirilmesine yardımcı olur. Tablo: Özerk Agent Sistemlerini İzlemek için Temel Performans Göstergeleri (KPI’lar)

Kategori	Örnek KPI’lar
Görev Tamamlama	Başarı Oranı (%), Ortalama Görev Süresi, Verim (görev/saat)
Hata ve Dayanıklılık	Hata Oranı (agent/görev başına), Yeniden Deneme Oranı, Hata Kurtarma Süresi, İnsan Müdahalesi Sayısı
LLM Performansı ve Maliyeti	Görev Başına Ortalama Token, Toplam LLM Maliyeti, LLM Çağrı Gecikmesi, Halüsinasyon Oranı (ölçülebilirse)
Agent Verimliliği	Agent Kullanım Oranı 178, Araç Çağrısı Başarı Oranı, Agent Adımı Başına Ortalama Süre
Orkestrasyon Kalitesi	Darboğaz Tespiti, Görev Delegasyon Doğruluğu (ölçülebilirse), İş Akışı Döngü Süresi
Kullanıcı Memnuniyeti (varsa)	Nihai çıktı kalitesine veya kullanıcı geri bildirimine dayalı.

7.4. Maliyet Optimizasyon Stratejileri

• LLM Token Tüketimi: Bu önemli bir maliyet etkenidir.¹
  • Yönlendirme Optimizasyonu: Kısa ve net yönlendirmeler. Girdiden gereksiz token/kelimeleri çıkarma.¹⁸⁰
  • Model Basamaklandırma/Yönlendirme: Daha basit alt görevler için daha ucuz/küçük modeller kullanın ve karmaşık muhakeme veya kritik adımlar için pahalı/büyük modelleri ayırın.¹⁸⁰ Bir LLM yönlendiricisi hangi modelin kullanılacağına karar verebilir. ¹⁸⁵, FrugalGPT’yi ve basamaklar için tutarlılık tabanlı değerlendirmeyi tartışır.
  • Bağlam/Bellek Yönetimi: Etkileşim başına token sayısını en aza indirmek için bellekte saklanan konuşma geçmişini optimize edin.¹⁸⁰ Her agent’a hangi bağlamın aktarılacağı konusunda seçici olun.
  • Ara Sonuçları Önbelleğe Alma: Girdiler önemli ölçüde değişmediyse pahalı LLM çağrılarının veya araç yürütmelerinin sonuçlarını saklayın ve yeniden kullanın.¹⁸¹¹⁸⁷, dağıtılmış önbellek bakımı için çoklu agent sistemlerini tartışır.
  • Toplu İşleme: Birden fazla benzer, bağımsız görev LLM işlemi gerektiriyorsa, API destekliyorsa bunları toplu olarak işleyin.
• Altyapı Maliyetleri:
  • Doğru Boyutta Hesaplama: Arka uç sunucuları ve Celery çalışanları için uygun örnek türlerini seçin.
  • Araçlar için Sunucusuz: Yalnızca yürütme süresi için ödeme yapmak üzere uygun olduğunda araçlar için sunucusuz işlevleri kullanın.
  • Optimize Edilmiş Veritabanı Kullanımı: Verimli sorgular, uygun veritabanı türleri.
• Çerçeve Seçenekleri: Açık kaynaklı çerçeveler ¹⁸³, tescilli platformlara kıyasla lisans maliyetlerini azaltabilir.
• Maliyetleri İzleme: Gözlemlenebilirlik araçları ¹⁸⁰, çağrı/agent/görev başına LLM maliyetlerini izlemeye yardımcı olabilir ve optimizasyon için sıcak noktaları belirleyebilir. AgentOps ayrıca LLM maliyetlerini de izler.⁹⁴

Özerklik, Dayanıklılık ve Maliyet Arasındaki Gerilim

Bu sistemlerin tasarımında doğal bir gerilim vardır. Özerkliği ve dayanıklılığı artırmak (örneğin, daha karmaşık LLM odaklı yeniden planlama, daha sık durum kontrol noktası oluşturma, daha sağlam hata işleme döngüleri, doğrulama için yedekli agent çağrıları yoluyla) genellikle LLM çağrılarının ve hesaplama yükünün artmasına ve dolayısıyla maliyetlerin artmasına neden olur. Maliyeti büyük ölçüde optimize etmek (örneğin, yalnızca en ucuz modeli kullanmak, minimum günlük kaydı, basit hata yeniden denemeleri) sistemin karmaşık hataları özerk bir şekilde ele alma ve uzun süreli görevleri sağlam bir şekilde tamamlama yeteneğini tehlikeye atabilir.

Kullanıcının yüksek özerklik (“bitene kadar durmaz”) ve dayanıklılık (uzun süreli görevlerle ima edilir) istediği göz önüne alındığında, bunu başarmak LLM’ler kullanılarak dinamik yeniden planlama (Bölüm 5.2), sağlam durum yönetimi (Bölüm 3.2) ve kapsamlı izleme (Bölüm 7.3) gibi özellikleri içerir. Bu özelliklerin her biri, özellikle muhakeme veya ayrıntılı durum kalıcılığı için sık LLM çağrıları içerenler, maliyetler (LLM tokenleri, hesaplama, depolama) doğurur (Bölüm 7.4). Örneğin, bir çalışanın hatasını analiz eden ve yeni bir plan oluşturan bir orkestratör LLM, ekstra bir LLM çağrısıdır. Ayrıntılı durumu sık sık saklamak depolama ve G/Ç maliyetine neden olur. Kapsamlı günlük kaydı ve izleme kaynak tüketir. Tersine, agresif maliyet kesintileri (örneğin, yalnızca basit modeller kullanmak, minimum durum, az sayıda yeniden deneme) sistemi kırılgan ve daha az özerk hale getirebilir ve “durup soruyor” sorununa geri dönülmesine yol açabilir. Bu nedenle, bir ödünleşim vardır. “En iyi” sistem yalnızca en özerk veya en ucuz olan değil, güvenilirlik, performans ve bütçe açısından belirli uygulamanın ihtiyaçları için doğru dengeyi kuran sistemdir. Rapor bu ödünleşimi vurgulamalı ve kullanıcıya “değer odaklı” bir yaklaşım düşünmesini tavsiye etmelidir. Bu, en yüksek özerkliği ve dayanıklılığı talep eden görevleri belirlemeyi ve oraya daha fazla kaynak yatırmayı, potansiyel olarak iş akışının daha az kritik bölümleri için daha basit, daha ucuz yaklaşımlar kullanmayı içerir. Model basamaklandırma gibi teknikler ¹⁸⁰ bu gerilime doğrudan bir yanıttır.

Örnek Senaryo: Özerk Bir Agent İş Akışının Kavramsal İncelemesi

Senaryo

Karmaşık, çok adımlı bir web tabanlı görev düşünelim: “E-ticarette ortaya çıkan yapay zeka trendlerini araştırın, küçük işletmemizle ilgili ilk 3’ünü belirleyin, her biri için bir blog yazısı taslağı oluşturun ve pazarlama ekibiyle bir inceleme toplantısı planlayın.”

Örnek için Çerçeve Seçimi

Kavramları göstermek için bir çerçeve seçilecektir (örneğin, hiyerarşik bir sürece ve özel bir yönetici agent’ına sahip CrewAI veya koşullu LLM odaklı yönlendirmeye sahip LangGraph).

• CrewAI Örnek Odağı ¹⁰:
  • Yönetici Agent’ı (örneğin, “Baş Araştırma Stratejisti”) ve Çalışan Agent’ları (örneğin, “Web Araştırmacısı,” “Trend Analisti,” “İçerik Taslakçısı,” “Toplantı Planlayıcısı”) tanımlayın.
  • Yönetici agent’ı ana hedefi çalışanlar için görevlere ayırır.
  • Yönetici agent’ının kısmi bir sonuç veya bir hata (örneğin, “Web Araştırmacısı” önemli bir kaynağa erişemiyor) alabileceğini gösterin.
  • Yönetici agent’ının ¹⁰ hata hakkında nasıl muhakeme yürütebileceğini kavramsal olarak gösterin: “Web Araştırmacısı başarısız oldu. Hata olası bir ödeme duvarını gösteriyor. Trend Analistine alternatif açık erişimli veritabanlarını denemesi veya benzer bilgiler için farklı bir arama stratejisi kullanması ve ardından bunu İçerik Taslakçısına iletmesi talimatını vermeliyim.” Bu, yeniden görevlendirerek veya talimatları değiştirerek planı uyarlamayı gösterir.
  • CrewAI’nin hiyerarşik süreci ¹⁰ yönetici/çalışan modeline doğal olarak uyar. Yönetici “iş akışını koordine eder, görevleri devreder ve sonuçları doğrular.” ¹¹², “otonom sorgu hatası düzeltme yeteneği” ve iş akışını tanımlayan yönetici agent’ından bahseder.
• LangGraph Örnek Odağı ⁴⁶:
  • Her adım için grafik düğümlerini tanımlayın (Araştırma, Analiz, Taslak, Planlama).
  • Bir “Orkestratör/Muhakeme Düğümü” (LLM tarafından desteklenir) her çalışan düğümünün çıktısını değerlendirir.
  • “Araştırma Düğümü” bir hata veya yetersiz veri döndürürse, koşullu bir kenar Orkestratör Düğümüne geri yönlendirir.
  • Orkestratör Düğümü durumu (hata mesajı, önceki denemeler) analiz eder ve bir sonraki adıma karar verir: örneğin, bir “AraştırmaSorgusunuİyileştir Düğümü”nü (daha iyi bir sorgu oluşturmak için başka bir LLM çağrısı) çağırır ve ardından “Araştırma Düğümü”ne yeniden yönlendirir veya bu birden çok kez başarısız olursa bir “AlternatifVeriKaynağı Düğümü”ne yönlendirir.
  • ⁴⁷, LLM’lerin bir döngüde eylemler hakkında muhakeme yürüttüğünü ve ⁷⁶, LLM’lerin koşullu kenarlarda kararlar aldığını vurgular. ⁷², GraphRecursionError ve düğüm düzeyinde hata işleme gibi somut hata işleme modelleri sunar.

Vurgulanacak Temel Hususlar

• Görev delegasyonu ve alt görev tanımı.
• Agent iletişimi/bilgi paylaşımı.
• İş akışı sırasında durum takibi.
• Olası bir hata senaryosu.
• Orkestratör/yönetici agent’ının muhakeme süreci (kavramsal LLM “düşünce süreci”).
• Yeniden planlama eylemi (örneğin, farklı bir araç denemek, yeniden atamak, bir alt görevi değiştirmek).
• İş akışının hedefe doğru devam etmesi.

Orkestratörün “Dünya Modeli” ve Muhakeme Sadakatinin Kritikliği

Dinamik yeniden planlamanın etkinliği, büyük ölçüde orkestratör agent’ının iç “dünya modeline” bağlıdır – mevcut çalışan agent’ları, yetenekleri, araçları, olası hata türleri ve genel görev bağımlılıkları hakkındaki anlayışı. Bu model yanlışsa veya hatalar hakkındaki LLM muhakemesi yüzeyselse, yeniden planlama girişimleri saf, verimsiz veya hatta ters etki yaratabilir.

Kullanıcının, diğer yapay zekaları kontrol eden ve sorunlara uyum sağlayan bir yapay zeka istediği göz önüne alındığında, bu, kontrol eden yapay zekanın (orkestratör) sistemin durumuna ve çalışan yapay zekaların çıktılarına göre kararlar almasını gerektirir (Bölüm 5.2). Orkestratörün iyi kararlar alabilmesi için, özellikle yeni hata senaryolarında, yalnızca mevcut çalışanların bir listesinden daha fazlasına ihtiyacı vardır. Her çalışanın ne yaptığını, yaygın hata modlarının neler olduğunu ve farklı görevlerin birbirleriyle nasıl ilişkili olduğunu (bir LLM anlamında) “anlaması” gerekir. ¹¹ (planlama, geri bildirime dayalı olarak dinamik olarak uyum sağlamayı içerir), ¹¹ (planlama, stratejiler geliştirmeyi içerir), ¹² (LLM’in “beyin” olarak akışı kontrol etmesi), ¹³ (orkestratörün gerçek zamanlı verilere ve kurallara dayalı olarak en uygun agent’ları dinamik olarak belirlemesi) gibi belgeler, orkestratörde bu karmaşık anlayış ve muhakeme yeteneği ihtiyacına işaret eder. Orkestratörün LLM’i, daha derin bir anlayış olmadan hata durumunda yalnızca rastgele alternatifler denerse, verimsiz bir şekilde döngüye girebilir veya sorunu çözemeyebilir. Bu nedenle, rapor, orkestratör agent’ının yönlendirmelerini, çalışan agent’lar hakkındaki bilgilere erişimini (örneğin, CrewAI’deki iyi tanımlanmış agent rolleri/açıklamaları veya araç açıklamaları yoluyla) dikkatli bir şekilde tasarlamanın ve potansiyel olarak yeniden planlama stratejileri hakkındaki muhakemesini geliştirmek için başarılı ve başarısız görev yürütme örnekleri sağlamanın önemini vurgulamalıdır. Orkestratör için kullanılan LLM’in kalitesi de çok önemlidir.

Sonuç: Gerçekten Özerk Web Uygulamalarına Doğru İlerlemek

Temel Stratejilerin Özeti

Temel ilkeler kısaca yinelenecektir: net bir orkestratöre sahip MAS mimarisi, sağlam durum yönetimi, eşzamansız işleme, uygun çerçeve seçimi, LLM odaklı dinamik yeniden planlama ile karmaşık hata işleme, güvenli entegrasyon, özenli izleme ve maliyet farkındalığı.

Kullanıcının Temel İhtiyacını Karşılamak

Bu stratejilerin, yapay zeka agent’larının sürekli insan müdahalesi olmadan uzun süreli görevleri tamamlamak için diğer agent’ları özerk bir şekilde yönetebileceği sistemlerin oluşturulmasını nasıl doğrudan sağladığı vurgulanacaktır; bu, bu özel amaç için bolt.new gibi araçların yeteneklerinin çok ötesine geçer.

Geleceğe Bakış ve Potansiyel Gelişmeler

Gelişmekte olan trendlere kısaca değinilecektir: daha gelişmiş agent’lar arası iletişim protokolleri ²⁹, daha karmaşık uyarlanabilir planlama ⁴, orkestrasyon stratejilerini optimize etmek için pekiştirmeli öğrenme (bu çerçevelerde pratik örnekler mevcut belgelerde seyrek olsa da) ¹⁸⁸ ve giderek daha özerk hale gelen sistemler için geliştirilmiş güvenlik önlemleri.