LangGraph mı CrewAI mı? Kurtarmada iş tekrarı riski

LangGraph ve CrewAI Flows, kesintiden dönerken tamamlanmış dış işlemleri yeniden çalıştırabilir: hata enjeksiyonlu bir ön baskı, LangGraph 1.2.9’da gerçek süreç ölümünden sonra, CrewAI 1.15.2’de ise sınanan Flow geri yükleme yollarında yan etkili işlerin tekrarlandığını gösterdi. Bu sonuç, her kurulumun aynı davranacağı anlamına gelmez; üretim seçimi, kullanılan saklama ve devam yoluna dayanmalıdır.

Durum geçişlerini düğüm düzeyinde görmek ve kurtarmada yeniden çalışabilecek alanı daraltmak isteyen ekip için LangGraph daha uygun bir başlangıçtır. Olaylarla ilerleyen bir Flow içinde mevcut CrewAI ajanlarını kullanan ekip CrewAI ile devam edebilir. İki durumda da ödeme alma veya kayıt oluşturma gibi dış işlemler için ayrı bir tekrar önleme düzeni gerekir: kaydedilmiş ajan durumu, hedef sistemde işlemin kaç kez gerçekleştiğini söylemez.

Aynı sipariş akışı iki mimaride

Koşullu bir sipariş akışı düşünün: uygunluğu değerlendir, insan onayını al, ödemeyi başlat ve sonucu bildir. LangGraph’ta bu aşamalar ortak durumu okuyan ve güncelleyen ayrı düğümler olabilir. LangGraph’ın Python tasarım rehberi, checkpoint’lerin düğüm sınırlarında oluştuğunu ve hata ya da kesintiden sonra çalışmanın durduğu düğümün başından başladığını açıklar. Ödeme ile bildirim aynı düğümdeyse, ödeme başarılı olduktan sonra gelen bir hata ikisini de yeniden çalıştırabilir. Ayrı düğümler tekrar edilecek işi daraltır, fakat ödeme çağrısıyla checkpoint yazımını tek bir işlem hâline getirmez.

CrewAI tarafında bu akışın karşılığı, yalnızca ajanlara rol dağıtan bir Crew değil, yöntemleri olaylarla bağlayan bir Flow’dur. CrewAI Flows belgeleri, @persist ile sınıfın tamamında veya seçili yöntemlerde durum saklanabildiğini ve varsayılan arka ucun yerel SQLite olduğunu anlatır. Belgelerde aynı kimlikle son durumun yüklenmesi ile restore_from_state_id kullanılarak yeni kimlikli bir dal açılması ayrı işlemlerdir. Durumun yüklenmesi, daha önce dış sisteme gönderilmiş çağrının yeniden yapılmayacağı garantisini vermez.

Durum kaydı dış işlemin kaydı değildir

LangGraph’ta yeni bir süreçten devam etmek için bellekte tutulan checkpoint yeterli değildir; kalıcı bir kayıt ve aynı iş parçacığı kimliği gerekir. Düğüm içindeki ödeme çağrısı başarılı olup süreç düğüm sonucunu kaydetmeden ölürse, geri dönüşte düğümün yeniden başlaması beklenir. Daha küçük düğümler bu aralığı küçültür; ödeme sağlayıcısının sonucuyla grafik durumunu atomik biçimde birleştirmez.

CrewAI’de @persist ile Flow durumunu saklamak ve CheckpointConfig ile yürütme anlık görüntüleri almak farklı yollardır. CrewAI checkpoint belgeleri, seçilen olay gerçekleştiğinde kayıt yazıldığını; otomatik yazma hatasında akışın devam edip hatanın günlüğe alınabildiğini belirtir. Dolayısıyla bir checkpoint ayarının bulunması tek başına yeterli bilgi değildir. Hangi olayın kaydı tetiklediği, kaydın oluşup oluşmadığı ve geri yükleme sırasında hangi yöntemin çağrıldığı ayrı ayrı önem taşır.

İki mimaride de kritik boşluk aynıdır: hedef sistem işlemi tamamlayabilir, ancak ajan bunu durumuna yazamadan durabilir. Tersi de mümkündür; ajan bir isteği gönderdiğini kaydederken hedef sistem henüz sonucu üretmemiş olabilir. Bu yüzden ödeme, bildirim veya yeni kayıt için son sözü akışın belleği değil, ilgili dış sistemin işlem kaydı söylemelidir.

Kesinti, insan onayı ve yinelenen teslim

Aşağıdaki olasılıklar aynı koşullu sipariş akışına uygulanır. Bunlar bütün yapılandırmalar için ölçülmüş ürün garantileri değil, adımların yerleşiminden çıkan kurtarma senaryolarıdır.

Normal çalışma: Uygunluk, onay, ödeme ve bildirim sırasıyla ilerler. Tek geçişte her adımın bir kez görünmesi, süreç öldüğünde veya aynı istek yeniden geldiğinde de öyle kalacağını göstermez.
Süreç ölümü: LangGraph, son kalıcı düğüm sınırından sonra yarım kalan düğümü yeniden çalıştırabilir. CrewAI Flow’da saklanan durum yüklenirken bir yöntemin tekrar tetiklenmesi mümkündür. Ödeme başarılı olduğu hâlde sonucu kaydetme fırsatı bulunamaması, iki tasarımda da dış işlemin sorgulanmasını gerektirir.
İnsan onayı: LangGraph’ta kesme noktasından devam ederken ilgili düğüm baştan çalışır; onay bekleme çağrısından önce aynı düğüme konan yan etki bu nedenle yeniden tetiklenebilir. CrewAI’de onay kararını saklamak da ödeme yöntemine kendiliğinden tek kullanım hakkı vermez. Karar ile dış işlem, ayrı kimliklerle izlenmelidir.
Yinelenen teslim: Aynı onay veya kuyruk işi iki yürütücüye ulaşırsa ikisi de dış çağrıya ilerleyebilir. Sıralı yeniden teslim ile eşzamanlı yürütme aynı hata modeli değildir; üretim kabulünde ikisi ayrı sınanmalıdır.

Özellikle insan onayında onaylanan şeyin kimliği açık olmalıdır: sipariş, tutar ve yapılacak işlem değişirse eski karar yeni çağrıya taşınmamalıdır. Onay kaydı, ödeme sonucuyla da karıştırılmamalıdır. İlki işlemi başlatma yetkisini, ikincisi hedef sistemde ne olduğunu anlatır.

Tekrar güvenliği nerede kurulmalı?

Dış işlem için yeniden denemelerde değişmeyen bir idempotency anahtarı kullanmak en temiz sınırdır. Anahtar, örneğin koşullu siparişte sipariş kimliği ile işlem türünden türetilebilir. Hedef API aynı anahtarla gelen isteği tek işlem olarak ele alıyorsa süreç ölümü sonrasında güvenle yeniden sorgulama veya deneme olanağı doğar. Bu davranışın gerçekten sağlanıp sağlanmadığı, kullanılan hedef API’nin sözleşmesine bağlıdır.

Her yan etkili adım için kalıcı iş kimliğini, hedef sistemi, istek kimliğini ve dönen işlem kimliğini saklayın.
«İstek gönderildi» ile «hedef sistem işlemi tamamladı» durumlarını ayırın. Zaman aşımında önce hedef sistemde aynı işlem kimliğini sorgulayın.
Aynı onay iki kez teslim edilirse yürütme hakkını atomik olarak tek çalışana verin. Yerel bir benzersiz kayıt, eşzamanlı başlatmayı engeller; dış sistemden sonuç alınmadan yaşanan ölümü tek başına çözmez.
Hedef API tekrar önlemeyi desteklemiyorsa sonucu bilinmeyen çağrıyı körlemesine yinelemek yerine dış kayıtla uzlaştırın; sonuç bulunamıyorsa işlemi inceleme için bekletin.

Bu düzen, checkpoint’in görevini ortadan kaldırmaz. Checkpoint ajanı uygun yerden yeniden çalıştırır; idempotency ve uzlaştırma ise aynı işin hedef sistemde ikinci kez gerçekleşmesini yönetir. Birini diğerinin yerine koymak, özellikle geri alınması zor işlemlerde yanlış güven oluşturur.

Ölçülen ek yük seçimi değiştirir mi?

Tacavar’ın Eylül 2026 ölçümünde tek araç çağrılı beşer tur için ortalama süre CrewAI 1.15.22’de 861 ms, LangGraph 1.2.12’de 943 ms; birer yeni süreçte soğuk açılış sırasıyla 4.441 ms ve 3.214 ms oldu. Ölçüm model API çağrısını da içeriyor ve süreç ölümünden kurtarma, kalıcı checkpoint yazımı veya yinelenen dış işlemi ölçmüyor. Bu küçük iş yükündeki süreler üretim ajanları için genel bir hız sıralaması kurmaya yetmez.

Seçimde anlamlı maliyet, aynı iş mantığı ve aynı kalıcılık düzeyinde ortaya çıkar: normal yürütme gecikmesi, checkpoint yazma süresi, kesintiden toparlanma süresi ve dış sistemde oluşan işlem sayısı birlikte değerlendirilmelidir. Daha sık kayıt, hata sonrasında tekrarlanan işi azaltabilir; her adımda yazma yükü de getirir. Dış işlem ikinci kez gerçekleşiyorsa kısa yanıt süresinin operasyonel değeri hızla düşer.

Durum geçmişini düğüm düzeyinde incelemek ve yan etkileri küçük adımlara ayırmak öncelikse LangGraph mantıklı seçimdir. Mevcut CrewAI ajanlarını olay tabanlı bir Flow içinde sürdürmek öncelikse CrewAI uygundur; bu seçimde @persist ile checkpoint üzerinden geri yükleme aynı davranış sayılmamalıdır. Her iki seçenek için belirleyici kabul koşulu, süreç ölümünden ve yinelenen teslimden sonra hedef sistemde tek dış işlem kaldığını gösterebilmektir.

Ayrıca okuyun: