Araçlara erişim
Ajan; arama, veritabanı, API çağrısı ya da kod çalıştırma gibi araçlarla dünyaya dokunur. Model karar verir, aracı çalıştıran kod eylemi yapar.
Bir dil modeli tek başına yalnızca metin üretir; dünyaya dokunamaz, bir API çağıramaz, bir dosyayı okuyamaz. AI ajanı, bu modeli bir hedefe yönlendiren ve ona araçlar (tools) veren bir kabuktur: model artık yalnızca yanıt yazmakla kalmaz, hangi aracı ne zaman kullanacağına karar verir, sonucu görür ve bir sonraki adımı buna göre atar. Bu "düşün → araç çağır → sonucu gözlemle → tekrarla" döngüsüne agent loop denir; sıradan bir sohbet botunu, çok adımlı işleri kendi başına yürütebilen bir sisteme dönüştüren şey budur. Bu sayfada bir ajanın normal LLM'den farkını, aracı nasıl çağırdığını (function calling), akıl yürütme döngüsünü, araçları standart biçimde bağlayan MCP'yi, birden çok ajanın iş bölümünü (orchestration) ve en kritik başlık olan güvenlik ile guardrail'ı birlikte ele alıyoruz. Temeller için LLM & Üretken AI rehberimizi öneririz.
Bir sohbet botu tek adımlıdır: soru gelir, yanıt üretir, durur. Bir ajan ise bir hedef alır ve o hedefe ulaşana kadar kendi başına birden çok adım atar. Aradaki fark üç yetenekte toplanır: ajanın araçlara erişimi vardır (arama, veritabanı, API, kod çalıştırma), her adımda karar verir (hangi aracı çağırayım, yeterince bilgi topladım mı) ve önceki adımların sonucunu bir tür bellekte taşıyarak ilerler. Bu otonomi güçlüdür ama bedeli vardır: ajan artık gerçek eylemler yapabildiği için, bir yanlış karar da gerçek sonuçlar doğurur. Bu yüzden ajan tasarımının merkezinde "ne yapabilsin" kadar "neyi yapamasın" sorusu durur.
# sohbet botu: tek atım
soru → yanıt → dur
# ajan: hedefe kadar döngü
hedef → düşün → araç çağır → sonucu gör
↑______________________________│
└─ yeterli mi? değilse tekrar
→ hedefe ulaşıldı
Ajan; arama, veritabanı, API çağrısı ya da kod çalıştırma gibi araçlarla dünyaya dokunur. Model karar verir, aracı çalıştıran kod eylemi yapar.
Adımlar önceden sabitlenmiş değildir; model her turda ne yapacağına kendisi karar verir. Otonomiyi de riski de bu esneklik getirir.
Önceki adımların sonuçları context'te taşınır; ajan nereye geldiğini "hatırlayarak" bir sonraki adımı planlar.
Model bir aracı doğrudan "çalıştırmaz"; onun ne yaptığını ve hangi parametreleri aldığını tarif eden bir şema verirsiniz (genellikle JSON schema ile: aracın adı, açıklaması ve girdileri). Model bir aracı kullanmak istediğinde, çağrılacak aracın adını ve parametrelerini yapılandırılmış bir çıktı olarak üretir — buna function calling denir. Aracı gerçekten çalıştıran sizin kodunuzdur; sonucu (tool result) tekrar modele geri verirsiniz, model de onu okuyup bir sonraki adıma karar verir. Kritik nokta şudur: modelin ürettiği yalnızca bir niyettir; o niyeti eyleme çevirmeden önce doğrulamak, yetkilendirmek ve gerektiğinde reddetmek sizin sorumluluğunuzdadır. Aracınız bir API ise, o API'nin tasarım ve güvenlik kuralları burada da geçerlidir.
# 1) araç şeması modele tanıtılır
{ "name": "hava_durumu",
"params": { "sehir": "string" } }
# 2) model bir niyet üretir (henüz eylem yok)
call hava_durumu({ "sehir": "İzmir" })
# 3) SİZİN kodunuz çağırır, sonucu modele verir
result { "derece": 31 }
model "İzmir'de hava 31°C."
Model yalnızca "şunu çağır" der; gerçek çağrıyı yapan sizin kodunuzdur. Bu ayrım, kontrolün nerede olduğunu belirler.
Aracın adı ve açıklaması, modelin onu doğru zamanda seçmesini sağlar. Belirsiz şema, yanlış araç çağrılarının en sık nedenidir.
Parametreleri çalıştırmadan önce denetleyin. Modelin ürettiği argümana körü körüne güvenmek, en yaygın güvenlik açığıdır.
Ajanın kalbi, akıl yürütme ile eylemi tek bir döngüde birleştiren desendir; yaygın adıyla ReAct (reason + act). Model her turda önce kısaca düşünür (ne yapmalıyım), sonra bir araç çağırır, aracın döndürdüğü sonucu gözlemler ve bu gözlemle bir sonraki adımı planlar. Bu döngü hedefe ulaşılana ya da bir sınıra değene kadar sürer. İşte bu yüzden ajanlarda iki güvenlik supabı şarttır: bir adım sınırı (sonsuz döngüye girip maliyeti patlatmasın) ve bir durma koşulu (görev bitti ya da başarısız). Karmaşık işlerde döngüden önce bir planlama adımı (görevi alt adımlara bölme) isabeti belirgin biçimde artırır.
hedef: "En yakın şubenin bugünkü çalışma saati?"
düşün önce kullanıcının konumunu bulmalıyım
çağır konum_bul() → "İzmir"
düşün şimdi İzmir şubesini arayayım
çağır sube_ara("İzmir") → { id: 12 }
düşün saatini sorgulayayım
çağır calisma_saati(12) → "09:00–18:00"
dur yeterli → yanıtı üret
# güvenlik supabı: max adım + durma koşulu
Her ajanı her araca ayrı ayrı, elle bağlamak katlanarak büyüyen bir entegrasyon yüküdür: N ajan × M araç. MCP (Model Context Protocol) bu sorunu, araçları ve veri kaynaklarını modele tanıtmak için ortak bir arayüz tanımlayarak çözer — tıpkı bir donanımın standart bir porta takılması gibi. Bir aracı bir kez "MCP sunucusu" olarak yayınlarsanız, bu protokolü konuşan her ajan onu ek kod yazmadan kullanabilir. Standartlaşmanın kazandırdığı ölçek büyük; ama getirdiği sorumluluk da net: modele bir araç bağlamak, ona gerçek bir yetki vermektir. Hangi MCP sunucusuna güvendiğiniz, o sunucunun hangi verilere ve eylemlere eriştiği, artık doğrudan güvenlik kararlarıdır.
Her ajanı her araca ayrı bağlamak sürdürülemez. Araç sayısı arttıkça özel entegrasyon kodu katlanarak büyür.
MCP, araçları ve veriyi modele tanıtmak için standart bir arayüz sunar. Bir kez yayınlanan araç, protokolü konuşan her ajanca kullanılır.
Bir MCP sunucusuna güvenmek, ona veri ve eylem yetkisi vermektir. Kaynağını, erişimini ve kapsamını denetlemeden bağlamayın.
Bir görev tek bir ajan için fazla genişse, işi uzmanlaşmış ajanlara bölmek işe yarayabilir. Yaygın desen orchestrator-worker'dır: bir yönetici ajan görevi parçalara ayırır ve her parçayı bir alt ajana (araştırmacı, kodlayıcı, doğrulayıcı) devreder, sonra sonuçları birleştirir. Bu, karmaşık işlerde odak ve paralellik kazandırır. Ama bedeli de gerçektir: her ajan ek maliyet, ek gecikme ve ek hata yüzeyi demektir; ajanlar arası iletişim yeni bir karmaşıklık katmanıdır. Pratik kural nettir — çoğu iş tek, iyi tasarlanmış bir ajanla çözülür. Çok ajanlı mimariye ancak görev gerçekten paralelleştirilebilir ya da belirgin biçimde ayrışan uzmanlıklar gerektiriyorsa geçin; "daha fazla ajan" kendiliğinden "daha iyi" demek değildir.
orchestrator
(görevi böl, birleştir)
│ │ │
┌─────┘ │ └─────┐
worker worker worker
araştırmacı kodlayıcı doğrulayıcı
└─────┐ │ ┌─────┘
▼ ▼ ▼
birleştirilen sonuç
# her ajan = ek maliyet + gecikme + hata yüzeyi
Çoğu iş, iyi tasarlanmış tek bir ajanla çözülür. Karmaşıklığı ancak gerçekten gerektiğinde ekleyin; sadelik varsayılan olmalı.
Görev paralelleştirilebiliyorsa ya da net biçimde ayrışan uzmanlıklar gerekiyorsa iş bölümü kazandırır. Aksi halde yük getirir.
Ajanlar çoğaldıkça "ne oldu" sorusu zorlaşır. Her adımı ve araç çağrısını loglamak hata ayıklamanın tek yoludur.
Bir ajan gerçek eylemler yapabildiği için, güvenliği bir sonradan-ekleme değil tasarımın merkezidir. En büyük tehdit prompt injection'dır: ajanın okuduğu güvenilmeyen bir içerik (bir e-posta, bir web sayfası, bir doküman) gizli bir talimat taşıyıp ajanı kaçırabilir. Bu yüzden asıl koruma modelin zekâsından değil, ajanın yetkisinin baştan sınırlanmasından gelir. Çerçeve sadedir: en az yetki (ajana yalnızca işini görecek araçları verin), geri alınamaz eylemlere insan onayı (para, silme, dışarı mesaj), güvenilmeyen içeriği veri gibi işleyip talimat saymamak ve her araç çağrısını loglamak. Bu konuyu derinlemesine, gerçek bir örnek üzerinden prompt injection ve AI ajanları yazımızda ele aldık.
Ajana yalnızca görevi için gereken araçları ve erişimi verin. Kullanmadığı her yetki, kötüye kullanılabilecek bir yüzeydir. Kimlik & erişim ilkeleri ajanlara da uygulanır.
Para transferi, veri silme, dışarı mesaj gibi geri alınamaz adımlar bir kişinin onayından geçsin. Ajan öneri üretir, tetiği insan çeker.
Ajanın okuduğu her dış metni potansiyel talimat sayın; onu "yapılacaklar" değil "işlenecek veri" olarak ele alın. Prompt injection'ın asıl panzehiri budur.
Ajanın hangi içeriği okuyup hangi aracı tetiklediğini görünür kılın; ajan davranışını temsili senaryolarla düzenli değerlendirin.
Sohbet botu tek adımda yanıt üretir ve durur. Ajan bir hedefe ulaşana kadar araç çağırıp sonuçları gözlemleyerek birden çok adım atar. Fark otonomidedir: bot konuşur, ajan iş yapar — ve bu yüzden ajanın yetkisini sınırlamak kritik olur.
Bir workflow'da adımlar önceden, kodla sabitlenmiştir; sonuç öngörülebilir ama esnek değildir. Bir ajan'da sıradaki adıma model karar verir; esnektir ama daha az öngörülebilirdir. Belirli ve tekrar eden işler için workflow, açık uçlu işler için ajan uygundur; ikisi bir arada da kullanılır.
İkisi de modele dış bilgi getirir ama farklı biçimde. RAG yanıt öncesi ilgili belgeleri çekip context'e koyar (çoğunlukla tek yönlü, okuma). Tool use ise modelin karar verip eylem çağırmasıdır — okuma da olabilir, yazma/işlem de. Aslında RAG, bir ajan için sadece bir araç türü olarak da kullanılabilir.
Bir API iki yazılımın konuştuğu genel bir arayüzdür. MCP ise özel olarak araçları ve veriyi bir dil modeline standart biçimde tanıtmak için tasarlanmış bir protokoldür. MCP'nin arkasında çoğu zaman yine bir API vardır; MCP onu modelin anlayacağı ortak bir sözleşmeye sarar.
Ajana ne kadar çok karar bırakırsanız o kadar otonom ama o kadar öngörülemez olur; ne kadar çok kural ve onay koyarsanız o kadar kontrollü ama o kadar dar olur. İyi tasarım bu ekseni göreve göre ayarlar: düşük riskli işlerde otonomi, geri alınamaz işlerde kontrol.
Agent loop desenini tanımlayan makale, tool use protokolünün resmi belgesi ve LLM uygulamalarının güvenlik rehberi.
Tool use tasarımından agent loop'a, MCP entegrasyonundan guardrail ve değerlendirmeye kadar; otonom ama kontrollü bir ajan mimarisi için bize yazabilirsiniz. Güvenlik tarafı için prompt injection ve AI ajanları yazımıza da göz atabilirsiniz.