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 Microsoft Agent Framework ile.NET’te Ajan Kurmanın İncelikleri yazıma bakın, orada daha detaylı anlattım.
Peki neden?
Mevcut Semantic Kernel veya AutoGen kullanıcıları için Microsoft migration guide’lar yayınladı. İlk projemi geçirirken yarım gün uğraştım; sandığım kadar acı değildi açıkçası. Ama her şey pürüzsüz aktı diyemem — özellikle plugin tarafında bazı işim değişiklikleri var, ona dikkat edin (şaşırtıcı ama gerçek)
v1.0 ile gelen kilit şeyler
- Çoklu model desteği — Azure OpenAI yanında Anthropic, Google Gemini, Amazon Bedrock ve Ollama geliyor. Yanı vendor lock-in derdi biraz hafifliyor.
- Workflows — Hem programatik hem deklaratif çok adımlı pipeline’lar var. DevUI’da görsel export bile alabiliyorsunuz.
- Foundry entegrasyonu — Memory, hosted agents, observability ve Foundry Tools artık kenarda köşede değil.
- Açık standartlar — MCP, A2A ve OpenAPI kutudan çıkar çıkmaz hazır geliyor.
Bence doğru yönde atılmış bir adım, ama hâlâ eksik kalan yerler var. Mesela bazı edge case’lerde Python ve.NET API’leri arasında küçük farklar gördüm; production’a geçmeden önce hangi dilde kalacaksanız onunla POC yapmak daha akıllıca.
Adım 1: Lokal Geliştirme — Foundry Toolkit for VS Code
Her ajan bir geliştiricinin makinesinde başlıyor zaten. Eskiden “AI Toolkit for VS Code” diye bildiğimiz uzantı şimdi Foundry Toolkit olarak GA’ya geçti; adı değişti ama içerik bayağı büyümüş durumda.
Ben prototipleri çoğunlukla VS Code’da kurmayı seviyorum. Sebebi basit: trace’leri görsel olarak inceleyebiliyorum, Copilot ile template’leri hızlıca üretebiliyorum ve deploy etmek için terminalde on beş komut koşturmak zorunda kalmıyorum (evet bazen insanın canını sıkıyor) (eh, fena değil). Geçen ay bir lojistik müşterisi için yaptığımız sipariş takip ajanını tamamen VS Code içinde yazıp deploy ettik; portal’a hiç girmedik bile ve bu bayağı zaman kazandırdı.
Kısa bir not düşeyim buraya.
Küçük bir örnek vereyim; Python tarafında başlangıç şöyle görünüyor: Bu konuyla ilgili Least Privilege Ajanlar: Güvenliği Baştan Kurmanın Yeni Yolu yazımıza da göz atmanızı tavsiye ederim.
import asyncio
from agent_framework.azure import AzureOpenAIResponsesClient
from azure.identity import AzureCliCredential
async def main():
agent = AzureOpenAIResponsesClient(
credential=AzureCliCredential(),
).as_agent(
name="DestekTriajBot",
instructions="Sen destek bileti önceliklendirmede uzman bir ajansın.",
)
response = await agent.run(
"Şu bileti analiz et ve öncelik seviyesini belirle."
)
print(response.text)
asyncio.run(main())Gördüğünüz gibi boilerplate neredeyse yok denecek kadar az. İlk denediğimde “bu kadar basit olamaz” dedim; hani insan ister istemez tuzak arıyor ya… Ama gerçekten bu kadar kolay başlıyor işte. Tabiî production’a gidince tablo biraz değişiyor; oraya da geleceğiz. Bu konuyla ilgili Foundry Toolboxes: Ajan Araçlarını Toplamak Neden Şart Oldu? yazımıza da göz atmanızı tavsiye ederim.
Türkiye perspektifinden bir parantez
Logosoft’ta danışmanlık verdiğim müşterilerin önemli kısmı Azure OpenAI’ı West Europe veya Sweden Central’dan kullanıyor. Lokal geliştirme yaparken latency hissediliyor; özellikle multi-agent senaryolarda her tool çağrısına 200-400ms ek gelebiliyor (küçük gibi dürüyor ama üst üste binince can sıkıyor). Eğer küçük bir ekipseniz ve hızlı iterasyon istiyorsanız lokal testlerde Ollama ile model çalıştırıp prod’a Azure OpenAI ile çıkmanızı öneririm; Agent Framework ikisini de aynı interface üzerinden desteklediği için kodu değiştirmek gerekmiyor. C++ Kodunu CLI’da Anlamak: Copilot’a Gelen Akıllı Katman yazımızda bu konuya da değinmiştik.
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. Bu konuyla ilgili SkiaSharp 4.0 Preview 1: 10 Yıl Sonra Büyük Atılım Geldi yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Foundry Hosted Agents ile MAF’ı Prod’a Taşımak: Benim Notlarım yazımıza da göz atmanızı tavsiye ederim.
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder