Üretimde Çökmeyen Agentik Sistemler Tasarlamak

Etkileyici demoların ötesinde: kırılgan üretim ajanları

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.

Demo neden çalışır, üretim neden bozulur

Gerçek iş yükleri altında aynı ajan, demoda hiç görmediği biçimlerde zorlanır:

• API'ler zaman aşımına uğrar, kısmi veri döner veya sözleşmeleri değişir.
• Birden fazla istek paylaşılan kaynaklar için yarışır ve durumu bozabilir.
• Uzun süreli konuşmalar bellek şişirir ve bağlam sınırlarını aşar.
• İnce model hataları birçok araç çağrısı boyunca birikir ve büyü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.

Gerçek iş etkisi

Kırılgan ajanlar sadece “kullanıcı memnuniyetini” zedelemez. Onlar:

• Olayları ve on-call sayfalarını tetikler.
• Aşağı sistemlere yanlış cevaplar sızdırır.
• Kullanıcı güvenini aşındırır: insanlar özelliğe güvenmeyi sessizce bırakır.
• Yeniden denemeler ve kontrolsüz döngüler yüzünden bulut maliyetlerini şişirir.

Bu rehberin odak noktası

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.

Neden çoğu ajan mimarisi ölçekte bozulur

Ç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.

Kırılgan davranışlar: döngüler, tıkanmalar, kısmi işler, sessiz hatalar

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:

• Döngüler: ajan, tamamlanmayı veya hatayı hiç tanımadığı için aynı aracı yeniden planlamaya veya yeniden çağırmaya devam eder.
• Tıkanmalar: ajan, zaman aşımı olmayan bir araç veya alt görev bekler ve kullanıcı oturumlarını asılı bırakır.
• Kısmi işler: ajan iş akışının yarısını tamamlar (ör. bir e‑posta taslağı oluşturur ama asla göndermez; bir plan üretir ama adımları uygulamaz).
• Sessiz hatalar: araçlar başarısız olur veya şemalar uyuşmaz, ancak ajan eksik veya yanlış verilerle kendinden emin bir cevap döner.

Açık durumlar ve son koşullar olmadan bu davranışlar kaçınılmazdır.

Gizli deterministik olmayanlık ve araç güvenilmezliği

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:

• Yukarı akış API'lerinden ve veritabanlarından zaman aşımı ve kırılganlık
• Araç sözleşmeleri ile hizmetlerin gerçekte döndürdükleri arasında şema kayması
• Ajanın öğrenmediği tutarsız hata formatları

Bunların her biri anlamsız döngülere, yeniden denemelere veya yanlış nihai cevaplara dönüşür.

Eşzamanlılık uç vakaları ve ürün uyuşmazlığını güçlendirir

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:

• Paylaşılan durum veya önbellek üzerinde yarış koşulları
• Tükenmiş hız limitleri, kademeli araç hatalarına yol açar
• Tek bir bağımlılık arızasının tetiklediği yeniden deneme sürüleri (thundering herd)

Ü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 agentik sistemler için tasarım ilkeleri

Ü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.

Bir ajanı üretim için hazır yapan nedir?

Dört özellik en önemli olanlardır:

• Güvenlik: Ajan, veri erişimi, yan etkiler ve kullanıcı sözleri etrafındaki kısıtlamalara saygı göstermeli. Bu, açık izinler, araçlar üzerinde güvenlik bariyerleri ve güvensiz çıktının dikkatli işlenmesini gerektirir.
• Öngörülebilirlik: Aynı girdiler ve durum verildiğinde, ajan dar ve beklenen bir bant içinde davranmalı. Nelerin yapabileceğini ve yapamayacağını açıklayabilmelisiniz.
• Hata ayıklanabilirlik: Bir şey ters gittiğinde yolu izleyebilmelisiniz: hangi durum, hangi karar, hangi araç, hangi model çağrısı. Gizli döngüler ya da yapısız “düşünceler” olmamalı.
• Değişime tolerans: Modelleri, araçları veya stratejileri tüm sistemi yeniden yazmadan yükseltebilmelisiniz.

