CodeAct ile AI Agent’ları Hızlandırmak: %50 Daha Az Gecikme

Geçen ay bir finans müşterimizde tuhaf bir tabloyla karşılaştık. Agent’lar çalışıyor, model fena değil, araçlar da düzgün tanımlanmış; ama işin garibi, her şey sürünüyor, bir soruya cevap gelene kadar agent 6-7 tür atıyor, her turda modeli yeniden çağırıyor, token’lar gidiyor, kullanıcı da ekranda bekleyip dürüyor.

Sorun modelde değildi. Sorun orkestrasyon tarafındaydı. İşte tam burada CodeAct devreye giriyor; kısaca şunu yapıyor: agent’ın normalde tek tek yürüteceği araç çağrılarını bir Python kod bloğu olarak yazdırıyor, model bir kere düşünüyor, bir kere kodu çıkarıyor, kod sandbox’ta çalışıyor — bence çok yerinde bir karar —. Sonuç geri geliyor.

Kulağa fazla düz geliyor, biliyorum. Ama etkisi bayağı hissediliyor — gecikme yaklaşık %50 düşüyor, token kullanımı da %60’ın üstüne iniyor; ben ilk duyduğumda “abartı olmasın” dedim açıkçası, sonra denedim ve fikrim değişti.

Klasik Agent D?ng?s?n?n Ger?ek Sorunu

Bir durup bakal?m. Diyelim ki agent’a “Seattle ve Amsterdam’ın hava durumunu kâr?la?t?r” diyorsunuz. Klasik ak?ta ne oluyor, peki?

1. Model d?n?yor: “?nce Seattle’?n hava durumunu alay?m” ? get_weather("Seattle") ?a?r?s?
2. Sonu? geliyor, model bir daha bak?yor: “Tamam, ?imdi Amsterdam’? alay?m” ? get_weather("Amsterdam") ?a?r?s?
3. ?ki veri de gelince bu kez kâr?la?t?rma türü ba?l?yor, yanı i? biraz uzuyor.
4. Model sonucu yaz?yor

D?rt tür. D?rt ayr? model ?a?r?s?. Her seferinde prompt’un tamam? yeniden gidiyor, token’lar sessizce ?i?iyor (sonra fatura taraf?nda sürat as?yorsunuz), bir de her tür aras?na a?k a?k a?a? gecikme biniyor.

Açıkçası, Hani k?k bir senaryoda “eh, 2-3 saniye ne olacak” diyebilirsiniz. Ama ger?ekte olay ba?ka; ge?enlerde bir m?teride agent tek bir kullan?c? sorusu i?in 12 farkl? ara? ?a?r?s? yap?p duruyordu, her tür yakla?k 1.5 saniye s?r?nce toplamda 18 saniye sadece orkestrasyona gitti, kullan?c? da do?a olarak beklemekten s?k?p “bu yapay zekâ yava?” diye pencereyi kapatt?.

Evet.

Agent’lar?n darboaz? art?k model kalitesi deil — orkestrasyon maliyeti. Her ara? ?a?r?s? iin yeni bir model türü, yeni token’lar, yeni gecikme demek.

CodeAct Ne Yapıyor, Nasıl Çalışıyor?

CodeAct’in olayı su: modele “hangi aracı cagiracaksin?” diye tek tek sordurmuyorsun, onun yerine “planının tamamını Python kodu olarak yaz” diyorsun. Model bir kerede programı yazıyor, bu kod sandbox içinde çalışıyor, araçları call_tool(...) fonksiyonu üzerinden çağırıyor. Sonucu geri veriyor. Kısa olan bu.

İlginç olan şu ki, Yanı agent yine aynı araçları kullanıyor. Model de aynı model, sihir falan yok. Sadece kablolama değişiyor, hani o kadar. Bu ayrım baya önemli çünkü mevcut araçlarınızı değiştirmeniz gerekmiyor; ben açık konuşayım, en sevilen kısım da bu oluyor genelde.

Bunu biraz açayım.

Minimal Bir Örnek

Aşağıdaki kod bloğu, CodeAct’i Agent Framework ile nasıl kullanacaginizi gösteriyor. Baya is görüyor, itiraf edeyim. Ama dur bir saniye — ilk bakışta çok sade görünüyor diye aldanmayin, arka tarafta akıllıca bir akış var.

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."
)

Burada dikkat edin; HyperlightCodeActProvider bir context provider olarak agent’a ekleniyor. Araçlarınızı olduğu gibi veriyorsunuz, ekstra bir çeviri katmanı kurmuyorsunuz. approval_mode parametresiyle kod çalıştırma öncesi onay isteyip istemeyeceginizi belirliyorsunuz. Production’da bunu “always_require” yapmanızı ben de mantıklı buluyorum, ama denemeler için “never_require” idare eder (en azından benim deneyimim böyle)

Evet.

Hyperlight Micro-VM Meselesi

Ha, bir de şunu söyleyeyim — CodeAct’in en can alıcı yeri güvenlik tarafı. Model’in yazdığı Python kodu doğrudan sisteminizde çalışmıyor; burada is değişiyor biraz. Her çağrı için taze bir Hyperlight micro-VM ayağa kalkıyor, kod orada çalışıyor, sonuç dönüyor, sonra VM yok ediliyor. Temiz akış.

Bu önemli çünkü… düşünsenize, LLM’in yazdığı rastgele bir Python kodunu kendi sunucunuzda çalıştırıyorsunuz. Dosya sisteminize erişebilir, ag çağrısı yapabilir, her türlü şeyi karıştırabilir. Hyperlight bunu ciddi şekilde daraltıyor. Aslında — dur bir saniye — micro-VM olması konteynerden bile daha izole; konteyner kernel’i paylasir, micro-VM paylasmaz. Aradaki fark da burada çıkıyor zaten (kendi tecrübem)

Kubernetes’te AI Agent Sandbox: Pratik Rehber yazımda sandbox konusunu daha detaylı ele almıştım (inanın bana). Hyperlight yaklaşımı o yazıdaki prensiplerin bir adım oteasi diyebilirim; hatta bazen insan “tamam ya, burası artık iyice ciddi olmuş” diyor (kendi tecrübem)

Rakamlarla Karşılaştırma: CodeAct vs Klasik Yaklaşım

Tamam, lafı çok uzattım. Somut rakamlara bakalım. Aynı görevi — 5 şehrin hava durumunu alıp karşılaştırma — iki yöntemle çalıştırınca tablo baya netleşiyor, hatta ilk bakışta insanın kafasında “hmm, burada iş değişmiş” hissi oluşuyor.

Token tasarrufunun bu kadar yüksek çıkmasının sebebi şu: klasik yaklaşımda her turda tüm konuşma geçmişi yeniden gidiyor. İlk turda 200 token, ikinci turda 400, üçüncüde 600… sonra bir bakıyorsunuz — en azından ben öyle düşünüyorum — sayı şişmiş; kümülatif etki biraz sinsice büyüyor. CodeAct tarafında işe model kodu tek seferde yazıyor, sonuç da tek seferde geliyor; işin aslı farkın büyük kısmı burada yatıyor.

Maliyet tarafından bakarsak — GPT-4o fiyatlandırmasıyla bu fark çağrı başına küçük görünebilir. Günde 10,000 agent çağrısı yapan bir sistemde aylık yüzlerce dolarlık tasarruf demek (evet, doğru duydunuz). Türkiye’deki kurumsal müşterilerimde (söylemesi ayıp) döviz hassasiyeti çok yüksek olduğu için bu tür iyileştirmelar doğrudan bütçe toplantılarında gündeme geliyor; bazen teknik değil finans konuşuyoruz, garip ama gerçek. Peki neden? Çünkü ölçek büyüyünce küçük farklar can sıkmaya başlıyor.

Bunu biraz açayım.

Evet.

Bakın, Açık konuşayım, burada mesele sadece hız da değil. Bir akışta modelin kaç kere ileri geri yaptığına baktığınızda, bazen en temiz çözümün daha kısa olan değil, daha az zıplayan çözüm olduğunu görüyorsunuz; yanı kod tarafında da aynı hikâye var.

Neyse uzatmayayım, özet şu: basit işte klasik yöntem idare eder, ama iş zincirlenmeye başlayınca CodeAct baya iş görüyor. Daha açık söyleyeyim, sız ne dersiniz?

Türkiye’de Bu İşe Yarar mı? Kurumsal Perspektif

Şimdi burada biraz durup Türkiye tarafına bakmak lazım. Çünkü dışarıdan bakınca insanın aklına hemen şu geliyor: “Güzel teknoloji, hadi kullanalım.” Evet, kağıt üstünde öyle dürüyor. Ama sahada iş biraz farklı ilerliyor.

