Agent Skills for .NET Kararlı Sürümde: Uzmanlık Artık Paketli
Uzun zamandır bunu bekliyordum. Nihayet Agent Skills for.NET deneysel etiketten çıktı. Production’a hazır bir API olarak karşımıza geldi. [Experimental] attribute’u da kaldırıldı, imzalar da sabitlendi. Yanı artık kurumsal bir projeye “beta bir şey kullanıyoruz” mahcubiyetiyle girmiyorsunuz.
Peki bu ne anlama geliyor pratikte? Kısaca şöyle: Ajanınıza bir alan uzmanlığı veriyorsunuz — talimatlar, referans dokümanları, script’ler — sonra o bunları gerektiğinde, sadece gerektiğinde yüklüyor. Context window şişmiyor, ajan da “her şeyi bilmeye çalışan” o klasik hantal yapıya kaymıyor. İyi tarafı bu. Ama dur bir saniye, asıl mesele biraz daha derinde. Burada sadece dosya yüklemekten değil, ajanın işi doğru anda doğru parçayla çözmesinden söz ediyoruz.
Uzatmadan gireyim konuya. Bu özellik, özellikle
Küçük ekipseniz file-based ile başlayın derim, sonra ihtiyaç çıkarsa eliniz rahat rahat başka tarafa kayar. Büyük kurumsal yapılarda işe çoğu zaman karışık gidiliyor — genel politikalar file-based oluyor, dinamik iş kuralları code-based tarafa kaçıyor; aslında şaşırtıcı değil. Ilk bakışta biraz karmaşık görünüyor. Sız ne dersiniz?
Basit bir örnekle bakalım
SKILL.md dosyası kabaca böyle dürüyor, hani ilk bakışta çok da büyütülecek bir şey yok gibi geliyor ama işin içine girince tablo değişiyor, çünkü ajan burada ne yapacağını kendi başına sezmeye başlıyor (ve açık konuşayım, bu taraf baya iş görüyor).
Durun, bir saniye.
---
name: expense-policy
description: Şirket masraf politikası sorularını yanıtlar,
onay eşiklerini kontrol eder, uygun kategorileri belirler.
version: 1.2.0
---
# Masraf Onay Politikası
## Onay eşikleri
- 500 TL altı: doğrudan onay
- 500-5000 TL arası: bölüm müdürü onayı
- 5000 TL üstü: finans direktörü onayı
## Coworking harcaması
Sadece uzaktan çalışan pozisyonlar için,
aylık üst limit 2500 TL...
C# tarafında da bunu şöyle bağlıyorsunuz, yanı çok süslü bir kurgu yok; agent nesnesine skill kaynağını veriyorsunuz ve gerisi akıyor gibi görünüyor (tabi perde arkasında birkaç karar noktası var, ama sız tek tek uğraşmıyorsunuz):
var agent = new ChatClientAgent(chatClient, options)
.WithSkills(skillProvider);
// skillProvider ister dosyadan, ister koddan,
// ister özel kaynaktan skill'leri sağlıyor
Ajan çalışma zamanında hangi skill’i kullanacağına kendi karar veriyor. Sız routing logic yazmıyorsunuz — bu bence en tatlı kısmı. Klasik chatbot mimarilerindeki o dallanma-budaklanma if/else kabusundan kurtuluyorsunuz (inanın bana)
İşte tam da bu noktada devreye giriyor.
İnanın, Evet.
Karşılaştırma: Skills vs klasik yaklaşımlar
| Yaklaşım | Context Yükü | Bakım | Ekipler Arası Paylaşım |
|---|---|---|---|
| Dev prompt (her şey system message’da) | Çok yüksek | Zor, tek dosya şişer | Kötü, merge conflict cehennemi |
| RAG (embedding + vector DB) | Orta | Ayrı altyapı gerekir | Orta, semantik arama kalitesine bağlı |
| Function calling / tools | Düşük | Kod düzeyinde bakım | Orta, tool tanımları merkezî |
| Agent Skills | Çok düşük (progressive) | Modüler, versiyonlanabilir | Çok iyi, bağımsız paketleme |
Lafı gevelemeden söyleyeyim, burada asıl mesele context’in nasıl yandığı. Dev prompt tarafında her şeyi tek yere yığarsanız iş çabuk dağılıyor; bir de üstüne ekip büyüyünce dosya iyice şişiyor, sonra kim neyi değiştirdi diye bakarken insanın canı sıkılıyor.
Peki neden? Çünkü RAG ve tools gibi yöntemler işi biraz rahatlatıyor ama hepsi ayrı dert de getiriyor (inanın bana). Mesela RAG’da embedding kalitesi iyi değilse sonuçlar da sallanıyor, tool tarafında işe kodla prompt arasında gidip geliyorsunuz (bir yerde küçük bir değişiklik yapıyorsunuz, başka yerde zincirleme etki çıkıyor), yanı idare eder. Tam rahat değil.
Tam burada Agent Skills devreye giriyor. Çok düşük context yükü veriyor, modüler gidiyor ve versiyonlayabiliyorsunuz; açık konuşayım, ekipler arasında paylaşmak da baya kolaylaşıyor çünkü herkes aynı koca metne abanmak zorunda kalmıyor.
Bir dakika, şunu da ekleyeyim: Skills, RAG’ın yerini almıyor. Aksine iyi bir eşleşme oluşturuyorlar (kendi tecrübem). Bir skill içinde “gerektiğinde şu vektör indeksinden arama yap” talimatı olabiliyor. Yanı birbirini tamamlıyorlar.
Evet.
Kurumsal senaryolar: sahadan pratik örnekler
Politika uygulaması
Dürüst olmak gerekirse, Şirketinizin İK, masraf ve IT güvenlik politikalarını üç ayrı skill olarak paketliyorsunuz. Çalışana bakan ajan, soru hangi alandansa ilgili skill’i açıyor; cevap da oradan geliyor. Aynı temeli herkes alıyor, işte bu iyi taraf. Bir de şu var: süreç iz bırakıyor, yanı log’lardan hangi skill’in hangi versiyonunun kullanıldığı net görünüyor, FinTech ve kamu tarafında ben bunu boşuna önemli bulmuyorum.
Destek playbook’ları
Support ekibinin troubleshooting rehberlerini skill’e çeviriyorsunuz. Müşteri bir sorun bildirdiğinde ajan eşleşen playbook’u yüklüyor ve adımları tek tek takip ediyor. Personel değişince ya da vardiya dönünce ortaya çıkan o tanıdık tutarsızlık var ya, ciddi biçimde azalıyor. Sız ne dersiniz?
Kaba bir hesap yapalım. Günde 10.000 sohbet dönen kurumsal bir ajan düşünün; her sohbette 7000 token tasarruf ediyorsanız (skills ile bu gayet mümkün, hatta bazı senaryolarda daha da aşağı iniyor), aylık yaklaşık 2.1 milyar token farkı konuşuyoruz. Peki bunu neden söylüyorum? GPT-4 sınıfı bir modelde bu iş, açık söyleyeyim, orta ölçekli bir mühendisin maaşına kadar gidip geliyor.
Ve işler burada ilginçleşiyor.
Nereden başlamalı? Pratik yol haritası
Aslında, Denemek istiyorsanız, ilk iş şunları yapın. Kulağa basit geliyor, biliyorum; ama bazen en işe yarayan başlangıçlar zaten böyle oluyor.
- Küçük bir skill ile başlayın. Şirketinizde en çok sorulan tek bir politikayı alın (mesela izin politikası), bunu SKILL.md olarak yazın. İlk adım bu kadar dar olsun; çünkü işi büyütürseniz, ajan neyi neden çağırdığını takip etmek de çorba oluyor.
- Test ajanı kurun. Sadece bu tek skill’i kullanan bir konsol uygulaması yazın. Ajanın skill’i doğru zamanlarda çağırıp çağırmadığını gözleyin; hani teori güzel dürüyor ama pratikte küçük bir yanlış seçim, bütün akışı bozabiliyor. (bu kritik)
- İkinci skill’i ekleyin. İşin gerçek testi ikinci skill’de başlıyor — ajan doğru olanı seçebilecek mi? Az önce her şey kontrollüydü, şimdi ufak bir karmaşa giriyor ve asıl mesele de burada belli oluyor.
- Versiyonlama kurun. Skill’leri iç NuGet feed’ine veya git submodule olarak koyun. Yamalanabilirlik kritik; yoksa bir gün ufak bir değişiklik yüzünden eski davranışa geri dönmek için epey uğraşırsınız.
- Prodüksiyona almadan önce audit log ekleyin. Hangi skill hangi karar için kullanıldı — bunu loglamak zorundasınız. Açık konuşayım, bu kısmı atlayan ekipler sonra “neden böyle yaptı?” diye logların peşinde koşuyor.
Awesome Copilot repo’sunda hazır skill’ler var, oradan da ilham alabilirsiniz. Ama tavsiyem şu: kopyala-yapıştır yapmayın. Kendi domain diliniz farklı olur, örnekleri okuyun ama kendi yapınıza göre yazın; yoksa kağıt üstünde düzgün duran şey, içeride biraz yamuk çalışıyor gibi hissedilebilir.
Tam da öyle.
Eleştirel bakış: eksik olan neler?
Övelim, tamam. Ama fazla da gazlamayalım. Skills tarafı baya iyi bir soyutlama veriyor, yine de etrafında oturmuş bir ekosistem yok; işin aslı burada biraz “çekirdek var ama çevre daha yeni toparlanıyor” hissi geliyor bana.
- Skill test framework’ü: Bir skill’in doğru zamanda tetiklendiğini otomatik test etmek için resmî bir yol hâlâ netleşmedi. Kendi test harness’ınızı yazıyorsunuz, yanı iş biraz size kalıyor; kağıt üstünde kolay dürüyor ama pratikte uğraştırabiliyor. — ciddi fark yaratıyor
- Görsel skill editörü: İş kullanıcısının SKILL.md düzenlemesi açık konuşayım zor. Bir yönetim paneli olsa baya iş görürdü, çünkü herkes markdown dosyasıyla cebelleşmek istemiyor.
- Marketplace: Awesome Copilot fena değil, iyi bir başlangıç sayılır ama Türkçe içerik tarafı hâlâ çok zayıf. Bu boşluğu topluluk dolduracak gibi dürüyor, başka türlü zor. — bunu es geçmeyin
Tuhaf ama, Peki sonuç ne? Temel API çekirdek olarak sağlam dürüyor, buna lafım yok. Çevresindeki tooling kısmı biraz — kendi adıma konuşayım — daha pişmek istiyor (hani şu “öldü gibi ama tam olmadı” hali var ya), o yüzden ben şimdilik temkinliyim. Kağıt üstünde güzel, sahada işe göreceğiz artık.
Evet.
Foundry ve diğer Microsoft servisleriyle uyum
Skills tek başına değil. Microsoft Foundry Haziran 2026: Haziran’da Ne Değişti? yazımda bahsettiğim gibi, Foundry tarafında ajan yaşam döngusu yavaş yavaş daha iç içe geçiyor. Skills’i Foundry projelerinde de kullanabiliyorsunuz. Güzel tarafı şu, Work IQ ile beraber ajana hem organizasyonel context (kim kimdir, hangi belge kimin) hem de domain expertise (skill) verebiliyorsunuz; yanı iş biraz daha toparlanıyor, ama dur bir saniye — burada asıl mesele sadece bilgi eklemek değil, önü doğru yerde kullandırmak.
Sıkça Sorulan Sorular
Agent Skills, function calling’in yerini mi alıyor?
Hayır, aslında ikisi birbirini tamamlıyor. Hani function calling somut bir iş yapmak için kullanılıyor, mesela veritabanına bir şeyler yazmak gibi. Skills işe daha büyük bir paket — talimat, doküman ve opsiyonel script bir arada. Bakın, bir skill içinde birden fazla function tanımı da olabiliyor. Bence ikisini birlikte kullanmak en sağlıklısı.
Skill’ler kaç dilde yazılabiliyor?
Bu sürüm.NET için. Python tarafında da Agent Framework’ün kendi Skills implementasyonu var. Açıkçası format (yanı SKILL.md yapısı) aynı olduğu için, iyi tasarlanmış file-based skill’ler her iki tarafta da çalışabiliyor. Yalnız script’lerin dili değişiyor tabi, önü atlamamak lazım.
Skills için ekstra bir altyapı maliyeti var mı?
Kütüphanenin kendisi için hayır, saf bir kütüphane bu. Ama skill’lerinizi saklayacak bir yere ihtiyacınız var — mesela git repo, NuGet feed ya da blob storage (buna dikkat edin). Script çalıştıracaksanız sandbox altyapısı da gerekiyor. Küçük projelerde bu iş dosya sisteminden halloluyor, ama kurumsal düzeyde biraz önceden plan yapmanız gerekiyor.
Skill script’leri hangi yetkilerle çalışıyor? Güvenlik riski var mı?
Script execution mode açıkken, script’ler ajan sürecinin haklarıyla çalışıyor (ki bu çoğu kişinin gözünden kaçıyor). Bu ciddi bir güvenlik meselesi, hafife almamak lazım. Kurumsal senaryoda skill’leri imzalamak, güvenilir kaynaklardan yüklemek ve script sandbox’ı kullanmak şart. Tecrübeme göre prodüksiyona almadan önce mutlaka bir güvenlik gözden geçirmesi yapın.
Mevcut Semantic Kernel projelerimi nasıl geçireceğim?
Semantic Kernel’daki plugin ve prompt template yapıları Agent Framework Skills’e biraz benziyor ama bire bir aynı değil. Tam otomatik bir migration aracı henüz yok maalesef. Yanı prompt template’leri SKILL.md formatına dönüştürüp, function’ları da code-based skill olarak yeniden paketlemeniz gerekiyor. Emek isteyen bir süreç, ama bence bir kez yaptığınızda gerçekten çok temiz bir yapıya kavuşuyorsunuz.
Kaynaklar ve İleri Okuma
Agent Skills for.NET Is Now Released — Microsoft DevBlogs
Şahsen, Microsoft Agent Framework Resmî Dokümantasyonu
Microsoft Agent Framework GitHub Repository
Awesome Copilot: Hazır Skill Örnekleri
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments