Ajanınızın Yeniden Deneme Hatası Bir Yapay Zeka Sorunu Değil; Üzerinde LLM Bulunan Bir Dağıtık Sistem Sorunudur

Çoğu yapay zeka ajanı (agent) demosu kusursuz bir senaryoda ilerler: Model bir araç (tool) seçer, araç 200 yanıtını döner ve ajan yoluna devam eder. Ancak üretim (production) ortamı farklıdır. Üretimde araç çağrıları bazen hiçbir yanıt döndürmez. İşte doğru bir kararın yanlış bir sonuca dönüştüğü nokta tam olarak burasıdır.

"Karar Verildi" ile "Tamamlandı" Arasındaki Boşluk#

Tipik bir senaryoyu ele alalım: Bir destek talebini işleyen ajan, müşteriye para iadesi yapılması gerektiğine karar verir ve POST /refunds çağrısını yapar. Ödeme servisi iadeyi işler, deftere kaydeder ve yanıtı göndermeye başlar. Tam o sırada ağda bir kesinti yaşanır. Ajanın HTTP istemcisi zaman aşımına (timeout) uğrar ve hata fırlatır.

Ajanın bakış açısından çağrı başarısız olmuştur; ödeme servisinin açısından ise başarılıdır. Ajan döngüsü hatayı görür ve en doğal tepki olarak işlemi yeniden dener. Sonuç: Müşteriye iki kez para iadesi yapılır.

Burada model kusursuz akıl yürütmüş, doğru argümanlarla doğru eylemi seçmiştir. Daha iyi prompt yazmak, daha büyük bir model kullanmak veya daha akıllı bir planlayıcı kurgulamak bu sorunu çözmez; çünkü hata, akıl yürütme aşaması bittikten sonra gerçekleşmiştir.

Hata Modu 1: Zaman Aşımını (Timeout) "Hayır" Olarak Kabul Etmek#

Zaman aşımı size yalnızca tek bir şey söyler: Bir yanıt alamadınız. İşlemin gerçekleşmediğini söylemez. Araç hatalarını doğrudan "araç başarısız oldu, ne yapacağına karar ver" şeklinde sarmalayan ajan çatıları (frameworks), üç farklı durumu tek bir potada eritir:

• İstek servise hiç ulaşmadı.
• İstek servise ulaştı ve reddedildi.
• İstek servise ulaştı, başarıyla işlendi ancak yanıt yolda kayboldu.

Yalnızca ilk iki durumda körü körüne yeniden deneme (retry) yapmak güvenlidir.

Hata Modu 2: Idempotency Anahtarının Olmaması#

Ajan bir idempotency (eş-etkililik) anahtarı göndermiş olsaydı, ikinci iade çağrısı yeni bir işlem yapmaz ve ilk işlemin sonucunu döndürürdü. Bu anahtar ilk denemeden önce uygulama katmanında üretilmeli ve aynı niyetin (intent) her yeniden denemesinde tekrar kullanılmalıdır:

intent = actions.record_intent(
    kind="refund",
    order_id=order.id,
    amount=amount,
    idempotency_key=uuid4(),  # bir kez oluşturulur, niyetle birlikte saklanır
)

try:
    result = payments.refund(
        order_id=order.id,
        amount=amount,
        idempotency_key=intent.idempotency_key,
    )
    actions.mark_confirmed(intent.id, result)
except Timeout:
    actions.mark_unknown(intent.id)  # "failed" (başarısız) DEĞİL

Buradaki kritik nokta anahtarın nerede üretildiğidir. Eğer anahtarı LLM üretirse veya her denemede yeniden oluşturulursa hiçbir koruma sağlamaz.

Hata Modu 3: Yalnızca Bağlam Penceresinde Yaşayan Durum Bilgisi#

"4812 numaralı siparişi iade etmeyi zaten denedim" kaydı yalnızca sohbet geçmişinde (context window) tutuluyorsa; sistem çöktüğünde, bağlam kırpıldığında veya işçi süreç (worker) yeniden başlatıldığında bu bilgi kaybolur. Niyet, yürütme öncesinde kalıcı bir depolama alanına (durable storage) yazılmalıdır ki işi devralan süreç ne olduğunu görebilsin.

Hata Modu 4: "Sonuç Bilinmiyor" Durumunun Olmaması#

Çoğu eylem modeli yalnızca iki uç duruma sahiptir: başarılı ve başarısız. Oysa güvenilir sistemler en az dört duruma ihtiyaç duyar:

• submitted (gönderildi): İsteği gönderdik, henüz yanıt yok.
• confirmed (onaylandı): Hedef sistem işlemi onayladı.
• failed (başarısız): Hedef sistem işlemi açıkça reddetti.
• unknown (bilinmiyor): Sonucu bilemiyoruz.

En kritik durum unknown durumudur. Otomatik yeniden denemeleri durdurması ve mutabakat (reconciliation) sürecini tetiklemesi gereken durum budur.

Hata Modu 5: Mutabakat (Reconciliation) Yolunun Olmaması#

Bir eylem unknown durumuna düştüğünde, gerçeği öğrenecek bir mekanizma devreye girmelidir: Ödeme servisini sorgulamak, işlem kaydını kontrol etmek ve durumu netleştirmek. Production'da Agent Güvenilirliği ve Tool Calling ve Multi-Step Agent'lar geliştirirken geliştiriciler için en önemli çıkarım şudur: Yan etkisi olan araç çağrılarını LLM'in insafına bırakmayın; idempotency, kalıcı durum yönetimi ve durum sorgulama adımlarını doğrudan altyapı katmanında inşa edin.