Üretim Sistemlerini Bozan 6 AI Ajan Döngüsü Hata Modu

Sessiz Araç Çağrısı Hataları: Ajan Hiçbir Şey Yapmadan "Başarılı" Olduğunda

Araç çağrısı boş bir dize ya da yumuşak bir "sonuç bulunamadı" mesajı döndürüyor, model bunu geçerli bir sonuç olarak yorumluyor ve ajan tamamen hiçbir şey yapmadan başarılı olmuş gibi devam ediyor. Düzeltme, her araç dönüşünde bir doğrulama kapısıdır: çıktıyı model görmeden önce şema denetimi veya akıl kontrolüne tabi tutun; döngünün başa çıkmak zorunda kalacağı gerçek bir başarısızlığı yüzeye çıkarın, boş bir başarı değil.

Bu sorun sinsidir çünkü hiçbir şey çökmez. Üretim ajanlarındaki sessiz hata modlarını yazan bir geliştirici üretim ajanlarındaki sessiz hata modları bunu doğrudan ifade etmiştir: modeller genel boş dizeleri geçerli işlemsizlikler olarak yorumlar ve hatanın farkında olmadan yürütmeye devam eder. Bağlantı düştüğü için sıfır satır döndüren veritabanı sorgusu, modele göre meşru olarak hiçbir şey bulmayan sorguyla aynı görünür. Dolayısıyla ajan "eşleşen kayıt yok" raporuyla devam eder ve bir hafta sonra çalıştırmalarının üçte birinin sessizce bozulduğunu fark edersiniz.

Doğrulama kapısı araç ile model arasında yer alır:

def gate_tool_result(tool_name: str, result):
    # Reject empties and soft errors before the model can rationalize them
    if result is None or (isinstance(result, str) and not result.strip()):
        raise ToolFailure(f"{tool_name} returned empty -- treat as failure, not no-op")
    if isinstance(result, str) and result.lower().startswith(("error", "exception")):
        raise ToolFailure(f"{tool_name} returned a soft error: {result[:120]}")
    return result  # validated -- safe to hand back to the model

Mesele tam kontroller değil; kendinizinkiler her aracın meşru olarak ne döndürdüğüne bağlıdır. Mesele şu: doğrulanmamış bir dönüş değeri, stokastik bir modele bıraktığınız bir karardır ve modelin varsayılan hareketi devam etmektir.

Doğrulanmamış araç dönüşü, yaşanmayı bekleyen sessiz bir hatadır. Çıktıyı doğrulayın, çağrıya güvenmeyin.

Uzun Bağlamlarda Akıl Yürütme Bozulması: Ajan Daha Uzun Çalıştıkça Kötüleştiğinde

Sert bağlam sınırının altında kalınsanız bile, bağlam büyüdükçe akıl yürütme kalitesi bozulur. Bu, "ortada kaybolma" etkisidir: model uzun bir bağlamın başına ve sonuna güvenilir biçimde dikkat ederken ortayı kaybeder. Düzeltme, sabitlenmiş kısıtlamaları koruyan döngü-ortası sıkıştırmadır: gürültüyü sıkıştırın, yük taşıyan talimatları koruyun.

Mekanizmanın bir adı var. Anthropic'in mühendislik blogu bunu şu şekilde tanımlar: bağlam çürümesi: "bağlam penceresindeki token sayısı arttıkça modelin bu bağlamdaki bilgileri doğru biçimde geri çağırma yeteneği azalır." Çünkü "her token diğer her token'a dikkat eder," n token için n² ikili ilişki elde edersiniz ve bağlam uzadıkça modelin dikkati giderek incelir.

Bu uyarıcı nitelik, yük taşıyan talimatları korumak, asıl meseledir ve bunu neden önemsendiğini gösteren belgelenmiş bir olay vardır. Bir bildirilen vakada, bir OpenClaw ajanı bir kullanıcının gelen kutusunu toplu sildi; bunun nedeni, kendisine verilen güvenlik talimatının ("bana söyleyene kadar harekete geçme") geçmiş sıkıştırıldığında aktif bağlamdan düşürülmüş olmasıydı. En son çıkarılması gereken kısıtlama, sıradan geçmiş olarak değerlendirildi ve özetlenerek silindi.

Dolayısıyla naif bir "N turdan eski her şeyi özetle" yaklaşımı tehlikelidir. Sıkıştırma, asla neyi bırakmaması gerektiğini bilmek zorundadır:

