Четбот може да објасни stack trace, да изработи тест или да сумира pull request. Агентот оди подалеку: презема цел, поминува низ низа чекори, користи алатки, ги проверува резултатите и одлучува што да прави понатаму. Токму таа разлика е местото каде што ВИ почнува да влијае врз софтверската работа, наместо само да ѝ помага.

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

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

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

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

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

На агентите им е потребна контролна јамка

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

цел -> собери контекст -> избери дејство -> изврши алатка
     ^                                             |
     |------------- провери резултат <--------------|
                         |
                    заврши или ескалирај

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

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

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

Дизајнот на алатките често е поважен од дизајнот на prompt-от. Алатка наречена run_command што прифаќа произволен shell текст му дава на агентот огромна моќ и малку насоки. Алатка наречена get_build_logs(build_id) или rerun_failed_test(test_id) е полесна за обезбедување, тестирање, ревизија и правилна употреба.

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

• Одделете ги алатките само за читање од алатките што ја менуваат состојбата.
• Барајте потврда пред неповратни или надворешно видливи дејства.
• Користете ограничени ингеренции наместо еден семоќен token.
• Враќајте статусни полиња читливи за машина покрај пораки читливи за луѓе.
• Евидентирајте ги името на алатката, влезовите, резултатот и идентитетот што дејствувал за подоцнежен преглед.

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

Дизајнирајте за неизвесност и неуспех

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

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

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

Користете ги луѓето како носители на одлуки во вистинските моменти

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

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

Оценувајте го однесувањето, не само одговорите

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

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

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

Интегрирајте ги агентите во постојната инженерска практика

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

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

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