Karanlık Kodu Çalıştırın: Agent'ınızın Error Handling'i Neden Hiç Çalışmadı ve Onu Bilerek Nasıl Çalıştırırsınız?

Bir Agent kod tabanında `except RateLimitError`, `finally: cleanup()` ya da 'RAG boş dönerse genel cevaba geç' gibi bloklar bolca bulunur. Bunların ortak özelliği, geliştirme sırasında neredeyse hiç çalışmamalarıdır. Laptop'ta API kotası dolmaz, tool subprocess'i OOM ile öldürülmez, disk dolmaz. Kod review'dan geçer, coverage raporunda kırmızı satır olarak kalır ve ilk kez üretimde, en kötü anda koşar.

Bu durumun bedeli ölçülmüş bir şey. Toronto Üniversitesi'nin OSDI 2014'te yayımlanan çalışması Cassandra, HBase, HDFS, MapReduce ve Redis'teki 198 kullanıcı raporlu hatayı inceledi ve felaket boyutundaki hataların yüzde 92'sinin ölümcül olmayan bir hatanın yanlış ele alınmasından doğduğunu buldu. Bunların yaklaşık üçte biri basit kalıplardı: hatayı yalnızca loglayan handler, içinde TODO kalmış catch bloğu, çok geniş bir exception yakalayıp sert bir aksiyon alan kod. Agent'lar bu tabloyu büyütür, çünkü bir istekte onlarca dış çağrı ve dolayısıyla onlarca hata yolu vardır.

Son on iki ayda Agent'lar için fault injection, genel kaos mühendisliğinin bir alt başlığı olmaktan çıkıp kendi araştırma ve araç alanına dönüştü. Ocak 2026'da yayımlanan ReliabilityBench, 1.280 epizotluk deneyde altyapı hataları arasında en büyük etkiyi rate limiting'in yaptığını raporladı. 7 Ağustos 2026'da arXiv'e konan ve ASE 2026'ya kabul edilen AgentChaos, LLM API yanıtındaki `content` ve `tool_calls` alanlarına altı tip hata enjekte etti; beş çok-Agent'lı sistemin hepsi bozuldu, pass@1 düşüşü 50 puana yaklaştı. En sağlam sistem olan AutoGen bile HumanEval'de yüzde 98,61'den 79,17'ye indi ve görev başına LLM çağrısı 1,72'den 7,3'e çıktı.

Araç tarafında küçük ve yeni açık kaynak projeler var: per-run CA ile HTTPS proxy ve eBPF kullanan faultkit Eylül 2026'daki v0.1.3 ile 14 senaryoya ulaştı; agentic-chaos çağrı noktasını saran bir Python kütüphanesi olarak tool ve handoff hataları ekledi. Klasik kaos tarafında Gremlin Ekim 2026'da deney üretimine AI eklediğini duyurdu. SDK'lar ise kendi katmanında hata yutmaya devam ediyor: Anthropic Python SDK'sı bağlantı hatası, 408, 409, 429 ve 5xx'i varsayılan olarak iki kez yeniden deniyor, varsayılan timeout 10 dakika.

Hata yolunu test etmenin en yaygın yolu mock'tur: `client.messages.create` yerine `RateLimitError` fırlatan bir sahte nesne koyarsınız, test geçer. Ama bu test yalnızca mock'un davranışını doğrular. Gerçek SDK'nın kendi retry döngüsünü, `retry-after` başlığını nasıl okuduğunu, streaming yanıt ortasında bağlantı koptuğunda hangi exception'ı fırlattığını hiç görmez. Mock'ta fırlattığınız exception tipi gerçekte hiç gelmeyebilir; handler'ınız yanlış tipi yakalıyor olabilir.

Kubernetes seviyesindeki kaos araçları ise ters yönden ıskalar. Pod öldürmek, ağ gecikmesi eklemek ya da node düşürmek altyapının dayanıklılığını ölçer, ama Agent'ın karşılaştığı tipik hata pod ölümü değildir. Agent'ın hatası sağlayıcının döndürdüğü 429, yarıda kesilen bir SSE akışı, şeması bozuk bir `tool_calls` JSON'u ya da MCP stdio sunucusunun sessizce ölmesidir. Bunlar uygulamanın HTTP, stdio ve syscall katmanlarında oluşur; pod ölümü bu hataların hiçbirini doğru biçimde üretmez. Doğru test, hatayı gerçek SDK'nın göreceği biçimde, gerçek bağlantı üzerinden üretmelidir.

Agent hatalarını düşünmek için dağıtık sistemlerin güvenilirlik teorisinden gelen basit bir sınıflandırma iş görüyor. Crash hataları sistemin açıkça hata verdiği durumlardır: HTTP 5xx, 429, timeout. Omission hataları yanıtın eksik gelmesidir: boş `content`, yarıda kesilmiş streaming yanıt. Value hataları ise en sinsi olanlardır: yanıt geliyor, biçimi geçerli JSON, ama alan adı yanlış ya da değer bozuk.

Bu sınıflar tespit zorluğu bakımından çok farklıdır. AgentChaos verisine dayanan bir derlemede kural tabanlı teşhis, boş yanıtı yaklaşık yüzde 97 oranında tanırken yarıda kesilmiş yanıtı yalnızca yüzde 4,3 oranında yakalayabildi; çünkü kesilmiş metin geçerli metin gibi görünür. Pratik sonuç: her LLM çağrısında `stop_reason` ve yanıt uzunluğunu loglayın, `max_tokens` ya da beklenmeyen bir durma nedeniyle biten yanıtı başarılı saymayın. Tool tarafında da aynı mantık geçerli: tool çıktısının şemasını doğrulamayan Agent, bozuk veriyi gerçek kabul edip bir sonraki adıma taşır ve hata zincirin üç adım ilerisinde, bambaşka bir yerde görünür.

