Ajan İş Akışlarında Hata Yönetimi ve Geri Alma

Bir yapay zeka ajanı tek bir soruyu yanıtlamaz; bir hedefe ulaşmak için sırayla adımlar atar, araçlar çağırır ve ara sonuçlara göre karar verir. Bu güç aynı zamanda ana kırılganlıktır: adımlardan biri hata yaptığında, bu hata sonraki adımların girdisi olur ve sessizce büyür. Bir chatbot yanlış bir cümle kurduğunda kullanıcı bunu görür ve düzeltir; ama bir ajan yanlış bir eylem gerçekleştirdiğinde — yanlış kaydı güncellediğinde, yanlış e-postayı gönderdiğinde, yanlış tutarı tahsil ettiğinde — sonuç gerçek dünyada birikir ve her zaman geri alınamaz. Ajan hata yönetimi, tam olarak bu kırılganlığı yöneten mühendislik disiplinidir — ajanı hatasız yapmayı değil, hata yaptığında zarar vermeden durdurmayı hedefler.

Bu rehberde ajan hata yönetimi konusunu bir danışman titizliğiyle, üretim gerçeğiyle ele alıyoruz: çok adımlı bir görevde hata nasıl yayılır, her adımın çıktısı nasıl doğrulanır, tekrar deneme ne zaman güvenli ne zaman zararlıdır, hangi işlemler geri alınabilir hangileri alınamaz, bir geri alma mekanizması nasıl tasarlanır, kısmi başarısızlıkta durum nasıl tutarlı tutulur, kararın insana devir eşiği nasıl belirlenir ve tüm bunlar nasıl test edilir. Ajanların ne olduğuna dair temel için AI ajanı ile chatbot farkı yazısı iyi bir başlangıçtır.

Tanım

Ajan Hata Yönetimi

Çok adımlı görevleri otonom yürüten bir yapay zeka ajanının bir adımda hata yaptığında bu hatanın sonraki adımlara yayılmasını önleyen, hatayı erken yakalayan ve mümkünse otomatik toparlanan tasarım disiplini. Adım çıktısı doğrulama, kontrollü tekrar deneme, geri alınabilir ve geri alınamaz işlem ayrımı, geri alma mekanizması, kısmi başarısızlıkta tutarlı durum yönetimi ve risk eşiğinde insana devir bileşenlerini kapsar. Amaç ajanı hatasız yapmak değil, hata yaptığında zarar vermeden durdurmaktır.

Ayrıca: ajan güvenilirliği, agent error handling, ajan hata toleransı, ajan dayanıklılığı

Ajan hata yönetimi, çok adımlı görevleri yürüten bir yapay zeka ajanının hatalarını yakalayan, sınırlayan ve mümkün olduğunda otomatik toparlayan tasarım disiplinidir. Klasik yazılımda "hata yönetimi" denince try/catch blokları, yeniden deneme ve loglama akla gelir; ajanlarda ise sorun daha derindir, çünkü ajanın kendisi olasılıksaldır (aynı girdiye farklı yanıt verebilir), aldığı kararlar önceden bilinemez ve her adımı gerçek dünyada yan etkiler doğuran araç çağrılarına dönüşebilir.

Bu üç özellik ajan hata yönetimini klasik hata yönetiminden ayırır. Birincisi, hata her zaman bir "çökme" olarak gelmez; ajan pekâlâ akıcı ve kendinden emin biçimde yanlış bir ara sonuç üretebilir — bu sessiz hata, bir istisna fırlatmadığı için standart try/catch ile yakalanmaz. İkincisi, ajanın attığı adımlar birbirine zincirlenir; bir adımın çıktısı bir sonrakinin girdisi olduğundan, erken bir hata ilerledikçe büyür. Üçüncüsü, bazı adımlar geri alınamaz gerçek dünya eylemleridir (bir e-posta gitti mi geri gelmez), bu yüzden "hata olursa düzeltiriz" yaklaşımı her zaman geçerli değildir.

Dolayısıyla ajan hata yönetimi tek bir teknik değil, birbirini tamamlayan bir korkuluklar kümesidir: her adımın çıktısını doğrulamak, geçici hatalarda kontrollü tekrar deneme uygulamak, işlemleri geri alınabilir ve geri alınamaz diye ayırmak, geri alınabilir olanlar için bir geri alma mekanizması kurmak, kısmi başarısızlıkta sistemi tutarlı bir duruma çekmek ve belirli bir risk eşiğinin üstünde insana devretmek. Bu rehberin geri kalanı bu bileşenleri tek tek açar.

Ajan hata yönetiminin neden bu kadar kritik olduğunu anlamak için önce hatanın nasıl yayıldığını görmek gerekir. Tek adımlı bir sistemde (soru gir, cevap al) bir hata izole kalır: yanlış cevabı görür, atarsınız. Ama bir ajan on adımlı bir görevi yürütüyorsa, üçüncü adımdaki küçük bir hata, dördüncü adımın yanlış girdisi olur; dördüncü adım bu yanlış girdiyle "doğru" çalışır ama yanlış sonuç üretir; beşinci adım bunu daha da büyütür. Zincir ilerledikçe hata katlanır.

Bu birikimin matematiği acımasızdır. Diyelim ki her adım tek başına yüzde 95 güvenilir — kulağa iyi gelir. Ama on adımlı bir görevde tüm adımların art arda doğru gitme olasılığı 0,95 üzeri 10, yani kabaca yüzde 60'a düşer. Yani her adımı "yeterince iyi" olan bir ajan, uzun bir görevde çoğu zaman başarısız olur. Ajan hata yönetiminin var oluş nedeni tam budur: adım güvenilirliğini yükseltmek yeterli değildir, hatanın adımlar arasında yayılmasını da durdurmak gerekir.

Hata yayılmasının birkaç tipik biçimi vardır. Birincisi, hatalı ara çıktının doğru sanılmasıdır: ajan bir aramadan alakasız bir sonuç alır ama bunu doğru varsayarak devam eder. İkincisi, bileşik yan etkidir: ajan yanlış bir kayda yanlış bir güncelleme yapar, sonraki adım o kaydı okuyup ikinci bir yanlış eylem gerçekleştirir. Üçüncüsü, döngüsel takılmadır: ajan bir hatayı düzeltmeye çalışırken aynı yanlış adımı tekrar tekrar dener ve kaynak tüketir. Bu son biçim, sağlam bir tekrar deneme sınırı olmayan sistemlerde özellikle pahalıya patlar; maliyet boyutunu LLM maliyet düşürme yazısında ele alıyoruz.

Hata yayılmasını durdurmanın ilk ve en güçlü kaldıracı, her adımın çıktısını bir sonraki adıma geçmeden doğrulamaktır. Buradaki ilke basittir: bir adımın ürettiği sonuca, doğruluğu kanıtlanana kadar güvenme. Doğrulama, ajanın "güzel görünen ama yanlış" ara çıktılarını erken yakalayıp zincirin kirlenmesini engeller. Ajan hata yönetiminde doğrulama katmanı, kalitenin büyük kısmını taşıyan sessiz kahramandır.

Doğrulama birkaç düzeyde yapılır. En ucuz düzey yapısal doğrulamadır: çıktının beklenen biçimde olup olmadığını kontrol etmek — bir JSON şeması, bir tür kontrolü, zorunlu alanların varlığı, sayısal bir değerin beklenen aralıkta olması. Bir adım "tarih" döndürmesi gerekiyorsa ve geçersiz bir metin döndürdüyse, bunu bir sonraki adıma geçirmeden yakalarsınız. İkinci düzey mantıksal doğrulamadır: çıktının iş kurallarına uyup uymadığı — bir indirim oranının yüzde 100'ü aşmaması, bir stok sayısının negatif olmaması gibi. Üçüncü düzey anlamsal doğrulamadır: çıktının göreve gerçekten uygun olup olmadığı; bu en zor olandır ve çoğu zaman ikinci bir model çağrısıyla ("bu sonuç şu soruya cevap veriyor mu?") ya da bir dış gerçekle karşılaştırmayla yapılır.

Pratik bir teknik, ajandan yalnızca sonucu değil, o sonuca nasıl vardığını da istemektir; böylece doğrulama katmanı gerekçeyi de denetleyebilir. Bir başka güçlü teknik, kritik adımlarda çıktıyı bağımsız bir yolla teyit etmektir — örneğin ajan bir hesabı yaptıktan sonra, aynı hesabı deterministik bir kod parçasıyla yeniden yapıp iki sonucu karşılaştırmak. Doğrulama başarısız olduğunda ajan körlemesine devam etmemeli; ya adımı düzeltilmiş bir talimatla tekrar denemeli ya da eşik aşılmışsa insana devretmelidir. Doğrulama disiplininin insan tarafındaki karşılığını insan ai iş birliği yazısında ele alıyoruz.

Bir adım başarısız olduğunda ilk refleks tekrar denemektir — ama körlemesine tekrar deneme, ajan hata yönetiminin en sık kötüye kullanılan aracıdır. Doğru tekrar deneme stratejisi, önce hatanın türünü ayırt etmekle başlar. Hatalar iki temel sınıfa ayrılır: geçici (transient) hatalar ve kalıcı (permanent) hatalar. Geçici hatalar kendiliğinden düzelebilir: ağ kesintisi, zaman aşımı, geçici hız sınırı, anlık servis dalgalanması. Kalıcı hatalar tekrarla düzelmez: yanlış girdi, yetki reddi, bulunamayan kaynak, mantık hatası. Tekrar deneme yalnızca geçici hatalar için anlamlıdır; kalıcı bir hatayı tekrar denemek yalnızca gecikme ve maliyet ekler.

İkinci ayrım idempotentliktir. Bir işlem idempotentse, aynı çağrıyı iki kez yapmak tek kez yapmakla aynı sonucu verir (bir kaydı okumak, bir değeri "X yap" diye ayarlamak). İdempotent değilse, tekrar her seferinde yeni bir yan etki üretir (bir ödeme almak, bir e-posta göndermek, bir sayacı artırmak). En tehlikeli senaryo şudur: yan etkili ve idempotent olmayan bir işlem çağrılır, işlem aslında başarılı olur ama yanıt ağda kaybolur; ajan bunu "başarısız" sanıp tekrar dener ve işlemi ikinci kez gerçekleştirir. Bu yüzden yan etkili işlemlerde tekrar deneme, mutlaka bir idempotency anahtarı ile korunmalıdır — sağlayıcı aynı anahtarı gördüğünde işlemi tekrarlamaz.

Doğru tekrar deneme stratejisinin bileşenleri şunlardır:

Nasıl Yapılır

Güvenli bir tekrar deneme stratejisi kurmak

Bir ajan adımı başarısız olduğunda hasarı büyütmeden toparlanmak için izlenecek adımlar.

1. 1

   Hatayı sınıflandır

   Hatanın geçici mi kalıcı mı olduğunu belirle; yalnızca geçici hatalar tekrar denemeye adaydır, kalıcı hatalar doğrudan başka yola gider.

2. 2

   İdempotentliği kontrol et

   İşlem yan etkiliyse ve idempotent değilse, tekrar denemeden önce bir idempotency anahtarı kullan ki işlem ikinci kez gerçekleşmesin.

3. 3

   Üstel geri çekilme uygula

   Her denemede bekleme süresini artır (exponential backoff) ve rastgele bir sapma ekle; böylece servisi daha da boğmazsın.

4. 4

   Bir üst sınır koy

   Tekrar sayısını sınırla (örneğin en fazla üç); sınıra ulaşınca körlemesine devam etme, bir sonraki adıma geç.

5. 5

   Devre kesiciye bağla

   Bir bağımlılık sürekli başarısızsa devre kesici (circuit breaker) ile o yolu geçici olarak kapat ve insana devir ya da yedek yola yönel.

Bu stratejinin kalbinde bir denge vardır: yeterince tekrar denemek (geçici hataları aşmak için) ama fazla değil (kalıcı hatada kaynak yakmamak için). Üstel geri çekilme, tekrarlar arasındaki süreyi kademeli artırarak hem geçici sorunun düzelmesine zaman tanır hem de bombardımanı önler. Bir tekrar üst sınırı ve devre kesici ise, sistemin sonsuz döngüye girmesini engeller. Sağlam bir tekrar deneme mekanizması olmayan ajanlar, bir bağımlılık çöktüğünde onu tekrar tekrar deneyerek hem maliyeti hem gecikmeyi patlatır.

Ajan hata yönetiminin belki de en belirleyici kavramı, her işlemin geri alınabilir mi yoksa geri alınamaz mı olduğunu baştan bilmektir. Bir ajanın attığı her adım gerçek dünyada bir iz bırakır; bu izin silinip silinemeyeceği, hata durumunda ne yapabileceğinizi tümüyle belirler. Bu ayrımı yapmadan bir ajanı otonom bırakmak, geri vitesi olmayan bir arabayı uçurumun kenarında park etmek gibidir.

İşlemler üç sınıfa ayrılır. Birincisi doğal geri alınabilir işlemlerdir: eski hâli saklandığı sürece tek bir ters işlemle geri alınır — bir taslak oluşturmak, bir dosyaya yazmak (önceki sürüm duruyorsa), bir veritabanı kaydını güncellemek (eski değer loglanmışsa). İkincisi telafiyle geri alınabilir işlemlerdir: doğrudan "geri alınmaz" ama ayrı, dengeleyici bir işlemle etkisi nötrlenir — bir sipariş oluşturmak (iptal işlemiyle), bir rezervasyon yapmak (iptalle), bir para transferini başlatmak (ters transferle). Üçüncüsü geri alınamaz işlemlerdir: bir kez yapıldığında geri dönüşü yoktur — bir e-posta veya bildirim göndermek, bir ödemeyi kesinleştirmek, bir kaydı kalıcı silmek, dış bir sisteme kesin bir komut vermek.

Bu sınıflandırma doğrudan davranışı belirler. Doğal geri alınabilir işlemler ajana rahatça bırakılabilir; hata olursa geri alma mekanizması temizler. Telafiyle geri alınabilir işlemler için önceden bir telafi işlemi tanımlanmalı ve kısmi başarısızlıkta çalıştırılmalıdır. Geri alınamaz işlemler ise otonom bırakılmamalı; yürütülmeden önce ya bir insanın onayına ya da yüksek güvenli bir doğrulama kapısına bağlanmalıdır. Kritik bir tasarım kuralı, geri alınamaz işlemleri mümkün olduğunca görevin sonuna bırakmaktır — böylece bir sorun çıkarsa, henüz geri dönülemez adıma gelinmeden durulabilir ve önceki tüm geri alınabilir adımlar temizlenebilir.

İşlem sınıfı × hata davranışı × geri alma yaklaşımı

İşlem sınıfı	Örnek	Hata olunca davranış	Geri alma yaklaşımı
Salt-okunur sorgu	Kayıt okuma, arama	Güvenle tekrar dene	Gerekmez (yan etki yok)
İdempotent yazma	'Durumu X yap' güncellemesi	Tekrar dene (aynı sonuç)	Eski değere geri yaz
Doğal geri alınabilir	Taslak, dosya yazma	Tekrar dene veya geri al	Önceki sürüme dön
Telafiyle geri alınabilir	Sipariş, rezervasyon	Telafi işlemini çalıştır	Dengeleyici iptal işlemi
Geri alınamaz	E-posta, ödeme, kalıcı silme	Önce onay/insana devir	Yok — önlem tek çare

Bu tablo, ajan hata yönetiminin en pratik karar aracıdır. Bir ajanı üretime almadan önce, kullandığı her aracı bu tabloya yerleştirmek gerekir; çünkü bir işlemin hangi sınıfa düştüğü, onun otonom bırakılıp bırakılamayacağını, tekrar denenip denenemeyeceğini ve hata durumunda ne yapılacağını doğrudan belirler. Risk boyutunu daha geniş bir çerçevede değerlendirmek için AI risk değerlendirmesi yazısına bakabilirsiniz.

Geri alınabilir işlemler için bir geri alma mekanizması kurmak, ajan hata yönetiminin toparlanma kaslarıdır. İyi bir geri alma mekanizması olmadan, bir görev yarıda kaldığında sistem tutarsız bir enkaza döner. Geri alma tasarımının temel prensibi şudur: değişiklik yapmadan önce, o değişikliği nasıl geri alacağını bil ve gerekli bilgiyi sakla. Bir kaydı güncellemeden önce eski değerini, bir dosyayı değiştirmeden önce önceki sürümünü, bir sipariş oluşturmadan önce onu iptal etmek için gereken kimliği kaydet.

İki temel geri alma yaklaşımı vardır. Birincisi durum anlık görüntüsü (snapshot / checkpoint): görevin belirli noktalarında sistemin durumunu kaydedip, hata olduğunda o noktaya geri dönmek. Bu, izole ve durumun bir bütün olarak yedeklenebildiği senaryolarda temizdir. İkincisi telafi işlemleri (compensation): her ileri işlem için, onun etkisini nötrleyen bir ters işlem tanımlamak ve hata olduğunda yapılan işlemleri tersten telafi etmek. Bu, dağıtık ve birden çok dış sistemin dahil olduğu senaryolarda daha uygulanabilirdir, çünkü çoğu dış sistem "tümünü geri sar" demeyi desteklemez ama "şu siparişi iptal et" demeyi destekler.

Telafi tabanlı geri almayı koordine eden klasik desen saga desenidir. Saga, uzun bir işlemi bir dizi küçük adıma böler; her adımın bir de telafi işlemi vardır. Görev ilerlerken adımlar sırayla çalışır; bir adım başarısız olduğunda, o ana kadar başarıyla çalışmış tüm adımların telafileri tersten çalıştırılır ve sistem tutarlı bir başlangıç durumuna çekilir. Ajan iş akışlarında saga deseni, kısmi başarısızlığı yönetmenin en olgun yoludur. Kritik nokta şudur: telafi işlemlerinin kendileri de başarısız olabilir, bu yüzden onlar da idempotent olmalı ve tekrar denenebilir tasarlanmalıdır.

Kısmi başarısızlık, çok adımlı bir görevin bir kısmının başarılı olup bir kısmının başarısız olması durumudur ve ajan hata yönetiminin en zorlu sınavıdır. Tehlike şudur: sistem ne "tümüyle yapıldı" ne "hiç yapılmadı" durumundadır; arada, tutarsız bir ara durumda kalmıştır. Örneğin ajan bir müşteri kaydını güncelledi, ilgili faturayı oluşturdu ama bildirim gönderme adımında başarısız oldu — şimdi sistem yarım bir durumdadır ve düzeltilmezse ilerideki her işlem bu tutarsızlık üzerine kurulur.

Kısmi başarısızlığı yönetmenin özü, atomiklik ilkesini olabildiğince taklit etmektir: görev ya bütünüyle tamamlanmalı ya da hiç yapılmamış gibi geri sarılmalıdır. Tam atomiklik dağıtık sistemlerde çoğu zaman mümkün değildir, ama saga deseni ve telafi işlemleriyle ona yaklaşılır. Bir adım başarısız olduğunda, o ana kadar yapılmış geri alınabilir adımlar geri alınır, telafiyle geri alınabilir adımlar için telafiler çalıştırılır ve sistem tutarlı bir noktaya çekilir. Bu, kısmi başarısızlığı bir felaketten yönetilebilir bir olaya dönüştürür.

Bunun ön koşulu, görevin durumunu kalıcı bir yerde tutmaktır. Ajan yalnızca bellekte çalışıyorsa ve süreç yarıda çökerse, hangi adımların yapıldığını bilemez ve ne temizleyebilir ne devam edebilir. Bu yüzden olgun ajan sistemleri, her adımın sonucunu ve görevin genel durumunu dayanıklı bir depoda (bir durum makinesi veya iş akışı motoru) tutar. Böylece bir kesinti sonrası ajan, "en son hangi tutarlı noktadaydım" diye bakıp oradan devam edebilir veya güvenle geri sarabilir. Bu altyapının nerede çalışacağı — bulutta mı, kendi sunucunuzda mı — ayrı bir karardır; on-premise yapay zeka yazısında bu boyutu ele alıyoruz.

Kısmi başarısızlıkta üç durum ve doğru müdahale

Durum	Belirti	Doğru müdahale
Geri alınabilir adımlar yapıldı, sonrası başarısız	Sistem yarım güncellenmiş	Yapılan adımları geri al, tutarlı başlangıca dön
Telafiyle geri alınabilir adım yapıldı	Sipariş/rezervasyon açık kaldı	Önceden tanımlı telafi işlemini çalıştır
Geri alınamaz adıma gelmeden durdu	Kritik eylem henüz yapılmadı	Güvenli — sadece öncekileri temizle

Kısmi başarısızlık yönetiminin altın kuralı, geri alınamaz adımı görevin en sonuna, tüm doğrulama ve geri alınabilir işlemler tamamlandıktan sonraya koymaktır. Böylece hata büyük olasılıkla o kritik adımdan önce yakalanır ve sistem güvenli biçimde geri sarılabilir. Geri alınamaz adımı erkene koymak, kısmi başarısızlığı yönetilemez kılan en yaygın tasarım hatasıdır.

Hiçbir ajan hata yönetimi, ajanı yüzde yüz otonom yapacak kadar güçlü değildir — ve olması da gerekmez. Olgun sistemlerin ayırt edici özelliği, ne zaman durup insana devredeceğini bilmesidir. İnsana devir (human handoff / human-in-the-loop), bir zayıflık değil, bir güvenlik özelliğidir; ajanın kendi sınırını tanıması ve riski bir insana taşımasıdır. Buradaki asıl mühendislik sorusu, "insana devredilsin mi" değil, "hangi eşikte devredilsin"dir.

İnsana devir eşiği üç sinyalle tetiklenmelidir. Birincisi risk sinyalidir: işlem geri alınamaz ve etkisi büyükse (para transferi, toplu veri silme, dış iletişim, sözleşmesel bir taahhüt), ajan otonom davranmamalı, önce onay istemelidir. Burada eşik, işlemin sınıfına ve büyüklüğüne bağlanır — küçük ve geri alınabilir işlemler otonom, büyük ve geri alınamaz olanlar onaylı. İkincisi belirsizlik sinyalidir: ajanın kendi güven skoru düşükse, adım çıktısı doğrulamayı geçemiyorsa veya çelişkili bilgiyle karşılaşıyorsa devretmelidir. Üçüncüsü tekrar sinyalidir: aynı adım birkaç tekrar denemeye rağmen başarısız oluyorsa, körlemesine devam etmek yerine durup insana bırakmalıdır.

İyi bir insana devir tasarımı, devri bir "çıkmaz sokak" değil, bir "iş birliği anı" yapar. Ajan devrederken, insana bağlamı eksiksiz sunmalıdır: ne yapmaya çalıştığını, hangi adıma kadar geldiğini, neden durduğunu ve önerdiği eylemi. Böylece insan sıfırdan başlamaz, ajanın hazırladığı zemin üzerinden hızlı karar verir. Devir sonrası insan onay verirse ajan kaldığı yerden devam eder; reddederse ajan yaptığı geri alınabilir adımları temizler. Bu insan-ajan iş bölümünün nasıl bir çalışma biçimine dönüştüğünü insan ai iş birliği yazısında derinleştiriyoruz.

Şimdiye kadarki bileşenler hatayı yakalamak ve toparlanmakla ilgiliydi; güvenli işlem tasarımı ise bir adım öncesine gider ve sorar: ajan yanlış bir şey yapmaya karar verirse, verebileceği en büyük zarar nedir ve bunu nasıl sınırlarız? Güvenli işlem, ajan hata yönetiminin önleyici katmanıdır — hatayı toparlamak yerine, hatanın etkisini baştan küçültür. Bir ajan ne kadar iyi tasarlanırsa tasarlansın, bir gün yanlış bir eylem seçecektir; güvenli işlem tasarımı o günü zararsız kılar.

En temel ilke en az yetkidir (least privilege): ajana yalnızca görevini yapması için gereken minimum erişimi vermek. Tüm veritabanına yazma yetkisi olan bir ajan, bir hata yaptığında tüm veritabanını bozabilir; yalnızca ilgili tabloya, yalnızca gereken işlemler için yetkili bir ajan ise en kötü ihtimalle sınırlı bir hasar verir. Aynı ilke araç erişimine de uygulanır: ajanın çağırabileceği araçlar, gerçekten ihtiyaç duyduklarıyla sınırlanır. İkinci ilke kuru çalıştırmadır (dry-run): ajan bir eylemi gerçekten yürütmeden önce, "şunu yapacağım" diye ne yapacağını önizlemesi ve bunun doğrulanması. Özellikle geri alınamaz ve toplu işlemlerde kuru çalıştırma, felaketleri önler.

Diğer güvenli işlem korkulukları arasında şunlar öne çıkar: idempotency anahtarları (yan etkili işlemlerin yanlışlıkla iki kez yürütülmesini önler), zaman aşımları (bir adım takılırsa sonsuza kadar beklemeyi keser), oran ve hacim sınırları (ajanın kısa sürede çok sayıda işlem yaparak hasarı ölçeklemesini engeller), ve onay kapıları (belirli eşiğin üstündeki işlemleri insana bağlar). Bu korkulukların toplamı, ajanı bir "her şeyi yapabilen" varlıktan, "sınırları belli, gözetimli bir çalışan" durumuna getirir. Güvenli işlem tasarımı, ajanın gücünü kısıtlamak değil, o gücü güvenli bir zarfın içine koymaktır.

Bir ajan hata yönetimi tasarımı, ancak test edildiği kadar gerçektir. Çoğu ajan sistemi mutlu yolda (her şey yolunda gittiğinde) iyi çalışır; asıl soru, kötü günde nasıl davrandığıdır. Test edilmemiş bir hata yönetimi, ilk gerçek kriz anında çöker — çünkü kriz anı, kodun ilk kez çalıştığı an olur. Bu yüzden ajan güvenilirliğinin doğrulanması, mutlu yolu değil, hata yollarını sınamayı gerektirir.

Birinci yöntem hata enjeksiyonudur (fault injection). Araç çağrılarına ve dış bağımlılıklara bilerek arızalar enjekte edersiniz: zaman aşımı, hız sınırı, bozuk/eksik yanıt, çelişkili veri ve en önemlisi "yarım başarı" (işlem yapıldı ama yanıt kayboldu). Sonra ajanın bunları doğru sınıflandırıp sınıflandırmadığını ölçersiniz — geçici hatayı tekrar deniyor mu, kalıcı hatayı devrediyor mu, idempotent olmayan işlemi ikinci kez yürütmekten kaçınıyor mu? Hata enjeksiyonu, gerçek dünyada nadiren ve öngörülemez biçimde çıkan kenar durumları, kontrollü ve tekrarlanabilir biçimde önünüze getirir.

İkinci yöntem tekrarlanabilir senaryolardır. Ajanlar olasılıksal olduğu için aynı görev her çalıştırmada biraz farklı ilerleyebilir; bu non-determinizm, testleri zorlaştırır. Çözüm, sabit tohum (seed) ve kaydedilmiş araç yanıtlarıyla senaryoları tekrarlanabilir kılmaktır — böylece bir hatayı gördüğünüzde onu aynı biçimde yeniden üretip düzeltebilirsiniz. Üçüncü yöntem geri alma provalarıdır: her geri alınabilir işlemin geri alma yolunu düzenli olarak çalıştırıp gerçekten çalıştığını doğrulamak. Bu üç yöntem, "kısmi başarısızlık", "güvenli işlem" ve "geri alma mekanizması" iddialarını laftan çıkarıp kanıta dönüştürür.

Nasıl Yapılır

Ajan hata yönetimini test etme rutini

Bir ajan iş akışının kötü günde de güvenilir davrandığını doğrulamak için düzenli çalıştırılacak test adımları.

1. 1

   Hata kataloğu çıkar

   Ajanın karşılaşabileceği tüm hata türlerini listele: zaman aşımı, hız sınırı, bozuk yanıt, yetki hatası, yarım başarı, çelişkili veri.

2. 2

   Her araca hata enjekte et

   Araç çağrılarına kontrollü olarak bu hataları enjekte edip ajanın tepkisini gözle; doğru sınıflandırma ve doğru toparlanmayı doğrula.

3. 3

   Yarım başarıyı özellikle sına

   İşlem yapıldı ama yanıt kayboldu senaryosunu kur; ajanın idempotency anahtarıyla ikinci yürütmeyi engellediğini doğrula.

4. 4

   Geri alma provası yap

   Her geri alınabilir ve telafiyle geri alınabilir işlemin geri alma/telafi yolunu çalıştır; tutarlı duruma dönüldüğünü ölç.

5. 5

   İnsana devir eşiğini doğrula

   Risk, belirsizlik ve tekrar sinyallerini tetikleyen senaryolar kur; eşik aşıldığında ajanın gerçekten durup devrettiğini kontrol et.

Bu test rutini bir kez değil, düzenli çalıştırılmalı ve her önemli değişiklikte (yeni araç, yeni adım, model güncellemesi) tekrarlanmalıdır — tıpkı bir regresyon test paketi gibi. Ajan sistemleri kırılgan biçimde birbirine bağlıdır; bir yerdeki değişiklik başka bir yerde sessiz bir hata doğurabilir. Düzenli test, bu sessiz bozulmaları üretim krizine dönüşmeden yakalar.

Ajan hata yönetimi, yalnızca hataları yakalamak ve toparlanmakla bitmez; hataları görebilmek de gerekir. Bir ajanın onlarca adımlık bir görevi nasıl yürüttüğünü, nerede takıldığını ve neden yanlış karar verdiğini göremiyorsanız, ne hatayı teşhis edebilir ne de sistemi iyileştirebilirsiniz. Gözlemlenebilirlik (observability), üretimdeki bir ajanın "kara kutu" olmaktan çıkıp "cam kutu" olmasını sağlayan katmandır ve olgun ajan sistemlerinin vazgeçilmez parçasıdır.

İyi bir ajan gözlemlenebilirliği birkaç şeyi kaydeder. İzler (traces): her görevin adım adım tam dökümü — hangi araç çağrıldı, hangi girdiyle, ne döndü, doğrulama geçti mi, tekrar denendi mi. Bu iz, bir hata sonrası "ne oldu" sorusunu cevaplayan tek kaynaktır. Kararlar (decision logs): ajanın neden o adımı seçtiği, gerekçesiyle birlikte; sessiz hataları teşhis etmenin tek yolu genellikle budur. Ölçütler (metrics): görev başarı oranı, adım başına hata oranı, ortalama tekrar sayısı, insana devir sıklığı, ortalama tamamlanma süresi ve maliyet. Bu ölçütler, sistemin zaman içinde iyileşip iyileşmediğini gösterir.

Bu izleme yalnızca teşhis için değil, sürekli iyileştirme için de gereklidir. Üretimdeki gerçek hatalar, en iyi test senaryosu kaynağıdır: bir hata görüldüğünde, onu bir teste dönüştürüp hata kataloğuna eklersiniz; böylece aynı hata bir daha sessizce geçmez. Ayrıca insana devir kayıtları, ajanın hangi durumlarda takıldığını gösterir ve bu durumlar, ajanı geliştirmek için bir yol haritası sunar. Gözlemlenebilirlik olmadan ajan hata yönetimi kördür; hataları toparlarsınız ama neden olduklarını hiç öğrenemezsiniz. Bu operasyon disiplini, kurumsal ölçekte bir ekip yetkinliği gerektirir; ekiplerin bunu kazanması için kurumsal eğitim seçeneklerini değerlendirebilirsiniz.

Deneyimli bir yazılımcı, "hata yönetimini zaten biliyorum, try/catch yazarım" diye düşünebilir. Ama ajan hata yönetimi, klasik yazılım hata yönetiminden birkaç temel noktada ayrılır ve bu farkları görmezden gelmek, en tecrübeli ekibi bile şaşırtır. Fark, ajanın doğasından gelir: olasılıksaldır, kararları önceden bilinemez ve dış dünyada yan etki üretir. Bu üç özellik, klasik hata yönetiminin varsayımlarını kırar.

Birinci fark, hatanın biçimidir. Klasik yazılımda hata çoğunlukla bir istisna (exception) olarak gelir: bir kod bloğu çöker, bir hata kodu döner ve siz onu yakalarsınız. Ajanda ise hata sıklıkla sessizdir: ajan hiç çökmez, akıcı ve kendinden emin biçimde yanlış bir şey üretir. Bu sessiz hata, hiçbir istisna fırlatmadığı için standart try/catch ile yakalanamaz. Klasik hata yönetimi "çöktü mü" sorusuna odaklanır; ajan hata yönetimi ise "doğru mu" sorusuna odaklanmak zorundadır — ve bu çok daha zordur. İkinci fark, belirlenimciliktir (determinizm). Klasik bir fonksiyon aynı girdiye her zaman aynı yanıtı verir; bir hatayı yeniden üretmek ve düzeltmek kolaydır. Ajan ise aynı girdiye farklı yanıtlar verebilir; bu non-determinizm, hataları yeniden üretilebilir kılmayı ve test etmeyi zorlaştırır.

Üçüncü fark, yan etkinin geri alınabilirliğidir. Klasik yazılımda çoğu işlem bir veritabanı işlemidir (transaction) ve bir hata olduğunda tümü geri sarılabilir — atomiklik doğal olarak sağlanır. Ajan ise çoğu zaman birbirinden bağımsız dış sistemlere birden çok yan etkili çağrı yapar; bunları tek bir işlem gibi geri sarmak mümkün değildir. Bu yüzden ajan hata yönetimi, klasik atomikliğin yerine saga deseni ve telafi işlemleri gibi daha zahmetli mekanizmalara başvurmak zorundadır. Dördüncü fark, kararın kendisidir: klasik yazılımda akış önceden sabittir, ajanda ise akışın kendisini ajan çalışırken belirler — yani hata, yalnızca bir adımın uygulanışında değil, hangi adımın seçildiğinde de olabilir.

Klasik yazılım hata yönetimi ile ajan hata yönetimi

Boyut	Klasik yazılım	Ajan sistemi
Hatanın biçimi	İstisna / hata kodu (gürültülü)	Sessiz yanlış çıktı da olabilir
Belirlenimcilik	Aynı girdi = aynı sonuç	Aynı girdi farklı sonuç verebilir
Geri alma	Transaction ile doğal atomiklik	Saga + telafi ile taklit edilir
Akış	Önceden sabit	Ajan çalışırken belirlenir

Bu farklar, ajan hata yönetimini klasik yazılımın basit bir uzantısı değil, kendine özgü kuralları olan yeni bir disiplin yapar. Klasik hata yönetimi bilgisi değerlidir ve temeldir; ama tek başına yetmez. Ajanların bu yeni davranış biçimini ve chatbot'lardan farkını AI ajanı ile chatbot farkı yazısında ele alıyoruz; doğrulama refleksini bir çalışma alışkanlığına dönüştürmenin yolunu ise insan ai iş birliği yazısında bulabilirsiniz.

Ajan hata yönetiminin belki de en teknik ama en belirleyici kavramı idempotentliktir; çünkü tekrar deneme, kısmi başarısızlık ve güvenli işlem tasarımının hepsi bu kavramın üzerine kuruludur. İdempotent bir işlem, kaç kez çağrılırsa çağrılsın tek bir kez çağrılmışçasına sonuç üretir. "Bu kaydın durumunu tamamlandı yap" komutu idempotenttir — on kez çalıştırsanız da sonuç aynıdır. "Bu sayacı bir artır" komutu ise idempotent değildir — her çağrı yeni bir yan etki üretir. Bu ayrım, bir işlemin güvenle tekrar denenip denenemeyeceğini doğrudan belirler.

Sorun şudur: dağıtık sistemlerde bir çağrının gerçekten başarılı olup olmadığını her zaman bilemezsiniz. Ajan bir ödeme çağrısı yapar, ödeme sağlayıcısı işlemi gerçekleştirir ama yanıt ağda kaybolur; ajanın gördüğü tek şey bir zaman aşımıdır. Şimdi ajan bilemez: ödeme yapıldı mı, yapılmadı mı? Naif bir tekrar deneme, ödemeyi ikinci kez alma riskini taşır. İşte bu noktada tam-bir-kez yürütme (exactly-once execution) garantisi devreye girer. Pratikte gerçek "tam-bir-kez" ağ üzerinde imkânsıza yakındır; onun yerine "en-az-bir-kez teslim + idempotent işleme" birleşimiyle aynı etki elde edilir: mesaj birden çok kez gelebilir, ama idempotent işleme sayesinde etki yalnızca bir kez oluşur.

Bunu sağlayan temel araç idempotency anahtarıdır. Ajan yan etkili bir işlem başlatırken, o işleme benzersiz bir anahtar atar ve çağrıya ekler. Sağlayıcı bu anahtarı kaydeder; aynı anahtarla ikinci bir çağrı geldiğinde, işlemi tekrar yapmak yerine ilk sonucun kaydını döndürür. Böylece ajan güvenle tekrar deneyebilir: en kötü ihtimalle çağrı tekrarlanır ama işlem tek bir kez gerçekleşir. Bu, güvenli işlem tasarımının belkemiğidir ve yan etkili adımlarda tekrar denemeyi tehlikeli olmaktan çıkarıp güvenli kılan tek mekanizmadır. İdempotency anahtarı olmayan bir sistemde, yan etkili bir işlemi tekrar denemek her zaman bir kumar olarak kalır.

Tüm bu bileşenleri somutlaştırmanın en iyi yolu, tek bir görevin hata dolu bir yolculuğunu adım adım izlemektir. Diyelim ki bir ajana şu görev veriliyor: "Şu müşterinin aboneliğini bir üst pakete yükselt, farkı tahsil et ve müşteriye bilgilendirme e-postası gönder." Bu görev üç adımlıdır ve her adım farklı bir işlem sınıfına düşer — bu yüzden ajan hata yönetiminin tüm kaslarını çalıştırır.

Ajan işe müşteri kaydını okuyarak ve mevcut paketi doğrulayarak başlar (salt-okunur, güvenli). Sonra aboneliği üst pakete yükseltir; bu telafiyle geri alınabilir bir işlemdir, çünkü gerekirse eski pakete döndürülebilir. Ajan bu adımdan önce eski paket bilgisini kaydeder — geri alma mekanizmasının ön hazırlığı. Yükseltme başarılı olur ve doğrulanır. Şimdi en riskli adım gelir: farkı tahsil etmek. Bu yan etkili, idempotent olmayan bir işlemdir, bu yüzden ajan bir idempotency anahtarıyla çağrıyı korur. İlk çağrıda ödeme sağlayıcısı zaman aşımına düşer — yanıt gelmez.

İşte kritik an. Naif bir ajan burada "başarısız oldu" deyip tekrar dener ve müşteriden iki kez tahsilat yapabilir. Ama iyi tasarlanmış ajan, önce idempotency anahtarıyla işlemin durumunu sorgular: "Bu anahtarla bir tahsilat gerçekleşti mi?" Sağlayıcı "evet, ilk çağrı aslında başarılıydı, yalnızca yanıt kayboldu" der. Ajan böylece ikinci bir tahsilattan kaçınır ve tek bir ödeme kaydeder. Bu, güvenli işlem tasarımının somut değeridir: yarım başarı, felakete dönüşmeden yönetilir.

Son adımda ajan bilgilendirme e-postası göndermeye çalışır — bu geri alınamaz bir işlemdir, gönderildikten sonra geri alınamaz. Ama e-posta servisinde kalıcı bir yapılandırma hatası vardır ve üç tekrar denemeye rağmen başarısız olur. Ajan burada körlemesine devam etmez; tekrar sinyali eşiği aşılmıştır. Görev tutarlı bir durumda: paket yükseltilmiş, ödeme alınmış, yalnızca bildirim eksik. Ajan durumu kaydeder, olanı bir insana devreder ("yükseltme ve tahsilat tamam, e-posta gönderilemedi, elle gönderim gerek") ve tam bağlamı sunar. İnsan e-postayı elle gönderir; görev tamamlanır. Bu yolculuk, ajan hata yönetiminin tüm bileşenlerinin birlikte nasıl çalıştığını gösterir: doğrulama, tekrar deneme, güvenli işlem, kısmi başarısızlık yönetimi ve insana devir.

Ajan hata yönetiminin sağlam kurulması, hataları doğru sınıflandırmakla başlar; çünkü her hata türü farklı bir tepki gerektirir ve yanlış tepki durumu kötüleştirir. Pratikte ajanların karşılaştığı hataları dört ailede toplamak işe yarar: altyapı hataları, araç hataları, muhakeme hataları ve durum hataları. Bu taksonomi soyut bir sınıflandırma değil, doğrudan hangi mekanizmanın devreye gireceğini belirleyen bir karar ağacıdır.

Altyapı hataları, ajanın kendisiyle değil, bağlı olduğu servislerle ilgilidir: bir API'nin zaman aşımına düşmesi, hız sınırının aşılması, ağın kopması, bir servisin geçici olarak çökmesi. Bunlar çoğunlukla geçicidir ve doğru tepki kontrollü tekrar denemedir. Araç hataları, ajanın çağırdığı bir aracın beklenmedik ya da geçersiz bir yanıt döndürmesidir: eksik alan, yanlış biçim, boş sonuç. Doğru tepki, adım çıktısı doğrulamasıyla bunu yakalamak ve gerekirse aracı düzeltilmiş bir girdiyle tekrar çağırmaktır. Muhakeme hataları en sinsi olanlardır: ajan doğru araçları doğru biçimde çağırır ama yanlış bir plan yapar, yanlış bir çıkarım üretir veya bir ara sonucu yanlış yorumlar. Bu sessiz hatalar istisna fırlatmaz; yalnızca anlamsal doğrulama veya insana devir yakalayabilir. Durum hataları ise sistemin tutarsız bir ara duruma düşmesiyle ilgilidir ve kısmi başarısızlık yönetimini gerektirir.

Bu dört aileyi ayırt etmek neden bu kadar önemlidir? Çünkü aynı yanlış tepki bir aile için doğru, başka biri için yıkıcıdır. Bir muhakeme hatasını tekrar denemek anlamsızdır — ajan aynı yanlış planı yeniden üretir. Bir altyapı hatasını insana devretmek gereksiz yük yaratır — birkaç saniye sonra kendiliğinden düzelecek bir sorun için insanı meşgul edersiniz. Olgun bir ajan hata yönetimi, her hatayı önce doğru aileye yerleştirir, sonra o aileye uygun mekanizmayı çalıştırır. Hata sınıflandırması yanlışsa, arkasındaki tüm toparlanma mantığı da yanlış hedefe ateş eder.

Hata ailesi × tipik belirti × doğru tepki

Hata ailesi	Tipik belirti	Doğru tepki
Altyapı hatası	Zaman aşımı, hız sınırı, ağ kopması	Üstel geri çekilmeyle tekrar deneme
Araç hatası	Geçersiz biçim, eksik alan, boş sonuç	Doğrulama + düzeltilmiş girdiyle tekrar
Muhakeme hatası	Yanlış plan, sessiz yanlış çıkarım	Anlamsal doğrulama veya insana devir
Durum hatası	Tutarsız ara durum, yarım görev	Geri alma / telafi ile tutarlı duruma çek

Ajan hata yönetiminin en çok ihmal edilen ama en pratik korkuluklarından biri zaman aşımıdır. Bir ajanın bir araç çağrısı veya bir alt görev sonsuza kadar sürebilir; yanıt gelmezse ajan bekler, kaynak tüketir ve tüm görev bir tek adımda takılır. Her adıma bir zaman aşımı koymak — "bu adım şu kadar sürede bitmezse başarısız say" — ajanın takılıp kalmasını önler ve hata yönetiminin devreye girmesini sağlar. Zaman aşımı olmayan bir ajan, tek bir yavaş bağımlılık yüzünden bütünüyle donabilir.

Zaman aşımının doğal tamamlayıcısı devre kesicidir (circuit breaker). Bir bağımlılık sürekli başarısız oluyorsa, her seferinde onu tekrar denemek hem boşuna hem zararlıdır: zaten sorunlu servisi daha da yorar ve ajanı gereksiz yere bekletir. Devre kesici, belirli sayıda ardışık başarısızlıktan sonra o yolu geçici olarak "açar" — yani çağrıyı hiç denemeden hızla başarısız sayar ve alternatif bir yola veya insana devre yönlendirir. Bir süre sonra devre kesici "yarı açık" duruma geçip tek bir deneme yapar; başarılıysa yolu yeniden kapatır (normale döner), değilse açık kalmaya devam eder. Bu desen, tek bir çöken bağımlılığın tüm sistemi kilitlemesini önler.

