Tüm kaynaklar

BatonX / Açıklama

Model gateway’ler neden tek başına yerel ajan çalışmasını yönetemez?

Model isteklerini yönetmekle, kodlama ajanının tüm çalışma oturumunu yönetmek arasındaki farkı anlayın.

Tek ajan. İki kontrol yolu.

Oturum yönetişimi

Kodlama ajanı

Model istekleri

Model gateway

Yönlendirme · kimlik bilgileri · kullanım limitleri

Onaylı model

Yerel işlemler

Çalışma ortamı
  • Dosyalar ve repository’ler
  • Komutlar ve süreçler
  • Ağ ve araçlar

Yetkilendirme · izolasyon · politika · onaylar · denetim

Kavramsal gösterim · Model trafiği ve yerel işlemler, kendi sınırlarında uygulanan kontroller gerektirir.

Bir kodlama ajanı yalnızca modele soru göndermez. Dosyaları okur ve değiştirir, terminal komutları çalıştırır, testleri yürütür ve harici araçlara bağlanabilir. Model çağrıları, bu çalışma sürecinin yalnızca bir parçasıdır.

Model gateway, ajan ile model sağlayıcısı arasındaki istekleri yönetir. Ajanın çalıştığı ortamda neler yapabileceğini kontrol etmek ise ayrı bir güvenlik ve yönetişim katmanı gerektirir.

Model gateway neyi yönetir?

Kullanılan ürüne ve yapılandırmaya bağlı olarak bir model gateway:

  • İstekleri izin verilen model ve sağlayıcılara yönlendirebilir.
  • Model erişimini doğrulayabilir ve sağlayıcı kimlik bilgilerini merkezi olarak yönetebilir.
  • İstek, token ve maliyet limitleri uygulayabilir.
  • Gecikmeleri, hataları ve model kullanımını kaydedebilir.
  • Üzerinden geçen istek ve yanıtları belirli kurallara göre değerlendirebilir.

Bunlar kurumsal AI kullanımının önemli kontrolleridir. Ancak kapsamları, gateway üzerinden geçen trafik ve ona bağlı entegrasyonlarla sınırlıdır.

Yerel işlemler neden farklıdır?

Model bir dosyanın okunmasını veya bir komutun çalıştırılmasını önerebilir. Bu işlemi gerçekleştiren bileşen, ajanın yerel araçları ve çalışma ortamıdır.

Gateway, model yanıtındaki araç çağrısını görebilse bile bu, işletim sistemindeki işlemi kontrol ettiği anlamına gelmez. Tek başına bir model proxy’si:

  • Ajanın yetkili çalışma alanı dışındaki dosyaları okumasını engellemez.
  • Terminal komutlarının hangi izinlerle çalışacağını belirlemez.
  • Başlatılan alt süreçlerin erişimini sınırlandırmaz.
  • Model API’si dışındaki ağ bağlantılarını denetlemez.
  • Yerel işlemlerin gerçekten gerçekleştiğini ve sonuçlarını bağımsız olarak doğrulamaz.

Bu kontrollerin, işlemlerin gerçekleştiği ortamda uygulanması gerekir.

Bir örnek: “Bu projeyi incele ve testleri çalıştır”

Ajan bu görev sırasında kaynak dosyalarını okuyabilir, bağımlılıkları kontrol edebilir ve test komutlarını çalıştırabilir.

Gateway, bu süreçte yapılan model çağrısının onaylı bir modele gittiğini ve kullanım limitlerine uyduğunu denetleyebilir.

Ancak ayrı çalışma ortamı kontrolleri yoksa aynı ajan veya başlattığı bir süreç, erişim izinleri ölçüsünde proje dışındaki bir dosyayı okumayı ya da harici bir adrese bağlanmayı deneyebilir. Bu işlemler model gateway’inden geçmek zorunda değildir.

Benzer şekilde, yeni model isteklerini engellemek, hâlihazırda çalışan yerel bir süreci otomatik olarak durdurmaz.

Tam bir oturumu yönetmek ne gerektirir?

Oturum düzeyinde yönetim; kullanıcı ve repository yetkilendirmesini, dosya sistemi izolasyonunu, komut izinlerini, ağ kısıtlarını ve oturumun durdurulmasını birlikte ele alır.

Denetim kayıtları da yalnızca model çağrılarını değil; ilgili politika kararlarını, onayları ve çalışma ortamından gelen işlem sonuçlarını ilişkilendirmelidir. Bu, tüm kaynak kodunun veya hassas içeriklerin kaydedilmesini gerektirmez.

Ajanın kendi izin ve sandbox özellikleri bu yapıya katkı sağlayabilir. Kurumsal ihtiyaç, bu kontrollerin merkezi politikalarla tutarlı biçimde uygulanmasıdır.

BatonX’in yaklaşımı

BatonX, model erişimi kontrollerini yetkilendirilmiş repository erişimi, izole çalışma ortamı, komut ve ağ politikaları ve oturum denetimiyle bir araya getirecek şekilde tasarlanmaktadır.

Hedef, geliştiricinin alıştığı ajan deneyimini mümkün olduğunca korurken kurumun belirlediği sınırları teknik olarak uygulamaktır.

Tüm kaynaklar