Bir ajan sistemi nasıl kurulur ve kontrol nerede durmalı

Ajan mimarisi şemaları genellikle ortaya bir model koyar ve geri kalan her şeye ok çizer. Bu resim mühendisliğin büyük kısmını gizler. Model, kendiniz geliştirme ihtimalinizin en düşük, değiştirme ihtimalinizin ise en yüksek olduğu parçadır. Bir ajan sisteminin güvenilir olup olmadığını onu çevreleyen yazılım belirler: döngünün nasıl işlediği, araçların nasıl sunulduğu, neyin hatırlandığı, kanıtın nerede tutulduğu, bir insanın nerede onay verdiği ve neyin kayda geçtiği. Bu yazı bu bileşenleri, sistemlerin çoğunun üzerine kurulduğu birkaç kalıbı, web erişiminin nereye bağlandığını ve en önemli kararı ele alıyor: kontrolün nerede durduğunu.

Bir ajan sisteminin altı bileşeni

Parçaların birbirine nasıl bağlandığı, parçaların kendisi kadar önemlidir:

istek        -> döngü: planla, uygula, gözlemle
döngü        -> politika kontrolü -> (sonuç doğuruyorsa onay kapısı) -> araç yürütücüsü
araç         -> kanıt deposu (pasaj, kaynak, erişim zamanı)
döngü        -> bellek (öneriler, kapsamlı)
her adım     -> denetim izi (yalnızca ekleme)

Döngünün içi

Döngünün her turu bağlamı kurar (hedef, kısıtlar, ilgili bellek ve o ana kadar olanlar), modelden sıradaki eylemi ister, bu eylemi bir şemaya göre doğrular, araç katmanı üzerinden yürütür ve gözlemi kaydeder. Döngüyü güvenilir kılan ayrıntılar modelin dışındadır:

• Durma koşulları. Hedefe ulaşılmıştır, ajan takılmıştır ve bunu söyler, bir bütçe dolmuştur ya da sıradaki adım bir karar gerektirir. Her biri ayrı ve görünür bir sonuç olmalıdır.
• Bütçeler. Süre, araç çağrısı sayısı ve harcama istemde rica edilmez; çalışma ortamı tarafından sayılır ve uygulanır.
• Yapılandırılmış eylemler. Araç çağrıları tipleri belli argümanlara ayrıştırılır; hatalı bir çağrı tahminle yürütülmek yerine reddedilir.
• Kalıcılık. Uzun işler, adımlar arasında durumu saklayarak yeniden başlatmalardan sağ çıkar. Kesintiye dayanıklı yürütme yoksa sistem ilerliyormuş gibi yapmak yerine bunu açıkça söylemelidir.

Araçlar ve politika sınırı

Her araç, şemasının yanında üç şeyi beyan etmelidir: ne tür bir yan etkisi olduğunu (okuma, yazma, gönderme, silme, dışa aktarma, zamanlama), hangi kimlik bilgisi kapsamına ihtiyaç duyduğunu ve hangi kaynaklara dokunabileceğini. Bu beyanlar sayesinde döngü ile yürütücü arasına bir politika kontrolü yerleşebilir ve her çağrıyı kendi koşullarına göre değerlendirir:

def execute(call, run):
    # her refuse() çağrısı da denetim izine yazılır
    kind = tools[call.name].effect          # okuma, yazma, gönderme, silme...
    if not run.scope.permits(call):
        return refuse(call, reason='kapsam dışı')
    if kind in CONSEQUENTIAL:
        decision = gate.ask(run, quote=call) # gözden geçiren çağrının birebir halini görür
        if not decision.covers(call):        # yürütme anında yeniden kontrol
            return refuse(call, reason=decision.reason)
    audit.append(run, call, kind)
    creds = vault.reference(run.scope)      # sunucu tarafında, istemde asla yok
    return tools[call.name].run(call.args, creds)

Bu taslağın kopyalanmaya değer üç özelliği var. Kontrol kodda yapılır; bu yüzden bağlamdaki hiçbir talimat onu ikna ederek aşamaz. Gözden geçiren kişi bekletilen çağrının bir özetini değil, birebir kendisini görür. Ve bir karar tek ve belirli bir çağrıyı kapsar; sistem “onaylandı” bilgisini genel bir ruh hali gibi hatırlamaz. MCP gibi protokoller araçların nasıl tanımlanıp çağrılacağını standartlaştırır ve bağlamayı kolaylaştırır. Ama belirli bir görevin belirli bir aracı kullanıp kullanamayacağına karar vermezler; bu, politika katmanının işidir.

Bellek ve kanıt ayrı depolardır

Ekipler çoğu zaman ajanın öğrendiği her şeyi tek bir yerde tutar. Bunu üçe ayırın:

• Çalışma bağlamı tek bir çalıştırma boyunca yaşar; sonunda atılır ya da özetlenir.
• Uzun süreli bellek çalıştırmalar arasında olguları ve tercihleri tutar. Her kaydın bir kapsamı (oturum, kullanıcı, proje ya da şirket), bir kaynağı, bir gerekçesi ve önerilmiş ya da onaylanmış bir durumu olmalıdır. Düzeltmeler yeni bir sürüm oluşturur. Bu modeli bellek dokümantasyonu daha ayrıntılı anlatıyor.
• Kanıt, ajanın getirdiği şeydir: kaynak referansı ve erişim zamanıyla birlikte, değiştirilmeden saklanan pasajlar. Bulgular bu depoya işaret eder.

Bellek ile kanıt karıştığında ajanın daha önce yazdığı bir özet kaynakmış gibi gösterilmeye başlar ve hangi iddiaların gerçekten kontrol edildiğini kimse ayırt edemez. Bunları ayrı tutmak tasarım aşamasında ucuzdur, sonradan eklemekse çok zordur.

Yaygın kalıplar

Araçlı tek ajanla başlayın ve başka bir kalıba ancak çözdüğü sorunu adlandırabildiğinizde geçin. Eklenen her ajan yeni bir bağlam devri demektir ve her devir, kapsamın ve kanıtın kaybolabileceği bir noktadır.

Web erişimi nereye oturur

“Web erişimi” dört farklı yeteneği kapsar ve bunlar farklı risk düzeylerine aittir:

• Arama. Bir sorgu girer, sıralanmış sonuçlar çıkar; genellikle bir web arama API’si üzerinden. Salt okunurdur ama sonuçlar güvenilmeyen metindir.
• Getirme ve çıkarma. Bir adres girer, sayfa içeriği ya da yapılandırılmış alanlar çıkar. Bu da salt okunurdur, bu da güvenilmezdir.
• Tarayıcı otomasyonu. Bir tarayıcı ajanı tıklar, yazar ve form gönderir. Canlı bir oturumda işlem yapabildiği için sonuç doğuran adımları onay kapısından geçmelidir.
• Tarama. Çok sayıda sayfadan sistematik veri toplama; genellikle robots dosyaları, istek hızı ve site koşulları için kendi kuralları olan ayrı bir hattır.

Dördünü de aynı politika kontrolünün arkasında birer araç olarak modelleyin ve web’e özgü birkaç kural ekleyin. Her göreve bir kaynak izin listesi verin ve boş bir listenin hiçbir kaynağa izin vermediğini kabul edin. Getirilen içeriği, ajan onun üzerinde akıl yürütmeden önce adresi ve erişim zamanıyla birlikte kanıt deposuna kaydedin. Sayfa içeriğinin ajanın talimatlarını ya da yetkilerini değiştirmesine asla izin vermeyin; “önceki talimatları unut” diyen bir sayfa yalnızca veridir. Bir adresi izin değil konum olarak görün: bir oturum açma ekranını geçmek açık bir yetki gerektirir.

Kontrol nerede durmalı

Bütün bölümlerden geçen ilke şudur: önemli kontroller modelin dışında, ajan çatısında ve eylemlerin gerçekleştiği sınırda yaşar. Pratik bir test, sistem istemini sildiğinizi hayal etmektir. Onunla birlikte kaybolan her güvenlik önlemi zaten hiçbir zaman güvenlik önlemi değildi.

• Kapsam, bütçeler ve durdurma kontrolü çalışma ortamı tarafından uygulanır.
• Kimlik bilgileri, modelin hiç görmediği sunucu tarafı referanslardır.
• Onaylar tek bir denemeye bağlıdır ve deneme yürütüldüğü anda yeniden kontrol edilir.
• Denetim izine yalnızca ekleme yapılır; retler ve reddedilen kararlar da izde yer alır. Hangi alanların kaydedilmesi gerektiğini bir ajan denetim izi neyi kaydetmeli yazısı ayrıntılandırıyor.
• Kurum sınırları kesindir: bir kuruluşta verilen karar başka bir kuruluşta hiçbir şeye yetki vermez.

Bu çevre katmanını bir bütün olarak ajan çatısı yazısı inceliyor.

Somut bir örnek olarak GoCux

GoCux bu kontrolleri her ajanın içine değil, ortak bir çalışma alanına yerleştirir. İş; hedefi, kapsamı ve kabul ölçütleri olan iş emirleriyle yürür. Yedi sonuç doğuran eylem sınıfı ekipten birinin kararını bekler; bekletilen çağrı ajanın yaptığı haliyle aynen gösterilir, verilen karar yalnızca o denemeyi kapsar ve yürütme anında yeniden kontrol edilir. Kimlik bilgileri sunucuda referans olarak kalır. İstekler, kararlar, araç çalıştırmaları ve sonuçlar tek bir iz oluşturur. Harcama, günlük bir tavanın altındaki görünür kredilerden düşer ve tek bir durdurma kontrolü yeni işi keser. MCP üzerinden bağlanan araçlar sizin uyumlu istemcinizde çalışır ve bir sunucuyu yapılandırmak, her görevin onu kullanmasına kendiliğinden izin vermez. Onay kapısını ve izi yönetişim sayfası, yedi eylem sınıfını ise ayrı bir yazı tek tek anlatıyor.

Mimari gözden geçirme kontrol listesi

• Döngü her nedenle (bitti, takıldı, sınır, karar) durabiliyor mu ve her durma ayrı olarak kaydediliyor mu?
• Her araç yan etki sınıfını, kimlik bilgisi kapsamını ve dokunduğu kaynakları beyan ediyor mu?
• Politika kontrolü kodda, döngü ile yürütücü arasında mı duruyor?
• Sonuç doğuran çağrılar, çağrının birebir hali gösterilerek duruyor mu ve onay yürütme anında yeniden kontrol ediliyor mu?
• Çalışma bağlamı, bellek ve kanıt ayrı depolarda mı; bellek kayıtları kapsamlı ve sürümlü mü?
• Her web aracı bir kaynak izin listesinin arkasında mı ve getirilen içerik kullanılmadan önce saklanıyor mu?
• Sayfa içeriği talimatları ya da yetkileri hiç değiştirebiliyor mu? Değiştirememeli.
• Denetim izi yalnızca başarıları değil, retleri ve reddedilen kararları da kaydediyor mu?
• Tek bir durdurma kontrolü var mı ve işi yeniden başlatmak bilinçli, arkasında adı belli bir kişi olan bir eylem mi?