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

Таа разлика е причината зошто агентите заслужуваат поголемо внимание отколку нов слој автоматизација. Кога се користат добро, тие стануваат алатки за соработка што ја намалуваат рутинската когнитивна работа, додека луѓето ја задржуваат одговорноста за проценката. Кога се користат лошо, стануваат нетранспарентни процеси со широки дозволи и нејасна одговорност.

Од скрипти до работа насочена кон цел

Скриптата обично кодира патека. Со влезови A и B, таа ги следи чекорите од C до F. Агентот е поблизок до ограничен решавач на проблеми. Тој добива цел, има пристап до алатки и информации и може да одлучи кое следно дејство е најкорисно.

Разгледајте работен тек за тријажа на поддршка. Традиционалната автоматизација може да открие порака што содржи „password reset“, да испрати стандарден одговор и да отвори тикет. Агентот може да ја разгледа пораката, да провери дали сметката има постоечки проблем со идентитетот, да го одреди соодветниот ред за поддршка, да подготви одговор врз основа на одобрена политика и да побара човечки преглед кога барањето е двосмислено.

Вредноста не е во тоа што агентот „размислува како човек“. Вредноста е во тоа што може да се справи со варијации без да бара посебна цврсто кодирана гранка за секоја формулација и низа настани. Таа флексибилност создава и ризик: системот мора да биде дизајниран така што варијацијата да не се претвори во неовластено дејство.

Соработката има потреба од јасни граници

Најсигурните агенти не добиваат нејасни упатства како „решавај проблеми на клиентите“ или „подобри ја базата на код“. Тие добиваат тесна мисија, дефинирани алатки, изречни ограничувања и корисен начин за истакнување на неизвесноста.

Практичниот дизајн на агент започнува со четири прашања:

• За каков исход е одговорен? Дефинирајте мерлива задача, како подготовка на резиме на барање за спојување или класифицирање на дојдовни барања.
• Кој контекст смее да го користи? Идентификувајте ги одобрените документи, складишта, записи и временскиот период што смее да ги прегледува.
• Кои дејства смее да ги преземе? Разграничете ги читањето податоци, изработката на нацрт-излез и правењето надворешни промени, како испраќање пораки или ажурирање на производствени системи.
• Кога мора да запре и да ескалира? Наведете прагови за двосмисленост, случаи чувствителни на политика, податоци што недостигаат и дејства со значајни последици.

Овие граници го прават агентот полесен за доверба бидејќи го прават полесен за проверка. Добро дизајнираниот систем може да ги објасни влезовите што ги користел, алатките што ги повикал, нацртот што го создал и моментот кога човекот ја презел работата.

Градете агенти како работни текови со точки за проценка

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

Асистент за преглед на код, на пример, може да ја следи следнава низа:

1. Прочитајте го описот на барањето за спојување и изменетите датотеки.
2. Преземете ги релевантните насоки за складиштето и блиските тестови.
3. Идентификувајте потенцијални проблеми и разликувајте ги набљудувањата од предлозите.
4. Создадете структуриран нацрт за преглед со референци до датотеки и белешки за сигурност.
5. Барајте од развивачот да ги одобри коментарите пред објавување.

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

Одделете го планирањето од извршувањето

Еден корисен образец е да му се дозволи на агентот да предложи план пред да повика алатки со значајни последици. За асистент за распоредување, планот може да ги наведе целната средина, верзијата што треба да се објави, предусловните проверки, условите за враќање и потребните одобренија. Човек или детерминистички слој на политики може да го потврди тој план пред да започне извршувањето.

Ова раздвојување ги подобрува безбедноста и отстранувањето грешки. Ако исходот е погрешен, тимовите можат да утврдат дали неуспехот потекнува од лош контекст, несоодветен план, грешка во алатка или политика за извршување што била премногу попустлива.

Сигурните алатки се поважни од паметните упатства

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

Претпочитајте операции со јасни договори. На пример, барање за создавање нацрт-тикет треба да врати идентификатор и статус, додека барање за објавување треба да бара изречно поле за потврда. Ако повикот на алатка не успее, агентот треба да добие доволно структурирани информации за безбедно да се обиде повторно, да избере алтернатива или да го пријави неуспехот без да нагаѓа.

Идемпотентноста е особено важна. Ако агентот се обиде повторно по истекување на мрежното време, второто барање не треба да создаде дупликат-тикет, да испрати второ известување или да го активира истото платежно дејство двапати. Каде што надворешните системи го поддржуваат тоа, користете стабилен идентификатор на барањето и запишете го исходот.

Оценувајте го однесувањето пред да ги проширите дозволите

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

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

Започнете со можности само за читање или за создавање нацрти. Откако системот доследно ќе се справува со тесна задача, додадете мал обем на овластување и набљудувајте ги резултатите. Овој постепен пристап е помалку гламурозен од целосно автономна демонстрација, но создава докази за тоа каде автономијата е навистина заслужена.

Човечката улога станува поважна, не помалку важна

Агентите ја оддалечуваат работата од повторливата координација и првичната синтеза. Тие не ја отстрануваат потребата од луѓе што ја разбираат областа, препознаваат штетни компромиси и можат да одлучат што всушност значи успех. Во многу тимови, човечкиот придонес со најголема вредност се поместува порано во процесот: поставување политики, обликување интерфејси, прегледување исклучоци и подобрување на повратната врска.

Најсилните системи со агенти помалку наликуваат на замени, а повеќе на способни колеги со внимателно ограничен мандат. Тие можат да подготвуваат, споредуваат, резимираат и извршуваат одобрени рутински дејства. Луѓето ја задржуваат одговорноста за намерата, стандардите и последиците.

Тоа е трајниот пат надвор од автоматизацијата. Не барајте од агентот магично да биде автономен. Побарајте од него да направи одреден дел од работата појасен, побрз и побезбеден—а потоа дајте му ги контекстот, алатките и границите потребни да го направи токму тоа.