Agenti pomoćnici: sigurne integracije s kalendarom i Gmailom

Moj stav: izgradnja sigurnih, upotrebljivih agenata pomoćnika koji djeluju na kalendarima, Gmailu i povezanim aplikacijama zahtijeva dizajniranje okruženja temeljenog na dozvolama, odvajanje planiranja od djelovanja i uključivanje sustava revizije i povratka u izvršnu razinu od prvog dana. Ovaj članak daje sažetu inženjersku kontrolnu listu i izvršne upute za postizanje tog cilja.

DIZAJN DOZVOLA ZA AGENTE POMOĆNIKE

Započnite s OAuth-om za svakog korisnika i minimalnim dozvolama. Koristite OAuth vezan uz korisnika umjesto zajedničkog servisnog računa osim kada administrator izričito zahtijeva delegaciju nad domenom. Googleova dokumentacija o granularnim dozvolama je osnovna; mapirajte svaku sposobnost agenta na jednu OAuth dozvolu i dokumentirajte jasno razumljiv namjenu te dozvole. Držite tokene izvan uputa. Pohranite ih u trezoru i umetnite kredencijale samo u vrijeme poziva unutar izvršne usluge koja provodi politiku.

Primijetili smo da timovi koji tretiraju dozvole kao UX proizvoda, s jasno definiranim ekranima privole i pregledima dozvola, dobivaju puno manje zahtjeva za podršku. Jedan problem na koji smo naišli je proliferacija tokena iz naivne logike osvježavanja; centralizirajte osvježavanje i redovito rotirajte osvježene tokene.

PLANIRANJE PROTIV DJELOVANJA

Podijelite pomoćnika na planera i izvršitelja. Planer proizvodi određeni akcijski plan: čitati nedavne niti, predložiti dva vremena sastanka, sastaviti nacrt e-pošte. Izvršitelj djeluje samo nakon provjere politike i, za osjetljive akcije, koraka potvrde od strane čovjeka. Ovaj obrazac sprječava model da improvizira privilegirane operacije i čini autorizaciju revizibilnom.

Praktična kompenzacija: duža latencija za ljudsku potvrdu nasuprot nižem riziku. Za mnoge akcije u kalendaru i e-pošti, pauza od 30 do 60 sekundi s ljudskim sudjelovanjem je prihvatljiva. Za zadatke s visokom učestalošću, skupne potvrde djeluju bolje od zasebnih klikova po akciji.

TESTOVI, DNEVNICI I OBNOVA

Svaka akcija mora proizvesti nepromjenjiv revizijski zapis koji sadrži zatraženu namjeru, izlaz planera, odluku politike, poziv izvršitelja i povratni API odgovor. Držite format naredbi koji se može ponovo izvršiti kako biste mogli ponoviti i vratiti se. Pružite jedinstveno povlačenje za posljednjih N akcija i tok oporavka koji stvara kompenzacijske događaje, na primjer otkazivanje događaja i slanje ispravne nadopune.

Primijetili smo da zaštitne mjere na razini uputa ne uspijevaju bez vanjskog politika motora. U praksi, modeli će sugerirati promjene koje izgledaju plauzibilno, ali krše politiku. Izvršna vrata koja odbijaju bilo kakvo pisanje kada je povjerenje ispod kalibriranog praga smanjuju ove incidente.

KONTROLNA LISTA ZA PROIZVOD I INŽENJERING

1. OAuth za svakog korisnika s minimalnim dozvolama i jasnim tekstom o suglasnosti. 2. Trezor tokena i izvršna usluga koja umetne kredencijale u vrijeme izvođenja. 3. Odvajanje planera i izvršitelja s provjerama politike. 4. Ljudsko sudjelovanje u eskalaciji za osjetljive akcije. 5. Nepromjenjivi revizijski dnevnici i format akcije koji se može ponovno izvršiti. 6. Povratni i kompenzacijski tokovi s jasnim UI mogućnostima.

Povežite UX proizvoda s radnim obrascima opisanim u Dizajniranju ljudsko-AI radnih tokova i koristite uvod o razlikama agenata u AI agenti protiv chatbota kako biste opravdali podjelu između planera i izvršitelja.

Isprobajte sami. Upute u nastavku prikazuju izlaz planera naspram instrukcija koje su sigurne za izvršitelja. Očekujte sažete planove slične JSON-u od planera i kratke potvrde od izvršitelja.

Ova uputa traži od modela da proizvede ograničeni plan mogućih vremena sastanka i obrazloženje; koristite je kao planera. Očekujte 2 do 3 kandidatska vremena i jednoobrazno obrazloženje.

Vi ste planer sastanaka. Korisnik ima 3 slobodna termina danas: 10:00, 14:30, 16:00. Vratite točno tri kandidatska vremena sastanka u ISO formatu s jednim obrazloženjem za svako, i jednom rečenicom o privatnosti koja govori dodiruje li poziv vanjske e-pošte.

Ova uputa je za izvršitelja. Očekuje token ljudske potvrde i izričitu provjeru politike prije stvaranja događaja.

Izvršitelj: na temelju tokena potvrde korisnika X i plana planera Y, pozovite Calendar.CreateEvent s poljima {start,end,attendees,summary} samo ako policy_check(policy_id:calendar_write) vrati prolaz. Ako policy_check ne uspije, vratite kod greške i potrebnu ljudsku akciju.

Protargument je da stroge kontrole usporavaju usvajanje. Moja procjena je da kada timovi provode ove obrasce, početno zadržavanje korisnika poboljšava se jer se povjerenje povećava, čak i ako je početna aktivacija sporija. Kompenzacija je jasna: brža implementacija bez ovih kontrola stvara mjerljiv rizik i veće troškove otklanjanja problema.