Bu özellikler yalnızca promptlardan gelmez. Bunlar yapıdan gelir.

Serbest biçimli döngüler yerine açık iş akışlarını tercih edin

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:

• Sonlu bir durum kümesi tanımlayın (ör. COLLECTING_INPUT, PLANNING, EXECUTING_STEP, WAITING_ON_HUMAN, DONE).
• Durumlar arasındaki izin verilen geçişleri tanımlayın.
• LLM'i esas olarak yerel kararlar için kullanın: bir sonraki durumu seçmek, bir araç seçmek veya parametreleri doldurmak.

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.

“Tanrı ajan”ı küçük becerilere bölün

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:

• Görevleri parçalayan bir planner.
• Somut adımları çalıştıran bir executor.
• Her alan için bir uzman (faturalama, destek, analiz vb.).

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.

Politika, durum ve araçları ayırın

Ajanı üç katmana bölmek faydalı bir zihinsel modeldir:

1. 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.

2. 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.

3. 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.

Küçüklük ve açıklık için tasarlayın

En güvenilir agentik sistemler en etkileyici demolar değil—beyaz tahtada davranışını açıklayabildiğiniz sistemlerdir.

Somut olarak:

• Her ajanı tek bir işe ve tek bir ana başarı metriğine odaklayın.
• İş akışını ve durum geçişlerini düzyazı yerine açık şekilde kodlayın.
• LLM'lerin tüm prosedürleri sıfırdan icat etmesine izin vermek yerine, iyi tanımlanmış seçenekler arasından seçim yapmalarına izin verin.

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.

Ajan iş akışlarını açık durum makineleri olarak modellemek

Ç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.

Ajan akışlarını durumlar ve geçişler olarak temsil etmek

Modelin ne yapacağını örtük olarak kararlaştırmasına izin vermek yerine küçük bir durum diyagramı tanımlayın:

• PLAN – kullanıcı isteğini yorumla, adımlara ayır, araçları seç.
• CALL_TOOL – doğrulanmış girdilerle tek bir araç çağrısı (veya toplu çağrı) yap.
• VERIFY – araç çıktısını basit invarianta'lara veya ek model kontrollerine karşı denetle.
• RECOVER – hataları ele al: yeniden dene, yedeğe geç veya yükselt.
• DONE – nihai cevabı döndür ve iş akışını kapat.
• FAILED – açık neden ve bağlamla terminal hata durumu.

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.

Dayanıklılık ve ölçek için durumu dışsallaştırmak

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:

• Dayanıklılık – bir işçi çalışmayı yarıda bırakırsa, başkası son kalıcı durumdan devam edebilir.
• Yatay ölçeklenebilirlik – durum bilgisi olmayan işçiler olayları tüketir, durumu günceller ve sonraki olayları üretir.
• Yeniden oynatma ve telafi – bir çalışmayı yeniden inşa edebilir, herhangi bir durumdan yeniden çalıştırabilir veya akış geri alınması gerektiğinde telafi edici işlemler çalıştırabilirsiniz.

Akıl yürütme ve denetimler için faydalar

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.

Ajanlar için güvenilir araç sözleşmeleri tasarlamak

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.

Sözleşmeyi, sadece promptu değil, tanımlayın

Her aracın bir sözleşmesi olmalı:

• Girdi şeması: gerekli alanlar, tipler, enumlar, kısıtlar, varsayılanlar
• Çıktı şeması: başarı yükü, boş olabilir alanlar ve "sonuç yok"un ne anlama geldiği
• Hata modeli: tipli hatalar (InvalidInput, NotFound, RateLimited, TransientFailure) ve açık semantik
• SLA'lar: gecikme beklentileri, kullanılabilirlik hedefleri ve hız limitleri

Bu 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.

Katı JSON, sıkı doğrulama

Araç I/O'sunu diğer üretim API'ları gibi ele alın:

• Girdi ve çıktı için katı JSON şemaları (OpenAPI, JSON Schema gibi) kullanın.
• Çağrıdan önce doğrulayın (model hatalarını yakalamak için) ve sonra doğrulayın (araç regresyonlarını yakalamak için).
• Küçük sorunları otomatik onarın (örn. tip dönüştürme) ama bunları izleyin ve sonraki ayarlamalar için loglayı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.

Versiyonlama ve uyumluluk

Araçlar gelişir; ajanlar her değişiklikte bozulmamalı.

• Araç sözleşmelerini versiyonlayın (v1, v1.1, v2) ve ajanları bir versiyona sabitleyin.
• Alanları kademeli olarak kullanımdan kaldırın; eski alanları bir süre okunabilir bırakın.
• Anlamsal değişiklikleri sessizce yapmaktan kaçının; geriye dönük uyumlu şekilde alan ekleyin.

Planlama mantığı daha sonra farklı olgunluk düzeylerindeki ajanlar ve araçları güvenle karıştırabilir.

Hata ve düşürülmüş modları ele alma

Sözleşmeleri kısmi başarısızlık göz önünde bulundurarak tasarlayın:

• Her öğe için hata detaylarıyla kısmi sonuçlara izin verin.
• Zor bir başarısızlık yerine bir düşürülmüş yanıt (ör. önbelleğe alınmış, yaklaşık veya eski veri) tanımlayın.
• Hangi alanların "elinden gelenin en iyisi" olduğunu, hangilerinin "zorunlu" olduğunu işaretleyin.

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.

Güvenlik ve yetkilendirme sınırları

Araç sözleşmeleri güvenlik limitlerini kodlamak için doğal bir yerdir:

• Aracın neyi okuyup değiştirebileceğini sınırlandırın.
• Hassas eylemler için açık parametreler gerektirin (örn. confirm: true).
• Kullanıcı kapsamlı işlemler ile sistem kapsamlı işlemleri ayırın.

Bunu sunucu tarafı kontrollerle birleştirin; modelin "davranacağına" yalnızca güvenmeyin.

Neden iyi sözleşmeler ajanları basitleştirir

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.

Yeniden denemeler, idempotentlik ve hata işleme desenleri

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: güvenli yeniden denemelerin temeli

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:

• İstek ID'leri: Her araç çağrısına stabil bir request_id ekleyin. Araç bu ID'yi gördüğünde aynı sonucu döndürür.
• Upsertler yerine insert: İş anahtarına göre anahtarlanan "oluştur veya güncelle" semantiği kullanın; auto-increment ID yerine doğal veya sentetik anahtar kullanın.
• Checksum ve versiyonlama: İçerik hashleri veya sürüm numaraları ekleyin ki araç kopyaları, eski yazmaları veya çakışan güncellemeleri tespit edebilsin.

Maliyeti patlatmayan yeniden deneme stratejileri

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.

Devre kesiciler ve yedekler

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.

Agentler için bellek, durum ve veri tutarlılığını yönetmek

Güvenilir ajanlar, durumun ne olduğu ve nerede durduğu hakkında net düşünceyle başlar.

Kısa vadeli durum vs uzun vadeli bellek

Bir isteği ele alan bir servisi nasıl düşünüyorsanız ajanı da öyle ele alın:

• Kısa vadeli durum: mevcut görevi veya alt görevi tamamlamak için gerekli olan her şey. Aktif hedef, mevcut adım, araç çıktıları, kısmi kararlar ve kontrol değişkenleri (kalan yeniden denemeler, seçilen dal vb.). Görev tamamlandığında atılabilir.
• Uzun vadeli bellek: oturumlar ve çalışmaları aşan bilgileri saklar: kullanıcı profilleri, tercihler, önceki kararlar, proje geçmişi ve öğrenilmiş kısayollar.

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.

Durum nerede saklanmalı

Üç ana seçenek var:

1. Bağlam içinde (sadece prompt) – Basit, düşük gecikme, ama sınırlı ve dayanıksız. Kısa vadeli durumlar için iyi.
2. Harici depo – Veritabanı, önbellek veya vektör deposu. Uzun vadeli bellek ve yeniden başlatmalar arasında kalıcılık için kullanın.
3. Hibrit – Yetkili durumu harici tutun; sadece bir sonraki adım için gerekenleri konteks'e yükleyin.

İ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.

"Günlükleri bellek olarak kullanma" anti-deseni

Yaygın bir hata, konuşma günlüklerini, izleri veya ham promptları fiili bellek olarak kullanmaktır.

Sorunlar:

• Erişim ad-hoc ve kırılgandır.
• Önemli gerçekler uzun metinlerin içinde gömülür.
• Birden fazla çalışma birbirine ters düşebilir ve hangi yazmanın son olduğu belirsizleşir.

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.

Paylaşılan veri ve araçlarla tutarlılık

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:

• Anahtar varlıklar için tek gerçek kaynak kullanın (sipariş, ticket, belge).
• Idempotent araç sözleşmelerini tercih edin: araçlar kararlı ID'ler ve "upsert" semantiği ile yeniden denemeleri güvenli hale getirsin.
• Ajanların aynı kaydı yarışabileceği durumlarda optimistik eşzamanlılık (sürüm numaraları, timestamp) uygulayın.

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.

Anlık görüntüler ve yeniden başlatılabilir yürütmeler

Çökme, dağıtım ve kota sınırlamalarıyla başa çıkmak için iş akışları yeniden başlatılabilir olmalı:

• Her anlamlı adımdan sonra bir durum anlık görüntüsü saklayın: mevcut adım, girdiler, araç sonuçları ve bekleyen eylemler.
• Durum makinenizdeki her geçiş anlık görüntüden yeniden oynatılabilir olsun.
• Hata veya yeniden başlatma durumunda en son anlık görüntüyü yükleyin ve sıfırdan başlamak yerine devam edin.

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.

Gizlilik, saklama ve minimal bellek

Bellek hem bir varlık hem de risk oluşturur. Üretim ajanları için:

• Hiç saklanmaması gerekenleri açıkça modelleyin (örn. gizli anahtarlar, ham belgeler, hassas KİŞİSEL BİLGİLER). Uygunsa redaksiyon veya hash kullanın.
• Bellek türü başına saklama politikaları tanımlayın (oturum düzeyi, 30 gün, hukuki koruma vb.).
• Kullanıcılara uzun vadeli belleğini görüntüleme ve silme kontrolleri verin.
• Tam promptları veya araç girdilerini saklamaktan kaçının; küçük, yapılandırılmış bir özet yeterliyse onu saklayın.

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.

Agent sistemlerinde eşzamanlılık, kota ve backpressure

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.

Ajan iş akışlarındaki eşzamanlılık tehlikeleri

Yaygın hata modları:

• Yarış koşulları: iki ajan yürütmesi aynı ticket, sepet veya belgeyi eşzamanlı günceller, birbirini üzerine yazar.
• Çift iş: yeniden denemeler veya yanlış yapılandırılmış işçiler aynı görevi iki kez işler (örn. bir ödemenin iki kez tahsil edilmesi).
• Sıra dışı etkiler: araç çağrıları beklenmedik bir sırada biter, eski bir sonuç yeni durumu bozar.

Bunları idempotent araç sözleşmeleri, açık iş akışı durumu ve veri katmanında optimistik veya pesimist kilitleme ile hafifletin.

Kuyruklar vs eşzamanlı akışlar

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:

• İşçi havuzlarıyla eşzamanlılığı kontrol etme
• Yeniden denemeleri ve deduplikasyonu merkezileştirme
• Yavaş veya kırılgan araçları kullanıcıya yönelik gecikmeden izole etme

Kota ve backpressure

Ajanlar tipik olarak üç kota sınıfına takılır:

• Modeller: dakika başına token, istek başına sınırlar, bağlam boyutu
• Araçlar: dahili hizmetlerin QPS veya CPU kısıtları
• Yukarı akış API'leri: 3. taraf kuotaları ve katı limitler

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:

• Kritik olmayan trafiği önce bırakmak
• Özellikleri düşürmek (daha küçük bağlamlar, daha az araç çağrısı)
• Kritik akışları tutarken düşük öncelikli kuyrukları duraklatmak

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.

Gözlemlenebilirlik: izleme, metrikler ve ajan davranışı için günlükleme

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.

Görmeniz gerekenler

Tasarımı öyle yapın ki tek bir görev şu öğeler boyunca bir ize sahip olsun:

• Her agent adımı ve durum geçişi
• Her araç çağrısı ve yanıtı
• Her model çağrısı ve prompt varyantı

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:

• Görev meta verisi: tenant, kullanıcı, kanal, öncelik
• Agent durumu: mevcut durum adı, sonraki durum, deneme sayısı
• Araç I/O: girdiler, çıktılar, gecikme, hatalar, devre kesici durumu
• Model çağrıları: prompt şablon ID, model adı, token sayıları, gecikme

Günlükleme ve redaksiyon

Promptları, araç girdilerini ve çıktıları yapılandırılmış biçimde loglayın ama önce bir redaksiyon katmanından geçirin:

• PII ve gizli bilgileri maskeleyin
• Aşırı büyük yükleri korelasyon için hash ile kırpın
• Alanları duyarlılık seviyeleriyle işaretleyin ki saklama ve erişim kontrolü uygulansın

Ham içerikleri alt ortamlarda özellik bayraklarıyla erişilebilir tutun; üretim varsayılan olarak redakte edilmiş görünüm sunmalı.

Gerçekten önemli metrikler

En azından şunları izleyin:

• Ajan ve kullanım senaryosu bazında görev başarı / hata oranı
• Görev başına ortalama ve P95 adım sayısı
• Gecikme: uçtan uca ve araç/model başına
• Başına maliyet (tokenlar, araç harcaması) ve başarılı sonuç başına maliyet

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.

Agentik sistemler için test ve değerlendirme stratejileri

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.

Birim testleri: prompt değil, araç sözleşmeleri

Testlere araç sınırından başlayın:

• Şemaları doğrulayın: gerekli alanlar, enumlar, aralıklar ve invarianta'lar.
• Idempotentlik ve hata semantiklerini kontrol edin (hangi hatalar, hangi kodlar, hangi yeniden deneme davranışı).
• Araçların bozuk girdileri nazikçe ele aldığını ve yapılandırılmış hatalar döndürdüğünü doğrulayı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: akışlar ve çok adımlı davranış

Entegrasyon testleri ajan iş akışını uçtan uca çalıştırır: LLM + araçlar + orkestrasyon.

Bunları senaryo tabanlı testler olarak modelleyin:

• Ana kullanıcı yolculukları için mutlu yollar (rezervasyon, iade, yükseltme vb.).
• Uç vakalar: eksik veri, kısmi araç hataları, zaman aşımı, kota sınırı.
• Araçlar arası etkileşimler: araç A'nın çıktısı araç B'ye nasıl besleniyor.

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.

LLM ve araçlar için deterministik fixtürler

Testleri tekrar üretilebilir tutmak için LLM yanıtlarını ve araç çıktıları fikstürleyin:

• LLM yanıtlarını bir kez kaydedin (prompt + model + konfigürasyon) ve JSON fixtürleri olarak saklayın.
• Araçların arkasındaki dış sistemleri mock'layın ki testler canlı servislere değmesin.
• Testlerde açık tohumlar ve sabit temperature konfigürasyonları kullanın.

Tipik desen:

with mocked_llm(fixtures_dir="fixtures/llm"), mocked_tools():
    result = run_agent_scenario(input_case)
    assert result.state == "COMPLETED"

Prompt ve şema regresyon dizinleri

