# aiagentdevelopment.info — tam metin

> Bu dildeki her rehberin tam metni; bir cevap motoru katalogu tek istekte okuyabilsin diye. Burada görünür sayfalarda olmayan hiçbir şey yok.

## Canlıya Ulaşan Bir Ajan Geliştirme Yol Haritası
https://aiagentdevelopment.info/tr/guides/ajan-gelistirme-yol-haritasi
2026-08-05 tarihinde güncellendi · Maliyet ve iş tarafı

- Yazılı çıkış sınavları olan dört faz: kapsamla, prototiple, sağlamlaştır, yayınla.
- Sağlamlaştırma en uzun ve en sık az bütçelenen fazdır.
- Sınırlı kitleye yayınlayın ve takvime değil sayılara göre genişletin.
- Yayından sonra bu bir servistir: sahip, büyüyen değerlendirme seti, model değişiminde yeniden onay.

Ajan projelerinin başarısızlık deseni teknik değil. Üçüncü haftada iyi bir prototip, ardından üç ay yönsüz iyileştirme, ardından hazır olup olmadığını kimse söyleyemediği için sessiz bir iptal.

Bu yol haritası bunu çıkış sınavlarıyla düzeltiyor. Her fazın, faz başlamadan önce yazılmış, ya karşılanan ya karşılanmayan bir koşulu var. Bir faz sınavını geçemiyorsa ya somut boşluğu düzeltirsiniz ya durursunuz — ve ikisi de sürüklenmekten iyi sonuçlardır.

### Faz 1 — Kapsamla (1–2 hafta)
Görevi, bir gözden geçirenin doğru ya da yanlış işaretleyebileceği bir cümle olarak yazın. Araçları argüman şemalarıyla listeleyin. Hangi eylemlerin geri alınamaz olduğuna ve insan kapısının arkasında duracağına karar verin. Kayıtlardan ya da bugün bu işi yapan kişiden, zor olanlar da dahil yirmi gerçek örnek toplayın.
Çıkış sınavı: toplantılarda olmayan bir meslektaş brief'i okuyup beş örnek koşuyu doğru notlayabiliyor.

### Faz 2 — Prototiple (2–3 hafta)
Görevi test ortamındaki gerçek araçlarla yapan en küçük döngüyü kurun. Kaçınabiliyorsanız henüz framework kararı vermeyin; elle yazılmış bir döngü, gerçekte neye ihtiyacınız olduğunu öğretir. Yirmi vakanızı koşturun, her hatayı inceleyin ve seçim sizdeyse prompt'u değil araç tasarımını düzeltin.
Çıkış sınavı: yirmi vakanın %60'ı uçtan uca geçiyor ve her hatanın yanına belirlenmiş bir sebep yazılmış.

### Faz 3 — Sağlamlaştır (3–5 hafta)
Gerçek işin çoğu burada ve az bütçelenen projeler burada ölüyor. Son kullanıcı kimliğiyle yetkiler, geri alınamaz eylemlerde onay kapıları, argüman doğrulama, okuyabileceğiniz izleme, birkaç davranışsal metrikle izleme, saldırgan vakalar dahil elli vakaya büyütülmüş değerlendirme seti ve sağlayıcı bozulduğunda devreye girecek bir geri çekilme modu.
- Her araç çağrısında sunucu tarafında kontrol edilen yetkilendirme.
- Geri alınamaz her eylemin önünde, karar vermeye hazır bağlamla insan kapısı.
- Adım ve harcama sınırları, artı tekrar tespiti.
- Her çağrıda koşu kimliği olan izler ve bilerek verilmiş bir saklama kararı.
- Değerlendirme setinde, diğer testler gibi koşturulan saldırgan vakalar.
Çıkış sınavı: değerlendirme setinde %85, reddetme alt kümesinde %100 ve çözülmemiş güvenlik bulgusu yok.

### Faz 4 — Yayınla (2 hafta, sonra sürekli)
Sınırlı bir kitleyle başlayın — tek bir ekip, tek bir müşteri segmenti ya da trafiğin bir yüzdesi. Koşuları her gün okuyun. Devir yolunu görünür ve insanlı tutun; çünkü değerlendirme seti ne kadar iyi olursa olsun ilk hafta sürprizler üretir. Takvim öyle dediği için değil, sayılar iki hafta üst üste tuttuğu için genişletin.
| 1 | Yalnız iç ekip | İzler, bariz hatalar, araç hataları |
| 2 | Gerçek trafiğin %5'i | Devir oranı, başarı oranı |
| 3–4 | %25 | Görev başına maliyet, zirvede gecikme |
| 5+ | Sayılar tutuyorsa tamamı | Kayma, yeni istek türleri |

### Yayından sonra ne olur
Ajan bir projedir değil, bir servistir. Biri sahiplenir, değerlendirme seti gerçek trafikten büyümeye devam eder, sağlayıcılar emekli ettikçe model sürümleri yeniden onaylanır ve kanıt biriktikçe insan kapıları seçerek kaldırılır. İlk dört fazı planlayıp ötesini planlamayan ekipler, ekimde mükemmel olup marta gelindiğinde sessizce yanlış olan bir ajanla kalıyor.

Q: Üç günde çalışan bir demo için on iki hafta uzun geliyor.
A: Demo gerçekten çalıştı. Kalan dokuz hafta yetkiler, değerlendirme, izleme ve hata yollarıdır — gerçek müşterilere emanet edilip edilemeyeceğine karar veren şeyler. Bunları atlamak işi ortadan kaldırmaz; olaydan sonrasına taşır.

Q: Fazlar çakışabilir mi?
A: Sağlamlaştırma prototip sırasında başlayabilir ve yetkiler için genelde başlamalı. Sağlamlaştırma çıkış sınavı geçmeden yayına başlamayın: onay kapısı olmayan sınırlı bir yayın sınırlı risk değil, sınırsız riskin küçük bir örneğidir.

Q: Prototip çıkış sınavını geçemezse?
A: Yazdığınız sebeplere bakın. Araç tasarımı ve veri erişimiyse düzeltin — bu normaldir. Görev, kimsenin tanımlayamadığı bir muhakeme gerektiriyorsa durun. Beşinci haftada durmak iyi bir sonuçtur; yedinci ayda durmak pahalı bir sonuçtur.

## Sektörlere Göre AI Ajanı Kullanım Senaryoları: Gerçekten İşleyenler
https://aiagentdevelopment.info/tr/guides/sektorlere-gore-ajan-kullanim-senaryolari
2026-08-05 tarihinde güncellendi · Maliyet ve iş tarafı

- Ajanlar; görev dar, kayıt sistemi var ve riskli adımlar kapılıysa kalıcı olur.
- En güvenilir ilk kazanımlar iç mutabakat, triyaj ve taslak yazmadır.
- Projeler model sınırlarından değil eksik API, tanımsız bitti ve sahipsizlikten takılır.
- Düzenlemeye tabi sektörlerde taslak tarafından başlayın ve otonomiyi kanıtla genişletin.

Kullanım senaryosu listeleri genelde dilek listesi gibi okunur. Bu liste, canlıya çıkıp orada kalan işlerden çıkarıldı — yani çok daha kısa ve pazarlamanın ima ettiğinden çok daha tekrarlı bir liste.

Desen sektörler arasında tutarlı. Bitti tanımı net olan dar bir görev, gerçek bir kayıt sistemine karşı iki üç araç ve geri alınamayan şeyin önünde bir insan. Bu üçü sağlandığında ajanlar kalıcı oluyor. Sağlanmadığında projeler, sektör ne olursa olsun pilotta takılıyor.

### Sektöre göre işleyenler
| E-ticaret | Sipariş durumu, iade uygunluğu, adres değişikliği | Sipariş sorgusu, iade politikası, adres güncelleme | Eşiğin üzerindeki iadeler |
| SaaS destek | Hesap bağlamıyla birinci seviye triyaj | Hesap sorgusu, belge araması, talep güncelleme | Plan değişikliği, kredi |
| Finans operasyon | Faturayı satın alma siparişiyle eşleştirme | ERP okuma, belge ayrıştırma, istisna işaretleme | Her ödeme |
| Sağlık idaresi | Randevu planlama ve hatırlatma | Takvim, hasta kaydı okuma | Klinik olan her şey |
| İşe alım | Açık kriterlere göre ön eleme, planlama | ATS okuma, takvim, e-posta taslağı | Ret ve teklifler |
| Lojistik | Geciken gönderilerde istisna yönetimi | Takip, taşıyıcı API, müşteri bildirimi | Tazminat teklifleri |

### Kimsenin yazmadığı iç ajanlar
En güvenilir kazanımlar gösterişsiz ve içeridedir: birbiriyle çelişen iki sistemi mutabık kılmak, tekrarlayan bir raporun ilk sürümünü yazmak, gelen talepleri doğru bağlamla doğru kuyruğa ayırmak ve çalışan sorularını kaynak göstererek cevaplamak. İşe yarıyorlar çünkü bitti tanımı nettir, izleyici kusurlu bir ilk taslağa tahammül eder ve hatalar ucuz ve görünürdür. Ayrıca müşteriye dönük bir ajanın gerektireceği operasyonel alışkanlıkların öğrenildiği yer de burasıdır.

### Her sektörde projelerin takıldığı yerler
- API'si olan bir kayıt sistemi yok — ajanın basacağı sağlam bir zemin yok.
- Doğru sonucun ne olduğu üzerinde uzlaşılmamış, dolayısıyla kimse notlayamıyor.
- Görev muhakeme ağırlıklı ama risk iştahı sıfır; her eylem kapıya giriyor ve değer buharlaşıyor.
- Sahiplik belirsiz: inovasyon kurdu, operasyon ihtiyaç duyuyor, nöbette kimse yok.

### İlkini seçmek
Aday görevleri dört eksende sıralayın: hacim, adımların ne kadar tekrarlı olduğu, bir kayıt sisteminin var olup olmadığı ve eylemlerin ne kadar geri alınabilir olduğu. En iyi ilk proje yüksek hacimli, çok tekrarlı, API destekli ve geri alınabilir olandır. Bu, odadaki kulağa en etkileyici gelen fikir nadiren olur ve neredeyse her zaman canlıya çıkıp bir sonrakini finanse eden fikirdir.
Hatanın pahalı değil utandırıcı olduğu bir şeyi bilerek seçin. İlk ajanınız aynı zamanda kurumunuzun bu kategoriye güvenmeyi öğrenme biçimidir.

### Düzenlemeye tabi sektörler: yavaş, kapalı değil
Finans, sağlık ve kamu kesinlikle ajan koşturabilir; yalnızca çizginin taslak tarafından başlamaları gerekir. Vakayı derleyen, kaynaklarını gösteren ve insana karar vermeye hazır bir özet veren bir ajan, otomatik karar riskinin hiçbirini almadan zaman tasarrufunun çoğunu sağlar. Denetim izi kanıtlanıp sayılar sıkıcılaştığında otonomiyi genişletme konuşması normal bir konuşmaya dönüşür — üstelik vaatten değil kanıttan başlar.

Q: En net kazanımlar hangi sektörde?
A: E-ticaret ve SaaS destek; çünkü görevler yüksek hacimli, kayıt sistemlerinin API'leri düzgün ve eylemlerin çoğu geri alınabilir. Ajanı gerekçelendirmeyi kolaylaştıran bu bileşimdir, sektörün kendisi değil.

Q: Ajanlar küçük işletmeler için faydalı mı?
A: Evet, genelde iç operasyon biçiminde: triyaj, taslak yazma, mutabakat. Kısıt büyüklerdekiyle aynı — veri yalnız tablolarda ve gelen kutularında yaşıyorsa önce erişimi düzeltin, yoksa ajan tahmin eder.

Q: Kurmadan önce değeri nasıl tahmin ederim?
A: Görev hacmini sayın, bugün bir insanın ne kadar sürdüğünü ölçün ve ajanın yardımsız tamamlayabileceği payı tahmin edin. O payda muhafazakâr olun; yüksek hacimli bir görevin %60'ını tamamlayan ilk ajan güçlü bir sonuçtur ve %95'ten çok daha güvenli bir vaattir.

## Kendinizi Kandırmadan Ajan Getirisini Ölçmek
https://aiagentdevelopment.info/tr/guides/ajan-getirisini-olcmek
2026-08-05 tarihinde güncellendi · Maliyet ve iş tarafı

- Temeli yayından önce yazın — hacim, işlem süresi, maliyet, mevcut hata oranı.
- Saptırmayı ya da mesaj sayısını değil, insan gerekmeden tamamlanan görevleri sayın.
- Hata maliyetini ve inceleme süresini çıkarın; sayıyı inandırıcı yapan o çıkarmadır.
- Niteliksel faydaları uydurma paraya çevirmek yerine ayrı raporlayın.

Ajan getirisi rakamlarının çoğu dikkatli bir okumaya dayanmıyor ve sebep neredeyse hep aynı: temel sonradan yeniden kuruldu ve hatalar aritmetiğe girmedi.

Dürüst bir sayı elde etmek zor değil ama yayından önce başlaması gerekiyor. Bugünün maliyetini, sonradan kullanacağınız birimlerle yazın. Geri kalan her şey bu tek disiplinden gelir.

### Önce temeli yazın
- Hacim: bu görev haftada kaç kez oluyor?
- İşlem süresi: bir insan ne kadar sürüyor — hatırlanan değil, örneklenerek ölçülen?
- Bunu yapan kişilerin tam yüklü saatlik maliyeti.
- Bugünkü kalite: hata ya da yeniden yapma oranı; ajan bununla karşılaştırılacak.
- Bekleme süresi: talep eden bugün ne kadar bekliyor, eğer bu onun için önemliyse.
Yayından sonra yeniden kurulan bir temel her zaman projeyi kayırır ve bunu inceleyen herkes bilir.

### Dayanan metrikler ve pohpohlayanlar
| Saptırma oranı | Cevapsız kalanı çözülmüş sayar | İnsan gerekmeden tamamlanan görevler |
| İşlenen mesaj | Hacim değer değildir | Uçtan uca tamamlanan görevler |
| Ajan sohbetlerinde memnuniyet | Hayatta kalan yanlılığı; sinirlenen ayrılır | Tüm temaslarda memnuniyet |
| Cevap başına kazanılan süre | İnceleme süresini yok sayar | İnsan incelemesinden sonra net dakika |
| Token başına maliyet | İş rakamı değil | Tamamlanan görev başına maliyet |

### Formül ve insanların attığı kısım
Yıllık fayda; insan gerekmeden tamamlanan görev sayısı çarpı görev başına kazanılan dakika çarpı dakika başına yüklü maliyet — eksi ajanın yol açtığı hataların maliyeti, eksi yarattığı inceleme süresi. Dürüst kısım o çıkarmadır. Görevlerin %70'ini tamamlayan ama her birini bir insanın kontrol etmesini gerektiren bir ajan, işlem süresini değil inceleme süresini kazandırmıştır ve fark genelde üç kattır.
Hata maliyetini kabaca da olsa açıkça tahmin edin: düzeltme süresi, artı itibar, artı hata yüzünden verilen iade ya da kredi.

### Gerçek ama faturada görünmeyen faydalar
Bazı gerçek değerler maliyet modelinde hiç görünmez. Gece üçte hızlı cevap. Tutarlılık — nöbette kim olursa olsun aynı soruya aynı cevap. Bir şeyin neden kararlaştırıldığına dair yazılı iz ki düzenlemeye tabi bir ortamda çok değerlidir. Personelin işin ilginç yarısına vakit ayırması. Bunları uydurma paraya çevirmek yerine ayrı ve dürüstçe raporlayın; bir finans incelemecisi, belirtilen niteliksel faydaya şüpheli derecede kesin bir rakamdan çok daha fazla güvenir.

### Dürüst cevabın hayır olduğu durumlar
Bazen aritmetik durun der ve bunu söylemek, bir getiri çalışmasının yaptığı en değerli şeydir. Düşük hacimli görevler bir yapımı nadiren geri öder. Her çıktının zaten kontrol edilmesi gereken görevler yalnız inceleme süresi kazandırır. Ve hataların pahalı olduğu görevler yüksek doğrulukta bile negatif getiri üretebilir — on bin yüksek değerli kararda %3 yanlış, üç yüz problem demektir. Bu sonucu da yayımlayın. Kanıta dayanarak bir ajanı öldürmüş bir ekip, bir sonrakini önerdiğinde çok daha inandırıcıdır.

Q: İlk ajan için gerçekçi tamamlama oranı ne?
A: İyi kapsamlanmış, yüksek hacimli bir görevin %60–80'i; kalanı devredilir. Verinizi görmeden %95 vaat eden biri, sizin salı öğleden sonranızı değil bir karşılaştırma testini tarif ediyordur.

Q: Geri ödeme ne kadar sürer?
A: İyi seçilmiş bir iç görevde makul hacimle, bakım dahil genelde altı ila on iki ay. Modeliniz altı haftada geri ödeme gösteriyorsa hata maliyetinin ve inceleme süresinin aritmetiğe girip girmediğini kontrol edin.

Q: Ajan yalnız taslak yazıyorsa değeri nasıl sayarım?
A: Boş sayfadan onaylı çıktıya kadar geçen süreyi önce ve sonra ölçün. Taslak yazan ajanlar riskin çok küçük bir kısmıyla tasarrufun çoğunu sağlar ve zaten onay almaları da çok daha kolaydır.

## Ajan Geliştiricisi İşe Almak: Neye Bakılır, Nasıl Sınanır
https://aiagentdevelopment.info/tr/guides/ajan-gelistiricisi-ise-alma
2026-08-05 tarihinde güncellendi · Maliyet ve iş tarafı

- Prompt uzmanı değil, hata biçimleriyle düşünen sistem mühendisleri işe alın.
- Bir briefle eleyin: araç şemaları, durma koşulları, on değerlendirme vakası, insan kapıları.
- Framework bilgisi başarıyı en az öngören sinyaldir.
- Her tedarikçiden prompt, şema, değerlendirme seti ve iz teslimi isteyin.

Unvan yeni, beceri seti değil. Canlıda ayakta kalan ajanları kuran insanlar, hızlı, yetenekli ve ara sıra kendinden emin biçimde yanlış olan bir bileşenle çalışmayı öğrenmiş sıradan güçlü mühendisler.

Bu yeniden çerçeveleme işe almayı çok kolaylaştırır. Prompt uzmanı aramıyorsunuz. Araç boş döndüğünde ne olacağını içgüdüsel olarak soran ve değişikliğin işleri iyileştirdiğini nasıl bileceğimiz konusunda bir fikri olan birini arıyorsunuz.

### Önem sırasıyla neler önemli
- API ve entegrasyon mühendisliği: işin çoğu sistemlerinizle düzgün konuşmaktır.
- Test içgüdüsü: modeli sormadan önce değerlendirmeyi sorarlar.
- Hata biçimi düşüncesi: boş sonuç, yetki, zaman aşımı, kısmi başarı.
- Güvenlik farkındalığı: en az ayrıcalık, enjeksiyon, denetim izleri, onay kapıları.
- Maliyet farkındalığı: token'ın nereye gittiğini bakmadan anlatabilirler.
- Model aşinalığı: faydalı, güçlü bir mühendisin haftalar içinde öğrenebileceği bir şey.
- Framework bilgisi: en az önemli ve en çok reklamı yapılan madde.

### İşe yarayan doksan dakikalık eleme alıştırması
Adaya kısa bir brief verin: sipariş sorularını cevaplayan ve iki bin liranın altında iade yapabilen bir ajan. Argüman şemalarıyla araç listesini, durma koşullarını, on değerlendirme vakasını ve insan kapısının arkasında ne olacağını isteyin. Kod aramıyorsunuz. `siparis_guncelle(id, alanlar)` yerine `siparis_iade_et(siparis_id)` tanımlayıp tanımlamadıklarına, reddetme ve boş sonuç vakalarını ekleyip eklemediklerine ve iade kapısının söylenmeden ortaya çıkıp çıkmadığına bakıyorsunuz.
Güçlü adaylar ilk beş dakikada yetkiler ve uç durumlar hakkında netleştirici sorular sorar. Tüm süreçteki en güvenilir sinyaldir.

### Deneyimi hevesten ayıran sorular
| Bir değişikliğin işe yaradığını nasıl bilirsiniz? | Elle deneriz | Sabit bir değerlendirme seti, öncesi ve sonrası |
| Araç boş döndüğünde ne yaparsınız? | Tekrar deneriz | Ajanın göre hareket edebileceği açık boş sonuç |
| Enjeksiyonu nasıl durdurursunuz? | Modele yok saymasını söyleriz | En az ayrıcalık, içerik yalıtımı, onay kapıları |
| Son ajanınız neden yavaştı? | Model yavaştı | Altı sıralı çağrı; ikisini paralelleştirdik, bağlamı kestik |
| Modeli nasıl seçersiniz? | En iyisini | Adım başına, kendi vakalarımızda ölçerek |

### Ajans, serbest çalışan ya da şirket içi
Ajans, teslim tarihi olan ilk yapıya uyar: standart hataları çoktan yapmış bir ekip satın alırsınız ve değerlendirme setiyle araç şemalarının teslimini bir çıktı olarak şart koşmalısınız. Serbest çalışan, ekibinizin sahiplenmeye devam edeceği bir sistemi genişletmeye uyar. Şirket içi, ajan ürünün parçası olduğunda doğrudur — o noktada birinin kalıcı olarak sahiplenmesi gerekir ve o kişi ancak kurarak edinilen bağlama ihtiyaç duyar. Yaygın başarısızlık, teslimatsız bir ajans yapısıdır: içeride kimsenin değiştiremediği bir sistem kalır.

### İki taraf için de kırmızı bayraklar
- Değerlendirme kalemi olmayan ya da değerlendirmeyi geliştiricinin denemesi sayan teklif.
- Verinizi görmeden doğruluk hakkında kendinden eminlik.
- Araç listesi yazılmadan yapılan framework önerisi.
- Yetkiler ya da son kullanıcının kim olduğu hakkında hiç soru sorulmaması.
- Sonda prompt, şema ve değerlendirme vakalarını teslim etmeye isteksizlik.

Q: Makine öğrenmesi mühendisi gerekli mi?
A: Genelde hayır. Ajan işi, bir model API'sine karşı sistem mühendisliğidir. ML uzmanlığını ince ayar, sınıflandırıcı eğitimi ya da ciddi getirim optimizasyonu yaparken getirin — ajanı kurmak için değil.

Q: Ekip ne kadar büyük olmalı?
A: İki mühendis ve yarı zamanlı bir alan uzmanı çoğu ilk yapıyı karşılar. Alan uzmanı isteğe bağlı değildir: değerlendirme vakalarını o verir ve doğru sonucun neye benzediğine o karar verir; hiçbir mühendislik bunun yerine geçmez.

Q: Ajans neyi teslim etmeli?
A: Depo, prompt'lar, araç şemaları, sonuçlarıyla değerlendirme seti, son bir aya ait izler, izleme panosu ve bilinen hata biçimlerinin yazılı notu. Bunlardan biri eksikse güvenle değiştiremeyeceğiniz bir sistem satın almışsınızdır.

## AI Ajanı Geliştirme Maliyeti: Gerçek Rakamlar ve Sebepleri
https://aiagentdevelopment.info/tr/guides/ajan-gelistirme-maliyeti
2026-08-05 tarihinde güncellendi · Maliyet ve iş tarafı

- İç ajanlar genelde 8–45 bin $, müşteriye dönük olanlar 35–150 bin $ arası kurulur.
- Saatlerin çoğunu entegrasyon, değerlendirme ve yetkiler alır — prompt en küçük kalemdir.
- İşletme maliyeti genelde mütevazıdır ve rutin bağlam/yönlendirme işiyle yarıya iner.
- Bakım için yılda kurma maliyetinin %15–25'ini ayırın ve bir sahip atayın.

Hiç kimse projenizi bir web sayfasından fiyatlandıramaz; ama aralıklar da gizem değil ve tahminin biçimi, yaptığımız ve incelediğimiz işlerde şaşırtıcı derecede tutarlı.

İhtiyacınız olan üç sayı şunlar: kurma, işletme ve bakım. Ekipler düzenli olarak birincisinde sıkı pazarlık eder, ikincisi için endişelenir ve üçüncüsünü tümden unutur — pek çok ajanın yayından sekiz ay sonra sessizce bozuk olmasının sebebi budur.

### Kapsama göre kurma maliyeti
| İç asistan, 2–3 salt okunur araç | 8–20 bin $ | Döngü, araçlar, getirim, küçük değerlendirme seti |
| Yazma yetkili iç ajan | 20–45 bin $ | Üstekiler artı yetkiler, denetim, onay kapıları |
| Müşteriye dönük destek ajanı | 35–90 bin $ | Üstekiler artı devir, ton işi, izleme, yük |
| Ürününüzün içindeki ajan | 60–150 bin $+ | Üstekiler artı arayüz, çok kiracılık, SLA, sürümleme |
| Yalnız kavram kanıtı | 5–12 bin $ | Tek yol, yetki yok, yayınlanabilir değil |

### Saatler gerçekte nereye gidiyor
Dağılım, projenin model olmasını bekleyenleri şaşırtıyor. İşler arasında kabaca: entegrasyonlar ve araç katmanı %30, değerlendirme ve yineleme %20, yetkiler, denetim ve güvenlik %15, izleme ve operasyonel araçlar %10, prompt ve getirim işi %15 ve ajan döngüsünün kendisi yaklaşık %10. Prompt mühendisliği tablodaki en küçük kalem; büyük kısmı prompt mühendisliğinden oluşan bir teklifin uyarı işareti olmasının sebebi de tam olarak bu.
Bir teklifte değerlendirme kalemi yoksa demo satın alıyorsunuz. Değerlendirme seti, bir demoyu korkmadan değiştirebileceğiniz bir şeye dönüştüren şeydir.

### İşletme maliyeti genelde korkulandan küçük
Tipik bir destek tarzı ajanda tamamlanan bir görev, bağlam boyutuna ve kaç adım sürdüğüne göre birkaç sentle birkaç on sent arasında model çağrısı eder. Ayda on bin görevde bu gerçek paradır ama yerine geçtiği emeğin yanında nadiren baskın sayıdır. Ayrıca standart önlemlerle hızla düşer — bağlamı budamak, basit adımları bir kademe aşağı yönlendirmek, sabit bir ön eki önbelleklemek — ki bunlar birlikte çıktı kalitesine dokunmadan faturayı sıklıkla yarıya indirir.

### Unutulan kalem: bakım
- Model emeklilikleri: yılda bir iki kez yeni sürümde yeniden onaylama.
- API kayması: araçlarınızın çağırdığı sistemler size sormadan değişir.
- Getirim bakımı: belgeler değişir ve bayat bir indeks hiç olmamasından kötüdür.
- Değerlendirme büyümesi: yeni kullanıcılarla yeni hata kategorileri gelir.
- Sahiplik: ajan tuhaf bir şey yaptığında birinin nöbette olması gerekir.
Yılda kurma maliyetinin %15–25'ini ayırın. Ajan biten bir proje değil, canlı bir servistir.

### Karşılaştırılabilir bir teklif nasıl alınır
Her tedarikçiden aynı beş şeyi isteyin, rakamlar karşılaştırılabilir hâle gelir: argüman şemalarıyla araç listesi; değerlendirme setini kimin kuracağı ve kaç vaka olacağı; hangi eylemlerin insan onayının arkasında duracağı; hangi izlemenin teslim edileceği; ve bakım anlaşmasının neyi kapsadığı. Üç kat farklı çıkan aralıklar neredeyse her zaman farklı kapsamları fiyatlıyordur — biri yetkileri ve değerlendirmeyi içerir, diğeri güzel arayüzlü bir demodur.

Q: Aynı brief için teklifler neden bu kadar farklı?
A: Çünkü brief hissettirdiği kadar belirli değildir. Yetkileri, değerlendirmeyi, izlemeyi ve bir bakım yolunu kapsayan teklif, çalışan bir mutlu yolu kapsayandan farklı bir üründür. Başlık rakam yerine yukarıdaki beş kalemi karşılaştırın.

Q: Bu aralıkların altında başlayabilir miyiz?
A: Evet. Dar bir görev, iki salt okunur araç ve yirmi değerlendirme vakası seçin; bu genelde 8–15 bin dolardır ve büyük yapının fonlanmaya değip değmediğini söyler. Ayrıca büyük projenin zaten ihtiyaç duyacağı araç katmanını ve değerlendirme takımını üretir.

Q: Şirket içinde geliştirmek daha mı ucuz?
A: Nakit olarak daha ucuz, zaman olarak daha pahalı ve yalnızca kıdemli biri sahiplenirse. Olağan başarısızlık, kimsenin yetkiler, değerlendirme ve izleme aşamalarına götürecek vakti olmayan umut verici bir iç prototiptir — maliyetin çoğunun saklandığı yer de tam orasıdır.

## Ajanları Ölçeklendirmek: Gecikme, Eşzamanlılık ve Kota
https://aiagentdevelopment.info/tr/guides/ajanlari-olceklendirmek
2026-08-04 tarihinde güncellendi · Canlı ortam ve işletme

- Darboğaz sunucularınız değil, sağlayıcı kotası ve saniyelerce süren çağrılardır.
- Etkileşimli ve arka plan trafiğini ayırın ve arka planı kuyruğa alın.
- Akıtın, gerçek ilerleme gösterin ve sınırlarda işe yarar kısmi sonuç döndürün.
- Bir olay sizi zorlamadan önce, bir anahtarın arkasında geri çekilme modu kurun.

İlk trafik dalgası her ekibe aynı dersi verir. Sunucularınız neredeyse boştur, veritabanınız gayet iyidir ve her şey yavaştır — çünkü her istek, kotası olan bir sağlayıcıya yapılan birkaç saniyelik çağrıdır ve kotalar kaç konteyner başlattığınızı umursamaz.

Bu yüzden ajan ölçeklendirmek çoğunlukla kuyruk teorisi ve beklenti yönetimidir; biraz da kapasite planlaması. İyi haber, tekniklerin iyi bilinmesi ve hiçbirinin ajanınızı yeniden yazmayı gerektirmemesi.

### Üç sınırdan hangisine çarptığınızı bilin
| Sağlayıcıdan 429 yanıtları | Dakika başına istek ya da token | Kuyruk, geri çekilme, anahtar/bölge dağıtımı |
| Yavaş ama hatasız | Koşu başına sıralı model çağrıları | Bağımsız adımları paralelleştir; döngüyü kısalt |
| Bellek ya da bağlantı tükenmesi | Kendi servisiniz | Sıradan kapasite işi |
| Yalnız yoğun saatte yavaş | Paylaşılan kota çekişmesi | Öncelik kuyruğu; düşük değerli işi ertele |

### Etkileşimli olmayan her şeyi kuyruğa alın
Trafiği ilk günden iki sınıfa ayırın. Etkileşimli iş — bir insan bekliyor — kısa bir süre sınırı, katı bir adım sınırı ve kalite izin veriyorsa hızlı bir model alır. Arka plan işi — toplu sınıflandırma, zenginleştirme, gece işleme — eşzamanlılığını sizin belirlediğiniz bir kuyruğa gider ve kota daraldığında ilk kısacağınız şey odur. Bu ayrım olmadan sabah dokuzda başlatılan bir toplu iş, ürünü kullanan insanlar için bir kesintiye dönüşür.

### Beklemeyi dürüstçe kısaltın
- Cevabı son token'dan sonra değil üretildikçe akıtın.
- Mevcut adımı sade dille gösterin: dönen bir çark değil, `siparişiniz kontrol ediliyor`.
- Bir sınıra çarpıldığında işe yarar kısmi sonucu, eksik olanı adlandırarak döndürün.
- Bloklamayan her şeyi kritik yoldan çıkarın ve sonrasında teslim edin.
Gecikme algısı, mühendislik kadar ürün problemidir. Görünür ilerlemeli beş saniyelik cevap, koşturduğumuz her testte üç saniyelik boş ekranı yeniyor.

### Geri çekilme modunu ihtiyaç duymadan önce tasarlayın
Sağlayıcı yavaşladığında, kota aştığında ya da çöktüğünde ajanın ne yapacağına önceden karar verin — ve sakin olduğunuz zaman kurun. Makul bir merdiven: tam ajan, sonra daha ucuz ya da alternatif model, sonra araç çağrısı olmadan yalnız getirimle cevaplama, sonra düz bir özür ve insana devir. Bunu nöbetçi mühendisin saniyeler içinde çevirebileceği bir anahtarın arkasına koyun. Geri çekilme modu olmayan ekipler, başkasının olayı sırasında tam kesinti yaşar; bu da bir cumayı harcamanın kötü bir yoludur.

### Önemli iki sayıyla kapasite planlaması
Tamamlanan görev başına model çağrısı ve tamamlanan görev başına token. Zirvede beklenen dakika başına görevle çarpın, kotanızla karşılaştırın ve limit artışına yayın sırasında değil öncesinde ihtiyacınız olup olmadığını bilin. Ajan biçim değiştirdiğinde yeniden hesaplayın — bir eleştirmen turu ya da ikinci bir uzman eklemek görev başına çağrıyı sessizce ikiye katlayabilir ve ilk işaret, aksi hâlde bir lansman günündeki 429 duvarı olur.

Q: Birkaç sağlayıcı hesabı ya da bölge kullanmalı mıyım?
A: Gerçek ölçek ya da dayanıklılık için evet — anahtarlar, bölgeler ya da sağlayıcılar arasında dağıtmak standart uygulamadır. Bunu tek bir iç arayüzün arkasında yapın ki ajan kodunuz habersiz kalsın ve rota başına model sürümlerini sabitleyin ki davranış hangi rotanın hizmet verdiğine göre değişmesin.

Q: Etkileşimli gecikmeyi nasıl kabul edilebilir tutarım?
A: Etkileşimli koşularda adımları sertçe sınırlayın, basit adımları hızlı modele yönlendirin, bağımsız araç çağrılarını paralelleştirin ve çıktıyı akıtın. Görev gerçekten on adım istiyorsa etkileşimli numarası yapmayı bırakın ve bir ilerleme görünümü verin.

Q: Trafik büyüdüğünde ilk ne bozulur?
A: Neredeyse her zaman sağlayıcı kotaları; ardından en yoğun aracınızın çağırdığı iç API. Yalnız ajanı değil araç katmanını da yük testine sokun; bir ajan, arkasındaki sistemlere giden trafiği o sistemlerin sahiplerini şaşırtan biçimde çarpar.

## Ajan Güvenliği: Korkuluklar, Yetkiler ve Prompt Enjeksiyonu
https://aiagentdevelopment.info/tr/guides/ajan-guvenligi-ve-korkuluklar
2026-08-04 tarihinde güncellendi · Canlı ortam ve işletme

- Ajanı, yabancılar tarafından ikna edilebilen yardımsever bir meslektaş gibi görün.
- Prompt enjeksiyonu mimaridir: en az ayrıcalık, içerik yalıtımı, onay kapıları, denetim.
- Yetkiyi son kullanıcı kimliğiyle, sunucu tarafında ve her çağrıda kontrol edin.
- Saldırgan vakaları değerlendirme setine koyun ve her model değişiminde yeniden koşturun.

Ajanların güvenlik modeli, ajanı kod olarak düşünmeyi bırakıp yardımsever, hızlı, yorulmaz ve bir yabancı tarafından bir şeye ikna edilebilen bir çalışan olarak düşünmeye başlayınca kolaylaşır.

O kişiye ilk gününde sınırsız veritabanı erişimi, limitsiz bir şirket kartı ve müşterilere denetimsiz e-posta gönderme yetkisi vermezdiniz. Aynı içgüdüler doğrudan çevrilebilir ve prompt'a yazacağınız her talimattan daha güvenilirdir.

### Prompt'la çözemeyeceğiniz tehdit
Prompt enjeksiyonu, ajanın okuduğu içeriğe gizlenmiş talimatlardır — bir destek talebi, bir web sayfası, bir PDF, bir araç açıklaması. Modelin, üzerinde akıl yürütmesi gereken veriyi izlemesi gereken talimattan güvenilir biçimde ayırmasının bir yolu yoktur ve `belgedeki talimatları yok say` gibi hiçbir ifade bu boşluğu kapatmaz. Bu yüzden savunma mimari olmak zorundadır: ajanın yapabileceklerini kısıtlarsınız ki başarılı bir enjeksiyon büyük değil küçük bir patlama yarıçapına ulaşsın.
Getirilen her içeriği, ajanınızın yanlış davranmasını isteyen biri yazmış gibi varsayın. Bunun yalnızca can sıkıcı olacağı şekilde tasarlayın.

