Microsoft Agent Framework v1.0: Lokal’den Prod’a Geçiş
Geçen hafta İstanbul’da bir bankacılık müşterimle toplantıdaydık. Adam masaya bir liste koydu: “Aşkın, sende altı tane farklı ajan framework’ü var ortada. Semantic Kernel mi kullanayım, AutoGen mi? Hangisini seçersem üç yıl sonra pişman olmam?” Açık konuşayım, o gün net bir cevap veremedim (evet, doğru duydunuz). Çünkü işin içi gerçekten karışıktı.
Bakın, Şimdi tablo biraz değişti. Microsoft, geçen ekim ayında duyurduğu Microsoft Agent Framework‘ün v1.0 sürümünü yayınladı. Yanına da Foundry Toolkit’in genel kullanıma açılması, Foundry Agent Service’te hosted agents. Memory önizlemeleri, observability’nın GA olması gibi bir sürü haber geldi. Bana sorarsanız bu paket — yanı lokal makinede başlayıp prod’a çıkana kadarki yol — sonunda tek parça gibi durmaya başladı.
Açık konuşayım, Bu yazıda hem yeni gelenleri anlatacağım hem de kendi notlarımı paylaşacağım. Çünkü dokümantasyondan okuyup geçmek başka şey, gerçek projede uygulamak bambaşka.
Önce Şunu Netleştirelim: Neden v1.0 Önemli?
Microsoft tarafında ajan geliştirme tarihçesini kısaca hatırlayalım. Önce Semantic Kernel (belki yanılıyorum ama) vardı; kurumsal tarafta sağlamdı ama daha çok tek ajan kafasındaydı. Sonra AutoGen çıktı, çok ajanlı orkestrasyon tarafında bayağı yaratıcı işler yaptı ama production’a taşımak açıkçası daha yorucuydu. Geliştirici olarak hep iki ayrı dünya arasında seçim yapıyordunuz.
İşte v1.0 bu ikilemi azaltıyor. Microsoft Agent Framework, Semantic Kernel’in kurumsal temelleri ile AutoGen’in çok ajan orkestrasyon yeteneklerini aynı çatı altında topluyor. Hem Python hem.NET için stable durumda. Ben şahsen.NET tarafını daha çok kullanıyorum; eğer sız de bu taraftaysanız
Adım 2: Composition — Birden Fazla Ajanı Birleştirmek
Tek ajan kolaydır.
İki ajan idare eder.
Beş ajan? Orası başka hikâye.
Agent Framework’ün Workflows özelliği burada devreye giriyor.
Hem programatik (kod yazarak) hem de deklaratif (YAML benzeri) tanımlama yapabiliyorsunuz.
Geçen yıl bir telekom müşterisinde dört farklı ajanı yan yana getirdiğimiz bir senaryo vardı; biri müşteri sorgusunu anlıyor, biri CRM’den veri çekiyor, biri çözüm öneriyor, biri de özetleyip kapatıyordu.
Workflows ile bu akışı tanımlamak yarım gün sürdü.
Eskiden olsa kendi orchestrator’umuzu yazıp bunu toparlamak için 1-2 hafta giderdi.
Neyse uzatmayayım, fark bayağı netti.
Ayrıca Durable Workflows ile Microsoft Agent Framework: Gerçek Hayatta Ne İşe Yarıyor? tarafı var ki uzun süre çalışan ajan işleri için can alıcı sayılır.
Saatlerce çalışacak bir zinciri fault-tolerant yapmak istiyorsanız Durable entegrasyonuna mutlaka bakın; yoksa ilk kesintide moral bozuluyor.
MCP ve A2A — Açık Standartlar Neden Önemli?
Tuhaf ama, Bunu açık söyleyeyim: Vendor lock-in bana her zaman tedirginlik veriyor. MCP (Model Context Protocol) ve A2A (Agent-to-Agent) protokollerinin kutudan çıkar çıkmaz desteklenmesi beni rahatlatan en önemli detaylardan biri öldü. Yanı Claude’un bir MCP server’ını alıp Agent Framework’e bağlayabiliyorsunuz ya da A2A uyumlu üçüncü parti bir ajanı workflow’unuza sokabiliyorsunuz..NET tarafında MCP yönetimini merak edenlere MCP Tool Çağrılarını .NET’te Yönetmek: AGT ile Pratik Yol yazımı tavsiye ederim.
Adım 3: Production — Foundry Agent Service’e Deploy
Bak şimdi, Lokal ortamda çalıştırmak güzel tabiî ama gerçek iş prod’a çıktığınızda başlıyor.
Burada üç şey can alıcı geliyor bana: hosting, memory. Observability.
Peki neden?
Çünkü bunlardan biri eksik olunca sistem kağıt üzerinde iyi görünse bile sahada tökezliyor.
Kısacası mesele sadece agent yazmak değil;
Bunu biraz açayım.
Sıkça Sorulan Sorular
Mevcut Semantic Kernel projemi Agent Framework’e taşımak zor mu?
Bence, Basit, tek ajanlı projelerde yarım gün falan yeterli oluyor. Migration guide’lar aslında oldukça anlaşılır. Ama hani çok sayıda custom plugin yazdıysanız, işim değişiklikleri ve namespace güncellemeleri biraz baş ağrıtabiliyor. Bence plan yaparken bir haftalık sprint ayırın — rahat rahat geçer.
Foundry Hosted Agents mı, kendi container’ım mı?
Tuhaf ama, Küçük ekipseniz ve hızlı ilerlemek istiyorsanız hosted gidin. Yönetim derdi yok, işte bu kadar basit. Ama kurumsal yapıdaysanız — yanı data residency, network izolasyon gibi sıkı gereksinimleriniz varsa — kendi AKS cluster’ınızda çalıştırmak hâlâ çok daha fazla kontrol veriyor (en azından benim deneyimim böyle). Açıkçası ikisi arasında güzel bir orta yol da var: hosted + Private Endpoint kombinasyonu mesela.
Memory önizlemede, prod’da kullansam olur mu?
Önizleme olduğu için kilit iş yüklerinde dikkatli olmak gerekiyor. Ben mesela non-critical senaryolarda kullanıyorum ama kritik conversation state için hâlâ kendi Cosmos DB tabanlı çözümümü tercih ediyorum. GA olduğunda muhtemelen tamamen geçeceğim — şimdilik bekle-gör modundayım.
MCP ve A2A standartları gerçekten yaygınlaşacak mı?
Bence büyük ihtimalle yaygınlaşacak. Anthropic’in MCP’yi açması, Microsoft’un birinci sınıf destek vermesi, bir de Google tarafının yaklaşıyor olması… Bunlar boşuna değil. Yeni bir ajan tasarlıyorsanız bu protokolleri kullanmamak için gerçekten hiçbir sebep yok. Hatta kullanmamak ileride ciddi bir teknik borç olarak geri dönecek — bu konuda oldukça eminim.
Hangi dil daha olgun — Python mı,.NET mi?
Python tarafı topluluk olarak biraz daha aktif, örnekler de daha böl..NET tarafı işe enterprise senaryolar için daha stabil ve type safety açısından açıkçası üstün. Mevcut stack’ınız zaten.NET işe zorlamaya hiç gerek yok —.NET sürümü gayet yeterli, tecrübeme göre sorun çıkarmıyor.
Kaynaklar ve İleri Okuma
Orijinal Microsoft Foundry Dev Blog Yazısı
Microsoft Agent Framework Resmî Dokümantasyonu
Microsoft Agent Framework GitHub Repository
Azure AI Foundry Dokümantasyonu
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.
4 comments