Bakın şimdi, “yerel yapay zekâ ajanı” lafı son iki yılda öyle şişti ki insan önce durup soruyor: Bu gerçekten iş yapan bir şey mi, yoksa tarayıcıya eklenmiş şık bir sohbet kutusu mu? EchoKernel tam da bu gürültünün ortasında, ilginç bir yerde duruyor (eh, fena değil). Ne devasa ekran kartı istiyor ne de sadece “cevap verip bırakıyor.” Komut alıyor, sesi yazıya çeviriyor, niyeti çözüyor ve sonra yerel makinede bir şeyler yapıyor — dosya oluşturuyor, kod yazıyor, metin özetliyor (şaşırtıcı ama gerçek). yani laf kalmıyor, iş çıkıyor.
Geçen ay Kadıköy’de kahve içerken küçük bir deneme yapmıştım; laptop’ta çalışan basit bir agent’a sesle komut verdim. Açık konuşayım, yarısı heyecan yarısı hayal kırıklığıydı. Çünkü çoğu sistem “beni dinle” kısmında fena değil ama “şimdi bunu gerçekten uygula” noktasında tökezliyor. EchoKernel’in ilgimi çekmesinin sebebi de tam olarak bu: zinciri açık açık gösteriyor. Her adımı değiştirebileceğiniz kadar sade kuruyor.
Ve işler burada ilginçleşiyor.
EchoKernel Ne Yapıyor, Ne Yapmıyor?
Sistemin en sevdiğim tarafı beklentiyi net koyması oldu. Kullanıcı ister sesle ister yazarak komut veriyor; ardından Whisper tabanlı STT katmanı bunu metne dönüştürüyor. Sonra LLaMA 3.3 70B gibi büyük bir model devreye girip niyeti sınıflandırıyor. Bu aşama önemli — çünkü her komutu “aynı türden” görmeyen, düzgün ajanlar ancak böyle kuruluyor, başka türlü değil.
İşin devamında araç yönlendirme var. Model “bu kod yazma işi”, “bu özetleme”, “bu sohbet” diye karar veriyor ve uygun yerel fonksiyona paslıyor (en azından benim deneyimim böyle). Sihir yok aslında burada. İyi ayrıştırılmış görevler var, o kadar. Basit görünüyor ama pratikte bayağı kritik — tek parça bir süper ajan yerine küçük ama net roller daha az saçmalıyor, bunu kendi projelerimde defalarca gördüm.
Bir de güvenlik tarafı var ki ben buna özellikle baktım. Her şey output/ klasörüne hapsediliyor. Kulağa sıradan gelebilir bu,. Kurumsal tarafta işin rengi değişiyor; dosya sistemine kafasına göre dağılan araçlar çok hızlı bela çıkarır. Geçen sene Şişli’deki bir startup’ın iç aracında benzer problem görmüştüm — otomasyon yanlış klasöre log atınca tüm ekip yarım gününü kaybetmişti. Gereksiz yere.
Neden bu mimari biraz daha mantıklı?
Monolitik değil diyelim; ya da durun, daha doğru söyleyeyim: her şeyi tek dev modele yığmıyor (en azından benim deneyimim böyle). STT ayrı, intent ayrılmış, tool execution ayrı tutulmuş. Ve sonuç: mesela Whisper yerine faster-whisper takmak isterseniz sadece tek fonksiyonu elinizden geçiriyorsunuz. Güzel değil mi?
Hmm, bunu nasıl anlatsamdı…
| Bileşen | Görev | Neden önemli? |
|---|---|---|
| STT Servisi | Sesi yazıya çevirir | Kullanıcının söylediğini düzgün yakalar |
| Niyet Katmanı | Komutu JSON’a döker | Ajanın ne yapacağını netleştirir |
| Araç Çalıştırıcı | Yerel işlemleri yapar | Kod üretme, dosya yazma gibi işleri halleder |
| Bellek Katmanı | Oturum geçmişini tutar | Kullanıcıyla bağlam kopmaz |
Sistem Akışı Neden Önemli?
Aslında, Akış meselesi sıkıcı gelebilir, biliyorum. Ama asıl oyun orada dönüyor. Browser’dan gelen ses blob’u FastAPI’ye gidiyor; oradan transcription alınıyor; sonra intent çözülüyor; en sonda local tool çalışıyor. Bu sıranın büyük avantajı şu: hata nerede çıktıysa bulmak kolaylaşıyor. Ciddi fark bu. Alibaba Qwen’i Nasıl Büyüttü, Parayı Nereden Arıyor? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Claude Code sahneyi kaptı: HumanX’ten çıkan asıl dersler yazımıza da göz atmanızı tavsiye ederim. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
2024 sonunda kendi test ortamımda benzer bir pipeline kurarken en çok zorlandığım konu görünmez aralardı — hani kullanıcı “neden olmadı?” diyor ya, siz de log’un hangi adımda koptuğunu anlamaya çalışıyorsunuz saatlerce. EchoKernel’in sıralı tasarımı o yüzden güzel; debug etmek, nasıl desem, daha az sinir bozucu oluyor (evet, doğru duydunuz). Küçük ama önemli bir fark. Bu konuyla ilgili Claude Desktop’a Mila Bağlama: 30 Saniyede MCP Kurulumu yazımıza da göz atmanızı tavsiye ederim.
En güçlü taraf burada gizli: Modeli büyütmekten önce sistemi bölmek gerekiyor.
Bir ajanın gerçekten işe yaraması için önce ne yaptığını bilmesi lazım.
Aksi halde elinizde konuşkan ama kararsız bir robot kalır.
Yani, Gel gelelim eksik taraf da var tabii. Tamamen sıralı yapı bazen hız kaybettirir; özellikle — itiraz edebilirsiniz tabi — çok adımlı işler üst üste binince bekleme hissi oluşuyor. Küçük projelerde sorun değil ama enterprise seviyede, aynı anda onlarca isteği taşırken cache, queue ve rate limit gibi ek katmanlara ihtiyaç doğar — kaçış yok bundan. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Küçük Bir Laptop’ta Büyük Söz Vermek Kolay Değil
No-GPU iddiasının gerçek hayattaki karşılığı
No-GPU çalışmak kulağa pazarlama cümlesi gibi geliyor olabilir. Ama kıymetli olan şu: herkesin RTX canavarı yok! Kendi MacBook Air M2 cihazımda benzer testler yaptığımda ağır modeller hemen nefes nefese kalmıştı; o yüzden görevleri ayırmak mantıklı geliyor bana.
İnanın, Eğer hedefiniz hızlı prototip ise lokal çalışan hafif parçalar sizi kurtarır. Ama karmaşık muhakeme bekliyorsanız — işte orada sınırlar başlıyor. Lafı gevelemeden söyleyeyim: küçük makinelerde başarı çoğu zaman model gücünden değil, iş akışını doğru bölmekten geçiyor (ciddiyim). Bu kadar basit aslında.
Küçük startup ile kurumsal ekip aynı şeyi mi ister?
Hani, Hayır istemezler. Bayağı farklı isterler diyeyim. Küçük startup için önemli olan hızlı deneme yapmak: dosya oluşturulsun, kod taslağı çıksın, bir özeti anında alsın. Kurumsalda ise izlenebilirlik, yetkilendirme, loglama ve veri sınırları öne çıkar. Yani aynı agent farklı dünyalarda farklı ayakkabı giyer.
- Küçük ekip: Hızlı kurulum, düşük maliyet, minimum bakım yükü.
- Büyüyen ürün: Modüler yapı, hata izolasyonu, genişletilebilir tool set’i.
- Kurumsal ortam: Audit log’ları, sandbox güvenliği, rol bazlı erişim.
Tatlı olan taraf şu ki EchoKernel tam ortada durmaya çalışıyor. Ne oyuncak kadar yüzeysel, ne de laboratuvar dışında kullanılması zor kadar ağır. Bu denge bana makul geldi açıkçası. Ama yine de beklediğim kadar cilalı değildi; özellikle çoklu oturum senaryolarında biraz daha pişmesi lazım.
Peki Niyet JSON’u Neden Bu Kadar Kritik?
Düz metin yerine yapılandırılmış çıktı almak neden iyi?
Düz metin cevaplar sohbet için tamamdır ama ajan dünyasında yetmez. Çünkü bilgisayarın anlaması gereken şey şiir değil; alanları belli nesnelerdir: primary_intent, target_filename, summary_length gibi… Bu yüzden JSON çıktısı oyunu değiştiriyor (buna dikkat edin). Model ne demek istediğini yalnızca anlatmıyor, makinenin okuyacağı biçimde paketliyor. Fark büyük.
{
"primary_intent": "write_code",
"target_filename": "retry.py",
"language": "python",
"needs_confirmation": false
}Editör masasında bu örneği görünce içimden “tamam işte” dedim. Çünkü bundan sonrası artık tahmin değil; kural motoru gibi çalışabiliyor. Birinci sınıf büyü falan yok burada — sadece düzgün şema tasarımı var (en azından benim deneyimim böyle). Hepsi bu.
Nerede duvara toslayabilir?
Tuhaf ama, Bence en hassas nokta intent çözümleme hatalarıdır. Mesela kullanıcı aslında kod istiyordur ama model onu özetleme sanabilir. Ya da filename üretirken saçma sapan isim döndürebilir — evet, oluyor bu. Bu yüzden doğrulama katmanı şart; Pydantic benzeri şemalar burada hayat kurtarıyor.
Neyi Beğendim, Neyi Eksik Buldum?
Beni en çok etkileyen şey açıklık oldu. Pipeline kapalı kutu değil; her aşama görülebiliyor ve değiştirilebiliyor. Bugün Groq API kullanırsınız, yarın lokal STT’ye geçersiniz, öbür gün başka bir intent modeli takarsınız — sistem dağılıp gitmiyor. Baya iş görüyor bu yaklaşım.
Kusursuz mu? Değil. Bilhassa üç noktada biraz tereddüt yaşadım: ilk olarak network bağımlılığı hala var, ikinci olarak büyük model çağrıları ucuz sayılmaz, üçüncü olarak da UI sade olsa bile bazı kullanıcılar için fazla teknik kalabiliyor. Dur bir saniye — bu üçüncü madde aslında önemli, çünkü her iyi mühendislik çözümü iyi ürün deneyimi vermiyor. Maalesef.
Bana göre artılar ve eksiler şöyle toparlanır:
| Artılar | Eksi taraflar |
|---|---|
| Açık mimari ve kolay modifikasyon | Büyük modellere bağlı olunca maliyet artabiliyor |
| Laptop’ta GPU’suz çalışma hedefi, öğrenmesi kolaylaştırıyor | Sıklıkla internet bağlantısına ihtiyaç duyuyor |
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.