Bu iki mekanizma, daha büyük bir ilkeye hizmet eder: kademeli bozulma (graceful degradation). İyi tasarlanmış bir ajan, bir bileşen çöktüğünde tümüyle durmak yerine, azalan bir yetenekle çalışmaya devam eder. Örneğin gelişmiş bir arama aracı yanıt vermiyorsa, ajan daha basit bir yedek araca düşebilir; bir zenginleştirme adımı başarısızsa, o adımı atlayıp temel yanıtı yine de üretebilir. Kademeli bozulmanın felsefesi şudur: mükemmel yanıt üretememek, hiç yanıt üretememekten iyidir — yeter ki ajan bunu bilerek ve kullanıcıya bildirerek yapsın. Tümü-ya-hiç davranan bir ajan kırılgandır; kademeli bozulan bir ajan dayanıklıdır.

Tek bir ajanın hatasını yönetmek zorken, birden çok ajanın birlikte çalıştığı sistemlerde iş daha da karmaşıklaşır. Çok ajanlı bir sistemde bir ajanın çıktısı, başka bir ajanın girdisi olur; yani bir ajandaki hata, yalnızca kendi görevini değil, ona bağlı diğer ajanların görevlerini de bozar. Bu, hata yayılmasının ajanlar arası bir üst katmanıdır ve ajan hata yönetiminin çok ajanlı sistemlerde neden ayrı bir dikkat gerektirdiğini açıklar.

Buradaki temel prensip hata sınırlamadır (error containment): bir ajanın hatası, o ajanın sınırları içinde kalmalı ve doğrulanmadan diğerlerine geçmemelidir. Bunun için ajanlar arası her devir noktasında bir doğrulama kapısı bulunmalıdır — bir ajan çıktısını bir sonrakine devretmeden önce, bu çıktı bir sözleşmeye (beklenen biçim ve içerik) göre denetlenir. Böylece bir ajanın ürettiği bozuk sonuç, zincirin geri kalanını kirletmeden yakalanır. Ayrıca ajanlar arası bağımlılıklar mümkün olduğunca gevşek tutulmalı ki bir ajanın başarısızlığı, tüm sistemi kilitlemesin.

İkinci prensip, bir koordinatör veya orkestratör katmanının varlığıdır. Çok ajanlı sistemlerde, alt ajanları yöneten bir üst katman, her alt ajanın durumunu izler, başarısız olanları tekrar dener veya yeniden atar, ve genel görevin tutarlılığını korur. Bu koordinatör, kısmi başarısızlık yönetiminin çok ajanlı karşılığıdır: bir alt ajan başarısız olduğunda, koordinatör diğerlerinin yaptıklarını geri alacak mı, yoksa başarısız alt görevi yeniden mi deneyecek buna karar verir. Koordinatörsüz bir çok ajanlı sistem, her ajanın kendi başına buyruk hareket ettiği ve kimsenin genel tutarlılıktan sorumlu olmadığı bir kaosa dönüşür. Ajanların birbirinden ve chatbot'lardan nasıl ayrıldığını AI ajanı ile chatbot farkı yazısında ele alıyoruz.

Bir ajan gerçek dünyada eylemler gerçekleştiriyorsa — kayıt güncelliyor, mesaj gönderiyor, işlem yapıyorsa — bu eylemlerin bir izi tutulmalıdır. Denetim kaydı (audit trail), ajanın attığı her önemli adımın, aldığı her kararın ve gerçekleştirdiği her yan etkili işlemin kim, ne zaman, hangi gerekçeyle sorularına cevap verecek biçimde kaydedilmesidir. Bu, yalnızca teknik bir gözlemlenebilirlik meselesi değil, aynı zamanda bir sorumluluk ve uyum gereğidir. Bir hata olduğunda "ajan ne yaptı ve neden yaptı" sorusuna cevap veremiyorsanız, ne düzeltebilir ne hesap verebilirsiniz.

Denetim kaydının kapsaması gerekenler nettir: ajanın hangi görevi aldığı, hangi araçları hangi girdilerle çağırdığı, her adımın sonucu, doğrulama sonuçları, insana devir olduysa kimin neyi onayladığı ve nihai eylemin ne olduğu. Özellikle geri alınamaz işlemlerde bu kayıt kritiktir; çünkü geri alınamaz bir eylemin ardından geriye kalan tek şey, o eylemin neden yapıldığının kaydıdır. Bu kayıt, hem sonradan teşhis için hem de düzenleyici bir inceleme durumunda kanıt olarak gereklidir. Regüle sektörlerde ve kişisel veri işleyen sistemlerde denetim kaydı çoğu zaman bir tercih değil, bir zorunluluktur.

Sorumluluk boyutu, denetim kaydının ötesine geçer. Bir ajanın verdiği bir kararın sonuçlarından kimin sorumlu olduğu, sistem tasarlanırken açıkça belirlenmelidir. Otonom bir eylemin sorumluluğu ajanı işleten kuruma aittir; bu yüzden insana devir eşikleri, onay kapıları ve yetki sınırları, yalnızca teknik korkuluklar değil, sorumluluğu yönetilebilir kılan araçlardır. Bir ajanı yüksek riskli bir alana yerleştirmeden önce, "bu ajan yanlış yaparsa kim, nasıl hesap verecek" sorusunun net bir cevabı olmalıdır. Bu boyutu daha geniş bir risk çerçevesinde AI risk değerlendirmesi yazısında ele alıyoruz.

Ajan hata yönetiminin her mekanizması bir bedelle gelir: doğrulama ek çağrı demektir, tekrar deneme ek gecikme demektir, insana devir ek bekleme demektir, gözlemlenebilirlik ek altyapı demektir. Bu yüzden güvenilirlik ile maliyet/gecikme arasında bilinçli bir denge kurmak gerekir. Amaç, her adımı en yüksek güvenlik düzeyinde koşmak değil; riskle orantılı bir güvenilirlik uygulamaktır. Düşük riskli, geri alınabilir bir adımı ağır doğrulama ve çoklu tekrarla boğmak, hem yavaşlatır hem pahalılaştırır — üstelik kazanç minimaldir.

Doğru yaklaşım, güvenilirlik yatırımını riske göre ölçeklemektir. Bir işlem ne kadar geri alınamaz ve etkili ise, o kadar çok doğrulama, o kadar sıkı onay ve o kadar dikkatli tekrar mantığı hak eder. Buna karşılık salt-okunur, düşük etkili bir işlem, hafif bir doğrulama ve basit bir tekrarla yetinebilir. Bu risk-orantılı yaklaşım, güvenilirlik bütçesini en çok ihtiyaç duyulan yere yönlendirir. Bir başka önemli kaldıraç, güvenilirlik mekanizmalarını akıllıca yerleştirmektir: kritik adımlardan önce yoğun doğrulama, sonra hafif izleme; her adımda aynı ağır kontrolü tekrarlamak yerine.

Gecikme tarafında, kullanıcının algıladığı hız da önemlidir. Bir ajan arka planda birkaç tekrar denerken kullanıcıyı boş bir ekranla bekletmek kötü bir deneyimdir; ilerlemeyi göstermek ("adım 2/4 çalışıyor"), akış hâlinde yanıt vermek veya uzun görevleri eşzamansız kılıp sonucu sonra bildirmek, algılanan gecikmeyi büyük ölçüde azaltır. Maliyet tarafında ise, gereksiz tekrarları ve aşırı doğrulama çağrılarını budamak doğrudan tasarruf getirir; bu boyutu LLM maliyet düşürme yazısında derinleştiriyoruz. Sonuçta ajan hata yönetimi, güvenilirliği körlemesine maksimize etmek değil, riske göre bilinçli optimize etmektir.

Kurumların ajan hata yönetiminde nerede durduğunu görmek ve bir sonraki adımı planlamak için bir olgunluk modeli yararlıdır. Olgunluk, tek bir teknikle değil, sistemin kötü güne ne kadar hazır olduğuyla ölçülür. Aşağıdaki dört seviye, sahada gözlemlenen tipik bir ilerlemeyi tarif eder; çoğu ekip birinci seviyede başlar ve bilinçli yatırımla yukarı çıkar.

Birinci seviye, yalnızca mutlu yolun tasarlandığı seviyedir: ajan iyi günde çalışır, hata yolları düşünülmemiştir, ilk gerçek hatada sistem öngörülemez biçimde davranır. İkinci seviye, temel korumaların eklendiği seviyedir: adım doğrulaması, geçici hatalarda tekrar deneme ve temel loglama vardır, ama işlemler sınıflandırılmamış ve geri alma mekanizması yoktur. Üçüncü seviye, işlemlerin geri alınabilir ve geri alınamaz diye ayrıldığı, geri alma ve telafi mekanizmalarının kurulduğu, kısmi başarısızlığın yönetildiği ve insana devir eşiklerinin tanımlandığı seviyedir. Dördüncü seviye, tüm bunların üstüne sistematik test (hata enjeksiyonu, geri alma provaları), tam gözlemlenebilirlik, denetim kaydı ve sürekli iyileştirme ekleyen seviyedir — burada ajan hata yönetimi bir kod parçası değil, yaşayan bir disiplindir.

Ajan hata yönetimi olgunluk seviyeleri

Seviye	Belirleyici özellik	Tipik risk
1 - Mutlu yol	Sadece iyi gün tasarlanmış	İlk hatada öngörülemez çöküş
2 - Temel koruma	Doğrulama + tekrar + loglama	Geri alma yok, kısmi başarısızlık yönetilemez
3 - Toparlanma	İşlem sınıflandırma + geri alma + insana devir	Test ve izleme eksikse sessiz bozulma
4 - Olgun	Sistematik test + gözlemlenebilirlik + denetim	Sürekli bakım yükü

Bu modelin amacı bir ekibi yargılamak değil, yol göstermektir. Her kurumun her ajanı dördüncü seviyede olmak zorunda değildir; düşük riskli, geri alınabilir işlemlerle çalışan bir ajan için ikinci seviye yeterli olabilir. Ama bir ajan yüksek riskli, geri alınamaz eylemler yapıyorsa, üçüncü ve dördüncü seviye artık bir tercih değil, bir zorunluluktur. Doğru soru "en üst seviyeye nasıl çıkarım" değil, "bu ajanın riski hangi seviyeyi gerektiriyor"dur. Kurumunuzun ajan olgunluğunu değerlendirmek ve doğru seviyeyi hedeflemek için danışmanlık ile başlayabilirsiniz.

Deneyimli bir gözle bakıldığında, başarısız olan ajan projeleri benzer hatalarla kırılır. En yaygın ajan hata yönetimi hataları şunlardır:

• Yalnızca mutlu yolu tasarlamak: Sistem her şey yolunda giderken çalışır, ama ilk gerçek hata karşısında çöker; çünkü hata yolları hiç düşünülmemiştir. Ajan güvenilirliği, mutlu yolda değil, kötü günde belli olur.
• Körlemesine tekrar deneme: Hatayı geçici mi kalıcı mı diye ayırmadan her başarısızlıkta tekrar denemek; kalıcı hatada kaynak yakar, yan etkili işlemde ise işlemi ikiye katlar.
• Geri alınamaz işlemi erkene koymak: E-posta, ödeme veya silme gibi geri alınamaz işlemleri görevin ortasına koyup, sonraki bir adım başarısız olduğunda geri sarılamaz bir enkaz yaratmak.
• İşlemleri sınıflandırmamak: Hangi işlemin geri alınabilir, hangisinin geri alınamaz olduğunu baştan belirlememek; bu, her işleme aynı körlükte davranmaya ve öngörülemez hasara yol açar.
• Durumu bellekte tutmak: Görev durumunu kalıcı bir yerde tutmayıp yalnızca bellekte çalışmak; bir kesinti olduğunda ajan ne temizleyebilir ne devam edebilir, kısmi başarısızlık yönetilemez olur.
• Sessiz hatayı yok saymak: Yalnızca çöken hataları yakalayıp, ajanın akıcı ama yanlış ürettiği sessiz hataları görmezden gelmek; oysa en pahalı hatalar genellikle bunlardır.
• İnsana devir eşiği koymamak: Ajanı her şeyde tam otonom bırakmak; yüksek riskli, geri alınamaz kararlarda bile insanı devreden çıkarmak, kaçınılmaz olarak büyük bir hataya davetiye çıkarır.
• Geri alma yolunu test etmemek: Yazılmış ama hiç çalıştırılmamış geri alma koduna güvenmek; ilk gerçek hatada bu kodun da bozuk olduğu ortaya çıkar.

Ajan hata yönetiminin tüm bu bileşenlerini aynı anda kurmaya çalışmak, çoğu ekibi felç eder. Doğru yaklaşım, klasik mühendislik prensibiyle aynıdır: dar bir kapsamla başla, ölç, iyileştir, sonra büyüt. İlk ajanınızı tüm kurumu dönüştürecek bir sistem olarak değil, tek ve sınırlı bir görevi güvenilir biçimde yapan bir prototip olarak kurun. Bu dar başlangıç, hata yönetimi kaslarınızı gerçek ama düşük riskli bir ortamda geliştirmenizi sağlar.

İyi bir başlangıç görevi üç özelliğe sahiptir. Birincisi düşük risk: ilk ajanınız mümkün olduğunca geri alınabilir işlemlerle çalışsın; geri alınamaz eylemleri (ödeme, dış iletişim) ya hiç içermesin ya da mutlaka insan onayına bağlasın. İkincisi ölçülebilirlik: görevin başarılı olup olmadığı net bir biçimde tanımlanabilsin ki hata yönetiminizin işe yarayıp yaramadığını görebilesiniz. Üçüncüsü sınırlılık: tek bir alanda, az sayıda araçla, öngörülebilir bir görevle başlayın — karmaşıklığı ancak temel güvenilirlik kanıtlandıktan sonra ekleyin.

Bu yaklaşımın kalbinde şu gerçek yatar: ajan hata yönetimi bir kere kurulup unutulan bir şey değil, sistemle birlikte büyüyen bir disiplindir. Her yeni araç yeni bir hata yüzeyi, her yeni adım yeni bir yayılma yolu getirir. Bu yüzden hata yönetimini, ajanın yeteneklerini genişletirken sürekli güncellenen bir katman olarak görmek gerekir. Kurumunuza özel bir ajan güvenilirlik yaklaşımı tasarlamak ve ekibinizin bu yetkinliği kazanması için eğitim programı ile başlayabilir, daha geniş bir yol haritası için danışmanlık seçeneğini değerlendirebilirsiniz.

Ajan hata yönetiminde sık atlanan bir soru şudur: "yeterince güvenilir" tam olarak nedir? Hedef netleştirilmezse iki uç ortaya çıkar: ya her hataya takılıp sistemi asla üretime alamayan aşırı-mükemmeliyetçilik, ya da hiçbir hedef koymadan "çalışıyor işte" diyen umursamazlık. İkisi de sağlıksızdır. Sağlam bir yaklaşım, yazılım güvenilirliği mühendisliğinden ödünç alınan iki kavramı ajan dünyasına taşımaktır: güvenilirlik hedefi (SLO) ve hata bütçesi.

Güvenilirlik hedefi, ajanın belirli bir ölçütte ulaşması beklenen açık bir eşiktir: örneğin "görevlerin en az yüzde 95'i insan müdahalesi olmadan doğru tamamlanmalı" veya "geri alınamaz bir işlem asla yanlış yürütülmemeli (hedef: yüzde 100)". Dikkat edin, hedef her ölçüt için aynı değildir — düşük riskli bir görevde yüzde 95 kabul edilebilirken, geri alınamaz bir finansal işlemde hedef pratikte mutlak olmalıdır. Hedefi işlem sınıfına göre ayarlamak, güvenilirlik çabasını riske göre dağıtmanın somut yoludur. Hedef olmadan "iyi mi" sorusu cevaplanamaz; çünkü karşılaştırılacak bir çizgi yoktur.

Hata bütçesi ise bu hedefin ikizidir: eğer hedef yüzde 95 başarıysa, kalan yüzde 5, "kabul edilebilir hata" bütçesidir. Bu bütçe iki işe yarar. Birincisi, mükemmeliyetçiliği dizginler: her tek hatayı bir kriz gibi görmek yerine, bütçe içinde kalındığı sürece sistemin sağlıklı olduğunu kabul edersiniz. İkincisi, önceliklendirmeyi yönlendirir: hata bütçesi hızla tükeniyorsa, yeni özellik eklemeyi durdurup güvenilirliğe yatırım yapmanın zamanı gelmiştir. Bu, "ne zaman daha çok güvenilirliğe yatırım yapmalıyım" sorusuna veriye dayalı bir cevap verir. Hata bütçesi tükenmiyorsa, belki de gereğinden fazla güvenilirliğe yatırım yapıyor ve hızdan feragat ediyorsunuzdur.

Bu hedefleri anlamlı kılan, onları gerçek ölçümle beslemektir. Gözlemlenebilirlik katmanından gelen görev başarı oranı, insana devir sıklığı, ortalama tekrar sayısı ve hata türü dağılımı, hedeflere göre değerlendirilir ve bir yönetim panosunda izlenir. Böylece ajan hata yönetimi, öznel bir "iyi görünüyor" hissinden çıkıp nesnel bir yönetim disiplinine dönüşür. Kurumunuz için doğru güvenilirlik hedeflerini belirlemek ve bunları izleyecek bir çerçeve kurmak, ekip yetkinliği gerektirir; bunu eğitim programı ile geliştirebilir, uçtan uca tasarım için danışmanlık alabilirsiniz.

Aşağıdaki kontrol listesi, bir ajan iş akışını fikirden üretime sağlam biçimde taşımak için pratik bir rehberdir. Bu adımları sırayla işaretleyebiliyorsanız, ajan hata yönetimi açısından sağlam bir temel kurmuşsunuz demektir.

Nasıl Yapılır

Ajan hata yönetimi uygulama kontrol listesi

Bir ajan iş akışını güvenilir biçimde üretime almak için adım adım kontrol listesi.

1. 1

   İşlemleri sınıflandır

   Ajanın kullandığı her aracı geri alınabilir, telafiyle geri alınabilir veya geri alınamaz diye etiketle; davranışını buna göre belirle.

2. 2

   Adım doğrulaması ekle

   Her adımın çıktısını yapısal, mantıksal ve gerektiğinde anlamsal olarak doğrula; doğrulanmadan bir sonraki adıma geçme.

3. 3

   Tekrar deneme stratejisi kur

   Geçici hatalar için üstel geri çekilme, tekrar üst sınırı ve devre kesici tanımla; yan etkili işlemleri idempotency anahtarıyla koru.

4. 4

   Geri alma mekanizması tasarla

   Geri alınabilir işlemler için eski durumu sakla; telafiyle geri alınabilir işlemler için telafi (compensation) işlemleri ve saga akışı kur.

5. 5

   Durumu kalıcı tut

   Her adımın sonucunu ve görev durumunu dayanıklı bir depoda tut; kesinti sonrası tutarlı noktadan devam edilebilsin.

6. 6

   İnsana devir eşiği koy

   Risk, belirsizlik ve tekrar sinyalleri için açık eşikler tanımla; eşik aşıldığında ajan durup insana bağlamla devretsin.

7. 7

   Güvenli işlem korkulukları uygula

   En az yetki, kuru çalıştırma, zaman aşımı ve hacim sınırlarıyla ajanın verebileceği en büyük hasarı baştan küçült.

8. 8

   Hata yollarını test et ve izle

   Hata enjeksiyonu, geri alma provası ve gözlemlenebilirlik ile kötü günde nasıl davrandığını sürekli ölç.

Bu kontrol listesini bir pilot üzerinde uygulamak, büyük bir dönüşüm vaadinden çok daha değerlidir; çünkü küçük ama güvenilir bir ajan, büyük ama kırılgan bir vaatten her zaman daha ikna edicidir. Uçtan uca bir ajan güvenilirlik tasarımı kurmak için danışmanlık ile başlayabilir, tüm kavramları derinleştirmek için öğrenme merkezini inceleyebilirsiniz.

Ajan hata yaparsa ne olur?

Bir ajan çok adımlı bir görevde hata yaptığında iki yol vardır. Ajan hata yönetimi kuruluysa hata adım çıktısı doğrulamasında yakalanır; sistem geçici bir sorunsa kontrollü tekrar deneme uygular, kalıcı bir sorunsa görevi güvenli bir noktada durdurur, yaptığı geri alınabilir değişiklikleri geri alma mekanizmasıyla temizler ve gerekirse insana devreder. Hata yönetimi kurulu değilse hata sessizce sonraki adımlara yayılır ve zarar birikir. Kısacası ajanın hata yapması kaçınılmazdır; belirleyici olan, hata yaptığında sistemin bunu yakalayıp hasarı sınırlayıp sınırlamadığıdır.

Ajanın yaptığı işlem geri alınabilir mi?

İşleme bağlıdır. İşlemler üç sınıfa ayrılır: doğal geri alınabilir olanlar (taslak, dosya, kayıt güncelleme — eski hâli saklanmışsa geri alınır), telafiyle geri alınabilir olanlar (sipariş, rezervasyon — ayrı bir iptal işlemiyle dengelenir) ve geri alınamaz olanlar (e-posta, ödeme, kalıcı silme). Geri alınamaz işlemler için gerçek bir geri alma mekanizması yoktur; bu yüzden yürütülmeden önce onaya veya insana devir eşiğine bağlanırlar. Doğru tasarım, her işlemi baştan bu sınıflardan birine yerleştirmektir.

Ajan ne zaman insana devredilmeli?

İnsana devir eşiği üç sinyalle tetiklenir. Birincisi risk: işlem geri alınamaz ve etkisi büyükse ajan onay istemelidir. İkincisi belirsizlik: ajanın güven skoru düşükse veya adım çıktısı doğrulamayı geçemiyorsa devretmelidir. Üçüncüsü tekrar: aynı adım birkaç denemeye rağmen başarısız oluyorsa durup insana bırakmalıdır. Sağlam kural, bu üç sinyali açık eşiklere bağlamak ve eşik aşıldığında ajanın kendiliğinden değil, insan onayıyla ilerlemesini sağlamaktır.

Tekrar deneme ne zaman zararlıdır?

Tekrar deneme yalnızca hata geçiciyse (ağ, zaman aşımı, hız sınırı) ve işlem idempotentse güvenlidir. Hata kalıcıysa (yanlış girdi, yetki hatası) tekrar deneme yalnızca gecikme ve maliyet ekler. En tehlikelisi, yan etkili ve idempotent olmayan bir işlemin körlemesine tekrar denenmesidir: ilk çağrı başarılı olmuş ama yanıtı kaybolmuşsa, tekrar işlemi ikinci kez yapar. Bu yüzden tekrar deneme, üstel geri çekilme, bir üst sınır ve idempotency anahtarı ile birlikte tasarlanmalıdır.

Kısmi başarısızlık nasıl yönetilir?

Kısmi başarısızlık, görevin bazı adımlarının başarılı bazılarının başarısız olmasıdır ve sistem tutarsız bir ara duruma düşer. Yönetimin özü, görevi tutarlı bir duruma çekmektir: doğal geri alınabilir adımlar geri alınır, telafiyle geri alınabilir adımlar için telafi işlemleri çalışır, geri alınamaz adımlar zaten en sona bırakıldığından hasar oluşmaz. Bu koordinasyona saga deseni denir. Ayrıca her görevin durumu kalıcı tutulmalı ki kesinti sonrası tutarlı noktadan devam edilebilsin.

Ajan hata yönetimi nasıl test edilir?

Sadece mutlu yol test edilerek güvenilemez. Üç yöntem birlikte kullanılır: hata enjeksiyonu (araç çağrılarına zaman aşımı, hız sınırı, bozuk yanıt ve yarım başarı enjekte edip ajanın tepkisini ölçmek), tekrarlanabilir senaryolar (sabit tohumla aynı görevi defalarca çalıştırıp kenar durumları yakalamak) ve geri alma provaları (her geri alınabilir işlemin geri alma yolunu düzenli çalıştırıp gerçekten çalıştığını doğrulamak). Bu testler bir gözlemlenebilirlik katmanıyla desteklenmelidir.

Mevcut bir ajanın hata yönetimi olgunluğunu hızlıca değerlendirmek için birkaç somut soru yeterlidir. Ajanınızın kullandığı her aracı geri alınabilir, telafiyle geri alınabilir ve geri alınamaz diye sınıflandırdınız mı? Geri alınamaz işlemler bir onaya veya insana devir eşiğine bağlı mı, yoksa ajan bunları tek başına mı yürütüyor? Bir adım başarısız olduğunda, ajan hatayı geçici mi kalıcı mı diye ayırt ediyor, yoksa körlemesine mi tekrar deniyor? Yan etkili işlemleriniz idempotency anahtarıyla korunuyor mu? Bir görev yarıda kaldığında sistem tutarlı bir duruma dönebiliyor mu, yoksa yarım bir durumda mı kalıyor?

Bu soruların çoğuna "hayır" veya "emin değilim" diyorsanız, ajanınız olgunluk modelinde muhtemelen birinci veya ikinci seviyededir ve üretimde bir gün sizi şaşırtacaktır. Bu bir başarısızlık değil, bir başlangıç noktasıdır. Doğru yaklaşım, bu soruları bir yol haritasına çevirmek: önce işlemleri sınıflandırın, sonra geri alınamaz olanları onaya bağlayın, ardından adım doğrulaması ve güvenli tekrar deneme ekleyin, en sonunda test ve gözlemlenebilirlikle bunu bir disipline dönüştürün. Her adım, ajanınızı kötü güne biraz daha hazır kılar.

Bu öz-değerlendirmeyi düzenli aralıklarla tekrarlamak, ajan hata yönetimini bir kerelik bir proje değil, süregelen bir olgunlaşma süreci olarak kurar. Ajanınız yeni araçlar ve yetenekler kazandıkça, bu sorular yeniden sorulmalı ve hata yönetimi buna göre güncellenmelidir. Kurumunuza özel bir değerlendirme ve yol haritası için danışmanlık ile başlayabilirsiniz.

Kısaca, ajan hata yönetimi, çok adımlı görevleri yürüten bir yapay zeka ajanının hatalarını erken yakalayan, yayılmalarını durduran, mümkün olduğunda otomatik toparlayan ve gerektiğinde insana devreden tasarım disiplinidir. Bileşenleri birbirini tamamlar: her adım çıktısını doğrulamak, geçici hatalarda kontrollü tekrar deneme uygulamak, işlemleri geri alınabilir ve geri alınamaz diye sınıflandırmak, geri alınabilir olanlar için sağlam bir geri alma mekanizması kurmak, kısmi başarısızlıkta sistemi tutarlı tutmak, güvenli işlem korkulukları ile hasarı baştan sınırlamak ve risk eşiğinde insana devretmek.

En önemli mesaj şudur: amaç ajanı hatasız yapmak değildir — bu imkânsızdır. Amaç, ajan hata yaptığında zarar vermeden durmasını sağlamaktır. Bir ajanın gerçek olgunluğu, mutlu yolda ne kadar iyi çalıştığıyla değil, kötü günde ne kadar güvenli davrandığıyla ölçülür. Temel kavramlar için AI ajanı ile chatbot farkı ve doğrulama alışkanlığı için insan ai iş birliği yazılarına bakabilir; kurumunuza özel bir ajan güvenilirlik tasarımı ve ekip yetkinliği için eğitim programı ile başlayıp danışmanlık ve öğrenme merkezi ile derinleşebilirsiniz.