Agent Harness: Kıskacı Büyütmek ve Yetenekleri Kuşanmak

Şöyle söyleyeyim, Kişisel finans asistanımızı hatırlıyor musunuz? İkinci bölümde ona portföyünüzü okumayı, işlem yapmadan önce izin istemeyi. Seanslar arası önemli şeyleri aklında tutmayı öğretmiştik. Fena değildi hani. İş görüyordu. Ama bir yerde tıkanıyordu; her bildiği tek bir prompt’un içine sıkışmıştı, işi tek hamlede yapıyordu. Dosya okuma araçlarının ötesine geçip gerçekten bir şeyi yeniden düzenleyemiyordu.

Şimdi işin asıl ilginç tarafına geliyoruz. Bu yazıda kıskacı dört ayrı yönden açacağız: skill’ler, shell erişimi, CodeAct ve arka plan ajanları. Kulağa biraz kalabalık geliyor, değil mi? Bakın, ilk bakışta mesele basit gibi dürüyor ama kurumsal ortamda devreye alınca taşlar yerinden oynuyor (özellikle izinler, güvenlik sınırları. Beklenmedik yan etkiler yüzünden), işte orada biraz dikkat gerekiyor.

Hmm, bunu nasıl anlatsamdı…

“Harness’ın yaklaşımı net: sız sadece ajanınızı sizin ajanınız yapan parçaları veriyorsunuz, gerisini altyapı hallediyor. İlk duyunca biraz iddialı geliyor ama üç ay sonra kod tabanınıza dönüp baktığınızda, dağınıklığın azaldığını görünce insan ister istemez ‘tamam ya, burada bir iş var’ diyor.”

Neden Tek Prompt Ölçeklenmez?

Şöyle bakın: Bir çalışanı işe alıyorsunuz, sonra da şirketteki her prosedürü, her hesaplama yöntemini, her risk skorlama modelini tek bir kalın kılavuza sıkıştırıp “al bunu, kolay gelsin” diyorsunuz. Adam ne yapsın? Büyük ihtimalle ilk gün indeks sayfasında kaybolur gider.

LLM tarafında da durum pek farklı değil. System prompt’a her şeyi doldurduğunuzda iki şey aynı anda patlıyor: context bloat yüzünden token bütçesi hızla eriyor, bir de model gerçekten önemli yere odaklanamıyor; focus dilution işe 40 ayrı konu arasında önceliği dağıtıyor, hâliyle halüsinasyon da artıyor. Bak şimdi, mesele sadece uzun prompt değil, asıl sorun dikkatin bölünüyor olması (evet, doğru duydunuz)

Sahada en sık gördüğüm hata bu. Ekipler “ya bir şey eksik kalırsa” diye prompt’a ne bulurlarsa ekliyor, sonra da “model saçmalıyor” diye dert yanıyor. E tabiî saçmalar.

Evet.

Skill’ler: İhtiyaç Duyulunca Öğren

Kendi deneyimimden konuşuyorum, İşte tam burada Agent Skills devreye giriyor (ben de ilk duyduğumda şaşırmıştım). Her skill aslında küçük bir SKILL.md dosyası; içinde işim var, kısa bir açıklama var, sonra da detaylı talimatlar geliyor, isterse yanında referans dokümanlar ve script’ler de durabiliyor. Yanı klasör şişirmeden işi parça parça açıyorsunuz.

Bence, Kritik nokta şu: Ajan başlangıçta sadece isimleri ve açıklamaları görüyor. Yanı bir çeşit indeks gibi düşünün. Kullanıcı istek atınca ilgili skill’in tam içeriği o anda yükleniyor; progressive loading dediğimiz şey bu. Bu arada ben bunu daha önce Agent Skills for.NET Kararlı Sürümde: Uzmanlık Artık Paketli yazısında da anlatmıştım, oraya da göz atabilirsiniz. Neyse uzatmayayım, mantık baya basit.

Bizim finans asistanına iki skill koyuyoruz: biri risk skorlama, diğeri valuation (buna dikkat edin). Kullanıcı “MSFT’yi benim için değerle” dediği anda asistan valuation skill’ını yüklüyor, rehberi okuyor, script’i çalıştırıyor. Çıktıyı üretiyor; öteki skill işe hiç devreye girmiyor. Token boşa gitmiyor, bu kadar net.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Şunu söyleyeyim, İşte, peki neden?

.NET ve Python Kullanımı

Harness tarafı varsayılan olarak skill provider’ı açık getiriyor. Çalışma dizinindeki SKILL.md dosyalarını kendi kendine buluyor. Ama biz bazen işi biraz daha kontrol etmek istiyoruz; mesela sadece belli bir klasöre bakmasını istiyoruz (hani her yeri taramasın). O yüzden kendi provider’ımızı kurup hedef klasörü veriyoruz.

Bakın,.NET tarafında kullanım şöyle ilerliyor:

var skillsProvider = new AgentSkillsProviderBuilder()
.UseFileSkills([skillsDir], scriptRunner: SubprocessScriptRunner.RunAsync)
.Build();
AIAgent agent = chatClient.AsHarnessAgent(new HarnessAgentOptions
{
DisableAgentSkillsProvider = true,
AIContextProviders = [skillsProvider],
// dosya erişimi, araçlar...
});

Python tarafında da yapı neredeyse aynı gidiyor; isimler değişiyor ama akış tanıdık:

from agent_framework import SkillsProvider
skills_provider = SkillsProvider.from_paths(
skill_paths=[str(skills_dir)],
script_runner=subprocess_script_runner,
)
agent = create_harness_agent(
client=client,
skills_provider=skills_provider,
)

Açık konuşayım, işin hoş tarafı burada çıkıyor: davranış modülerleşiyor ama prompt şişmiyor. Sız ne dersiniz? İlk bakışta küçük bir detay gibi dürüyor olabilir, fakat pratikte modelin doğru yerde doğru bilgiyi yüklemesini sağlıyor; yanı hem maliyet hem odak tarafında baya iş görüyor.

Foundry Skills: Merkezî Yönetim Meselesi

Dosya bazlı skill’ler, geliştirme aşamasında baya iş görüyor. Repo’ya atıyorsun, versiyonluyorsun, tamamdır. Ama işin aslı şu: kurumsal bir yerde çalışıyorsanız, her ajana ayrı ayrı lokal skill dosyası taşıtmak pek sürdürülebilir olmuyor.

Türkiye’deki kurumsal müşterilerimde en sık gördüğüm tablo şu: bir bankanın 12 farklı ekibi var. Hepsi de “compliance skill” istiyor. Şimdi bunu 12 repo’ya kopyaladığınızda bakım işi biraz kabusa dönüyor; bir değişiklik geliyor, 12 yerde güncelleme yapıyorsunuz, üstüne versiyonlar kayıyor, bir ekip eski sürümle çalışıp bambaşka sonuç üretiyor — yanı ortalık biraz yumak oluyor.

Foundry Skills tam da bu yüzden devreye giriyor. Skill’i merkezî tanımlıyorsunuz, bütün ajanlar aynı kaynağa bakıyor; compliance tarafı bir şey değiştirdi mi herkes önü görüyor. Hani bazen “küçük fark” dersiniz ya, burada küçük değil açıkçası (bizzat test ettim). En çok da finans, sağlık ve telekom gibi regüle alanlarda bu yaklaşım baya mantıklı dürüyor (ki bu çoğu kişinin gözünden kaçıyor)

Ne Zaman Hangisi?

Evet.

Hmm, bunu nasıl anlatsamdı…

Peki neden? Çünkü küçük işlerde dosya bazlı yapı gayet yeterli oluyor; ama ölçek büyüyünce merkezî yönetim daha az sürpriz çıkarıyor. Yine de şunu da söyleyeyim: her yerde Foundry Skills kullanacağız diye bir kural yok. Bazen repo içi basitlik daha doğru seçim olabiliyor.

Hani, Neyse, çok dağıtmadan toparlayayım: ekip küçükse. Hızlı ilerlemek istiyorsanız dosya bazlı yaklaşım işinizi görür. Ama ortak domain büyüyorsa, hele bir de denetim baskısı varsa, merkezî model ciddi rahatlık sağlıyor.

Eh, Tam da öyle.

Shell Erişimi: Kıskaç Artık Düzenleyebiliyor

Şöyle söyleyeyim, İkinci bölümde ajan dosyaları okuyordu, ama iş onları toparlamaya gelince biraz afallıyordu. Yanı “portföy klasörümü tarihe göre yeniden düzenle” dediğinizde, öyle boş boş bakıyordu. Shell araçları bu tıkanıklığı açıyor.

Ajan artık mv, mkdir, ls, grep gibi komutları çalıştırabiliyor. Güzel tarafı bu. Ama dur bir saniye, burada küçük bir güvenlik gölgesi de var.

İnanın, Açık konuşayım, ben production tarafında shell işini hep izole bir working directory ile kullanmayı severim. Ajanın küçük bir alanı olsun, dışarı taşamasın; Docker container olur, chroot benzeri bir yapı olur, fark etmez, yeter. Sınır net olsun. Azure’da bunu Container Apps üzerinde koşturuyorsanız zaten iş biraz daha rahatlıyor, ama VM üstünde host’ta çalıştırıyorsanız hmm, bir kez daha düşünmek lazım (ilk duyduğumda inanamadım)

CodeAct: Bakma, Hesapla

Şimdi işin rengi değişiyor. CodeAct, ajanın cevabı bulmak için kod yazıp çalıştırmasına izin veriyor. Yanı “portföyümdeki hisselerin son 30 günlük Sharpe oranı nedir?” gibi bir soruda ajan artık tabloya şöyle bir göz atıp sallamıyor; Python kodu yazıyor, çalıştırıyor (inanın bana). Sonucu oradan çekiyor.

Tuhaf ama, Bu fark baya önemli. Çünkü LLM’ler hesap işinde, şey, pek güven vermiyor; açık konuşayım, GPT-4 sınıfı modeller bile virgüllü sayılarda üç haneden sonra saçmalayabiliyor (bazen çok bariz değil, bazen de insanın gözüne baka baka). Finans tarafında işe bu kadar oynaklık pek hoş değil. Kimse “portföyünüz %8.4 kaybetti” yerine “%8.7 kaybetti” duymak istemez.

Çok konuştum, örnekle göstereyim.

CodeAct ile ajan şunu yapıyor: soruyu görüyor, “burada kod lazım” diye düşünüyor, Python kodunu üretiyor, çalıştırıyor, çıktıyı yorumluyor ve size sunuyor. NumPy devrede, Pandas devrede, hatta yfinance gibi kütüphaneler de işin içine giriyor; sonuç hem net oluyor hem de tekrar üretilebiliyor.

Evet.

Küçük Bir Uyarı

CodeAct güçlü ama pahalı da olabiliyor. Her hesaplama için model kod üretiyor, execution ortamı ayağa kalkıyor, çıktı geri parse ediliyor; yanı basit toplama çıkarma için bunu açmak biraz deveye hendek atlatmak gibi dürüyor (gerek yokken masraf çıkarmaya da bayılmıyorum açıkçası). O yüzden ajanın system prompt’una “sadece matematiksel karmaşıklık gerektiğinde CodeAct kullan” gibi bir kural koymanız iyi olur.

Peki neden?

Background Agents: Paralel Çalışan Yardımcılar

Buraya kadar gelen ajan, aslında tek seritte gidiyor. Bir is, sonra diğeri, sonra bir başkası. Ama bazı işler var ki, sırayla yapmak baya yoruyor; mesela “S&P 500’deki 500 hisseyi tara. Düşük P/E oranli olanları listele” diyorsanız, bunu tek tek yapmak akşama kadar uzar gider. Hatta bazen daha da kötü olur.

Background agents tam burada devreye giriyor. Ana ajan, işi alt ajanlara bir düşüneyim… dağıtıyor, onlar aynı anda çalışıyor ve çıktılar sonunda tek yerde toplanıyor; klasik fan-out / fan-in mantığı yanı, çok temiz görünüyor ama alt tarafta epey is yapıyor. Bu konunun Agent Framework tarafındaki orkestrasyon kısmını daha önce Agent Framework Orchestration 1.0: Çoklu Ajan Koordinasyonu Yetişkin yazımda da anlatmıştım, oraya da bakabilirsiniz.

Çok konuştum, örnekle göstereyim.

Maliyet Analizi

Dürüst olmak gerekirse, Şimdi FinOps sapkasini takayim. Background agents kağıt üstünde hoş dürüyor, ama bir durun — 500 tane paralel sub-agent demek 500 ayrı LLM çağrısına çıkmak demek; Azure OpenAI tarafında GPT-4 sınıfı bir modelde 1M input token kabaca 5-15 USD aralığında dolasabiliyor, TL hesabına girince de taramanin maliyeti hızla şişiyor. Evet, ciddi fark ediyor.

Ben sahada şunu tercih ediyorum: background agent’lar için mümkün olduğunca küçük model kullanın. GPT-4o-mini ya da benzeri bir şey gayet idare eder; ana ajan büyük model olsun, kararı o versin ve sonuçları yorumlasın, ama alt işleri küçük modeller yuklensin. Ilk bakışta basit geliyor ama açık konuşayım, bu ayrım maliyeti 8-10 kat dusurebiliyor.

“Enterprise ajan mimarilerinde en sık gördüğüm olumsuz hata: her şeye en pahalı modeli koymak. Sanki model seçimi bir güvence gibi görünüyor. Değil — sadece fatura büyütüyor. Model seçimi mimarı kararlar arasında en kritiklerinden biri.”

Türkiye Perspektifi: Bunu Kim Kullanacak?

Ne yalan söyleyeyim, Şimdi işin yerel tarafına geleyim. Türkiye’de kurumsal AI ajan projelerinin çoğu, açık konuşayım, finans ile telekom ile e-ticaret arasında dönüp dürüyor (bizzat test ettim). Peki bu harness yaklaşımı hangi senaryoda daha iyi oturuyor? İşte asıl soru bu.

Finans sektörü: Skill’lerin merkezî yönetimi (Foundry Skills) burada baya iş görüyor. Compliance ekibi bir kuralı güncellediğinde tüm ajanların aynı anda hizaya girmesi lazım, yoksa iş büyüyor; manuel senkronizasyon da KVKK ve BDDK tarafında baş ağrısı çıkarabiliyor.

Şahsen, Perakende / e-ticaret: CodeAct. Background agents ikilisi envanter analizi, fiyat karşılaştırma gibi işlerde fena değil. Trendyol ya da Hepsiburada ölçeğinde binlerce SKU’yu paralel işlemek gerekiyor, yoksa sistem bir yerde tıkanıyor; şey, tam da burada otomasyonun tadı çıkıyor.

KOBİ segmenti: Doğrusu bu tarafta harness biraz “ağır” gelebiliyor. 20 kişilik bir yazılım şirketi için tam harness yerine daha hafif bir çerçeve daha mantıklı olabilir, en azından başlangıçta; önce skill’lerle başlayın, ihtiyaç oldukça CodeAct’i ekleyin, en son background agents’a geçin.

Tam da öyle.

İlk Adımda Ne Yapmalı?

Bir bakıma, ne yalan söyleyeyim, Denemek isteyenlere pratik bir yol haritası bırakayım (ciddiyim). Hmm, ilk bakışta basit görünüyor. Içeride birkaç küçük tuzak var; o yüzden sırayı çok bozmayın, yoksa sonra geri dönüp toparlamakla uğraşırsınız.

1. Önce mevcut ajanınızın system prompt’ünü inceleyin. 500 token’dan uzunsa skill’lere ayırmanın vakti geldi.
2. En sık kullanılan 2-3 domain bilgisini SKILL.md dosyalarına taşıyın; böylece her şeyi prompt içine yığmamış olursunuz. (bu kritik)
3. Bir hafta boyunca hangi skill’in kaç kere yüklendiğini loglayın — kullanılmayanları temizleyin, çünkü rafta duran şey zamanla yük oluyor. — bunu es geçmeyin
4. Shell erişimini sandboxlı bir working directory ile açın, önce staging’de test edin; production’a koşmadan önce ayağı yere bassın.
5. CodeAct’i sadece matematiksel/analitik sorularda tetiklenecek şekilde konumlandırın; her soruda devreye girerse gereksiz maliyet çıkarabilir.
6. Background agents’ı en son ekleyin — maliyet monitöring hazır olmadan asla production’a atmayın. Evet, burada acele etmeye hiç gerek yok.

E sonra? İlk hafta her şey düzgün görünürse sevinebilirsiniz ama yine de loglara bakmadan rahat etmeyin. Yukarıda bahsettiğim o olay var ya, hani kullanılmayan skill’ler sessizce şişer gider; işte önü erken yakalamak baya fark ettiriyor.

Eksik Kalan Neresi?

Hani, Dürüst olayım: Harness daha yolun başında sayılır. Bazı tarafları hâlâ biraz ham geliyor. Mesela skill loading’in observability kısmı, hani, beklediğim kadar rahat değil; hangi skill ne zaman yüklendi, kaç token harcadı, bunları net görmek için biraz uğraşıyorsunuz. Çoğu zaman custom telemetry yazıp Application Insights’a bağlamak gerekiyor, işin aslı bu.

Bir de background agents tarafında hata yönetimi var ya, orada da tam içime sinmeyen yerler gördüm (ki bu çoğu kişinin gözünden kaçıyor). 500 paralel ajanın 3’ü fail olunca ne oluyor? Ana ajan bunu nasıl topluyor, nasıl ayıklıyor? Cevap çoğu senaryoda “duruma göre”. Açık konuşayım, ben bu cevabı pek sevmiyorum. Kısa. Ama can sıkıcı.

Yine de yön doğru görünüyor. Bir yıl önce böyle bir yapı kurmak için elle yazmanız gereken glue code miktarını düşününce, harness baya iş görüyor. Biraz daha pişmesi lazım tabiî. Bugün bile production’a girebilecek projeler var; özellikle Eve + Azure Cosmos DB: Unutmayan Ajan Nasıl Kurulur yazısında anlattığım persist katmanını bununla birleştirince ortaya cidden sağlam bir kombinasyon çıkıyor (bazı yerlerde sürpriz şekilde sade kalıyor, bazı yerlerdeyse beklediğinizden fazla kontrol veriyor).

Durun, bir saniye.

Sıkça Sorulan Sorular

Agent Skills ile normal function calling arasındaki fark ne?

Function calling ajana tanımlı bir aracı çağırma yeteneği veriyor. Skills işe ajana bilgi ve talimat veriyor — hani ihtiyaç anında yüklenen türden. Yanı function calling “ne yapabilirsin”i, skills “nasıl yapmalısın”ı tanımlıyor diyebiliriz. Tahmin eder mısınız? Aslında — hayır dur, daha doğrusu ikisi birbirini tamamlıyor; birini seçip diğerini bırakmıyorsunuz.

CodeAct güvenlik açısından risk mi yaratıyor?

Doğru izole edilmezse evet, kesinlikle. Ajanın yazdığı kod bir sandbox içinde çalışmalı — mesela üretim veritabanınıza doğrudan bağlanmaması şart. Harness bu izolasyonu sağlıyor ama bence sız de working directory. Network erişimini kısıtlayarak ekstra bir katman koymalısınız. Production’da CodeAct çıktısını büyük ihtimalle loglayın, açıkçası bu adımı atlamayın.

Background agents her senaryoda paralel işi hızlandırır mı?

Hayır. Küçük iş yüklerinde orkestrasyon overhead’i faydayı yiyor. Kabaca söylersem: 10’un altında paralel işte tek ajan genelde daha hızlı ve ucuz. 50+ paralel iş varsa background agents kazanmaya başlıyor. Arada kalanlarda — yanı gri bölgede — bence benchmark yapmadan karar vermeyin.

Foundry Skills için ekstra Azure maliyeti var mı?

Foundry’nın kendi fiyatlandırma modeli var; skill sayısına göre değil, kullanım hacmine göre işliyor. Küçük ölçekli kullanımda maliyet ihmal edilebilir düzeyde. Ama binlerce ajanın merkezî skill’lere sürekli eriştiği bir ortamda, Foundry’nın read tarafındaki quota’ları önceden planlamak lazım — tecrübeme göre bu kısım sürpriz yapabiliyor. Fiyatlama detayları için Microsoft’un resmî sayfasını takip edin.

Harness.NET ve Python arasında feature parity var mı?

Açık konuşayım, Şu an büyük ölçüde evet. Ama Python tarafı genelde bir tık önde gidiyor —. Yeni özellikler önce orada çıkıyor, sonra.NET’e geliyor..NET ekibi bu farkı hızlı kapatıyor aslında. Yine de kritik projelerinizde tercih yaparken güncel dokümantasyonu bir kontrol edin, açıkçası bu fark zaman zaman önemli olabiliyor.

Kaynaklar ve İleri Okuma

Agent Harness: Scaling the Claw or Harness Capabilities — Microsoft DevBlogs

Microsoft Agent Framework Resmî Dokümantasyonu

Microsoft Agent Framework GitHub Repository (şaşırtıcı ama gerçek)

Give Your Agents Domain Expertise with Agent Skills

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

MSSQL Extension v1.43: Azure SQL'i VS Code'dan Kurmak Artık Mümkün28 Haz 2026

PyCon US 2026’de Python Ekosistemi Nereye Gidiyor?18 May 2026

Bot PR’lere de CI yolu açıldı: Güvenlikte ince ayar zamanı12 Haz 2026

Azure Files NFS ile Modern Linux İş Yükleri: Sahadan Bakış6 Tem 2026