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

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

Од интерфејс за разговор до учесник во работниот тек

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

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

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

Архитектурата околу моделот е најважна

Способниот модел е само еден слој од агентски систем. Сигурните агенти се градат со тоа што околните слоеви се прават експлицитни.

• Јасна цел: Дефинирајте ги испорачливиот резултат и границата. „Подготви опис за pull request од завршениот diff“ е појасно од „помогни со изданието.“
• Доверлив контекст: Обезбедете тековни, релевантни информации од одобрени извори наместо да барате од моделот да нагаѓа врз основа на општо знаење.
• Ограничени алатки: Дајте му на агентот најмал сет дејства што е потребен, со тесни влезови и предвидливи излези.
• Состојба: Зачувајте што е пробано, што е научено и што сè уште бара потврда.
• Евалуација: Проверувајте ги излезите со тестови, шеми, детерминистички правила или човечко одобрување пред дејството да има значајни последици.

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

Направете ги алатките едноставни и конкретни

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

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

Започнете со ограничена работа со големо триење

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

Практичното воведување може да следи едноставна прогресија:

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

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

Дизајнирајте за неизвесност, а не за совршени одговори

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

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

Цел: безбедно ажурирање на зависност
1. Проверете ги декларираната верзија и промените во lockfile.
2. Прочитајте ги белешките за изданието на пакетот од одобрен извор.
3. Ажурирајте ја зависноста во изолирана гранка.
4. Извршете ги постојните команди за инсталација, компајлирање и тестирање.
5. Сумирајте ги променетите датотеки, резултатите и нерешените предупредувања.
6. Застанете за одобрување пред спојување или распоредување.

Вредноста на оваа низа не е во формулацијата на моделот. Таа е во контролираниот циклус: провери, дејствувај, верификувај, извести и застани на соодветната граница.

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

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

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

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

Новата предност е подобро системско размислување

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

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