Агентски асистенти: безбедни интеграции со календарот и Gmail

Мојот став: изградбата на безбедни, употребливи агентски асистенти кои функционираат на календарите, Gmail и поврзаните апликации бара проектирање на систем за време на работа кој првенствено се фокусира на дозволи, одвојување на планирањето од дејствувањето, и вградба на текови за ревизија и поврат во слојот на исполнување од првиот ден. Овој напис дава компактен инженерски биро и извршливи упатства за достигнување на тоа.

ДИЗАЈН НА ДОЗВОЛИ ЗА АГЕНТСКИ АСИСТЕНТИ

Започнете со OAuth за секој корисник и минимални права. Користете OAuth врз основа на корисникот наместо споделен сервисен акуант освен кога администраторот експлицитно бара дељење на доменот. Документацијата на Google за прецизни права е основа; поврзете секоја способност на агентот со единствено OAuth право и документирајте ја намерта на човечки јазик за тоа право. Држете токените надвор од упатствата. Чувајте ги во трезор и инјектирајте ги акредитици само во времето на повик во услуга за исполнување која применува политика.

Набљудувавме дека тимовите кои ги третираат дозволите како UX за производ, со јасни комунти и прегледи на опсегот, добиваат многу помалку билети за поддршка. Еден проблем со кој се сретнавме е пренаселување на токени поради наивната логика за освежување; централизирајте освежувањето и редовно ротирате токените за освежување.

ПЛАНИРАЊЕ ВРСУ ДЕЈСТВУВАЊЕ

Разделете го асистентот во планер и активатор. Планерот создава дискретен план на дејствија: прочитајте ги најновите нити, предложете две времиња за состанок, составете нацрт на е-пошта. Активаторот извршува само по проверка на политиката и, за чувствителни дејства, чекор за потврда од човек. Оваа шема го спречува моделот да импровизира привилегирани операции и прави авторизацијата проверлива.

Практичен компромис: подолга латентност за одобрување од човек отколку понизок ризик. За многу календарски и е-писмени дејства, пауза од 30 до 60 секунди со човек во петно е прифатлива. За високофреквентни задачи, одобрувањата во групи работат подобро од по-действие кликови.

ТЕСТОВИ, ЛОГОВИ И ВРАТЕЊЕ

Секоја акција мора да произведе непомичен влез за ревизија кој содржи побараната намера, резултатот од планерот, одлуката за политиката, повикот на актерот и вредноста на API одговорот. Држете формат на командите повторно воспроизводлив за да можете да ги повторите и вратите назад. Обезбедете еднократна опција за повлекување за последните N дејства и тек на враќање што создава компензациски настани, на пример, откажување на настан и испраќање на корективен следствен е-пошта.

Набљудувавме дека контроли на ниво на упатствата не успеваат без надворешен политички механизам. Во практика, моделите ќе предложат промени кои изгледаат веродостојно, но нарушуваат политичките правила. Извршната врата која одбива какво било запишување кога довербата е под калибриран праг го намалува овие инциденти.

ЛИСТА ЗА ПРОДОЖЕН И ИНЖЕНЕРИНГ

1. OAuth за секој корисник со минимални права и експлицитен текст на согласност. 2. Трезор за токени и услуга за исполнување која инјектира акредитици во времето на работа. 3. Разделување на планер/актер со проверки на политиката. 4. Унапредување со човек во петно за чувствителни дејства. 5. Непомични логови за ревизија и повторно воспроизводлив формат на акција. 6. Повратни и компензациски текови со јасни UI можности.

Поврзете UX производот со работниот тек опишан во Дизајнирање на работни текови помеѓу човекот и AI и користете го воведот за разликите помеѓу агентите во AI агенти против чатботови за да го оправдате разделбата на планерот и актерот.

Пробајте го сами. Упатствата подолу демонстрираат излез од планерот во однос на безбедни инструкции од активаторот. Очекувајте кратки планови во стилот на JSON од планерот и кратки потврди од активаторот.

Ова упатство го бара моделот да произведе ограничен план на временски настани и образложение; користете го како планер. Очекувајте 2 до 3 кандидати за времиња и еднообразно образложение.

Вие сте планер за состаноци. Корисникот има 3 слободни слотови денес: 10:00, 14:30, 16:00. Вратите точно три предлог времиња за состанок во ISO формат со кратко образложение за секое, и еднолиниска забелешка за приватноста која кажува дали поканата се однесува на надворешни е-пошти.

Ова упатство е за активаторот. Очекува човечки-потврден токен и експлицитна проверка на политиката пред да создаде настан.

Активатор: со даден кориснички потврден токен X и планер план Y, повикајте Calendar.CreateEvent со полиња {start,end,attendees,summary} само ако policy_check(policy_id:calendar_write) врати поминат. Ако policy_check не успее, вратете го кодот за неуспех и дејството потребно од човек.

Контрааргумент е дека строги контроли го забавуваат усвојувањето. Моето проценување е дека кога тимовите ги применуваат овие шеми, раната задршка на корисниците се подобрува бидејќи довербата расте, дури и ако иницијалната активација е побавна. Компромисот е јасен: побрзо лансирање без овие контроли создава мерлив ризик и повисоки трошоци за реакции.