Ajansal çerçevelerden sık sık bahsettik. LangGraph, CrewAI, AutoGen, çeşitli SDK'lar, döngü, araç çağırma, bellek, planlayıcı, eleştirmen, süpervizör. Allah aşkına, hepsi faydalı sözler. Ancak gerçekte kullanılan aracılara ne kadar çok bakarsam, bana öyle geliyor ki ilginç kısım çerçeve düzeyinin altına kaymış.

Artık soru basit değil: Bir adım modelinin düşünmesini sağlamak için hangi kütüphaneyi kullanmalıyım?

Asıl soru şu: Bu ajan demo olmayı bıraktığında nerede yaşıyor?

Because a serious agent is not a function that calls a model and returns text. Küçük bir dağıtılmış sistemdir. Bağlamı okumalı, araçları kullanmalı, kodu çalıştırmalı, dosyalara dokunmalı, kararları hatırlamalı, izin istemeli, başarısız olmalı, yeniden başlamalı, günlükleri bırakmalı, bütçeyi yakmamalı ve üretim deposunda bir buldozere dönüşmemelidir.

Çerçeve direksiyondur. Altyapı yol, frenler, garaj, sigorta ve anahtarların nerede olduğunu bilen kişidir.

Çünkü artık bunun hakkında çok fazla konuşuluyor

2023 ve 2024'teki konuşma oldukça model merkezliydi. Which LLM? Ne kadar bağlam? Fiyatı ne kadar? Programlamada ne kadar iyi?

2025 ve 2026'da konu değişti. Modeller gerçek işi yapabilecek kadar iyidir, ancak sıkıcı parçaların görünür olmasının nedeni budur: çalışma zamanı, güvenlik, bağlayıcılar, kimlik, gözlemlenebilirlik, kod yürütme, dağıtım, geri alma.

Bu, sihirden mühendisliğe doğal geçiştir.

Bir temsilcinin yalnızca yanıt oluşturması gerektiğinde sohbet etmek yeterlidir. Bir çekme isteği açmanız, bir veritabanını sorgulamanız, bir CRM'yi çağırmanız, bir iş başlatmanız, bir sitede gezinmeniz, Slack okumanız, kodu derlemeniz ve bir belgeyi güncellemeniz gerektiğinde, bunun etrafında bir işletim sistemine ihtiyacınız vardır.

Kelimenin tam anlamıyla değil. Organizasyonel anlamda.

İlk parça: aracının dayanabileceği bir çalışma zamanı

An agent often works in steps. Duruma bakın, bir eylem seçin, bir araç kullanın, sonucu gözlemleyin, planı güncelleyin, tekrarlayın.

Bu döngü tek bir HTTP isteğinin içinde yaşıyorsa, hemen bir sorun yaşarsınız. Bazı eylemler yavaştır. Bazıları insan girdisini bekliyor. Bazıları başarısız olur ve tekrar denenmesi gerekir. Bazılarının dağıtımdan veya zaman aşımından sağ çıkması gerekir.

Dayanıklı iş akışlarının, kuyrukların, iş geçmişlerinin ve durum makinelerinin devreye girdiği yer burasıdır. Gösterişli değiller ama demoda akıllı görünen bir temsilci ile kahve alırken çalışmayı bırakabileceğiniz bir temsilci arasındaki fark bunlar.

Benim için ajansal çalışma zamanının çok somut sorulara cevap vermesi gerekiyor:

• where do I save the state between one step and another?
• süreç yarı yolda ölürse ne olur?
• Duraklatıp onay isteyebilir miyim?
• neden bu seçimi yaptığını anlamak için bir koşuyu tekrar oynatabilir miyim?
• Süreyi, belleği, araçları ve maliyeti sınırlayabilir miyim?

Vercel, web uygulamalarındaki yapı aracılarına yönelik AI SDK'ları, işlevleri, iş akışları ve araçlarıyla bu alanda yoğun çaba harcıyor. Ancak mesele sadece Vercel değil. Önemli olan, aracının tek bir uç noktaya değil, operasyonel bir eve ihtiyacı olmasıdır.

İkinci parça: sandbox, çünkü aracının kırılmadan kirlenebilmesi gerekiyor

Bir aracı kod yazdığında veya komutları yürüttüğünde bir sanal alana ihtiyaç duyulur.

Teknik bir kelime gibi görünüyor ama fikir çok yerel: Ona bir çalışma tezgahı veriyorsunuz. Dosyaları açabilir, bağımlılıkları yükleyebilir, testler çalıştırabilir, deneyler yapabilir, çıktı üretebilir. Eğer yanlış anlarsa, hasarı kontrol altına almış olursunuz. If it works, promote the result.

Ajansal bir sanal alanın bazı özelliklere sahip olması gerekir:

• yalıtılmış dosya sistemi;
• CPU, bellek ve zaman sınırları;
• kontrollü ağ;
• yalnızca ihtiyaç duyulduğunda saklanan sırlar;
• günlükleri tamamlayın;
• eserleri ihraç etme imkanı;
• gerektiğinde çalıştırmalar arasında temiz sıfırlama.

Vercel Sandbox tam olarak bu yönde ilerliyor: her şeyi ana uygulama çalışma zamanında çalıştırmadan kod çalıştırmak, bağımlılıklar yüklemek, dosyalarla çalışmak ve yapılar üretmek için yalıtılmış ortamlar.

Bu şey göründüğünden daha önemli. Birçok etken prototip, doğrudan modelden gerçek sisteme atlar. Model aracı çağırabilir. Araçlar bir şeyler yapabilir. İlk yanlış komuta, ilk bağımlılığın yanlış yere kurulmasına, bir günlüğe yazılan ilk jetona kadar her şey zarif görünüyor.

Korumalı alan, yetişkinlerin şunu söyleme şeklidir: Devam et, ama burada.

Üçüncü parça: MCP ve konektör sorunu

Model Bağlamı Protokolü, ekosistemin en ilginç parçalarından biri haline geldi çünkü normalde hızla yönetilemez hale gelen bir şeyi standartlaştırmaya çalışıyor: bir modelin harici araçları nasıl keşfedip kullandığını.

Standart olmadan her entegrasyon küçük bir adadır. GitHub için bir bağlayıcı bir şekilde yapıldı, biri Slack için diğeri yapıldı, biri farklı semantiklere sahip veritabanları için, biri hiçbir şeye benzemeyen tarayıcı otomasyonu için yapıldı.

MCP, istemci ve sunucu arasında ortak bir dil önerir: araçlar, kaynaklar, istemler, yetkilendirmeler, aktarım, keşif. Yönetişimi ve güvenliği sihirli bir şekilde çözmez, ancak bir dilbilgisi sağlar.

Ve gramer önemlidir. Bir aracı birçok araca bağlanabildiğinde soru yalnızca "bunu yapabilir mi?" değildir. Sorun "neyi, hangi sınırlarla, kimin adına yapabileceğini, nasıl bir iz bırakabileceğini anlıyor mu?"

Benim için MCP abartılı değil çünkü "araç çağırma yapıyor". Bunu zaten yaptık. Bu bir heyecan çünkü ağırlık merkezini tek entegrasyondan operasyonel araç kataloğuna kaydırıyor.

İyi bir etmensel mimaride MCP bir tür bağlantı paneli haline gelir:

• Kod ve sorunlar için GitHub;
• Konuşma bağlamı için gevşeklik;
• Planlı çalışma için Doğrusal veya Jira;
• analitik için salt okunur veritabanı;
• harici siteler için kontrol edilen tarayıcı veya kazıyıcı;
• belge saklama;
• yalıtılmış yürütme ortamları;
• katı izinlere sahip dahili sistemler.

İşin zor kısmı, politikasız bir araç kataloğunun kaos yaratmanın daha zarif bir yolu olmasıdır.

Dördüncü parça: kimlik ve izinler

Burası birçok demonun görmezden geldiği alandır.

Bir temsilci, birisi adına hareket eder. Yani eylemin konusunun kim olduğu açık olmalıdır.

Kullanıcı izinlerini kullanıyor mu? Bir hizmet hesabından mı? Bir çalışma alanından mı? Geçici veya kalıcı erişiminiz var mı? Her şeyi okuyabiliyor musun, yoksa sadece bazı kaynakları mı? Yazabilir misin? İptal edebilir misin? Gerçek insanlara mesaj atabilir mi?

Bu sorulara iyi cevap vermezseniz, er ya da geç ev anahtarlarına sahip olan ve bunları ona kimin verdiğini hatırlamayan bir asistan yaratacaksınız.

Benim hoşuma giden genel kural şudur: Aracı insandan daha azını yapabilmelidir, insandan daha fazlasını değil. Daha riskli bir şey yapması gerektiğinde durup sorması gerekiyor.

Bu, OAuth, jeton kapsamlı, gizli yönetim, denetim günlüğü, araç politikası, izin verilenler listesi, onay adımı anlamına gelir. Pek romantik şeyler değil. Gerekli şeyler.

Beşinci parça: bellek ve bağlam, ancak çöp biriktirmeden

Ajanların hafızaya ihtiyacı vardır ama hafıza tavan arasına dönüştüğünde tehlikelidir.

En az üç tür bellek vardır:

• belleği çalıştır: bu yürütmede ne oldu;
• proje hafızası: gelenekler, kararlar, kısıtlamalar;
• kişisel veya takım hafızası: tercihler, üslup, ritüeller, süreçler.

Her şeyi komut istemine koymak kısayoldur. Artık çalışmayana kadar çalışır. Yararlı hafızaya dikkat edilmelidir: indekslenmeli, güncellenmeli, süresi dolmalı, doğrulanmalı, alıntı yapılabilir hale getirilmelidir.

Kötü hatırlayan bir ajan, hatırlamayan bir ajandan daha kötüdür. Çünkü güvenle konuşuyor.

Bu nedenle altyapının, erişim, talimat dosyaları, bilgi tabanı, gerektiğinde yerleştirme ve aynı zamanda temizlemeyi içermesi gerekir. Bir hafıza kültürüne ihtiyacımız var: Ne girer, kim onaylar, bozulduğunda nasıl düzeltirim.

Altıncı parça: gözlemlenebilirlik, değerlendirme ve tekrar oynatma

Bir aracı hata yaparsa "model adı verilen" günlüğü yeterli değildir.

Rotayı görmek istiyorsunuz. Hangi bağlamı aldı? Hangi araçlar mevcuttu? Hangi aracı seçtiniz? Hangi argümanlarla? Nasıl bir yanıt aldınız? Ne kadara mal oldu? Nerede sıkıştı? İnsan herhangi bir şeyi onayladı mı? Hata modeli, araç, bilgi istemi, veri veya izin hatası mı?

Burada aracılar sohbet robotlarından ziyade dağıtılmış sistemlere benziyor.

Yalnızca metin günlüklerine değil, okunabilir izlere de ihtiyacınız var. Bir koşuyu tekrar oynatabilmeniz gerekir. Aynı aracının iki versiyonunu bilinen görevlerde karşılaştırmak gerekir. Regresyonları ölçmemiz gerekiyor: yalnızca "daha iyi yanıt vermek"le kalmıyor, aynı zamanda "istenmeyen dosyalara dokunmadan doğru bileti kapatıyor".

Eylemli değerlendirmeler, eylemleri içerdikleri için metin değerlendirmelerinden daha zordur. Beklenen bir dizeyi karşılaştırmak yeterli değildir. Sıralara, yan etkilere, eserin kalitesine, zamana, maliyete, insan müdahalelerinin sayısına bakmalısınız.

İşin komik yanı, her zaman oraya dönüyoruz: yazılım mühendisliği. Testler, ortamlar, izlemeler, geri almalar. Bunun dışında kod artık bundan sonra ne yapılacağına da karar veriyor.

Yedinci parça: insan arayüzleri

Temsilcinin sadece sohbet içinde yaşaması gerekmez.

Bazı ajanların bir kurula ihtiyacı vardır. Diğerleri durum ve günlüğün bulunduğu bir sayfa. Diğerleri "onayla" butonudur. Daha fazla satır içi yorum. Hala bir CLI'nin diğerleri.

Kullanıcı arayüzü davranışı değiştirir. Bir temsilciyi kontrol etmenin tek yolu uzun bir mesaj yazmaksa, kullanıcı temsilciye belirsiz talimatlar verecektir. Ancak planı, farkı, kaynakları, riskleri ve bir sonraki hamleyi görürse tam olarak müdahale edebilir.

