Azure | The .NET Blog

Azure MCP Server Artık .mcpb — Herhangi Bir Runtime Olmadan Yükle

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

MCP sunucularını kurarken can sıkıcı olan ne olduğunu biliyor musunuz? Bir runtime gerekiyordu. npm sürümü için Node.js, pip/uvx için Python, dotnet varyantı için .NET SDK.

Azure MCP Server bunu değiştirdi. Artık .mcpb — MCP Bundle — olarak kullanılabilir ve kurulum sürükle-bıraktır.

MCP Bundle Nedir?

VS Code uzantısı (.vsix) veya tarayıcı uzantısı (.crx) gibi düşünün, ama MCP sunucuları için. .mcpb dosyası, sunucu ikilisini ve tüm bağımlılıklarını içeren bağımsız bir ZIP arşividir.

Nasıl Kurulur

1. Platformunuz için bundle’ı indirin

GitHub Releases sayfasına gidin ve OS ve mimarinize uygun .mcpb dosyasını indirin.

2. Claude Desktop’a kurun

En kolay yol: Uzantılar ayarları sayfasındayken (☰ → Dosya → Ayarlar → Uzantılar) .mcpb dosyasını Claude Desktop penceresine sürükleyip bırakın. Sunucu ayrıntılarını inceleyin, Yükle’ye tıklayın, onaylayın.

3. Azure’da kimlik doğrulaması yapın

az login

Başlamak için

İndirme: GitHub Releases
Depo: aka.ms/azmcp
Belgeler: aka.ms/azmcp/docs

Tam makaleye bakın.

GPT-5.5 Burada ve Azure Foundry'e Geliyor — .NET Geliştiricilerinin Bilmesi Gerekenler

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Microsoft, GPT-5.5’in Microsoft Foundry’de genel kullanıma sunulduğunu duyurdu. Azure’da agent oluşturuyorsanız, beklediğiniz güncelleme bu.

GPT-5 Evrimi

GPT-5: akıl yürütme ve hızı tek bir sistemde birleştirdi
GPT-5.4: daha güçlü çok adımlı akıl yürütme, enterprise için erken ajansal özellikler
GPT-5.5: daha derin uzun bağlam akıl yürütme, daha güvenilir ajansal yürütme, daha iyi token verimliliği

Gerçekte ne değişti

Geliştirilmiş ajansal kodlama: GPT-5.5, büyük kod tabanlarında bağlamı korur, mimari düzeydeki hataları teşhis eder ve test gereksinimlerini öngörür. Model, harekete geçmeden önce bir düzeltmenin başka neyi etkilediğini akıl yürütür.

Token verimliliği: Daha az token ve daha az yeniden denemeyle daha yüksek kaliteli çıktılar. Üretimde doğrudan düşük maliyet ve gecikme.

Fiyatlandırma

Model	Girdi ($/M token)	Önbelleğe alınmış	Çıktı ($/M token)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Foundry Neden Önemli

Foundry Agent Service, agentları YAML’de tanımlamanıza veya Microsoft Agent Framework, GitHub Copilot SDK, LangGraph ya da OpenAI Agents SDK ile bağlamanıza olanak tanır — ve bunları kalıcı dosya sistemi, Microsoft Entra kimliği ve sıfıra ölçekleme fiyatlandırmasıyla izole barındırılan agentlar olarak çalıştırır.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Yardımcı bir asistansınız.", name: "BenimAgentim");

Tüm ayrıntılar için tam duyuruya bakın.

Foundry Toolboxes: Tüm Ajan Araçları için Tek Bir Endpoint

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Bizzat yaşayana kadar önemsiz görünen bir sorun var: Kuruluş birden fazla yapay zeka ajanı oluşturuyor, her birinin araçlara ihtiyacı var ve her ekip sıfırdan yapılandırıyor. Aynı web arama entegrasyonu, aynı Azure AI Search yapılandırması, aynı GitHub MCP sunucusu bağlantısı — ama farklı bir depoda, farklı bir ekip tarafından, farklı kimlik bilgileriyle ve paylaşılan yönetim olmadan.

Microsoft Foundry, genel önizlemede Toolboxes yayımladı ve bu soruna doğrudan bir yanıt niteliğinde.

Toolbox nedir?

Toolbox, Foundry’de bir kez tanımlanıp tek bir MCP uyumlu endpoint üzerinden sunulan, adlandırılmış ve yeniden kullanılabilir bir araç paketidir. MCP konuşabilen herhangi bir ajan çalışma zamanı bunu tüketebilir — Foundry Agents’a bağımlılık yoktur.

Vaat basittir: build once, consume anywhere. Araçları tanımla, kimlik doğrulamayı merkezi olarak yapılandır (OAuth doğrudan geçiş, Entra yönetilen kimlik), endpoint’i yayımla. Bu araçlara ihtiyaç duyan her ajan endpoint’e bağlanır ve tümünü alır.

Dört sütun (bugün ikisi mevcut)

Sütun	Durum	Ne yapar
Discover	Yakında	Elle arama yapmadan onaylı araçları bulma
Build	Mevcut	Araçları yeniden kullanılabilir pakete gruplama
Consume	Mevcut	Tek MCP endpoint tüm araçları sunar
Govern	Yakında	Merkezi kimlik doğrulama + tüm araç çağrılarının gözlemlenebilirliği

Pratik örnek

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Dokümanlarda arama yap ve GitHub sorunlarına yanıt ver.",
 tools=[
 {"type": "web_search", "description": "Genel belgelerde arama yap"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Yayımlandıktan sonra Foundry birleşik bir endpoint sağlar. Tek bağlantı, tüm araçlar.

Foundry Agents’a bağımlılık yok

Toolboxes, Foundry’de oluşturulur ve yönetilir; ancak tüketim yüzeyi açık MCP protokolüdür. Bunları özel ajanlardan (Microsoft Agent Framework, LangGraph), GitHub Copilot ve diğer MCP destekli IDE’lerden kullanabilirsiniz.

Neden şimdi önemli?

Çoklu ajan dalgası üretime ulaşıyor. Her yeni ajan, yinelenen yapılandırma, eski kimlik bilgileri ve tutarsız davranış için yeni bir yüzeydir. Build + Consume temeli merkezileşmeye başlamak için yeterlidir. Govern sütunu geldiğinde, tüm ajan filosu için tam gözlemlenebilir ve merkezi olarak kontrol edilen bir araç katmanı elde edilmiş olacak.

Sonuç

Henüz erken — genel önizleme, önce Python SDK, Discover ve Govern henüz yolda. Ancak model sağlam ve MCP yerel tasarımı, zaten inşa ettiğiniz araçlarla çalıştığı anlamına geliyor. Ayrıntılar için resmi duyuruya bakın.

azd + GitHub Copilot: Yapay Zeka Destekli Proje Kurulumu ve Akıllı Hata Çözümü

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Mevcut bir uygulamayı Azure’a dağıtmak isteyip boş bir azure.yaml dosyasına bakarak Express API’nizin Container Apps mı yoksa App Service mi kullanması gerektiğini hatırlamaya çalıştığınız o anı biliyor musunuz? O an artık çok daha kısa.

Azure Developer CLI (azd) artık GitHub Copilot ile iki somut şekilde entegre: azd init sırasında AI destekli proje iskele kurma ve dağıtımlar başarısız olduğunda akıllı hata giderme. Her iki özellik de tamamen terminalde kalıyor.

azd init Sırasında Copilot ile Kurulum

azd init çalıştırıldığında artık “Set up with GitHub Copilot (Preview)” seçeneği görünüyor. Seçin ve Copilot, gerçek kodunuzu temel alarak azure.yaml, altyapı şablonları ve Bicep modülleri oluşturmak için kod tabanınızı analiz eder.

azd init
# Seçin: "Set up with GitHub Copilot (Preview)"

Gereksinimler:

azd 1.23.11 veya üzeri — azd version ile kontrol edin veya azd update ile güncelleyin
Aktif GitHub Copilot aboneliği (Bireysel, İş veya Kurumsal)
GitHub CLI (gh) — gerekirse azd oturum açmanızı isteyecek

Gerçekten faydalı bulduğum şey: her iki yönde de çalışıyor. Sıfırdan mı inşa ediyorsunuz? Copilot doğru Azure hizmetlerini başından itibaren yapılandırmanıza yardımcı olur. Dağıtmak istediğiniz mevcut bir uygulamanız mı var? Copilot’u ona yöneltin — kodu yeniden yapılandırmadan konfigürasyon oluşturulur.

Gerçekte Ne Yapar

PostgreSQL bağımlılığına sahip bir Node.js Express API’niz olduğunu varsayalım. Container Apps ile App Service arasında manuel seçim yapmak ve ardından sıfırdan Bicep yazmak yerine, Copilot yığınınızı algılar ve şunları oluşturur:

Doğru language, host ve build ayarlarına sahip azure.yaml
Azure Container Apps için Bicep modülü
Azure Database for PostgreSQL için Bicep modülü

Ve herhangi bir şeyi değiştirmeden önce ön kontroller yapar — git çalışma dizininin temiz olduğunu doğrular, MCP sunucu araç iznini önceden sorar. Her şey bilginiz dahilinde gerçekleşir.

Copilot ile Hata Giderme

Dağıtım hataları kaçınılmazdır. Eksik parametreler, izin sorunları, SKU kullanılabilirlik sorunları — ve hata mesajı nadiren gerçekten bilmeniz gereken tek şeyi söyler: nasıl düzeltilir.

Copilot olmadan döngü şöyle görünür: hatayı kopyala → belgelerden ara → ilgisiz üç Stack Overflow cevabı oku → birkaç az CLI komutu çalıştır → tekrar dene ve umut et. azd‘de Copilot ile bu döngü çöküyor. Herhangi bir azd komutu başarısız olduğunda anında dört seçenek sunuluyor:

Explain — ne yanlış gittiğinin anlaşılır dilde açıklaması
Guidance — sorunu gidermek için adım adım talimatlar
Diagnose and Guide — tam analiz + Copilot düzeltmeyi uygular (onayınızla) + isteğe bağlı yeniden deneme
Skip — kendiniz halledin

Kritik nokta: Copilot’un projeniz, başarısız olan komut ve hata detayları hakkında zaten bağlamı var. Önerileri sizin durumunuza özeldir.

Varsayılan Davranışı Ayarlama

Her zaman aynı seçeneği seçiyorsanız etkileşimli istemi atlayın:

azd config set copilot.errorHandling.category troubleshoot

Değerler: explain, guidance, troubleshoot, fix, skip. Otomatik düzeltme ve yeniden denemeyi de etkinleştirebilirsiniz:

azd config set copilot.errorHandling.fix allow

İstediğiniz zaman etkileşimli moda geri dönün:

azd config unset copilot.errorHandling.category

Sonuç

En son sürümü edinmek için azd update çalıştırın ve bir sonraki projenizde azd init deneyin.

Orijinal duyuruyu buradan okuyun.

Azure'daki AI Deneyimleriniz Para Yakıyor — İşte Bunu Düzeltmenin Yolu

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Şu an Azure üzerinde AI destekli uygulamalar geliştiriyorsanız, muhtemelen şunu fark etmişsinizdir: bulut faturanız eskisinden farklı görünüyor. Sadece daha yüksek değil — daha tuhaf. Ani sıçramalar yapıyor. Tahmin etmesi güç.

Microsoft, hâlâ geçerliliğini koruyan bulut maliyet optimizasyon ilkeleri üzerine harika bir yazı yayımladı ve dürüst olmak gerekirse, zamanlama daha iyi olamazdı. Çünkü AI iş yükleri, maliyetler söz konusu olduğunda oyunun kurallarını değiştirdi.

AI iş yükleri neden farklı hissettiriyor

Şöyle düşünün. Geleneksel .NET iş yükleri görece tahmin edilebilir. App Service katmanınızı bilirsiniz, SQL DTU’larınızı bilirsiniz, aylık harcamayı makul ölçüde doğru tahmin edebilirsiniz. AI iş yükleri? O kadar da değil.

Hangisinin uygun olduğunu görmek için birden fazla modeli test ediyorsunuz. İnce ayar için GPU destekli altyapı kuruyorsunuz. Prompt uzunluğuna ve kullanıcı davranışına göre token tüketiminin çılgınca değiştiği Azure OpenAI’ya API çağrıları yapıyorsunuz. Her deney gerçek para maliyeti içeriyor ve doğru yaklaşımı bulmadan önce düzinelerce deneme yapabiliyorsunuz.

Bu öngörülemezlik, maliyet optimizasyonunu kritik kılıyor — sonradan düşünülecek bir şey olarak değil, ilk günden itibaren.

Yönetim ile optimizasyon — farkı bilin

Makaledeki geliştiricilerin gözden kaçırdığını düşündüğüm bir ayrım var: maliyet yönetimi ile maliyet optimizasyonu arasında bir fark var.

Yönetim, takip etmek ve raporlamaktır. Azure Cost Management’ta bütçeler kurarsınız, uyarılar alırsınız, panolar görürsünüz. Bu temel gereksinimdir.

Optimizasyon, gerçek kararlar aldığınız yerdir. O S3 katmanına gerçekten ihtiyacınız var mı, yoksa S1 yükü kaldırır mı? O her zaman açık hesaplama örneği hafta sonları boşta mı oturuyor? Eğitim işleriniz için spot instance kullanabilir misiniz?

.NET geliştiricileri olarak koda odaklanma ve altyapı kararlarını “operasyon ekibine” bırakma eğilimindeyiz. Ama Azure’a dağıtıyorsanız, o kararlar sizin kararlarınızdır.

Gerçekten işe yarayan şeyler

Makaleye ve kendi deneyimlerime dayanarak, fark yaratan şeyler şunlar:

Ne harcadığınızı ve nerede harcadığınızı bilin. Kaynaklarınızı etiketleyin. Gerçekten. Hangi projenin ya da deneyin bütçenizi tükettiğini söyleyemiyorsanız hiçbir şeyi optimize edemezsiniz. Uygun etiketlemeyle Azure Cost Management en iyi dostunuzdur.

Deney yapmadan önce güvenlik sınırları koyun. Geliştirme/test ortamlarında pahalı SKU’ları kısıtlamak için Azure Policy kullanın. Azure OpenAI dağıtımlarınıza harcama limitleri belirleyin. Hafta sonu biri GPU kümesini çalışır durumda bırakmış diye fatura gelene kadar beklemeyin.

Sürekli boyutlandırın. Prototip aşamasında seçtiğiniz VM? Üretim için muhtemelen yanlış. Azure Advisor size öneriler sunuyor — gerçekten bakın. Yıllık değil, aylık olarak gözden geçirin.

Yaşam döngüsünü düşünün. Geliştirme kaynakları kapanabilmeli. Test ortamlarının 7/24 çalışması gerekmez. Otomatik kapatma politikaları kullanın. AI iş yükleri için özellikle, hesaplamayı sıcak tutmak yerine kullanım başına ödeme yaptığınız sunucusuz seçenekleri değerlendirin.

Maliyeti değil, değeri ölçün. Bunu unutmak kolay. Daha pahalı ama önemli ölçüde daha iyi sonuçlar veren bir model doğru seçim olabilir. Amaç en az harcamak değil — akıllıca harcamaktır.

Sonuç

Bulut maliyet optimizasyonu tek seferlik bir temizlik değildir. Bir alışkanlıktır. AI iş yükleri harcamayı her zamankinden daha az öngörülebilir hale getirirken, bu alışkanlığı erken edinmek sizi daha sonra acı sürprizlerden kurtarır.

Azure üzerinde geliştiren bir .NET geliştiricisiyseniz, bulut faturanıza kodunuza baktığınız gibi bakmaya başlayın — düzenli olarak gözden geçirin, karmaşıklaştığında yeniden yapılandırın ve ne kadara mal olacağını anlamadan asla dağıtmayın.

Foundry'nin RFT'si Daha Ucuz ve Daha Akıllı Hale Geldi — İşte Neler Değişti

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Fine-tune edilmiş modellere dayanan .NET uygulamaları geliştiriyorsanız, bu ayki Foundry güncellemeleri dikkat etmeye değer. Reinforcement Fine-Tuning daha erişilebilir ve önemli ölçüde daha ucuz hale geldi.

Tüm ayrıntılar resmi duyuruda mevcut, ancak işte pratik özet.

o4-mini için Global Eğitim

o4-mini, akıl yürütme ağırlıklı ve agentic iş yükleri için tercih edilen modeldir. Büyük haber: artık 13+ Azure bölgesinden fine-tuning işleri başlatabilirsiniz; Standart eğitime kıyasla daha düşük token başına eğitim maliyetiyle. Aynı altyapı, aynı kalite, daha geniş erişim.

Ekibiniz coğrafi olarak dağıtılmışsa bu önemlidir. Artık eğitim yapabilmek için birkaç bölgeyle sınırlı değilsiniz.

Global bir eğitim işi başlatmak için REST API çağrısı:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

trainingType: globalstandard bayrağı temel farktır.

Yeni Model Grader’lar: GPT-4.1 Ailesi

Grader’lar, modelinizin optimize ettiği ödül sinyalini tanımlar. Şimdiye kadar model tabanlı grader’lar daha küçük bir model setiyle sınırlıydı. Artık üç yeni seçenek var: GPT-4.1, GPT-4.1-mini ve GPT-4.1-nano.

Deterministik grader’lar yerine model grader’larına ne zaman başvurmalısınız? Görev çıktınız açık uçluysa, birden fazla boyutta kısmi puan almanız gerekiyorsa veya araç çağrısının doğruluğunun semantik bağlama bağlı olduğu agentic iş akışları oluşturuyorsanız.

Kademeli strateji pratik:

İlk iterasyonlar için GPT-4.1-nano. Düşük maliyet, hızlı geri bildirim döngüleri.
Grading rubric’iniz stabil olduğunda ve daha yüksek doğruluğa ihtiyaç duyduğunuzda GPT-4.1-mini.
Üretim grading’i veya her puanlama kararının önemli olduğu karmaşık rubric’ler için GPT-4.1.

Tek bir RFT işinde grader türlerini bile karıştırabilirsiniz. “Doğru cevap” boyutu için string eşleşmesi ve akıl yürütme kalitesini değerlendirmek için model grader kullanın. Bu esneklik, gerçek iş yükleri için kullanışlı kılan şey.

RFT Veri Formatı Tuzağı

Bu insanları tökezletiyor. RFT veri formatı SFT’den farklıdır. Her satırdaki son mesaj User veya Developer rolünde olmalıdır — Assistant değil. Beklenen cevap, grader’ın doğrudan referans aldığı reference_answer gibi üst düzey bir anahtara gider.

Denetimli fine-tuning yapıyorsanız ve RFT’ye geçmek istiyorsanız, eğitim verilerinizi yeniden yapılandırmanız gerekir. Bu adımı atlarsanız işleriniz sessizce başarısız olur.

.NET Geliştiricileri İçin Neden Önemli?

Azure OpenAI SDK üzerinden fine-tune edilmiş modelleri .NET uygulamalarınızdan çağırıyorsanız, daha ucuz eğitim daha agresif iterasyon yapabileceğiniz anlamına gelir. Model grader seçenekleri, nüanslı görevler için fine-tuning yapabileceğiniz anlamına gelir — yalnızca tam eşleşme senaryoları için değil. GitHub‘daki en iyi pratikler kılavuzu size gerçek hata ayıklama süresi kazandıracak.

Küçük başlayın. On ila yüz örnek. Basit grader. Döngüyü doğrulayın. Sonra ölçeklendirin.

Azure MCP Araçları Artık Visual Studio 2022'ye Entegre — Uzantı Gerekmiyor

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Azure MCP araçlarını ayrı uzantı üzerinden Visual Studio’da kullandıysanız, süreci biliyorsunuzdur — VSIX’i kurun, yeniden başlatın, bir şeylerin bozulmamasını umun, sürüm uyumsuzluklarıyla uğraşın. O sürtünme artık tarihe karışıyor.

Yun Jung Choi duyurdu: Azure MCP araçları artık Visual Studio 2022’de Azure geliştirme iş yükünün doğrudan bir parçası olarak geliyor. Uzantı yok. VSIX yok. Yeniden başlatma dansı yok.

Bu aslında ne anlama geliyor

Visual Studio 2022 sürüm 17.14.30 itibarıyla Azure MCP Server, Azure geliştirme iş yüküyle birlikte geliyor. Bu iş yükünü zaten yüklediyseniz, tek yapmanız gereken GitHub Copilot Chat’te etkinleştirip kullanmaya başlamak.

45 Azure servisi genelinde 230’dan fazla araç — doğrudan sohbet penceresinden erişilebilir. Depolama hesaplarınızı listeleyin, ASP.NET Core uygulaması dağıtın, App Service sorunlarını tanılayın, Log Analytics’i sorgulayın — tek bir tarayıcı sekmesi açmadan.

Bu neden göründüğünden daha önemli

Geliştirici araçlarındaki şu gerçeği biliyoruz: her ekstra adım sürtünmedir, sürtünme ise benimsemeyi öldürür. MCP’nin ayrı bir uzantı olması; sürüm uyumsuzlukları, kurulum hataları ve güncel tutulması gereken bir şey daha demekti. İş yüküne entegre etmek şu anlama geliyor:

Visual Studio Installer üzerinden tek güncelleme yolu
Uzantı ile IDE arasında sürüm kayması yok
Her zaman güncel — MCP Server, düzenli VS sürümleriyle birlikte güncelleniyor

Azure üzerinde standartlaştıran ekipler için bu büyük bir avantaj. İş yükünü bir kez kuruyorsunuz, araçları etkinleştiriyorsunuz ve her oturumda hazır oluyorlar.

Bununla neler yapabilirsiniz

Araçlar Copilot Chat üzerinden tüm geliştirme yaşam döngüsünü kapsıyor:

Öğrenin — Azure servisleri, en iyi pratikler, mimari kalıplar hakkında sorular sorun
Tasarlayın ve geliştirin — servis önerileri alın, uygulama kodunu yapılandırın
Dağıtın — kaynakları sağlayın ve doğrudan IDE’den dağıtın
Sorun giderin — günlükleri sorgulayın, kaynak sağlığını kontrol edin, üretim sorunlarını tanılayın

Hızlı bir örnek — Copilot Chat’e şunu yazın:

List my storage accounts in my current subscription.

Copilot, arka planda Azure MCP araçlarını çağırır, aboneliklerinizi sorgular ve isimler, konumlar ve SKU’larla birlikte biçimlendirilmiş bir liste döndürür. Portal gerekmez.

Nasıl etkinleştirilir

Visual Studio 2022 17.14.30 veya üzerine güncelleyin
Azure development iş yükünün yüklendiğinden emin olun
GitHub Copilot Chat’i açın
Select tools düğmesine tıklayın (iki İngiliz anahtarı simgesi)
Azure MCP Server‘ı etkinleştirin

Hepsi bu. Oturumlar arasında etkin kalır.

Bir not

Araçlar varsayılan olarak devre dışıdır — katılımınız gerekiyor. VS 2026’ya özgü araçlar VS 2022’de mevcut değil. Araç kullanılabilirliği de portaldaki gibi Azure abonelik izinlerinize bağlı.

Büyük resim

Bu, net bir trendin parçası: MCP, bulut araçlarını geliştirici IDE’lerinde sunmanın standart yolu haline geliyor. Azure MCP Server 2.0 kararlı sürümünü ve VS Code ile diğer editörlerdeki MCP entegrasyonlarını zaten gördük. Visual Studio’nun iş yükü sistemine entegre olması doğal bir ilerleme.

Visual Studio’da yaşayan .NET geliştiricileri olarak bu, Azure portalına bağlam değiştirmek için bir neden daha ortadan kalkıyor. Ve dürüst olmak gerekirse, ne kadar az sekme değiştirirsek o kadar iyi.

Aspire 13.2, MongoDB EF Core ve Azure Data Lake Desteği Kazandı — Denemeye Değer İki Entegrasyon

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Aspire 13.2 dikkatinizi çekmeye değer iki yeni veritabanı entegrasyonuyla yayımlandı: MongoDB Entity Framework Core ve Azure Data Lake Storage. Bir Aspire uygulamasında MongoDB ile EF Core kullanmak istiyorsanız veya uygun servis keşfiyle data lake iş yüklerini bağlamanız gerekiyorsa, bu sürüm her ikisini de sunuyor.

MongoDB, Aspire’da EF Core ile buluşuyor

En çok heyecanlandığım bu. Aspire bir süredir MongoDB’yi destekliyordu ama her zaman ham sürücüydü — EF Core yok, DbContext yok, belgelerinize karşı LINQ sorgusu yok. Artık MongoDB ile tam EF Core deneyimini, ayrıca Aspire’ın otomatik sağlık kontrolleri ve servis keşfini elde ediyorsunuz.

Kurulum, tipik Aspire desenidir. AppHost’unuzda:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Ardından tüketen projenize EF Core entegrasyonunu ekleyin:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Ve DbContext‘inizi kaydedin:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Oradan itibaren standart EF Core. Varlıklarınızı tanımlayın, DbContext‘inizi herhangi bir sağlayıcıyla kullandığınız gibi kullanın. Entegrasyon, bağlantı havuzlamasını, OpenTelemetry izlerini ve sağlık kontrollerini arka planda yönetir.

Ham sürücüyle MongoDB kullanan ve bağlantı dizelerini manuel olarak ayarlayan .NET geliştiricileri için bu, güzel bir yaşam kalitesi yükseltmesi. Aspire’ın servis keşfini kaybetmeden tam EF Core soyutlamasını elde ediyorsunuz.

Azure Data Lake Storage katılıyor

İkinci büyük ekleme, Azure Data Lake Storage (ADLS) entegrasyonu. Veri pipeline’ları, ETL süreçleri veya analitik platformlar geliştiriyorsanız, artık Data Lake kaynaklarını herhangi bir diğer Aspire bağımlılığını bağladığınız gibi bağlayabilirsiniz.

AppHost’ta:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Tüketen projede:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Manuel bağlantı dizesi yönetimi yok, kimlik bilgisi avcılığı yok. Aspire kaynakları sağlar ve enjekte eder. Hem operasyonel veriye hem de analitik iş yüklerine dokunan cloud-native .NET uygulamaları geliştiriyorsanız, bu data lake’i Aspire modelinde birinci sınıf vatandaş gibi hissettiriyor.

Önemli küçük düzeltmeler

Manşet özelliklerin ötesinde, dikkate değer birkaç yaşam kalitesi iyileştirmesi var:

MongoDB bağlantı dizesi düzeltmesi — veritabanı adından önce eğik çizgi artık doğru şekilde işleniyor. Bunun etrafından dolaşıyorsanız, o geçici çözümü kaldırabilirsiniz
SQL Server dışa aktarmaları — Aspire.Hosting.SqlServer artık daha ince ayarlı kontrol için ek sunucu yapılandırma seçenekleri dışa aktarıyor
Emülatör güncellemeleri — ServiceBus emülatörü 2.0.0, App Configuration emülatörü 1.0.2 ve CosmosDB’nin önizleme emülatörü artık bir hazır olma kontrolü içeriyor
Azure Managed Redis — artık varsayılan olarak rediss:// (Redis Secure) kullanıyor; bağlantılar kutudan çıktığı gibi şifreli

Son madde ince ama önemli — varsayılan olarak şifreli Redis, üretimde yapılandırılacak bir şey daha az demek.

Sonuç

Aspire 13.2 artımlı bir sürüm, ancak MongoDB EF Core ve Data Lake entegrasyonları gerçek boşlukları dolduruyor. Aspire’da MongoDB için uygun EF Core desteğini bekliyorsanız veya Data Lake’in birinci sınıf bağımlılık olmasına ihtiyacınız varsa, 13.2’ye yükseltin ve bir deneyin. aspire add komutu ihtiyacınız olan her şeyi iskelet haline getiriyor.

Daha fazla ayrıntı için tam sürüm notlarını okuyun ve tam liste için entegrasyon galerisine göz atın.

azd update — Tüm Paket Yöneticileriniz İçin Tek Bir Komut

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Her birkaç haftada bir beliren “azd’nin yeni bir sürümü mevcut” mesajını biliyor musunuz? azd‘yi winget, Homebrew veya altı ay önce çalıştırdığınız curl betiğiyle mi yüklediğinizi hatırlayamadığınız için görmezden geldiğiniz mesajı? Evet, bu sonunda düzeldi.

Microsoft, azd update‘i piyasaya sürdü — Azure Developer CLI’ı, başlangıçta nasıl yüklediğinizden bağımsız olarak en son sürüme güncelleyen tek bir komut. Windows, macOS, Linux — fark etmiyor. Tek komut.

Nasıl çalışıyor

azd update

Hepsi bu. Yeni özelliklere erken erişim istiyorsanız, günlük insiders derlemesine geçebilirsiniz:

azd update --channel daily
azd update --channel stable

Komut, mevcut kurulum yönteminizi algılar ve arka planda uygun güncelleme mekanizmasını kullanır. Artık “bu makinede winget mi yoksa choco mu kullandım?” sorusuna gerek yok.

Küçük bir uyarı

azd update, 1.23.x sürümünden itibaren gönderilmeye başlandı. Daha eski bir sürümdeyseniz, orijinal kurulum yönteminizi kullanarak son bir manuel güncelleme yapmanız gerekecek. Bundan sonra azd update her şeyi halleder.

Mevcut sürümünüzü azd version ile kontrol edin. Yeni bir kuruluma ihtiyacınız varsa, kurulum dokümanları size yol gösterir.

Neden önemli

Bu küçük bir yaşam kalitesi iyileştirmesi, ancak Azure’a AI ajanları ve Aspire uygulamaları dağıtmak için azd‘yi günlük kullananlar için güncel kalmak daha az “bu hata zaten son sürümde düzeltilmişti” anı demek. Düşünmek zorunda kalmamanız gereken bir şey daha.

Daha fazla bağlam için tam duyuruyu ve Jon Gallant’ın daha ayrıntılı incelemesini okuyun.

Azure Smart Tier Genel Kullanıma Açıldı — Yaşam Döngüsü Kuralları Olmadan Otomatik Blob Depolama Maliyet Optimizasyonu

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Azure Blob Storage yaşam döngüsü politikalarını ayarlamak için zaman harcadınız ve ardından erişim kalıpları değişince bunların çöktüğünü izlediyseniz, bu yazı sizin için. Microsoft, Azure Blob ve Data Lake Storage için smart tier’ın genel kullanıma açıldığını duyurdu — nesneleri gerçek kullanıma göre hot, cool ve cold katmanları arasında otomatik olarak taşıyan, tam yönetimli bir katmanlama özelliği.

Smart tier aslında ne yapıyor

Konsept basit: smart tier, depolama hesabınızdaki her nesnenin son erişim zamanını sürekli değerlendiriyor. Sık erişilen veriler hot’ta kalıyor, etkin olmayan veriler 30 gün sonra cool’a geçiyor ve ardından 60 gün sonra cold’a iniyor. Verilere tekrar erişildiğinde hemen hot’a geri yükseltiliyor. Döngü yeniden başlıyor.

Yapılandırılacak yaşam döngüsü kuralı yok. Erişim kalıbı tahmini yok. Manuel ayarlama yok.

Önizleme sürecinde Microsoft, smart tier tarafından yönetilen kapasitenin %50’sinden fazlasının gerçek erişim kalıplarına göre otomatik olarak daha soğuk katmanlara geçtiğini bildirdi. Büyük depolama hesapları için bu anlamlı bir maliyet azalması.

Bu .NET geliştiricileri için neden önemli

Günlük, telemetri, analitik veri veya büyüyen herhangi bir veri kümesi üreten uygulamalar geliştiriyorsanız — ki dürüst olmak gerekirse kim üretmiyor — depolama maliyetleri hızla artıyor. Geleneksel yaklaşım, yaşam döngüsü yönetim politikaları yazmak, bunları test etmek ve uygulamanızın erişim kalıpları değiştiğinde yeniden ayarlamaktı. Smart tier bu iş akışının tamamını ortadan kaldırıyor.

Bunun işe yaradığı pratik senaryolar:

Uygulama telemetrisi ve günlükleri — hata ayıklama sırasında hot, birkaç hafta sonra nadiren erişilen
Veri pipeline’ları ve ETL çıktıları — işleme sırasında yoğun erişim, ardından çoğunlukla cold
Kullanıcı tarafından oluşturulan içerik — son yüklemeler hot, eski içerik zamanla soğuyor
Yedekleme ve arşiv verileri — uyumluluk için ara sıra erişilen, çoğunlukla atıl

Kurulum

Smart tier’ı etkinleştirmek tek seferlik bir yapılandırma:

Yeni hesaplar: Depolama hesabı oluşturma sırasında varsayılan erişim katmanı olarak smart tier’ı seçin (bölgesel yedeklilik gereklidir)
Mevcut hesaplar: Blob erişim katmanını mevcut varsayılandan smart tier’a geçirin

128 KiB’den küçük nesneler hot’ta kalır ve izleme ücretine tabi değildir. Diğer her şey için katman geçiş ücreti, erken silme ücreti ve veri alma maliyeti olmaksızın standart hot/cool/cold kapasite ücretleri ödüyorsunuz. Nesne başına aylık bir izleme ücreti orkestrasyon maliyetini karşılıyor.

Bilmeniz gereken takas

Smart tier’ın katmanlama kuralları sabit (30 gün → cool, 90 gün → cold). Belirli bir iş yükü için 7 günde cool’a geçmek gibi özel eşikler ihtiyacınız varsa, yaşam döngüsü kuralları hâlâ doğru seçenek. İkisini de karıştırmayın: smart tier tarafından yönetilen nesnelerde yaşam döngüsü kurallarından kaçının, çünkü çakışabilirler.

Sonuç

Bu devrim niteliğinde değil, ama gerçek bir operasyonel baş ağrısını çözüyor. Büyüyen blob depolama hesaplarını yönetiyorsanız ve yaşam döngüsü politikalarını korumaktan bıktıysanız, smart tier’ı etkinleştirin ve Azure’un üstlenmesine izin verin. Neredeyse tüm bölgesel genel bulut bölgelerinde bugün itibariyle kullanılabilir.

Azure'da AI Ajanlarınızı Nerede Barındırmalısınız? Pratik Bir Karar Rehberi

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Şu an .NET ile AI ajanları geliştiriyorsanız, muhtemelen bunu fark etmişsinizdir: Azure’da bunları barındırmanın pek çok yolu var. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — ve gerçekten birini seçmeniz gerekene kadar hepsi makul görünüyor. Microsoft, bunu netleştiren Azure AI ajan barındırma için kapsamlı bir rehber yayımladı ve ben bunu pratik bir .NET geliştirici perspektifinden ele almak istiyorum.

Altı seçeneğe genel bakış

Ortamı şöyle özetlerim:

Seçenek	En iyi kullanım	Siz yönetirsiniz
Container Apps	K8s karmaşıklığı olmadan tam container kontrolü	Gözlemlenebilirlik, durum, yaşam döngüsü
AKS	Kurumsal uyumluluk, çok kümeli, özel ağ	Her şey (bu onun amacı)
Azure Functions	Olay odaklı, kısa süren ajan görevleri	Çok az — gerçek serverless
App Service	Basit HTTP ajanları, öngörülebilir trafik	Dağıtım, ölçeklendirme yapılandırması
Foundry Agents	Portal/SDK aracılığıyla kod gerektirmeyen ajanlar	Neredeyse hiçbir şey
Foundry Hosted Agents	Yönetilen altyapıyla özel framework ajanları	Yalnızca ajan kodunuz

İlk dördü genel amaçlı işlem — üzerlerinde ajan çalıştırabilirsiniz, ancak bunlar bunun için tasarlanmadı. Son ikisi ajan doğasında: konuşmaları, araç çağrılarını ve ajan yaşam döngülerini birinci sınıf kavramlar olarak anlıyorlar.

Foundry Hosted Agents — .NET ajan geliştiricileri için tatlı nokta

İşte dikkatimi çeken kısım. Foundry Hosted Agents tam ortada duruyor: kendi kodunuzu çalıştırma esnekliğini alıyorsunuz (Semantic Kernel, Agent Framework, LangGraph — her neyse), ancak platform altyapıyı, gözlemlenebilirliği ve konuşma yönetimini üstleniyor.

Kilit parça Hosting Adapter — ajan framework’ünüzü Foundry platformuna köprüleyen ince bir soyutlama katmanı. Microsoft Agent Framework için şöyle görünüyor:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Barındırma hikayenizin tamamı bu. Adapter, protokol çevirisini, server-sent events aracılığıyla streaming’i, konuşma geçmişini ve OpenTelemetry izlemeyi otomatik olarak hallediyor. Özel middleware yok, manuel bağlantı yok.

Dağıtım gerçekten basit

Daha önce Container Apps’e ajan dağıttım ve çalışıyor, ancak durum yönetimi ve gözlemlenebilirlik için çok fazla yapıştırıcı kod yazıyorsunuz. Hosted Agents ve azd ile dağıtım şöyle:

# AI agent uzantısını yükle
azd ext install azure.ai.agents

# Bir şablondan başlat
azd ai agent init

# Derle, gönder, dağıt — tamam
azd up

Tek azd up komutu, container’ınızı derliyor, ACR’a gönderiyor, Foundry projesini oluşturuyor, model endpoint’lerini dağıtıyor ve ajanınızı başlatıyor. Beş adım tek komuta indirgeniyor.

Yerleşik konuşma yönetimi

Bu, üretimde en çok zaman kazandıran kısım. Kendi konuşma durum deposunuzu oluşturmak yerine, Hosted Agents bunu doğal olarak hallediyor:

# Kalıcı bir konuşma oluştur
conversation = openai_client.conversations.create()

# İlk tur
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Unutma: favori numaram 42.",
)

# İkinci tur — bağlam korunuyor
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Favori numamı 10 ile çarp.",
)

