Agentli köməkçilər: təhlükəsiz kalendər və Gmail inteqrasiyaları

Mənim iddiam: kalendərlərdə, Gmail-də və bağlı tətbiqlərdə fəaliyyət göstərən təhlükəsiz, istifadəyə yararlı agentli köməkçilər yaratmaq icazə-əsaslı iş mühiti dizayn etməyi, planlamanı hərəkətdən ayırmağı və icra qatına audit və geri çevirmək axınlarını birinci gündən daxil etməyi tələb edir. Bu məqalə oraya çatmağınıza kömək edəcək sıx mühəndislik yoxlama siyahısını və işlədilə bilən təşviqləri təqdim edir.

AGENTLİ KÖMƏKÇİLƏR ÜÇÜN İCAZƏ DİZAYNI

İstifadəçi-əsaslı OAuth və minimal icazə aralığı ilə başlayın. Administrator açıq şəkildə sahə səlahiyyəti tələb etmədikcə, paylaşılmış xidmət hesabı yerinə istifadəçi-əsaslı OAuth istifadə edin. Google-ın incə icazələr haqqında sənədləri əsasdır; hər bir agent qabiliyyətini tək bir OAuth icazəsi ilə haritalayın və həmin icazə üçün insan tərəfindən oxunaqlı məqsədi sənədləşdirin. Təşviqlərdə tokenləri saxlamayın. Onları bir vault-da saxlayın və yalnız icra xidmətinin içində, siyasəti tətbiq edən zaman girişlərinizi daxil edin.

Biz müşahidə etdik ki, icazələri məhsul UX kimi müalicə edən komandalar, açıq razılıq ekranları və icazə önizləmələri ilə, çox daha az dəstək bileti alırlar. Qarşılaşdığımız bir problem isə bəsit yeniləmə məntiqindən yaranan token yayılmasıdır; yeniləməni mərkəzləşdirin və yeniləmə tokenlərini mütəmadi olaraq dövrü edin.

PLANLAMA VERSUS HƏRƏKƏT

Köməkçini planlayıcıya və icraçıya ayırın. Planlayıcı ayrı bir fəaliyyət planı istehsal edir: son müzakirələri oxumaq, iki görüş vaxtı təklif etmək, bir layihə e-poçtu tərtib etmək. İcraçı yalnız siyasət yoxlamasından sonra və həssas fəaliyyətlər üçün insan təsdiq mərhələsindən sonra icra edir. Bu model, modelin səlahiyyətli əməliyyatları improvisasiya etməsinin qarşısını alır və icazəni audit oluna bilən edir.

Praktik ticarət: insan təsdiqi üçün daha uzun gecikmə ilə daha aşağı risk arasında seçim. Bir çox kalendər və e-poçt əməliyyatları üçün 30-dan 60-saniyəyə qədər insan iştirak edən dayandırma qəbul ediləndir. Yüksək tezlikli vəzifələr üçün, partiya təsdiqləri hər bir əməliyyata tıklamağın yerinə daha yaxşı işləyir.

TESTLƏR, GİZLİLİK VƏ BƏRPA

Hər bir fəaliyyət, tələb olunan məqsədi, planlayıcının çıxışını, siyasət qərarını, icraçı çağırışını və geri dönən API cavabını əhatə edən dəyişməz audit girişi istehsal etməlidir. Yenidən oynanabilir komanda formasını saxlayın ki, yenidən oynaya biləsiniz və geri döndərəsiniz. Son N fəaliyyət üçün bir kliklə ləğv etmə və müsbət hadisələr yaradan bir bərpa axını təqdim edin, məsələn, bir hadisəni ləğv etmək və düzəliş dəvətini göndərmək.

Biz müşahidə etdik ki, təşviq səviyyəsindəki qoruyucu çəpərlər xarici siyasət mühərriki olmadan uğursuz olur. Təcrübədə, modellər siyasəti pozan ama mümkün görünən dəyişikliklər təklif edir. İcra qapısı, etibar kalibre edilmiş bir həddin altında olduqda hər hansı bir yazmağı rədd edirsə, bu hadisələri azaldır.

MƏHSUL VƏ MÜHƏNDİSLİK ÜÇÜN YOXLAMA SİYAHISI

1. İstifadəçi-əsaslı OAuth minimal icazələrlə və açıq razılıq mətni. 2. Token vault və icra xidməti, girişləri işləmə vaxtında daxil edən. 3. Siyasət yoxlamaları ilə planlayıcı/icraçı ayrılması. 4. Həssas əməliyyatlar üçün insan müdaxiləsi artımı. 5. Dəyişməz audit qeydləri və yenidən oynana bilən fəaliyyət forması. 6. Aydın İT mühitləri ilə geri çevirmək və kompensasiya axınları.

Məhsul UX-ni İnsan-Aİ iş axınlarını dizayn etmək də təsvir edilən iş axınları ilə bağlayın və planlayıcı/icraçı ayrılmasını əsaslandırmaq üçün Aİ agentləri və çətir botları haqqında primerdən istifadə edin.

Özünüz sınayın. Aşağıdakı təşviqlər, planlayıcı çıxışının icraçıdan təhlükəsiz göstərişlərə qarşı müqayisəsini nümayiş etdirir. Planlayıcının sıxışdırılmış planından 2-3 namizəd vaxtı gözləyin və bir cümləlik əsaslandırma düzəldin.

Siz bir görüş planlayıcısınız. İstifadəçinin bu gün 3 sərbəst vaxtı var: 10:00 AM, 2:30 PM, 4:00 PM. Hər biri üçün bir cümləlik əsaslandırma ilə ISO formatında dəqiq üç namizəd görüş vaxtı qaytarın, və dəvətin xarici e-poçtlara təsir edib-etmədiyini bildirən cümləlik gizli nota əlavə edin.

Bu təşviq icraçıdır. O, insan təsdiq tokenini və hadisəni yaratmadan əvvəl açıq siyasət yoxlama keçidini gözləyir.

İcraçı: istifadəçi təsdiq tokeni X və planlayıcı plan Y verilmişdirsə, yalnız siyasət_yoxlama(policy_id:calendar_write) keçdiği halda Calendar.CreateEvent-də {start,end,attendees,summary} sahələrini çağırın. Siyasət yoxlama uğursuz olarsa, uğursuzluq kodunu və tələb olunan insan fəaliyyətini qaytarın.

Bir əks arqument sərt nəzarətlərin qəbulu yavaşlatacağıdır. Mənim qiymətləndirməm odur ki, komandalar bu nümunələri tətbiq edərkən, erkən istifadəçi saxlama səviyyəsi artır, çünki inam artmaqdadır, hətta ilkin aktivasiya daha yavaş olsa belə. Müqayisə aydındır: bu nəzarətlər olmadan daha sürətli yayım ölçülə bilən risk və daha yüksək geri dönüş xərcləri yaradır.