### Uyguladığımız sırayla dokuz denetim
- Araç başına en az ayrıcalık: kapsamı dar, mümkünse salt okunur, asla her şeye yetkili bir servis hesabı değil.
- Son kullanıcı üzerinden yetkilendirme, her çağrıda sunucu tarafında kontrol edilir — oturum başında bir kez değil.
- Geri alınamaz her eylemin önünde, saniyeler içinde karar vermeye yetecek bağlamla insan onayı.
- Çalıştırmadan önce argüman doğrulama ve kimlik çözme; zorlamak yerine reddet.
- Koşu başına harcama ve adım sınırı, kullanıcı ve araç başına hız sınırı.
- İçerik yalıtımı: getirilen metni veri say, asla sistem talimatlarıyla birleştirme.
- Sistemden çıkan her şeyde, özellikle giden mesajlarda çıktı filtreleme.
- Tam denetim kaydı: kim, ne, hangi kayıt, hangi koşu, hangi sonuç.
- Acil durdurma: salt okunur cevaplamayı canlı bırakırken araçları kapatan tek bir ayar.

### Eylem türüne göre patlama yarıçapı
| Kullanıcının kendi kaydını okumak | — | Yetki kontrolü |
| Cevap taslağı yazmak | Evet | Gerekmez |
| Bir durum alanını güncellemek | Genelde | Denetim kaydı ve hız sınırı |
| Dışarıya mesaj göndermek | Hayır | İnsan onayı |
| İade ya da ödeme yapmak | Hayır | İnsan onayı, tutar sınırı |
| Veri silmek | Hayır | İnsan onayı, yalnız yumuşak silme |

### Veri işleme, açık konuşarak
Model sağlayıcısına neyin gönderilebileceğine yayından önce karar verin ve bunu politika belgesiyle değil kodla uygulayın — sınırda maskeleme, alan izin listesi ve banka numarası içeren bir kaydın asla dışarı çıkmadığını kanıtlayan bir test. Bulunduğunuz kademe için sağlayıcının saklama ve eğitim koşullarını bilin, tedarikçi dosyanızda tutun ve yenilemede yeniden kontrol edin. Gördüğümüz uyum sorunlarının çoğu karmaşık değildir: tam istek gövdelerini yakalayan bir hata ayıklama kaydı ya da tüm müşteri kaydını bağlama yapıştıran iyi niyetli bir özelliktir.

### Saldırgan gibi ve düzenli test edin
Değerlendirme setinize saldırgan vakalar koyun ve onları herhangi bir test gibi koşturun: içinde bir iç belgeyi e-postalama talimatı olan bir destek talebi; kullanıcının yönetici olduğunu iddia eden bir belge; kabul edilirse ajanın yetkisini aşacak bir istek. Ajanın yapmaması gereken bir eylemle biten her koşu ilginç bir anekdot değil, başarısız bir testtir. Bunları her model sürümü değişikliğinden sonra yeniden koşturun; çünkü saldırgan girdi altındaki davranış, sürümler arasında sıradan davranıştan daha çok kayar.

Q: Prompt enjeksiyonu daha iyi prompt'la çözülebilir mi?
A: Hayır. Sistem prompt'undaki talimatlar oranı düşürür ama ortadan kaldıramaz; çünkü model veriyi talimattan güvenilir biçimde ayıramaz. Bunu mimari bir problem sayın: en az ayrıcalık, içerik yalıtımı, onay kapıları ve denetim kaydı.

Q: Ajan servis hesabı kullanmalı mı?
A: Yalnız gerçekten kamuya açık veri için. Kullanıcıya özel her şeyde son kullanıcı kimliği yetki kontrolüne kadar akmalı ki ajan, yardım ettiği kişinin göremeyeceği bir şeyi asla okuyup değiştiremesin.

Q: İnsan kapısının arkasına ne konur?
A: Geri alamayacağınız her şey, müşterinin göreceği her şey, parasal bir eşiğin üzerindeki her şey ve ajanın emin olmadığı her şey. Gereğinden fazla kapıyla başlayın ve değerlendirme sayıları hak ettikçe kaldırın — tersi değil.

## Canlıda Ajan İzleme: Ne Kaydedilir, Neye Uyarı Kurulur
https://aiagentdevelopment.info/tr/guides/canlida-ajan-izleme
2026-08-04 tarihinde güncellendi · Canlı ortam ve işletme

- Her koşuyu izleyin: bağlamlar, araç çağrıları, model sürümleri, durma sebebi, sonraki düzeltmeler.
- Altı davranışsal metriği izleyin; en önemlileri başarı oranı ve insan müdahale oranı.
- Değişim hızına uyarı kurun ve her uyarıya temsilî bir iz iliştirin.
- Her gün gerçek koşulardan örnek okuyun — sorunlar metriklerden önce izlerde görünür.

Geleneksel bir servis, hızlı yanıt veriyor ve hata fırlatmıyorsa sağlıklıdır. Bir ajan ikisini de yaparken tamamen yanlış olabilir — her istek iki saniyede cevaplanır ve her biri mart ayında geri çekilmiş bir politikayı alıntılar.

Bu yüzden ajan izleme farklı bir disiplindir. İki şeye dayanır: ne olduğunu yeniden kurmaya yetecek ayrıntıda her koşunun izi ve hareketi bir anlam taşıyan küçük bir davranışsal metrik seti. Gerisi süstür.

### İşe yarar bir iz neler içerir
- Her log satırına, model çağrısına ve dış isteğe iliştirilmiş bir koşu kimliği.
- Her adımda modele gönderilen tam bağlam ya da bir özet artı birleştirilen parçalar.
- Argümanları, sonucu, süresi ve çıktısıyla her araç çağrısı.
- Çağrı başına model adı ve sürümü, artı token sayıları.
- Durma sebebi: tamamlandı, adım sınırı, harcama sınırı, insan kapısı, hata.
- Son çıktı ve bir insanın sonradan düzeltip düzeltmediği ya da geri alıp almadığı.

### Gerçekten hareket eden altı metrik
| Görev başarı oranı | Süregelen düşüş | Model değişimi, veri kayması, üst API değişimi |
| Koşu başına adım | Yavaş yükseliş | Araç hataları yeniden deneniyor; getirim bozulmuş |
| Araç bazında hata oranı | Tek araçta sıçrama | Üst sistem bozuk — ajan sorunu değil |
| İnsan müdahale oranı | Yükseliş | Güven düşüyor ya da yeni bir istek türü var |
| Dayanaksız iddia oranı | Herhangi bir artış | Getirim sessizce bozuluyor |
| Tamamlanan görev başına maliyet | Hacim sabitken artış | Bağlam şişmesi ya da fazladan tekrar |

### Yalnız hataya değil davranışa uyarı kurun
Bir ajan nadiren gürültüyle bozulur. Bozulması kayarak olur: biraz daha fazla adım, biraz daha fazla tekrar, biraz daha fazla devir ve bir sabah bayat belgelerden cevap veriyordur. Mutlak eşikler yerine kayan pencerede değişim hızına uyarı kurun — koşu başına adımın hafta bazında %30 artması gerçek bir sinyaldir, tek bir sekiz adımlı koşu değildir. Her uyarıyı temsilî bir koşunun iziyle eşleyin; çünkü kimsenin inceleyemediği uyarı hızla herkesin sustuğu uyarıya döner.

### Her gün gerçek koşuları örnekleyin ve okuyun
Hiçbir gösterge panosu okumanın yerine geçmez. Günde birkaç koşu seçin — birkaç başarı, her devir, sınıra çarpan her koşu — ve baştan sona okuyun. Canlı bir ajanda bulduğumuz her ciddi problem, metrikte görünmeden önce izde görünüyordu. Okuyan kişiyi dönüşümlü yapın; prompt'u yazan kişi, onun ne yanlış yaptığını fark etme ihtimali en düşük olandır.
Bulduğunuz şaşırtıcı her şeyi aynı gün değerlendirme setine ekleyin. İzlemeyi gözlem olmaktan çıkarıp iyileştirmeye çeviren alışkanlık budur.

### Toplamamanız gerekeni toplamadan kaydetmek
İzler yapısı gereği müşteri verisi içerir. Kimlikleri sonraki bir işte değil kayıt anında maskeleyin, tam bağlamlara metriklerden daha kısa bir saklama süresi verin ve kişisel verinin yoğunlaştığı yer olan araç argümanlarını, altındaki sistemle aynı erişim denetimlerinde tutun. İşe yarayabilir diye her şeyi sonsuza kadar saklamak, bir izleme projesinin uyum bulgusuna dönüşme biçimidir.

Q: Tam izleri ne kadar saklamalıyım?
A: Hata ayıklamaya ve denetim ihtiyaçlarına yetecek kadar — tam bağlamlar için yaygın olarak 30–90 gün; metrikler ve sonuç özetleri çok daha uzun. Süreyi bilerek belirleyin, çünkü bu kayıtlar kullanıcılarınızın yazdığı her şeyi içerir.

Q: En değerli tek uyarı hangisi?
A: Devirlerde ya da insan düzeltmelerinde artış. Davranışın kaydığına dair en erken dürüst sinyaldir ve doğruluğun aksine etiketleme gerektirmez — kullanıcılarınız ve operatörleriniz ajanı bedavaya notluyor.

Q: Özel bir gözlemlenebilirlik aracı şart mı?
A: Başlangıçta değil. Sorgulayabildiğiniz yapılı bir iz tablosu ihtiyacın çoğunu karşılar. Özel araçlar; yan yana koşu karşılaştırması, değerlendirme entegrasyonu ve prompt sürümlemeyi tek yerde isteyince işe yarar — iz okumak birkaç kişi için günlük bir işe dönüştüğünde benimseyin.

## Ajan Maliyetini Kaliteyi Bozmadan Düşürmek
https://aiagentdevelopment.info/tr/guides/ajan-maliyetini-dusurmek
2026-08-04 tarihinde güncellendi · Canlı ortam ve işletme

- Bir şeyi optimize etmeden önce görev türüne göre tamamlanan görev başına maliyeti ölçün.
- Artık ihtiyaç duymadığınız bağlam genelde faturanın en büyük kalemidir.
- Az muhakeme gerektiren adımları teker teker ve değerlendirmeyle bir kademe aşağı yönlendirin.
- Koşu başına harcamayı sınırlayın ve sınıra çarpan koşular için uyarı kurun.

Bir token faturası birini şaşırttığında ilk içgüdü, her yerde daha ucuz modele geçip kalite kaybını kabullenmektir. Bu nadiren gereklidir. İncelediğimiz sistemlerde harcamanın çoğu, orada olması gerekmeyen bağlamdan ve pahalı modele ihtiyaç duymayan adımlardan geliyordu.

Aşağıdaki yöntem sıkıcı ve etkili: önce ölçün, sonra dört değişikliği getiri sırasına göre uygulayın, ardından hâlâ bir sorununuz olup olmadığına karar verin. Ekiplerin çoğu ikinci değişiklikten sonra duruyor.

### Bir şeyi değiştirmeden önce koşu başına ölçün
Aylık toplam harcama size uygulanabilir hiçbir şey söylemez. Her koşu için şunları kaydedin: girdi token'ı, çıktı token'ı, model çağrısı sayısı, çağrı başına kullanılan model ve görev türü. Sonra görev türüne göre ayrılmış, tamamlanan görev başına maliyete bakın. Neredeyse her zaman bir ya da iki görev türü baskındır ve onların içinde bir adım baskındır. Başka bir şeyi optimize etmek, paranın olmadığı yere harcanan emektir.
Başarısız ve yarıda bırakılmış koşuları da paydaya katın. Başarmadan önce üç deneme yakan bir tekrar döngüsü, kalite sorunu kılığında bir maliyet sorunudur.

### Dört değişiklik, getiri sırasıyla
| Bağlamı buda: kullanılan belgeleri at, geçmişi sıkıştır | %20–40 | Hedef sabit kaldıkça düşük |
| Ucuz adımları küçük modele yönlendir | %20–40 | Adım bazlı değerlendirmeyle düşük |
| Sabit prompt ön ekini önbellekle | Tekrarlı trafikte %10–30 | Düşük |
| Adımları azalt: daha iyi araç, daha az tekrar | %10–25 | Orta — araç işi gerektirir |

### Fatura bağlamdır
Her tur biriken bağlamı yeniden gönderir; yani sekiz adımlık bir koşu aynı belgeyi sekiz kez ödeyebilir. Üç alışkanlık bunun çoğunu çözer: getirilen pasajları, onlara ihtiyaç duyan adım bittiğinde atın; eski turları döküm taşımak yerine kısa olgusal notlara sıkıştırın; ve araç sonuçlarını tüm API yanıtı yerine ajanın kullandığı alanlara budayın. Bunların hiçbiri yeteneği azaltmaz — modelin zaten kullanmadığı metni kaldırır ve dikkat daha az seyreldiği için kalite çoğu zaman artar.

### Zevke göre değil adıma göre yönlendirin
Çıkarma, sınıflandırma ve biçimlendirme nadiren en güçlü modelinizi ister; planlama ve kullanıcıya dönük düzyazı çoğu zaman ister. İlk grubu bir kademe aşağı taşıyın, değerlendirme setinizi koşturun ve sayılar tutuyorsa değişikliği koruyun. Bunu genel değil adım bazında yapmak, kimsenin okuduğu çıktıda fark görmeden faturanın üçte birini kesmenizi sağlar.
- En yüksek hacimli, en az muhakeme gerektiren adımla başlayın.
- Her seferinde tek adım değiştirin ve sonrasında değerlendirme setini yeniden koşturun.
- Hangi kararı hangi modelin ürettiğini kaydedin ki sonraki bir gerileme ilişkilendirilebilsin.
- Koşu başına harcama sınırı koyun ki patolojik bir vaka sınırsız olamasın.

### Yapılmaması gerekenler
Cevaplarınızı dayanaklandıran getirimi kesmeyin — biri düzeltmek zorunda kaldığında halüsinasyon token'dan çok daha pahalıdır. Bir çağrı tasarruf etmek için geri alınamaz eylemlerdeki eleştirmen turunu kaldırmayın. Ve prompt kelimelerinde mikro optimizasyon peşinde koşmayın; tasarruf, bağlam budamanın yanında gürültüdür ve aradaki farktan daha değerli mühendis saati harcarsınız.

Q: Önbellekleme kurmaya değer mi?
A: Koşularınız uzun ve sabit bir ön ek paylaşıyorsa — sistem talimatları, araç tanımları, politika metni — evet ve elinizdeki en ucuz kazançlardan biridir. Prompt'u sabit kısım önde, değişken kısım sonda olacak şekilde kurun; aksi hâlde önbellek işe yaramaz.

Q: Tasarruf için ince ayar yapmalı mıyım?
A: Yalnız yüksek hacimli, dar ve kararlı bir adımda, küçük bir modelin ince ayarla büyüğüne yetiştiği durumda. İnce ayar bir bakım yükümlülüğü ve yeniden eğitim döngüsü ekler; düşük hacimde yönlendirme ve bağlam budama onu rahatça döver.

Q: Tek bir patolojik koşunun servet yakmasını nasıl engellerim?
A: Koşu başına adım ve harcamayı sınırlayın, tekrarlanan aynı araç çağrılarını tespit edin ve devam etmek yerine kısmi sonuçla durun. Sonra sınıra çarpan koşular için uyarı kurun — bunlar genelde sadece bir gider değil, düzeltilmeye değer bir hatadır.

## Ajanları Test Etmek: Hakkını Veren Bir Değerlendirme Seti Kurmak
https://aiagentdevelopment.info/tr/guides/ajanlari-test-etme-ve-degerlendirme
2026-08-04 tarihinde güncellendi · Canlı ortam ve işletme

- Bir değişikliğin işe yarayıp yaramadığını kendi elli vakanız, her genel karşılaştırmadan iyi söyler.
- Sonucu ve yan etkileri notlayın, birebir dökümü asla.
- Belirsiz girdileri, reddetme vakalarını ve boş araç sonuçlarını bilerek kapsayın.
- Her prompt, araç, model ya da getirim değişikliğinde yeniden koşturun ve canlıdan örneklemeye devam edin.

Yayına çıkan ajanları pilotta çürüyenlerden ayıran soru basit: dünkü değişikliğin işleri iyileştirdiğini nereden biliyorsunuz? Cevabı olmadan her prompt düzenlemesi tahmindir ve her gerileme bir müşteri tarafından keşfedilir.

Değerlendirme seti bu sorunun cevabıdır ve bir platform gerektirmez. Bir dosyada elli vaka, onları koşturan bir betik ve vaka başına bir notlama kuralı, herhangi bir lider tablosundan çok şey söyler; çünkü bunlar sizin vakalarınızdır.

### Bir vaka neye benzer
Vaka; bir girdi, dünyanın başlangıç durumu ve kontrol edilebilir bir beklentidir. Beklenti neredeyse hiçbir zaman birebir metin değildir — bir ajan birkaç farklı ifadeyle doğru olabilir. Bunun yerine sonucu notlayın: 4471 numaralı siparişle iade aracını çağırdı mı; son cevap doğru teslim tarihini içeriyor mu; gerektiği gibi eylemeyi reddedip soru sordu mu. Düzyazı kalitesinin önemli olduğu yerlerde model tarafından notlanan bir ölçüt listesi kabul edilebilir; ama birkaç açık kritere indirin ve arada bir notlayanı elle kontrol edin.
Her vakanın ihtiyaç duyduğu durumu — sabit veriyi — vakayla birlikte saklayın. Canlı veri yüzünden yalnız salı günü geçen bir test, test değildir.

### Elli vaka ve nereden geldikleri
| Kayıtlardan sık gelen gerçek istekler | 20 | Gündelik yolu korur |
| Bilinen geçmiş hatalar | 10 | Gerilemelerin geri dönmesini engeller |
| Belirsiz ya da eksik tanımlı girdiler | 8 | Tahmin değil, soru sormalı |
| Reddetmesi gereken vakalar | 6 | Kapsam dışı, yetkisiz, güvensiz |
| Boş ya da bozuk araç sonuçları | 6 | Gerçekte en sık yaşanan olay |

### Yolu değil sonucu notlayın
Aynı doğru sonuca farklı yollardan varan iki koşu da doğrudur ve tek bir döküm dayatan test paketi sebepsiz yere sürekli kırılır. Neyin değiştiğini ve neyin söylendiğini doğrulayın: yan etkisi olan araç çağrıları, son cevabın kilit olguları, insan kapısının istenip istenmediği. Tam izi hata ayıklama için saklayın ama üzerine doğrulama yazmayın; yoksa her prompt iyileştirmesi yüz hata gibi görünür.

### Zaman içinde izlenecek dört sayı
- Tüm sette görev başarı oranı ve ayrıca reddetmesi gereken alt kümede.
- Dayanaksız iddia oranı — getirilen kanıtta olmayan olgular içeren cevaplar.
- Koşu başına maliyet ve gecikmenin ortancası ve 95. yüzdeliği.
- İnsan müdahale oranı: bir kişinin ne sıklıkla ve neden devreye girdiği.

### Hattınızda koşturun, yayından sonra da
Seti; prompt, araç, model sürümü ya da getirim yapılandırması her değiştiğinde koşturun — davranışı değiştiren yalnız bu dördü vardır ve dördü de sanılandan sık değişir. Yayından sonra gerçek trafikten örneklemeye devam edin: günde birkaç koşu seçin, elle notlayın ve şaşırtıcı olan her şeyi sete ekleyin. Büyümeyi bırakan bir değerlendirme seti, genelde bir çeyrek içinde kullanıcılarınızı temsil etmeyi bırakır.

Q: Başlamak için kaç vaka gerekir?
A: Elli, gerçek gerilemeleri yakalamaya yeter ve birkaç günde yazılacak kadar azdır. Yirmi başlamak için yeterlidir. Sayı, zor kategorileri kapsamaktan çok daha az önemlidir: belirsiz girdiler, reddetmesi gereken vakalar ve boş araç sonuçları.

Q: Çıktıları notlamak için model kullanabilir miyim?
A: Evet, dikkatle. Cevabın iyi olup olmadığını sormak yerine açık kriterler verin, ölçüt listesini kısa tutun ve düzenli olarak elle örnek kontrol edin. Model notlayıcılar kayar ve kaymış bir notlayıcı bir gerilemeyi seve seve onaylar.

Q: Değerlendirme dağıtımı engellemeli mi?
A: Güvenlik açısından kritik alt kümede engellesin — reddetmesi gereken vakalar ve geri alınamaz eylemleri içeren her şey. Genel kalitede eğilimi izleyin ve düşüşte otomatik engel yerine bir insan kararı isteyin; küçük hareket gürültü olabilir.

## Çok Ajanlı Sistemler: Birkaç Ajan Tek Ajanı Ne Zaman Döver
https://aiagentdevelopment.info/tr/guides/cok-ajanli-sistemler
2026-08-04 tarihinde güncellendi · Ajan geliştirme

- Birkaç ajanı yalnız alt görevler bağımsız, farklı araç isteyen ve yavaşsa kullanın.
- Düzyazı değil yapılı nesneler geçirin ve tüm isteğe tek koşu kimliği verin.
- Maliyeti ajan başına değil sistem genelinde sınırlayın.
- Sonuçların yanında devirleri de değerlendirin; yoksa gerileme size hiçbir şey söylemez.

Çok ajanlı diyagramlar bu alandaki en baştan çıkarıcı üründür. İş unvanı taşıyan kutular, aralarında oklar, tepede bir koordinatör — organizasyon şemasına benzer ve organizasyon şemaları ilerleme hissi verir.

Sonra canlıya çıkar ve sorular başlar: bu yanlış sayıyı hangi ajan üretti, koordinatör neden kabul etti ve bir istek neden artık on bir model çağrısına mal oluyor. Bu rehber, cevabın yine de buna değdiği koşullar ve ayıklanabilir kalan bir sistemin nasıl kurulacağı üzerine.

### Üç koşul
Birden fazla ajan, üçü birden geçerliyse kendini öder. Alt görevler gerçekten bağımsızdır — hiçbiri diğerinin çıktısı olmadan başlayamaz değildir. Her biri farklı bir araç seti ya da farklı bir model kademesi ister, yani uzmanlaşma gerçek bir şey satın alır. Ve iş, paralel yapmanın kullanıcı deneyimini değiştireceği kadar yavaştır. Yalnız ikisi geçerliyse daha çok araçlı tek bir döngü neredeyse her zaman daha iyi, daha ucuz ve daha kolay düzeltilir.
Sürekli birbiriyle konuşmak zorunda olan iki ajan, pahalı bir mesaj yolu olan tek ajandır.

### Topolojiler ve maliyetleri
| Amir | Bir ajan uzmanlara devreder | N+1 döngü | Amir yanlış yönlendirir |
| Hat | Sabit devirler, her aşama uzman | Öngörülebilir | Bir aşama sessizce bozulur |
| Paralel yayılım | Aynı görev, birkaç bakış, birleştirilir | En yüksek | Birleştirme adımı darboğaz olur |
| Tartışma / eleştirmen | Biri önerir, biri itiraz eder | Değişim başına 2× | İçgörüsüz uzlaşma |
| Kara tahta | Paylaşılan durum, ajanlar okur yazar | Öngörülemez | Yarış koşulları ve döngüler |

### Ayıklanabilir tutan tasarım kuralları
- Her ajana yazılı bir sözleşme verin: ne alır, ne döndürür ve asla ne yapmamalı.
- Ajanlar arasında yapılı nesneler geçirin; sonrakinin yeniden yorumlaması gereken serbest düzyazı asla.
- Tüm isteğe tek bir koşu kimliği verin ve her ajanın her çağrısına iliştirin.
- Toplamı ajan başına değil sistem genelinde sınırlayın, yoksa maliyet sessizce birikir.
- Açık bir yineleme sayacı ve çıkış koşulu olmadan döngüleri yasaklayın.
- Her ajan `bunu yapamadım` diyebilsin ve koordinatör bunu ele alsın.

### Kimsenin planlamadığı değerlendirme problemi
Tek ajanda sonuçları değerlendirirsiniz. Birkaç ajanda devirleri de değerlendirmelisiniz; çünkü her ajan tek tek doğru davranırken sistem yanlış cevap üretebilir — yönlendirici kötü seçmiştir ya da birleştirme önemli yarıyı düşürmüştür. İki düzeyde değerlendirme seti kurun: uçtan uca sonuçlar ve gerçek koşulardan yakalanmış ajan başına girdi-çıktı çiftleri. İkincisi olmadan bir gerileme size sistemin kötüleştiğini söyler, nerede olduğunu hiç söylemez.

### Buna değen bir örnek
Rakip araştırması gerçekten uyan bir görevdir: on şirket verildiğinde her biri için kamuya açık bilgi toplamak. Alt görevler bağımsızdır, her biri yavaştır ve birleştirme düz bir tabloya toplamadır. On paralel araştırma ajanı birinin süresinde biter ve tek bir sentezleyici özeti üretir. Bunu tek bir müşteri sorusunu ele alan destek ajanıyla karşılaştırın: adımlar sırayla birbirine bağlıdır, dolayısıyla ajanlara bölmek hiçbir karşılığı olmadan devir ve gecikme ekler.

Q: Amir ajan doğruluğu artırır mı?
A: Yalnız yönlendirme doğruysa. %95 doğru uzmanların önünde %90 doğru bir amir uçtan uca yaklaşık %85 verir ve yönlendirmeyi ayrı ölçmezseniz kayıp görünmez. Uzman sayısını, her birini tek cümleyle anlatacak kadar az tutun.

Q: Ajan tartışması maliyetine değer mi?
A: Bazen; eleştirmene karşı kontrol edeceği kanıtı verebildiğiniz, gerçekten tartışmalı yargılarda. Olgusal sorgularda çoğunlukla uzlaşma üretir, üstelik iki katı maliyetle. Yaygın olarak benimsemeden önce tek geçişli bir temele karşı ölçün.

Q: Çok ajanlı bir hatayı nasıl ayıklarım?
A: Her çağrıda paylaşılan bir koşu kimliği, ajan başına saklanmış girdi ve çıktılar ve devirleri sırayla gösteren bir görünümle. Kimin kime ne söylediğini yeniden kuramıyorsanız düzeltemezsiniz ve rastgele prompt yazmaya başlarsınız.

## Ajanlar İçin RAG: Bağlamda Boğulmadan Cevabı Dayanaklandırmak
https://aiagentdevelopment.info/tr/guides/ajanlar-icin-rag
2026-08-04 tarihinde güncellendi · Ajan geliştirme

- Getirimi her isteğin önüne cıvatalanmış bir adım değil, ajanın çağırdığı bir araç yapın.
- Yapıya göre parçalayın, parçaları kendi başına anlaşılır tutun, başlık ve kimlik iliştirin.
- Gerçek trafikte anahtar kelime + vektör melezi, ikisinden birini tek başına döver.
- Kaynak gösterimi şart koşun ve dürüst boş sonuca izin verin; yoksa ajan uydurur.

Getirimle güçlendirilmiş üretim genelde bir hat olarak anlatılır: soruyu göm, en iyi parçaları çek, yapıştır, üret. Bu bir soru-cevap kutusu için çalışır. Bir ajanın içinde ise yanlış biçimdir; çünkü ajan, bir adım atana kadar neye ihtiyaç duyduğunu bilmez.

İşe yarayan sürüm getirimi, ajanın kanıta ihtiyacı olduğuna karar verdiğinde çağırdığı bir araç olarak ele alır — bazen farklı sorgularla iki kez, bazen hiç. Bu tek değişiklik epeyce alakasız bağlamı ortadan kaldırır ve tüm koşuyu hem ucuzlatır hem keskinleştirir.

### Getirim bir ön adım değil, bir araç
Aramayı, sorgu argümanı olan ve küçük, yapılı bir sonuç döndüren sıradan bir araç olarak açın: her biri kimlik ve kaynak taşıyan birkaç pasaj. Ajan ne zaman çağıracağına karar verir, döneni gördükten sonra sorgusunu iyileştirebilir ve cevap düzyazı değil yapılı veriyse başka bir aracı çağırabilir. Hat sürümü bunların hiçbirini yapamaz ve isteğin kanıta ihtiyacı olsun olmasın her istekte getirim maliyetini öder.
Ajanın yazdığı sorguları kaydedin. Kullanıcılarınızın gerçekte ne sorduğuna dair alacağınız en dürüst tariftir.

### Gömme modelinden çok önemli olan parçalama kararları
- Sabit karakter sayısına değil yapıya göre bölün — başlıklar, bölümler, madde imleri.
- Her parçayı kendi başına anlaşılır tutun: `Ayrıca şunu gerektirir` diye başlayan bir parça bağlam dışında işe yaramaz.
- Hem model hem kaynak gösterimi için her parçaya belge başlığını ve bölüm başlığını iliştirin.
- Her parçayla birlikte bir kimlik ve URL saklayın ki cevap kaynağını gösterebilsin.
- Çok sayıda küçük parça yerine daha az, daha büyük ve anlamlı parçaları tercih edin; örtüşme kötü sınırların yamasıdır, strateji değil.

### Gerçek derlemlerde melez getirim saf vektörü döver
| Kavramsal soru | Güçlü | Zayıf | Vektör |
| Tam ürün kodu ya da hata metni | Zayıf | Güçlü | Anahtar kelime |
| Nadir özel isim | Karışık | Güçlü | Anahtar kelime |
| Yeniden ifade edilmiş politika sorusu | Güçlü | Zayıf | Vektör |
| Gerçek trafiğin çoğu | Karışık | Karışık | İkisi, birleştirilip yeniden sıralanmış |

### Ajana kaynak gösterdirin ve başarısız olmasına izin verin
Güvenilirlik işinin çoğunu iki gereklilik yapar. Birincisi, getirimden çıkan her iddia, geldiği pasajın kimliğini taşır ve arayüzünüz bunu bir bağlantı olarak basar — bu, dayanaksız ifadeleri makul değil görünür kılar. İkincisi, arama aracı hiçbir şey döndürebilmeli ve ajana `bunu belgelerimizde bulamadım` demenin doğru bir sonuç olduğu öğretilmelidir. Getirimde başarısız olamayan bir ajan uydurur; çünkü ona bıraktığınız tek seçenek uydurmaktır.

### İndeksi dürüst tutmak
Getirim kalitesi sessizce bozulur. Belgeler değişir, bölümler silinir ve indeks en son gördüğünü sunmaya devam eder. Düzenli aralıklarla yeniden indeksleyin, kaynağı yok olan parçaları oyalanmalarına izin vermek yerine silin ve doğru pasajı bilinen küçük bir sorgu değerlendirme seti tutun ki her değişiklikten sonra kapsamı ölçebilesiniz. Bu olmadan ortaya çıkan hata biçimi en kötüsüdür: mart ayında geri çekilmiş bir politikayı kendinden emin biçimde alıntılayan bir ajan.

Q: Ajan cevaplamadan önce her zaman getirim yapmalı mı?
A: Hayır. Her istekte getirim, gecikmeyi israf eder ve kanıta ihtiyaç duymayan sorularda bağlamı doldurur. Ajanın kanıt gerektiğine kendisi karar vermesine izin verin ve gerekirken ne sıklıkla getirmediğini ölçün.

Q: Kaç pasaj döndürmeliyim?
A: İyi seçilmiş üç ila altı pasaj, yirmiyi döver. Daha fazla metin dikkati seyreltir, maliyeti artırır ve ajanın yalnızca ilgili görünen bir pasaja dayanma ihtimalini yükseltir.

Q: Getirim işe yarar bir şey döndürmezse?
A: Bu desteklenen bir sonuç olmalı. Açık bir boş sonuç döndürün ve ajana bilgiyi bulamadığını söyleyip bir sonraki adımı önermesini — netleştirici bir soru sormak ya da bir insana devretmek — talimatlayın.

## Ajanlarda Hafıza: Ne Tutulur, Ne Sıkıştırılır, Ne Atılır
https://aiagentdevelopment.info/tr/guides/ajanlarda-hafiza
2026-08-04 tarihinde güncellendi · Ajan geliştirme

- Modellerin hafızası yoktur; ajanların bağlama yeniden koyduğunuz şey vardır.
- Dört katman: sabit hedef, birebir yakın turlar, sıkıştırılmış olgular, taze getirilmiş veri.
- Anlatıya değil kontrol edilebilir olgulara ve yalnız bir eşikte sıkıştırın.
- Kalıcı hafıza kaynak, süre ve kullanıcının düzeltme yolu ister.

Bir dil modeli çağrısında hafıza yoktur. Her tur taze bir istektir ve modelin bildiği tek şey bu sefer bağlama koyduğunuzdur. İnsanların "ajan unuttu" ya da "uzun koşuda kötüleşti" diye tarif ettiği her şey, kodunuzun ne taşıyacağına dair verdiği bir karardır.

Bunu kabul ettiğinizde hafıza tasarımı tanıdık bir mühendislik problemine dönüşür: her zaman ilgili olan ne, yakın zamanda ilgili olan ne, özetlenebilecek olan ne ve saklanmak yerine taze getirilmesi gereken ne.

### Dört katman
| Sabitlenmiş | Hedef, kısıtlar, kullanıcı kimliği, politika | Asla | 200–500 token |
| Yakın | Son birkaç tur, araç sonuçlarıyla birebir | Kayan pencere | 2–5 tur |
| Sıkıştırılmış | Eski turlar kısa olgusal not olarak | Büyüdükçe yeniden yazılır | 500 token altı |
| Getirilmiş | Bu adım için çekilen belge ve kayıtlar | Kullanımdan sonra atılır | Adım başına |

### Düzyazıyı değil olguları sıkıştırın
Yaygın hata, eski turları anlatı olarak özetlemektir — kullanıcı siparişini sordu, ajan baktı. Bu güzel okunur ve hiçbir işe yaramaz. Sonraki bir adımın ihtiyaç duyabileceği olgulara sıkıştırın: sipariş 4471, durum kargoda, müşteri iade istedi, iade politikası 30 gün, henüz iade yapılmadı. Yapılı, kontrol edilebilir ve onda biri boyutunda. Sonraki adım bir karar verecekse, sıkıştırma o kararın girdilerini korumak zorundadır; korumuyorsa tek işinde başarısız olmuştur.
Her turda değil, bir eşikte sıkıştırın. Bir özeti tekrar tekrar özetlemek, ayrıntıların sessizce kaybolma biçimidir.

### Getirim hafıza değildir
Bilgi tabanından çekilen belgeler, onlara ihtiyaç duyan adıma aittir. O adım bittikten sonra onları koşan bağlamda tutmak, şişkin, pahalı ve dikkati dağılmış bir koşuya giden en hızlı yoldur. Getir, kullan, kaynak göster, at — ve sonraki bir adım aynı bilgiye ihtiyaç duyarsa yeniden getir. Getirim ucuzdur; bayat belgelerle dolu bir bağlam değil.

### Oturumlar arasında kalıcı hafıza
Uzun ömürlü ajanlar bir kullanıcı ya da hesap hakkında gerçekten faydalı olgular biriktirir: tercihler, önceki kararlar, değişmeyecek kısıtlar. Bunları konuşma geçmişinin yığılmasına izin vererek değil, açık bir yazma adımıyla küçük ve yapılı bir kayıtta bilerek saklayın. Üç kural sağlıklı tutar: yalnız gelecek bir koşunun göre hareket edeceği olguları yazın, her olgunun nereden geldiğini kaydedin ve her olguya bir son kullanma ya da gözden geçirme tarihi verin. Kaynağı ve süresi olmayan kalıcı hafıza, yavaşça çürüyen bir kendinden emin hata kaynağına dönüşür.
- Bilerek yazın — sohbetin yan etkisi değil, bir araç çağrısı olarak.
- Her olgunun yanına kaynağını ve tarihini saklayın.
- Kayıt boyutunu sınırlayın ve kullanılmayanı süresi dolunca atın.
- Kullanıcının, hakkında saklananı görmesine ve düzeltmesine izin verin.

### Belirtiler ve sebepleri
| Koşunun başındaki bir kısıtı unutuyor | Kısıt sabitlenmemiş; geçmişle birlikte budanmış |
| Birkaç adımdan sonra kalite düşüyor | Bağlam bayat araç çıktısıyla seyrelmiş |
| Tamamlanmış bir adımı tekrarlıyor | Sonuç, bir sonuç işareti bırakılmadan özetlenip atılmış |
| Koşu uzadıkça maliyet tırmanıyor | Getirilen belgeler atılmak yerine birikiyor |
| Güncelliğini yitirmiş bir şeyi kendinden emin söylüyor | Kalıcı hafızada süre ve kaynak yok |

Q: Geçmişin ne kadarını birebir tutmalıyım?
A: Üç ila beş tur, bağlamı ele geçirmeden muhakemenin çoğunu karşılar. Araç sonuçlarını çağrılarına iliştirin ve daha eskisini sessizce atmak yerine yapılı olgulara sıkıştırın.

Q: Ajan hafızası için vektör veritabanı kullanmalı mıyım?
A: Belge getirmek için çoğu zaman evet. Tek bir koşunun anlık durumu için hayır — o, kendi deponuzdaki küçük ve yapılı bir nesnedir. İkisini karıştırmak hem bulanık bir durum makinesi hem odaksız bir arama indeksi üretir.

Q: Kalıcı hafızanın bayatlamasını nasıl önlerim?
A: Saklanan her olguya kaynak, tarih ve süre verin ve ikisi de varsa ajanın taze getirilmiş veriyi tercih etmesini sağlayın. Saklanan kaydı kullanıcıya açın ki yanlış olgular sessizce tekrarlanmak yerine düzeltilebilsin.

## Araç Çağırma: Ajanın Doğru Kullanacağı Araçlar Nasıl Tasarlanır
https://aiagentdevelopment.info/tr/guides/ajanlar-icin-arac-cagirma
2026-08-04 tarihinde güncellendi · Ajan geliştirme

- Ajan hatalarının çoğu prompt değil araç tasarımı hatasıdır.
- Bir araç bir iş; argümanları düzyazıyla değil tiplerle kısıtlayın.
- Hataları kısa talimat olarak yazın; boş sonucu meşru bir sonuç sayın.
- Her argümanı doğrulayın ve kimlikleri bu kullanıcının görebildiğine karşı çözün.

Bir ajan kötü davrandığında ilk içgüdü prompt'u yeniden yazmaktır. Bizim deneyimimizde sebep belki üçte bir oranında prompt'tur; kalanında araçlar bir programa göre tasarlanmıştır, oysa karşıda adlardan ve açıklamalardan fonksiyonun ne yaptığını çıkarmak zorunda olan bir okuyucu vardır.

Araçlar, ajanın dünyayı etkileme yeteneğinin tamamıdır ve tanımları kelimenin tam anlamıyla modelin bağlamının parçasıdır. İyi tasarlamak, prompt ayarından hem ucuz hem çok daha kalıcıdır; çünkü iyi bir araç davranışı rica etmek yerine kısıtlar.

### Kötü çağrıların çoğunu önleyen yedi kural
- Bir araç, bir iş. `siparis_ara` ve `siparis_iade_et`, mod argümanlı tek bir `siparis_yonet`i döver.
- Düzyazı yerine tipler. Numaralandırmalar, tam sayı aralıkları ve biçimler, açıklamanın asla yapamayacağı işi yapar.
- Ne olacağını söyleyen adlar. `musteriye_eposta_gonder`, `bildir`in olamadığı kadar açıktır.
- Talimat gibi hatalar: neyin yanlış olduğunu ve sırada ne yapılacağını tek kısa cümlede söyleyin.
- Boş sonuç da sonuçtur. Açık bir eşleşme-yok dönüşü, modelin tekrar denenebilir saydığı bir istisnayı döver.
- Yan etkili her şeyde etkisizlik anahtarı, ki tekrar deneme onu çoğaltamasın.
- Küçük dönüşler. Yükleri ajanın ihtiyaç duyduğu alanlara budayın; 40 KB'lık JSON bağlam değil kafa karışıklığı satın alır.

### Öncesi ve sonrası
| `sorgu(sql)` | Sınırsız güç, denetlenemez | `musteri_siparisleri(musteri_id, limit)` |
| `tarih: metin` | Model biçim uydurur | `tarih: metin, biçim YYYY-AA-GG` |
| `HTTP 500` | Eylem ima etmez, sonsuz denenir | `Sipariş servisi yanıt vermiyor. Kullanıcıya sonra denemesini söyle.` |
| Tüm kaydı döndürür | Bağlamı doldurur, dikkati seyreltir | Altı adlandırılmış alan döndürür |
| `durum_guncelle(id, durum)` | Her durum, her kayıt | Yetki kontrollü `siparisi_iptal_et(id)` |

### Açıklamalar prompt'tur, öyle yazın
Açıklama alanı meslektaşlarınız için belge değildir; modelin karar verirken okuduğu metindir. Aracın ne zaman kullanılacağını ve ne zaman kullanılmayacağını söyleyin, önemli olan tek ön koşulu adlandırın ve bir örnek argüman verin. Üç cümle, üç paragrafı döver — uzun açıklamalar bağlamın geri kalanını sıkıştırır ve davranışı nadiren değiştirir. Ayrıca hepsini tek dosyada, birlikte gözden geçirin: tek tek anlamlı olan araçlar, set olarak okunduğunda ancak görünen biçimlerde örtüşür.
İki araç aynı isteği makul biçimde karşılayabiliyorsa ajan bazen yanlışını seçer. Ya birleştirin ya da sınırı ikisinin açıklamasında da açık yazın.

### Çalıştırmadan önce her zaman doğrulayın
Model çıktısını hiçbir zaman denetlenmeden bir sistem çağrısına geçirmeyin. Argümanları şemaya göre doğrulayın, kimlikleri mevcut son kullanıcının görmeye yetkili olduğu kayıtlara karşı çözün ve eşleşmeyeni makul bir şeye zorlamak yerine reddedin. Net mesajlı bir ret iyi bir sonuçtur: ajan kısıtı öğrenir ve aynı koşuda başka bir şey dener. Sessiz bir zorlama ise ajanın yanlış kaydı güncellemesi ve raporun tuhaf görünmesine kadar kimsenin fark etmemesidir.

### Araçları ajandan ayrı test edin
Her araca kendi testlerini verin: geçerli çağrı, geçersiz argüman, yetki reddi, boş sonuç, üst sistem zaman aşımı. Sonra ajanı bir taklit araç katmanına karşı test edin ki bu koşulları bilerek zorlayabilesiniz. İncelediğimiz neredeyse her canlı olay, biri denemeyi akıl ettiğinde bu düzeyde kolayca yeniden üretiliyor — özellikle geliştirmede nadir, gerçek bir salı öğleden sonrasında sıradan olan boş sonuç durumu.

Q: Kaç araç fazla?
A: Tek döngüde kabaca ondan sonra seçim doğruluğu düşmeye ve açıklamalar bağlamı sıkıştırmaya başlar. Daha fazlası gerekiyorsa dar bir yönlendiricinin arkasına gruplayın ya da her biri küçük araç setli uzmanlaşmış ajanlara bölün.

Q: Araçlar ham API yanıtını döndürmeli mi?
A: Hayır. Ajanın gerçekten ihtiyaç duyduğu alanları taşıyan küçük, kararlı bir biçim döndürün. Ham yanıtlar bağlam israf eder, ajanın yanlış kullanabileceği alanları açar ve prompt davranışınızı başkasının API sürümüne bağlar.

Q: Ajanın argüman uydurmasını nasıl durdururum?
A: Kısıtlayın: serbest metin yerine numaralandırma, açık biçimler ve gerçek kayıtlara çözülmesi gereken kimlikler. Sonra doğrulayın ve net bir ret döndürün. Uydurulmuş argüman genelde, aracın ajanın bilmesinin imkânsız olduğu bir şeyi istediğinin işaretidir.

## Ajan Mimarisi: Canlıda Ayakta Kalan Desenler
https://aiagentdevelopment.info/tr/guides/ajan-mimarisi-desenleri
2026-08-04 tarihinde güncellendi · Ajan geliştirme

- Varsayılanınız, açık durma koşulları ve doğrusal izi olan sınırlı döngü olsun.
- Araç geçidi — doğrulama, yetkilendirme, hız sınırı, denetim — en yüksek değerli bileşendir.
- Planlayıcı–yürütücü görünür niyet, eleştirmen turu daha az dayanaksız iddia kazandırır.
- Hafızayı katmanlayın: hedef, son turlar, sıkıştırılmış geçmiş, taze getirilmiş bilgi.

Ajan mimarisi tartışmaları genelde yanlış uçtan başlar: kavram adları taşıyan kutulardan oluşan bir diyagramla. İşe yarayan sürüm, önlemeye çalıştığınız hatadan başlar; çünkü aşağıdaki her desen, belirli bir kötü öğleden sonrayı engellemek için vardır.

Bu altısı sürekli başvurduklarımız. Birbirleriyle birleşirler: canlıdaki tipik bir ajan, araç geçidi, iki hafıza katmanı ve insan kapısı olan sınırlı bir döngüdür; eleştirmen turu ise yalnız yanlış cevabın bedeli bir model çağrısını haklı çıkardığı yerdedir.

### 1. Sınırlı döngü
Temel durum ve varsayılanınız olması gereken şey. Küçük bir araç seti üzerinde tek bir döngü; açık durma koşullarıyla: adım sınırı, harcama sınırı, tekrar tespiti ve duvar saati sınırı. Erdemi, bir mühendisin yukarıdan aşağı okuyabileceği doğrusal izdir. Buradaki diğer desenlerin hepsi buna ektir, yerine geçen değil.
Ajanınızı çıkış listesi olan bir döngü olarak çizemiyorsanız henüz bir mimariniz yok; hevesli bir prompt'unuz var.

### 2. Planlayıcı–yürütücü ve yeniden planlama
Düzenli olarak beş adımı aşan görevlerde önce açık, numaralı bir plan isteyin, adımları yürütün ve bir adım başarısız olduğunda bayat planla devam etmek yerine yeniden planlayın. Fayda doğruluk değildir — bir insanın, ajan eylemeden önce niyetini görebilmesidir; bu da hem onayı hem hata ayıklamayı mümkün kılar. Bedeli fazladan bir model çağrısı ve planı kutsal değil değiştirilebilir sayma disiplinidir.

### 3. Eleştirmen turu
İkinci bir model çağrısı, taslak cevabı ya da önerilen eylemi hedefe ve getirilen kanıta karşı inceler ve bir kez geri gönderebilir. Bu, kendinden emin ama dayanaksız çıktının kayda değer bir kısmını yakalar. Yanlış sonucun pahalı, fazladan bir çağrının ucuz olduğu yerlerde kullanın: müşteriye giden mesajlar, finansal özetler, kod değişiklikleri. Her yerde kullanmayın — maliyeti ve gecikmeyi ikiye katlar ve kolay görevlerde çoğunlukla kendisiyle hemfikir olur.
| Sınırlı döngü | 0 | İzlenebilirlik, maliyet denetimi | Asla — temel bu |
| Planlayıcı–yürütücü | 1–2 | Görünür niyet, denetlenebilirlik | Beş adımın altındaki görevler |
| Eleştirmen turu | İncelenen çıktı başına 1 | Daha az dayanaksız iddia | Ucuz, geri alınabilir çıktılar |
| Araç geçidi | 0 | Yetki, denetim, hız sınırı | Yalnız prototiplerde |
| Hafıza katmanları | 0–1 | Uzun bağlamda isabet | Kısa tek turlu koşular |
| İnsan kapısı | 0 | Geri alınamaz eylemler güvende | Geri alınamaz hiçbir şey yoksa |

### 4. Araç geçidi
Ajanın sistemlerinizi doğrudan çağırmasına izin vermeyin. Her aracın önüne dört iş yapan tek bir katman koyun: argümanları şemaya göre doğrular, bu son kullanıcının bu kayda dokunabileceğini kontrol eder, hız sınırı uygular ve koşu kimliğiyle bir denetim satırı yazar. Bu, ajan sistemindeki en yüksek değerli altyapı parçasıdır ve haftalar değil günler süren sıradan bir koddur. Ayrıca ajan framework'ünü değiştirmenin güvenlik duruşunuza hiç dokunmaması demektir.

### 5. Katmanlı hafıza
Tek ve ayrıştırılmamış bir konuşma geçmişi, koşu ilerledikçe kötüleşen ajanların en yaygın sebebidir. Taşıdığınızı ayırın: hiç budanmayan hedef ve kısıtlar; birebir tutulan son turlar; kısa olgusal bir özete sıkıştırılan eski turlar; ve adım başına taze çekilen, hiç biriktirilmeyen getirilmiş bilgi. Uzun bağlam pahalıdır ve dikkat sonludur — her şeyi taşımak titizlik değil, seyreltmedir.

### 6. İnsan kapısı
Geri alınamaz her eylem, bir insanın saniyeler içinde karar vermesine yetecek bağlamla birlikte açık bir onay adımının arkasında durur: ne olacak, hangi kayda, ajan neden böyle düşünüyor ve reddedilirse ne yapacak. Kapı bir kısıt değil ürün özelliğidir — hataların pahalı olduğu bir sisteme ajanı sokmanızı sağlayan şeydir ve değerlendirme sayılarınız hak ettikçe seçerek kaldırdığınız şeydir.

Q: Altı desenin hepsi gerekli mi?
A: Hayır. Sınırlı döngü ve araç geçidiyle başlayın; gerçek sistemlere dokunan her şey için bu ikisi neredeyse zorunlu. Geri alınamaz bir eylem belirir belirmez insan kapısını ekleyin. Gerisi, izde işaret edebildiğiniz somut hatalarla hak edilir.

Q: Eleştirmen turu doğruluğu gerçekten artırır mı?
A: Modelin makul ama dayanaksız cevap üretebildiği görevlerde kayda değer biçimde evet — özellikle eleştirmene getirilen kanıt verilip iddiaları ona karşı kontrol etmesi istendiğinde. Basit sorgularda çoğunlukla ilk cevapla hemfikir olur ve maliyetinizi ikiye katlar.

Q: Araç geçidi nerede yaşamalı?
A: Ajan ile sistemleriniz arasında, son kullanıcı kimliğinin içinden aktığı kendi servisinizde. Ajan framework'ünün içinde yaşarsa, framework değiştirdiğiniz ilk anda yeniden yazarsınız ve güvenlik incelemeniz sıfırdan başlar.

## No-Code Ajan Platformları mı, Özel Geliştirme mi? Dürüst Karşılaştırma
https://aiagentdevelopment.info/tr/guides/no-code-mu-ozel-gelistirme-mi
2026-08-04 tarihinde güncellendi · Framework ve modeller

- Platform ve özel geliştirme rakip değil aşamadır; hata birinde fazla kalmaktır.
- Kullanıcı bazlı yetkiler, ürün sahipliği ve hacim sizi özele iter.
- Akışı platformda kanıtlayın, sonra yalnız hak eden parçaları yeniden kurun.
- Prompt, araç tanımı ve kayıtları ilk günden dışa aktarın.

No-code mu özel mi tartışması genelde satacak bir şeyi olan kişiler arasında yürüyor. İkisini de kurmuş biri olarak görüşümüz daha sıkıcı ve daha kullanışlı: bunlar rakip değil, aşamadır ve hata, kanıtın desteklediğinden uzun süre birinde kalmaktır.

Platform, görevinizin gerçekte ne gerektirdiğini keşfetmenin en ucuz yoludur. Özel geliştirme ise bunu öğrendikten sonra yetkilerin, birim maliyetin ve ürün yüzeyinin denetimini almaktır. Aşağıda hangi aşamada olduğunuzu nasıl anlayacağınız var.

### Pazarlamasız yan yana
| İlk çalışan sürüme süre | Günler | Haftalar |
| Maliyet biçimi | Koltuk ya da koşu başına, sürekli | Önde mühendislik, sonra altyapı |
| İç sistemlere erişim | Var olan bağlayıcılar kadar | Kod yazabildiğiniz her şey |
| Son kullanıcı bazlı yetkiler | Genelde kaba | Kurduğunuz kadar ince |
| Değerlendirme ve gerileme testi | Satıcıdan, bazen yüzeysel | Sizin, yatırdığınız kadar derin |
| Taşınabilirlik | Yapılandırma satıcıda | Sahip olduğunuz depo |
| Ne zaman doğru | Değer kanıtı, standart görev, küçük ekip | Ürün yüzeyi, gerçek yetkiler, hacim |

### Kararı hızla veren dört soru
- Ajanın iç veride kullanıcı bazlı yetkiye ihtiyacı var mı? Evetse, neredeyse her zaman özel.
- Ajan sattığınız şeyin parçası mı? Evetse özel — ürün yüzeyinizi dışarıya veremezsiniz.
- Ayda birkaç binden fazla görev koşacak mısınız? Evetse taahhütten önce koşu başına fiyatın aritmetiğini yapın.
- Kendi değerlendirme setinize ve denetim izinize ihtiyacınız var mı? Evetse platformun neyi dışa aktardığını sonradan değil önceden kontrol edin.

### İşe yarayan melez desen
Akışı platformda kanıtlayın, her şeyi ölçümleyin ve gerçek kullanıcılarla bir ay çalıştırın. Tasarlayarak öğrenemeyeceğiniz üç şey öğrenirsiniz: gerçekte hangi istekler geliyor, hangi araçlar kullanılıyor ve insanlar nerede devreye giriyor. Sonra yalnız hak eden parçaları yeniden kurun — genelde hassas sistemlere dokunan iki araç ve değerlendirme koşum takımı — gerisini yerinde bırakın. Her şeyi birden yeniden kurmak, edinmek için para ödediğiniz operasyonel bilgiyi çöpe atar.
Prompt'larınızı, araç tanımlarınızı ve konuşma kayıtlarınızı ilk günden dışa aktarın. Bir platform bunu zorlaştırıyorsa, bunu platform hakkında bir bulgu sayın.

### Özel geliştirmenin gerçek maliyeti
Özel geliştirme yalnız ajan döngüsü değildir. Tipli argümanları ve hata sözleşmeleri olan araç katmanı, yetki kontrolleri, değerlendirme seti, okuyabileceğiniz izleme, bir dağıtım yolu ve model sağlayıcı bir sürümü emekli ettiğinde bir sahip demektir. Müşteriye dönük bir ajan için iki ila dört aylık tahminimiz buradan gelir; dar bir API arkasındaki iç ajanın neden çok daha ucuz olduğu da buradan. Yalnız döngüyü bütçeleyen ekipler bir demo teslim edip orada takılıyor.

### Platformdan ayrılma zamanının işaretleri
- Özellik yerine bir bağlayıcı için geçici çözüm yazıyorsunuz.
- Koşu başına maliyet, toplantıda birinin sorduğu bir kalem hâline geldi.
- Bir güvenlik incelemesi sonraki adımı durdurdu ve platform soruyu cevaplayamıyor.
- Tek bir davranışı değiştirmek istiyorsunuz ve bunu arayüzde ifade edemiyorsunuz.
- Ajan artık müşteri deneyiminin parçası ve onu düzgün test etmenin yolu yok.

Q: No-code platform kalıcı cevap olabilir mi?
A: Evet; iç, standart, orta hacimli ve yanlış cevabın bedeli düşük görevler için. Pek çok faydalı otomasyon hiç kod projesine dönüşmemeli — ölçüt, yetkilerin, hacmin ya da ürün sahipliğinin bu soruyu dayatıp dayatmadığıdır.

Q: Özel geliştirme her zaman daha mı doğru?
A: Hayır. Doğruluk araç tasarımından, dayanaklandırmadan ve değerlendirmeden gelir; bunların hepsini platformda da yapabilirsiniz. Özel geliştirme size denetim ve ekonomi verir, zekâ değil.

Q: Özel geliştirmenin en büyük gizli maliyeti ne?
A: Bakım. Modeller emekli olur, API'ler değişir ve değerlendirme setinizin her değişiklikte yeniden koşması gerekir. Yılda kabaca geliştirme maliyetinin %15–25'ini ayırın ve ajana, herhangi bir canlı servise vereceğiniz gibi bir sahip atayın.

## Model Context Protocol Nedir? Geliştiriciler İçin Açıklama
https://aiagentdevelopment.info/tr/guides/model-context-protocol-nedir
2026-08-04 tarihinde güncellendi · Framework ve modeller

- MCP, ajan istemcisi ile sunucu arasında araç keşfini ve çağrısını standartlaştırır.
- Kimlik doğrulama, yetkilendirme ve onay MCP'de değil sizde kalır.
- Dar yetenek sarın ve izinleri sunucunun içinde, çağrı başına uygulayın.
- Üçüncü taraf sunucular, açıklamaları model bağlamınıza giren bağımlılıklardır.

Birden fazla ajan kuran her ekip aynı adaptörü iki kez yazar: sisteme bağlan, neler yapabileceğini anlat, bu yetenekleri modele bugünkü istemcinin beklediği biçimde sun. Model Context Protocol, ajan istemcisi ile araç sunucusu arasındaki arayüzü standartlaştırarak bu tekrarı durdurmak için var.

Bu gerçekten faydalı ve aynı zamanda coşkunun ima ettiğinden dar. MCP, yeteneklerin nasıl ilan edildiğini ve çağrıldığını tanımlar. Kimin çağırmaya yetkili olduğunu tanımlamaz — ve bu ikisini karıştırmak, güvenlik olaylarının çıktığı yerdir.

### Protokolün standartlaştırdığı şey
- Keşif: sunucu, istemciye hangi araçları ve kaynakları şemalarıyla sunduğunu söyler.
- Çağırma: istemci aracı tipli argümanlarla çağırır ve yapılı bir sonuç alır.
- Kaynaklar: istemcinin istek üzerine bağlama çekebileceği salt okunur içerik.
- Taşıma: farklı kişilerin yazdığı istemci ile sunucunun anlaşabilmesi için ortak bir biçim.

### Bilerek yapmadıkları
MCP kullanıcılarınızı doğrulamaz, belirli bir kullanıcının hangi kayıtları okuyabileceğine karar vermez ve bir eylemin insan onayı gerektirip gerektirmediğini belirlemez. Bunlar sizde kalır ve sınırın sunucu tarafında yaşamalıdır — izin isteyen bir istemci, izin sistemi değildir. En yaygın mimari hata, `run_query` gibi geniş bir aracı MCP üzerinden açıp ajanın prompt'unun onu sınırda tutmasını ummaktır.
Her MCP aracına, kafası karışmış ya da manipüle edilmiş bir çağıranın onu en kötü makul argümanlarla çağıracağı varsayımıyla davranın; er geç biri çağıracak.

### Bugün nerede kendini ödüyor
| Tek iç sistem, birkaç ajan istemcisi | Yüksek — sunucuyu bir kez yazarsınız |
| Yerel bağlamı okuyan masaüstü asistanları | Yüksek — ekosistem bunun etrafında kuruldu |
| Üç özel araçlı tek ajan | Düşük — doğrudan fonksiyon çağrısı daha basit |
| Denetiminizde olmayan üçüncü taraf araçlar | Orta — pratik, ama sunucuyu inceleyin |

### Güvenli benimseme yolu
- Genel güç değil, dar yetenek sarın: `sql(sorgu)` değil `siparis_getir(id)`.
- Yetkilendirmeyi sunucunun içinde, çağrı başına ve her şeye yetkili bir servis hesabı yerine son kullanıcının kimliğiyle uygulayın.
- Dürüst, kısa hatalar döndürün — `bulunamadı`, `yetkiniz yok` — ki ajan tekrar denemek yerine makul davransın.
- Her çağrıyı argümanları ve çağıran kimliğiyle kaydedin; biri ne olduğunu sorduğunda denetim iziniz budur.
- Bağımlı olduğunuz sunucuları, herhangi bir bağımlılıkta yapacağınız gibi incelediğiniz sürüme sabitleyin.

### Tedarik zinciri sorusu
Üçüncü taraf bir MCP sunucusu, ajanınıza araçları anlatan ve ajanınızın göndermeye karar verdiği argümanları alan koddur. Araç açıklamaları modelin bağlamının parçasıdır; yani kötü niyetli ya da özensiz bir açıklama davranışı etkileyebilir. Sunucuları benimsemeden inceleyin, okuyabildiklerinizi tercih edin ve güvenilmeyen sunucuları, hassas sistemlere de erişimi olan istemcilerden uzak tutun. Bu, yeni bir bağımlılık türüne uygulanan sıradan bağımlılık hijyenidir.

Q: Ajan kurmak için MCP şart mı?
A: Hayır. Bir avuç özel araçlı tek ajan için doğrudan fonksiyon çağrısı daha basittir. MCP, aynı yeteneğe birkaç istemciden ulaşılması gerektiğinde ya da başka ekiplerin kurduğu araçları tüketmek istediğinizde kendini ödemeye başlar.

Q: MCP varsayılan olarak güvenli mi?
A: O bir taşıma ve keşif standardı, güvenlik modeli değil. Kimlik doğrulama, kullanıcı bazlı yetkilendirme ve onay kapıları sizin sunucu tarafında uygulamanız gereken şeylerdir ve ajanın prompt'una devredilemez.

Q: MCP sunucuları prompt enjeksiyonu vektörü olabilir mi?
A: Evet — hem model bağlamına giren araç açıklamalarıyla hem de dönen içerikle. Sunucu çıktısını güvenilmeyen girdi sayın, araç kapsamlarını dar tutun ve canlı yazma yetkisi olan bir ajanı incelemediğiniz sunuculara yöneltmeyin.

## Ajanınız İçin Model Seçimi: Yetenek, Gecikme ve Maliyet
https://aiagentdevelopment.info/tr/guides/ajaniniz-icin-model-secimi
2026-08-04 tarihinde güncellendi · Framework ve modeller

- Tüm ajan için değil, adım başına model seçin.
- Kısa listeyi karşılaştırmalar, kararı kendi otuz vakanız yapar.
- Bağlayan kısıtlar: gecikme, yapılı çıktı güvenilirliği ve gerçek bağlam uzunluğu.
- Açık sürüm sabitleyin ve değerlendirme setini tek komut uzağında tutun.

Ekiplerin sorduğu soru "ajanlar için en iyi model hangisi" oluyor. İyi bir sistem üreten soru ise şu: bu adım için, bizim verimizde, bizim gecikme bütçemizde en iyi model hangisi — ve cevap genelde birden fazla model.

Bir ajan koşusu türdeş değildir. Bir sonraki eyleme karar vermek muhakeme ister. Dönen bir belgeden üç alan çıkarmak istemez. Sonucu kullanıcı için özetlemek istemez. Bunların hepsini tek bir satın alma kararı gibi ele almak, ekiplerin JSON biçimlendirmek için sınır model fiyatı ödemesine yol açar.

### Seçmeden önce koşuyu parçalayın
| Planlama ya da eylem seçimi | Muhakeme, talimata uyum | Karşılayabildiğiniz en güçlüsü |
| Argümanlarla araç çağırma | Güvenilir yapılı çıktı | Katı şemalarla orta kademe |
| Sonuçtan alan çıkarma | Kısa metinde doğruluk | Küçük ve hızlı |
| Sınıflandırma ya da yönlendirme | Tutarlılık | Küçük ya da ince ayarlı sınıflandırıcı |
| Kullanıcıya dönük cevabı yazma | Ton ve netlik | Orta kademe |

### Karşılaştırmalar kısa liste yapar, karar vermez
Genel karşılaştırmalar hangi modellerin makul olduğunu söyler. Sizin araç şemalarınızı, belge biçimlerinizi ve zor müşterilerinizi nasıl karşıladıklarını söyleyemez, çünkü bunların hiçbiri karşılaştırmada yoktur. Kendi kayıtlarınızdan otuz gerçek vaka toplayın — sizi utandıran beş tanesi de dahil — ve kısa listeyi bunlarla koşturun. Karşılaştırma sırası ile kendi-verinizdeki sıra arasındaki fark, kararı değiştirecek kadar büyük çıkıyor.
Doğru davranışın reddetmek ya da soru sormak olduğu vakaları da ekleyin. Modeller ne söyleyeceğini bilmekten çok, ne zaman duracağını bilmekte ayrışıyor.

### Gerçekten bağlayan üç kısıt
- Gecikme tabanı: her model çağrısının bir tabanı var ve ajan birkaç çağrı yapıyor. Tek çağrıyı değil tüm koşuyu ölçün.
- Yapılı çıktı güvenilirliği: geçerli argümanı %97 döndüren bir model, üç araç çağrılı koşularda on koşudan birini bozar.
- Bağlam davranışı: uzun bağlam pahalıdır ve dikkati zayıflatır; pazarlama üst sınırında değil, gerçekten kullanacağınız uzunlukta doğruluğu ölçün.

### Araştırma projesine dönüşmeyen yönlendirme
Model yönlendirme kulağa gelişmiş geliyor, genelde bir yapılandırma dosyası. Adım türü başına varsayılan model atayın, araç bazında geçersiz kılmaya izin verin ve hangi kararı hangi modelin ürettiğini kaydedin ki hataları ilişkilendirebilesiniz. Yalnız çıkarma ve sınıflandırma adımlarını bir kademe aşağı taşıyarak başlayın; bu tek başına, kullanıcıların gördüğü kısmın kalitesine dokunmadan token faturasının üçte biriyle yarısı arasını sıklıkla siler.

### Kullanımdan kalkmayı baştan planlayın
Model sürümleri sizin değil sağlayıcının takvimiyle emekli edilir. İki alışkanlık bunu olaysızlaştırır: kayan bir takma ad yerine açık sürüm sabitleyin ki altınızdan sessizce bir şey değişmesin ve değerlendirme setinizi tek komutla koşturulabilir tutun ki yerine geçecek modeli yeniden onaylamak bir proje değil bir öğleden sonra olsun. Bu alışkanlıkları olmayan ekipler, kullanımdan kalkma e-postasıyla olayı aynı sabah öğreniyor.

Q: Her şey için en büyük modeli mi kullanmalıyım?
A: Yalnızca ölçmediyseniz. Karar adımı genelde en güçlü modelden fayda görür; çıkarma, sınıflandırma ve biçimlendirme nadiren görür. Adım bazında ayırmak, elinizdeki en kolay maliyet düşürme yöntemidir ve kullanıcıların gördüğü kaliteye dokunmaz.

Q: Açık ağırlıklı modeller ajanlarda işe yarar mı?
A: Katı şemalı, dar ve iyi tanımlanmış adımlarda sıklıkla evet ve hacimde ekonomisi cazip olabilir. Çok araçlı açık uçlu planlamada hâlâ daha fazla iskele istiyorlar. Lider tablosunda değil, kendi otuz vakanızda test edin.

Q: Model seçimimi ne sıklıkla gözden geçirmeliyim?
A: Sağlayıcı benimseyebileceğiniz bir sürüm çıkardığında ve bunun dışında yaklaşık iki çeyreklik sabit bir ritimde. Bu ancak değerlendirme setini yeniden koşturmak tek komutsa sürdürülebilir; ona yatırım yapmanın asıl sebebi budur.

## Ajan Orkestrasyonu: Ne Zaman Gerekir, Ne Zaman Fazlalıktır
https://aiagentdevelopment.info/tr/guides/ajan-orkestrasyonu-ne-zaman-gerekir
2026-08-04 tarihinde güncellendi · Framework ve modeller

- Orkestrasyon dayanıklılık, etkisiz-tekrarlanabilirlik, dallanma ve sürdürme satın alır.
- Yarıda kalan bir koşuyu tekrarlamanın maliyetini sorun; benimseme kararını o verir.
- Kuyruk, durum satırı ve etkisizlik anahtarları faydanın çoğunu ucuza sağlar.
- Ne seçerseniz seçin prompt ve araç şemalarını akış tanımlarının dışında tutun.

Orkestrasyon kütüphaneleri gerçek bir problemi çözüyor: dakikalar süren, birkaç sisteme dokunan ve bir süreç yeniden başladığında zaten yaptığı ödemeyi tekrarlamadan hayatta kalması gereken bir koşu. Bu problem gerçektir ve elle çözmesi nahoştur.

Aynı zamanda çoğu ajanın problemi değildir. On beş saniyede cevap veren ve sıfırdan güvenle tekrar denenebilen bir destek ajanının hiçbirine ihtiyacı yoktur. Bu rehber durumları ayırıyor ki orkestrasyonu, mimari diyagram boş göründüğü için değil, hata biçimleri gerektirdiği için benimseyin.

### Orkestrasyonun gerçekte verdiği şey
- Kalıcı durum: koşu bir dağıtımı, bir çökmeyi ya da ölçek düşüşünü atlatır.
- Etkisiz-tekrarlanabilir adımlar: yeniden denenen bir adım, zaten olmuş bir yan etkiyi tekrarlamaz.
- Dallanma ve birleşme: prompt'un anlattığı akış değil, gerçek akış denetimi.
- Sürdürme: dört saat sonra gelecek bir insan onayı için duraklama.
- Yapıdan gelen gözlemlenebilirlik: her adım, durumu olan birinci sınıf bir nesnedir.

### Kararı veren sınav
Tek bir soru sorun: bu koşu yarıda ölseydi baştan başlamanın maliyeti ne olurdu? Cevap birkaç kuruş ve birkaç saniyeyse baştan başlayın — kalıcılığa değil, tekrar denemeye ihtiyacınız var. Cevap mükerrer bir iade, müşteriye ikinci bir e-posta ya da bir insanın yirmi dakikalık beklemesiyse kalıcı ve etkisiz-tekrarlanabilir adımlara ihtiyacınız var ve bunları elle örmeyi bırakmalısınız.
Çoğu ekip gerçek cevabını, ilk kez bir dağıtım koşunun ortasına denk geldiğinde öğreniyor. Öncesinde karar vermek daha ucuz.

### Karmaşıklığın nerede göründüğü
| Yerel geliştirme | Dosyayı çalıştır | İşçiyi ve durum deposunu da çalıştır |
| Hata ayıklama | Tek doğrusal iz oku | Koşu geçmişindeki adımları ilişkilendir |
| Koşu ortasında dağıtım | Koşu ölür | Koşu devam eder |
| İnsan onayı adımları | Zahmetli; genelde yeni istek | Birinci sınıf duraklat ve sürdür |
| 3. adımdaki hatanın bedeli | Her şeyi baştan koştur | Yalnız 3. adımı koştur |

### Çoğu ekibin atladığı orta yol
Çıplak döngü ile tam orkestrasyon platformu arasında seçim yapmak zorunda değilsiniz. Mütevazı bir kuyruk, koşu başına bir durum satırı ve yan etkili iki araçta etkisizlik anahtarları, faydanın belki yüzde sekseni kadarını operasyonel yüzeyin çok küçük bir kısmıyla verir. Koşu kimliğini ve adım indeksini yaptığınız her dış çağrıya yazın; iki tehlikeli aracın tekrarlanan kimliği reddetmesini sağlayın. Bu bir öğleden sonralık iştir ve insanların gerçekten canını yakan hata biçimini ortadan kaldırır.

### Benimseyecekseniz
- Ajan mantığını — prompt, araç şeması, durma kuralları — akış tanımlarının dışında tutun.
- Framework tam-bir-kez sözü verse bile her adımı etkisiz-tekrarlanabilir yapın; sözler eninde sonunda ağla karşılaşır.
- Toplam koşu maliyetini yalnız ajan döngüsünde değil, orkestrasyon katmanında da sınırlayın.
- İzleri satıcı konsolu olmadan okuyabileceğiniz bir biçimde dışa aktarın; olaylar hep uygunsuz saatlerde olur.

Q: Basit bir sohbet tarzı ajan için orkestrasyon kullanabilir miyim?
A: Kullanabilirsiniz ve çalışır; ama nadiren talep edeceğiniz bir fayda için her gün yerel geliştirme sürtünmesi ve hata ayıklama dolaylılığı ödersiniz. Koşular uzun, tekrarı pahalı ya da insan için duraklaması gerekiyorsa uzanın.

Q: Mesaj kuyruğu yeterli mi?
A: Çoğu zaman evet. Kuyruk artı koşu başına durum satırı artı yan etkili çağrılarda etkisizlik anahtarları, yaygın hata biçimlerini kapsar. Gerçek dallanma, birleşme ya da saatlerle ölçülen duraklamalar gerektiğinde yukarı çıkın.

Q: Adımlar dağıtıldığında koşuları nasıl ayıklanabilir tutarım?
A: Her koşuya kalıcı bir kimlik verin, bunu her log satırına, model çağrısına ve dış isteğe iliştirin ve her adımda modele gönderilen tam bağlamı saklayın. Dağıtık sistemler ilişkilendirme baştan tasarlandığında ayıklanabilir, sonradan eklendiğinde eziyettir.

## Ajan Framework'ü Seçimi: Asıl Önemli Olan Ne
https://aiagentdevelopment.info/tr/guides/ajan-frameworku-secimi
2026-08-04 tarihinde güncellendi · Framework ve modeller

- Framework sıralamaları hızlı eskir; uygunluğu belirleyen sorular eskimez.
- Üç pazarlık: sağlayıcı SDK'sı, orkestrasyon kütüphanesi, yönetilen platform.
- Prompt, araç şeması, değerlendirme seti ve iz biçimini kendi deponuzda tutun.
- Karar vermeden önce aynı küçük ajanı iki kez kurun — doğruluğu değil ayıklanabilirliği ölçün.

Ajan framework'lerini adlarıyla sıralayan her yazı, dizine girmeden eskir. Bu alandaki kütüphaneler çekirdek soyutlamalarını birkaç sürümde bir yeniden yazıyor; bugün karşılaştırmada en iyi görünen, sizin proje yayına girdiğinde çoktan başka bir şey olmuş olabilir.

Bu yüzden bu rehber daha kalıcı bir şey yapıyor: altı ay sonra seçiminizden hâlâ memnun olup olmayacağınızı belirleyen sekiz soruyu sıralıyor ve her cevabın size neye mal olduğunu anlatıyor. Bunu güncel kısa listeye götürün, savunabileceğiniz bir karar çıkar.

### Sekiz soru, önem sırasıyla
- Döngüyü okuyabiliyor muyum? Model çıktısının araç çağrısına dönüştüğü dosyayı bulamıyorsanız kötü bir koşuyu ayıklayamazsınız.
- Araç hatasında ne oluyor — bana mı geliyor, yoksa farklı bir prompt'la görünmez biçimde mi yeniden deneniyor?
- Prompt'um framework'ün prompt'u mu? Yazmadığınız gizli sistem metni bir denetimde sizi şaşırtır.
- Durum kalıcılaştırılıp sürdürülebiliyor mu, yoksa bir çökme koşuyu kaybettiriyor mu?
- Araçlar nasıl tanımlanıyor ve bu tanımları framework dışında yeniden kullanabilir miyim?
- Yükseltme hikâyesi ne — son iki sürümde çekirdek soyutlamalar yeniden adlandırıldı mı?
- Framework değiştirmeden model değiştirebilir miyim?
- Soğuk başlangıca ve her tura ne ekliyor?

### Üç geniş kategori, üç farklı pazarlık
| Sağlayıcı SDK'sı + kendi döngünüz | Tam görünürlük, en az bağımlılık | Tekrar deneme, durum, kalıcılık sizde | Tek ajan, az araç, yüksek ayıklanabilirlik ihtiyacı |
| Orkestrasyon kütüphanesi | Kalıcı durum, dallanma, tekrar deneme, sürdürme | Bir miktar görünürlük; yükseltme çalkantısı | Uzun süren ya da çok adımlı akışlar |
| Yönetilen ajan platformu | Barındırma, izleme, değerlendirme, arayüz | Taşınabilirlik; koltuk ya da koşu başına ücret | Küçük ekip, standart görev, hızlı kanıt |

### Size ait kalması gereken parçaları siz yazın
Ne seçerseniz seçin, dört varlık hiçbir framework'ün sahiplenmediği bir biçimde kendi deponuzda yaşamalı: prompt'lar, araç tanımları ve JSON şemaları, değerlendirme seti ve iz biçimi. Bunlar doğru hâle getirmesi gerçekten emek isteyen şeyler. Düz veri ve ince adaptörler olarak ifade edilmişlerse framework değiştirmek bir günlük adaptör işidir. Framework dekoratörleri ve kalıtım sınıfları olarak ifade edilmişlerse framework değiştirmek baştan yazmaktır — ve bu yüzden, değiştirmeniz gerektiğinde bile değiştirmezsiniz.

### Kimsenin yapmadığı ama herkesin yapması gereken deneme
Karar vermeden önce aynı küçük ajanı iki kez kurun: bir kez kısa listedeki favorinizle, bir kez sağlayıcı SDK'sı ve elle yazılmış bir döngüyle. İkisine de aynı üç aracı ve aynı on test vakasını verin. Doğruluk ölçmüyorsunuz — ikisi de benzer çıkacak. Ne kadar sürdüğünü, izin ne kadar okunur olduğunu ve yedinci vakanın neden başarısız olduğunu bulmanın ne kadar kolay olduğunu ölçüyorsunuz. Bu yarım gün, tanıdığımız her ekibe maliyetinden çok daha fazlasını kazandırdı.
Elle yazılmış sürümü saklayın. Bir tuhaflığın prompt'unuzdan mı framework'ten mi geldiğini kanıtlamanız gerektiğinde referans uygulamanız olur.

### Seçiminizi aştığınızın işaretleri
- Framework kaynağını kendi kodunuzdan daha sık okuyorsunuz.
- İhtiyacınız olan davranış için bir yama ya da çatal bakıyorsunuz.
- Yükseltmeler kırıcı adlandırmalar yüzünden erteleniyor ve iki ana sürüm geridesiniz.
- Prompt'unuzun yarısı, framework'ün eklediği metni etkisizleştirmek için var.
- İzleme için özel bir dışa aktarıcı gerekiyor çünkü yerleşik olan araç argümanlarını gizliyor.

Q: İlk ajan için framework şart mı?
A: Hayır. Üç araçlı bir ilk ajan bir döngü, bir şema listesi ve bir durma koşuludur. Bir kez elle kurmak, bir framework'ün sizin adınıza ne yapacağını öğretir; sonraki seçim çok daha bilinçli olur.

Q: Yönetilen platform bir tuzak mı?
A: Prompt'larınızı, araç şemalarınızı ve değerlendirme setinizi taşınabilir tuttuğunuz sürece değil. Platformlar çalışan bir sonuca gerçekten hızlı ulaştırır. Risk platform değil, fikri birikiminizin yalnızca orada yapılandırma olarak var olmasıdır.

Q: Framework seçimi doğruluğu ne kadar etkiler?
A: Sanılandan çok daha az. Doğruluk araç tasarımından, dayanaklandırmadan ve değerlendirmeden gelir. Framework'ler geliştirme hızını, ayıklanabilirliği ve operasyonel özellikleri etkiler — bunlar önemlidir ama karşılaştırma tablolarının ima ettiği biçimde değil.

## Ne Zaman Ajan Kullanılmaz (ve Onun Yerine Ne Kurulur)
https://aiagentdevelopment.info/tr/guides/ne-zaman-ajan-kullanilmaz
2026-08-04 tarihinde güncellendi · Ajan temelleri

- Sabit diziler ajan değil, içinde model adımı olan bir hat ister.
- Aritmetik, birebir eşleme ve saniye altı gecikme hepsi yanlış uyum.
- Değerlendirme seti yoksa değişikliğin işe yarayıp yaramadığı bilinemez — önce yirmi örnek kurun.
- Geri alınamaz yüksek değerli eylemler insan kapısının arkasına ait; ajan taslak yazar.

Ajan geliştirmek bizim işimiz; bu sayfa tam da bu yüzden var. Bir ekibin bu teknolojiye güvenini zedelemenin en hızlı yolu, hiç gerek olmayan bir göreve ajan koymak, betiğin %100 doğru yaptığı yerde %94 doğru çalışmasını izlemek ve sonraki çeyreği onu savunarak geçirmektir.

Aşağıda hayır dediğimiz altı durum ve yerine önerdiğimiz şey var. Hiçbiri model yeteneği hakkında bir yargı değil; belirsizliğin bir özellik değil bir maliyet olduğu yerlerle ilgili.

### 1. Adımlar hiç değişmiyor
Sıra sabitse — dosyayı çek, sütunları doğrula, dönüştür, yükle, bildir — bir sonraki adıma karar verecek bir şeye ihtiyacınız yok, çünkü kimse karar vermiyor. Hattı yazın. Bir adım muhakeme istiyorsa, örneğin serbest metin bir alanı sınıflandırmak, o tek adım için modeli çağırın ve gerisini deterministik bırakın. Modeli işe yaradığı yerde kullanır, her yerde öngörülebilir davranış elde edersiniz.
Gördüğümüz en yaygın fazla inşa bu. Hattın içindeki bir model çağrısı ajandan daha aşağı bir şey değildir; doğru olan şeydir.

### 2. Görev aritmetik ya da birebir eşleme
Toplamlar, mutabakatlar, vergi, yayımlanmış eşiklerle uygunluk kuralları: bunların doğru cevabı ve mevcut uygulaması vardır. Bir model bir hesabı çok güzel açıklayıp yine de ara sıra yanlış yapabilir; finansta ara sıra bir felakettir. Kodda hesaplayın, sonra modele asıl iyi olduğu şeyi yaptırın: sonucu kişiye kendi dilinde anlatmak.

### 3. Gecikme bütçesi bir saniyenin altında
Planlayıp iki araç çağırıp cevap veren bir ajan bunu güvenilir biçimde bir saniyenin altında yapamaz, çünkü her model çağrısının kendi gecikme tabanı vardır. Ödeme adımının, yazarken arama kutusunun ya da çağrı yönlendirme kararının içindeyseniz ya işi kritik yoldan çıkarıp sonucu sonra gösterin ya da bir sınıflandırıcı ve bir sorgu kullanın. Kullanıcılar istedikleri yavaş cevabı affeder; yavaş sayfayı affetmez.

### 4. Doğru bir koşunun neye benzediğini kimse söyleyemiyor
Ekip görevin doğru yapılmış yirmi örneğini üretemiyorsa değerlendirme setiniz yok demektir — ve değerlendirme seti olmadan bir değişikliğin işe yarayıp yaramadığını bilemezsiniz. Önce örnekleri kurun. Çoğu zaman bu yazma eylemi, görevin aslında üç ayrı görev olduğunu, ikisinin önemsiz, birinin ise asıl problem olduğunu ortaya çıkarır.
Yirmi etiketli örnek bilerek düşük bir eşik. Bir ekip buna ulaşamıyorsa görev, hangi yöntemle olursa olsun otomatikleştirilecek kadar anlaşılmamış demektir.

### 5. Her eylem geri alınamaz ve yüksek değerli
Havale, sözleşme imzası, canlı veri silme. Bunların önüne kesinlikle ajan koyabilirsiniz — vakayı derleyip insana devreden bir taslakçı olarak. Yapmamanız gereken, en kötü haftanızı içermeyen bir test setinden çıkan doğruluk oranına dayanarak, geri alınamaz bir şeye otonom bir döngüye denetimsiz yazma yetkisi vermektir.

### 6. İhtiyaç duyduğu veriye erişilemiyor
Bir ajan araçları kadar yeteneklidir, araçları da API'leriniz kadar. Bilgi okuma API'si olmayan bir sistemde ya da üç kişinin elle düzenlediği bir tabloda yaşıyorsa ajan tahmin etmeye indirgenir. Önce erişimi düzeltin. Bu iş gösterişsizdir ve değerin çoğunu da o taşır: okuma API'sini kuran ekipler ajanın sonrasında iki haftalık bir iş olduğunu görüyor.

Q: Peki ajan ne zaman açıkça doğru araçtır?
A: Bir sonraki adım gerçekten son adımın döndürdüğüne bağlıysa, önceden sabitleyemeyeceğiniz bir sırada birkaç araç gerekebiliyorsa ve bugün bir insan bunu bakıp karar vererek yapıyorsa. Döngü maliyetini bu bileşimde hak eder.

Q: Sabit bir hat için zaten ajan kurduk. Söküp atalım mı?
A: Şart değil — önce ölçün. Güvenilirse ve maliyet kabul edilebilirse bırakın, emeğinizi başka yere verin. Somut bir acıya işaret edebildiğinizde değiştirin: öngörülemeyen gecikme, koşu başına maliyet ya da kimsenin tekrar üretemediği hatalar.

Q: Ajan, deterministik bir sistemin parçası olabilir mi?
A: Evet ve çoğu zaman en iyi tasarım budur. Omurgayı deterministik tutun ve ajana muhakeme gereken tek bir sınırlı bölge verin; ne döndürebileceğine dair net bir sözleşmeyle. Esnekliği ihtiyaç duyduğunuz yerde, öngörülebilirliği her yerde elde edersiniz.

## Yapay Zeka Ajanı Türleri: Neredeyse Her Şeyi Kapsayan Beş Biçim
https://aiagentdevelopment.info/tr/guides/yapay-zeka-ajani-turleri
2026-07-28 tarihinde güncellendi · Ajan temelleri

- Beş pratik biçim: araçla güçlendirilmiş cevaplayıcı, tek döngü, planlayıcı–yürütücü, yönlendirici, işbirlikçi ajanlar.
- Her üst basamak, izlenebilirlik ve maliyet harcayarak yetenek satın alır.
- Canlıdaki ajanların çoğu üç ila altı araçlı tek döngüdür.
- Yukarı yalnız, basit biçimin yapısal olarak yetmediğini kanıtlayan bir izle çıkın.

Akademik ajan sınıflandırmaları — refleks, model tabanlı, hedef tabanlı, fayda tabanlı — sınavlarda işe yarar, pazartesi günü ne kuracağınıza karar verirken neredeyse hiç yaramaz. Pratikte önemli olan kontrol akışının biçimidir; çünkü maliyetinizi, gecikmenizi ve hata ayıklamanın zorluğunu o belirler.

Beş biçim, geliştirdiğimiz ya da incelediğimiz hemen her ajanı kapsıyor. Kabaca bir karmaşıklık merdiveni oluşturuyorlar ve en yaygın pahalı hata, görevin gerektirdiğinden iki basamak yukarıdan başlamak.

### Beş biçim, ucuzdan zora
| Araçla güçlendirilmiş cevaplayıcı | Tek model çağrısı, belki bir araç | Sorgu, zenginleştirme, sınıflandırma | Zar zor ajan; sorun değil |
| Tek döngülü ajan | Model küçük bir araç setinde döner | Destek işleri, araştırma, triyaj | Uzun görevlerde dolanma |
| Planlayıcı–yürütücü | Bir kez planla, yürüt, hatada yeniden planla | Çok adımlı operasyon, göç işleri | Üçüncü adımdan sonra bayat plan |
| Yönlendirici + uzmanlar | Bir yönlendirici dar bir alt ajan seçer | Farklı becerileri olan geniş alanlar | Yönlendirme hataları birikir |
| İşbirlikçi ajanlar | Birkaç ajan sonuç değiş tokuş eder | Gerçekten paralel araştırma ya da inceleme | Maliyet, gecikme, izi sürülemeyen hatalar |

### Doğru gelenden bir basamak aşağıdan başlayın
Tek döngülü ajan, ününün ima ettiğinden çok daha fazla gerçek problemi çözer ve muazzam bir üstünlüğü vardır: bir insanın yukarıdan aşağı okuyabileceği doğrusal bir iz. Üstündeki her basamak, izlenebilirliği harcayarak yetenek satın alır. Yukarı çıkmadan önce, basit biçimin başarısız olduğu somut vakayı adıyla söyleyebilin ve bunu bir izle kanıtlayın. Bu adımı atlayan ekipler, hatalarını kimsenin yerini bulamadığı beş ajanlı bir sistemle kalıyor — üstelik dört araçlı bir döngünün beşte bir maliyetle zaten yaptığı işi yaparak.

### Hangi basamağın gerektiğini anlamak
- Görev bir sorgu ve bir karardan ibaretse araçla güçlendirilmiş cevaplayıcı yeter.
- Araçlar az ve sıraları değişiyorsa tek döngü gerekir.
- Bu işi yapan bir insan önce kontrol listesi yazacaksa planlayıcı–yürütücü gerekir.
- İş, farklı araçlar isteyen ayrı uzmanlıklara temiz biçimde bölünüyorsa yönlendirici gerekir.
- İki alt görev gerçekten birbirine bağlı değilse ve ikisi de yavaşsa işbirliği kendini ödeyebilir.

### Uzman tuzağı
Yönlendiriciler diyagramda derli toplu görünür, kenarlarda kötü davranır. Yönlendirici yalnız isteği görür, uzmanların ne bulacağını görmez; yani tahmin etmek zorundadır — ve yanlış bir tahmin isteği, işe yarar bir şey söyleyemeyecek bir uzmana yollar. İki önlem işe yarar: bir uzmanın `benim alanım değil` demesine ve bir kez yeniden yönlendirmeye izin verin; uzman sayısını, yönlendirici prompt'unun her birini tek net cümleyle anlatabileceği kadar az tutun. Sınırı bir cümleyle anlatamıyorsanız yönlendirici de anlatamaz.
Yönlendirme doğruluğunu görev doğruluğundan ayrı ölçün. %95 doğru uzmanların önünde %90 doğru bir yönlendirici uçtan uca %85 verir ve yalnız toplamı izliyorsanız teşhis görünmez.

### Biçim ve maliyet, dürüstçe
Maliyet, diyagramın ima ettiğinden hızlı büyür. Tipik bir destek görevinde tek döngülü ajan bir avuç model çağrısı eder. Planlayıcı–yürütücü bir planlama çağrısı ve çoğu zaman bir yeniden planlama ekler. Yönlendirici, işe yarar hiçbir şey olmadan önce bir çağrı ekler. İşbirlikçi ajanlar çarpar: kendi döngüsünü koşturan üç uzman üç döngüdür ve bir koordinatör çıktılarını inceliyorsa dört olur. Bunların hiçbiri üst biçimlerden kaçınma sebebi değildir; onlara elinizde bir sayıyla, bilerek varma sebebidir.

Q: Çok ajanlı sistemler tek ajandan iyi midir?
A: Yalnızca alt görevler gerçekten bağımsızsa ve her biri farklı araç ya da farklı model kademesi istiyorsa. Aksi hâlde fazladan gecikme, fazladan token ve izi çok daha zor sürülen bir hata yüzeyi ödemiş olursunuz; karşılığında sunumda etkileyici duran bir diyagram alırsınız.

Q: Canlıda en yaygın biçim hangisi?
A: Üç ila altı araçlı, geri alınamaz eylemlerde insan kapısı olan tek döngülü ajan. Gösterişsizdir, gerçek görevlerin çoğuna oturur ve doğrusal izi sayesinde bir mühendis özel araç gerekmeden kötü bir koşuyu teşhis edebilir.

Q: Bir basamak yukarı çıkma zamanını nasıl anlarım?
A: Basit biçimin yapısal olarak düzeltemeyeceği gerçek bir hatanın izi elinizde olduğunda — bir kez yanlış yaptığı bir vaka değil, temsil edemediği bir vaka sınıfı. O izi yazın; aynı zamanda yeni biçimin işe yaradığını kanıtlayan test vakanızdır.

## Yapay Zeka Ajanları Nasıl Çalışır? Döngü, Adım Adım
https://aiagentdevelopment.info/tr/guides/yapay-zeka-ajanlari-nasil-calisir
2026-07-28 tarihinde güncellendi · Ajan temelleri

- Bir ajan turu: bağlamı topla, karar ver, doğrula, çalıştır, kaydet, durma koşullarını kontrol et.
- Model yalnız bağlama geri koyduğunuzu görür — tuhaf davranışların çoğu budama kararlarından doğar.
- Araç hatalarını teşhis değil, modelin uygulayabileceği talimat olarak yazın.
- İzler birincil hata ayıklama aracıdır; ikinci özellikten önce kurun.

Ajanlar demolarda sihir, canlıda tesisat gibi görünür. Sebebi şu: ilginç olan kısım modelin çıktısı değil, o çıktıyı tüketen döngüdür ve döngü tek oturuşta okunacak kadar kısadır.

Bu rehber tek bir isteği baştan sona o döngüde yürütüyor: her turda modelin ne gördüğünü, kodunuzun sonuçla ne yaptığını, başarısız bir aracın nasıl geri döndüğünü ve döngüyü neyin durdurduğunu. Bunu kendi sisteminiz için anlatabiliyorsanız hata ayıklayabilirsiniz. Anlatamıyorsanız hiçbir prompt ayarı onu güvenilir yapmaz.

### Döngünün bir turu, sırasıyla
- Bağlamı topla: hedef, araç tanımları, ilgili getirilmiş bilgiler ve olanların budanmış geçmişi.
- Modelden bir sonraki adımı iste. Ya doğrudan cevap verir ya da argümanlarıyla bir araç çağrısı ister.
- Hiçbir şey yapmadan önce argümanları doğrula — tipler, aralıklar ve bu çağıranın bu kayda dokunmaya yetkisi olup olmadığı.
- Aracı çalıştır. Hataları yakala ve yığın izi yerine kısa, olgusal mesajlara çevir.
- Çağrıyı ve sonucunu geçmişe ekle, sonra durma koşullarını kontrol et.
- Tekrarla ya da ajanın gerçekte ne yaptığıyla birlikte son cevabı döndür.

### Modelin görebildiği ve göremediği
Modelin, bağlama geri koyduğunuz şeyin ötesinde önceki turdan hiçbir hatırası yoktur. Kafa karıştırıcı ajan davranışlarının çoğu bu tek gerçekle açıklanır. Ajan dört adım önce söylenen bir kısıtı unutuyorsa, geçmiş budamanız onu düşürmüştür. Aynı başarısız çağrıyı üç kez deniyorsa, hata mesajı modelin harekete geçebileceği kelimelerle nedenini söylememiştir. Bağlam kurmak ilginç işin girişi değildir; ilginç işin ta kendisidir.
Araç hatalarınızı teşhis gibi değil, talimat gibi yazın. `HTTP 404` değil; `Bu numarayla müşteri yok. Kullanıcıdan sipariş numarasını doğrulamasını iste.`

### Planlama: açık mı, kendiliğinden mi
Plana ulaşmanın iki saygın yolu var. Kendiliğinden planlama, modelin plan belgesi olmadan tek tek adım seçmesidir — basit, dirençli ve uzun görevlerde dolanmaya yatkın. Açık planlama önce numaralı bir plan ister, sonra adım adım yürütür ve yalnız bir adım başarısız olduğunda yeniden planlar. Açık planlamanın denetimi ve kullanıcıya gösterimi çok daha kolaydır; bedeli, gerçeklik üçüncü adımda plandan ayrıldığında kırılgan olmasıdır. Beş adımın altındaki görevlerde kendiliğinden genelde yeter; ötesinde açık plan izlenebilirlikle kendini öder.

### Durma: demoların hiç göstermediği kısım
| Adım sınırı | 8–15 araç çağrısı | Kısmi işi açıklamayla birlikte döndür |
| Harcama sınırı | Koşu başına sabit maliyet | Dur ve incelemeye kaydet |
| Duvar saati | Etkileşimli kullanımda 30–120 sn | Bilinenle birlikte devret |
| Tekrar tespiti | Aynı çağrı ve argüman iki kez | Farklı bir dala zorla ya da dur |
| İnsan kapısı | Geri alınamaz her eylem | Durakla ve onay iste |

### Bir şey ters gittiğinde izi okumak
İz, tek bir koşudaki her bağlamın, kararın, çağrının ve sonucun sıralı kaydıdır. Önemli olan tek hata ayıklama aracıdır ve ilk kurulacak şeydir. Bir ajan yanlış davrandığında soru asla modelin neden kötü olduğu değildir; hangi turun ilk kez yoldan çıktığı ve o anda modelin ne görebildiğidir. On seferin dokuzunda cevap sıkıcıdır: bir araç boş liste döndürüp bunu söylememiştir, bayat bir bilgi bağlamda kalmıştır ya da bir yetki hatası genel bir arıza gibi ifade edilip model onu tekrar denenebilir saymıştır.

Q: Bir ajan durmadan önce kaç adım atmalı?
A: Etkileşimli görevlerde sekiz ila on iki araç çağrısı meşru olan hemen her şeyi kapsar; daha fazlasını isteyen bir koşu genelde takılmıştır. Toplu işler daha yükseğe çıkabilir ama yüksek sınırı bir harcama sınırıyla eşleyin ki döngü hem uzun hem pahalı olamasın.

Q: Ajan önce mi planlamalı, adım adım mı karar vermeli?
A: Kısa görevler adım adım gayet iyi ilerler. Bir görev düzenli olarak beş adımı aştığında açık plan koşuyu denetlenebilir kılar ve kullanıcıya ilerleme göstermenizi sağlar — bayat bir planı uçuruma kadar izlemek yerine hata durumunda yeniden planlayın.

Q: Ajanım neden aynı başarısız çağrıyı tekrarlıyor?
A: Neredeyse her zaman hata mesajı harekete geçirici bilgi taşımadığı için. Neyin yanlış olduğunu ve makul bir sonraki adımın ne olacağını söyleyen kısa, sade hatalar döndürün; ayrıca aynı argümanlarla aynı çağrının bir koşuda iki kez olmasını engelleyen tekrar tespiti ekleyin.

## AI Ajanı mı Sohbet Botu mu? Probleminiz Hangisini İstiyor
https://aiagentdevelopment.info/tr/guides/ai-ajani-mi-sohbet-botu-mu
2026-07-21 tarihinde güncellendi · Ajan temelleri

- Sohbet botları cevaplar; ajanlar konuşmanın dışındaki sistemlerde bir şeyi değiştirir.
- Fark bütçeyi, test stratejisini ve yayını kimin onaylayacağını belirler.
- Başarılı yapıların çoğu melezdir: getirimli cevaplama artı iki üç seçilmiş araç.
- Kullanıcıların bottan isteyip alamadığı şeyleri kaydedin — araç yol haritanız odur.

Ajan isteyen ekiplerin çoğu aslında sohbet botu tarif ediyor; sohbet botu isteyen ekiplerin azımsanmayacak bir kısmı da aslında ajan tarif ediyor. Etiket önemli, çünkü metin kutusunun ötesine geçtiğinizde bu ikisinin neredeyse hiç ortak yanı kalmıyor: farklı başarısızlık biçimleri, farklı testler, farklı onaylar, farklı maliyet eğrileri.

Ayrım çizgisi basit. Yazılımın konuşmanın dışında bir şeyi değiştirmesi gerekiyor mu? Cevap hayırsa — açıklıyor, özetliyor, taslak yazıyor, bilgi getiriyor — istediğiniz şey bir sohbet botudur, muhtemelen getirimle birlikte, ve haftalar içinde yayında olmalısınız. Cevap evetse — randevu alıyor, iade ediyor, güncelliyor, kaydediyor, gönderiyor — istediğiniz şey bir ajandır ve aylarla plan yapmalısınız; çünkü asıl iş cevaplarda değil, yetkilerde ve kurtarma yollarındadır.

### Dürüst karşılaştırma
| Ürettiği şey | İnsanın okuyacağı metin | Sistemde değişiklik, artı metin |
| En kötü gerçekçi hata | Birinin göre hareket ettiği yanlış cevap | Çoktan atılmış yanlış adım |
| Test | Soru setinde cevap kalitesi | Tüm koşu boyunca sonuç doğruluğu |
| Tipik geliştirme süresi | 2–6 hafta | Canlıya 2–4 ay |
| Kimin onayı gerekir | İçerik ve destek sahipleri | Ayrıca güvenlik, veri ve sistem sahibi |
| Süregelen maliyet kalemi | Token ve içerik bakımı | Entegrasyon kayması ve değerlendirme bakımı |

### Aslında sohbet botu istediğinizin işaretleri
- İşe yarayan çıktı, bir insanın gözden geçireceği açıklama, özet ya da taslak.
- Bilgi tabanınız süreçlerinizden daha sık değişiyor.
- Yazılımın yazmasına gönül rahatlığıyla izin vereceğiniz bir API yok.
- Değer saptırmada: daha az kolay talebin insana ulaşması.

### Aslında ajan istediğinizin işaretleri
- Cevabı okuyan kişi ardından başka bir sistemde beş tık yapıyor.
- Bir sonraki adımın ne olduğunu bilmek için önce bir şeye bakmak gerekiyor.
- Başarı, memnun okuyucuyla değil tamamlanmış işlemle ölçülüyor.
- Bir insan zaten bir kontrol listesi izliyor ve liste dallanıyor.

### Genelde kazanan melez
Gerçek kullanıcılarla temas ettiğinde ayakta kalan biçim nadiren saftır. Dikkatle seçilmiş iki üç aracı çağırabilen, geri alınamaz her şeyin önünde insan kapısı olan bir sohbet botudur. Getirim tabanlı cevaplamadan hızlı değere ulaşırsınız ve en çok tıkı ortadan kaldıran eylemleri tam tam ekleyersiniz — iade sorularından önce sipariş sorgusu, randevu sorularından önce müsaitlik sorgusu. Eklenen her araç, tam otonomiye sıçramak yerine küçük ve test edilebilir bir artıştır.
Sohbet botunu ölçümleyerek başlayın: insanların isteyip de yapamadığı şeyleri kaydedin. O kayıt, hayal gücüne göre değil talebe göre sıralanmış araç yol haritanızdır.

### Yalnız kodunuz değil, ekibiniz de değişir
Ajan, sorumluluğun kimde olduğunu değiştirir. Yanlış bir sohbet botu cevabı içerik sorunudur ve içeriğin sahibi ekibindir. Yanlış bir ajan eylemi operasyonel bir olaydır ve dokunduğu sistemin sahibinindir — o ekip de haklı olarak denetim izi, geri alma yolu ve saat başına ne kadar şeyin ters gidebileceğine dair bir sınır isteyecektir. Bu konuşmaları projenin başına bütçeleyin. Atlayan ekipler çalışan bir ajan kurar, sonra bir çeyreği yayına alamamakla geçirir.

Q: Sohbet botunu sonradan ajana yükseltebilir miyim?
A: Evet ve genelde en ucuz yol budur. Getirim katmanını, günlükleri ve prompt varlıklarını cevap döngüsünden ayrı tutun, sonra insan onay kapısıyla birlikte teker teker araç ekleyin. Atacağınız parçalar küçüktür; sohbet botunu önce çalıştırarak kazandığınız operasyonel bilgi değildir.

Q: Sohbet botu her zaman daha mı ucuzdur?
A: İstek başına genelde evet, çünkü ajan birkaç model çağrısı yaparken bot bir tane yapar. Sonuç başına çoğu zaman hayır. Bir ajan, aksi hâlde sekiz dakika personel zamanı yiyen bir işi tamamlıyorsa fazladan token, yerine geçtiği emeğin yanında önemsizdir.

Q: Düzenlemeye tabi bir işletme için hangisi daha riskli?
A: Açıkça ajan, çünkü eyliyor. Bu onu elemez — onay kapılarının, denetim kaydının ve geri alma yollarının sonraki faz değil, işin parçası olması gerektiği anlamına gelir; ve tasarımı gereği geri alınabilir eylemlerle başlamak gerekir.

## Yapay Zeka Ajanı Nedir? Geliştiriciler İçin İşe Yarar Bir Tanım
https://aiagentdevelopment.info/tr/guides/yapay-zeka-ajani-nedir
2026-07-21 tarihinde güncellendi · Ajan temelleri

- Bir AI ajanı karar verir, gerçek araçlarla eyler, sonucu gözler ve yeniden karar verir.
- Mühendislik döngüde ve araç sözleşmelerindedir; model içindeki bileşenlerden biridir.
- Sabit adım dizileri iş akışıdır — daha ucuz, daha öngörülebilir ve çoğu zaman doğru cevap.
- Otonomi eylem başınadır: yalnız taslak, yalnız geri alınabilir, kum havuzu ya da sınırsız.

"Ajan" kelimesi, güzel bir isim verilmiş bir prompt'tan kendi nöbet listesi olan dağıtık bir sisteme kadar her şeyi kapsayacak biçimde esnetildi. Bu bir sözlük sorunu değil, bütçe sorunu: ekipler bir şeyi onaylayıp başka bir şeyi teslim alıyor.

İş kapsamlarken kullandığımız tanım şu ve bilerek dar tutuluyor. Yapay zeka ajanı, bir dil modelinin bir sonraki adımı seçtiği, o adımı atmak için gerçek bir araç çağırdığı, dönen sonucu okuyup yeniden seçtiği yazılımdır — hedefe varılana ya da bir sınır durdurana kadar. Sisteminizde hiçbir şey araç çağırmıyorsa elinizde çok iyi bir metin üreteci var. Adımların sırası önceden sabitse elinizde, kutulardan birinde model olan bir iş akışı var. İkisi de yapılmaya değer şeyler. Hiçbiri ajan bütçesi gerektirmiyor.

### Ürün model değil, döngüdür
Her ajan aynı üç hamlenin tekrarıdır: karar ver, eyle, gözle. Model yalnızca karar adımına katkı sunar. Geri kalan her şey — hangi araçların var olduğu, hatalarının nasıl ifade edildiği, yinelemeler arasında hangi durumun taşındığı, döngünün ne zaman durması gerektiği — sizin yazdığınız ve sahiplendiğiniz sıradan yazılımdır. Ürünün model olduğunu sanan ekipler vakitlerini prompt'a harcar ve sistemin güvenilmez çıkmasına şaşırır. Ürünün döngü olduğunu bilen ekipler vakitlerini araç sözleşmelerine ve durma koşullarına harcar; kötü bir öğleden sonra hata ayıklayabilecekleri bir şey elde ederler.
İşe yarar bir sınav: modeli çıkarıp yerine aynı bilgiyi okuyan bir insan koysanız, sistemin geri kalanı hâlâ anlamlı olur muydu? Olmuyorsa çevredeki yazılım fazla ince demektir.

### Ajanı karıştırıldığı şeylerden ayıran şey
| Sohbet botu | Kimse — sorulanı cevaplar | Hayır | Yanlış ya da uydurma cevap |
| İçinde LLM adımı olan iş akışı | Geliştirici, önceden | Evet, sabit sırayla | Akış dışı girdide kırılır |
| Ajan | Model, çalışma anında | Evet, çalışma anında seçerek | Dolanır, döngüye girer, kötü veriyle eyler |
| Çok ajanlı sistem | Birkaç model, artı bir koordinatör | Evet | Yukarıdakilerin tümü, izi daha zor sürülür |

### Her gerçek ajanın taşıdığı dört parça
Framework adlarını çıkarın; çalıştığımız her canlı ajanda aynı dört parça vardı.
- Kontrol edilebilir bir hedef. Havada bir niyet değil: bir gözden geçirenin doğru ya da yanlış diye işaretleyebileceği bir cümle.
- Araç yüzeyi. Çağırabileceği belirli fonksiyonlar; tipli argümanlar ve dürüst hata dönüşleriyle.
- Bir hafıza ya da durum taşıyıcı. Bir sonraki yinelemenin öncekinden ne görmesine izin verildiği.
- Durma koşulları. Adım sınırı, harcama sınırı ve kontrolü insana devretme kuralı.

### Otonomi bir anahtar değil, bir kademe düğmesidir
Ajan tasarımındaki asıl karar ajan kullanıp kullanmamak değil, ne kadar ip vereceğinizdir. Pratikte dört kademe var ve başarılı projelerin çoğu demonun önerdiğinden daha solda başlar: ajan taslak yazar, insan gönderir; ajan geri alınabilir şeylerde eyler, geri alınamazları sorar; ajan bir kum havuzunda harcama sınırıyla serbestçe eyler; ajan canlı sistemlerde serbestçe eyler. Sağa doğru her adım hem değeri hem de patlama yarıçapını çarpar. Sağa, yol haritası öyle dediği için değil, değerlendirme sayılarınız hak ettiği için geçin.

### Tanımın hakkını verdiği yerler
Kelimede katı olmak üç yerde gerçek para tasarruf ettirir. Kapsamlama: bir özetleme adımı olan sabit beş API çağrısı bir iş akışıdır; bunu ajan olarak kurmak ihtiyacınız olmayan belirsizliği ekler. Tahmin: ajanlar iş akışlarından pahalıdır çünkü başarısızlık yüzeyi geniştir; dürüst bir etiket dürüst bir bütçe kurar. Değerlendirme: bir ajanı ancak aynı girdinin farklı yollar izleyebileceğini kabul ettiğinizde doğru test edebilirsiniz — bu da döküm yerine sonucu test etmek demektir.
Bir paydaş ajan istiyorsa, yazılımın kendi başına hangi kararı vermesini istediğini sorun. Böyle bir karar yoksa ona üç ay kazandırdınız.

Q: Sohbet botu bir AI ajanı mıdır?
A: Bu tanıma göre hayır. Sohbet botu konuşmanın içinde cevaplar; ajan konuşmanın dışındaki sistemlerde eylem alır. Sipariş veritabanınızı okuyan, iade işleyen ve müşteriye e-posta gönderen bir destek botu ajandır — kategorisini değiştiren şey konuşması değil, eylemleridir.

Q: Bir ajanın sayılması için otonom olması şart mı?
A: Kendi bir sonraki adımını seçmesi şart; bu, denetimsiz eylemek demek değil. Beş adım planlayıp dördünü yürüten ve beşinci için insan onayı bekleyen bir yapı hâlâ ajandır. Otonomi, eylemin geri alınabilirliğine göre eylem başına seçtiğiniz bir ayardır.

Q: Bunu kurmak için framework şart mı?
A: Hayır. En küçük işe yarar ajan bir while döngüsü, bir araç tanımı listesi ve bir durma koşuludur — belki yüz satır. Framework'ler kalıcı durum, dallanan akış ya da birkaç ajan arasında eşgüdüm gerektiğinde hak eder; başlangıçta değil.