Her prompt veya şema değişikliği mutlaka bir regresyon çalıştırmalı:

• Girdi kümesinden ve beklenen durum/araç izi veya sınıflandırmalardan oluşan küratörlü bir korpus tutun.
• Bunları golden dosyalar olarak kilitleyin; farklar davranış değişikliklerini ortaya çıkarır.
• Kritik akışlarda herhangi bir sürüklenmeyi açıkça onaylayın veya geri alın.

Ş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.

Yayına almadan önce çevrimdışı değerlendirme

Yeni bir modeli, politikayı veya yönlendirme stratejisini doğrudan üretime göndermeyin.

Bunun yerine:

• Regresyon korpusunuzu yeni konfigürasyonda çevrimdışı yeniden çalıştırın.
• Örneklenmiş geçmiş etkileşimler üzerinde replay testleri yapın.
• Otomatik metrikleri hesaplayın (görev başarısı, araç hata oranları, gecikme, maliyet) ve gerekirse örnek üzerinden insan değerlendirmesi yapın.

Çevrimdışı kapıları geçtikten sonra yeni varyantı feature flag ve kademeli dağıtım ile üretime alın.

Test veri yönetimi ve anonimizasyon

Ajan günlükleri sıklıkla hassas kullanıcı verisi içerir. Testler buna saygı göstermeli:

• Test veri setlerini anonimleştirilmiş veya sentetik girdilerden oluşturun.
• Tanımlayıcıları, serbest metin PII'yi ve gizli bilgileri saklamadan önce kırpın veya hash'leyin.
• Erişimi segmentleyin: mühendisler davranış izlerini görsün ama ham kullanıcı sırları görülmesin.

Bu kuralları CI boru hattınıza kodlayın ki hiçbir test artefaktı anonimleştirme kontrolleri olmadan üretilip saklanamasın.

Üretimde ajanları işletme, izleme ve geliştirme

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.

Güvenli dağıtım stratejileri

Yeni ajanları veya davranışları kademeli olarak tanıtın:

• Gölge modu: Ajanı mevcut sistemin yanında çalıştırın, kararlarını loglayın ama kullanıcıyı etkilemesine izin vermeyin. Çıktıları çevrimdışı karşılaştırın.
• Kanaryalar: Trafiğin küçük bir kısmını (örn. %1–5) yeni ajan versiyonuna yönlendirin. Hata oranları, gecikme ve kaliteyi izleyin.
• A/B testleri: Kullanıcıya dönük akışlarda, işletme KPI'larına göre yeni ve eski ajanı karşılaştırı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.

SLO'lar ve olay iş akışları

Hem sistem sağlığı hem kullanıcı değeri yansıtan SLO'lar tanımlayın:

• Güvenilirlik: görevlerin, araç çağrılarının ve uçtan uca iş akışlarının başarı oranı
• Gecikme: kritik yollar için p50/p95
• Kalite: otomatik değerlendirme skorları, insan değerlendirme dağılımları veya işe özgü başarı metrikleri

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ışı).

Sürekli iyileştirme ve değişim kontrolü

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.

Güvenilir agentik sistemler için referans mimari

Ü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.

Temel bileşenler

1. Gateway / API kenarı
İstemciler (uygulamalar, servisler, UI'lar) için tek giriş noktasıdır. Şunlarla ilgilenir:

• Kimlik doğrulama ve yetkilendirme (kullanıcı, servis, tenant)
• Oran sınırlamalar ve kotalar
• İstek şekillendirme (şemalar, boyut sınırları, temel doğrulama)

2. Orkestratör
Orkestratör “beyin sapı”, ama beyin değil. Şunları koordine eder:

• Planner: kullanıcı niyetini bir iş akışına veya durum makinesine çevirir
• Durum orkestratörü: bu iş akışını yürütür, durumu izler, yeniden denemeler ve zaman aşımı yönetir
• Politika motoru: güvenlik, uyumluluk, izin verilen araçlar, PII kuralları ve maliyet bütçelerini uygular

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:

• Dahili HTTP/gRPC servisleri
• Veritabanları, vektör/önbellek depoları
• Dış API'ler

Orkestratör araçları sıkı sözleşmelerle çağırır; depolama sistemleri gerçek veri kaynağı olarak kalır.

Entegrasyon, kontroller ve telemetri

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:

• Aşama aşama davranış için izler
• SLO ve kota için metrikler
• Güvenlik ve uyumluluk için denetim günlükleri
• Kullanıcı, proje ve araç bazında maliyet hesaplama

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.

Tüm parçaları birleştirmek ve takımınız için sonraki adımlar

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.

Temel desenler, tek bir resimde

Her ajanı bir durumlu iş akışı olarak düşünün:

• Bir durum makinesi yasal adımları (plan → topla → uygula → özetle vb.) ve bunlar arasındaki geçişleri tanımlar.
• Araç sözleşmeleri her eylemin neler yapabileceğini sınırlar; katı şemalar, zaman aşımı ve hata yüzeyleri içerir.
• Yeniden denemeler ve idempotentlik her dış etkileşimi korur ki yeniden oynatmalar güvenli olsun ve yan etkiler iki kez uygulanmasın.
• Gözlemlenebilirlik (izler, metrikler, loglar) her kararı ve araç çağrısını açıklanabilir ve hata ayıklanabilir kılar.

Bu parçalar hizalandığında, sistemler uç vakalar altında çökmek yerine kademeli olarak bozulur.

Agent üretime alınmadan önce hafif kontrol listesi

Bir prototip ajanı gerçek kullanıcılara göndermeden önce doğrulayın:

• İş akışı: Durumlar ve geçişler açık; gizli döngüler yok, sınırsız araç zincirleri yok.
• Sözleşmeler: Her aracın tiplenmiş girdi/çıktısı, net hata modları ve zaman aşımı var.
• Güvenlik: Girdi, çıktı ve eylemler üzerinde guardrail'lar (oran sınırlamalar, allowlist'ler, kotalar).
• Yeniden denemeler: Her araç için politikalar tanımlı; yan etki yapan çağrılar için idempotentlik anahtarları mevcut.
• Durum: Bellek ve kalıcı durum sınırlandırılmış, versiyonlanmış ve kurtarılabilir.
• Gözlemlenebilirlik: Her kullanıcı oturumu için tek bir izde “ne oldu?” sorusunu cevaplayabiliyorsunuz.
• Test: Senaryo tabanlı testler ve prompt/araç/politika regresyon dizileri var.

Herhangi bir madde eksikse, hâlâ prototip aşamasındasınız.

Takımlar nasıl sorumlulukları bölebilir

Sürdürülebilir bir kurulum genellikle şunu ayırır:

• Ürün ekipleri: Ajan davranışını, promptları, kendi alanlarına özgü araçları ve değerlendirme veri setlerini sahiplenir.
• Platform / infra ekipleri: Durum makinesi çerçevesini, ortak araç SDK'larını, günlükleme ve izleme altyapısını, politika uygulamasını ve ortak değerlendirme altyapısını sahiplenir.

Bu, ürün ekiplerinin hızlı hareket etmesini, platform ekiplerinin ise güvenilirlik, güvenlik ve maliyet kontrollerini zorunlu kılmasını sağlar.

Gelecek uzantılar ve güvenli yinelemeler

Temeller stabil olduktan sonra keşfedebileceğiniz alanlar:

• Öğrenme tabanlı politikalar: Yönlendirme, araç seçimi ve yedek stratejilerini logged izlerden iyileştirmek.
• Pekiştirmeli öğrenme: Tek bir yanıttan ziyade görev tamamlama veya gelir gibi uzun vadeli sonuçları optimize etmek.
• Kendi kendine ayarlanan iş akışları: Gözlemlenen performansa göre otomatik olarak temperature, araç veya alt akışları ayarlamak.

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.