PINNED = {"system_constraints", "safety_instructions", "active_task_spec"}

def compress_history(messages):
    pinned = [m for m in messages if m.tag in PINNED]      # never summarized
    transient = [m for m in messages if m.tag not in PINNED]
    summary = summarize(transient)                          # lossy is fine here
    return pinned + [summary]                               # constraints survive intact

Bu, önceki bölümdeki taşma sorunuyla farklıdır. Taşma yer bitmesi hakkındadır; bozulma ise yer hala varken modelin kötüleşmesi hakkındadır. Pencerenizin yüzde 60'ında olabilir ve zaten kötü akıl yürütüyor olabilirsiniz.

Yeniden Başlatmada Durum Kaybı: Çöküş Yeniden Başlamak Anlamına Geldiğinde

Uzun süre çalışan bir ajan çöktüğünde, yeniden başlatma, OOM sonlandırması veya düşen bir ağ bağlantısından kaynaklanıyor olsun, varsayılan olarak checkpoint'ten devam etme yoktur. Döngü sıfırdan başlar: zaten bitirdiği işi yeniden yapar ve daha da kötüsü, aynı e-postayı iki kez göndermek veya ücretli bir API çağrısını yeniden çalıştırmak gibi daha önce gerçekleştirdiği eylemleri tekrar edebilir. Düzeltme checkpoint almaktır: döngünün durumunu her adımdan sonra kalıcı hale getirin, böylece yeniden başlatma sıfırdan değil kaldığı yerden rehydrate etsin.

LangGraph'ta checkpoint backend seçimi, geliştirme ile üretim arasındaki seçimdir. LangGraph'ın kalıcılık belgeleri describe SqliteSaver as "ideal for experimentation and local workflows" and PostgresSaver as "ideal for using in production," and the latter is what LangSmith itself runs on. The two are deliberately parallel in code, which makes the contrast easy to see:

# Development -- single file, no server, do not ship this
from langgraph.checkpoint.sqlite import SqliteSaver

# Production -- survives the box it runs on
from langgraph.checkpoint.postgres import PostgresSaver

İki ayrıntı insanları ısırıyor. Birincisi, checkpoint paketleri çekirdek LangGraph'tan ayrı kurulur (langgraph-checkpoint-sqlite ve langgraph-checkpoint-postgres kendi bağımlılıklarıdır), bu nedenle yeni bir ortamda siz ekleyene kadar Postgres saver olmayacaktır. İkincisi, her checkpoint işleminin config'de bir thread_id gereksinimi vardır. Bu ID, belirli bir çalıştırmayı kaydedilen durumuna bağlar ve doğru thread_id olmadan yeniden başlatma hiçbir şeyi rehydrate etmez.

Yeniden Deneme Fırtınaları: Kendi Ajanlarınız Çökmüş Bir Servise DDoS Attığında

Bir alt servis çöktüğünde, safça yapılan yürütme başına yeniden denemeler, ajan filonuzu kendi kendinize bir hizmet reddi saldırısına dönüştürür. Düzeltmenin iki yarısı vardır: yeniden denemeleri zaman içinde yaymak için her ajanda jitter'lı üstel geri çekilme ve paylaşılan bir başarısızlık eşiğine ulaşıldıktan sonra devreye girerek tüm sürüyü açıkça çökmüş bir servisi dövmekten alıkoyan global bir devre kesici.

Matematik affetmez. Bir yeniden deneme örüntüleri yazısının da belirttiği gibi, her biri on kez yeniden deneyen on paralel ajan, zaten yerde olan bir servise yüz istek gönderir; çünkü her ajanın geri çekilmesi yürütme başınadır, global değil. Ajan başına geri çekilme tek başına bunu çözmez. Her biri kibarca geri çekilen on ajan, hepsi aynı anda başladıysa yine de uyum içinde geri çekilir ve senkronize dalgalar halinde yeniden dener. Jitter, her ajanın bekleme süresini rastgeleleştirerek senkronizasyonu bozar; devre kesici ise tek bir başarısızlık durumunu tüm ajanlarda paylaşarak sürüyü durdurur.

Geri çekilme yarısı Python'da çözülmüş bir problemdir; tenacity kütüphanesi üstel-jitter'lı yapıyı temiz biçimde ele alır:

from tenacity import retry, stop_after_attempt, wait_random_exponential

@retry(wait=wait_random_exponential(multiplier=1, max=60), stop=stop_after_attempt(5))
def call_flaky_service(payload):
    return downstream.post(payload)

Devre kesici global: tüm ajanlar arasında paylaşılmalıdır, yürütme başına yeniden örneklenmemeli. Başarısızlıklar bir eşiği aştığında devre açılır, her ajan çağrı yapmak yerine hızla başarısız olur ve bir soğuma süresi sonunda servisi test etmek için tek bir probe geçirilir. Her ajanın kendi sürecinde yaşayan bir devre kesici hiçbir şeyi korumaz, çünkü hiçbir şey paylaşılmaz; çökmüş servis yine de yüz isteğin tamamını alır.

Yürütme başına geri çekilme, on ajanın çökmüş bir servisi hala uyum içinde dövmesine izin verir. Sürüyü durdurmak için devre kesicinin global olması gerekir.

Altı Hataya Tek Bakış

Altyapı kısmından önce, tüm katalog tek bir yerde: hata, onu yaratan mekanizma, koşum takımı düzeltmesi ve ilgili parametrenin her framework'teki yeri.

CrewAI, AutoGen, Dify veya el yapımı bir Python döngüsü kullananlar için not: framework parametreleri değişir, ama altı örüntü değişmez. Tekilleştirme, aralık özetleme, şema doğrulama, kısıtlama farkındalıklı sıkıştırma, checkpoint ve global devre kesici, framework'ten bağımsız kavramlardır. Buradaki LangGraph ve n8n özelliklerini somut tutamaklar olarak düşünün, bu örüntülerin geçerli olduğu sınır olarak değil.

Üretim Ajan Dağıtımını Boyutlandırma

Yukarıdaki her örüntü, süreç yöneticisini, veritabanını ve yeniden başlatma davranışını kontrol ettiğinizi varsayar. Çökmüş bir döngü hiç geri gelmiyorsa checkpoint almanın hiçbir faydası yoktur ve global devre kesicinin paylaşılan durumunu tutacak bir yere ihtiyacı vardır. Bu kontrol tam olarak self-hosting'in size verdiği ve yönetilen kara kutunun vermediği şeydir. Dolayısıyla son karar, bunu 7/24 çalıştıran kutuyu boyutlandırmaktır.

Çoğu tek ajan dağıtımı için (bir ajan, harici API'ye giden LLM çağrıları, temel Postgres checkpoint) küçük bir örnek yeterlidir: yaklaşık 2 GB RAM, 1 vCPU, and 60 GB of NVMe storage. Ağır hesaplama model sağlayıcısı tarafında yaşar; sizin kutunuz çıkarım değil, orkestrasyon, checkpoint ve durum tutma işi yapar. Ajan durumlu ve çok adımlı, Postgres checkpoint artı oturum rehydration için Redis kullanıyorsa ya da aynı konağı paylaşan eşzamanlı iş akışları çalıştırıyorsanız yaklaşık 4 GB RAM, 2 vCPU, and 120 GB NVMe 'a geçin.

Bunun kısıtlı bir platform yerine self-managed VPS istedirmesinin nedeni, düzeltmelerin çalışmasının nedeniyle aynıdır: root gerektirir. Checkpoint için kendi Postgres'iniz, oturum durumu için kendi Redis'iniz ve gerçek bir süreç yöneticisi (örneğin systemd or pm2) gerekir; böylece bir döngü öldüğünde supervisor onu yeniden başlatır ve işi baştan başlatmak yerine son checkpoint'inden rehydrate eder. Tüm bu kurtarma senaryosu, süreç yaşam döngüsüne sahip olmaya bağlıdır.

Kendi marketplace'imizde n8n'i tek tıklama uygulaması olarak çalıştırdığımız için kurulumun bu kısmı kendi tarafımızda en kısa yoldur: Cloudzy VPS'te n8n'i dağıtabilirsiniz üretim yolunun ihtiyaç duyduğu Postgres destekli yapılandırmayla birlikte; kendi Redis ve süreç denetlemenizi eklemek için root erişiminizin olduğu bir örnekte. Bu, yukarıda açıklanan self-hosted ayak iziyle aynıdır; veritabanına ve yeniden başlatma davranışına sahip olursunuz ki bu checkpoint ve otomatik kurtarmayı gerçekten işlevsel kılan şeydir.

Koşum takımı örüntüleri yalnızca üzerinde çalıştıkları kutu kadar güvenilirdir. Süreç hiç yeniden başlamıyorsa checkpoint almanın faydası yoktur.

Sıkça Sorulan Sorular