Redis yok. Cosmos DB oturum deposu yok. Mesaj serileştirme için özel middleware yok. Platform sadece hallediyor.

Karar çerçevem

Altı seçeneğin tamamını inceledikten sonra, işte hızlı zihinsel modelim:

Sıfır altyapı mı istiyorsunuz? → Foundry Agents (portal/SDK, container yok)
Özel ajan kodunuz var ama yönetilen barındırma mı istiyorsunuz? → Foundry Hosted Agents
Olay odaklı, kısa ömürlü ajan görevlerine mi ihtiyacınız var? → Azure Functions
K8s olmadan maksimum container kontrolü mü istiyorsunuz? → Container Apps
Katı uyumluluk ve çok kümeli mimariye mi ihtiyacınız var? → AKS
Öngörülebilir trafikli basit bir HTTP ajanınız mı var? → App Service

Semantic Kernel veya Microsoft Agent Framework ile geliştiren çoğu .NET geliştirici için, Hosted Agents muhtemelen doğru başlangıç noktası. Sıfıra ölçekleme, yerleşik OpenTelemetry, konuşma yönetimi ve framework esnekliği alıyorsunuz — Kubernetes yönetmeden veya kendi gözlemlenebilirlik yığınınızı bağlamadan.

Özet

Azure’daki ajan barındırma ortamı hızla olgunlaşıyor. Bugün yeni bir AI ajan projesi başlatıyorsanız, alışkanlıkla Container Apps veya AKS’e uzanmadan önce Foundry Hosted Agents’ı ciddi olarak değerlendirirdim. Yönetilen altyapı gerçek zaman kazandırıyor ve hosting adapter modeli, framework seçiminizi korumanıza olanak tanıyor.

Çalışan örnekler için Microsoft’ın tam rehberine ve Foundry Samples reposuna göz atın.

.NET'te Agent Skills Ciddi Anlamda Esnek Hale Geldi

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Microsoft Agent Framework ile agent geliştiriyorsanız rutini bilirsiniz: skill’leri tanımlarsınız, bir provider’a bağlarsınız ve agentın hangisini çağıracağına karar vermesini beklersiniz. Yeni olan şey ise bu skill’leri nasıl yazdığınız — ve esneklik sıçraması önemli.

Son güncelleme, agent skill’leri için üç farklı yazım deseni sunuyor: dosya tabanlı, sınıf tabanlı ve satır içi kod tanımlı. Üçü de tek bir AgentSkillsProviderBuilder‘a takılır; yani herhangi bir yönlendirme mantığı veya özel bağlantı kodu olmadan bunları karıştırıp eşleştirebilirsiniz. Her birini ve ne zaman kullanacağınızı anlatalım.

Dosya tabanlı skill’ler: başlangıç noktası

Dosya tabanlı skill’ler tam olarak adından anlaşıldığı gibi — diskte bir SKILL.md dosyası, isteğe bağlı scriptler ve referans belgelerle dolu bir dizin. Agentınıza yeni yetenekler vermenin en doğrudan yolu olarak düşünün:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

SKILL.md frontmatter’ı skill adını ve açıklamasını bildirir, talimatlar bölümü ise agenta scriptleri ve referansları nasıl kullanacağını söyler:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Ardından script yürütmesi için SubprocessScriptRunner.RunAsync ile bağlantı kurarsınız:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

Agent, skill’i otomatik olarak keşfeder ve hesap durumunu kontrol etmesi gerektiğinde provisioning scriptini çağırır. Temiz ve basit.

Sınıf tabanlı skill’ler: NuGet üzerinden yayımlayın

İşte ekipler için ilginç kısım. Sınıf tabanlı skill’ler AgentClassSkill<T>‘dan türetilir ve [AgentSkillResource] ile [AgentSkillScript] gibi attribute’lar kullanır; framework her şeyi yansıma (reflection) yoluyla keşfeder:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Buradaki güzellik, bir ekibin bunu NuGet paketi olarak paketleyebilmesidir. Projenize eklersiniz, builder’a bırakırsınız ve dosya tabanlı skill’lerinizle sıfır koordinasyonla birlikte çalışır:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Her iki skill de agentın sistem prompt’unda görünür. Agent, konuşmaya göre hangisini kullanacağına karar verir — yönlendirme kodu gerekmez.

Satır içi skill’ler: hızlı köprü

Başka bir ekibin tam ihtiyacınız olan skill’i geliştirdiğini ama bir sprint boyunca yayımlanmayacağını bildiğiniz anı tanıyor musunuz? AgentInlineSkill köprünüzdür:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Diğerleri gibi builder’a ekleyin:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

NuGet paketi sonunda yayımlandığında, satır içi skill’i sınıf tabanlıyla değiştirirsiniz. Agent farkı anlamaz.

Ancak satır içi skill’ler sadece köprü için değil. Çalışma zamanında dinamik olarak skill üretmeniz gerektiğinde de doğru seçimdir — config’den yüklenen iş birimi başına bir skill gibi — veya bir scriptin DI container’ına ait olmayan yerel durumu kapatması (closure) gerektiğinde.

Script onayı: human-in-the-loop

Üretim agentları geliştiren .NET geliştiricileri için bu, dağıtım konuşmalarını gerçekten açık eden kısım. Bazı scriptlerin gerçek sonuçları var — birini sigorta planına kaydetmek, üretim altyapısını sorgulamak. UseScriptApproval‘ı açın ve agent herhangi bir scripti çalıştırmadan önce duraklar:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Agent bir script çalıştırmak istediğinde, bunun yerine bir onay isteği döndürür. Uygulamanız kararı toplar — onayla veya reddet — ve agent buna göre devam eder. Düzenlenmiş ortamlarda bu, “bunu dağıtabiliriz” ile “hukuk hayır diyor” arasındaki farktır.

Bu kombinasyonun önemi

Gerçek güç tek bir yazım deseninde değil — kompozisyondadır. Şunları yapabilirsiniz:

Küçük başlayın dosya tabanlı skill ile, talimatlarda yineleyin ve C# yazmadan yayımlayın
Yeniden kullanılabilir skill’ler yayımlayın NuGet paketleri olarak; diğer ekipler tek satırla ekleyebilir
Boşlukları kapatın satır içi skill’lerle ihtiyacınız olan şeyi hemen geliştirmek için
Paylaşılan skill dizinlerini filtreleyin predicate’lerle, agentınızın yalnızca gereken şeyi yüklemesi için
İnsan denetimi ekleyin üretim sistemlerine dokunan scriptler için

Bunların tümü AgentSkillsProviderBuilder üzerinden birleşir. Özel yönlendirme, koşullu mantık, skill tür kontrolleri yok.

Sonuç

.NET’te agent skill’leri artık gerçekten esnek bir yazım modeline sahip. İster dosya tabanlı skill’lerle prototip çizen solo bir geliştirici olun, ister NuGet aracılığıyla paketlenmiş yetenekler yayımlayan kurumsal bir ekip, desenler her duruma uyuyor. Ve script onay mekanizması, insan denetim noktasına ihtiyaç duyduğunuz ortamlar için üretime hazır hale getiriyor.

Tam rehber için orijinal duyuruya, Microsoft Learn’deki Agent Skills belgelerine ve uygulamalı deneyim için GitHub’daki .NET örneklerine göz atın.

Azure MCP Server 2.0 Yayınlandı — Self-Hosted Agentic Bulut Otomasyonu Artık Burada

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

Son zamanlarda MCP ve Azure ile bir şeyler geliştirdiyseniz, yerel deneyimin gayet iyi çalıştığını muhtemelen zaten biliyorsunuzdur. Bir MCP server bağlayın, AI agent’ınızın Azure kaynaklarıyla konuşmasına izin verin, devam edin. Ama bu kurulumu bir ekip genelinde paylaşmanız gerektiğinde? İşte orada işler karmaşıklaşıyordu.

Artık değil. Azure MCP Server 2.0 kararlı sürüme ulaştı ve başlık özelliği tam olarak kurumsal ekiplerin istediği şey: self-hosted uzak MCP server desteği.

Azure MCP Server nedir?

Kısa bir hatırlatma. Azure MCP Server, Model Context Protocol spesifikasyonunu uygular ve Azure yeteneklerini AI agent’larının çağırabileceği yapılandırılmış, keşfedilebilir araçlar olarak sunar. Agent’ınız ile Azure arasında standartlaştırılmış bir köprü olarak düşünebilirsiniz — sağlama, dağıtım, izleme, tanılama, hepsi tek tutarlı bir arayüz üzerinden.

Rakamlar kendisi konuşuyor: 57 Azure servisi genelinde 276 MCP aracı. Bu ciddi bir kapsam.

Büyük haber: self-hosted uzak dağıtımlar

Şöyle ki. MCP’yi kendi makinenizde yerel olarak çalıştırmak geliştirme ve deneyler için sorun değil. Ama gerçek bir ekip senaryosunda şunlara ihtiyacınız var:

Geliştiriciler ve dahili agent sistemleri için paylaşımlı erişim
Merkezi yapılandırma (tenant bağlamı, abonelik varsayılanları, telemetri)
Kurumsal ağ ve politika sınırları
CI/CD pipeline’larına entegrasyon

Azure MCP Server 2.0 tüm bunları ele alıyor. HTTP tabanlı taşıma, uygun kimlik doğrulama ve tutarlı yönetişimle merkezi olarak yönetilen bir dahili servis olarak dağıtabilirsiniz.

Kimlik doğrulama için iki sağlam seçenek var:

Managed Identity — Microsoft Foundry ile birlikte çalışırken
On-Behalf-Of (OBO) akışı — Azure API’lerini oturum açmış kullanıcının bağlamını kullanarak çağıran OpenID Connect delegasyonu

Bu OBO akışı, .NET geliştiricileri olarak bizim için özellikle ilginç. Agentic iş akışlarınızın aşırı ayrıcalıklı bir servis hesabı yerine kullanıcının gerçek izinleriyle çalışabileceği anlamına geliyor. En az ayrıcalık ilkesi, doğrudan yerleşik.

Güvenlik güçlendirmesi

Bu yalnızca bir özellik sürümü değil — aynı zamanda bir güvenlik sürümü. 2.0 sürümü şunları ekliyor:

Daha güçlü endpoint doğrulaması
Sorgu odaklı araçlarda injection kalıplarına karşı koruma
Geliştirme ortamları için daha sıkı izolasyon kontrolleri

MCP’yi paylaşımlı bir servis olarak sunacaksanız, bu güvenceler önemli. Çok önemli.

Nerede kullanabilirsiniz?

İstemci uyumluluk hikayesi geniş. Azure MCP Server 2.0 şunlarla çalışıyor:

IDE’ler: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI agent’ları: GitHub Copilot CLI, Claude Code
Bağımsız: basit kurulumlar için yerel server
Self-hosted uzak: 2.0’ın yeni yıldızı

Ayrıca düzenlenmiş dağıtımlar için kritik olan Azure US Government ve 21Vianet tarafından işletilen Azure için sovereign bulut desteği de var.

Bu .NET geliştiricileri için neden önemli

.NET ile agentic uygulamalar geliştiriyorsanız — ister Semantic Kernel, ister Microsoft Agent Framework, ister kendi orkestrasyon çözümünüz — Azure MCP Server 2.0, agent’larınızın Azure altyapısıyla etkileşime geçmesi için üretime hazır bir yol sunuyor. Özel REST wrapper’ları yok. Servise özgü entegrasyon kalıpları yok. Sadece MCP.

Birkaç gün önce yayınlanan MCP Apps için fluent API ile birleşince .NET MCP ekosistemi hızla olgunlaşıyor.

Başlarken

Kendi yolunuzu seçin:

GitHub Repo — kaynak kodu, dokümantasyon, her şey
Docker Image — container’lı dağıtım
VS Code Extension — IDE entegrasyonu
Self-hosting rehberi — 2.0’ın öne çıkan özelliği

Sonuç

Azure MCP Server 2.0, demoda gösterişli görünmeyen ama pratikte her şeyi değiştiren altyapı yükseltmesi türünden. Uygun kimlik doğrulama, güvenlik güçlendirmesi ve sovereign bulut desteğiyle self-hosted uzak MCP, gerçek ekiplerin Azure üzerinde gerçek agentic iş akışları oluşturması için hazır olduğu anlamına geliyor. “Kurumsal kullanıma hazır” sinyalini bekliyordunuz — işte bu.

Ajanlı Platform Mühendisliği Gerçek Oluyor — Git-APE Bunu Nasıl Yapıyor

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Platform mühendisliği, konferans konuşmalarında harika duyulan ama genellikle “dahili bir portal ve bir Terraform sarmalayıcı geliştirdik” anlamına gelen terimlerden biridir. Gerçek vaat — gerçekten güvenli, yönetişimli ve hızlı self-servis altyapı — her zaman birkaç adım uzakta olmuştur.

Azure ekibi, ajanlı platform mühendisliği serisinin 2. Bölümünü yayımladı ve bu bölüm tamamen uygulamalı implementasyona odaklanıyor. Buna Git-APE (evet, kısaltma kasıtlı) diyorlar; GitHub Copilot agentları ile Azure MCP sunucularını kullanarak doğal dil isteklerini doğrulanmış, dağıtılmış altyapıya dönüştüren açık kaynak bir proje.

Git-APE gerçekte ne yapıyor

Temel fikir şu: geliştiricilerin Terraform modüllerini öğrenmesi, portal arayüzlerinde gezinmesi veya platform ekibine bilet açması yerine, bir Copilot agentıyla konuşması. Agent niyeti yorumlar, Infrastructure-as-Code üretir, politikalara göre doğrular ve dağıtır — tümü VS Code içinde.

İşte kurulum:

git clone https://github.com/Azure/git-ape
cd git-ape

Çalışma alanını VS Code’da açın; agent yapılandırma dosyaları GitHub Copilot tarafından otomatik olarak keşfedilir. Agent ile doğrudan etkileşime geçersiniz:

@git-ape deploy a function app with storage in West Europe

Agent, Azure servisleriyle etkileşim kurmak için arka planda Azure MCP Server’ı kullanır. VS Code ayarlarındaki MCP yapılandırması belirli yetenekleri etkinleştirir:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Neden önemli

Azure üzerine geliştirme yapanlar için bu, platform mühendisliği konuşmasını “nasıl bir portal inşa ederiz” yerine “kısıtlamalarımızı API’ler olarak nasıl tanımlarız” sorusuna kaydırıyor. Platformunuzun arayüzü bir AI agentı olduğunda, kısıtlamalarınızın ve politikalarınızın kalitesi ürün haline geliyor.

Bölüm teorisi ortaya koydu: iyi tanımlanmış API’ler, kontrol şemaları ve açık koruyucular platformları agent-hazır kılar. 2. Bölüm gerçek araçları yayımlayarak bunun işe yaradığını kanıtlıyor. Agent kaynakları körü körüne üretmez — en iyi uygulamalara karşı doğrular, adlandırma kurallarına saygı gösterir ve kuruluşunuzun politikalarını uygular.

Temizlik de aynı derecede kolaydır:

@git-ape destroy my-resource-group

Benim görüşüm

Dürüst olacağım — bu, belirli araçtan çok desen hakkında. Git-APE’nin kendisi bir demo/referans mimarisidir. Ama temel fikir — platformunuza arayüz olarak agentlar, protokol olarak MCP, host olarak GitHub Copilot — kurumsal geliştirici deneyiminin nereye gittiğidir.

Dahili araçlarını agent-dostu hale getirmeye bakan bir platform ekibiyseniz, daha iyi bir başlangıç noktası yok. .NET geliştiricisi olarak bunun dünyanzla nasıl bağlantılı olduğunu merak ediyorsanız: Azure MCP Server ve GitHub Copilot agentları herhangi bir Azure iş yüküyle çalışır. ASP.NET Core API’niz, .NET Aspire yığınınız, konteynerize mikro servisleriniz — hepsi ajanlı bir dağıtım akışının hedefi olabilir.

Sonuç

Git-APE, ajanlı platform mühendisliğine pratikte erken ama somut bir bakış. Repo’yu klonlayın, demoyu deneyin ve platformunuzun API’lerinin ve politikalarının bir agentın bunları güvenle kullanması için nasıl görünmesi gerektiğini düşünmeye başlayın.

Rehber ve video demolar için tam yazıyı okuyun.

Azure Functions Üzerindeki MCP Server'larınızı Foundry Agent'larına Bağlayın — İşte Nasıl Yapılır

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

MCP ekosistemi hakkında sevdiğim bir şey var: server’ınızı bir kez oluşturuyorsunuz ve her yerde çalışıyor. VS Code, Visual Studio, Cursor, ChatGPT — her MCP istemcisi araçlarınızı keşfedip kullanabiliyor. Şimdi Microsoft bu listeye bir tüketici daha ekliyor: Foundry agent’ları.

Azure SDK ekibinden Lily Ma, Microsoft Foundry agent’larıyla Azure Functions’a dağıtılmış MCP server’larını bağlamaya dair pratik bir kılavuz yayımladı. Zaten bir MCP server’ınız varsa, bu tamamen katma değer — yeniden yapılandırma gerekmiyor.

Bu Kombinasyon Neden Mantıklı?

Azure Functions, MCP server’larını barındırmak için ölçeklenebilir altyapı, yerleşik auth ve sunucusuz faturalama sunuyor. Microsoft Foundry ise akıl yürütebilen, plan yapabilen ve eylemler gerçekleştirebilen AI agent’ları sağlıyor. İkisini birleştirmek, özel araçlarınızın — veritabanı sorgulama, iş API’si çağrısı, doğrulama mantığı çalıştırma — kurumsal AI agent’larının özerk olarak keşfedip kullanabileceği yetenekler haline gelmesi anlamına geliyor.

Önemli nokta: MCP server’ınız aynı kalıyor. Yalnızca Foundry’yi başka bir tüketici olarak ekliyorsunuz. VS Code kurulumunuzda çalışan araçların aynısı artık ekibinizin veya müşterilerinizin etkileşime girdiği bir AI agent’ına güç veriyor.

Kimlik Doğrulama Seçenekleri

Yazının gerçek değer kattığı yer burası. Senaryonuza bağlı olarak dört auth yöntemi:

Yöntem	Kullanım Senaryosu
Key tabanlı (varsayılan)	Geliştirme veya Entra auth olmayan server’lar
Microsoft Entra	Yönetilen kimliklerle üretim
OAuth identity passthrough	Her kullanıcının bireysel olarak kimlik doğruladığı üretim
Kimlik doğrulamasız	Geliştirme/test veya yalnızca genel veriler

Üretim için, agent kimliğiyle Microsoft Entra önerilen yoldur. OAuth identity passthrough, kullanıcı bağlamının önemli olduğu durumlar içindir — agent kullanıcıların giriş yapmasını ister ve her istek kullanıcının kendi token’ını taşır.

Kurulum

Üst düzey akış:

MCP server’ınızı Azure Functions’a dağıtın — .NET, Python, TypeScript ve Java için örnekler mevcut
Function app’inizde yerleşik MCP kimlik doğrulamasını etkinleştirin
Endpoint URL’nizi alın — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
MCP server’ı Foundry’de araç olarak ekleyin — portaldaki agent’ınıza gidin, yeni bir MCP aracı ekleyin, endpoint ve kimlik bilgilerini sağlayın

Ardından araçlarınızdan birini tetikleyecek bir prompt göndererek Agent Builder playground’unda test edin.

Değerlendirmem

Buradaki kompozisyon hikayesi gerçekten güçleniyor. MCP server’ınızı .NET’te (veya Python, TypeScript, Java’da) bir kez oluşturun, Azure Functions’a dağıtın ve her MCP uyumlu istemci onu kullanabilsin — kodlama araçları, chat uygulamaları ve artık kurumsal AI agent’ları. Bu, gerçekten işleyen bir “bir kez yaz, her yerde kullan” pattern’ı.

.NET geliştiricileri için özellikle, Azure Functions MCP extension bunu kolaylaştırıyor. Araçlarınızı Azure Functions olarak tanımlayın, dağıtın ve Azure Functions’ın sağladığı tüm güvenlik ve ölçeklendirme özellikleriyle birlikte üretim kalitesinde bir MCP server’ınız olsun.

Son Söz

Azure Functions üzerinde çalışan MCP araçlarınız varsa, bunları Foundry agent’larına bağlamak hızlı bir kazanımdır — özel araçlarınız, server’ın kendisinde hiçbir kod değişikliği yapmadan ve uygun auth ile kurumsal AI yeteneklerine dönüşür.

Her kimlik doğrulama yöntemi için adım adım talimatlar için tam kılavuzu okuyun ve üretim kurulumları için ayrıntılı belgeleri inceleyin.

GitHub Copilot'un Modernizasyon Değerlendirmesi, Henüz Kullanmadığınız En İyi Göç Aracı

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Eski bir .NET Framework uygulamasını modern .NET’e taşımak, herkesin yapması gerektiğini bildiği ama kimsenin başlamak istemediği işlerden biri. Bu hiçbir zaman sadece “hedef framework’ü değiştir” meselesi değildir. Ortadan kalkan API’lar, artık mevcut olmayan paketler, tamamen farklı çalışan hosting modelleri ve neyin container’a alınacağı, neyin yeniden yazılacağı, neyin olduğu gibi bırakılacağına dair binlerce küçük karar var.

Jeffrey Fritz, GitHub Copilot’un modernizasyon değerlendirmesine derin bir dalış yayımladı ve dürüst olmak gerekirse? Bu, .NET için gördüğüm en iyi göç araçları. Kod oluşturma nedeniyle değil — bu artık herkes için temel gereksinim. Ürettiği değerlendirme belgesi nedeniyle.

Bu sadece bir kod öneri motoru değil

VS Code uzantısı bir Değerlendir → Planla → Uygula modeli izliyor. Değerlendirme aşaması tüm kod tabanınızı analiz ediyor ve her şeyi yakalayan yapılandırılmış bir belge üretiyor: neyin değişmesi gerektiği, hangi Azure kaynaklarının sağlanacağı, hangi dağıtım modelinin kullanılacağı. Aşağıdaki her şey — altyapı-kodu, containerlaştırma, dağıtım manifestoları — değerlendirmenin bulduklarından akıyor.

Değerlendirme, projenizde .github/modernize/assessment/ altında saklanıyor. Her çalıştırma bağımsız bir rapor üretiyor, böylece bir geçmiş oluşturabilir ve sorunları düzelttikçe göç pozisyonunuzun nasıl geliştiğini takip edebilirsiniz.

Başlamanın iki yolu

Önerilen Değerlendirme — hızlı yol. Seçilmiş alanlardan birini seçin (Java/.NET Yükseltme, Bulut Hazırlığı, Güvenlik) ve yapılandırmaya dokunmadan anlamlı sonuçlar alın. Uygulamanızın nerede durduğuna ilk bakış için harika.

Özel Değerlendirme — hedefli yol. Neyin analiz edileceğini tam olarak yapılandırın: hedef hesaplama (App Service, AKS, Container Apps), hedef işletim sistemi, containerlaştırma analizi. Göç yaklaşımlarını yan yana karşılaştırmak için birden fazla Azure hedefi seçin.

Bu karşılaştırma görünümü gerçekten yararlı. App Service için 3 zorunlu sorunu olan bir uygulamanın AKS için 7 sorunu olabilir. Her ikisini de görmek, bir göç yoluna bağlanmadan önce hosting kararını yönlendirmeye yardımcı oluyor.

Sorun dökümü uygulanabilir

Her sorun bir kritiklik düzeyiyle geliyor:

Zorunlu — düzeltilmeli, yoksa göç başarısız olur
Olası — göçü etkileyebilir, insan değerlendirmesi gerektirir
İsteğe bağlı — önerilen iyileştirmeler, göçü engellemez

Ve her sorun etkilenen dosyalara ve satır numaralarına bağlantı veriyor, neyin yanlış olduğunu ve neden hedef platformunuz için önemli olduğunu ayrıntılı açıklıyor, somut düzeltme adımları sunuyor (sadece “bunu düzelt” değil) ve resmi belgelere bağlantılar içeriyor.

Bireysel sorunları geliştiricilere verebilir ve harekete geçmek için ihtiyaç duydukları her şeye sahip olurlar. Bu, “bir sorun var” diyen bir araç ile nasıl çözüleceğini söyleyen bir araç arasındaki farktır.

Kapsanan yükseltme yolları

.NET için özellikle:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Her yükseltme yolunun, hangi API’ların kaldırıldığını, hangi desenlerin doğrudan eşdeğerinin bulunmadığını ve hangi güvenlik sorunlarının ele alınması gerektiğini bilen algılama kuralları var.

Birden fazla uygulamayı yöneten ekipler için çok-repo toplu değerlendirmeleri destekleyen bir CLI de var — tüm repoları klonlayın, hepsini değerlendirin, uygulama başına raporlar artı toplu portföy görünümü alın.

Benim düşüncem

Eski .NET Framework uygulamalarının üzerinde oturuyorsanız (ve gerçekçi olalım, çoğu kurumsal ekip oturuyor), bu başlamak için tek araçtır. Değerlendirme belgesi tek başına zamana değer — belirsiz bir “modernize etmeliyiz"i, somut ve önceliklendirilmiş, net ileriye dönük yolları olan bir iş öğeleri listesine dönüştürür.

İş birliğine dayalı iş akışı da akıllıca: değerlendirmeleri dışa aktarın, ekibinizle paylaşın, yeniden çalıştırmadan içe aktarın. Karar vericilerin araçları çalıştıranlar olmadığı mimari incelemeler? Karşılandı.

Sonuç

GitHub Copilot’un modernizasyon değerlendirmesi, .NET göçünü korkunç, tanımsız bir projeden yapılandırılmış, izlenebilir bir sürece dönüştürüyor. Nerede durduğunuzu görmek için önerilen değerlendirmeyle başlayın, ardından Azure hedeflerini karşılaştırmak ve göç planınızı oluşturmak için özel değerlendirmeleri kullanın.

Tam anlatımı okuyun ve kendi kod tabanınızda denemek için VS Code uzantısını alın.

Kara Kutu Hissi Vermeyen Gerçek Zamanlı Çoklu-Agent Arayüzleri Oluşturmak

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Çoklu-agent sistemler hakkında şunu söylemek gerekir: demo ortamlarında inanılmaz görünürler. Üç agent iş birbirine aktarır, sorunları çözer, kararlar alır. Sonra bunu gerçek kullanıcıların önüne koymaya çalışırsınız ve… sessizlik. Dönen bir yükleme göstergesi. Hangi agentın ne yaptığını ya da sistemin neden durduğunu anlatan hiçbir şey yok. Bu bir ürün değil — bu bir güven sorunudur.

Microsoft Agent Framework ekibi, MAF iş akışlarını AG-UI ile eşleştiren harika bir rehber yayımladı. AG-UI, agent yürütme olaylarını Server-Sent Events üzerinden bir frontend’e aktarmak için kullanılan açık bir protokoldür. Ve dürüst olmak gerekirse? Bu, eksik olan köprünün ta kendisi.

.NET geliştiricileri için neden önemli

AI destekli uygulamalar geliştiriyorsanız, muhtemelen bu duvarla karşılaşmışsınızdır. Backend orkestrasyonunuz mükemmel çalışır — agentlar birbirlerine iş devreder, araçlar tetiklenir, kararlar alınır. Ancak frontend, perde arkasında ne olduğundan habersizdir. AG-UI, agent olaylarını (RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_* gibi) SSE üzerinden doğrudan UI katmanınıza aktarmak için standart bir protokol tanımlayarak bunu çözer.

Geliştirdikleri demo, üç agentlı bir müşteri destek iş akışı: istekleri yönlendiren bir triage agentı, para işlerini yöneten bir refund agentı ve ikame yönetimi yapan bir order agentı. Her agentın kendi araçları var ve devir teslim topolojisi açıkça tanımlanmış — “prompt’tan çöz” vibesinden eser yok.

Devir teslim topolojisi asıl yıldız

Dikkatimi çeken şey, HandoffBuilder‘ın agentlar arasında yönlendirilmiş bir rotalama grafiği tanımlamanıza izin vermesidir:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Her add_handoff, doğal dil açıklamasıyla yönlendirilmiş bir kenar oluşturur. Framework, bu topolojiye dayanarak her agent için devir teslim araçları üretir. Böylece yönlendirme kararları, LLM’in keyfine değil, orkestrasyon yapınıza dayanır. Bu, üretim güvenilirliği açısından son derece önemlidir.

Gerçekten işe yarayan human-in-the-loop

Demo, her gerçek dünya agent uygulamasının ihtiyaç duyduğu iki kesme (interrupt) deseni sergiliyor:

Araç onay kesmeleri — bir agent approval_mode="always_require" ile işaretlenmiş bir araç çağırdığında iş akışı duraklar ve bir olay yayımlar. Frontend, araç adı ve argümanlarıyla bir onay modalı gösterir. Token yakan yeniden deneme döngüleri yok — sadece temiz bir duraklat-onayla-devam et akışı.

Bilgi isteği kesmeleri — bir agentın kullanıcıdan daha fazla bağlam (örneğin bir sipariş ID’si) ihtiyacı olduğunda durur ve sorar. Frontend soruyu gösterir, kullanıcı yanıtlar ve yürütme tam kaldığı yerden devam eder.

Her iki desen de standart AG-UI olayları olarak stream edilir; bu nedenle frontend’inizin her agent için özel mantığa ihtiyacı yoktur — SSE bağlantısından gelen olayı olduğu gibi gösterir.

Bağlantı kurmak şaşırtıcı derecede basit

MAF ile AG-UI arasındaki entegrasyon tek bir fonksiyon çağrısıdır:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factory, thread başına yeni bir iş akışı oluşturur; böylece her konuşma izole bir duruma sahip olur. Endpoint, tüm SSE altyapısını otomatik olarak yönetir. Zaten FastAPI kullanıyorsanız (ya da hafif bir katman olarak ekleyebiliyorsanız), bu neredeyse hiç sürtünme gerektirmez.

Benim görüşüm

.NET geliştiricileri olarak aklımıza gelen ilk soru şu: “Bunu C#’ta yapabilir miyim?” Agent Framework hem .NET hem de Python için mevcut ve AG-UI protokolü dilden bağımsız (aslında sadece SSE). Bu nedenle, bu demo Python ve FastAPI kullansa da, desen doğrudan çevrilebilir. Aynı AG-UI olay şemasını takip eden SSE endpoint’leriyle ASP.NET Core minimal API kurabilirsiniz.

Daha büyük çıkarım şu: çoklu-agent arayüzleri artık sonradan düşünülen bir konu değil, birinci sınıf bir endişe haline geliyor. Agentların insanlarla etkileşime girdiği herhangi bir şey geliştiriyorsanız — müşteri desteği, onay iş akışları, belge işleme — MAF orkestrasyonu ve AG-UI şeffaflığının bu kombinasyonu, izlenecek yol.

Sonuç

AG-UI + Microsoft Agent Framework, her iki dünyanın en iyisini sunar: backend’de sağlam çoklu-agent orkestrasyonu, frontend’de gerçek zamanlı görünürlük. Artık kara kutu agent etkileşimleri yok.

Daha fazla bilgi için tam rehbere ve AG-UI protokol deposuna göz atın.

Microsoft Foundry Mart 2026 — GPT-5.4, Agent Service GA ve Her Şeyi Değiştiren SDK Yenilemesi

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Aylık “Microsoft Foundry’de Neler Yeni” yazıları genellikle kademeli iyileştirmelerin ve ara sıra bir manşet özelliğinin karışımı olur. Mart 2026 sayısı? Bu neredeyse tamamen manşet özelliklerden oluşuyor. Foundry Agent Service GA’ya geçiyor, GPT-5.4 üretime geliyor, SDK büyük bir kararlı sürüm alıyor ve Fireworks AI, Azure’a açık model çıkarımı getiriyor. .NET geliştiricileri için önemli olanları ele alayım.

Foundry Agent Service Üretime Hazır

Bu büyük haber. Yeni nesil agent runtime genel kullanıma sunuldu — OpenAI Responses API üzerine kurulu, OpenAI agent’larıyla wire uyumlu ve birden fazla sağlayıcının modellerine açık. Bugün Responses API ile geliştirme yapıyorsanız, Foundry’ye geçiş mevcut agent mantığınızın üstüne kurumsal güvenlik, özel ağ desteği, Entra RBAC, tam izleme ve değerlendirme ekler.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Önemli eklemeler: uçtan uca özel ağ desteği, MCP auth genişlemesi (OAuth passthrough dahil), konuşmadan konuşmaya agent’lar için Voice Live önizlemesi ve 6 yeni bölgede barındırılan agent’lar.

GPT-5.4 — Ham Zekadan Çok Güvenilirlik

GPT-5.4, daha akıllı olmak için değil. Daha güvenilir olmak için. Uzun etkileşimlerde daha güçlü akıl yürütme, daha iyi talimat uyumu, daha az iş akışı ortası başarısızlık ve entegre bilgisayar kullanım yetenekleri. Üretim agent’ları için o güvenilirlik, kıyaslama puanlarından çok daha önemlidir.

Model	Fiyatlandırma (M token başına)	En İyi Kullanım
GPT-5.4 (≤272K)	$2,50 / $15 çıktı	Üretim agent’ları, kodlama, belge iş akışları
GPT-5.4 Pro	$30 / $180 çıktı	Derin analiz, bilimsel akıl yürütme
GPT-5.4 Mini	Maliyet etkin	Sınıflandırma, çıkarım, hafif araç çağrıları

Akıllı hamle bir yönlendirme stratejisidir: GPT-5.4 Mini yüksek hacimli, düşük gecikmeli işleri yönetirken GPT-5.4 akıl yürütme ağırlıklı istekleri alır.

SDK Nihayet Kararlı

azure-ai-projects SDK tüm dillerde kararlı sürümler gönderdi — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0 ve .NET 2.0.0 (1 Nisan). azure-ai-agents bağımlılığı kalktı — her şey AIProjectClient altında yaşıyor. pip install azure-ai-projects ile kurun; paket openai ve azure-identity‘yi doğrudan bağımlılık olarak birlikte getiriyor.

.NET geliştiricileri için bu, tam Foundry yüzeyi için tek bir NuGet paketi anlamına geliyor. Artık ayrı agent SDK’larını dengeleme yok.

Fireworks AI Açık Modelleri Azure’a Taşıyor

Belki de mimarısal açıdan en ilginç ekleme: günlük ~180K istek/saniye ile 13+ trilyon token işleyen Fireworks AI artık Foundry üzerinden kullanılabilir. Lansmanında DeepSeek V3.2, gpt-oss-120b, Kimi K2.5 ve MiniMax M2.5.

Asıl hikaye kendi ağırlıklarını getir — sunum yığınını değiştirmeden her yerden nicel veya fine-tune edilmiş ağırlıklar yükleyin. Sunucusuz token başına ödeme veya sağlanan iş hacmi ile dağıtın.

Diğer Öne Çıkanlar

Phi-4 Reasoning Vision 15B — grafikler, diyagramlar ve belge düzenleri için çok modlu akıl yürütme
Evaluations GA — Azure Monitor’a aktarılan sürekli üretim izlemeyle hazır değerlendiriciler
Priority Processing (Önizleme) — gecikmeye duyarlı iş yükleri için ayrılmış hesaplama şeridi
Voice Live — doğrudan Foundry agent’larına bağlanan konuşmadan konuşmaya runtime
Tracing GA — sıralama ve filtrelemeyle uçtan uca agent iz incelemesi
PromptFlow kullanımdan kaldırma — Ocak 2027’ye kadar Microsoft Framework Workflows’a geçiş

Son Söz

Mart 2026, Foundry için bir dönüm noktası. Agent Service GA, tüm dillerde kararlı SDK’lar, güvenilir üretim agent’ları için GPT-5.4 ve Fireworks AI üzerinden açık model çıkarımı — platform ciddi iş yükleri için hazır.

Başlamak için tam özeti okuyun ve ilk agent’ınızı oluşturun.

SQL MCP Server — AI Ajanlarına Veritabanı Erişimi Vermenin Doğru Yolu

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Dürüst olalım: bugün mevcut veritabanı MCP sunucularının çoğu gerçekten ürkütücü. Doğal dil sorgusu alıyor, anında SQL üretiyor ve bunu üretim verinize karşı çalıştırıyor. Ne yanlış gidebilir ki? (Her şey. Her şey yanlış gidebilir.)