İyi bir aracı altyapısı kontrol yüzeylerini içerir:

• mevcut durum;
• düzenlenebilir plan;
• üretilen eserler;
• fark;
• onay talepleri;
• kronoloji;
• durdur düğmesi;
• yeniden dene düğmesi;
• görünür izinler.

Önemsiz görünüyor, ama değil. "Korkunç yapay zeka" ile "güvenilir asistan" arasındaki fark genellikle ikincisinin size elindekilerin nerede olduğunu göstermesidir.

Zihinsel yığın

Eğer bugün çizecek olsaydım minimum temsilci yığını şu şekilde olurdu:

1. Model: akıl yürütme, oluşturma, araç çağırma, gerekirse çok modlu.
2. Düzenleme: döngü, adım, planlayıcı, politika, döngüdeki insan.
3. Dayanıklı çalışma zamanı: iş akışı, kuyruk, yeniden deneme, duraklatma, devam ettirme.
4. Sandbox: kod yürütme, yalıtılmış dosya sistemi, sınırlamalar, yapılar.
5. Araç katmanı: MCP, dahili API, tarayıcı, veritabanı, depo.
6. Kimlik katmanı: OAuth, kapsam, sır, denetim, politika.
7. Bellek katmanı: proje bağlamı, erişim, talimatlar, sona erme.
8. Gözlemlenebilirlik: izleme, tekrar oynatma, değerlendirme, maliyet ve kalite ölçümleri.
9. Ürün yüzeyi: Yeterli olduğunda sohbet edin, gerektiğinde kontrol panelini kullanın, önemli olduğunda inceleyin.

Failsel çerçeve esas olarak 2. noktayı ve 1. noktanın bir kısmını kapsar. Gerisi asıl çalışmadır.

Pratikte ne yapardım

Bir ekip bana "üretimde temsilci istiyoruz" derse on temsilciyle başlamazdım.

Küçük, tekrarlayan ve gözlemlenebilir bir iş akışıyla başlardım. Örneğin: bakım PR'lerini açın, kapatılan sorunların belgelerini güncelleyin, haftalık bir inceleme hazırlayın, yinelenen hataların önceliklerini belirleyin, etkilenen dosyalar için testler oluşturun.

O zaman çok net sınırlar koyardım:

• dallar veya sanal alan olmadan yazı yazmak yasaktır;
• istemde sır yok;
• izin verilenler listesindeki araçlar;
• dış eylemler için insan onayı;
• zorunlu kayıt ve izleme;
• çalıştırma başına bütçe;
• çıktı her zaman denetlenebilir.

Ancak o zaman genişleyebilirim.

Ajanlar sırf modeller yanlış anladığı için başarısız olmazlar. Başarısız oluyorlar çünkü onları kafa karıştırıcı izinler ve teatral beklentilerle belirsiz ortamlara koyuyoruz.

Okumalarım

Acente altyapısı en iyi şekilde sıkıcıdır.

Demoda sizi alkışlayan kısım değil. Bu, demoyu Pazartesi sabahı gerçek kişilerle, gerçek verilerle ve gerçek sonuçlarla gerçekten kullanmanızı sağlayan kısımdır.

Temsilcilerin geleceğine yalnızca kimin en iyi rol modele sahip olduğuna karar verilmeyecek. Kimin çalışabileceği en iyi yeri inşa edeceğine karar verecek: Deney yaparken izole, ihtiyaç duyulduğunda bağlantı kuran, her zaman gözlemlenebilir, kriterlerle yetkilendirilmiş ve bilmediğinde duracak kadar alçakgönüllü.

Ajanların oyuncak olmayı bırakıp altyapı haline geldiği yer burasıdır.

Kaynaklar

• Vercel: Vercel ve AI SDK ile AI aracıları nasıl oluşturulur
• Vercel Dokümanları: Korumalı Alan
• Vercel Dokümanları: Sandbox ile Çalışmak
• Vercel Dokümanları: MCP
• Model Bağlamı Protokolü: Belirtim
• OpenAI: İnşaat acenteleri için yeni araçlar
• Cloudflare Blogu: Cloudflare'deki Aracılar