07 Eki 2025·8 dk
Üretimde Çökmeyen Agentik Sistemler Tasarlamak
Çoğu agentik sistemin üretimde neden başarısız olduğu ve durum makineleri, açık araç sözleşmeleri, yeniden denemeler ve derin gözlemlenebilirlik ile güvenilir ajanlar nasıl tasarlanır.
Çoğu agentik sistemin üretimde neden başarısız olduğu ve durum makineleri, açık araç sözleşmeleri, yeniden denemeler ve derin gözlemlenebilirlik ile güvenilir ajanlar nasıl tasarlanır.
Agentik sistemler, bir LLM'in sadece bir prompta cevap vermesi değil, sonraki adımı kararlaştırmasıdır: hangi araçların çağrılacağı, hangi verilerin alınacağı, hangi adımların çalıştırılacağı ve ne zaman “bittiğinin” anlaşılacağı gibi. Bunlar bir modeli, bir dizi aracı (API'ler, veritabanları, servisler), bir planlama/uygulama döngüsünü ve her şeyi birbirine bağlayan altyapıyı birleştirir.
Demoda bu sihir gibi görünür: bir ajan bir plan oluşturur, birkaç araç çağırır ve mükemmel bir sonuç döner. Mutlu yol kısadır, gecikme düşüktür ve hiçbir şey aynı anda başarısız olmaz.
Gerçek iş yükleri altında aynı ajan, demoda hiç görmediği biçimlerde zorlanır:
Sonuç: yeniden üretmesi zor, arka planda sessiz veri bozulması olan, kullanıcı akışlarının ara sıra takıldığı veya sonsuza dek döndüğü kırılgan davranışlar.
Kırılgan ajanlar sadece “kullanıcı memnuniyetini” zedelemez. Onlar:
Bu makale daha iyi promptlar değil, mühendislik desenleri hakkında. Durum makineleri, açık araç sözleşmeleri, yeniden deneme ve hata yönetimi stratejileri, bellek ve eşzamanlılık kontrolü ile ajanik sistemleri yük altında öngörülebilir yapan gözlemlenebilirlik desenlerine bakacağız—sahnedeki gibi etkileyici olmalarının ötesinde.
Çoğu ajan sistemi tek bir mutlu yol demosunda iyi görünür. Trafik, araçlar ve uç vakalar aynı anda geldiğinde başarısız olurlar.
Basit orkestrasyon, modelin bir veya iki çağrıda “doğru şeyi yapacağını” varsayar. Gerçek kullanımda tekrar eden desenler görürsünüz:
Açık durumlar ve son koşullar olmadan bu davranışlar kaçınılmazdır.
LLM örneklemesi, gecikme değişkenliği ve araç zamanlaması gizli deterministik olmayanlık yaratır. Aynı girdi farklı dallara sapabilir, farklı araçları çağırabilir veya araç sonuçlarını farklı yorumlayabilir.
Ölçeklendiğinde, araç sorunları hakim hale gelir:
Bunların her biri anlamsız döngülere, yeniden denemelere veya yanlış nihai cevaplara dönüşür.
10 RPS'de nadiren bozulan bir şey 1.000 RPS'de sürekli kırılır. Eşzamanlılık şu sorunları açığa çıkarır:
Ürün ekipleri genellikle deterministik iş akışları, net SLA'lar ve denetlenebilirlik bekler. Ajanlar, sınırlama getirilmezse olasılıksal, elinden gelenin en iyisini yapan davranışlar sunar ve zayıf garantiler verir.
Mimariler bu uyumsuzluğu göz ardı ettiğinde—ajanları stokastik planlayıcılar yerine geleneksel hizmetler gibi ele almak—sistemler en çok güvenilirlik gerektiğinde tahmin edilemez davranır.
Üretime hazır ajanlar “zeki promptlardan” çok disiplinli sistem tasarımına dayanır. Onları bazen arada bir LLM çağıran küçük, öngörülebilir makineler olarak düşünmek faydalıdır; gizemli LLM blobları olarak değil.
Dört özellik en önemli olanlardır:
Bu özellikler yalnızca promptlardan gelmez. Bunlar yapıdan gelir.
Birçok ekibin başladığı varsayılan desen şudur: “while not done, call the model, let it think, maybe call a tool, repeat”. Bu prototip için kolaydır ama işletmesi zordur.
Daha güvenli bir desen, ajanı bir açık iş akışı olarak temsil etmektir:
COLLECTING_INPUT, PLANNING, EXECUTING_STEP, WAITING_ON_HUMAN, DONE).Bu, ajanı her adımı denetlenebilir, test edilebilir ve yeniden oynatılabilir bir durum makinesine dönüştürür. Serbest döngüler esnek hissettirir; ancak açık iş akışları olayları hata ayıklanabilir ve davranışı denetlenebilir kılar.
Her şeyi yapan monolitik ajanlar caziptir, fakat ilgisiz sorumluluklar arasında sıkı bağımlılık yaratır: planlama, geri getirme, iş mantığı, UI orkestrasyonu ve daha fazlası.
Bunun yerine, küçük, iyi sınırlandırılmış ajanlar veya yetenekler (skills) bileşimi yapın:
Her yeteneğin kendi durum makinesi, araçları ve güvenlik kuralları olabilir. Bileşim mantığı daha sonra yüksek seviyeli bir iş akışı olur; tek bir ajanın içindeki sürekli genişleyen prompt olmaz.
Bu modülerlik, her ajanın üzerinde akıl yürütülebilecek kadar basit kalmasını sağlar ve bir yeteneği evriltirken diğerlerini destabilize etmez.
Ajanı üç katmana bölmek faydalı bir zihinsel modeldir:
Karar politikası (LLM promptları + model)
Ajanın nasıl sonraki eylemi seçtiğini kapsar; sıkı kısıtlar altında yorumlanır. Modeli değiştirebilmeli, temperature ayarını değiştirebilmeli veya promptları rafine edebilmelisiniz; sistem kabuğunu değiştirmeden.
Durum makinesi / iş akışı motoru
Sürecin nerede olduğunu, hangi geçişlerin mümkün olduğunu ve ilerlemenin nasıl kalıcı hale getirileceğini yönetir. Politika bir hamle önersin; durum makinesi bunu doğrular ve uygular.
Araç katmanı
Dünyada ne olabileceğini uygular: API'ler, veritabanları, kuyruklar, dış servisler. Araçlar dar, iyi tiplenmiş sözleşmeler açığa çıkarır ve yetkilendirme, kota ve girdi doğrulaması uygular.
Bu ayrımı uygulayarak iş mantığını promptlara veya araç açıklamalarına saklama tuzağından kaçınırsınız. LLM, deterministik bir kabuğun içindeki bir karar bileşeni olur; kabuk kendisi değil.
En güvenilir agentik sistemler en etkileyici demolar değil—beyaz tahtada davranışını açıklayabildiğiniz sistemlerdir.
Somut olarak:
Bu küçük, bileşenli, iyi yapılandırılmış ajanlara yönelik eğilim, kapsam büyüdükçe sistemlerin kendi karmaşıklığı altında çökmesini önler.
Çoğu ajan uygulaması, bir LLM çağrısının etrafına sarılmış "düşün, hareket et, gözle" döngüsü olarak başlar. Demo için kabul edilebilir, ama hızla opak ve kırılgan hale gelir. Daha iyi bir yaklaşım ajanı açık bir durum makinesi olarak ele almaktır: tetikleyici olaylarla çalışan sonlu bir durum kümesi ve net tanımlanmış geçişler.
Modelin ne yapacağını örtük olarak kararlaştırmasına izin vermek yerine küçük bir durum diyagramı tanımlayın:
Bu durumlar arasındaki geçişler UserRequestReceived, ToolCallSucceeded, ToolValidationFailed, TimeoutExceeded veya HumanOverride gibi türlendirilmiş olaylar ile tetiklenir. Her olay ve mevcut durum bir sonraki durumu ve yapılacak eylemleri belirler.
Bu, yeniden denemeleri ve zaman aşımlarını basitleştirir: her duruma politika ekleyebilirsiniz (ör. CALL_TOOL üç kez üstel geri çekilmeyle yeniden dener, PLAN hiç yeniden denemez) yerine yeniden deneme mantığını kod tabanına yaymak.
Geçerli durumu ve minimal bağlamı harici bir depoda (veritabanı, kuyruk veya iş akışı motoru) saklayın. Ajan sonra saf bir fonksiyon olur:
next_state, actions = transition(current_state, event, context)
Bu şunları mümkün kılar:
Bir durum makinesiyle ajan davranışının her adımı açıktır: hangi durumda olduğu, hangi olayın meydana geldiği, hangi geçişin tetiklendiği ve hangi yan etkilerin üretildiği. Bu netlik hata ayıklamayı hızlandırır, olay soruşturmalarını basitleştirir ve uyumluluk incelemeleri için doğal bir denetim izi oluşturur. Günlükler ve durum geçmişi ile belirli riskli eylemlerin sadece belirli durumlardan ve tanımlı koşullar altında alındığını kanıtlayabilirsiniz.
Araçlar "prompt içinde gizlenmiş API'ler" gibi değil, iyi tasarlanmış arayüzler gibi göründüğünde ajanlar çok daha öngörülebilir davranır.
Her aracın bir sözleşmesi olmalı:
InvalidInput, NotFound, RateLimited, TransientFailure) ve açık semantikBu sözleşmeyi modele yapılandırılmış dokümantasyon olarak sunun, düz metin duvarı olarak değil. Ajan planlayıcısı hangi hataların yeniden denenebilir olduğunu, hangilerinin kullanıcı müdahalesi gerektirdiğini ve hangilerinin iş akışını durduracağını bilmelidir.
Araç I/O'sunu diğer üretim API'ları gibi ele alın:
Bu, promptları basitleştirmenizi sağlar: uzun talimatlar yerine şema odaklı rehberliğe güvenin. Net kısıtlar, uydurma argümanları ve anlamsız araç dizilerini azaltır.
Araçlar gelişir; ajanlar her değişiklikte bozulmamalı.
v1, v1.1, v2) ve ajanları bir versiyona sabitleyin.Planlama mantığı daha sonra farklı olgunluk düzeylerindeki ajanlar ve araçları güvenle karıştırabilir.
Sözleşmeleri kısmi başarısızlık göz önünde bulundurarak tasarlayın:
Ajan buna göre adapte olabilir: azaltılmış işlevsellikle akışı sürdürebilir, kullanıcıdan onay isteyebilir veya yedek bir araca geçiş yapabilir.
Araç sözleşmeleri güvenlik limitlerini kodlamak için doğal bir yerdir:
confirm: true).Bunu sunucu tarafı kontrollerle birleştirin; modelin "davranacağına" yalnızca güvenmeyin.
Araçlar net, doğrulanmış ve versiyonlanmış sözleşmelere sahip olduğunda, promptlar daha kısa olur, orkestrasyon mantığı basitleşir ve hata ayıklama çok daha kolay hale gelir. Karmaşıklığı kırılgan doğal dil talimatlarından deterministik şemalara ve politikalara taşırsınız; bu, uydurulmuş araç çağrılarını ve beklenmedik yan etkileri azaltır.
Güvenilir agentik sistemler her şeyin eninde sonunda başarısız olacağını varsayar: modeller, araçlar, ağlar hatta koordinasyon katmanınız. Amaç başarısızlığı önlemek değil, onu ucuz ve güvenli hale getirmektir.
Idempotentlik demek: aynı isteği tekrarlamak, dışarıdan görünen etkiyi bir kez yapmakla aynı olmalıdır. Bu, kısmi hatalar veya belirsiz yanıtlar sonrasında ajanların sıkça araç çağrısı tekrarladığı durumlar için kritik önemdedir.
Araçları şu şekilde idempotent yapın:
request_id ekleyin. Araç bu ID'yi gördüğünde aynı sonucu döndürür.Geçici hatalar (zaman aşımı, kota, 5xx) için yapılandırılmış yeniden denemeler kullanın: üstel geri çekilme, sürpriz jitter ve sıkı maksimum deneme sayısı. Her denemeyi korelasyon ID'leri ile loglayın ki ajan davranışını izleyebilesiniz.
Kalıcı hatalar (4xx, doğrulama hataları, iş kuralı ihlalleri) için yeniden deneme yapmayın. Yapılandırılmış bir hatayı ajana sunun ki planı revize etsin, kullanıcıya sorsun veya farklı bir araç seçsin.
Hem ajan hem araç katmanlarında devre kesiciler uygulayın: tekrarlayan başarısızlıklardan sonra o araca geçici blok koyun ve hızlıca başarısız olun. Bunu iyi tanımlanmış yedeklerle eşleştirin: düşürülmüş modlar, önbelleğe alınmış veriler veya alternatif araçlar.
Ajan döngüsünden kör yeniden denemelerden kaçının. Idempotent araçlar ve açık hata sınıfları olmadan sadece yan etkileri, gecikmeyi ve maliyeti çoğaltırsınız.
Güvenilir ajanlar, durumun ne olduğu ve nerede durduğu hakkında net düşünceyle başlar.
Bir isteği ele alan bir servisi nasıl düşünüyorsanız ajanı da öyle ele alın:
Bunları karıştırmak kafa karışıklığına ve hatalara yol açar. Örneğin geçici araç sonuçlarını “belleğe” koymak ajanların gelecekte bozulmuş bağlam kullanmasına neden olur.
Üç ana seçenek var:
İyi bir kural: LLM, açık bir durum nesnesi üzerinde durumsuz bir fonksiyondur. O nesneyi modelin dışında kalıcı yapın ve promptları ondan üretin.
Yaygın bir hata, konuşma günlüklerini, izleri veya ham promptları fiili bellek olarak kullanmaktır.
Sorunlar:
Bunun yerine yapılandırılmış bellek şemaları tanımlayın: user_profile, project, task_history vb. Günlükleri durumdan türetin, durumdan günlük oluşturmayın.
Birden fazla araç veya ajan aynı varlıkları güncelliyorsa (örn. CRM kaydı veya görev durumu), temel tutarlılık kontrollerine ihtiyacınız var:
Yüksek değerli işlemler için, konuşma günlüğünden ayrı olarak ne değişti, neden ve hangi girdilere dayanarak değiştiğini kaydeden bir karar günlüğü tutun.
Çökme, dağıtım ve kota sınırlamalarıyla başa çıkmak için iş akışları yeniden başlatılabilir olmalı:
Bu ayrıca zaman yolculuğu hata ayıklamayı mümkün kılar: kötü karara yol açan tam durumu inceleyip yeniden oynatabilirsiniz.
Bellek hem bir varlık hem de risk oluşturur. Üretim ajanları için:
Belleği ürüne dair bir yüzey gibi ele alın: tasarlanmış, versiyonlanmış ve yönetilen; rastgele büyüyen bir metin yığını değil.
Ajanlar beyaz tahtada ardışık görünür ama gerçek yük altında dağıtık sistemler gibi davranır. Çok sayıda eşzamanlı kullanıcı, araç ve arka plan işi olduğunda yarış koşulları, çift işler ve sıralama sorunlarıyla uğraşırsınız.
Yaygın hata modları:
Bunları idempotent araç sözleşmeleri, açık iş akışı durumu ve veri katmanında optimistik veya pesimist kilitleme ile hafifletin.
Eşzamanlı istek–cevap akışları basittir ama kırılgandır: her bağımlılık ayakta olmalı, kota içinde olmalı ve hızlı olmalıdır. Ajanlar birçok araca yayılmaya veya paralel alt görevlere fırlamaya başlarsa, uzun süren veya yan etkiye sahip adımları kuyruğun arkasına alın.
Kuyruk tabanlı orkestrasyon size şunları sağlar:
Ajanlar tipik olarak üç kota sınıfına takılır:
Kullanıcı-başına, kiracı-başına ve global kotolarla açık bir oran sınırlama katmanına ihtiyacınız var. Token bucket veya leaky bucket gibi mekanizmalar kullanın ve ajanların nazikçe geri çekilmeleri için açık hata tipleri (RATE_LIMIT_SOFT, RATE_LIMIT_HARD) sağlayın.
Backpressure sistemin kendisini stres altında korumasıdır. Stratejiler:
Kuyruk derinliği, işçi kullanım oranı ve model/araç hata oranları ile gecikme yüzdelerini izleyin. Kuyruk derinlikleriyle birlikte artan gecikme veya 429/503 hataları, ajanların çevrelerini aşırı yüklemeye başladığının erken uyarısıdır.
Bir ajanı güvenilir yapmak istiyorsanız iki soruyu hızlıca cevaplayabilmelisiniz: ne yaptı? ve neden yaptı? Agentik sistemler için gözlemlenebilirlik bu cevapları ucuz ve kesin hale getirmekle ilgilidir.
Tasarımı öyle yapın ki tek bir görev şu öğeler boyunca bir ize sahip olsun:
Bu iz içinde önemli kararlar (yönlendirme seçimi, plan revizyonu, guardrail tetiklemeleri) için yapılandırılmış günlükler ve iş hacmi ile sağlık için metrikler iliştirin.
Kullanışlı bir iz genellikle şunları içerir:
Promptları, araç girdilerini ve çıktıları yapılandırılmış biçimde loglayın ama önce bir redaksiyon katmanından geçirin:
Ham içerikleri alt ortamlarda özellik bayraklarıyla erişilebilir tutun; üretim varsayılan olarak redakte edilmiş görünüm sunmalı.
En azından şunları izleyin:
Olaylar olduğunda, iyi izler ve metrikler sizi “ajanın kırılgan hissettiği” yorumundan alıp şu gibi net bir ifadeye götürür: “P95 görevleri ToolSelection aşamasında 2 yeniden denemenin ardından yeni billing_service şemasından dolayı başarısız oluyor”, böylece tanı süresi saatler yerine dakikalara iner ve davranışı ayarlamak için somut kollar sunar.
Ajanları test etmek, çağırdıkları araçları ve her şeyi birbirine bağlayan akışları test etmek demektir. Bunu sadece prompt inceliği değil, dağıtık sistem testi gibi ele alın.
Testlere araç sınırından başlayın:
Bu testler hiçbir zaman LLM'e dayanmaz. Aracı sentetik girdilerle doğrudan çağırır ve tam çıktıyı veya hata sözleşmesini iddia edersiniz.
Entegrasyon testleri ajan iş akışını uçtan uca çalıştırır: LLM + araçlar + orkestrasyon.
Bunları senaryo tabanlı testler olarak modelleyin:
Bu testler LLM'in her tokenini değil, durum geçişlerini ve araç çağrılarını doğrular. Hangi araçların çağrıldığı, hangi argümanlarla, hangi sırayla ve sonucun ne olduğu kontrol edilir.
Testleri tekrar üretilebilir tutmak için LLM yanıtlarını ve araç çıktıları fikstürleyin:
Tipik desen:
with mocked_llm(fixtures_dir="fixtures/llm"), mocked_tools():
result = run_agent_scenario(input_case)
assert result.state == "COMPLETED"
Her prompt veya şema değişikliği mutlaka bir regresyon çalıştırmalı:
Şema evrimi (alan ekleme, tip sıkılaştırma) bunu kırabilecek ajanlar veya araçlar için ayrı regresyon vakalarına sahip olmalıdır.
Yeni bir modeli, politikayı veya yönlendirme stratejisini doğrudan üretime göndermeyin.
Bunun yerine:
Çevrimdışı kapıları geçtikten sonra yeni varyantı feature flag ve kademeli dağıtım ile üretime alın.
Ajan günlükleri sıklıkla hassas kullanıcı verisi içerir. Testler buna saygı göstermeli:
Bu kuralları CI boru hattınıza kodlayın ki hiçbir test artefaktı anonimleştirme kontrolleri olmadan üretilip saklanamasın.
Ajanları üretimde işletmek statik bir modeli çalıştırmaktan çok dağıtık bir sistemi çalıştırmaya benzer. Yayın, net güvenilirlik hedefleri ve disiplinli değişim yönetimi için kontroller gerekir.
Yeni ajanları veya davranışları kademeli olarak tanıtın:
Bütün bunları feature flag'ler ve konfigürasyonla destekleyin: yönlendirme kuralları, etkin araçlar, temperature, güvenlik ayarları. Değişiklikler kod değil konfigürasyonla dağıtılabilmeli ve anında geri alınabilmelidir.
Hem sistem sağlığı hem kullanıcı değeri yansıtan SLO'lar tanımlayın:
Bunları alarmlara bağlayın ve olayları diğer üretim servisleriniz gibi yönetin: net sahiplik, triage runbook'ları ve standart hafifletme adımları (flag geri alma, trafik boşaltma, güvenli mod davranışı).
Promptları, araçları ve politikaları günlükler, izler ve konuşma transkriptleri ile rafine edin. Her değişikliği versiyonlu bir eser olarak ele alın, inceleme, onay ve geri alma kapasitesiyle yönetin.
Sessiz prompt veya araç değişikliklerinden kaçının. Değişim kontrolü olmadan regresyonları belirli düzenlemelere bağlayamazsınız; olay yanıtı mühendislik tahminlerine dönüşür.
Üretim hazır bir agentik sistem, sorumlulukların net ayrımından fayda sağlar. Amaç, ajanı karar verme konusunda akıllı, altyapıda ise aptal tutmaktır.
1. Gateway / API kenarı
İstemciler (uygulamalar, servisler, UI'lar) için tek giriş noktasıdır. Şunlarla ilgilenir:
2. Orkestratör
Orkestratör “beyin sapı”, ama beyin değil. Şunları koordine eder:
LLM(ler) orkestratörün arkasında yaşar; planner tarafından ve belirli dil anlama gerektiren araçlar tarafından kullanılır.
3. Araçlar ve depolama katmanı
İş mantığı mevcut mikroservislerde, kuyruklarda ve veri sistemlerinde kalır. Araçlar, şunların etrafındaki ince sargılardır:
Orkestratör araçları sıkı sözleşmelerle çağırır; depolama sistemleri gerçek veri kaynağı olarak kalır.
Gateway'de kimlik doğrulamayı ve kotaları uygulayın; orkestratörde güvenlik, veri erişimi ve politikayı uygulayın. Tüm çağrılar (LLM ve araçlar) yapılandırılmış telemetri yayınlasın ve bu pipeline şunları beslesin:
Daha basit bir mimari (gateway → tek orkestratör → araçlar) işletmesi kolaydır; ayrı plannerlar, politika motorları ve model gateway'leri ek esneklik sağlar, fakat koordinasyon, gecikme ve operasyonel karmaşıklık getirir.
Artık üretim yükü altında öngörülebilir davranan ajanlar için temel bileşenlere sahipsiniz: açık durum makineleri, net araç sözleşmeleri, disiplinli yeniden deneme kuralları ve derin gözlemlenebilirlik. Son adım bu fikirleri takımınız için tekrarlanabilir uygulamalara dönüştürmektir.
Her ajanı bir durumlu iş akışı olarak düşünün:
Bu parçalar hizalandığında, sistemler uç vakalar altında çökmek yerine kademeli olarak bozulur.
Bir prototip ajanı gerçek kullanıcılara göndermeden önce doğrulayın:
Herhangi bir madde eksikse, hâlâ prototip aşamasındasınız.
Sürdürülebilir bir kurulum genellikle şunu ayırır:
Bu, ürün ekiplerinin hızlı hareket etmesini, platform ekiplerinin ise güvenilirlik, güvenlik ve maliyet kontrollerini zorunlu kılmasını sağlar.
Temeller stabil olduktan sonra keşfedebileceğiniz alanlar:
Bu ilerlemeyi yinelemeli ve kontrollü tutun: yeni öğrenme bileşenlerini feature flag'lerin arkasında, çevrimdışı değerlendirmeler ve güçlü guardrail'larla tanıtın.
Temel tema hep aynı: başarısızlığı tasarlayın, zekâ yerine açıklığı tercih edin ve gözlemleyip güvenle geri alabileceğiniz yerlerde yineleyin. Bu kısıtlar olduğunda agentik sistemler korkutucu prototipler olmaktan çıkar ve kuruluşunuzun güvenebileceği altyapıya dönüşür.
Bir agentik sistem, bir LLM'in tek bir prompta cevap vermekten öteye geçerek sonraki adımı kararlaştırdığı bir uygulamadır: hangi araçların çağrılacağı, hangi verilerin alınacağı, bir iş akışının hangi adımının çalıştırılacağı ve ne zaman bitileceği gibi kararlar verir.
Basit bir sohbet tamamlamadan farklı olarak, bir agentik sistem şunları birleştirir:
Üretimde, LLM tüm sistem değil, daha büyük ve deterministik bir kabuğun içindeki bir karar bileşeni haline gelir.
Demo'lar genellikle tek bir mutlu yol üzerinde çalışır: bir kullanıcı, ideal araç davranışı, zaman aşımı yok, şema kayması yok ve kısa konuşmalar. Üretim yükü altında ajanlar şunlarla karşılaşır:
Açık iş akışları, sözleşmeler ve hata işleme olmadan, bu faktörler demo ortamlarında hiçbir zaman görünmeyen döngüler, duraklamalar, kısmi işler ve sessiz hatalar yaratır.
LLM'i serbest biçimli bir döngü yerine açık bir yapı içinde çalıştırın:
Ajanı while not done: call LLM yerine adlandırılmış durumlar ve türlendirilmiş olaylarla bir iş akışı olarak modelleyin.
Tipik durumlar şunları içerebilir:
Araçları, promptların içinde gizlenmiş düz yazılar yerine doğru üretim API'leri gibi tasarlayın. Her aracın şunları kapsayan bir sözleşmesi olmalı:
Her şeyin eninde sonunda başarısız olacağını varsayarak tasarlayın: modeller, araçlar, ağlar hatta kendi koordinasyon katmanınız. Amaç başarısızlıktan kaçınmak değil, onu ucuz ve güvenli hale getirmektir.
Temel desenler:
Kısa vadeli durum ile uzun vadeli belleği ayırın ve LLM'i durumsuz tutun.
LLM'i açık bir durum nesnesi üzerinde çalışan saf bir fonksiyon olarak ele alın: ilgili durumu yükleyin, promptu oluşturun, modeli çağırın ve güncellenmiş durumu kalıcı hale getirin. Ham konuşma geçmişini veya günlükleri bellek olarak kullanmaktan kaçının; bunun yerine bunlardan yapılandırılmış, özetlenmiş kayıtlar türetin ve saklama/şeffaflık kurallarını uygulayın.
Agent sisteminizi gerçek yük altında bir dağıtık sistem olarak düşünün; her akış sıradan görülebilir ama birçok kullanıcı olduğunda yarış koşulları, çift işler ve sıralama sorunları ortaya çıkar.
Güvenli kalmak için:
Her görevin şunları içeren bir izsi olmalı:
İz üzerinde ilişkilendirme kimlikleriyle yapılandırılmış günlükler, önemli kararlar (yönlendirme seçimi, plan revizyonu, guardrail tetiklemeleri) ve metrikler ekleyin. İz genellikle şu meta verileri içerir: tenant, kullanıcı, kanal, öncelik; agent durumu: mevcut durum adı, sonraki durum, deneme sayısı; araç I/O: girdi, çıktı, gecikme, hatalar; model çağrıları: prompt şablon ID, model adı, token sayıları, gecikme.
Günlükleri kaydederken PII ve gizli bilgileri maskeleyin; büyük yükleri kırpın ve korelasyon için hash'lerini saklayın. Bu sayede olay incelemeleri “ajan kararsız görünüyor”dan, belirli araç ve durumun neden olduğunu söylemeye dönüşür.
Ajanları gelişen servisler olarak yönetin; statik promptlar gibi değil.
Önerilen uygulamalar:
Bu yaklaşımla, davranışı adım adım açıklayabilir, test edebilir ve hataları gizemli “ajan düşünce” döngülerinin peşinden koşmak yerine kolayca ayıklayabilirsiniz.
PLAN – isteği yorumla ve adım adım bir plan üretCALL_TOOL – belirli bir aracı veya araç paketini çağırVERIFY – çıktıları basit kurallara veya ikincil model kontrollerine göre denetleRECOVER – hataları yeniden deneme, yedekleme veya yükseltme ile ele alDONE / FAILED – sonlanma durumlarıToolCallSucceeded, TimeoutExceeded gibi olaylar ve geçerli durum birlikte bir sonraki durumu belirler. Bu yapı, yeniden denemeleri, zaman aşımlarını ve hata işleme mantığını promptlarda veya dağıtık kod tabanında rastgele dağılmaktan çıkarıp açık hale getirir.
InvalidInput, NotFound, RateLimited, TransientFailure gibi türlendirilmiş hatalar ve anlamlarıModele bu sözleşmeyi yapılandırılmış belge olarak sunun, uzun bir metin duvarı olarak değil. Ajan planlayıcısı hangi hataların yeniden denenebilir, hangilerinin kullanıcı müdahalesi gerektirdiğini ve hangilerinin iş akışını durduracağını bilmelidir.
request_id ekleyin.Bunlar, güvenliği yüksek tutarken kontrolsüz döngüler, yinelenen yan etkiler ve maliyet patlamalarının önüne geçer.
Kuyruk derinliği, işçi kullanım oranı ve 429/503 oranlarını izleyin; bunlar aşırı yük sinyalleridir.
Bu süreç, ajanları sürekli geliştirirken hataları izole, teşhis edilebilir ve geri alınabilir tutar.