Agentni asistenti: sigurne integracije sa kalendarom i Gmail-om

Moj stav: izgradnja sigurnih, upotrebljivih agentnih asistenata koji deluju na kalendarima, Gmail-u i povezanim aplikacijama zahteva dizajn runtime-a koji se fokusira na dozvole, odvajanje planiranja od delovanja i integraciju revizijskih i povratnih tokova u sloj izvršenja od prvog dana. Ovaj članak daje kratak inženjerski kontrolni spisak i pokretnu provjeru za ostvarenje tog cilja.

DIZAJN DOZVOLA ZA AGENTNE ASISTENTE

Počnite sa OAuth za svakog korisnika i minimalnim privilegijama. Koristite OAuth vezan za korisnika umesto deljenog servisnog naloga osim kada administrator eksplicitno zahteva delegiranje domena. Googleova dokumentacija o granularnim opsezima je osnova; mapirajte sve sposobnosti agenta na jedan OAuth opseg i dokumentujte ljudski čitljiv intenzitet za taj opseg. Držite tokene van provjera. Čuvajte ih u trezoru i ubacujte akreditive samo u trenutku pozivanja unutar servisa za izvršenje koji sprovodi politiku.

Primijetili smo da timovi koji tretiraju dozvole kao proizvodnu UX, sa jasnim ekranima za pristanak i pregledima opsega, dobijaju znatno manje zahteva za podršku. Jedan problem na koji smo naišli je proliferacija tokena zbog naivne logike osvežavanja; centralizujte osvežavanje i redovno rotirajte tokene za osvežavanje.

PLANIRANJE NASUPROT DELANJU

Podelite asistenta na planera i izvršitelja. Planer proizvodi diskretni akcioni plan: pročitajte nedavne teme, predložite dva vremena sastanka, sastavite nacrt e-pošte. Izvršitelj izvršava samo nakon provere politike i, za osetljive radnje, koraka ljudske potvrde. Ovaj obrazac sprečava model da improvizuje privilegovane operacije i čini autorizaciju revizibilnom.

Praktična trgovina: duže vreme čekanja za ljudsko odobrenje nasuprot smanjenom riziku. Za mnoge akcije u kalendaru i e-pošti, pauza od 30 do 60 sekundi u kojoj učestvuje čovek je prihvatljiva. Za zadatke velike frekvencije, grupni odobrenja bolje funkcionišu od odobrenja po akciji.

TESTOVI, DNEVNICI I OBNOVA

Svaka akcija mora proizvoditi nepromenljivu reviziju koja sadrži traženi intenzitet, izlaz planera, odluku o politici, poziv izvršitelja i vraćeni API odgovor. Održavajte ponovljive formate komandi tako da ih možete ponovo odigrati i vratiti nazad. Pružite mogućnost jednog klika za opoziv poslednjih N akcija i tok povratka koji stvara kompenzatorske događaje, na primer, otkazivanje događaja i slanje korigovanog naknadnog obaveštenja.

Primijetili smo da zaštitne mere na nivou provjera propadaju bez spoljnog motora politike. U praksi, modeli će predlagati promene koje izgledaju verovatno, ali krše politiku. Vrata izvršenja koja odbacuju bilo kakvo pisanje kada je poverenje ispod kalibrisanog praga smanjuje ove incide.

KONTROLNA LISTA ZA PROIZVOD I INŽENJERING

1. OAuth za svakog korisnika sa minimalnim opsezima i eksplicitnim tekstom pristanka. 2. Trezor tokena i servis za izvršenje koji unosi akreditive u trenutku izvršenja. 3. Razdvajanje planera i izvršitelja sa proverama politike. 4. Eskalacija sa ljudima za osetljive akcije. 5. Nepromenljivi revizijski dnevnici i ponovljivi format akcije. 6. Povratni i kompenzatorski tokovi sa jasnim UI funkcionalnostima.

Povežite UX proizvoda sa obrascima rada opisanim u Dizajn ljudsko-AI radnog toka i koristite uvod o razlikama među agentima u AI agenti nasuprot chatbotovima kako biste opravdali razdvajanje planera i izvršitelja.

Isprobajte to sami. Uputstva ispod predstavljaju izlaz planera nasuprot sigurnim instrukcijama izvršitelja. Očekujte sažete planove nalik JSON-u od planera i kratke potvrde od izvršitelja.

Ova provjera traži od modela da proizvede ograničen plan mogućih vremena sastanka i obrazloženje; koristite je kao planera. Očekujte 2 do 3 kandidatska vremenska okvira i objašnjenje u jednoj rečenici.

Vi ste planer sastanaka. Korisnik ima 3 slobodna mesta danas: 10:00, 14:30, 16:00. Vratite tačno tri kandidatska vremena sastanka u ISO formatu sa jednim rečenicom objašnjenja za svako i jednom rečenicom obaveštenja o privatnosti koja govori da li poziv uključuje spoljne e-poruke.

Ova provjera je za izvršitelja. Očekuje token ljudske potvrde i eksplicitnu proveru politike pre nego što kreira događaj.

Izvršitelj: dat je token ljudske potvrde X i plan planera Y, pozovite Calendar.CreateEvent sa poljima {start,end,attendees,summary} samo ako policy_check(policy_id:calendar_write) vrati uspeh. Ako policy_check ne uspe, vratite kod greške i potreban ljudski akcija.

Protuargument je da stroge kontrole usporavaju usvajanje. Procena je da kada timovi sprovode ove obrasce, ranija zadržavanje korisnika se poboljšava jer poverenje raste, čak i ako je početna aktivacija sporija. Trgovina je jasna: brža primena bez ovih kontrola stvara merljiv rizik i više troškove sanacije.