Aģentiskie asistenti: drošas kalendāra un Gmail integrācijas

Mana prasība: drošu, lietojamu aģentisko asistentu, kas rīkojas ar kalendāriem, Gmail un saistītām lietotnēm, izstrāde prasa izveidot atļauju pirmo izpildes vidi, atdalīt plānošanu no rīkošanās, un ieviest audita un atgriešanas plūsmas izpildes līmenī no pirmās dienas. Šis raksts sniedz saspringtu inženiertehnisko pārskatu un funkcionējošas komandas, lai to sasniegtu.

ATĻAUJU DIZAINS AĢENTISKAJIEM ASISTENTIEM

Sāciet ar per lietotāju OAuth un minimālām atļaujām. Izmantojiet lietotājam piesaistītu OAuth, nevis kopīgu pakalpojumu kontu, izņemot gadījumus, kad administrators skaidri prasa domēna deleģēšanu. Google dokumentācija par sīku atļauju izmantošanu ir pamats; kartējiet katru aģenta spēju uz vienu OAuth atļauju un dokumentējiet cilvēkam saprotamo nodomu šai atļaujai. Izturieties pret piekļuves žetoniem prom no komandām. Glabājiet tos seifā un injicējiet akreditīvus tikai izsaukuma laikā izpildes pakalpojumā, kas izpilda politiku.

Mēs novērojām, ka komandas, kas izturas pret atļaujām kā produkta UX ar skaidrām piekrišanas ekrāniem un atļauju priekšskatījumiem, saņem krietni mazāk atbalsta pieprasījumu. Viens jautājums, ar ko mēs saskārāmies, ir žetona pieaugums naivās atsvaidzināšanas loģikas dēļ; centralizējiet atsvaidzināšanu un regulāri rotējiet atsvaidzināšanas žetonus.

PLĀNOŠANA VERSUS RĪKOŠANA

Sadaliet asistentu plānotājā un rīkotājā. Plānotājs izstrādā atsevišķu rīcības plānu: izlasīt jaunākās sarakstes, ierosināt divus tikšanās laikus, sastādīt melnrakstu e-pastam. Rīkotājs izpilda tikai pēc politikas pārbaudes un, jutīgiem pasākumiem, pēc cilvēka apstiprināšanas. Šī shēma neļauj modelim improvizēt privilēģētās darbības un padara autorizāciju auditu pārbaudāmu.

Praktiska tirdzniecības izsistē: garāka latentēšana cilvēka apstiprināšanai pret zemāku risku. Daudziem kalendāra un e-pasta pasākumiem 30 līdz 60 sekunžu cilvēka apstāšanās laikā ir pieņemami. Biežu uzdevumu veikšanai partiju apstiprinājumi darbojas labāk nekā katrai rīcībai.

TESTI, ŽURNĀLI UN ATGRIEZUMS

Katram pasākumam jāražo nemainīgs audita ieraksts, kas satur pieprasīto nodomu, plānotāja izeju, politikas lēmumu, rīkotāja izsaukumu un atgriezto API atbildi. Saglabājiet atkārtojamu komandu formātu, lai jūs varētu atkārtot un atgriezties. Nodrošiniet vienas klikšķa atsaukšanu iepriekšējiem N pasākumiem un atgriešanas plūsmu, kas rada kompensējošus notikumus, piemēram, pasākuma atcelšanu un labojuma sekošanas pasūtījumu.

Mēs novērojām, ka komandu līmeņa drošības plūsmām neizdodas, bez ārējā politikas dzinēja. Praksē modeļi ierosinās izmaiņas, kas izskatās ticamas, bet pārkāpj noteikumus. Izpildes vārti, kas atsakās no jebkuras rakstīšanas, kad pašpārliecinātība ir zem kalibrēta sliekšņa, samazina šādas incidentes.

PĀRBAUDES SARAKSTS PRODUKTAM UN INŽENIERIJAI

1. Per lietotāju OAuth ar minimālām atļaujām un skaidru piekrišanas tekstu. 2. Žetonu seifs un izpildes pakalpojums, kas injicē akreditīvus izpildes laikā. 3. Plānotāja/rīkotāja sadalījums ar politikas pārbaudēm. 4. Cilvēku iesaistīšana jutīgām darbībām. 5. Nemainīgas audita žurnālu un atkārtojama rīcības formāta. 6. Atgriešanas un kompensējošas plūsmas ar skaidriem UI risinājumiem.

Saistiet produkta UX ar darba plūsmām, kas aprakstītas Cilvēka un AI darba plūsmu izstrādē, un izmantojiet pamatu par aģentu atšķirībām AI aģenti vs čatboti, lai pamatotu plānotāja/rīkotāja dalījumu.

Pats izmēģiniet. Apakšējās komandas demonstrē plānotāja izeju pret rīkotāja drošajām instrukcijām. Sagaidiet lakoniskus JSON līdzīgus plānus no plānotāja un īsas apstiprināšanas no rīkotāja.

Šī komanda lūdz modeli izstrādāt ierobežotu plānu par kandidātu tikšanās laikiem un racionālu pamatojumu; izmantojiet to kā plānotāju. Sagaidiet 2 līdz 3 kandidātu slots un vienas teikuma racionālu pamatojumu.

Jūs esat tikšanās plānotājs. Lietotājam šodien ir 3 brīvas slotas: 10:00, 14:30, 16:00. Atgrieziet tieši trīs kandidātu tikšanās laikus ISO formātā ar vienas rindas pamatojumu katram, un vienrindas konfidencialitātes piezīmi, sakot, vai uzaicinājums skar ārējus e-pastus.

Šī komanda ir rīkotājam. Tā sagaida cilvēka apstiprināšanas žetonu un skaidru politikas pārbaudes apstiprinājumu pirms pasākuma izveides.

Rīkotājs: ņemot vērā lietotāja apstiprināšanas žetonu X un plānotāja plānu Y, izsauciet Calendar.CreateEvent ar laukiem {sākums,gals,dalībnieki, kopsavilkums} tikai tad, ja policy_check(policy_id:calendar_write) atgriež apstiprinājumu. Ja policy_check neizdodas, atgrieziet neveiksmju kodu un norādiet nepieciešamās cilvēku darbības.

Pretargumenta apsvērums ir, ka stingras kontroles palēnina pieņemšanu. Manas aplēses liecina, ka, kad komandas ievieš šīs shēmas, agrīna lietotāju noturība uzlabojas, jo uzticība aug, pat ja sākotnējā aktivizācija ir lēnāka. Izmaksu sadalījums ir skaidrs: ātrāka izplatīšana bez šīm kontrolēm rada izmērāmu risku un augstākas atveseļošanās izmaksas.