Azure SQL ekibi az önce SQL MCP Server’ı tanıttı ve bu yaklaşım temelden farklı. Data API builder (DAB) 2.0’ın bir özelliği olarak geliştirilen bu araç, AI ajanlarına NL2SQL olmadan, şemanızı açıklamadan ve her adımda tam RBAC ile veritabanı işlemlerine yapılandırılmış, deterministik erişim sağlıyor.

Neden NL2SQL yok?

Bu, en ilginç tasarım kararı. Modeller deterministik değil ve karmaşık sorgular en büyük hata riskini taşıyan yapılar. AI’ın üretmesini umduğunuz tam sorgular da deterministik olmayan şekilde üretildiğinde en dikkatli incelenmesi gereken sorgular oluyor.

Bunun yerine SQL MCP Server bir NL2DAB yaklaşımı benimsiyor. Ajan, Data API builder’ın varlık soyutlama katmanı ve yerleşik sorgu oluşturucu ile birlikte çalışarak doğru ve düzgün biçimlendirilmiş T-SQL deterministik olarak üretiyor. Kullanıcı için aynı sonuç, ancak hayali JOIN’ler veya kazara veri ifşası riski olmadan.

Yedi araç, yedi yüz değil

SQL MCP Server, veritabanının büyüklüğünden bağımsız olarak tam olarak yedi DML aracı sunuyor:

describe_entities — mevcut varlıkları ve işlemleri keşfet
create_record — satır ekle
read_records — tablolar ve görünümleri sorgula
update_record — satırları değiştir
delete_record — satırları sil
execute_entity — saklı yordamları çalıştır
aggregate_records — toplama sorguları

Bu akıllıca bir tasarım çünkü bağlam pencereleri ajanın düşünme alanıdır. Yüzlerce araç tanımıyla doldurmak, muhakeme için daha az alan bırakır. Yedi sabit araç, ajanın gezinmek yerine düşünmeye odaklanmasını sağlar.

Her araç ayrı ayrı etkinleştirilebilir veya devre dışı bırakılabilir:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Üç komutla başlangıç

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Bu kadar. Customers tablonuzu açığa çıkaran çalışan bir SQL MCP Server’ınız var. Varlık soyutlama katmanı, adları ve sütunları takma adla kullanmanıza, rol başına alanları sınırlamanıza ve iç şema ayrıntılarını açıklamadan ajanların tam olarak neyi göreceğini kontrol etmenize olanak tanıyor.

Güvenlik hikayesi sağlam

Data API builder’ın olgunluğu burada meyvesini veriyor:

Her katmanda RBAC — her varlık hangi rollerin okuyabileceğini, oluşturabileceğini, güncelleyebileceğini veya silebileceğini ve hangi alanların görünür olduğunu tanımlıyor
Azure Key Vault entegrasyonu — bağlantı dizeleri ve gizli anahtarlar güvenli şekilde yönetiliyor
Microsoft Entra + özel OAuth — üretim düzeyinde kimlik doğrulama
Content Security Policy — ajanlar ham SQL değil, denetimli bir sözleşme üzerinden etkileşim kuruyor

Şema soyutlaması özellikle önemli. İç tablo ve sütun adlarınız asla ajana açıklanmıyor. Veritabanı ERD’nize göre değil, AI etkileşimi için mantıklı olan varlıkları, takma adları ve açıklamaları siz tanımlıyorsunuz.

Çok veritabanı ve çok protokol

SQL MCP Server, Microsoft SQL, PostgreSQL, Azure Cosmos DB ve MySQL’i destekliyor. Ve bir DAB özelliği olduğundan, aynı yapılandırmadan eş zamanlı olarak REST, GraphQL ve MCP endpoint’leri elde ediyorsunuz. Aynı varlık tanımları, aynı RBAC kuralları, aynı güvenlik — üç protokol genelinde.

DAB 2.0’daki otomatik yapılandırma, hızlı prototipleme için daha az soyutlamaya razıysanız veritabanınızı inceleyebilir ve yapılandırmayı dinamik olarak oluşturabilir.

Kişisel görüşüm

AI ajanları için kurumsal veritabanı erişimi işte böyle çalışmalı. “Hey LLM, biraz SQL yaz da üretime at bakalım” değil. Bunun yerine: iyi tanımlanmış bir varlık katmanı, deterministik sorgu üretimi, her adımda RBAC, önbellekleme, izleme ve telemetri. En iyi anlamda sıkıcı.

.NET geliştiricileri için entegrasyon hikayesi temiz — DAB bir .NET aracıdır, MCP Server bir container olarak çalışır ve çoğumuzun zaten kullandığı Azure SQL ile çalışır. Veri erişimine ihtiyaç duyan AI ajanları geliştiriyorsanız buradan başlayın.

Sonuç

SQL MCP Server ücretsiz, açık kaynaklı ve her yerde çalışır. AI ajanlarına güvenli veritabanı erişimi sağlamak için Microsoft’un öngörülü yaklaşımıdır. Başlamak için tam yazıyı ve dokümantasyonu inceleyin.

azd Artık AI Ajanlarınızı Yerel Ortamda Çalıştırıp Hata Ayıklamanıza İzin Veriyor — Mart 2026'daki Değişiklikler

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Bir ayda yedi sürüm. Azure Developer CLI (azd) ekibinin Mart 2026’da yaptığı bu ve başlık özelliği benim beklediğim şey: AI ajanları için yerel çalıştırma ve hata ayıklama döngüsü.

PC Chan tam özeti yayımladı ve orada pek çok şey olsa da, AI destekli uygulamalar geliştiren .NET geliştiricileri için gerçekten önem taşıyan şeyleri özetleyeyim.

AI ajanlarını dağıtmadan çalıştırın ve hata ayıklayın

En büyük yenilik bu. Yeni azure.ai.agents uzantısı, AI ajanları için düzgün bir iç döngü deneyimi sunan bir dizi komut ekliyor:

azd ai agent run — ajanı yerel olarak başlatır
azd ai agent invoke — ona mesaj gönderir (yerel veya dağıtılmış)
azd ai agent show — container durumunu ve sağlığını gösterir
azd ai agent monitor — container loglarını gerçek zamanlı akıtır

Bundan önce, bir AI ajanını test etmek her değişiklik yaptığınızda Microsoft Foundry’e dağıtmak anlamına geliyordu. Artık yerel olarak yineleyebilir, ajanın davranışını test edebilir ve yalnızca hazır olduğunuzda dağıtabilirsiniz. Microsoft Agent Framework veya Semantic Kernel ile ajan geliştiriyorsanız, bu günlük iş akışınızı değiştiriyor.

invoke komutu hem yerel hem de dağıtılmış ajanlara karşı çalışıyor; bu, ajanın nerede çalıştığından bağımsız olarak aynı test iş akışını kullanabileceğiniz anlamına geliyor. Bu tür bir ayrıntı, iki ayrı test betiği setini sürdürmek zorunda kalmaktan sizi kurtarıyor.

GitHub Copilot azd projenizi iskelet oluşturuyor

azd init artık “GitHub Copilot ile Kur (Önizleme)” seçeneği sunuyor. Proje yapınız hakkındaki prompt’lara manuel olarak yanıt vermek yerine, bir Copilot ajanı yapılandırmayı sizin için iskelet oluşturuyor. Herhangi bir şeyi değiştirmeden önce kirli çalışma dizinini kontrol ediyor ve MCP sunucusu araç iznini önceden istiyor.

Bir komut başarısız olduğunda, azd artık AI destekli sorun giderme sunuyor: bir kategori seçin (açıkla, rehberlik, sorun gider veya atla), ajanın bir düzeltme önermesine izin verin ve yeniden deneyin — hepsi terminali terk etmeden. Karmaşık altyapı kurulumları için bu gerçek anlamda zaman kazandırıyor.

Container App Jobs ve dağıtım iyileştirmeleri

Dikkat çekmeye değer birkaç dağıtım özelliği:

Container App Jobs: azd artık mevcut host: containerapp yapılandırması aracılığıyla Microsoft.App/jobs dağıtıyor. Bicep şablonunuz hedefin Container App mı yoksa Job mu olduğunu belirliyor — ekstra kurulum gerekmez.
Yapılandırılabilir dağıtım zaman aşımları: azd deploy üzerinde yeni --timeout bayrağı ve azure.yaml‘da deployTimeout alanı. Varsayılan 1200 saniyelik sınırı artık tahmin etmek zorunda değilsiniz.
Uzak derleme yedeklemesi: Uzak ACR derlemesi başarısız olduğunda, azd otomatik olarak yerel Docker/Podman derlemesine geri düşüyor.
Yerel ön uçuş doğrulama: Bicep parametreleri, Azure’a bir gidiş-dönüş yapmadan eksik parametreleri yakalamak için dağıtımdan önce yerel olarak doğrulanıyor.

Geliştirici deneyimi iyileştirmeleri

Toplanınca fark yaratan küçük iyileştirmeler:

JS/TS projeleri için otomatik pnpm/yarn algılama
Python paketleme için pyproject.toml desteği
Yerel şablon dizinleri — azd init --template artık çevrimdışı yineleme için dosya sistemi yollarını kabul ediyor
--no-prompt modunda daha iyi hata mesajları — eksik tüm değerler çözüm komutlarıyla birlikte bir kerede raporlanıyor
Derleme ortam değişkenleri tüm framework derleme alt süreçlerine enjekte ediliyor (.NET, Node.js, Java, Python)

Son madde ince ama önemli: .NET derlemeniz artık azd ortam değişkenlerine erişebilir; bu, ekstra betik yazmadan derleme zamanı yapılandırma enjeksiyonu yapabileceğiniz anlamına geliyor.

Özet

Yerel AI ajan hata ayıklama döngüsü bu sürümün yıldızı, ancak dağıtım iyileştirmeleri ve geliştirici deneyimi cilasının birikmesi azd‘yi her zamankinden daha olgun hissettiriyor. .NET uygulamalarını Azure’a — özellikle AI ajanlarını — dağıtıyorsanız, bu güncelleme kuruluma değer.

Her ayrıntı için tam sürüm notlarına bakın ya da azd kurulumu ile başlayın.

KubeCon Avrupa 2026: .NET Geliştiricilerinin Gerçekten Önemsemesi Gerekenler

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Büyük bir duyuru yazısı yayımlandığında ve “harika, ama bu benim için ne değiştiriyor ki” diye düşünerek kaydırma yaptığınız o hissi bilirsiniz, değil mi? Ben her KubeCon sezonunda böyle hissediyorum.

Microsoft, KubeCon Avrupa 2026 tam özetini yayımladı — bizzat Brendan Burns tarafından yazıldı — ve dürüst olmak gerekirse? Burada gerçek bir içerik var. Yalnızca özellik onay kutuları değil, üretimdeki çalışma biçiminizi değiştiren türden operasyonel iyileştirmeler.

.NET geliştiricileri olarak bizim için gerçekten önemli olanları ele alayım.

Service Mesh Yükü Olmadan mTLS

Service mesh’ler hakkında şunu söylemek gerekir: herkes güvenlik garantilerini istiyor, kimse operasyonel yükü istemiyor. AKS nihayet bu boşluğu kapatıyor.

Azure Kubernetes Application Network, ağır sidecar’lı bir mesh dağıtmadan karşılıklı TLS, uygulama farkında yetkilendirme ve trafik telemetrisi sunuyor. Advanced Container Networking Services’deki Cilium mTLS ile birleşince, kimlik yönetimi için X.509 sertifikaları ve SPIRE kullanan şifreli pod-to-pod iletişimi elde ediyorsunuz.

Pratikte ne anlama geliyor: arka plan worker’larıyla konuşan ASP.NET Core API’leriniz, birbirini çağıran gRPC servisleriniz — sıfır uygulama kodu değişikliğiyle ağ düzeyinde şifreli ve kimlik doğrulamalı. Bu büyük bir şey.

ingress-nginx‘ten geçiş yapan ekipler için tam Kubernetes Gateway API desteğiyle Application Routing with Meshless Istio da mevcut. Sidecar yok. Standart tabanlı. Ve kademeli geçiş için ingress2gateway araçlarını gönderdiler.

Sonradan Düşünülmemiş GPU Gözlemlenebilirliği

.NET servislerinizin yanında AI çıkarımı çalıştırıyorsanız (ve dürüst olalım, kim başlamıyor?), GPU izleme kör noktasına çarpmış olabilirsiniz. Harika CPU/bellek dashboard’larınız olur ve ardından… manuel exporter bağlantıları olmadan GPU’lar için hiçbir şey.

AKS artık GPU metriklerini yönetilen Prometheus ve Grafana’ya yerel olarak sunuyor. Aynı yığın, aynı dashboard’lar, aynı uyarı pipeline’ı. Özel exporter yok, üçüncü taraf ajan yok.

Ağ tarafında, tek tıklamalı Azure Monitor deneyimiyle HTTP, gRPC ve Kafka trafiği için akış başına görünürlük eklediler. IP’ler, portlar, iş yükleri, akış yönü, politika kararları — hepsi yerleşik dashboard’larda.

Ve beni iki kez baktıran şu oldu: agentic container networking kümenizin ağ durumu hakkında doğal dil soruları sorabileceğiniz bir web UI ekliyor. “Pod X neden servis Y’ye ulaşamıyor?” → canlı telemetriden salt okunur tanılamalar. Gece 2’de gerçekten kullanışlı.

PhD Gerektirmeyen Kümeler Arası Ağ

Multi-cluster Kubernetes, tarihsel olarak “kendi ağ yapıştırıcınızı getirin” deneyimiydi. Azure Kubernetes Fleet Manager artık yönetilen Cilium cluster mesh üzerinden kümeler arası ağ sunuyor:

AKS kümeleri arasında birleşik bağlantı
Kümeler arası keşif için global servis kaydı
Merkezi olarak yönetilen, küme başına tekrarlanmayan konfigürasyon

Dayanıklılık veya uyumluluk için bölgeler arasında .NET mikro servisler çalıştırıyorsanız, bu çok sayıda kırılgan özel yapıştırıcının yerini alıyor. West Europe’daki A Servisi, tutarlı yönlendirme ve güvenlik politikalarıyla mesh üzerinden East US’deki B Servisini keşfedebilir ve çağırabilir.

Cesaret Gerektirmeyen Yükseltmeler

Dürüst olalım — üretimdeki Kubernetes yükseltmeleri streslidir. “Yükselt ve umut et” pek çok ekip için fiili strateji olmuştur ve kümelerin sürümlerin gerisinde kalmasının ana nedenidir.

İki yeni özellik bunu değiştiriyor:

Mavi-yeşil agent pool yükseltmeleri yeni konfigürasyonla paralel bir node pool oluşturur. Davranışı doğrulayın, trafiği kademeli olarak kaydırın ve temiz bir geri alma yolu tutun. Üretim node’larında artık yerinde mutasyon yok.

Agent pool rollback, bir yükseltme ters gittiğinde kümeyi yeniden oluşturmadan bir node pool’u önceki Kubernetes sürümüne ve node imajına döndürmenizi sağlar.

Birlikte ele alındığında, bunlar nihayet operatörlere yükseltme yaşam döngüsü üzerinde gerçek kontrol veriyor. .NET ekipleri için bu önemlidir çünkü platform hızı, yeni runtime’ları, güvenlik yamalarını ve ağ özelliklerini ne kadar hızlı benimseyebileceğinizi doğrudan belirler.

AI İş Yükleri Birinci Sınıf Kubernetes Vatandaşı Oluyor

Upstream açık kaynak çalışması da eşit derecede önemli. Dynamic Resource Allocation (DRA) Kubernetes 1.36’da GA’ya geçti, GPU planlamasını bir geçici çözüm yerine gerçek anlamda birinci sınıf bir özellik haline getirdi.

İzlemeye değer birkaç proje:

Proje	Ne Yapıyor
AI Runway	Çıkarım için ortak Kubernetes API’si — K8s bilmeden model dağıtın, HuggingFace keşfi ve maliyet tahminleriyle
HolmesGPT	Cloud-native için agentic sorun giderme — artık CNCF Sandbox projesi
Dalec	SBOM üretimiyle bildirimsel container imaj oluşturma — derleme aşamasında daha az CVE

Yön açık: .NET API’niz, Semantic Kernel orkestrasyon katmanınız ve çıkarım iş yüklerinizin hepsi tek tutarlı bir platform modelinde çalışmalı. Oraya doğru ilerliyoruz.

Bu Hafta Nereden Başlardım

Bu değişiklikleri ekibiniz için değerlendiriyorsanız, işte dürüst öncelik listem:

Önce gözlemlenebilirlik — üretim dışı bir kümede GPU metriklerini ve ağ akış günlüklerini etkinleştirin. Neyi kaçırdığınızı görün.
Mavi-yeşil yükseltmeleri deneyin — bir sonraki üretim kümesi yükseltmenizden önce rollback iş akışını test edin. Sürece güven inşa edin.
Kimlik farkında ağı pilot edin — bir dahili servis yolu seçin ve Cilium ile mTLS’i etkinleştirin. Yükü ölçün (spoiler: minimumdur).
Fleet Manager’ı değerlendirin — ikiden fazla küme çalıştırıyorsanız, kümeler arası ağ azaltılan özel yapıştırıcıyla kendini amorti eder.

Küçük deneyler, hızlı geri bildirim. Her zaman doğru hamle budur.

Son Söz

KubeCon duyuruları bunaltıcı olabiliyor, ancak bu grup gerçekten AKS’teki .NET ekipleri için iğneyi hareket ettiriyor. Mesh yükü olmadan daha iyi ağ güvenliği, gerçek GPU gözlemlenebilirliği, daha güvenli yükseltmeler ve daha güçlü AI altyapısı temelleri.

Halihazırda AKS’teyseniz, bu operasyonel temelinizi sıkılaştırmak için harika bir an. .NET iş yüklerini Kubernetes’e taşımayı planlıyorsanız — platform önemli ölçüde daha üretim hazır hale geldi.

SQL MCP Server, SSMS'de Copilot ve AI Agentlı Veritabanı Hub'ı: SQLCon 2026'dan Gerçekten Önemli Olanlar

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft, Atlanta’da FabCon ile birlikte SQLCon 2026’yı başlattı ve açılacak çok şey var. Orijinal duyuru, tasarruf planlarından kurumsal uyumluluk özelliklerine kadar her şeyi kapsıyor. Kurumsal fiyatlandırma slaytlarını atlayarak, Azure SQL ve AI ile bir şeyler geliştiren bir geliştirici olarak önemli olanlara odaklanacağım.

SQL MCP Server genel önizlemede

Bu, benim için manşet. Azure SQL Database Hyperscale artık, Model Context Protocol kullanarak SQL verilerinizi AI agentlarına ve Copilot’lara güvenli biçimde bağlamanıza olanak tanıyan genel önizlemede bir SQL MCP Server‘a sahip.

MCP dalgasını takip ediyorsanız — ve dürüst olmak gerekirse, şu anda bunu kaçırmak zor — bu büyük bir gelişme. AI agentlarınıza veritabanından bağlam sağlamak için özel veri pipeline’ları oluşturmak yerine, SQL verilerini doğrudan sergilemek için standart bir protokol elde ediyorsunuz. Agentlarınız canlı veritabanı bilgilerini sorgulayabilir, üzerinde akıl yürütebilir ve harekete geçebilir.

Semantic Kernel veya Microsoft Agent Framework ile AI agentları geliştiriyoruz için bu, temiz bir entegrasyon yolu açıyor. Agentınızın envanteri kontrol etmesi mi gerekiyor? Müşteri kaydına bakması mı? Bir siparişi doğrulaması mı? MCP, her senaryo için özel veri-getirme kodu yazmadan bunu yapmanın yapılandırılmış bir yolunu sunar.

SSMS 22’de GitHub Copilot artık GA’da

SQL Server Management Studio’da zaman geçiriyorsanız — ve dürüst olalım, çoğumuz hâlâ geçiriyoruz — GitHub Copilot artık SSMS 22’de genel kullanım için hazır. VS Code ve Visual Studio’da zaten kullandığınız Copilot deneyiminin aynısı, ama T-SQL için.

Buradaki pratik değer açık: sorgu yazma, saklı yordam yeniden düzenleme, performans sorunlarını giderme ve yönetim görevleri için sohbet tabanlı yardım. Kavram olarak devrimci bir şey yok, ama SSMS’in içinde olması, veritabanı işleriniz için AI yardımı almak üzere başka bir editöre geçmenize gerek kalmadığı anlamına gelir.

Vektör indeksler ciddi bir yükseltme aldı

Azure SQL Database artık tam ekleme, güncelleme ve silme desteğiyle daha hızlı, daha yetenekli vektör indekslerine sahip. Bu, vektör verilerinizin gerçek zamanlı güncel kalması anlamına gelir — toplu yeniden indeksleme gerekmez.

İşte yenilikler:

Daha küçük indeks boyutları için fazla doğruluk kaybetmeden quantization (niceleme)
Daha hassas sonuçlar için iterative filtering (yinelemeli filtreleme)
Öngörülebilir performans için daha sıkı sorgu optimize edici entegrasyonu

Azure SQL’i vektör deposu olarak kullanarak RAG (Retrieval-Augmented Generation) yapıyorsanız, bu iyileştirmeler doğrudan işe yarar. Vektörlerinizi aynı veritabanındaki ilişkisel verilerle birlikte tutabilirsiniz; bu, ayrı bir vektör veritabanı çalıştırmaya kıyasla mimarinizi önemli ölçüde basitleştirir.

Aynı vektör geliştirmeleri Fabric’teki SQL veritabanında da mevcut; çünkü her ikisi de aynı SQL motoru üzerinde çalışıyor.

Fabric’te Database Hub: ajanlı yönetim

Bu daha ileriye dönük ama ilginç. Microsoft, Azure SQL, Cosmos DB, PostgreSQL, MySQL ve Arc üzerinden SQL Server genelinde tek bir cam panel sunan Microsoft Fabric’te Database Hub‘ı (erken erişim) duyurdu.

İlginç taraf, yalnızca birleşik görünüm değil — yönetimin ajanlı yaklaşımı. AI agentlar veritabanı altyapınızı sürekli izler, nelerin değiştiğini öne çıkarır, neden önemli olduğunu açıklar ve ne yapılması gerektiğini önerir. Agentın ön çalışmayı yaptığı ve siz kararları aldığınız bir human-in-the-loop modelidir.

Ondan fazla veritabanını yöneten ekipler için bu, operasyonel gürültüyü gerçekten azaltabilir. Portaller arasında atlayıp metrikleri manuel olarak kontrol etmek yerine, agent sinyali size getirir.

.NET geliştiricileri için ne anlama geliyor

Tüm bu duyuruları birbirine bağlayan ip açık: Microsoft, veritabanı yığınının her katmanına AI agentları yerleştiriyor. Bir hile olarak değil, pratik bir araç katmanı olarak.

Azure SQL tarafından desteklenen .NET uygulamaları geliştiriyorsanız, gerçekten yapacaklarım şunlar:

AI agentları geliştiriyorsanız SQL MCP Server’ı deneyin. Agentlarınıza özel bağlantı kodu olmadan veritabanı erişimi vermenin en temiz yolu.
Henüz yapmadıysanız SSMS’de Copilot’u etkinleştirin — günlük SQL çalışması için ücretsiz üretkenlik kazanımı.
RAG yapıyorsanız ve şu anda ayrı bir vektör deposu çalıştırıyorsanız vektör indekslerine bakın. Azure SQL’de birleştirmek, yönetilecek bir servis daha az demek.

Sonuç

Tam duyuruda daha fazlası var — tasarruf planları, geçiş asistanları, uyumluluk özellikleri — ancak geliştirici hikayesi MCP Server’da, vektör iyileştirmelerinde ve ajanlı yönetim katmanında. Bunlar, bütçenizi değil, oluşturduğunuz şeyleri değiştiren parçalar.

Tam tablo için Shireesh Thota’nın tam duyurusuna göz atın; yeni yönetim deneyimini denemek istiyorsanız Database Hub erken erişimine kaydolun.

Azure DevOps MCP Server Microsoft Foundry'ye Geldi: AI Agent'larınız İçin Ne Anlama Geliyor

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) son dönemde çok konuşuluyor. AI agent ekosistemine dikkat ettiyseniz, MCP server’ların her yerde belirdiğini fark etmişsinizdir — agent’lara standart bir protokol üzerinden harici araçlar ve servislerle etkileşim kurma yeteneği kazandırıyorlar.

Artık Azure DevOps MCP Server Microsoft Foundry’de mevcut ve bu, pratik olasılıklar üzerine düşündüren entegrasyonlardan biri.

Aslında ne oluyor

Microsoft, Azure DevOps MCP Server’ı genel önizleme olarak zaten yayınlamıştı — bu MCP server’ın kendisi. Yeni olan şey ise Foundry entegrasyonu. Artık Azure DevOps MCP Server’ı araç kataloğundan doğrudan Foundry agent’larınıza ekleyebilirsiniz.

Foundry’ye henüz aşina olmayanlar için: Microsoft’un AI destekli uygulama ve agent’ları ölçekli şekilde oluşturma ve yönetme için birleşik platformu. Model erişimi, orkestrasyon, değerlendirme, dağıtım — hepsi tek bir yerde.

Kurulum

Kurulum şaşırtıcı derecede basit:

Foundry agent’ınızda Add Tools > Catalog bölümüne gidin
“Azure DevOps” arayın
Azure DevOps MCP Server (önizleme) seçin ve Create tıklayın
Organizasyon adınızı girin ve bağlanın

Hepsi bu. Agent’ınız artık Azure DevOps araçlarına erişebilir.

Agent’ınızın nelere erişeceğini kontrol etme

Takdir ettiğim kısım şu: ya hep ya hiç yaklaşımına mahkum değilsiniz. Agent’ınıza hangi araçların sunulacağını belirtebilirsiniz. Yalnızca iş öğelerini okusun ama pipeline’lara dokunmasın istiyorsanız bunu yapılandırabilirsiniz. En az ayrıcalık ilkesi, AI agent’larınıza uygulanmış hali.

Bu, birinin “sürümle ilgili yardım et” demesi üzerine agent’ın kazara bir dağıtım pipeline’ını tetiklemesini istemediğiniz kurumsal senaryolarda önem taşıyor.

Bu .NET ekipleri için neden ilginç

Pratikte neleri mümkün kıldığını düşünün:

Sprint planlama asistanları — iş öğelerini çekebilen, hız verilerini analiz edebilen ve sprint kapasitesi önerebilen agent’lar
Kod inceleme botları — repolarınızı ve bağlantılı iş öğelerinizi gerçekten okuyabildikleri için PR bağlamınızı anlayan agent’lar
Olay müdahalesi — iş öğesi oluşturabilen, son dağıtımları sorgulayabilen ve hataları son değişikliklerle ilişkilendirebilen agent’lar
Geliştirici onboarding’i — “Ne üzerinde çalışmalıyım?” sorusuna gerçek proje verileriyle desteklenmiş gerçek bir yanıt

CI/CD pipeline’ları ve proje yönetimi için Azure DevOps’u zaten kullanan .NET ekipleri için, bir AI agent’ının bu sistemlerle doğrudan etkileşim kurabilmesi, yararlı otomasyona doğru önemli bir adım (sıradan chatbot-as-a-service değil).

Daha geniş MCP resmi

Bu, daha geniş bir trendin parçası: MCP server’lar, AI agent’larının dış dünyayla etkileşim kurmasının standart yolu haline geliyor. GitHub, Azure DevOps, veritabanları, SaaS API’leri için MCP server’lar görüyoruz — ve Foundry, tüm bu bağlantıların bir araya geldiği merkez haline geliyor.

.NET ekosisteminde agent geliştiriyorsanız MCP’ye dikkat etmeye değer. Protokol standartlaşmış, araç kitleri olgunlaşıyor ve Foundry entegrasyonu, server bağlantılarını manuel olarak kurmak zorunda kalmadan erişilebilir hale getiriyor.

Sonuç

Foundry’deki Azure DevOps MCP Server önizleme aşamasında, bu yüzden gelişmeye devam etmesini bekleyin. Ancak temel iş akışı sağlam: bağlanın, araç erişimini yapılandırın ve agent’larınızın DevOps verilerinizle çalışmasına izin verin. Zaten Foundry ekosistemindeyseniz, birkaç tıklama uzaktasınız. Bir deneyin ve hangi iş akışlarını oluşturabileceğinizi görün.

Adım adım kurulum ve daha fazla ayrıntı için tam duyuruya göz atın.

Dizüstü Bilgisayardan Üretime: İki Komutla AI Agent'larını Microsoft Foundry'ye Dağıtma

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

“Makinemde çalışıyor” ile “dağıtıldı ve trafik sunuyor” arasındaki o boşluğu bilirsiniz? AI agent’ları için bu boşluk acı verici derecede geniş oldu. Kaynak sağlamanız, modelleri dağıtmanız, kimliği bağlamanız, izlemeyi kurmanız gerekiyor — ve bütün bunlar herhangi biri agent’ınızı çağırabilmeden önce.

Azure Developer CLI bunu iki komutluk bir iş haline getirdi.

Yeni `azd ai agent` iş akışı

Bunun gerçekte nasıl göründüğünü anlatalım. Bir AI agent projeniz var — diyelim ki bir otel danışman agent’ı. Yerel olarak çalışıyor. Microsoft Foundry üzerinde çalışmasını istiyorsunuz.

azd ai agent init
azd up

Hepsi bu. İki komut. azd ai agent init, reponuzda altyapı-kod olarak iskele oluşturur ve azd up her şeyi Azure’da sağlayıp agent’ınızı yayımlar. Foundry portalında agent’ınıza doğrudan bir bağlantı alırsınız.

Arka planda ne oluyor

init komutu reponuzda gerçek, incelenebilir Bicep şablonları oluşturuyor:

