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 Agent Framework Orchestration 1.0: Çoklu Ajan Koordinasyonu Yetişkin ile birlikte düşünülünce, ajan tarafında baya net bir olgunlaşma sinyali veriyor. Hani bazen küçük görünen bir değişiklik olur ya, sonra bütün mimariyi başka yere çeker; işte burada öyle bir his var. Peki, sız ne dersiniz?
Evet, doğru duydunuz.
Agent Skills tam olarak nedir?
Bir “skill”i şöyle düşünün: İçinde bir SKILL.md dosyası, birkaç script, belki de iki üç referans PDF’i ya da markdown notu duran bir klasör. Ajan da bunu ilk bakışta kutu gibi görüyor, hani üstünde “İK Politikaları” ya da “Azure Fatura Analizi” yazan türden. İçine hemen dalmıyor. Önce sadece etikete bakıyor.
Bakın, Kullanıcı bir soru sorunca, ajan kendi kendine şunu yokluyor: “Bu soru hangi kutuya uyuyor?” Uyanı bulursa kutuyu açıyor, talimatları okuyor, gerekiyorsa içindeki script’i çalıştırıyor. Başka kutulara elini bile sürmüyor. Güzel tarafı bu; sade çalışıyor.
Bu işin teknik adı progressive disclosure, yanı kademeli açığa çıkarma. Dört adımda ilerliyor, ama açık konuşayım, kağıt üstünde basit duran şey pratikte baya iş görüyor:
- Skill isimlerini/açıklamalarını göster
- İhtiyaç olanın talimatlarını yükle
- Referans kaynaklarını oku
- Gerekirse script’i çalıştır
İşin aslı şu: ajanın “beyni” (yanı sistem prompt’u) bu bilgilerle şişmiyor. Otuz farklı departman politikasını her sohbette taşımıyorsunuz, ki bu zaten biraz saçma olurdu (ki bu çoğu kişinin gözünden kaçıyor). Sadece o anki soruyla alakalı olanı yüklüyorsunuz; gerisi rafta dürüyor, bekliyor.
Evet.
Bir ajanı prompt yığınıyla eğitmeye çalışmak, bir çalışana her sabah tüm şirket el kitabını ezberletmeye benziyor. Skills yaklaşımı işe raftaki dosyayı gerektiğinde açmasına izin veriyor. Fark ölçülmeyecek kadar büyük.
Burada, peki neden? Çünkü burada mesele daha çok doğru bilgiyi doğru anda göstermek. Hepsi bu kadar değil tabiî; yanlış şeyi erken yüklemezseniz hem kafa karışıklığı azalıyor hem de ajan daha az gereksiz bağlam taşıyor (ki bu kısım çoğu zaman gözden kaçıyor).
Bir bakıma, tam da öyle.
Neden bu sürüm önemli?
İtiraf edeyim, Açık konuşayım, preview aşamasındaki bir API’yi production’a almak çoğu kurumsal yerde epey yoruyor. Compliance ekibi bekliyor. Mimarı komitesi de “kararlı sürümü bekleyelim” diyor; haklı oldukları taraf var, (yanlış duymadınız). Kimse yarın sabah kırılan bir entegrasyonla uğraşmak istemiyor.
Şimdi o duvar biraz kalktı. API sabit, [Experimental] etiketi yok. Yanı mimarı onaylarda “bu Microsoft’un GA ürünü” diyebiliyorsunuz; kağıt üstünde ufak bir detay gibi dürüyor ama sahada haftalar süren beklemeyi ciddi biçimde kısaltıyor. Evet, mesele bu kadar pratik.
Türkiye pazarı açısından ne anlama geliyor?
Türkiye’deki kurumsal müşterilerde sık gördüğüm bir şey var: LLM tabanlı projeler önce bir POC ile başlıyor, sonra “peki bunu nasıl ölçekleyeceğiz?” sorusunda hafifçe tökezliyor. Prompt’ları versiyonlamak, farklı ekiplerin yazdığı prompt’ları tek düzene sokmak, güncellemeleri denetlemek (bak şimdi, asıl iş burada başlıyor) Türkçe kaynaklarda pek konuşulmuyor (ki bu çoğu kişinin gözünden kaçıyor). Gerçek dert tam da bu.
Skills paketleri işte bu boşluğu dolduruyor. Bir ekip İK politikası skill’ını yazıyor, başka bir ekip finans onay akışını çıkarıyor, bir başkası IT güvenlik prosedürünü ekliyor; hepsi ayrı repolarda dürüyor, ayrı sürüm numaralarıyla geliyor ve ajan çalışma zamanında bunları bir araya getiriyor. Türkiye’deki holding yapıları — müşterilerimin çoğu böyle — buna baya uyuyor,. Her iştirak kendi skill’ını yazabiliyor, merkezî ajan da hepsini gerektiği anda kullanıyor. Şey, kulağa düzenli geliyor ama sahada ilk kurulumda biraz dağınık hissettirebiliyor.
Üç farklı yazım stili: hangisi kime?
Release ile birlikte üç yazım tarzı geliyor. Aynı provider’a bağlanıyorlar, ajan çalışma zamanında bunları ayırmıyor bile; ama iş geliştirme tarafına gelince, hikâye biraz değişiyor. Evet, fark orada.
1. File-based skills
Klasik yol bu. Bir klasör açıyorsunuz, içine SKILL.md koyuyorsunuz, üstüne isterseniz birkaç script ve referans dokümanı ekliyorsunuz; içerik ekibi de rahatça katkı verebiliyor çünkü çoğu şey zaten markdown, yanı işin aslı biraz dosya düzeniyle çözülen bir mesele. Development dışındaki bir grubun skill yazmasını istiyorsanız, açık konuşayım, en mantıklı seçeneklerden biri bu.
2. Code-based skills
Şahsen, Burada iş.NET sınıflarına dönüyor. Metadata’yı property’lerle veriyorsunuz, compile-time güvenlik var, IDE yardım ediyor, test yazmak da fena zorlamıyor — kısa cümleyle söyleyeyim, geliştirici eli değecekse baya iş görüyor. Peki, ama dur bir saniye: bu yapı her ekip için şart mı? Değil tabiî; daha çok development ekibinin sahip çıkacağı skill’ler için uygun dürüyor (ilk duyduğumda inanamadım)
İşte tam da bu noktada devreye giriyor.
3. Custom/programmatic skills
Şimdi biraz daha farklı bir yere gidiyoruz (yanlış duymadınız). Kendi kaynağınızdan (veritabanı, — ki bu tartışılır — blob storage, uzak bir API) skill üreten özel provider yazabiliyorsunuz; hani burada olay tek tek dosya yönetmekten çıkıp veri akışını kontrol etmeye dönüyor. Bu yaklaşım özellikle “çok kiracılı SaaS ürünüm var, her müşterinin kendi skill seti olsun” diyen senaryolarda anlam kazanıyor. Deutsche Telekom OpenAI ile Telekomu Baştan Kuruyor yazımızda bu konuya da değinmiştik.
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. Bu konuyla ilgili Node Readiness Controller: Kubernetes’te Ready’nin Ötesi yazımıza da göz atmanızı tavsiye ederim.
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. GPT-5.6 Sol, Terra, Luna Copilot’ta: Hangisi Sizin İçin? yazımızda bu konuya da değinmiştik.
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? Eve + Azure Cosmos DB: Unutmayan Ajan Nasıl Kurulur yazımdaki kalıcı bellek yaklaşımıyla birlikte kullanınca, ajan hem geçmişi hatırlıyor hem de standart operasyondan sapmıyor; açık konuşayım, sahada baya iş görüyor.
Çok ekipli skill kompozisyonu
Ne yalan söyleyeyim, Farklı ekipler ayrı repolarda ya da iç NuGet feed’inde skill paketleri yayınlıyor. Sız bunları tek bir ajana bağlıyorsunuz, sonra da olay kendiliğinden akıyor gibi oluyor. Cross-team koordinasyon toplantısı yok; en azından eskisi kadar yok diyeyim. Her ekip kendi skill’ını kendi hızında güncelliyor, ajan da çalışma zamanında en güncel sürümü çekiyor (buna dikkat edin) Bu konuyla ilgili Azure AI Foundry Kota Başvurusu Otomasyonu: Ücretsiz Web Aracıyla Hızlı Çözüm yazımıza da göz atmanızı tavsiye ederim.
Evet.
Türkiye’de maliyet perspektifi
Bunu Türkiye’deki şirketler açısından düşününce tablo biraz değişiyor. Token maliyetleri hâlâ dolar bazlı, TL’nın hali de ortada; o yüzden sistem prompt’unda 8000 token taşımakla 800 token taşımak arasında, ilk bakışta ufak gibi duran ama ay sonunda can sıkan bir fark çıkıyor. net ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder