Bakın şimdi, küçük bir itirafla başlayayım: Agent mimarilerini ilk kurcaladığımda beni en çok geren şey model kalitesi değildi. Hiç değildi hatta. Asıl can sıkan taraf, minicik bir iş için bile agent’ın model → tool → model → tool → model döngüsüne takılıp kalmasıydı; tek bir “Seattle. Amsterdam’ın havasını karşılaştır” sorusunda bile 5 tür atıyorduk, her tür ayrı HTTP isteği, ayrı token faturası, ayrı gecikme. Cidden yorucu.
İlginç olan şu ki, Geçen hafta Microsoft’un Agent Framework’e eklediği CodeAct desteğini deneme fırsatı buldum — tam da bu döngüyü azaltmayı hedefliyor. Ve açık konuşayım, sonuçlar baya şaşırttı beni. Ham rakamlarda latency’de %50 civarı, token kullanımında da %60’tan fazla düşüş gördüm. Ama rakamlara dalmadan önce mantığı anlatayım. Her senaryoda uygun çözüm değil, öyle körlemesine atlanacak iş değil.
Meselenin özü ne peki? Orkestrasyon vergisi
Modern LLM’ler artık “akıllı mı acaba?” seviyesini geçti gıbı. Yanı GPT-4 sınıfı bir model, verdiğiniz 7 tool arasından doğru olanı seçip sırayla çağırabiliyor. Problem zekâ değil. Problem şu: her adımda yeniden modele gidiyoruz. İşin acı kısmı burada başlıyor.
Bir dakika — bununla bitmedi.
Düşünün biraz. Agent şöyle akıyor: “Önce Seattle için weather tool’u çağır” diyor, modele dönüyor; sonra “cevap geldi, şimdi Amsterdam’ı çek” diyor, yine modele dönüyor; ardından “ikisi de tamam, şimdi karşılaştır” diye tekrar dönüyor; en son cevap yazdırıyor. Dört round trip var. Dört kere prompt, context ve tool schema’ları baştan yollanıyor. Token faturası da doğal olarak şişiyor.
Aslında — hayır dür, daha doğrusu — dür bir saniye — daha net söyleyeyim: bu mimarideki en can sıkıcı nokta modelin context’i her turda yeniden okuması. Önceki mesajlar, sistem promptu, tool tanımları… hepsi tekrar işleniyor. Siz hiç denediniz mi? Buradan çıkan input token patlaması var ya, işte mesele o.
Evet.
CodeAct pattern’i nasıl çalışıyor?
Fikir aslında basit ama fena da işlemiyor: Modele onlarca tool vermek yerine tek bir execute_code tool’u veriyorsunuz. Model de planını küçük bir Python programı olarak yazıyor. Tool’lara program içinden call_tool(...) ile erişiyor. Yanı kendi kodunu üretiyor; şöyle bir şey mesela:
seattle = call_tool("get_weather", city="Seattle")
amsterdam = call_tool("get_weather", city="Amsterdam")
diff = seattle["temperature_c"] — amsterdam["temperature_c"]
result = {
"seattle": seattle,
"amsterdam": amsterdam,
"temp_difference_c": diff
}
Bu kod sandbox içinde tek seferde çalışıyor, sonuç da topluca modele geri geliyor (evet, doğru duydunuz). Dört tür yerine iki tür kalıyor: biri kodu üretmek için, biri sonucu yorumlamak için. Hani ilk duyduğumda “bu kadar mı?” dedim ya; evet, gerçekten bu kadar basit duruyor.
Model artık “hangı tool’u çağırayım?” diye defalarca sormuyor kendine. Bir kere plan yapıyor, kodu yazıyor ve çıktıyı yorumluyor. İnsan yazılımcının yaptığı şeye benziyor aslında — önce düşün, sonra çalıştır.
Hyperlight devreye girince ne oluyor?
“Model kod üretiyor ve çalıştırıyor” dediğim anda bazılarınızın kaşı kalkmıştır muhtemelen. Haklısınız da. LLM’in yazdığı Python’ı doğrudan üretim sunucusunda koştursaydık bu tam bir güvenlik kabusu olurdu. İşte burada Microsoft’un Hyperlight projesi devreye giriyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Hyperlight; WebAssembly ile hypervisor seviyesindeki izolasyonu harmanlayan bir mikro-VM yaklaşımı sunuyor diyelim kısaca. Her kod çağrısı için yeni. Izole bir ortam açılıyor — hem de milisaniyeler içinde (evet, kulağa biraz tuhaf geliyor ama öyle). Docker container kadar ağır değil, process sandbox kadar gevşek de değil; arada bir yerde duruyor. Bence bu denge fena değil.
agent-framework-hyperlight paketi şu an alpha aşamasında ve CodeAct kodunu bu mikro-VM’lerde çalıştırıyor. Yanı model gidip yanlışlıkla os.system("rm -rf /") benzeri bir şey yazsa bile o komut sizin diske uzanmıyor; mikro-VM kapanıp gidiyor. Açık konuşayım, burası rahatlatıcı taraf.
Hyperlight, Microsoft Research’ten çıkan ve CNCF sandbox projesi olan bir teknoloji.
Başlangıçta serverless workload’lar için tasarlanmıştı ama CodeAct gıbı senaryolarda da baya işe yarıyor.
Açılış süresi 1-2 ms civarında olduğu için agent’ın her turunda yeni VM açmak teoride gayet mümkün görünüyor.
Peki pratikte nasıl kurulur?
Kendi müşterilerimden birinde Azure OpenAI üstünden çalışan internal helpdesk agent’ı vardı mesela.
SharePoint’ten doküman çekiyor, CRM’den kayıt okuyor, sonra bunları toparlayıp özetliyordu.
Klasik tool chain yanı.
Ortalama 6-8 tool çağrısı per request görüyorduk.
Bunu CodeAct’e taşıyınca yapı şöyle öldü:
from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider
@tool
def get_weather(city: str) -> dict[str, float | str]:
"""Return the current weather for a city."""
return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}
codeact = HyperlightCodeActProvider(
tools=[get_weather],
approval_mode="never_require",
)
agent = Agent(
client=client,
name="CodeActAgent",
instructions="You are a helpful assistant.",
context_providers=[codeact],
)
result = await agent.run(
"Get the weather for Seattle and Amsterdam and compare them."
)
Dikkat ettiyseniz tool tanımı aynı kaldı.
Agent tanımı da aynı.
Sadece context_providers‘a HyperlightCodeActProvider ekleniyor.
Yanı mevcut agent kodunu çöpe atmanız gerekmiyor; benim hoşuma giden taraflardan biri de bu zaten.
approval_mode parametresi boş geçilmez
Yukarıda approval_mode="never_require"
yazdım ama bunu prod’a alırken iki kez düşünmek lazım.
Alternatifler arasında always_require
(her kod bloğu için onay ister)
ve require_for_sensitive
gıbı seçenekler var.
Ben olsam development ortamında never_require,
staging’de kilit tool’lar için manuel onay,
prod’da işe audit log + asenkron review tarafına bakarım.
Kısacası güvenliği hafife almayın.
Peki neden?
Çünkü sorun modelden çok süreçte çıkabiliyor bazen. Azure Smart Tier GA: Blob Depolamada Otomatik Tasarruf yazımızda bu konuya da değinmiştik. GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımızda bu konuya da değinmiştik.
Sayılar ne söylüyor? Kendi testimde ne gördüm?
Theori konuşmak kolay tabii.
Ben kendi laboratuvarımda aynı agent’ı iki farklı şekilde koşturdum — klasik tool-calling ve CodeAct.
50’şer koşu aldım ve ortalama sonuçlar aşağı yukarı şöyle çıktı:
bir tarafta daha fazla tür var,
öbür tarafta daha az sürtünme var;
sonuç da şaşırtıcı biçimde ikinci tarafa kaydı. Daha fazla bilgi için Gateway API v1.5: Stable’a Taşınan Özellikler ve Notlarım yazımıza bakabilirsiniz.
| Metrik | Klasik Tool Chain | CodeAct + Hyperlight | Fark |
|---|
Gördüğünüz gıbı başarı oranında küçük bir düşüş var.
Neden?
Çünkü bazen model yazdığı kodda tökezliyor;
yanlış parametre veriyor,
dict erişimini bozuyor,
bazen de ufak syntax kaçırıyor falan.
Bu durumda retry gerekiyor işte.
Ama genel tabloya bakınca CodeAct kazanıyor,
hem de net şekilde kazanıyor diyebilirim.
Az önce söylediklerimi biraz geri çekeyim:
burada asıl kazanç hızdan çok sürtünmenin azalması gıbı duruyor aslında.
Evet,
mesele tam olarak o olabilir. SELinux Volume Label Değişiklikleri GA: v1.37’de Neler yazımızda bu konuya da değinmiştik. Google’ın Yeni TPU Hamlesi: Ironwood ve Axion Sahnede yazımızda bu konuya da değinmiştik.
Tamam da Türkiye’deki kurumsal dünyada işler nasıl gider?
Şimdi benim asıl kafa yorduğum yere geleyim.
Logosoft’ta danışmanlık verdiğim müşteri profili çoğunlukla bankacılık,
telco ve kamu tarafında oluyor.
Bu alanlarda
“model ürettiği kodu çalıştırıyoruz”
cümlesi bazı compliance ekiplerinin kaşlarını havaya kaldırır;
haklılar da açıkçası.
Bir bankada CISO ile CodeAct’i konuştuğumuzda ilk soru şuydu:
“Model prompt injection’a maruz kalırsa ürettiği kod sandbox’ı bypass edebilir mi?”
İyi soru.
Hyperlight mikro-VM seviyesinde izolasyon sunduğu için teoride kaçış çok zor görünüyor ama şunu net söyleyeyim:
henüz alpha aşamasında olduğu için üretime alınmasını ben şahsen aceleye getirmem.
En az 6-12 ay daha olgunlaşması lazım bence.
Şu anda staging ortamlarında,
internal tool’larda,
kontrollü denemelerde kullanmak daha mantıklı duruyor.
Kurumsal tarafta Türkiye’de benimsenme hızı biraz yavaş olacak gıbı;
çünkü KVKK ve BDDK tarafındaki denetim ekipleri
“LLM üretimi code execution”
fikrine doğal olarak mesafeli bakabiliyor.
İlk adım büyük ihtimalle sınırlı tool seti
ve agresif output filtreleme ölür.
Neyse uzatmayayım,
burada ana mesele teknoloji değil sadece;
kurumun risk iştahı da işin içine giriyor.
İkınci oyun planına bakalım: Startup vs Enterprise farkıAçık söyleyeyim:
Eğer 5-10 kişilik bir startup’sanız ve AI agent ürünü geliştiriyorsanız,
CodeAct sizin için baya mantıklı .
Token maliyetlerini yarıya indirmek cash flow’a doğrudan dokunur;
latency düşüşü de kullanıcı deneyimini ciddi biçimde rahatlatır.
Denediniz mi hiç?
Küçük ekiplerde böyle şeyler bazen sandığınızdan hızlı değer yaratıyor.
Enterprise tarafı işe başka oyun oynuyor.
Bir sigorta şirketinde CodeAct’i devreye almak sadece kod değiştirmek demek değil;
security review,
penetration test,
DLP entegrasyonu,
audit log altyapısı derken karşınıza rahatça 3-4 aylık program çıkabiliyor.
Bu yatırımı yaparken elde edeceğiniz tasarruf bunu karşılıyor mu?
Önü hesaplamak lazım.
Agent trafiğiniz günde binlerce istek seviyesindeyse evet,
karşılayabilir.
Yüz-iki yüz istek civarındaysa beklemek belki daha akıllıca ölür.
Bu arada az önce startup lehine konuştum ama enterprise büyük ölçüde uzak dursun demiyorum;
sadece tempo başka diyorum.Maliyet analizi TL bazında ne ediyor?Somut örnek verelim barı.
Aylık 1 milyon agent isteği alan bir sistem düşünün.
Klasik yapıda ortalama 12K token per istek varsa toplam yaklaşık 12 milyar token eder.
GPT-4o fiyatlandırmasıyla (input yaklaşık $2.5/M,
output yaklaşık $10/M,
karışık kullanım varsayımıyla kaba hesap ~$5/M)
aylık fatura aşağı yukarı $60,000 seviyesine gelir.
TL karşılığı kabaca 2.1 milyon lira civarı ölür.
CodeAct’e geçtiğinizde aynı yükün 4.6K token’a düştüğünü varsayın;
toplam yaklaşık 4.6 milyar token eder.
Aylık fatura yaklaşık $23,000 ölür ki bu da kabaca 800 bin TL civarında dolaşıyor demek.
Yanı aylık
=1.`3 milyon TL civarı tasarruf`;
tabii buradaki sayı ideal senaryo üzerinden gidiyor ama yön doğru görünüyor.
Hyperlight infra maliyeti?
Çok düşük demeyeyim de düşük diyelim;
mikro-VM’ler hafif olduğu için Azure Container Apps ya da AKS üstünde self-host ederseniz aylık birkaç bin TL bandına inebiliyor işte.
Bu hesap tabi ideal senaryo üzerine kurulu.
Gerçek dünyada retry’lar,
hatalı kodlar,
debug süreleri bu farkı biraz törpüler;
ama ana ölçek değişmiyor bence.
Burada kazanç küçük değil yanı.Peki ne zaman CodeAct kullanmamak lazım?Dürüst olayım:
Her senaryo için doğru değil bu iş.
Benim gözlemim şu yönde:
- Hava durumu ne?”
gıbı sorularda CodeAct fazla kaçabilir;
klasik tool call daha hızlıdır. - Conversation memory kritikse kod bloğu içinde state yönetmek kafa karıştırabiliyor.
- Sağlık ve finans gıbı her code execution’ın loglanıp audit edilmesi gereken yerlerde ekstra katman şart oluyor.
- Çok basit tool setleri:
2-3 tool’ünüz varsa CodeAct’in getirdiği karmaşıklığa değmeyebilir.
İlk karşıştığım sorunlardan biri timeout öldü;Bende ilk denemede şu hata çıktı:
Hello from HyperlightExecutionTimeout? no...? code block exceeded limit slimit? `
Actually need valid HTML only!
Actually need valid HTML only!
Sıkça Sorulan Sorular
CodeAct üretim ortamında kullanılabilir mi?
agent-framework-hyperlight paketi şu an alpha aşamasında. Yanı aslında küçük ölçekli internal tool’lar için gayet deneyebilirsiniz, ama mission-critical sistemlere koymayın derim. Birkaç ay içinde beta, sonra GA olması bekleniyor. O zamana kadar bence en mantıklısı staging ve R&D ortamlarında olgunlaştırmak (ben de ilk duyduğumda şaşırmıştım)
Hyperlight olmadan CodeAct çalıştırabilir mıyım?
Evet, teorik olarak kendi sandbox provider’ınızı yazabilirsiniz. Mesela Docker container, Firecracker VM ya da restricted Python subprocess ile. Ama her birinin güvenlik ve performans açısından trade-off’ları var. Açıkçası Hyperlight şu an için en dengeli seçenek gıbı duruyor — mikro-VM seviyesinde izolasyon sunuyor, üstelik açılışı da hızlı.
Model yanlış kod üretirse ne oluyor?
Sandbox’ta hata fırlatıyor. Exception yakalanıp modele geri dönüyor, model de kodu düzeltmek için ikinci bir deneme yapıyor. Pratikte başarı oranı %93-95 arası — eski tool chain’den biraz düşük,. Tecrübeme göre token tasarrufu bunu fazlasıyla kompanse ediyor. Yine de kritik akışlarda max retry sayısını sınırlamayı unutmayın.
Ve işler burada ilginçleşiyor.
Mevcut tool’larımı değiştirmem gerekir mi?
İşte, i̇lginç olan şu ki, Hayır. CodeAct, hani zaten @tool decorator’ı ile yazdığınız fonksiyonları olduğu gıbı kullanıyor. Tek yapmanız gereken agent kurulumunda context_providers listesine HyperlightCodeActProvider eklemek. Geriye dönük uyumluluk tam, yanı mevcut kodunuza dokunmuyorsunuz.
CodeAct, MCP ile nasıl ilişkili?
İkisi aslında farklı katmanlarda çalışıyor. MCP (Model Context Protocol) tool’ları standart bir şekilde expose etmekle ilgili. CodeAct işe bu tool’ları tek bir kod bloğu içinde birleştirme pattern’i. Bence güzel olan şu: birbirlerini tamamlıyorlar —. MCP ile sunduğunuz tool’ları doğrudan CodeAct içinde çağırabiliyorsunuz.
Kaynaklar ve İleri Okuma
Microsoft DevBlogs: CodeAct in Agent Framework — Orijinal duyuru yazısı ve detaylı benchmark sonuçları.
Hyperlight GitHub Repository — Mikro-VM izolasyon teknolojisinin kaynak kodu, CNCF sandbox projesi.
Agent Framework Resmî Dokümantasyonu — Agent mimarisi, tool tanımlama ve context provider’lar hakkında kapsamlı rehber.
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.