Bir Foundry Kaynağı (üst düzey kapsayıcı)
Bir Foundry Projesi (agent’ınızın bulunduğu yer)
Model dağıtımı yapılandırması (GPT-4o vb.)
Uygun RBAC rol atamalarıyla Yönetilen kimlik
Servis haritası için azure.yaml
Agent meta verileri ve ortam değişkenleriyle agent.yaml

İşte kilit nokta: bunların hepsi size ait. Reponuzda sürümlendirilmiş Bicep. İnceleyebilir, özelleştirebilir ve agent kodunuzun yanı sıra commit edebilirsiniz. Sihirli kara kutular yok.

Geliştirme döngüsü

Gerçekten beğendiğim şey yerel geliştirme hikayesi. Agent mantığını geliştirirken, her prompt değişikliğinde yeniden dağıtmak istemezsiniz:

azd ai agent run

Bu, agent’ınızı yerel olarak başlatır. Bunu test promptları göndermek için azd ai agent invoke ile eşleştirin, sıkı bir geri bildirim döngüsü elde edersiniz. Kodu düzenleyin, yeniden başlatın, çağırın, tekrarlayın.

invoke komutu yönlendirme konusunda da akıllı — yerel bir agent çalışırken otomatik olarak onu hedefler. Çalışmıyorken uzak endpoint’e isabet eder.

Gerçek zamanlı izleme

Bu beni ikna eden özellik. Agent’ınız dağıtıldığında:

azd ai agent monitor --follow

Agent’ınızdan geçen her istek ve yanıt gerçek zamanlı olarak terminalinize akıyor. Üretim sorunlarını hata ayıklamak için bu paha biçilmez. Log analitiğini karıştırmak yok, metriklerin toplanmasını beklemek yok — şu an ne olduğunu görüyorsunuz.

Tam komut seti

İşte hızlı referans:

Komut	Ne yapıyor
`azd ai agent init`	IaC ile bir Foundry agent projesi iskele oluşturur
`azd up`	Azure kaynaklarını sağlar ve agent’ı dağıtır
`azd ai agent invoke`	Uzak veya yerel agent’a prompt gönderir
`azd ai agent run`	Geliştirme için agent’ı yerel olarak çalıştırır
`azd ai agent monitor`	Yayımlanan agent’dan gerçek zamanlı logları akıtır
`azd ai agent show`	Agent sağlığını ve durumunu kontrol eder
`azd down`	Tüm Azure kaynaklarını temizler

.NET geliştiricileri için neden önemli

Duyuruda örnek Python tabanlı olsa da, altyapı hikayesi dilden bağımsız. .NET agent’ınız aynı Bicep iskeleleme, aynı yönetilen kimlik kurulumu, aynı izleme pipeline’ı alıyor. .NET Aspire uygulamalarınız veya Azure dağıtımları için zaten azd kullanıyorsanız, bu mevcut iş akışınıza tam oturuyor.

AI agent’ları için dağıtım boşluğu, ekosistemdeki en büyük sürtüşme noktalarından biri oldu. Çalışan bir prototipi uygun kimlik, ağ ve izlemeyle bir üretim endpoint’ine götürmek bir haftalık DevOps çalışması gerektirmemeli. Artık iki komut ve birkaç dakika gerektiriyor.

Sonuç

azd ai agent şu an mevcut. AI agent’larınızı dağıtmayı erteliyorsanız çünkü altyapı kurulumu çok fazla iş gibi geliyordu, bunu bir deneyin. Ön uç sohbet uygulaması entegrasyonu dahil adım adım tam kılavuz için tam anlatıma göz atın.

Foundry Agent Service GA'ya Geçti: .NET Agent Geliştiricileri İçin Gerçekten Önemli Olan Nedir?

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Kabul edelim — bir AI agent prototipi oluşturmak kolay kısım. Zor olan ise sonrasındaki her şey: uygun ağ izolasyonuyla üretime almak, gerçekten anlamlı değerlendirmeler yapmak, uyumluluk gereksinimlerini karşılamak ve gece 2’de her şeyin çökmemesini sağlamak.

Foundry Agent Service az önce GA’ya geçti ve bu sürüm tam da bu “sonrasındaki her şey” boşluğuna odaklanıyor.

Responses API Üzerine İnşa Edildi

İşte manşet haber: yeni nesil Foundry Agent Service, OpenAI Responses API üzerine kurulu. Eğer bu wire protokolüyle zaten geliştirme yapıyorsanız, Foundry’ye geçiş minimal kod değişikliği gerektiriyor. Kazandıklarınız: kurumsal güvenlik, özel ağ desteği, Entra RBAC, tam izleme ve değerlendirme — mevcut agent mantığınızın üstüne.

Mimari kasıtlı olarak açık tasarlanmış. Tek bir model sağlayıcısına veya tek bir orkestrasyon framework’üne bağlı değilsiniz. Planlama için DeepSeek, üretim için OpenAI, orkestrasyon için LangGraph kullanabilirsiniz — runtime tutarlılık katmanını halleder.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Özel Ağ Desteği: Kurumsal Engel Kaldırıldı

Bu, kurumsal benimsemeyi engelleyen sorunu ortadan kaldıran özelliktir. Foundry artık BYO VNet ile uçtan uca tam özel ağ desteği sunuyor:

Genel çıkış yok — agent trafiği hiçbir zaman genel internete çıkmıyor
Container/alt ağ enjeksiyonu yerel iletişim için ağınıza entegre ediliyor
Araç bağlantısı dahil — MCP server’lar, Azure AI Search, Fabric data agent’ları hepsi özel yollar üzerinden çalışıyor

Son nokta kritik. Yalnızca çıkarım çağrıları değil, her araç çağrısı ve her veri alma işlemi de ağ sınırınızın içinde kalıyor. Dışarıya yönlendirmeyi yasaklayan veri sınıflandırma politikaları altında çalışan ekipler için işte bu eksik olan parçaydı.

Doğru Yapılmış MCP Kimlik Doğrulaması

MCP server bağlantıları artık tüm auth pattern yelpazesini destekliyor:

Auth Yöntemi	Ne Zaman Kullanılır
Key tabanlı	Kurum geneli dahili araçlar için basit paylaşımlı erişim
Entra Agent Identity	Servisten servise; agent kendisi olarak kimlik doğrular
Entra Managed Identity	Proje bazında izolasyon; kimlik bilgisi yönetimi yok
OAuth Identity Passthrough	Kullanıcı delegeli erişim; agent kullanıcılar adına hareket eder

OAuth Identity Passthrough ilginç olan. Kullanıcıların bir agent’a kişisel verilerine — OneDrive’larına, Salesforce organizasyonlarına, kullanıcı kapsamlı bir SaaS API’sine — erişim vermesi gerektiğinde, agent standart OAuth akışlarıyla onlar adına hareket eder. Herkesi temsil etmeye çalışan paylaşımlı bir sistem kimliği yok.

Voice Live: Tesisatla Uğraşmadan Konuşmadan Konuşmaya

Bir agent’a ses eklemek eskiden STT, LLM ve TTS’i bir araya getirmek anlamına geliyordu — üç servis, üç gecikme adımı, üç faturalama yüzeyi, hepsi elle senkronize. Voice Live bunu tek bir yönetilen API’ye indirgiyor:

Semantik ses aktivitesi ve konuşma sonu algılama (anlamı anlıyor, sadece sessizliği değil)
Sunucu taraflı gürültü bastırma ve yankı giderme
Araya girme desteği (kullanıcılar yanıt ortasında sözü kesebilir)

Ses etkileşimleri, metinle aynı agent runtime’ından geçiyor. Aynı değerlendiriciler, aynı izler, aynı maliyet görünürlüğü. Müşteri desteği, saha hizmeti veya erişilebilirlik senaryoları için bu, daha önce özel bir ses pipeline’ı gerektiren şeyin yerini alıyor.

Değerlendirmeler: Onay Kutusundan Sürekli İzlemeye

Foundry’nin üretim kalitesi konusunda ciddiye geldiği yer burası. Değerlendirme sistemi artık üç katmana sahip:

Hazır değerlendiriciler — tutarlılık, alaka, temellendirilme, erişim kalitesi, güvenlik. Bir veri kümesine veya canlı trafiğe bağlayın, puanları geri alın.
Özel değerlendiriciler — kendi iş mantığınızı, ton standartlarınızı ve alana özgü uyumluluk kurallarınızı kodlayın.
Sürekli değerlendirme — Foundry canlı üretim trafiğini örnekliyor, değerlendirici paketinizi çalıştırıyor ve sonuçları dashboard’lar aracılığıyla sunuyor. Temellendirilme düştüğünde veya güvenlik eşikleri aşıldığında Azure Monitor uyarıları ayarlayın.

Her şey Azure Monitor Application Insights’a yayımlanıyor. Agent kalitesi, altyapı sağlığı, maliyet ve uygulama telemetrisi — hepsi tek bir yerde.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Barındırılan Agent’lar İçin Altı Yeni Bölge

Barındırılan agent’lar artık East US, North Central US, Sweden Central, Southeast Asia, Japan East ve daha fazlasında kullanılabilir. Bu, veri yerleşim gereksinimleri için ve agent’ınız veri kaynaklarına yakın çalıştığında gecikmeyi azaltmak için önemlidir.

.NET Geliştiricileri İçin Neden Önemli?

GA duyurusundaki kod örnekleri Python öncelikli olsa da, altta yatan altyapı dilden bağımsız — ve azure-ai-projects için .NET SDK aynı pattern’leri takip ediyor. Responses API, değerlendirme framework’ü, özel ağ desteği, MCP auth — bunların hepsi .NET’ten erişilebilir.

AI agent’larının “harika demo” aşamasından “bunu işte gerçekten gönderebilirim” aşamasına geçmesini bekliyorsanız, bu GA sürümü sinyaldir. Özel ağ desteği, uygun auth, sürekli değerlendirme ve üretim izleme — işte eksik olan parçalar bunlardı.

Son Söz

Foundry Agent Service şu anda kullanılabilir. SDK’yı kurun, portal’ı açın ve geliştirmeye başlayın. Hızlı başlangıç kılavuzu sıfırdan çalışan bir agent’a dakikalar içinde ulaştırıyor.

Tüm kod örnekleriyle birlikte tam teknik derinlemesine bakış için GA duyurusunu inceleyin.

Microsoft Agent Framework'te Arka Plan Yanıtları: Zaman Aşımı Kaygısına Son

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

o3 veya GPT-5.2 gibi akıl yürütme modelleriyle bir şeyler geliştirdiyseniz, o acıyı biliyorsunuzdur. Agent’ınız karmaşık bir görev üzerinde düşünmeye başlıyor, istemci beklemeye devam ediyor ve “bu tamam” ile “çöktü mü acaba?” arasında bir yerde bağlantınız zaman aşımına uğruyor. Tüm o emek? Gitti.

Microsoft Agent Framework yeni arka plan yanıtlarını yayınladı — ve dürüst olmak gerekirse bu, ilk günden beri var olması gereken özelliklerden biri.

Engelleyen çağrıların sorunu

Geleneksel istek-yanıt kalıbında, agent işini bitirene kadar istemciniz bekler. Hızlı görevler için bu sorunsuz çalışır. Ama bir akıl yürütme modelinden derin araştırma, çok adımlı analiz veya 20 sayfalık rapor oluşturması istediğinizde? Gerçek zamanlı dakikalar söz konusu. Bu pencerede:

HTTP bağlantıları zaman aşımına uğrayabilir
Ağ kesintileri tüm işlemi mahvedebilir
Kullanıcınız bir şeylerin olup olmadığını merak ederek dönen bir simgeye bakmak zorunda kalır

Arka plan yanıtları bunu tersine çeviriyor.

Continuation token’lar nasıl çalışır

Engellemek yerine, agent görevini başlatırsınız ve geriye bir continuation token alırsınız. Bunu bir tamirhanedeki teslimat fişi gibi düşünün — tezgahın önünde beklemezsiniz, hazır olduğunda gelirsiniz.

Akış basit:

AllowBackgroundResponses = true ile isteğinizi gönderin
Agent arka plan işlemeyi destekliyorsa bir continuation token alırsınız
Token null döndürene kadar kendi zamanlamanızda sorgulama yapın — bu, sonucun hazır olduğu anlamına gelir

.NET versiyonu şöyle:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Tamamlanana kadar sorgula
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Agent hemen tamamlarsa (basit görevler, arka plan işleme gerektirmeyen modeller), continuation token döndürülmez. Kodunuz sadece çalışır — özel bir işlem gerekmez.

Devam ettirme özellikli streaming: asıl sihir

Sorgulama, fırlat-unut senaryoları için uygun, ama gerçek zamanlı ilerleme izlemek istediğinizde ne olur? Arka plan yanıtları aynı zamanda yerleşik devam ettirme özelliğiyle streaming’i de destekliyor.

Her streaming güncellemesi kendi continuation token’ını taşıyor. Bağlantınız streaming ortasında kesilirse, tam kaldığınız yerden devam ediyorsunuz:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Ağ kesintisini simüle et
}

// Tam kaldığımız yerden devam et
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Agent, istemcinizde ne olursa olsun sunucu tarafında işlemeye devam ediyor. Bu, retry mantığı veya circuit breaker yazmadan yerleşik hata toleransı demek.

Bunu gerçekten ne zaman kullanmalısınız

Her agent çağrısının arka plan yanıtlarına ihtiyacı yok. Hızlı tamamlamalar için gereksiz yere karmaşıklık ekliyor olursunuz. Ama bunların parlattığı durumlar şunlar:

Karmaşık akıl yürütme görevleri — çok adımlı analiz, derin araştırma, bir akıl yürütme modelinin gerçekten düşünmesi gereken her şey
Uzun içerik üretimi — ayrıntılı raporlar, çok bölümlü belgeler, kapsamlı analizler
Güvenilmez ağlar — mobil istemciler, edge dağıtımlar, kararsız kurumsal VPN’ler
Asenkron UX kalıpları — görevi gönder, başka bir şey yap, sonuçlar için geri gel

Kurumsal uygulamalar geliştiren .NET geliştiricileri olarak bizim için özellikle son madde ilginç. Kullanıcının karmaşık bir rapor talep ettiği bir Blazor uygulaması düşünün — agent görevini başlatırsınız, ilerleme göstergesi gösterirsiniz ve kullanıcının çalışmaya devam etmesine izin verirsiniz. WebSocket karmaşası yok, özel kuyruk altyapısı yok, sadece bir token ve bir sorgulama döngüsü.

Sonuç

Arka plan yanıtları Microsoft Agent Framework üzerinden şu anda hem .NET hem de Python’da mevcut. Basit soru-cevabın ötesinde herhangi bir şey yapan agent’lar geliştiriyorsanız, bunu araç kutunuza eklemeye değer. Continuation token kalıbi, gerçek bir üretim sorununu çözerken işleri basit tutuyor.

Tam API referansı ve daha fazla örnek için belgelere bakın.