Konteynerler hasar yarıçapını sınırlar, davranışı değil
Ekipler bir agent'ı ilk kez sandbox'a aldığında, konuşma genellikle izolasyon teknolojisiyle başlar. Firecracker microVM'ler, gVisor, seccomp profilleri, cgroup limitleri, salt okunur kök dosya sistemleri. Bunlar gerçek ve faydalıdır, ancak çoğu insanın varsaydığından daha dar bir soruyu yanıtlarlar. Hasarın nereye düşebileceğini sınırlarlar. Agent'ın neyi denemesine izin verildiğini sınırlamazlar.
Host ağ namespace'ini paylaşan bir sandbox, sorunun ilginç kısmını zaten kabul etmiştir. Agent hâlâ iç metadata servisine, paket kayıt defterine, model sağlayıcısına, şirket wiki'sine ve host'un IP'sine güvenen herhangi bir servise erişebilir. Dosya sistemi izolasyonu, gerçek yetenek yüzeyi giden HTTP artı bir dizi API kimlik bilgisi olan bir agent'ı kısıtlamaz. Kök dosya sistemini salt okunur bağlayabilir ve yine de agent'ın izin verilen bir çıkış yolu üzerinden bir veritabanını sızdırdığını izleyebilirsiniz, çünkü önemli olan yetenek hiçbir zaman dosya tanımlayıcısı değildi. O token'dı.
Bu yüzden konteyner öncelikli çerçeveleme, titiz görünen ve izin verici davranan sandbox'lar üretme eğilimindedir. Analiz birimi yanlıştır. Faydalı birim, adım başına yetenek kümesidir ve bu küme çalıştırma ilerledikçe değişir.
Tasarım ilkesi olarak yetenek bütçesi
Etrafında inşa etmeye değer tasarım ilkesi, bir çalıştırmanın her adımına bağlı bir yetenek bütçesidir. Bir adım, sınırlı bir iş birimidir: bir tool call, bir model turu, bir tarayıcı gezinmesi, bir aktüatör komutu. Her adım ihtiyaç duyduğu yetenekleri bildirir. Runtime, tam olarak bu yetenekleri adımın süresi boyunca verir ve daha fazlasını vermez.
Somut bir mekanizma şöyle görünür. Orkestratör bir politika motoru ve kısa ömürlü bir kimlik bilgisi broker'ı tutar. Bir adım yürütülmeden önce, agent bir yetenek talebi gönderir: kaynağı, işlemi ve amaçlanan kapsamı adlandıran yapılandırılmış bir belge.
{
"step": "fetch_invoice_pdf",
"capabilities": [
{"type": "http", "host": "billing.internal", "methods": ["GET"], "paths": ["/invoices/*/pdf"]},
{"type": "fs", "mount": "/tmp/run-7f3a", "mode": "write"}
],
"ttl_seconds": 30
}
Politika motoru talebi, çalıştırmanın birikmiş bütçesine ve görevin bildirilen kapsamına göre değerlendirir. Geçerse, broker o host, method ve path'e kapsanmış, saniye cinsinden ölçülen bir TTL'ye sahip bir kimlik bilgisi üretir. Adım yürütülür. Kimlik bilgisi sona erer. Sonraki adım sıfırdan başlar ve yeniden sormak zorundadır.
Yükseltme ilginç durumdur. Bir adım mevcut bütçenin dışında bir şeye ihtiyaç duyduğunda, açık bir yükseltme talebi dosyalamalıdır. Bu talep kendisi, ekli bir politika kararıyla birlikte kaydedilmiş bir olaydır: kim veya ne onayladı, hangi kural altında, hangi son kullanma tarihiyle. Bu, ayrıcalık sürünmesini sessiz bir kaymadan denetlenebilir bir diziye dönüştürür. Ayrıca çalıştırmanın yetenek geçmişini birinci sınıf bir artefakt haline getirir; kırkıncı adımda bir şeyler ters gittiğinde gerçekte istediğiniz şey budur.
İptal, çalıştırma sırasında mümkün olmalıdır. Bu, görev başlangıcında üretilen uzun ömürlü token'ları dışlayan kısıttır. Agent'ın elinde tuttuğu tek kimlik bilgisi bir saat ömürlü, göreve kapsanmış bir bearer token ise, runtime agent'ın davranışı kaydığında, görevin öncülü yanlış çıktığında veya bir insan bir sorun fark ettiğinde yetkiyi geri çekemez. Kısa ömürlü, adıma kapsanmış kimlik bilgileri, iptali yenilememe meselesi haline getirir. Bu, bir düzine servis arasında zaten uçuşta olan bir token'ı geçersiz kılmaya çalışmaktan çok daha küçük ve güvenilir bir işlemdir.
Ödünleşim gerçektir ve açıkça belirtilmeye değer. Adıma kapsanmış kimlik bilgileri token değişimlerinin sayısını çoğaltır, kritik yola bir broker ekler ve tek bir uzun ömürlü token'ın sahip olmadığı gecikme ve hata modlarını getirir. Artık her adım broker'ın mevcut olmasına ve politika motorunun doğru olmasına bağlıdır. Bu deseni benimseyen ekipler bunun bedelini operasyonel karmaşıklıkla öder ve görevin risk profilinin bu maliyeti haklı çıkarıp çıkarmadığına bilinçli olarak karar vermelidirler. Kamu verileri üzerinde salt okunur bir özetleme agent'ı için genellikle haklı çıkarmaz. Üretim sistemlerine yazma erişimi olan bir agent için genellikle haklı çıkarır.
Tarayıcı ve masaüstü agent'ları
Tarayıcı ve masaüstü agent'ları, yapıları gereği geniş ortam yetkisine sahiptir. Bir tarayıcı sürücüsü herhangi bir şeye tıklayabilir, herhangi bir yere yazabilir ve oturumun cookie'lerinin izin verdiği her yere gidebilir. Bir masaüstü agent'ı genellikle daha fazlasını yapabilir. Yetenek bütçesi konteyner tarafından uygulanamaz, çünkü konteyner tam bir ortam kimlik bilgileri kümesine sahip tam bir kullanıcı oturumunu barındırmaktadır. Sürücü katmanında uygulanmalıdır.
Pratikte bu, sürücünün gezinmeyi, form gönderimini, dosya indirmeyi, pano erişimini ve bir güven sınırını geçen herhangi bir çağrıyı yakaladığı ve her birini mevcut adımın bildirilen yeteneklerine göre kontrol ettiği anlamına gelir. "Fiyatlandırma sayfasını oku" diye bildiren bir adım, DOM bir form sunsa bile bir form gönderememelidir. Bu sürücü düzeyinde bir politikadır ve kontrolün anlamlı olduğu tek katmandır, çünkü eylemi gerçekte gerçekleştiren katman odur.
Fiziksel ve robotik agent'lar
Fiziksel agent'lar, yazılım sandbox'larının sahip olmadığı ikinci bir bütçe boyutu ekler: hareket zarfı ve kuvvet limitleri. Bir robotik kolun yetenek kümesi yalnızca hangi API'yi çağırabileceğini değil, nereye hareket edebileceğini, ne kadar hızlı ve ne kadar kuvvetle hareket edebileceğini de içerir. Bu limitler denetleyici tarafından uygulanır ve aynı şekilde adım başına kapsanmalıdır. "A kutusundan nesne al" diye bildiren bir adım, B kutusunu dışlayan bir hareket zarfı ve nesne sınıfına uygun bir kuvvet tavanı taşımalıdır. Daha geniş bir zarfa yükseltme, tıpkı ağ yeteneklerinde olduğu gibi, kaydedilmiş bir politika kararıdır.
Bunun önemi, hata modlarının geri döndürülemez olmasıdır. İptal edilen bir HTTP token'ı bir veri sızıntısını durdurur. İptal edilen bir hareket zarfı bir kolu yörünge ortasında durdurur; bu, yavaşlama profilleri ve güvenli durumları içeren farklı bir mühendislik problemidir. Yetenek modeli aynıdır; iptal semantiği değildir.
Değerlendirme harness'ları
Değerlendirme harness'ları, üretimle aynı yetenek uygulamasını çalıştırmalıdır, yoksa test sonucu kanıt değildir. Bu, en sık atlanan adımdır ve değerlendirmenin değerini en çok baltalayan adımdır. Harness agent'a üretim yeteneklerinin bir üst kümesini verirse, agent'ın ölçülen başarı oranı var olmayan bir sistemi yansıtır. Harness bir alt küme uygularsa, agent üretimde geçeceği görevlerde başarısız görünür.
Doğru desen, harness'ı üretimin kullandığı aynı politika motoruna ve aynı broker'a karşı, aynı yetenek bildirimleriyle çalıştırmak ve politika redlerini altyapı gürültüsü yerine birinci sınıf değerlendirme sonuçları olarak ele almaktır. Bir görevi üç kez yükselterek tamamlayan bir agent, onu bütçe içinde tamamlayandan farklı davranmaktadır ve harness hangisinin olduğunu size söyleyebilmelidir.
Bunun değiştirdiği şey
Konteyner sorusu ortadan kalkmaz. İzolasyon teknolojisi, bir yetenek kontrolü başarısız olduğunda ve agent yine de beklenmedik bir şey yaptığında ne olacağını hâlâ belirler. Derinlemesine savunma meselenin özüdür. Ancak konteyner ikinci hattır, birinci değil. Birinci hat, adım başına bildirilen, o adımın süresi boyunca verilen, yalnızca kaydedilmiş politika kararlarıyla yükseltilen ve çalıştırma hâlâ devam ederken iptal edilebilen bir yetenek bütçesidir.
Konteynerle başlayan ekipler, teknik olarak etkileyici ve operasyonel olarak izin verici bir sandbox'la sonuçlanma eğilimindedir, çünkü yetenek yüzeyi hiç numaralandırılmamıştır. Yetenek bütçesiyle başlayan ekipler, agent'ın her anda ne yapabileceğine dair net bir resme ve tüm probleme değil artık riske göre boyutlandırılmış bir konteynere sahip olurlar. İkinci sıralama, başlangıçta daha fazla iş ve bir olay sırasında önemli ölçüde daha az iştir.