Shippy'nin Ajan Dersleri: Hafıza Neden Bayatlıyor
Çok-ajanlı bir sistemi kendi prodüksiyonunda çalıştıranlar bu sahneyi bilir: lider ajan bir görevi worker’a devreder, worker ya doğru komutu kurar ya da emin adımlarla yanlış — ama kulağa doğru gelen — bir çağrı uydurur. Aradaki fark çoğu zaman modelin zekâsında değil, ajanın eline verdiğin araçların ne kadar öngörülebilir olduğunda saklı. Bu yüzden ajan inşa etme dersleri arayan herkes gibi ben de Ai2’nin deniz güvenliği ajanı Shippy’yi anlatan yazıyı AgentSpace’in lider+worker Claude ajanlarına karşı okudum.
Shippy ne anlatıyor
Ai2’nin Skylight ekibi, Shippy’nin mimarisini Hugging Face blogunda anlattı. Ajan üç parçadan kuruluyor: davranış sınırlarını çizen sistem promptu (“soul”), markdown+frontmatter formatındaki görev talimatları (“skills”) ve model/harness seçimini taşıyan ayrı bir “config” katmanı. Ajan API’yi ham haliyle çağırmak yerine tipli komutlar sunan özel bir CLI’a sarılmış. Ekip özetliyor: “Agents are nondeterministic. You can’t control what the model decides to do, but you can make the tools it reaches for predictable.”
Bizim eksiğimiz: resmi bir eval değil, göz kararı
Beni en çok yakalayan kısım CLI değil, eval sistemleriydi: konu uzmanları her görev için ağırlıklı bir rubrik yazıyor, bir LLM hakem her kriteri puanlayıp gerekçesini not ediyor, ağırlıklı toplam sabit bir eşiğe göre geçti/kaldı kararına dönüşüyor. Regresyon yapan bir sürüm kullanıcıya hiç ulaşmıyor.
AgentSpace’te böyle bir harness yok. Sprint çıktısını lider ajan ve ben elle gözden geçiriyoruz; biçimsel bir rubrik veya sabit eşik yok, hafızanın ne zaman bayatladığını da çoğunlukla iş bozulunca fark ediyoruz. Bunu kurmayı düşünüyorum ama henüz kurmadım — şu an elimdeki tek şey niyet, ölçüm değil.
Araç belirlenebilirliği ve model seçimi
İkinci ders CLI determinizmiyle ilgili: Shippy sonuçlarını shell’e değil diske yazıyor, böylece pipe limitlerini ve bozuk çıktıyı baştan önlüyor. AgentSpace’in headless worker’larında araç çağrıları bu kadar sıkı sınırlı değil; hangi komutun gerçekten var olduğunu ajanın kendi hafızasından değil sabit bir listeden okumasını istiyorum ama bunu Shippy’nin CLI katmanı kadar disipline etmiş değilim.
Yazının yol haritasındaki “basit sorguları küçük modele yönlendir” fikri de bize uyarlanabilir: sprint başına bütçeyi zaten kişiye değil işe göre ayırıyoruz, ama hangi worker adımının ucuz modelle idare edeceğine sistematik bakmadım — bir sonraki deneyim bu olacak.
Okuyucu için sonuç: ajanı akıllandırmak yerine ajanın dokunduğu her aracı ve her puanlama kriterini önceden sabitlemek, güvenilirliği modelin kendisinden daha çok belirliyor.
Bugün yapılabilecekler:
- Worker ajanının serbestçe komut/API çağrısı uydurabildiği noktaları listele
- Her noktayı tek, tipli bir CLI/fonksiyon çağrısına indir — encoding’i ajan icat etmesin
- Sprint sonunda en az birkaç görevi ağırlıklı bir rubrikle elle puanla (doğruluk, kapsam dışı öneri, kaynak ihlali)
- Ajanın “olmayan bir komut” uydurduğu her anı not al — bir sonraki skill/tool sınırın orada