Üç LangGraph Yeniden Yazımı: Durumsal Ajanların Üretimdeki Gerçek Maliyeti

LangGraph ile durumsal kontrol noktaları (stateful checkpointing) kurumsal düzeyde dayanıklı ve kesintisiz yürütme vaat eder. Ancak Telegram ve WhatsApp gibi yüksek trafikli canlı üretim ortamlarında bu mekanizma, sessizce gerçekleşen hata modları nedeniyle büyük veri kayıplarına yol açabilir. İşte bu süreçte yaşanan üç büyük mimari yeniden yazım deneyimi ve pratik geliştirici çıkarımları:

1. Yeniden Yazım: Her Şeyi Yutan Durum Şeması

İlk sürümde TypedDict kullanıldı ancak eşzamanlı yük altında veri kayıpları yaşandı. Çalışma zamanında şema doğrulaması yapılmadığından, basit bir yazım hatası (typo) verilerin sessizce kaybolmasına yol açtı.

Pydantic Geçişi: TypedDict yerine extra="forbid" parametreli katı Pydantic modeline geçildi.
Açık Reducer'lar: Birikimli alanlar için varsayılan üzerine yazma yerine Annotated[list, operator.add] gibi açık reducer'lar tanımlandı.
Doğrulama Düğümü: Akış sonuna durum doğruluk kontrolü (invariant assertions) gerçekleştiren özel bir düğüm eklendi. Öğrenme: Çalışma zamanında statik tip belirteçlerine asla güvenmeyin. Pydantic ile katı dinamik şema doğrulaması yapmak, sessizce yutulan hataları engellemek için kritiktir.

2. Yeniden Yazım: Kontrol Noktası Bozulması

Varsayılan SQLite kontrol noktası eşzamanlı yazmalarda kilitlendi (database is locked) ve beklenmedik OOM çökmeleri yarım yazılmış bozuk durumlara yol açtı.

PostgresSaver Geçişi: Satır düzeyinde kilitleme (row-level locking) için SQLite yerine Postgres'e geçildi.
İdempotent Tasarım: API çağrısı yapan tüm harici düğümler, mükerrer işlemleri önlemek adına durum tabanlı dedup anahtarlarıyla idempotent yapıldı.
Tutarlılık Kontrolü: Kaldığı yerden devam etmeden önce durum bütünlüğü dinamik olarak doğrulandı. Öğrenme: Üretim ortamında asla SQLite kullanmayın. Kontrol noktası kaydı ile harici yan etkilerin atomik olarak gerçekleşmediğini bilerek tasarımı idempotent kurgulayın.

Yönlendirme Problemi: Kontrol Noktalarının Durumu Kötüleştirmesi

Model yönlendirme kararları gibi dinamik mantıklar kontrol noktasına yazıldığında eski kod mantığı donar ve maliyetleri artırır. Öğrenme: Kararın sonucunu değil, kararı tetikleyen girdileri saklayıp düğüm içinde dinamik olarak yeniden hesaplayın.

3. Yeniden Yazım: Sonunda İşe Yarayan Şablon

Durum bütünlüğünü korumak için şu üç kural uygulandı:

Tek Yan Etki: Her düğüm en fazla bir harici etki (API çağrısı, DB kaydı vb.) barındırır.
Önce Dedup: Yan etkiler tetiklenmeden önce durumdan dedup kontrolü yapılır.
Sıkı Doğrulama: Giriş, çıkış ve devam anlarında Pydantic şema doğrulaması zorunlu kılındı. Öğrenme: Karmaşık akışları küçük ve bağımsız düğümlere bölmek hata yönetimini ve kurtarmayı son derece kolaylaştırır.

Bugün Başlayacaklara Tavsiyeler

SQLite yerine doğrudan PostgresSaver kullanın.
TypedDict yerine strict modda Pydantic modelleri tercih edin.
Kalıcı yürütmenin harici çağrıları mükerrer olmaktan korumadığını bilin.
Gelecekte değişebilecek dinamik kararları kontrol noktasına kaydetmeyin.

[Orijinal kaynağa buradan ulaşabilirsiniz.](https://dev.to/elenarevicheva/three-langgraph-rewrites-what-stateful-agents-actually-cost-in-production-25on)