Ai | The .NET Blog

Agent Framework'te CodeAct: Ajanınızın Gecikmesini Yarıya Nasıl İndirirsiniz

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.

Her ajan projesinde, izlemeye bakıp “bu neden bu kadar uzun sürüyor?” diye düşündüğünüz bir an gelir. Model iyi çalışıyor. Araçlar çalışıyor. Ama tek seferinde hesaplanabilecek bir sonuç için yedi gidiş-dönüş oluyor.

CodeAct’ın tam olarak çözdüğü sorun bu — ve Agent Framework ekibi yeni agent-framework-hyperlight paketiyle alfa destek yayınladı.

CodeAct Nedir?

CodeAct deseni zarifçe basittir: Modele tek tek çağrılacak araçların listesini vermek yerine, tek bir execute_code aracı verin ve planın tamamını kısa bir Python programı olarak ifade etmesine izin verin.

Yaklaşım	Süre	Token
Geleneksel	27.81s	6.890
CodeAct	13.23s	2.489
İyileştirme	%52.4	%63.9

Güvenlik: Hyperlight Mikro-VM’leri

agent-framework-hyperlight paketi Hyperlight mikro-VM’leri kullanır. Her execute_code çağrısı kendi yeni mikro-VM’ini alır. Başlatma milisaniyelerle ölçülür. İzolasyon neredeyse ücretsizdir.

Araçlarınız ana bilgisayarda çalışmaya devam eder. Modelin oluşturduğu yapıştırıcı kod sandbox’ta çalışır. Bu doğru ayrımdır.

Minimum Kurulum

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

CodeAct Ne Zaman Kullanılır (Ne Zaman Kullanılmaz)

CodeAct kullanın:

Görev birçok küçük araç çağrısını zincirliyor (aramalar, birleştirmeler, hesaplamalar)
Gecikme ve token maliyeti önemliyse
Model tarafından oluşturulan kod için güçlü izolasyon istiyorsanız

Geleneksel araç çağrısında kalın:

Ajan tur başına yalnızca bir iki araç çağrısı yapıyorsa
Her çağrının bireysel onay gerektiren yan etkileri varsa

Şimdi Deneyin

pip install agent-framework-hyperlight --pre

Agent Framework blogundaki tam gönderiyi okuyun.

Ajanınız Şeyleri Nerede Hatırlıyor? Sohbet Geçmişi Depolama için Pratik Rehber

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.

Bir AI ajanı oluştururken enerjinizin büyük bölümünü modele, araçlara ve istemlere harcarsınız. Konuşma geçmişinin nerede tutulduğu sorusu bir uygulama ayrıntısı gibi görünür — ancak alacağınız en önemli mimari kararlardan biridir.

Kullanıcıların konuşmaları dallandırıp dallandıramayacağını, yanıtları geri alıp alamayacağını, yeniden başlatmadan sonra oturumları devam ettirip ettiremeyeceğini ve verilerinizin altyapınızı terk edip etmediğini belirler. Agent Framework ekibi derinlemesine bir analiz yayımladı.

İki temel desen

Servis tarafından yönetilen: AI servisi konuşma durumunu depolar. Uygulamanız bir referans tutar ve servis her istekte ilgili geçmişi otomatik olarak ekler.

İstemci tarafından yönetilen: Uygulamanız tam geçmişi tutar ve her istekte ilgili mesajları gönderir. Servis durumsuzdur. Her şeyi siz kontrol edersiniz.

Agent Framework bunu nasıl soyutlar

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Adım Alice.", session);
var second = await agent.RunAsync("Benim adım ne?", session);

session = agent.create_session()
first = await agent.run("Adım Alice.", session=session)
second = await agent.run("Benim adım ne?", session=session)

Sağlayıcı hızlı referans

Sağlayıcı	Depolama	Model	Sıkıştırma
OpenAI/Azure Chat Completions	İstemci	Yok	Siz
Foundry Agent Service	Servis	Doğrusal	Servis
Responses API (varsayılan)	Servis	Dallanma	Servis
Anthropic Claude, Ollama	İstemci	Yok	Siz

Nasıl seçilir

Dallanma veya “geri al” gerekiyor mu? → Servis tarafından yönetilen Responses API
Veri egemenliği gerekiyor mu? → DB destekli istemci tarafından yönetilen
Basit bir sohbet botu mu? → Servis tarafından yönetilen doğrusal yeterli

Tam karar ağacı için tam makaleyi okuyun.

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.

Windows App Dev CLI v0.3: Terminalden F5 Hata Ayıklama ve Ajanlar için UI Otomasyonu

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

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

Visual Studio’nun F5 deneyimi harika. Ama yalnızca paketlenmiş bir Windows uygulamasını başlatıp hata ayıklamak için VS’yi açmak — bir CI boru hattında, otomatik bir iş akışında veya bir yapay zeka ajanı testleri çalıştırırken — fazla ağır bir yük.

Windows App Development CLI v0.3 yayınlandı ve bunu iki temel özellikle doğrudan ele alıyor: winapp run ve winapp ui.

winapp run: Her yerden F5

winapp run paketlenmemiş bir uygulama klasörü ve manifest alır; VS’nin hata ayıklama başlatmasında yaptığı her şeyi yapar: loose paket kaydeder, uygulamayı başlatır ve yeniden dağıtımlar arasında LocalState‘i korur.

# Uygulamayı derleyin, ardından paketlenmiş uygulama olarak çalıştırın
winapp run ./bin/Debug

WinUI, WPF, WinForms, Console, Avalonia ve daha fazlası için çalışır. Modlar hem geliştiriciler hem de otomatik iş akışları için tasarlanmıştır:

--detach: Başlatır ve hemen terminale kontrolü geri döndürür. CI için ideal.
--unregister-on-exit: Uygulama kapatıldığında kayıtlı paketi temizler.
--debug-output: OutputDebugString mesajlarını ve istisnaları gerçek zamanlı yakalar.

Yeni NuGet Paketi: Paketlenmiş uygulamalar için dotnet run

.NET geliştiricileri için yeni bir NuGet paketi var: Microsoft.Windows.SDK.BuildTools.WinApp. Kurulumdan sonra dotnet run tüm iç döngüyü yönetir: derleme, loose-layout paketi hazırlama, Windows’ta kayıt ve başlatma — tek adımda.

winapp init
# veya
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: Komut satırından UI Otomasyonu

Bu, ajan senaryolarını açan özellik. winapp ui, terminalden çalışan herhangi bir Windows uygulamasına (WPF, WinForms, Win32, Electron, WinUI3) tam UI Automation erişimi sağlar.

Yapılabilecekler:

Tüm üst düzey pencereleri listele
Herhangi bir pencerenin tam UI Automation ağacında gezin
Ad, tür veya otomasyon kimliğine göre öğe ara
Tıkla, çağır ve değer ayarla
Ekran görüntüsü al
Öğelerin görünmesini bekle — test senkronizasyonu için ideal

winapp ui ile winapp run‘ı birleştirmek, terminalden eksiksiz bir derleme → başlatma → doğrulama iş akışı sağlar. Bir ajan uygulamayı çalıştırabilir, UI durumunu inceleyebilir, programatik olarak etkileşime girebilir ve sonucu doğrulayabilir.

Diğer yenilikler

winapp unregister: Tamamlandığında yandan yüklenmiş paketi kaldırır.
winapp manifest add-alias: Terminalden adıyla uygulama başlatmak için takma ad ekler.
Sekme tamamlama: PowerShell tamamlamayı tek komutla yapılandırın.

Nasıl edinilir

winget install Microsoft.WinAppCli
# veya
npm install -g @microsoft/winappcli

CLI genel önizleme aşamasında. Tam belgeleme için GitHub deposuna, tüm ayrıntılar için orijinal duyuruya bakın.

VS Code 1.117: Agentlar Artık Kendi Git Dallarını Alıyor ve Ben Bunun İçin Buradayım

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

