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

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

Размислувајте во работни текови, не во магија

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

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

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

Почнете со задачи само за читање, со богат контекст

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

Добри почетни случаи на употреба вклучуваат:

• Сумирање на pull request и идентификување области што заслужуваат поблиска ревизија.
• Следење на функционалност низ складишта, услуги, конфигурација и документација.
• Претворање на извештај за проблем во чекори за репродукција, претпоставки и прашања за појаснување.
• Извлекување веројатни обрасци на грешки од логови доставени до агентот.
• Изготвување тест-случаи од критериуми за прифаќање и постојни проектни конвенции.
• Подготовка на план за миграција што ги наведува зависностите, ризиците и прашањата за враќање назад.

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

Дајте му на агентот алатки со договори

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

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

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

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

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

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

Цел: безбедно ажурирање на зависност на услуга

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

Таквата инструкција е покорисна од „ажурирај ја оваа зависност“. Таа му кажува на агентот како изгледа успехот и, исто толку важно, каде да запре.

Потврдата е разликата меѓу демо и соработник

LLM може да создадат веродостоен код што е нецелосен, неконзистентен со локалните конвенции или едноставно погрешен. Затоа агентот треба да го потврди својот излез користејќи ги истите механизми што би ги користел внимателен развивач: проверка на типови, единечни тестови, интеграциски тестови, linting, статичка анализа и насочена проверка.

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

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

Дизајнирајте за неуспех пред да го проширите пристапот

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

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

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

Мерете ја работата, не новината

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

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

Подобра поделба на трудот

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

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