Дизајнирање, усавршавање и одржавање вјештина агената у компанији Perplexity

Продукти граничних агената компаније Perplexity заснивају се на темељу знања и стручности из одређене области пакованим у модуларне вјештине агената. Одржавамо пажљиво одабрану библиотеку вјештина у нашим техничким окружењима. Ове вјештине укључују многе услужне програме опште намјене који покрећу Perplexity Computer; могућности специфичне за вертикале у областима као што су финансије, право и здравство; и веома дуг низ модула за рјешавање потреба корисника. Неке вјештине се ријетко покрећу, али су кључне када се покрену. Да би се осигурало доследно одлично корисничко искуство, тим агената компаније Perplexity даје приоритет квалитету вјештина једнако као и квалитету кода.

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

На примјер, ако узмете неке од афоризама из PEP20 – Зен за Python, брзо постаје јасно да писање доброг Python кода није исто што и писање добрих вјештина. Од 20 линија мудрости, најмање половина је потпуно погрешна или активно мање усмјерена при писању вјештина. Ево пет њих:

Pet kontrasta između Zena Pythona i smjernica članka za pisanje vještina.

Овај водич је документ који инжењери у Perplexity-ју користе приликом развоја и прегледа вјештина. Такође објављујемо овај водич јавно како би наша открића и сазнања могла да користе широј заједници. Било да сте инжењер који свакодневно дизајнира производне вјештине, корисник Computer-а који жели да развије сопствену вјештину у области коју најбоље познаје, или обоје, овај водич је за вас.

Шта је вјештина?

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

Вјештина је најмање четири ствари, посебно у контексту како их градимо у компанији Perplexity.

Вјештина је директоријум

Вјештина није само једна SKILL.md датотека. У многим случајевима, вјештина укључује неколико датотека. Испод директоријума названог по вашој вјештини, можда имате:

SKILL.md: уводни дио и упутства

scripts/: код који агент извршава, а не поново осмишљава

references/: обимна документација, учитана условни

assets/: шаблони, шеме и подаци

config.json: подешавање корисника при првом покретању

Овај образац чворишта и кракова вам омогућава да вјештине одржите веома фокусираним и уским, а структура фасцикли се може користити на врло креативан начин. Понекад посебно сложене вјештине имају користи од више нивоа хијерархије како би се помогло моделу да се боље снађе. Претпоставимо да вјештина захтијева знање о 300 тема које се могу груписати у 20 области предмета. Поуздан одабир праве теме међу 300 је неријешен изазов чак и за данашње најбоље граничне моделе. Много је лакћи проблем избора за модел да се усредсреди на једну од 20 области, него међу 15 тема унутар те области.

Као један примјер како вишестепена хијерархија пружа вриједност, наш тим је употријебио три нивоа тематског угнежђивања у вјештинама које покрећу могућности пореза на доходак у САД за Computer током ове пореске сезоне. Ова хијерархија је била апсолутно неопходна с обзиром на сложеност пореског закона: у нашим раним тестовима, представљање модела са једном фасциклом која садржи свих 1.945 одјељака америчког Пореског законика резултирало је лошијим перформансама него уопште не учитавање вјештине. Организовање информација у логичке подподјеле било је неопходно за обезбјеђивање операција читања високе прецизности.

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

Увећај

Вјештина је формат

Вјештина је формат. Главна корјенска SKILL.md датотека мора имати и назив и опис. Штавише, вјештина мора тачно да се поклапа са називом директоријума у којем се вјештина налази. Назив мора бити искључиво мала слова, без размака и може користити цртице. Опис је окидач за рутирање. Ово је уобичајена тачка неуспјеха: опис није интерна документација о томе шта вјештина ради. Он се своди на упутства за модел о томе када треба учитати вјештину. Дакле, често ћете видјети „Учитај када“, а не „Ова вјештина ради“. Ово је важно због начина на који већина имплементација убацује опис у контекст модела.

У оквиру уводног дијела постоји и „depends:“, што вам омогућава да креирате хијерархијске зависности вјештина, и „metadata:“, који се користи за прегледе и евалуације. Различити системи агената могу чак дефинисати сопствена поља уводног дијела која ће се користити на начин специфичан за те системе. Као алтернатива, метаподаци специфични за вјештину могу се упаковати у помоћну JSON или YAML конфигурациону датотеку. Ово је пожељно када се граде системи агената који треба да олакшају различите врсте понашања у вријеме извршавања по вјештини без загађивања контекста модела ситницама. Коначно, слично понашање се може постићи уклањањем уводног дијела вјештине при читању. Computer користи ову методологију, што омогућава да се конфигурација сачува у корјенској SKILL.md датотеци. Пажљива пажња посвећена детаљима је неопходна у логици парсирања, а можда ћете пожељети да имплементирате условно уклањање ако постоје одређена поља која је корисно имати у контексту модела.

Вјештина је покретљива

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

Постоје најмање три нивоа трошкова контекста на начин на који смо имплементирали вјештине у Computer. Ево процеса:

Computer позива load_skill(name="...")

Computer копира директоријум вјештине у изолирано окружење за извршавање (sandbox)

Computer рекурзивно аутоматски учитава зависности у ознаци „depends:“

Computer затим уклања уводни дио и агент стога види само тијело и додатне датотеке

Различити системи агената могу изабрати да изложе садржај вјештине на различите начине. Као примјер, неки системи могу одлучити да уопште не изложе хијерархију датотека, остављајући моделу да открије хијерархију кроз операције система датотека. Други системи могу изабрати да дају моделу мапу цијелог стабла датотека до одређеног скраћивања и/или ограничења дубине. Да би контекст био чист, Computer изоставља пуне хијерархије датотека из контекста позивања; међутим, ово се може преписати за сваку вјештину појединачно.

Вјештина је прогресивна

Вјештине су прогресивне. У Computer постоје три различита нивоа трошкова контекста, и ми сносимо сва три у различитим фазама:

Tri nivoa konteksta vještine: indeks, potpuno učitavanje vještine i referentne datoteke za izvršavanje.

Computer гради индекс вјештина који има назив и опис за сваку доступну вјештину. Буџет за ово је око 100 токена по вјештини (краће је још боље). То је тако уско јер ову цијену плаћате у свакој сесији, за сваког корисника. Ово се убацује у промпт система на самом почетку разговора. Модел има приступ гомили именованих вјештина и описа тако да може одлучити да ли да позове „load_skill()“. Праг за улазак у овај индекс је изузетно висок. Ваша вјештина мора бити веома корисна, а опис мора бити изузетно густ и сажет зато што сви плаћају цијену све вријеме.

Након што систем агената учита вјештину, ту је пуно тијело SKILL.md. Идеално би било да текст тијела не прелази 5.000 токена. И тада желите да свака реченица буде важна јер када једном учитате вјештину, остатак разговора мора то да плаћа све док не дођете до границе сабијања. Многе нити учитавају било гдје између три и пет различитих вјештина, умножавајући овај трошок. Вјештине са пуно сувишних детаља готово сигурно ће деградирати друге вјештине, као и укупне могућности агената. Укратко, ако се ваша вјештина учита и не ради праву ствар, то је изгубљени контекст.

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

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

Када вам је потребна вјештина?

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

Када вам је потребна вјештина

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

Може бити да је ваше знање трајно, али није у подацима за обуку. Може постојати прекиди или специфични радни токови за предузећа, или то може бити ствар укуса. На примјер, имамо неколико вјештина везаних за дизајн у Computer које је написао Henry Modisett (наш шеф дизајна). Разлог зашто сваки токен постоји у тим вјештинама је тај што Henry има веома добар укус када је у питању дизајнирање веб сајтова и PDF-ова. Henry одређује које фонтове треба користити а које фонтове не треба користити, како се ти фонтови осећају, и друга питања расуђивања која модел не може научити само из података за обуку.

Када вам није потребна вјештина

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

Виђамо примјере гдје вјештине рекапитулирају упутства из системског промпта. За то вам није потребна вјештина. Знање релевантно за већину захтјева треба да буде укључено у глобални контекст, а не у условно учитану вјештину

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

Свака вјештина је порез

Ево корисног теста који можете примијенити на сваку реченицу у вашој вјештини: „Да ли би агент погрешио без овог упутства?“ Ако реченица не мора да буде ту, не може себи да приушти да буде ту јер сви плаћају овај трошок сваки пут. Када одлучујете да ли да додате вјештину или не, запамтите овај порез у којем свака сесија и сваки корисник коштају токена.

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

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

Баш као и Паскал, морате уложити вријеме у сваку вјештину. Тешко је написати кратку вјештину. Ако је вашу вјештину лако написати, вјероватно је пре дугачка или не би требало да постоји. Добра вјештина је онолико кратка колико може бити.

Ако се нађете како покушавате да генеришете вјештину из прве и постављате PR-ове за пет минута, резултати ће готово сигурно бити испод просјека. У ствари, рана истраживања су показала да ако користите LLM за писање вјештина, LLM вјероватно неће имати користи од тога: „Вјештине које су самостално генерисане не пружају никакву корист у просјеку, што показује да модели не могу поуздано да ауторствују процедурално знање од чијег конзумирања имају користи.“

Како изградити вјештину

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

Корак 0: Напишите евал-ове

Напишите неке од евал-ова први пут. Можете набавити случајеве евалуације из:

Упити стварних корисника: узорак из продукције или вашег групе повјерења

Познати неуспјеси: Агент није успио јер вјештина није постојала

Збуњеност сусједа: Близу границе вашег домена али усмјерава на другу вјештину

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

Почните са сличним негативним и позитивним примјерима. Негативни примјери су изузетно моћни и могу бити важнији од позитивних примјера.

Корак 1: Опис

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

Опет, лош опис описује шта вјештина ради или зашто је корисна. Добре опис каже када агент треба да учита вјештину. На примјер, рецимо да имате нешто за праћење захтјева за повлачење. Немојте писати шта вјештина ради. Напишите шта инжењери говоре када су фрустрирани и желе да осигурате да њихов PR ради, као што је „чувај децу“ или „гледај CI“ или „постарај се да ово прође“.

Ево брзе контролне листе:

Почиње са "Учитај када..."

Циљајте 50 ријечи или мање

Описује намјеру корисника, идеално из стварних упита

Не резимира ток рада

Стварни упити су оно што можете покрити у 80-20. Обично два или три примјера добро раде. Није лако додати тачно и само онолико колико вам је потребно.

Корак 2: Напишите тијело

Затим напишите садржај саме вјештине. Приметитите да ово није Корак 0 или Корак 1.

Комуникација радних токова са LLM је потпуно другачија од комуникације радних токова са колегом, па чак и са вашим системом извршавања. При учењу новог софтверског алата, инжењер ће можда морати да прочита документацију, добије обилазак од неког са искуством и научи како да користи алат. У међувремену, за скоро сваки софтверски алат који постоји најмање годину дана, само требате поменути његово име и LLM има све информације које су му потребне.

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

На примјер, не морате писати, „git log # пронађи комит; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;“

Умјесто тога, напишите: „Примените cherry-pick на комит на чисту грану. Ријешите конфликте чувајући намјеру. Ако не може чисто проћи, објасните зашто.“

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

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

На крају, ако постоји било који дио који је услован или изузетно обиман, извадите га из SKILL.md, који је чвориште, и ставите га у једну од спољних датотека. Ставите га у помоћну датотеку која се може постепено учитавати, а у то ћемо ући у наставку.

Корак 3: Користите хијерархију

Искористите хијерархију вјештина када имате скрипту, референце или користите неки специфичан алат:

