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

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

Што го прави ВИ агентот различен?

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

На сигурен агент обично му се потребни пет работи:

• Јасна цел: конкретен исход, како што е сортирање тикети за поддршка или подготовка на резиме за pull request.
• Корисен контекст: тековни информации за проектот, политики, документација и состојбата на задачата.
• Ограничени алатки: одобрени начини за пребарување, читање записи, извршување проверки, креирање нацрти или барање човечко одобрување.
• Правила за одлучување: инструкции за тоа кога да продолжи, да запре, да ескалира или да побара појаснување.
• Набљудливост: логови и траги што покажуваат што видел, одлучил и променил агентот.

Без овие компоненти, „агент“ често значи четбот со пристап до премногу работи. Тоа не е автоматизација; тоа е оперативен ризик што може да се избегне.

Каде агентите создаваат практична вредност

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

Поддршка за испорака на софтвер

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

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

Оперативна тријажа

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

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

Деловни и внатрешни операции

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

Дизајнирајте го работниот тек пред да го изберете моделот

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

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

1. Дефинирајте го настанот што ја започнува задачата.
2. Наведете ги информациите што агентот смее да ги чита.
3. Наведете го секое дејство што смее да го преземе.
4. Идентификувајте ги дејствата што бараат одобрување.
5. Дефинирајте услови за успех, неуспех и ескалација.

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

Сигурноста доаѓа од ограничувања, не од самодоверба

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

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

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

Како треба да се приспособат софтверските архитекти

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

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

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

Трајната поука

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

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