“AI asistanı” ile “AI takım üyesi” arasındaki çizgi giderek inceliyor. VS Code 1.117 az önce yayınlandı ve tam sürüm notları çok şey içeriyor, ancak buradaki hikaye açık: agentlar geliştirme iş akışınızda birinci sınıf vatandaş haline geliyor.

İşte gerçekten önemli olan şeyler.

Autopilot modu artık tercihinizi hatırlıyor

Daha önce her yeni oturum başlattığınızda Autopilot’u yeniden etkinleştirmeniz gerekiyordu. Can sıkıcıydı. Artık izin modunuz oturumlar arasında korunuyor ve varsayılanı yapılandırabiliyorsunuz.

Agent Host üç oturum yapılandırmasını destekliyor:

Default — araçlar çalışmadan önce onay istiyor
Bypass — her şeyi otomatik onaylıyor
Autopilot — tamamen özerk, kendi sorularını yanıtlıyor ve devam ediyor

Migrasyonlar, Docker ve CI ile yeni bir .NET projesi kuruyorsanız — Autopilot’u bir kez ayarlayın ve unutun. O tercih kalıcı.

Agent oturumları için worktree ve git izolasyonu

Bu en büyük özellik. Agent oturumları artık tam worktree ve git izolasyonunu destekliyor. Bu, bir agent bir görev üzerinde çalışırken kendi dalını ve çalışma dizinini aldığı anlamına geliyor. Ana dalınız dokunulmadan kalıyor.

Daha da iyisi — Copilot CLI bu worktree oturumları için anlamlı dal adları üretiyor. Artık agent-session-abc123 yok. Agentin ne yaptığını gerçekten açıklayan bir şey alıyorsunuz.

Birden fazla özellik dalı üzerinde çalışan veya uzun bir iskele görevi çalışırken hata düzelten .NET geliştiricileri için bu oyun değiştirici. Bir worktree’de API controller’larınızı oluşturan bir agent varken siz başka bir worktree’de servis katmanı sorununu ayıklıyor olabilirsiniz. Çakışma yok. Stash yok. Karmaşa yok.

Alt-agentlar ve agent ekipleri

Agent Host Protocol artık alt-agentları destekliyor. Bir agent, bir görevin parçalarını yönetmek için başka agentlar çalıştırabilir. Görevlendirme gibi düşünün — ana agent koordine eder, uzman agentlar parçaları yönetir.

Bu erken aşamada, ancak .NET iş akışları için potansiyel açık. EF Core migrasyonlarınızı yöneten bir agent varken diğeri entegrasyon testlerinizi kuruyor, bunu hayal edin. Tam olarak oraya henüz ulaşmadık, ancak protokol desteğinin şimdi gelmesi tooling’in hızla takip edeceği anlamına geliyor.

Agentlar girdi gönderdiğinde terminal çıktısı otomatik dahil ediliyor

Küçük ama anlamlı. Bir agent terminale girdi gönderdiğinde, terminal çıktısı artık otomatik olarak bağlama dahil ediliyor. Daha önce, agent ne olduğunu görmek için ekstra bir tur atmak zorundaydı.

Bir agentin dotnet build çalıştırdığını, başarısız olduğunu ve ardından hatayı görmek için başka bir gidiş-dönüş yaptığını izlediyseniz — bu sürtünme gitti. Çıktıyı hemen görüyor ve tepki veriyor.

macOS’ta Agents uygulaması kendi kendini güncelliyor

macOS’taki bağımsız Agents uygulaması artık kendi kendini güncelliyor. Artık yeni sürümleri manuel olarak indirmeye gerek yok. Güncel kalıyor.

Bilmeye değer küçük şeyler

package.json hover’ları artık hem yüklü sürümü hem de mevcut en son sürümü gösteriyor. .NET projelerinizin yanında npm tooling yönetiyorsanız kullanışlı.
JSDoc yorumlarındaki resimler hover ve tamamlamalarda doğru şekilde render ediliyor.
Copilot CLI oturumları artık VS Code tarafından mı yoksa harici olarak mı oluşturulduklarını gösteriyor — terminaller arasında atlıyorsanız kullanışlı.
Copilot CLI, Claude Code ve Gemini CLI kabuk türleri olarak tanınıyor. Editör ne çalıştırdığınızı biliyor.

Sonuç

VS Code 1.117 gösterişli bir özellik yığını değil. Altyapı. Worktree izolasyonu, kalıcı izinler, alt-agent protokolleri — bunlar, agentların kodunuza basmadan gerçek, paralel görevleri üstlendiği bir iş akışının yapı taşları.

.NET ile geliştirme yapıyorsanız ve henüz ajanlı iş akışına girmediyseniz, dürüstçe söylemek gerekirse, başlamak için şimdi tam zamanı.

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.

Docker Sandbox, Copilot Agent'larının Makinenizi Tehlikeye Atmadan Kodunuzu Yeniden Düzenlemesini Sağlıyor

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

Copilot’un agent modunu küçük düzenlemelerin ötesinde bir şey için kullandıysanız, acısını bilirsiniz. Her dosya yazma işlemi, her terminal komutu — bir izin isteği daha. Bunu 50 proje boyunca çalıştırdığınızı düşünün. Hiç eğlenceli değil.

Azure ekibi, GitHub Copilot agent’ları için Docker Sandbox hakkında bir yazı yayımladı ve dürüst olmak gerekirse, bu gördüğüm en pratik agentic araç geliştirmelerinden biri. MicroVM’ler kullanarak Copilot’a tamamen izole bir ortam sağlıyor; orada istediği gibi davranabilir — paket yükleyebilir, build çalıştırabilir, testleri yürütebilir — ana sisteminize dokunmadan.

Docker Sandbox size gerçekte ne veriyor

Temel fikir basit: tam Linux ortamıyla hafif bir microVM başlatın, çalışma alanınızı içine senkronize edin ve Copilot agent’ının içinde serbestçe çalışmasına izin verin. İşi bittiğinde değişiklikler geri senkronize edilir.

Bunu sadece “bir container’da bir şeyler çalıştır"dan fazlası yapan şeyler şunlar:

Mutlak yolları koruyan çift yönlü çalışma alanı senkronizasyonu. Proje yapınız sandbox içinde tamamen aynı görünür. Yol kaynaklı build hataları yok.
MicroVM içinde çalışan özel Docker daemon. Agent, ana makinenizin Docker soketini bağlamak zorunda kalmadan container oluşturabilir ve çalıştırabilir. Güvenlik açısından bu büyük bir kazanım.
Agent’ın ağda neye erişebileceğini kontrol eden HTTP/HTTPS filtreleme proxy’leri. Hangi registry’lere ve endpoint’lere izin verildiğine siz karar verirsiniz. Sandbox içindeki bir npm install‘dan gelen tedarik zinciri saldırıları mı? Engellendi.
YOLO modu — evet, gerçekten böyle çağırıyorlar. Agent izin istemi olmadan çalışıyor çünkü ana makinenize gerçekten zarar veremez. Her yıkıcı eylem sandbox içinde kalıyor.

.NET geliştiricilerinin neden önemsemesi gerekiyor

Pek çok ekibin şu an karşı karşıya olduğu modernizasyon işini düşünün. .NET 9’a taşımanız gereken, 30 projelik bir .NET Framework çözümünüz var. Bu yüzlerce dosya değişikliği demek — proje dosyaları, namespace güncellemeleri, API değişiklikleri, NuGet geçişleri.

Docker Sandbox ile bir Copilot agent’ını bir projeye yönlendirebilir, microVM içinde serbestçe yeniden düzenlemesine izin verebilir, doğrulama için dotnet build ve dotnet test çalıştırabilir ve yalnızca gerçekten çalışan değişiklikleri kabul edebilirsiniz. Denemeler yaparken yerel geliştirme ortamınızı yanlışlıkla mahvetme riski yok.

Yazı ayrıca paralel agent filosu çalıştırmayı da anlatıyor — her biri kendi sandbox’ında — farklı projeleri aynı anda ele alıyor. Büyük .NET çözümleri veya microservice mimarileri için bu muazzam bir zaman tasarrufu. Servis başına bir agent, hepsi izole çalışıyor, hepsi bağımsız olarak doğrulanıyor.

Güvenlik boyutu önemli

İnsanların çoğunlukla atladığı şey şu: bir AI agent’ının rastgele komutlar yürütmesine izin verdiğinizde, ona tüm makinenizle güveniyorsunuz demektir. Docker Sandbox bu modeli tersine çeviriyor. Agent, tek kullanımlık bir ortam içinde tam özerklik alıyor. Ağ proxy’si yalnızca onaylanan kaynaklardan çekebilmesini sağlıyor. Ana makine dosya sisteminiz, Docker daemon’unuz ve kimlik bilgileriniz dokunulmadan kalıyor.

Uyumluluk gereksinimleri olan ekipler için — ki bu çoğu kurumsal .NET mağazasıdır — bu, “agentic AI kullanamayız” ile “güvenle benimseyelim” arasındaki farktır.

Sonuç

Docker Sandbox, agentic kodlamanın temel gerilimini çözüyor: agent’ların kullanışlı olabilmek için özgürlüğe ihtiyacı var, ama ana makinenizde özgürlük tehlikelidir. MicroVM’ler her ikisini de sunuyor. Büyük ölçekli herhangi bir .NET yeniden düzenleme veya modernizasyon planı yapıyorsanız, bunu şimdi kurmaya değer. Copilot’un kod zekasını güvenli bir yürütme ortamıyla birleştirmek, üretim ekiplerinin beklediği tam olarak bu.

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.

.NET Aspire 13.2 AI Ajanınızın En İyi Dostu Olmak İstiyor

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

AI kodlama ajanınızın sağlam bir kod yazdığı, heyecanlandığınız ve ardından uygulamayı çalıştırmaya çalışırken her şeyin dağıldığı o anı biliyor musunuz? Port çakışmaları, hayalet süreçler, yanlış ortam değişkenleri — ve bir anda ajanınız özellik geliştirmek yerine başlangıç sorunlarını çözmek için token harcamaya başlıyor.

Aspire ekibi tam da bu sorun hakkında gerçekten düşünceli bir yazı yayımladı ve cevapları ikna edici: Aspire 13.2 yalnızca insanlar için değil, AI ajanları için de tasarlanmış.

Sorun gerçek

AI ajanları kod yazmakta inanılmaz derecede başarılı. Ancak çalışan bir full-stack uygulama göndermek, dosya oluşturmaktan çok daha fazlasını gerektiriyor. Servisleri doğru sırayla başlatmanız, portları yönetmeniz, ortam değişkenlerini ayarlamanız, veritabanlarını bağlamanız ve bir şeyler bozulduğunda geri bildirim almanız gerekiyor. Şu an çoğu ajan bunların hepsini deneme-yanılma yoluyla hallediypr — komutları çalıştırıyor, hata çıktısını okuyor, yeniden deniyor.

Markdown talimatları, özel skill’ler ve prompt’lar ekleyerek onlara rehberlik etmeye çalışıyoruz, ancak bunlar öngörülemez, derlenemiyor ve ayrıştırılmaları bile token harcıyor. Aspire ekibi temel içgörüyü doğru yakaladı: ajanların daha fazla Markdown’a değil, derleyicilere ve yapılandırılmış API’lara ihtiyacı var.

Ajan altyapısı olarak Aspire

Aspire 13.2’nin ajansal geliştirme masasına getirdikleri:

Tüm yığınınız yazılı kodda. AppHost, tam topolojinizi — API, frontend, veritabanı, önbellek — derlenebilir TypeScript veya C# olarak tanımlıyor:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Bir ajan, uygulama topolojisini anlamak, kaynak eklemek, bağlantıları oluşturmak ve doğrulamak için derlemek amacıyla bunu okuyabilir. Derleyici bir şeyin yanlış olduğunu anında söylüyor. Tahmin yok, yapılandırma dosyalarıyla deneme-yanılma yok.

Her şeyi yöneten tek komut. Ajanların docker compose up, npm run dev ve veritabanı başlangıç betikleri arasında denge kurması yerine tek yapmaları gereken şey aspire start. Tüm kaynaklar doğru sırayla, doğru portlarda, doğru yapılandırmayla başlıyor. Uzun süre çalışan süreçler ajanı engellemez — bunları Aspire yönetiyor.

Paralel ajanlar için isolated mod. --isolated seçeneğiyle her Aspire çalıştırması kendi rastgele portlarını ve ayrı user secret’larını alıyor. Git worktree’lerinde çalışan birden fazla ajanınız mı var? Çakışmayacaklar. Bu, paralel ortamlar açan VS Code’un background agent’ları gibi araçlar için çok büyük bir gelişme.

Telemetri aracılığıyla ajan gözleri. İşte burada gerçekten güçlü oluyor. Aspire CLI, geliştirme sırasında tam OpenTelemetry verilerini açığa çıkarıyor — trace’ler, metrikler, yapılandırılmış loglar. Ajanınız yalnızca konsol çıktısını okuyup en iyisini ummak zorunda değil. Başarısız bir isteği servisler arasında izleyebilir, yavaş endpoint’lerin profilini çıkarabilir ve neyin tam olarak nerede bozulduğunu saptayabilir. Bu, geliştirme döngüsünde üretim kalitesinde gözlemlenebilirlik demek.

Bowling koruma bandı analojisi

Aspire ekibi harika bir analoji kullanıyor: Aspire’ı AI ajanları için bowling koruma bantları olarak düşünün. Ajan mükemmel olmasa da (ve olmayacak), bantlar onu oluktan atmaktan koruyor. Yığın tanımı yanlış yapılandırmayı önlüyor, derleyici hataları yakalıyor, CLI süreç yönetimini üstleniyor ve telemetri geri bildirim döngüsünü sağlıyor.

Bunu Playwright CLI gibi bir şeyle birleştirdiğinizde, ajanınız uygulamanızı gerçekten kullanabilir — akışlara tıklayabilir, DOM’u kontrol edebilir, telemetride kırık şeyleri görebilir, kodu düzeltebilir, yeniden başlatabilir ve tekrar test edebilir. Derle, çalıştır, gözlemle, düzelt. Bu, peşinden koştuğumuz özerk geliştirme döngüsü.

Başlarken

Aspire’a yeni misiniz? CLI’ı get.aspire.dev adresinden yükleyin ve başlangıç rehberini takip edin.

Zaten Aspire kullanıyor musunuz? 13.2’yi almak için aspire update --self komutunu çalıştırın, ardından favori kodlama ajanınızı repoya yönlendirin. Aspire’ın koruma bantlarıyla ne kadar daha ileri gittiğini görünce şaşırabilirsiniz.

Özet

Aspire 13.2 artık sadece bir dağıtık uygulama framework’ü değil — temel ajan altyapısına dönüşüyor. Yapılandırılmış yığın tanımları, tek komutla başlangıç, izole paralel çalıştırmalar ve gerçek zamanlı telemetri, AI ajanlarına kod yazmaktan uygulama göndermek için tam olarak ihtiyaç duydukları şeyleri veriyor.

Tüm ayrıntılar ve demo videolar için Aspire ekibinin tam yazısını 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.

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.

MCP Uygulamaları Fluent API Kazandı — .NET'te Üç Adımda Zengin AI Araç Arayüzleri Oluşturun

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

MCP araçları, AI agent’larına yetenekler kazandırmak için harika. Peki ya aracınızın kullanıcıya bir şey göstermesi gerekiyorsa — bir dashboard, bir form, etkileşimli bir görselleştirme? MCP Apps tam bu noktada devreye giriyor ve çok daha kolay hale geldi.

Azure SDK ekibinden Lilian Kasem, .NET Azure Functions’daki MCP Apps için yeni fluent yapılandırma API’sini tanıttı ve bu, neden başından beri bu kadar basit olmadığını düşündüren türden bir geliştirici deneyimi iyileştirmesi.

MCP Apps Nedir?

MCP Apps, araçların kendi UI görünümlerini, statik varlıklarını ve güvenlik kontrollerini taşımasına izin vererek Model Context Protocol’ü genişletir. MCP aracınız yalnızca metin döndürmek yerine tam HTML deneyimleri render edebilir — etkileşimli dashboard’lar, veri görselleştirmeleri, yapılandırma formları — bunların hepsi AI agent’ları tarafından çağrılabilir ve MCP istemcileri tarafından kullanıcılara sunulur.

Sorun şuydu: tüm bunları manuel olarak bağlamak MCP spesifikasyonunu yakından bilmeyi gerektiriyordu: ui:// URI’leri, özel mime türleri, araçlar ve kaynaklar arasında metadata koordinasyonu. Zor değil, ama zahmetli.

Üç Adımda Fluent API

Adım 1: Fonksiyonunuzu tanımlayın. Standart bir Azure Functions MCP aracı:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Adım 2: Bir MCP App’e yükseltin. Program başlatmanızda:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Adım 3: HTML görünümünüzü ekleyin. İhtiyacınız olan herhangi bir UI ile assets/hello-app.html dosyasını oluşturun.

Hepsi bu kadar. Fluent API tüm MCP spesifikasyon altyapısını halleder — sentetik kaynak fonksiyonu oluşturma, doğru mime türünü ayarlama, aracınızı görünümüne bağlayan metadata’yı ekleme.

API Yüzeyi İyi Tasarlanmış

Gerçekten beğendiğim birkaç şey:

Görünüm kaynakları esnektir. HTML’i diskteki dosyalardan sunabilir veya kendi kendine yetişen dağıtımlar için kaynakları doğrudan assembly’nize gömebilirsiniz:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP kompozisyona uygundur. Uygulamanızın ihtiyaç duyduğu kaynakları açıkça beyaz listeye alırsınız, en az ayrıcalık ilkelerini izleyerek. WithCsp‘yi birden fazla kez çağırın ve kaynaklar birikir:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Görünürlük kontrolü. Bir aracı yalnızca LLM’ye görünür, yalnızca host UI’a görünür veya her ikisine de görünür yapabilirsiniz. Yalnızca UI render eden ve model tarafından çağrılmaması gereken bir araç mı istiyorsunuz? Kolay:

.WithVisibility(McpVisibility.App) // Yalnızca UI, modelden gizli

Başlarken

Preview paketini ekleyin:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Zaten Azure Functions ile MCP araçları oluşturuyorsanız, bu yalnızca bir paket güncellemesi. Konsepte yeniyseniz MCP Apps hızlı başlangıç kılavuzu başlamak için en iyi yer.

Son Söz

MCP Apps, AI araçlama alanındaki daha heyecan verici gelişmelerden biri — yalnızca işler yapan değil, kullanıcılara şeyler gösterebilen araçlar. Fluent API protokol karmaşıklığını ortadan kaldırır ve önemli olan şeye odaklanmanızı sağlar: aracınızın mantığı ve UI’ı.

Tam API referansı ve örnekler için tam yazıyı okuyun.

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.

VS Code 1.115 — Arka Plan Terminal Bildirimleri, SSH Agent Modu ve Daha Fazlası

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 az önce yayınlandı ve başlık özellikleri açısından hafif bir sürüm olsa da, AI kodlama asistanlarıyla her gün çalışıyorsanız agent ile ilgili iyileştirmeler gerçekten kullanışlı.

Gerçekten bilinmeye değer olanları öne çıkarayım.

Arka plan terminalleri agentlara geri bildirim veriyor

Bu, öne çıkan özellik. Arka plan terminalleri artık komutlar tamamlandığında çıkış kodu ve terminal çıktısını da içerecek şekilde otomatik olarak agentları bilgilendiriyor. Arka plan terminallerindeki giriş istemleri de tespit edilerek kullanıcıya iletiliyor.

Bu neden önemli? Copilot’un agent modunu arka planda build komutları veya test dizileri çalıştırmak için kullandıysanız, “o bitti mi acaba?” sancısını bilirsiniz — arka plan terminalleri esasen ateş et ve unut mantığıyla çalışıyordu. Artık agent, dotnet build veya dotnet test tamamlandığında haberdar ediliyor, çıktıyı görüyor ve buna göre tepki verebiliyor. Küçük bir değişiklik, ama agent odaklı iş akışlarını önemli ölçüde daha güvenilir kılıyor.

Ayrıca, agentların kullanıcı onayıyla arka plan terminallerine komut göndermesine olanak tanıyan yeni bir send_to_terminal aracı var; bu da run_in_terminal‘in zaman aşımıyla terminalleri arka plana taşıdığı ve salt okunur hale getirdiği sorunu çözüyor.

SSH uzak agent barındırma

VS Code artık SSH üzerinden uzak makinelere bağlanmayı, CLI’yi otomatik olarak yüklemeyi ve agent ana bilgisayar modunda başlatmayı destekliyor. Bu, AI agent oturumlarınızın uzak ortamları doğrudan hedefleyebileceği anlamına geliyor — Linux sunucularda veya bulut VM’lerinde geliştirme ve test yapan .NET geliştiricileri için kullanışlı.

Agent oturumlarında düzenleme takibi

Agent oturumları sırasında yapılan dosya düzenlemeleri artık farklar, geri alma/yeniden yapma ve durum geri yükleme ile birlikte takip ediliyor ve geri yükleniyor. Bir agent kodunuzda değişiklik yapar ve bir şeyler ters giderse, tam olarak neyin değiştiğini görebilir ve geri alabilirsiniz. Agentların kod tabanınızı değiştirmesine izin vermek için gönül rahatlığı.

Tarayıcı sekme farkındalığı ve diğer iyileştirmeler

Birkaç yaşam kalitesi iyileştirmesi daha:

Tarayıcı sekme takibi — sohbet artık bir oturum sırasında açılan tarayıcı sekmelerini takip edip bunlara bağlantı verebiliyor, böylece agentlar baktığınız web sayfalarına referans verebiliyor
Terminale dosya yapıştırma — Ctrl+V, sürükle-bırak veya sağ tıklamayla terminale dosya (resimler dahil) yapıştırın
Minimap’te test kapsamı — test kapsamı göstergeleri artık hızlı bir görsel özet için minimap’te gösteriliyor
Mac’te sıkıştırarak yakınlaştırma — entegre tarayıcı sıkıştırarak yakınlaştırma hareketlerini destekliyor
Sessions’da Copilot yetkilendirmeleri — durum çubuğu Sessions görünümünde kullanım bilgilerini gösteriyor
Go to File’da favicon — açık web sayfaları hızlı seçim listesinde favicon gösteriyor

Sonuç

VS Code 1.115 artımlı bir sürüm, ancak agent iyileştirmeleri — arka plan terminal bildirimleri, SSH agent barındırma ve düzenleme takibi — AI destekli geliştirme için fark edilir şekilde daha akıcı bir deneyim oluşturuyor. .NET projeleri için Copilot’un agent modunu kullanıyorsanız, bunlar günlük sürtünmeyi azaltan yaşam kalitesi düzeltmeleri.

Her ayrıntı için tam sürüm notlarına bakın.

Aspire 13.2 Bir Dokümantasyon CLI'ı Sunuyor — ve AI Ajanınız da Kullanabilir

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

Bir Aspire AppHost’un içinde derinlere dalıp entegrasyonları bağlarken Redis entegrasyonunun tam olarak hangi parametreleri beklediğini kontrol etmeniz gereken o anı biliyor musunuz? Tarayıcınıza geçersiniz, aspire.dev’de arama yaparsınız, API dokümanlarını incelersiniz, sonra editörünüze dönersiniz. Bağlam kaybolmuş. Akış bozulmuş.

Aspire 13.2 tam da bunun için bir çözüm sundu. aspire docs CLI’ı, terminali terk etmeden resmi Aspire belgelerini doğrudan arayıp okuyabilmenizi sağlıyor. Yeniden kullanılabilir servisler tarafından desteklendiği için, AI ajanları ve skill’ler de var olmayan API’ları uydurmak yerine belge aramak amacıyla aynı komutları kullanabiliyor.

Bu aslında ne sorunu çözüyor

David Pine orijinal yazısında konuyu net olarak özetliyor: AI ajanlar, geliştiricilere Aspire uygulamaları geliştirmede yardım etmekte berbattı. aspire run yerine dotnet run öneriyorlar, aspire.dev’deki belgeleri learn.microsoft.com’a yönlendiriyorlardı, güncel olmayan NuGet paketleri öneriyorlardı ve — kişisel favorim — var olmayan API’ları uyduruyorlardı.

Neden? Çünkü Aspire, çok dilli olmadan çok daha uzun süre .NET’e özel kaldı ve LLM’ler en son özelliklerin öncesindeki eğitim verileriyle çalışıyor. Bir AI ajanına mevcut belgeleri gerçekten arama yeteneği verdiğinizde, tahmin etmeyi bırakıp işe yarar hale geliyor.

Üç komut, sıfır tarayıcı sekmesi

CLI ferahlatıcı derecede basit:

Tüm belgeleri listele

aspire docs list

aspire.dev’de mevcut her belge sayfasını döndürür. Makine tarafından okunabilir çıktı mı istiyorsunuz? --format Json ekleyin.

Bir konu arayın

aspire docs search "redis"

Ağırlıklı ilgi puanlamasıyla hem başlıkları hem içeriği arar. Dahili olarak dokümantasyon araçlarını destekleyen arama motorunun aynısı. Başlıklar, slug’lar ve ilgi puanlarıyla sıralı sonuçlar alırsınız.

Tam sayfayı okuyun (ya da yalnızca bir bölümü)

aspire docs get redis-integration

Tam sayfayı markdown olarak terminalinize akıtır. Yalnızca bir bölüme mi ihtiyacınız var?

aspire docs get redis-integration --section "Add Redis resource"

Cerrahi hassasiyet. 500 satır kaydırma yok. Sadece ihtiyacınız olan kısım.

AI ajan boyutu

İşte AI araçlarıyla geliştirme yapan bizim için ilginç olan kısım. Aynı aspire docs komutları, AI ajanları için araç olarak çalışıyor — skill’ler, MCP sunucuları veya basit CLI sarmalayıcıları aracılığıyla.

AI asistanınızın eski eğitim verilerine dayalı Aspire API’ları uydurmak yerine, aspire docs search "postgres" çağırabilir, resmi entegrasyon belgelerini bulabilir, doğru sayfayı okuyabilir ve size belgelenmiş yaklaşımı sunabilir. Gerçek zamanlı, güncel belgeler — modelin altı ay önce ezberledikleri değil.

Bunun arkasındaki mimari kasıtlı. Aspire ekibi tek seferlik bir entegrasyon yerine yeniden kullanılabilir servisler (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) inşa etti. Bu, aynı arama motorunun terminaldeki insanlar, editörünüzdeki AI ajanları ve CI pipeline’ınızdaki otomasyonlar için çalışması anlamına geliyor.

Gerçek dünya senaryoları

Hızlı terminal aramaları: Üç dosya derindesiniz ve Redis yapılandırma parametrelerine ihtiyacınız var. İki komut, doksan saniye, işe geri dönüş:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI destekli geliştirme: VS Code skill’iniz CLI komutlarını sarmalıyor. “AppHost’uma bir PostgreSQL veritabanı ekle” diyorsunuz ve ajan cevap vermeden önce gerçek belgelere bakıyor. Halüsinasyon yok.

CI/CD doğrulama: Pipeline’ınız, AppHost yapılandırmalarını programatik olarak resmi belgelerle doğruluyor. --format Json çıktısı jq ve diğer araçlara temiz şekilde aktarılıyor.

Özel bilgi tabanları: Kendi AI araçlarınızı mı geliştiriyorsunuz? Yapılandırılmış JSON çıktısını doğrudan bilgi tabanınıza aktarın:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Web scraping yok. API anahtarı yok. Dokümantasyon araçlarının dahili olarak kullandığı aynı yapılandırılmış veri.

Belgeler her zaman canlı

En çok takdir ettiğim kısım bu. CLI bir anlık görüntü indirmiyor — aspire.dev’i ETag tabanlı önbelleklemeyle sorguluyor. Belgeler güncellenir güncellenmez, CLI’ınız ve üzerine inşa edilmiş tüm skill’ler bunu yansıtıyor. Eski kopyalar yok, “ama wiki şöyle diyordu…” anları yok.

Özet

aspire docs, gerçek bir sorunu temiz biçimde çözen küçük özelliklerden biri. İnsanlar terminale özgü belge erişimi kazanıyor. AI ajanları tahmin etmeyi bırakıp gerçek belgelere başvurmanın bir yolunu buluyor. Ve hepsi aynı gerçek kaynakla destekleniyor.

.NET Aspire ile geliştirme yapıyorsanız ve CLI’ı henüz denemediyseniz, aspire docs search "konunuz" çalıştırın ve nasıl hissettirdiğini görün. Sonra bu komutları kullandığınız AI skill veya otomasyon kurulumuna entegre etmeyi düşünün — ajanlarınız size teşekkür edecek.

Dokümantasyon araçlarının nasıl oluşturulduğuna dair David Pine’ın derinlemesine incelemesine ve tüm ayrıntılar için resmi CLI referansına göz atın.

Microsoft Agent Framework 1.0 Yayımlandı — .NET Geliştiricileri İçin Gerçekten Önemli Olan Şeyler

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

Erken Semantic Kernel ve AutoGen günlerinden bu yana Agent Framework yolculuğunu takip ediyorsanız, bu gelişme önemli. Microsoft Agent Framework 1.0 sürümüne ulaştı — üretime hazır, kararlı API’lar, uzun vadeli destek taahhüdü. Hem .NET hem de Python için mevcut ve gerçek iş yükleri için gerçekten hazır.

Duyuru gürültüsünü bir kenara bırakarak, .NET ile AI destekli uygulamalar geliştiriyorsanız önemli olan şeylere odaklanayım.

Özet

Agent Framework 1.0, eski Semantic Kernel ve AutoGen’i tek, açık kaynaklı bir SDK’da birleştirir. Tek bir agent soyutlaması. Tek bir orkestrasyon motoru. Birden fazla AI sağlayıcısı. Kurumsal desenler için Semantic Kernel ile araştırma düzeyindeki çoklu-agent iş akışları için AutoGen arasında gidip geliyorsanız, buna son verebilirsiniz. Artık tek SDK bu.

Başlamak neredeyse haksız derecede kolay

İşte .NET’te çalışan bir agent:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Bu kadar. Birkaç satırla Azure Foundry üzerinde çalışan bir AI agentınız var. Python karşılığı da aynı derecede özlü. İlerlediğinizde function araçları, çok turlu konuşmalar ve streaming ekleyin — API yüzeyi tuhaflaşmadan büyür.

Çoklu-agent orkestrasyonu — işte asıl konu bu

Tek agentlar demolar için güzel, ama üretim senaryoları genellikle koordinasyon gerektirir. Agent Framework 1.0, Microsoft Research ve AutoGen’den gelen savaşta test edilmiş orkestrasyon desenlerini içerir:

Sequential (Sıralı) — agentlar sırayla işler (yazar → gözden geçiren → editör)
Concurrent (Eş zamanlı) — birden fazla agenta paralel olarak yayıl, sonuçları birleştir
Handoff (Devir teslim) — bir agent, niyete göre başka birine devreder
Group chat (Grup sohbeti) — birden fazla agent tartışır ve bir çözümde uzlaşır
Magentic-One — MSR’den araştırma düzeyindeki çoklu-agent deseni

Tümü streaming, checkpointing, human-in-the-loop onayları ve duraklat/devam et özelliklerini destekler. Checkpointing kısmı kritik — uzun süreli iş akışları süreç yeniden başlatmalarını atlatır. Azure Functions ile dayanıklı iş akışları geliştirmiş .NET geliştiricileri için bu tanıdık hissettiriyor.

En önemli özellikler

Bilmeye değer şeylerin kısa listesi:

Middleware kancaları. ASP.NET Core’un middleware pipeline’ları var ya? Aynı kavram, ama agent yürütmesi için. Her aşamayı yakalayın — içerik güvenliği, loglama, uyumluluk politikaları ekleyin — agent prompt’larına dokunmadan. Agentları kurumsal düzeyde hazır kılmanın yolu budur.

Takılabilir bellek. Konuşma geçmişi, kalıcı anahtar-değer durumu, vektör tabanlı erişim. Backend’inizi seçin: Foundry Agent Service, Mem0, Redis, Neo4j veya kendinizinkini yazın. Bellek, durumsuz bir LLM çağrısını gerçekten bağlamı hatırlayan bir agenta dönüştüren şeydir.

Bildirimsel YAML agentları. Agentınızın talimatlarını, araçlarını, belleğini ve orkestrasyon topolojisini sürüm kontrollü YAML dosyalarında tanımlayın. Tek bir API çağrısıyla yükleyin ve çalıştırın. Bu, kod yeniden dağıtmadan agent davranışını yinelemek isteyen ekipler için oyun değiştiricidir.

A2A ve MCP desteği. MCP (Model Context Protocol), agentların harici araçları dinamik olarak keşfetmesine ve çağırmasına izin verir. A2A (Agent-to-Agent protokolü), çalışma zamanları arası işbirliğini mümkün kılar — .NET agentlarınız diğer framework’lerde çalışan agentlarla koordinasyon kurabilir. A2A 1.0 desteği yakında geliyor.

Takip etmeye değer önizleme özellikleri

Bazı özellikler 1.0’da önizleme olarak yayımlandı — işlevsel ama API’lar gelişebilir:

DevUI — agent yürütmesini, mesaj akışlarını ve araç çağrılarını gerçek zamanlı olarak görselleştirmek için tarayıcı tabanlı yerel hata ayıklayıcı. Application Insights gibi ama agent muhakemesi için.
GitHub Copilot SDK ve Claude Code SDK — Copilot veya Claude’u doğrudan orkestrasyon kodunuzdan agent harness’i olarak kullanın. Kod yazabilen bir agentı aynı iş akışındaki diğer agentlarla birleştirin.
Agent Harness — agentlara shell, dosya sistemi ve mesajlaşma döngülerine erişim sağlayan özelleştirilebilir yerel çalışma zamanı. Kodlama agentları ve otomasyon desenlerini düşünün.
Skills — agentlara kullanıma hazır yapılandırılmış yetenekler sunan yeniden kullanılabilir alan yetkinliği paketleri.

Semantic Kernel veya AutoGen’den geçiş

Mevcut Semantic Kernel veya AutoGen kodunuz varsa, kodunuzu analiz eden ve adım adım geçiş planları üreten özel geçiş asistanları mevcuttur. Semantic Kernel geçiş rehberi ve AutoGen geçiş rehberi her şeyi adım adım anlatıyor.

RC paketlerindeyseniz, 1.0’a yükseltme sadece bir sürüm güncellemesidir.

Sonuç

Agent Framework 1.0, kurumsal ekiplerin beklediği üretim mihenk taşıdır. Kararlı API’lar, çoklu sağlayıcı desteği, gerçek ölçekte çalışan orkestrasyon desenleri ve hem Semantic Kernel hem de AutoGen’den geçiş yolları.

Framework GitHub’da tamamen açık kaynak ve dotnet add package Microsoft.Agents.AI ile bugün başlayabilirsiniz. Ellerinizi kirletmek için hızlı başlangıç rehberine ve örneklere göz atın.

“Üretimde kullanmak güvenli” sinyalini bekliyorsanız — işte bu.

Aspire 13.2 Dashboard'una Telemetri API'si Geldi — ve Her Şeyi Değiştiriyor

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

.NET Aspire ile dağıtık uygulamalar geliştiriyorsanız, dashboard’un tüm deneyimin en iyi parçası olduğunu zaten bilirsiniz. Tüm izleriniz, loglarınız ve metrikleriniz tek bir yerde — harici Jaeger yok, Seq kurulumu yok, “öbür terminale bakayım” anı yok.

Aspire 13.2 bunu önemli ölçüde daha iyi hale getirdi. James Newton-King güncellemeyi duyurdu ve dürüst olmak gerekirse? Telemetri dışa aktarma ve API özellikleri tek başına yükseltmeye değer.

Telemetriyi sağlıklı bir şekilde dışa aktarın

Hepimizin yaşadığı senaryoyu düşünün: dağıtık bir sorunu ayıklıyorsunuz, yirmi dakikalık kurulumun ardından sonunda yeniden üretiyorsunuz ve şimdi yaşananları ekibinizle paylaşmanız gerekiyor. Önceden? Ekran görüntüleri. İz ID’lerini kopyala-yapıştır. Her zamanki karmaşa.

Aspire 13.2, şunları yapabileceğiniz uygun bir Logları ve telemetriyi yönet iletişim kutusu ekliyor:

Tüm telemetriyi temizleme (yeniden üretim denemesinden önce kullanışlı)
Seçili telemetriyi standart OTLP/JSON formatında ZIP dosyasına dışa aktarma
Bu ZIP’i daha sonra herhangi bir Aspire dashboard’una yeniden içe aktarma

Son kısım öldürücü özellik. Bir hatayı yeniden üretirsiniz, telemetriyi dışa aktarırsınız, iş öğenize eklersiniz ve ekip arkadaşınız tam olarak gördüğünüzü görmek için kendi dashboard’una içe aktarabilir. Artık “kendi makinende yeniden üretebilir misin?” yok.

Bireysel izler, span’lar ve loglar da bağlam menülerinde “JSON Dışa Aktar” seçeneği kazanıyor. Tek bir izi paylaşmanız mı gerekiyor? Sağ tıklayın, JSON kopyalayın, PR açıklamanıza yapıştırın. Tamam.

Telemetri API’si gerçek oyun değiştirici

En çok bu konuya heyecanlıyım. Dashboard artık telemetri verilerini programatik olarak sorgulamak için /api/telemetry altında bir HTTP API sunuyor. Kullanılabilir endpoint’ler:

GET /api/telemetry/resources — telemetrisi olan kaynakları listele
GET /api/telemetry/spans — filtrelerle span’ları sorgula
GET /api/telemetry/logs — filtrelerle logları sorgula
GET /api/telemetry/traces — izleri listele
GET /api/telemetry/traces/{traceId} — belirli bir iz için tüm span’ları getir

Her şey OTLP JSON formatında dönüyor. Bu, yeni aspire agent mcp ve aspire otel CLI komutlarını besliyor, ama gerçek anlam daha büyük: artık uygulamanızın telemetrisini doğrudan sorgulayan araçlar, scriptler ve AI agent entegrasyonları oluşturabilirsiniz.

Hata ayıklarken gerçek dağıtık izlerinize bakabilen bir AI kodlama agentı hayal edin. Bu artık hayali değil — bu API’nin mümkün kıldığı şey tam olarak bu.

GenAI telemetri pratikleşiyor

Semantic Kernel veya Microsoft.Extensions.AI ile AI destekli uygulamalar geliştiriyorsanız, geliştirilmiş GenAI telemetri görselleştiricisini takdir edeceksiniz. Aspire 13.2 şunları ekliyor:

Markdown olarak render edilen AI araç açıklamaları
AI iz erişimini hızlandırmak için izler sayfasında özel GenAI butonu
Kesik veya standart olmayan GenAI JSON için daha iyi hata yönetimi
Araç tanımları arasında tıkla-vurgula navigasyonu

Blog yazısı, VS Code Copilot chat, Copilot CLI ve OpenCode’un tümünün OTEL_EXPORTER_OTLP_ENDPOINT yapılandırmasını desteklediğinden bahsediyor. Bunları Aspire dashboard’una yönlendirin ve AI agentlarınızın telemetri aracılığıyla gerçek zamanlı olarak nasıl düşündüğünü izleyebilirsiniz. Bu, başka hiçbir yerde bulamayacağınız bir hata ayıklama deneyimidir.

Sonuç

Aspire 13.2, dashboard’u “güzel bir hata ayıklama arayüzü"nden “programlanabilir bir gözlemlenebilirlik platformu"na taşıyor. Dışa aktarma/içe aktarma iş akışı tek başına dağıtık hata ayıklamada gerçek zaman kazandırıyor; telemetri API’si ise AI destekli tanılama kapısını açıyor.

Zaten Aspire kullanıyorsanız, yükseltin. Kullanmıyorsanız — bu, aspire.dev’e göz atmak ve tüm meseleyi anlamak için iyi bir neden.

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.

Visual Studio'nun Mart Güncellemesiyle Özel Copilot Agentları Oluşturabilirsiniz — find_symbol Aracı Gerçekten Büyük

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

Visual Studio bugüne kadarki en önemli Copilot güncellemesini aldı. Mark Downie Mart sürümünü duyurdu ve başlık özel agentlar — ama dürüstçe söylemek gerekirse, daha aşağılarda geçen find_symbol aracı iş akışınızı en çok değiştirecek özellik olabilir.

Gerçekte neler olduğunu açıklayayım.

Reponuzda özel Copilot agentları

Copilot’un ekibinizin kodlama standartlarını izlemesini, build pipeline’ınızı çalıştırmasını veya dahili belgelerinizi sorgulamasını ister misiniz? Artık tam olarak bunu oluşturabilirsiniz.

Özel agentlar, reponuzdaki .github/agents/ klasörüne bıraktığınız .agent.md dosyaları olarak tanımlanıyor. Her agent, çalışma alanı farkındalığına, kod anlayışına, araçlara, tercih ettiğiniz modele ve harici servislere MCP bağlantılarına tam erişim elde ediyor. Yerleşik agentların yanında agent seçicisinde görünüyorlar.

Bu, VS Code’un süredir desteklediği desenin aynısı — ve Visual Studio’nun yetişmesini görmek harika. VS Code için zaten agent oluşturmuş ekipler için .agent.md dosyalarınız her iki IDE’de de çalışmalı (ancak araç adları farklılık gösterebilir, bu yüzden test edin).

awesome-copilot reposunda başlangıç noktası olarak kullanabileceğiniz topluluk katkılı agent yapılandırmaları var.

Agent becerileri: yeniden kullanılabilir talimat paketleri

Beceriler, reponuzdaki .github/skills/ klasöründen veya profilinizdeki ~/.copilot/skills/ konumundan otomatik olarak alınıyor. Her beceri, Agent Skills spesifikasyonunu takip eden bir SKILL.md dosyası.

Becerileri, karıştırıp eşleştirebileceğiniz modüler uzmanlık alanları olarak düşünün. API kurallarınız için bir beceri, test desenleriniz için bir diğeri ve dağıtım iş akışınız için başka biri olabilir. Bir beceri etkinleştiğinde, uygulandığını bilmeniz için sohbette görünüyor.

VS Code’da beceri kullandıysanız Visual Studio’da da aynı şekilde çalışıyorlar.

find_symbol: agentlar için dile duyarlı navigasyon

İşler burada gerçekten ilginçleşiyor. Yeni find_symbol aracı, Copilot’un agent moduna gerçek dil servisi destekli sembol navigasyonu sağlıyor. Kodunuzu metin olarak aramak yerine agent şunları yapabiliyor:

Projeniz genelinde bir sembole yapılan tüm referansları bul
Tür bilgisine, bildirimlere ve kapsam meta verilerine eriş
Tam dil farkındalığıyla çağrı noktalarında gezin

Pratikte ne anlama geliyor: Copilot’tan bir metodu yeniden düzenlemesini veya çağrı noktaları genelinde parametre imzasını güncellemesini istediğinizde, kodunuzun yapısını gerçekten görebiliyor. Artık “agent metodu değiştirdi ama üç çağrı noktasını kaçırdı” durumu yok.

Desteklenen diller arasında C#, C++, Razor, TypeScript ve desteklenen LSP uzantısına sahip her şey yer alıyor. .NET geliştiricileri için bu büyük bir iyileştirme — derin tür hiyerarşileri ve arayüzlere sahip C# kod tabanları, sembol farkındalıklı navigasyondan büyük ölçüde yararlanıyor.

Copilot ile testleri profilleyin

Test Gezgini bağlam menüsünde artık bir Profile with Copilot komutu var. Bir test seçin, profile tıklayın ve Profiling Agent onu otomatik olarak çalıştırıp performansı analiz eder — uygulanabilir içgörüler sunmak için CPU kullanımı ve enstrümantasyon verilerini birleştirir.

Artık profil oluşturucu oturumlarını manuel olarak yapılandırmak, testi çalıştırmak, sonuçları dışa aktarmak ve bir flame graph okumaya çalışmak yok. Agent analizi yapıp neyin yavaş olduğunu ve neden olduğunu söylüyor. Şu anda yalnızca .NET, ki bu Visual Studio’nun derin .NET tanı entegrasyonu göz önüne alındığında mantıklı.

Canlı hata ayıklama sırasında performans ipuçları

Performans optimizasyonu artık sonrasında değil, hata ayıklarken gerçekleşiyor. Kod üzerinde adım adım ilerlerken Visual Studio satır içinde yürütme süresini ve performans sinyallerini gösteriyor. Yavaş bir satır mı gördünüz? Perf İpucu’na tıklayın ve Copilot’tan hemen orada optimizasyon önerileri isteyin.

Profiling Agent çalışma zamanı verilerini otomatik olarak yakalıyor — geçen süre, CPU kullanımı, bellek davranışı — ve Copilot bunu sıcak noktaları tespit etmek için kullanıyor. Bu, performans çalışmasını ertelediğiniz ayrı bir görev yerine hata ayıklama akışınızın bir parçası olarak tutuyor.

Solution Explorer’dan NuGet güvenlik açıklarını düzeltin

Bir NuGet paketinde güvenlik açığı tespit edildiğinde, artık doğrudan Solution Explorer’da Fix with GitHub Copilot bağlantısıyla bir bildirim görüyorsunuz. Tıklayın ve Copilot güvenlik açığını analiz eder, doğru paket güncellemelerini önerir ve uygular.

Bağımlılıkları güncel tutmakta zorlanan ekipler için (ki bu esasen herkes), “bir güvenlik açığı olduğunu biliyorum ama doğru güncelleme yolunu bulmak başlı başına bir proje” sürtünmesini ortadan kaldırıyor.

Sonuç

Özel agentlar ve beceriler başlık haberi, ancak find_symbol uyuyan dev — .NET kodunu yeniden düzenlerken Copilot’un ne kadar doğru olabileceğini temelden değiştiriyor. Canlı profil oluşturma entegrasyonu ve güvenlik açığı düzeltmeleriyle birleşince bu güncelleme, Visual Studio’nun AI özelliklerini demo hazır değil gerçekten pratik hissettiriyor.

Her şeyi denemek için Visual Studio 2026 Insiders‘ı indirin.

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.

.NET Geliştiricilerinin VS Code 1.112'de Gerçekten Önemsemesi Gerekenler

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

VS Code 1.112 yayınlandı ve dürüstçe söylemek gerekirse? .NET dünyasında gününüzü geçiriyorsanız bu sürüm farklı bir his veriyor. Resmi sürüm notlarında pek çok şey var, ama sizi biraz kaydırmadan kurtarayım ve gerçekten bizim için önemli olanlara odaklanayım.

Copilot CLI çok daha kullanışlı hale geldi

Bu sürümün büyük teması agent özerkliği — Copilot’a her adımı siz denetlemeden işini yapması için daha fazla alan tanıma.

Mesaj yönlendirme ve sıralama

Copilot CLI bir görevin ortasındayken bir şeyi söylemeyi unuttuğunuzu fark ettiğiniz o anı bilirsiniz. Önce beklemeniz gerekiyordu. Artık bir istek hâlâ çalışırken mesaj gönderebilirsiniz — ya mevcut yanıtı yönlendirmek ya da takip talimatlarını sıraya almak için.

Bu, Copilot’un bir proje kurduğunu izlerken “ah, buna MassTransit de eklemeliyim” dediğiniz uzun dotnet iskele görevleri için çok önemli.

İzin seviyeleri

En çok heyecanlandığım bu. Copilot CLI oturumları artık üç izin seviyesini destekliyor:

Default Permissions — araçların çalışmadan önce onay istediği olağan akış
Bypass Approvals — her şeyi otomatik onaylar ve hatalarda yeniden dener
Autopilot — tamamen özerk: araçları onaylar, kendi sorularını yanıtlar ve görev tamamlanana kadar devam eder

Entity Framework ile migrasyonlar, Docker kurulumu ve yeni bir ASP.NET Core API’si oluşturuyorsanız — Autopilot modu demek istediğinizi tanımlayıp kahve almaya gidebilirsiniz demek. Gerisini halledecek.

Autopilot’u chat.autopilot.enabled ayarıyla etkinleştirebilirsiniz.

Devretmeden önce değişiklikleri önizleyin

Copilot CLI’a bir görev devrettiğinizde bir worktree oluşturur. Daha önce, teslim edilmemiş değişiklikleriniz varsa nelerin etkileneceğini görmek için Source Control’ü kontrol etmeniz gerekiyordu. Artık Chat görünümü, kopyalamak, taşımak veya yoksaymak isteyip istemediğinize karar vermeden önce bekleyen değişiklikleri doğrudan orada gösteriyor.

Küçük bir şey, ama “dur, ne hazırlamıştım?” anından kurtarıyor.

VS Code’dan çıkmadan web uygulamalarını hata ayıklayın

Entegre tarayıcı artık tam hata ayıklamayı destekliyor. Kesme noktaları koyabilir, kod üzerinde adım adım ilerleyebilir ve değişkenleri inceleyebilirsiniz — hepsi VS Code içinde. Artık Edge DevTools’a geçiş yok.

Yeni bir editor-browser hata ayıklama türü var ve mevcut msedge veya chrome başlatma yapılandırmalarınız varsa, geçiş launch.json‘daki type alanını değiştirmek kadar basit:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Blazor geliştiricileri için bu oyun değiştirici. Terminalde zaten dotnet watch çalıştırıyorsunuz — artık hata ayıklamanız da aynı pencerede kalıyor.

Tarayıcı aynı zamanda bağımsız yakınlaştırma seviyeleri (sonunda!), düzgün sağ tıklama bağlam menüleri aldı ve yakınlaştırma web sitesi başına hatırlanıyor.

MCP sunucu korumalı alanı

Bu, düşündüğünüzden daha önemli. MCP sunucuları kullanıyorsanız — belki Azure kaynaklarınız veya veritabanı sorguları için özel bir tane kurduysanız — bunlar VS Code sürecinizle aynı izinlerle çalışıyordu. Yani dosya sisteminize, ağınıza, her şeye tam erişim.

Artık onları korumalı alana alabilirsiniz. mcp.json dosyanızda:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Korumalı alandaki bir sunucu sahip olmadığı bir şeye erişim gerektirdiğinde, VS Code izin vermeniz için sizi uyarıyor. “Kimse garip bir şey yapmasın” yaklaşımından çok daha iyi.

Monorepo özelleştirme keşfi

Bir monorepo’da çalışıyorsanız (ve dürüstçe söylemek gerekirse, pek çok kurumsal .NET çözümü buna dönüşüyor), bu gerçek bir sorun noktasını çözüyor.

Daha önce, reponuzun bir alt klasörünü açtığınızda VS Code, depo kökünüzdeki copilot-instructions.md, AGENTS.md veya özel becerileri bulamıyordu. Artık chat.useCustomizationsInParentRepositories ayarıyla .git köküne kadar yukarı çıkıp her şeyi buluyor.

Bu, ekibinizin tüm monorepo projelerine herkesin kök klasörü açmasına gerek kalmadan agent talimatlarını, prompt dosyalarını ve özel araçları paylaşabilmesi anlamına geliyor.

Agent hata ayıklama için /troubleshoot

Özel talimatlar veya beceriler ayarlayıp neden alınmadığını hiç merak ettiniz mi? Yeni /troubleshoot becerisi agent hata ayıklama günlüklerini okuyup ne olduğunu söylüyor — hangi araçların kullanıldığı veya atlandığı, neden talimatların yüklenmediği ve yavaş yanıtlara neyin yol açtığı.

Bunu şununla etkinleştirin:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Ardından sohbette /troubleshoot neden özel beceri yüklenmiyor? yazın.

Bu hata ayıklama günlüklerini artık dışa ve içe aktarabilirsiniz; bir şey beklendiği gibi çalışmadığında ekibinizle paylaşmak için harika.

Resim ve ikili dosya desteği

Agentlar artık diskten resim dosyalarını ve ikili dosyaları doğrudan okuyabiliyor. İkili dosyalar hexdump formatında sunuluyor ve resim çıktıları (entegre tarayıcıdan alınan ekran görüntüleri gibi) bir carousel görünümünde gösteriliyor.

.NET geliştiricileri için düşünün: bir UI hatasının ekran görüntüsünü sohbete yapıştırın ve agent neyin yanlış olduğunu anlasın, ya da Blazor bileşeni render çıktısını analiz ettirin.

Otomatik sembol referansları

Küçük bir yaşam kalitesi iyileştirmesi: bir sembol adını (bir sınıf, metot vb.) kopyalayıp sohbete yapıştırdığınızda VS Code artık otomatik olarak #sym:İsim referansına dönüştürüyor. Bu, agent’a manuel olarak eklemek zorunda kalmadan bu sembol hakkında tam bağlam sağlıyor.

Bunun yerine düz metin istiyorsanız Ctrl+Shift+V kullanın.

Eklentiler artık etkinleştirilebilir/devre dışı bırakılabilir

Daha önce bir MCP sunucusunu veya eklentiyi devre dışı bırakmak kaldırmak anlamına geliyordu. Artık hem genel hem de çalışma alanı başına açıp kapatabilirsiniz. Extensions görünümünde veya Customizations görünümünde sağ tıklayın ve işiniz bitti.

npm ve pypi’den eklentiler artık otomatik güncellenebilir; ancak güncellemeler makinenizde yeni kod çalıştırmak anlamına geldiğinden önce onay isteyecekler.

Sonuç

VS Code 1.112, agent deneyimini açıkça ileriye taşıyor — daha fazla özerklik, daha iyi hata ayıklama, daha sıkı güvenlik. .NET geliştiricileri için entegre tarayıcı hata ayıklama ve Copilot CLI iyileştirmeleri öne çıkan özellikler.

Bir .NET projesi için tam Copilot CLI oturumu Autopilot modunda henüz denemediyseniz bu sürüm başlamak için iyi bir zaman. Sadece izinlerinizi ayarlamayı ve bırakıp gidermeyi unutmayın.

VS Code 1.112’yi indirin veya Help > Check for Updates aracılığıyla VS Code içinden güncelleyin.

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.