Hatayı gerçek SDK'ya gerçek biçimde ulaştırmanın birkaç yolu var ve her birinin bedeli farklı. HTTPS proxy yaklaşımında test, her çalıştırma için geçici bir CA üretir, TLS'i sonlandırır ve sağlayıcının gerçek yanıtını yolda değiştirir: 429 sentezler, akışı belirli bir token sayısından sonra keser. SDK gerçek TLS bağlantısı üzerinden üretimdekiyle aynı byte'ları görür. Sınırları var: certificate pinning yapan istemciler yakalanmaz, HTTP/2 desteği araçtan araca değişir. `HTTPS_PROXY`'yi yok sayan istemciler için `OPENAI_BASE_URL` gibi base URL değişkenleriyle trafiği yönlendirmek ikinci bir yol.

Daha alt katmanda eBPF var. Kernel'deki kprobe'lara bağlanan bir program, `recvmsg` ya da `openat` gibi çağrıların dönüş değerini değiştirerek süreçe simüle değil gerçek bir `ECONNRESET` ya da `EACCES` verir. Bu yaklaşım Linux'a ve kernel'in error injection altyapısına (`CONFIG_BPF_KPROBE_OVERRIDE`) bağlıdır; Trail of Bits'in ebpfault aracı aynı fikrin genel amaçlı bir örneği. Üçüncü yol süreç içi sarmalamadır: AgentChaos `httpx.AsyncClient`'ı yamalar, agentic-chaos çağrı noktasını sarar. Kurulumu kolaydır ama SDK'nın altındaki taşıma katmanını atlar.

Fault injection testlerinin kendine özgü bir tuzağı var: test geçer, ama enjekte edilecek hata hiç tetiklenmemiştir. Proxy'yi yok sayan bir istemci, değişen bir endpoint adı ya da yanlış eşleşen bir kural hatayı devre dışı bırakır; Agent normal yoldan çalışır, test yeşil yanar. Ekip hata yolunun doğrulandığını sanır. Bu, kırmızı yanan bir testten daha tehlikelidir, çünkü yanlış bir güven üretir ve kimse ona bir daha bakmaz.

Çözüm, fault'un ateşlendiğini ayrı bir koşul olarak doğrulamaktır. faultkit bunu çıkış koduna gömüyor: 0 'hata altında geçti', 1 'hata bir bug buldu', 3 ise 'fault hiç ateşlenmedi, test o yolu çalıştırmadı' anlamına geliyor. AgentChaos da analizlerinde hatanın gerçekten tetiklenmediği görevleri sonuçlardan çıkarıyor. Hangi aracı kullanırsanız kullanın kural aynı: her senaryo için kaç kez enjeksiyon yapıldığını sayın ve sıfırsa testi başarısız sayın. CI'da 'fault fired: 0' satırı, 'tests passed' satırından daha önemli bir sinyaldir.

Hata altında 'Agent çökmedi' demek yetmez; neyin doğru davranış olduğunu baştan yazmak gerekir. İlk kontrol retry katmanlarıdır. SDK zaten iki kez yeniden deniyorsa ve siz üstüne üç denemelik bir döngü, orchestration katmanı da kendi retry'ını ekliyorsa, tek bir 429 sağlayıcıya on sekiz isteğe dönüşebilir. Bu, rate limit'i büyüten bir retry fırtınasıdır. Testte istek sayısını sayıp bir üst sınıra assert etmek bunu yakalar.

İkinci kontrol uydurmadır. Tool hata döndürdüğünde Agent ya hatayı kullanıcıya söylemeli ya da alternatif bir yol denemeli; olmayan veriyle cevap üretmemeli. Yedi adımlık bir planın dördüncü adımında gelen 429, Agent'ın baştan başlayıp ilk üç adımın yan etkilerini tekrarlamasına yol açmamalı; bu yüzden tool çağrıları idempotent olmalı. Üçüncü kontrol telemetridir: timeout, rate limit ve bağlantı hatası aynı `outcome=error` etiketiyle loglanıyorsa üretimde hangisinin yaşandığını ayıramazsınız. Hata sınıfını ayrı bir alanda tutmak, Trace'te hatanın kökünü bulmayı mümkün kılar.

Hata yolunu bilerek çalıştırmanın sürdürülebilir hali bir katalogdur. Başlangıç noktası geçmiş incident'lardır: sağlayıcının yoğunluk nedeniyle 529 döndürdüğü gün, MCP sunucusunun stdio'da takılı kaldığı deploy, vektör veritabanının boş sonuç döndüğü index yenilemesi. Her biri bir senaryoya dönüşür: hangi katmanda, hangi hata, planın hangi adımında, kaç kez.

Sıra şöyle işler: senaryoyu yazın, mevcut kodla testin kırmızı yandığını görün, en küçük guard'ı aynı Pull Request'te ekleyin, testin yeşile döndüğünü ve fault'un gerçekten ateşlendiğini doğrulayın. Bu senaryolar her PR'da değil, gece çalışan ayrı bir CI işinde koşabilir; çünkü gerçek sağlayıcıya giden testler hem maliyetli hem yavaştır. Kaos mühendisliğinin klasik ilkesi burada da geçerli: blast radius'u küçük tutun. Önce staging'de, tek bir senaryo ve tek bir sağlayıcıyla başlayın; üretim trafiğine enjeksiyon ancak geri alma mekanizması ve net bir durdurma eşiği olduğunda gündeme gelsin.