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

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

Сопственоста не е неограничена автономија

„Преземи го проектот“ не треба да значи „дај му на агентот акредитиви за продукција и надевај се на најдоброто“. Во здрав инженерски тим, сопственоста вклучува одговорност, граници, докази и ескалација. Истото важи и за агентите.

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

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

Почнете со цел обликувана според проектот

Слабите цели создаваат бучно однесување на агентот. „Подобри ги перформансите“ поттикнува широко истражување и двосмислени измени. Цел обликувана според проектот му дава на агентот целна линија: да ја намали повторената работа на одредено барање, да зачува постоечки API-договор, да додаде бенчмарк и да обезбеди тест-пакетот да помине.

Добрата дефиниција на задачата одговара на неколку практични прашања:

• Каков исход е потребен и како ќе се провери?
• Кои делови од складиштето или инфраструктурата се во опфат?
• Кои однесувања не смеат да се променат?
• Кои дозволи смее да ги користи агентот?
• Што треба да предизвика ескалација наместо обид за заобиколување?

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

Дајте му на агентот сигурен работен циклус

Ефективните агенти не повикуваат едноставно алатки во долга, импровизирана низа. Тие работат низ циклус што ги претвора набљудувањата во одлуки, а одлуките во докази.

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

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

Повторните обиди имаат потреба од политика, не од оптимизам

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

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

if command_fails_due_to_transient_network_error; then
  retry_with_bounded_backoff
else
  inspect_failure_and_choose_a_new_action
fi

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

Дизајнот на алатките одредува дали агентот е безбеден

Моделите расудуваат преку интерфејсите што им се дадени. Нејасна школка со широк пристап за пишување поттикнува нејасни, широки дејства. Алатките создадени за конкретна намена ја прават намерата видлива, а заштитните мерки спроведливи.

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

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

Верификацијата е дефиницијата на агентот за завршена работа

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

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

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

Меморијата треба да биде курирана, не насобрана

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

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

Измерете ја доверливоста пред да ги проширите овластувањата

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

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

Трајната предност е подобар инженерски систем

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

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