Preporučena upotreba skripti, referenci, resursa i konfiguracije unutar vještine.

За било шта што је условно или се грана од главне вјештине, раздвојите га у фасциклу. Запамтите такође да се вишестепена хијерархија може користити за посебно сложене вјештине. За ове ћете жељети да пажљиво размислите да ли функционалност треба да буде имплементирана монолитно или као колекција вјештина (можда са односима учитавања заснованим на depends:).

Корак 4: Итерирајте

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

Вјероватно ћете направити многе мале промјене ријечи. Мале промјене ријечи у описима могу имати превелики утицај на рутирање (укључујући преливајуће ефекте на друге вјештине), зато уради сав тај посао прије Корака 5.

Корак 5: Испоручите

Испоручите то.

Како одржавати вјештину

Сада када сте написали вјештину, морате је одржавати.

Замајац замки

Од овог тренутка па надаље, ваша листа замки има тенденцију да расте или се много мијења. Често виђамо инжењере који праве PR-ове који нису евалуирани, на примјер, мијењају опис. Ако мијењате опис након што је ваша вјештина спојена, скинули сте се са пута. Ако правите промјене на ономе што одлучује да ли да рутира вашу вјештину, морате написати неке евал-ове који подржавају промјене.

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

Агент не успије у нечему → Додај замку

Агент учитава вјештину ван циља → Затегни опис и додај негативне евал-ове

Агент не учитава вјештину када би требало → Додај кључне ријечи и позитивне евал-ове

Системски промпт се мијења → Провјери контроверзу или дуплирање

Лако је примијетити један случај неуспјеха у интрном тестирању или у продукцији и додати замку. То је негативан примјер тако да заправо не мијења експлицитно упутство, али омогућава моделу да зна: „Еј, постоји ова позната грешка.“

Како прелазите са 80-20 на постизање стопе успјеха од 99,9% или 99,99%, лако је повећати ову листу замки. Како видите ове негативне примјере, требало би углавном да додајете у секцију замки. Не би требало да додајете дужа упутства или мијењате опис.

Суити евалуације

У компанији Perplexity изводимо многе евал суите да провјеримо различите ствари. Постоје учитавање вјештине и читање датотека вјештина, што провјерава прецизност, опозив и забрањене провјере самог учитавања вјештине. Да ли ће агент рутирати вашу вјештину када би требало? Ови осигуравају да нове вјештине не руше постојеће границе.

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

Такође постоје евал-ови за вјештине који тестирају завршетак задатка од краја до краја у оквиру домена. Покрећем комплетну петљу агената и користимо LLM судију да оцјени резултате на основу рубрике добро дефинисаних критеријума.

Коначно, важно је покренути ове евал-ове против различитих модела. Computer подржава најмање три различите породице модела оркестрације: GPT, Claude Opus и Claude Sonnet. Желите да покренете учитавање вјештине и вјештине домена против ових различитих оркестратора агената како бисте били сигурни да не добијате различито понашање. Sonnet и GPT се понашају сасвим другачије када су у питању вјештине.

Коначне мисли и закључци

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

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

Можете ли аутоматизовати постмортеме? Можете ли прегледати захтјеве за повлачење? Било који задатак који можете урадити, можете барем имати да први пролаз буде вјештина агента. То ће вам уштедјети значајно вријеме.

Уз то, запамтите да вјештина није лака нити чак увијек неопходна. Мање је више. Неколико других закључака:

Напишите евал-ове прије вјештине. Укључите негативне примјере и забрањена учитавања за сусједне али различите вјештине.

Опис је тежак дио. „Учитај када...“ (свака ријеч кошта пажњу).

Замке су садржај изузетно високе вриједности. Почните танко, растите како агент не успије.

Запамтите да је лако разбити друге претходно постојеће вјештине додавањем нове вјештине, иако је нисте додирнули (чувајте се дјеловања на даљину).

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

Цитирање

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}