Size bir şey söyleyeyim, Türkiye’deki kurumsal şirketlerin çoğu daha agent mimarisine tam geçmemiş durumda. Hâlâ basit chat completion API’leriyle yol alıyorlar. CodeAct işe bir anlamda ikinci aşama gibi; yanı önce temel yapıyı oturtmanız gerekiyor, sonra bunun üstüne çıkıyorsunuz. Logosoft’ta danışmanlık yaptığım projelerde sık gördüğüm şey şu: ekipler önce agent framework’ü kuruyor, ardından araçları bağlıyor, sonra performans düşmeye başlayınca bu kez CodeAct benzeri çözümlere dönüyorlar; sırayı ters çevirince de karmaşa büyüyor, iş uzuyor, hatta bazen kimse neyin nerede patladığını anlayamıyor. Bu konuyla ilgili Azure MCP Server .mcpb Paketi: Kurulum Artık Çocuk Oyuncağı yazımıza da göz atmanızı tavsiye ederim.

Bir de işin platform tarafı var. Hyperlight micro-VM şu an sadece Linux üzerinde çalışıyor. Windows tabanlı altyapısı olan şirketler için bu küçük bir detay değil; özellikle Türkiye’de bankacılıkta. Bazı büyük kurumsal yapılarda Windows hâlâ baya yaygın (inanın bana). Azure üzerinde Linux VM’lerde kullanabilirsiniz tabi, ama on-prem Windows sunucularda doğrudan devreye alamazsınız. Peki neden önemli? Çünkü teknik olarak iyi görünen bir çözüm, ortamınıza uymuyorsa rafta kalıyor.

Durun, bir saniye. Kubelet API Yetkilendirmesi GA Oldu: Güvenlik Devrimi yazımızda bu konuya da değinmiştik.

Bilmem anlatabiliyor muyum, Küçük bir ekipseniz. Az sayıda araç çağrısı yapıyorsanız, açık konuşayım, CodeAct’a koşmanız gerekmiyor. Ama enterprise tarafta işler değişiyor; özellikle yüksek hacimli agent operasyonları varsa (müşteri hizmetleri botu gibi, veri analiz agent’ı gibi), o zaman bunu ciddi ciddi masaya koymak lazım. Hani bazen “şimdilik idare eder” diyorsunuz ya, işte o nokta tam burada kırılıyor. AI Maliyet Optimizasyonu: ROI’yi Gerçekten Artırmanın Yolu yazımda maliyet optimizasyonu tarafını detaylıca anlatmıştım; CodeAct da aslında o yaklaşımın doğal bir devamı gibi dürüyor (ben de ilk duyduğumda şaşırmıştım) Gemini ile Hayatını Düzenle: 8 Yapay Zeka Destekli İpucu yazımızda bu konuya da değinmiştik.

Güvenlik ve Onay Mekanizması

Açık konuşayım, bir LLM’in yazdığı kodu otomatik çalıştırmak bana hâlâ biraz tedirginlik veriyor. Evet, Hyperlight izolasyon sağlıyor. Evet, micro-VM’ler her çağrıda sıfırdan açılıyor. Ama yine de insanın aklı bir köşede kalıyor, çünkü işin içinde kod var ve kod bazen en sakın anda bile saçmalayabiliyor.

İşte tam da bu noktada devreye giriyor. Bu konuyla ilgili GitHub Pull Requests Dashboard: Herkes İçin Açılan Yeni Deneyim yazımıza da göz atmanızı tavsiye ederim.

CodeAct üç ayrı onay modu sunuyor:

• never_require: Kod doğrudan çalışır. Bunu sadece geliştirme ortamında kullanın, cidden.
• always_require: Her kod çalıştırma öncesi insan onayı gerekir. Production tarafında en temkinli seçenek bu.
• auto: Belirli kriterlere göre kendi kararını verir. Hmm, bir saniye… Aslında bu modu production’da henüz ben de zorlamadım, o yüzden burada kesin konuşmam doğru olmaz.

2024’ün sonlarında bir e-ticaret projesinde (agent henüz CodeAct kullanmıyordu ama benzer bir kod çalıştırma mekanizması vardı) model’in ürettiği kodun beklenmedik şekilde sonsuz döngüye girdiğini gördük (en azından benim deneyimim böyle). Sandbox timeout’u 30 saniyeye ayarlı olmasaydı işler kötüleşebilirdi, hatta baya can sıkıcı bir yere gidebilirdi; bu yüzden CodeAct’ta da timeout. Kaynak limitlerini mutlaka koyun. Bu konuda biraz paranoyak davranmak fena değil.

Ne Zaman CodeAct Kullanmamalısınız?

Her şeyi CodeAct’a taşımak ilk bakışta cazip geliyor, ama açıkçası her senaryoda mantıklı değil. Şu durumlarda klasik araç çağrısı daha iyi dürüyor: basit sorgular için tek bir araç çağrısı yeterliyse, ya da araç çağrısı sonucuna göre dallanan yollar çok karmaşıksa (if/else zinciri uzadıkça model’in doğru kod yazma ihtimali düşüyor), orada CodeAct biraz fazla yük bindirebiliyor.

Bazı ortamlarda güvenlik çizgisi zaten çok net oluyor; yanı hiçbir kod çalıştırmanın kabul edilmediği yerlerde bu yaklaşımı zorlamaya gerek yok. Peki, bir de — en azından ben öyle düşünüyorum — işin küçük model tarafı var — 7B-13B aralığındaki modeller bu konuda pek parlak değil, nasıl desem, idare eder bile diyemeyebilirim. Kısacası, sız ne dersiniz? Bana kalırsa burada mesele “daha akıllı model”den çok “doğru yerde doğru araç” seçimi.

Hmm, bunu nasıl anlatsamdı…

Evet.

Pratik Başlangıç Rehberi

Tamam, denemek istiyorsanız, işin aslı çok karışık değil: adım adım ilerleyin, ama ilk günden prod’a atlamayın.

1. Paketi kurun: pip install agent-framework-hyperlight — evet, komut bu kadar basit. Burada, ama dur bir saniye; bu paket henüz alpha,. Production’a koymadan önce iki kere bakın, mümkünse küçük bir test ortamında çevirip dolaştırın. Kubernetes v1.36 User Namespaces GA: Root Artık Gerçek Root Değil yazımızda bu konuya da değinmiştik.

2. Mevcut araçlarınızı listeleyin: Hangi araçlar zincirleme çağrılıyor, hangileri tek başına çalışıyor, bunu netleştirin. Zincirleme olanları CodeAct tarafına taşıyın; bağımsız duranlar şimdilik yerinde kalabilir, yanı her şeyi aynı sepete atmayın.

3. Küçük başlayın: Önce basit bir senaryo deneyin. İki-üç araç çağrısı olan bir görev seçin, sonra sonucu klasik yaklaşımla kıyaslayın; bazen fark beklediğiniz kadar büyük olmuyor, bazen de şaşırtıyor açıkçası.

Ne yalan söyleyeyim, 4. Timeout. Limitleri ayarlayın: Sandbox’ın ne kadar süre çalışacağını ve ne kadar bellek kullanabileceğini mutlaka sınırlandırın. Yoksa model bir yere saplanıp kalabiliyor, şey gibi düşünün; küçük bir deneme diye girip gereksiz kaynak tüketimine dönmesi hiç hoş olmaz.

5. İzleme kurun: Model’in yazdığı kodları loglayın (bizzat test ettim). Başta ne ürettiğini görmek baya işe yarıyor; hem öğreniyorsunuz hem de güvenlik tarafında eliniz boş kalmıyor, çünkü insan ilk bakışta “idare eder” dediği şeyin içinde sürpriz çıkabiliyor.

Ha bu arada, AI Agent’larda Sohbet Geçmişi: Nerede Saklamalı? yazımı da okumanızı öneririm. CodeAct kullandığınızda sohbet geçmişi yapısı değişiyor çünkü artık 6 tür yerine 2 tür var — bu da geçmiş yönetimini etkiliyor, hatta beklediğinizden biraz daha fazla etkiliyor diyeyim; sız ne dersiniz?

İşin garibi, Evet.

Benim Değerlendirmem: İyi Yönde Bir Adım Ama…

CodeAct, bence doğru tarafa atılmış bir adım. Agent Framework’ün bunu birinci sınıf vatandaş gibi ele alması da fena durmuyor. Rakamlar? Açıkçası ikna edici.

