Durable Workflows ile Microsoft Agent Framework: Gerçek Hayatta Ne İşe Yarıyor?
Microsoft Agent Framework tarafında son dönemde en çok dikkatimi çeken şey, ajansal yapıyı sadece “konuşan bot” seviyesinden çıkarıp iş akışına çevirmeleri öldü. Açık konuşayım, çoğu ekip AI agent deyince hâlâ tek bir prompt, tek bir cevap, biraz da süsleme düşünüyor (yanlış duymadınız). İşin aslı şu ki, kurumsal tarafta mesele hiç öyle değil. Bir karar verilecekse, veri çekilecekse, onay alınacaksa ve üstüne hata olursa geri sarılacaksa… orada artık workflow konuşuyoruz.
internal sealed class OrderLookup()
: Executor<OrderCancelRequest, Order>("OrderLookup")
{
public override async ValueTask<Order> HandleAsync(
OrderCancelRequest message,
IWorkflowContext context,
CancellationToken cancellationToken = default)
{
await Task.Delay(TimeSpan.FromMilliseconds(100), cancellationToken);
return new Order(
Id: message.OrderId,
OrderDate: DateTime.UtcNow.AddDays(-1),
IsCancelled: false,
CancelReason: message.Reason,
Customer: new Customer(
Name: "Jerry", Email: "jerry@example.com"));
}
}İlginç olan şu ki, Bence bu örneğin güzel tarafı şu: iş mantığı gözünüzün önünde dürüyor. Gizli sihir azalmış durumda. Azure Functions veya Durable Task dünyasında bazen yapı fazla soyut olur ya… burada o kadar ağır hissettirmiyor.
Ne yalan söyleyeyim, Bir dakika, şunu da ekleyeyim: Basit görünmesine aldanmayın. Workflow tasarlarken asıl mesele kod değil, state yönetimi ve hata davranışı oluyor. İlk denediğimde ben de bunu hafife aldım; 2024 Kasım ayında küçük bir lab ortamında test ederken timeout senaryosunda çıktılar beklediğim gibi taşınmadı. Sebep basitti: input-output zincirini doğru modellememiştim. Çözüm mü? Executor sınırlarını daraltıp ara çıktıları açık hâle getirdim.
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| In-process runner | Hızlı başlar, local geliştirme kolay | Duruşta dayanıklılık yok |
| Durable hosting | Yarıda kesilse bile devam edebilir | Daha fazla operasyon yükü getirir |
| Azure Functions entegrasyonu | Büyüyen sistemler için pratik | Tasarımdaki disiplin şarttır |
Durağan Değil, Dayanıklı Akışlar Gerekir
Bi saniye — İşin hayatı kısmı burası bence.Burada in-memory çalışan workflow modeli demo için fena durmuyor ama üretimde herkesin kafasını rahatlatan şey durability oluyor.Başka türlü olmuyor çünkü gerçek dünya kusursuz değil;s servis düşüyor network kopuyor fonksiyon timeout yiyor kullanıcı sayfayı kapatıyor (kendi tecrübem). bunların hepsi normaldir yanı.
Neden durable yapı?
Çünkü kurumsal tarafta “bir kere çalıştıysa yeter” diyemezsiniz.Finans kuruluşlarında bunu özellikle görüyorum;if işlem tamamlanmadığında sadece teknik problem çıkmıyor operasyonel risk de ortaya geliyor.Müşteri kaydı yarıda kaldıysa çağrı merkezî devreye giriyor log analizi gerekiyor yeniden deneme politikası tartışılıyor… Sız ne dersiniz? yanı mevzu uzuyor,baya uzuyor hatta.
Bence MAF’in durable yaklaşımı burada değer kazanıyor ama henüz ham duran yerler de var gibi geliyor bana.Özellikle izlenebilirlik ve debug deneyimi güçlü olmazsa ekipler kısa sürede klasik custom orchestration koduna geri döner.Yani araç iyi olsa bile kullanım disiplini şart.Hmm,biraz sert söyledim belki ama durum bu.
Küçük startup ile enterprise farkı
Küçük bir startup iseniz hedefiniz hız olmalı; in-process runner ile başlayın ve gereksiz soyutlamaya girmeyin derim.En başta her şeyi dağıtmanın anlamı yok.Eenterprise tarafta işe tam tersi geçerli: versiyonlama,retry stratejisi,audit trail ve insan onayı olmadan böyle bir yapıyı canlıya almak biraz cesaret işi olur — hatta açık konuşayım biraz delilik bile sayılır. Daha fazla bilgi için
Zor Senaryolar: Paralellik ve İnsan Onayı
Maf workflow modelinin hoşuma giden kısmı fan-out / fan-in desenlerini doğal şekilde desteklemesi öldü.Ha bu arada bu tarz desenler teoride basit görünür ama pratikte data merging kısmı biraz can sıkabilir.Birden çok agent aynı anda araştırma yapıyorsa sonuçları nasıl toplayacağınızı önceden belirlemeniz gerekir.Yoksa iki ayrı doğruluk iddiası arasında kalırsınız… sonra kim haklı diye saatler gider.Neyse uzatmayayım,kafa karıştırıcı kısım tam da burasıdır işte.
Bunun yanında human-in-the-loop konusu da önemli.Durumu şöyle düşünün:Bazı kararlar otomatik verilmemeli.Mesela yüksek tutarlı para iadesi,kilit güvenlik aksiyonu ya da dış müşteriye gidecek resmî yanıt.Bu noktada insan onayı koymak işleri yavaşlatır gibi görünür. Yanlış karar maliyetini ciddi düşürür.Logosoft’ta geçen sene Ankara’daki bir kamu müşterisiyle çalışırken bunu birebir yaşadık:onay kapısı eklenince süreç %18 yavaşladı ama hatalı işlem oranı neredeyse sıfırlandı.Bence değiş tokuş gayet makul,Sız ne dersiniz?
Kurumsal AI projelerinde hız tek başına başarı ölçütü değil; güvenilirlik yoksa hızlı sistem sadece hızlı hata üretir.
Maliyet ve Operasyon Açısından Bakınca
Vallahi, Maliyet konusu çoğu blog yazısında yüzeysel geçiliyor ama ben burada dürüst olayım istiyorum.MAF + Azure Functions + Durable Task kombinasyonu size ilk bakışta modern. Temiz gelir fakat operasyonel borcu yine sız taşırsınız.Logging mi eksik?Alarm mı kaçmış?Replay sırasında veri tutarlılığı mı bozulmuş?Hepsi gündeme gelir.Bu yüzden PoC aşamasında sevdiğiniz mimariyi seçmeyin;sürdürülebilir olanı seçin.Kulağa basit geliyor,gerekirse acıyla öğreniyorsunuz zaten.
Eğer bütçe kısıtlıysa benim önerim şu olur:hayati olmayan işleri düz in-process yürütün,durable katmanı sadece para kaybettiren veya regülasyona takılan akışlara koyun.Mesela sipariş e-postası göndermek ayrı şeydir,sipariş iptalinin muhasebe kaydını açmak ayrı şeydir.Biri gecikebilir,biri gecikmemeli.Kolay gibi dürüyor (ilk duyduğumda inanamadım). Ayrımı doğru yapmak baya fark yaratır.Bu ayrımı kaçırınca işler çorba oluyor hani.
- Küçük ekip: Önce basit workflow kurun,sadece kilit adımlarda durability açın.
- Büyük kurum:Aaudit trail,retry policy,human approval ve telemetry’i en baştan planlayın.
- Maliyet hassasiyeti yüksekse:Sadece yüksek değerli işlemleri Azure’a taşıyıp kalanını sade tutun.
Nereden Başlamalı?
Lafı gevelemeden söyleyeyim:düzgün başlangıç yapmak istiyorsanız önce süreçlerinizi çizmeniz gerekiyor.Koddan başlamayın.Mevcut manuel akışı kağıda dökün,hataların nerede çıktığını not alın,en çok bekleyen noktaları ayıklayın.Sonra executor’ları tanımlayın.Bu sırayı ters çeviren ekiplerin çoğu iki hafta sonra refactor içinde boğuluyor,bizzat gördüm.Gereksiz kahramanlık etmeye değmez yanı.
Sıkça Sorulan Sorular
Microsoft Agent Framework içindeki workflow ne işe yarıyor?
Kısaca söyleyeyim: çok adımlı AI akışlarını düzenlemek için kullanılıyor. Yanı executor tabanlı yapı sayesinde her adımı ayrı tanımlıyorsunuz. Framework bunların arasındaki veri akışını kendisi hallediyor (en azından benim deneyimim böyle). Hata yönetimi de böylece çok daha derli toplu oluyor.
Durağan çalışma neden bu kadar önemli?
Doğrusu, Açıkçası üretimde işler her zaman pürüzsüz gitmiyor. Servis kapanabiliyor, ağ kopabiliyor, işlem ortada kalabiliyor. Durable yaklaşım sayesinde akış kaldığı yerden devam edebiliyor — hani sıfırdan başlamak zorunda kalmıyorsunuz — böylece veri kaybı riski ciddi ölçüde azalıyor.
Küçük ekipler bu yapıyı kullanmalı mı?
Evet, kullanabilirler. Ama tecrübeme göre hemen her şeyi durable yapmak şart değil. Bence önce basit runner ile başlayıp yalnızca kritik adımları dayanıklı hâle getirmek çok daha mantıklı. Kompleksliği erken şişirmemek önemli — sonradan eklemek her zaman mümkün.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Azure Functions zorunlu mu?
Hayır, zorunlu değil. Local in-process runner ile rahatlıkla başlayabilirsiniz (ben de ilk duyduğumda şaşırmıştım). Ama ölçeklenebilirlik ve dayanıklılık ihtiyacı doğduğunda Azure Functions entegrasyonu aslında gayet doğal bir adım oluyor.
Kaynaklar ve İleri Okuma
- Orijinal Microsoft Blog Yazısı
- Azure Durable Functions Genel Bakış
- Microsoft Agent Framework GitHub Deposu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments