Ajan Asistanları: Güvenli Takvim ve Gmail Entegrasyonları

Benim iddiam: takvimlerde, Gmail'de ve bağlı uygulamalarda hareket eden güvenli, kullanılabilir ajan asistanları inşa etmek, izin öncelikli bir çalışma zamanı tasarımını gerektirir, planlama ile harekete geçmeyi ayırmak ve yürütme katmanına denetim ve geri alma akışlarını ilk günden entegre etmektir. Bu makale, buna ulaşmak için sıkı bir mühendislik kontrol listesi ve çalıştırılabilir komutlar sunmaktadır.

AJAN ASISTANLARI İÇİN İZİN TASARIMI

Kullanıcı başına OAuth ve en az ayrıcalık kapsamları ile başlayın. Bir yönetici açıkça domain devri gerektirmedikçe, kullanıcıya bağlı OAuth kullanın, paylaşılan bir hizmet hesabı yerine. Google’ın ayrıntılı kapsamlar üzerindeki belgeleri temel alandır; her ajan yeteneğini tek bir OAuth kapsamına eşleyin ve o kapsam için insan tarafından okunabilir niyeti belgeleyin. Belirteçleri komutlardan uzak tutun. Onları bir kasada saklayın ve yalnızca çağrı zamanında, politika uygulayan bir yürütme hizmetinin içinde kimlik bilgilerini enjekte edin.

İzinleri ürün UX'i olarak ele alan takımların, net onay işlemleri ve kapsam önizlemeleriyle, çok daha az destek talebi aldığını gözlemledik. Karşılaştığımız bir sorun, naif yenileme mantığından dolayı belirteçlerin çoğalmasıydı; yenileme işlemini merkezileştirin ve yenileme belirteçlerini düzenli olarak döndürün.

PLANLAMA VE HAREKET

Asistanı bir planlayıcı ve bir hareket ettiriciye ayırın. Planlayıcı, belirli bir eylem planı üretir: son dizileri okumak, iki toplantı zamanı önermek, bir taslak e-posta oluşturmak. Hareket ettirici yalnızca bir politika kontrolünden sonra ve hassas eylemler için bir insan onay adımından sonra harekete geçer. Bu model, yetkili işlemler konusunda doğaçlama yapılmasını engeller ve yetkilendirmeyi denetlenebilir hale getirir.

Pratik bir denge: insan onayı için uzun gecikme karşısında daha düşük risk. Birçok takvim ve e-posta işlemi için 30 ila 60 saniyelik insan-akışta bir bekleyiş kabul edilebilir. Yüksek frekanslı görevler için, toplu onaylar her bir eylem tıklamasından daha iyi çalışır.

TESTLER, KAYITLAR VE İYİLEŞTİRME

Her eylem, talep edilen niyeti, planlayıcı çıktısını, politika kararını, aktör çağrısını ve dönen API yanıtını içeren değiştirilemez bir denetim girişi üretmelidir. Tekrar oynatılabilir bir komut formatı tutun, böylece geri alabilir ve geri dönebilirsiniz. Son N eylem için tek tıklamayla geri alma ve örneğin bir etkinliği iptal etme ve düzeltici bir takip gönderme gibi telafi eden olaylar oluşturacak bir geri kazanım akışı sağlayın.

İletim düzeyindeki korumaların harici bir politika motoru olmadan başarısız olduğunu gözlemledik. Pratikte, modeller makul görünen ancak politikayı ihlal eden değişiklikler önerir. Güvenin kalibre edilmiş bir eşiğin altında olduğu durumlarda yazma eylemini reddeden bir yürütme kapısı, bu olayları azaltır.

ÜRÜN VE MÜHENDİSLİK İÇİN KONTROL LİSTESİ

1. Kullanıcı başına en az kapsamlı OAuth ve net onay metni. 2. Kimlik bilgilerini çalışma zamanında enjekte eden token kasası ve yürütme hizmeti. 3. Politika kontrolleri ile planlayıcı/hareket ettirici ayrımı. 4. Hassas eylemler için insan-akışında yükseltme. 5. Değiştirilemez denetim kayıtları ve tekrar oynatılabilir eylem formatı. 6. Açık UI olanakları ile geri alma ve telafi akışları.

Ürün UX'inizi İnsan-AI iş akışlarını Tasarlama ve AI ajanları ve chatbotlar üzerindeki ajans farklılıkları primeri ile tanımlanan iş akışı desenlerine bağlayın.

Kendiniz deneyin. Aşağıdaki komutlar, planlayıcı çıktısının hareket ettirici-güvenli talimatlarla karşılaştırıldığını gösterir. Planlayıcıdan kısa, öz JSON benzeri planlar ve aktörden kısa onaylar bekleyin.

Bu komut, modelin aday toplantı zamanlarının kısıtlı bir planını ve bir mantığını üretmesini ister; bunu planlayıcı olarak kullanın. 2 ila 3 aday slot ve bir cümlelik mantık bekleyin.

Bir toplantı planlayıcısınız. Kullanıcının bugünün 3 boş slotu var: 10:00, 14:30, 16:00. ISO formatında tam olarak üç aday toplantı zamanını, her biri için bir cümlelik mantıkla ve davetin dış e-postaları kapsayıp kapsamadığını söyleyen bir cümlelik gizlilik notu ile iade edin.

Bu komut ise hareket ettirici içindir. Bir insan-onay tokeni ve bir planlayıcı planı ile etkinliği yalnızca policy_check(policy_id:calendar_write) başarıyla dönerse oluşturmasını bekler.

Hareket Ettirici: Kullanıcı onay tokeni X ve planlayıcı planı Y verildiğinde, Calendar.CreateEvent'i yalnızca policy_check(policy_id:calendar_write) başarıyla dönüş yaparsa {start,end,attendees,summary} alanları ile çağırın. Eğer policy_check başarısız olursa, başarısızlık kodunu ve gerekli insan eylemini döndürün.

Bir karşı argüman, katı kontrollerin benimsenmeyi yavaşlattığıdır. Takımlar bu desenleri uyguladıklarında, erken kullanıcı tutumu iyileşiyor çünkü güven artıyor, başlangıç aktivasyonu daha yavaş olsa bile. Denge nettir: bu kontroller olmadan daha hızlı yayılma ölçülebilir risk ve daha yüksek düzeltme maliyetleri yaratır.