Asisten agensi: integrasi aman untuk kalender dan Gmail

Klaim saya: membangun asisten agensi yang aman dan dapat digunakan yang berfungsi pada kalender, Gmail, dan aplikasi terhubung memerlukan perancangan runtime yang memprioritaskan izin, memisahkan perencanaan dari tindakan, dan mengintegrasikan alur audit serta pengembalian sejak hari pertama. Artikel ini memberikan daftar periksa teknik yang padat dan prompt yang dapat dijalankan untuk mencapainya.

PERANCANGAN IZIN UNTUK ASISTEN AGENSI

Mulailah dengan OAuth per pengguna dan lingkup yang paling sedikit. Gunakan OAuth terikat pengguna daripada akun layanan bersama kecuali ketika administrator secara eksplisit membutuhkan delegasi domain. Dokumentasi Google tentang lingkup granular adalah dasar; pemetakan setiap kemampuan agen ke satu lingkup OAuth dan mendokumentasikan niat yang dapat dibaca manusia untuk lingkup tersebut. Jauhkan token dari prompt. Simpan dalam sebuah brankas dan injeksikan kredensial hanya saat waktu panggilan di dalam layanan eksekusi yang menegakkan kebijakan.

Kami mengamati bahwa tim yang memperlakukan izin sebagai UX produk, dengan layar persetujuan yang jelas dan pratinjau lingkup, mendapatkan jauh lebih sedikit tiket dukungan. Salah satu masalah yang kami temui adalah proliferasi token dari logika penyegaran yang naif; sentralisasi penyegaran dan rotasi token penyegaran secara teratur.

PERENCANAAN VS TINDAKAN

Pisahkan asisten menjadi perencana dan pelaksana. Perencana menghasilkan rencana aksi diskrit: membaca utas terbaru, mengusulkan dua waktu rapat, menyusun email draf. Pelaksana melakukan hanya setelah pemeriksaan kebijakan dan, untuk tindakan sensitif, langkah konfirmasi manusia. Pola ini mencegah model melakukan operasi dengan hak istimewa secara sembarangan dan membuat otorisasi dapat diaudit.

Pertukaran praktis: latensi lebih lama untuk persetujuan manusia versus risiko lebih rendah. Untuk banyak tindakan kalender dan email, jeda 30 hingga 60 detik dengan manusia dalam loop dapat diterima. Untuk tugas dengan frekuensi tinggi, persetujuan batch bekerja lebih baik daripada klik per tindakan.

UJI, LOG, DAN PEMULIHAN

Setiap tindakan harus menghasilkan entri audit yang tidak dapat diubah yang berisi niat yang diminta, output perencana, keputusan kebijakan, panggilan aktor dan respons API yang dikembalikan. Pertahankan format perintah yang dapat diputar kembali sehingga Anda dapat memutar ulang dan membatalkan. Sediakan pembatalan satu klik untuk N tindakan terakhir dan alur pemulihan yang membuat peristiwa kompensasi, misalnya membatalkan sebuah acara dan mengirimkan tindak lanjut yang korektif.

Kami mengamati bahwa pengaman di tingkat prompt gagal tanpa mesin kebijakan eksternal. Dalam praktiknya, model akan menyarankan perubahan yang tampak plausibel tetapi melanggar kebijakan. Pintu eksekusi yang menolak setiap penulisan ketika kepercayaan di bawah ambang batas yang terkalibrasi mengurangi insiden ini.

DAFTAR PERIKSA UNTUK PRODUK DAN TEKNOLOGI

1. OAuth per pengguna dengan lingkup minimal dan teks persetujuan yang eksplisit. 2. Brankas token dan layanan eksekusi yang menginjeksikan kredensial pada waktu runtime. 3. Pemisahan perencana/pelaksana dengan pemeriksaan kebijakan. 4. Eskalasi manusia dalam loop untuk tindakan sensitif. 5. Log audit yang tidak dapat diubah dan format tindakan yang dapat diputar ulang. 6. Alur pengembalian dan kompensasi dengan antarmuka pengguna yang jelas.

Hubungkan UX produk dengan pola alur kerja yang dijelaskan di Merancang alur kerja manusia-AI dan gunakan pengantar tentang perbedaan agen di Agen AI vs chatbot untuk membenarkan pemisahan perencana/pelaksana.

Coba sendiri. Prompt di bawah ini menunjukkan output perencana versus instruksi aman pelaksana. Harapkan rencana ala JSON yang singkat dari perencana dan konfirmasi singkat dari pelaksana.

Prompt ini meminta model untuk menghasilkan rencana terbatas dari waktu rapat kandidat dan alasan; gunakan sebagai perencana. Harapkan 2 hingga 3 slot kandidat dan alasan satu kalimat.

Anda adalah perencana rapat. Pengguna memiliki 3 slot waktu bebas hari ini: 10:00 AM, 2:30 PM, 4:00 PM. Kembalikan tepat tiga waktu rapat kandidat dalam format ISO dengan satu alasan untuk setiap, dan satu catatan privasi satu baris yang mengatakan apakah undangan menyentuh email eksternal.

Prompt ini untuk pelaksana. Ia mengharapkan token konfirmasi manusia dan pemeriksaan kebijakan eksplisit sebelum membuat acara.

Pelaksana: diberikan token konfirmasi pengguna X dan rencana perencana Y, panggil Calendar.CreateEvent dengan bidang {start,end,attendees,summary} hanya jika policy_check(policy_id:calendar_write) mengembalikan pass. Jika policy_check gagal, kembalikan kode kegagalan dan tindakan manusia yang diperlukan.

Argumen penyangkal adalah bahwa kontrol ketat memperlambat adopsi. Perkiraan saya adalah bahwa ketika tim menegakkan pola ini, retensi pengguna awal meningkat karena kepercayaan tumbuh, bahkan jika aktivasi awal lebih lambat. Pertukaran ini jelas: peluncuran lebih cepat tanpa kontrol ini menciptakan risiko yang dapat diukur dan biaya remediasi yang lebih tinggi.