Ama — evet, burada ciddi bir ama var — iş henüz alpha aşamasında. Hyperlight micro-VM’lerin production tarafında ne kadar stabil kaldığı konusunda elimizde yeterli veri yok, modelin her seferinde doğru Python kodunu yazacağını da kimse garanti edemez (keşke etseydi), üstüne bir de debugging kısmı bayağı uğraştırıyor.

Klasik yaklaşımda her adımı tek tek görüyorsunuz. Burada işe model bir kod bloğu bırakıyor ve ya çalışıyor ya çalışmıyor; aradaki niyeti, küçük sapmaları, “neden böyle yaptı?” sorusunun cevabını görmek için ekstra efor harcıyorsunuz. Şey, bu detay küçük gibi dürüyor ama pratikte can sıkabiliyor.

Kısa bir not düşeyim buraya.

Beklediğim kadar olgun değil, açık konuşayım. Ama 6 ay sonra? Hah, orası başka hikâye olabilir. Şu an için “izle, dene, öğren ama production’a koyma” demek en makul çizgi gibi geliyor bana.

Tabi eğer zaten yüksek hacimli agent operasyonlarınız varsa. Maliyet sizi zorluyorsa, kontrollü bir pilot başlatmak da mantıksız değil (yanlış duymadınız). Sız ne dersiniz?

Sıkça Sorulan Sorular

CodeAct ile klasik araç çağrısı arasındaki fark ne?

Açık konuşayım, Klasik yaklaşımda model her araç için ayrı bir tür dönüyor — çağır, sonucu al, tekrar düşün, tekrar çağır. Yanı hani sürekli gidip gelme var. CodeAct’ta işe model tüm planı tek bir Python kod bloğu olarak yazıyor ve bu kod sandbox’ta tek seferde çalışıyor. Aslında bu sayede model turları, token kullanımı ve gecikme ciddi şekilde azalıyor (bizzat test ettim)

CodeAct güvenli mi? Modelin yazdığı kodu çalıştırmak riskli değil mi?

Hyperlight micro-VM sayesinde kod neredeyse tamamen izole bir ortamda çalışıyor. Her çağrıda taze bir VM oluşturuluyor, işi bitince yok ediliyor. Bence bu kısım oldukça iyi düşünülmüş. Yine de production’da mutlaka “always_require” onay modunu kullanın, timeout. Kaynak limitleri de koyun — açıkçası bunları atlamayın.

Hangi modeller CodeAct ile iyi çalışıyor?

GPT-4o, GPT-4 ve Claude 3.5 Sonnet gibi büyük modeller CodeAct ile gayet iyi kod üretebiliyor. Küçük modeller — mesela 7B-13B parametreli olanlar — genellikle doğru çalışan kod üretmekte zorlanıyor (yanlış duymadınız). Tecrübeme göre model seçiminde kod yazma yeteneği gerçekten kritik bir kriter oluyor.

CodeAct her agent senaryosunda kullanılmalı mı?

Hayır. Tek bir araç çağrısı yeterli olan basit görevlerde CodeAct gereksiz karmaşıklık ekliyor. Aslında CodeAct en çok üç veya daha fazla zincirleme araç çağrısı gerektiren, yanı veri toplama-hesaplama-birleştirme tarzı görevlerde işe yarıyor.

agent-framework-hyperlight paketi production’a hazır mı?

Şu an alpha aşamasında. Microsoft aktif olarak geliştiriyor ama açıkçası production stabilitesi konusunda henüz yeterli topluluk verisi yok. Bence geliştirme. Test ortamlarında rahatça deneyin, ama production’a almadan önce en az birkaç ay daha beklemenizi öneririm.

Kaynaklar ve İleri Okuma

CodeAct in Agent Framework: Faster Agents with Fewer Model Turns — Microsoft DevBlogs (ki bu çoğu kişinin gözünden kaçıyor)

Bunu yaşayan biri olarak söyleyeyim, Hyperlight — GitHub Resmî Deposu

Azure AI Services Resmî Dokümantasyonu

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

Azure OpenAI ve GPT-4o: FedRAMP High ile ABD Devletinde Yepyeni Bir Yapay Zekâ Çağı24 Mar 2026

azd update Komutu: Paket Yöneticisi Derdine Son15 Nis 2026

TFVC’de Eski Politikaları Temizleyin: Azure DevOps Uyarısı9 Mar 2026

Claude Sonnet 4.6: Güçlü ve Uygun Fiyatlı Yapay Zeka9 Mar 2026