Perplexity компаниясында агент skill-дерін жобалау, жетілдіру және техникалық қолдау көрсету
Perplexity агент skill-дерін қалай жазады, тексереді және қолдайды, сондай-ақ инженерлеріміз оларды құру үшін пайдаланатын нұсқаулық.
Perplexity компаниясының шекті агент өнімдері модульдік Agent Skills ішінде жинақталған тәжірибе мен салалық білімге негізделген. Біз техникалық ортамызда мұқият іріктелген Skill кітапханасын сақтаймыз. Бұл Skill-дерге Perplexity Computer жұмысын қамтамасыз ететін көптеген жалпы мақсаттағы утилиталар; қаржы, заң және денсаулық сақтау сияқты салаларға арналған вертикалды мүмкіндіктер; және пайдаланушы қажеттіліктерін қанағаттандыруға арналған модульдердің өте ұзын тізбегі кіреді. Кейбір Skill-дер сирек шақырылады, бірақ шақырылған кезде өте маңызды. Пайдаланушы тәжірибесінің әрқашан тамаша болуын қамтамасыз ету үшін Perplexity агенттер командасы Skill сапасына код сапасы сияқты басымдық береді.
Жоғары сапалы Skill әзірлеу үшін қажетті интуиция мен озық тәжірибелер дәстүрлі бағдарламалық жасақтаманы құру үшін қажеттілерден айтарлықтай ерекшеленеді. Агенттер командасы өз жұмысы барысында Skill әзірлейтін мықты инженерлердің көптеген pull request сұрауларын тексереді. Нәтижесінде әрқашан дерлік көптеген түсініктемелер мен түзету ұсыныстары беріледі. Себебі код жазудың көптеген пайдалы үлгілері Skill жасауда антипатернге айналады.
Мысалы, PEP20 – The Zen of Python афоризмдерінің кейбірін алсаңыз, жақсы Python кодын жазу жақсы Skill жазудан мүлде бөлек екені тез түсінікті болады. 20 дана даналық жолының кем дегенде жартысы Skill жазған кезде толығымен қате немесе белсенді түрде жаңылыстыратын болып табылады. Міне, солардың бесеуі:
Zen of Python | Zen of Skills |
Қарапайым күрделіден жақсырақ | Skill — бұл файл емес, папка. Күрделілік — бұл мүмкіндік. |
Анық нәрсе жасырыннан жақсырақ | Активация — бұл жасырын үлгіні сәйкестендіру. Біртіндеп ашу. |
Сирек тығыздан жақсырақ | Контекст қымбат тұрады. Токен сайынғы максималды сигнал. |
Ерекше жағдайлар ережені бұзатындай ерекше емес | Мәселелер (gotchas) — бұл нақты ерекше жағдайлар (олар ең жоғары құнды мазмұн). |
Егер іске асыруды түсіндіру оңай болса, бұл жақсы идея болуы мүмкін | Егер оны түсіндіру оңай болса, модель оны бұрыннан біледі. Оны жойыңыз. |
Python тіліндегі Zen мен Skills жазуға арналған мақала нұсқауы арасындағы бес айырмашылық.
Бұл нұсқаулық — Perplexity инженерлері Skill әзірлеу және шолу кезінде пайдаланатын құжат. Сондай-ақ біз бұл нұсқаулықты көпшілікке ұсынып отырмыз, осылайша біздің жаңалықтарымыз бен тәжірибеміз кең қауымдастыққа пайда әкеледі. Күнделікті жұмысыңызда өндірістік Skill жасайтын инженер болсаңыз да, өзіңізге ең жақсы таныс сала бойынша өз Skill-іңізді әзірлегіңіз келетін Computer пайдаланушысы болсаңыз да немесе екеуі де болсаңыз да, бұл нұсқаулық сізге арналған.
Skill дегеніміз не?
Skill жазған кезде сіз жай ғана ескі бағдарламалық жасақтама жазып жатпайсыз (қазір Skill-дер агент жүйелерінің негізгі логикалық қозғалтқыштарының бөлігі болса да). Керісінше, сіз модельдер мен олардың ортасы үшін контекст құрып жатырсыз. Skill-дің басқа шектеулері мен басқа дизайн принциптері болады. Егер сіз Skill-ді код жазғандай жазсаңыз, сәтсіздікке ұшырайсыз.
Skill — бұл кем дегенде төрт нәрсе, әсіресе оларды Perplexity-те құру контекстінде.
Skill — бұл каталог
Skill — бұл тек бір SKILL.md файлы емес. Көп жағдайда Skill бірнеше файлды қамтиды. Skill атымен аталған каталог астында мыналар болуы мүмкін:
SKILL.md: frontmatter және нұсқаулар
scripts/: агент қайта ойлап таппайтын, орындайтын код
references/: ауыр құжаттар, шартты түрде жүктеледі
assets/: үлгілер, схемалар және деректер
config.json: бірінші рет іске қосу кезіндегі пайдаланушыны орнату
Бұл «хаб және спиц» (hub-and-spoke) үлгісі Skill-дерді өте шоғырланған және жинақы ұстауға мүмкіндік береді, сонымен қатар қалта құрылымын өте шығармашылық жолмен пайдалануға болады. Кейде әсіресе күрделі Skill-дер модельге жақсырақ бағдар жасауға көмектесу үшін иерархияның бірнеше деңгейлерінен пайда көреді. Егер Skill 20 пәндік салаға топтастырылатын 300 тақырып бойынша білімді қажет етсе делік. 300 тақырыптың ішінен дұрыс тақырыпты сенімді түрде таңдау — тіпті бүгінгі ең жақсы шекті модельдер үшін де шешілмеген міндет. Модель үшін осы аймақтағы 15 тақырыптың арасынан емес, 20 аймақтың біреуін таңдау — әлдеқайда оңайырақ таңдау мәселесі.
Көп деңгейлі иерархияның қалай құндылық беретінінің бір мысалы ретінде біздің команда өткен салық маусымында Computer-дің АҚШ-тағы табыс салығы мүмкіндіктерін қамтамасыз ететін Skill ішінде үш деңгейлі тақырыптық сатылауды қолданды. Салық заңнамасының күрделілігін ескерсек, бұл иерархия өте қажет болды: біздің алғашқы тесттерімізде модельге АҚШ-тың Ішкі кірістер кодексінің барлық 1 945 бөлімін қамтитын бір ғана қалтаны ұсыну Skill-ді мүлде жүктемегеннен де нашар нәтиже берді. Ақпаратты логикалық бөлімшелерге ұйымдастыру жоғары дәлдіктегі оқу операцияларын қамтамасыз ету үшін өте қажет болды.
Алайда бұл иерархия тегін келген жоқ. Иерархия деңгейлерінің артуы нәтижесіндегі жанамалықты басқару үшін ақпараттық архитектура бойынша күтім жасау деңгейлерін арттыруды талап етеді. Біз модельге ақпаратты минималды жанамалықпен табуға көмектесу үшін жылдам анықтамалық нұсқаулықтарды, реттелетін іздеу утилиталарын және басқа құралдарды жасадық. Бұл жағдайда караттаудың қиын жұмысын жасау сайып келгенде оң нәтиже берді: бұл модельдерге салыққа қатысты тапсырмаларды жалпы құралдарды ғана пайдалануға қарағанда әлдеқайда қабілетті түрде орындауға мүмкіндік беретін Skill болды.
Skill — бұл формат
Skill — бұл формат. Негізгі түбірлік SKILL.md файлының атауы да, сипаттамасы да болуы керек. Бұған қоса, Skill ол орналасқан каталог атауына дәл сәйкес келуі тиіс. Атауы толықтай кіші әріптермен жазылуы, бос орынсыз болуы және дефистерді қолдана алуы керек. Сипаттама — маршруттау триггері. Бұл — жиі кездесетін сәтсіздік нүктесі: сипаттама Skill не істейтінінің ішкі құжаттамасы емес. Ол модельге Skill-ді қашан жүктеу керектігі туралы нұсқауларға тең. Сондықтан сіз жиі «Load when» дегенді көресіз, ал «This Skill does» дегенді емес. Бұл маңызды, өйткені көптеген іске асырулар сипаттаманы модель контекстіне енгізетін тәсілге байланысты.
Frontmatter ішінде сондай-ақ “depends:” бар, ол иерархиялық Skill тәуелділіктерін жасауға мүмкіндік береді, және “metadata:”, ол шолулар мен бағалаулар үшін пайдаланылады. Әртүрлі агенттік жүйелер тіпті өздерінің frontmatter өрістерін анықтай алады, оларды сол жүйелерге тән тәсілмен қолдану үшін. Балама ретінде, Skill-ге тән метадеректерді қосымша JSON немесе YAML конфигурация файлына орауға болады. Бұл әрбір Skill үшін орындалу уақытының әртүрлі мінез-құлық түрлерін қамтамасыз етуі қажет агенттік жүйелерді құру кезінде, модельдің контекстін ұсақ-түйекпен ластамай, ыңғайлы. Ақырында, ұқсас мінез-құлықты Skill frontmatter-ын оқу кезінде алып тастау арқылы да алуға болады. Computer осы әдістемені қолданады, бұл конфигурацияны түбірлік SKILL.md файлында сақтауға мүмкіндік береді. Талдау логикасында егжей-тегжейге мұқият көңіл бөлу қажет, әрі модель контекстінде болғаны пайдалы болатын кейбір өрістер болса, шартты түрде алып тастауды іске асырғыңыз келуі мүмкін.
Skill — шақырылатын нысан
Skill шақырылатын болып табылады. Агент Skill-ді жұмыс уақытында жүктейді. Маңыздысы, Skill-дер әрқашан контекстке біріктірілмейді. Әдепкі бойынша, көптеген агент жүйелері Skill-дерді нақты қажеттілікке байланысты біртіндеп ашады.
Computer-де Skill-дерді іске асырғанымызда контекст шығындарының кем дегенде үш деңгейі бар. Бұл процесс төмендегідей:
Computer функцияны шақырады: load_skill(name="...")
Computer оқшауланған орындау sandbox ішіне Skill каталогын көшіреді
Computer «depends:» тегіндегі тәуелділіктерді рекурсивті түрде автоматты түрде жүктейді
Содан кейін Computer frontmatter жояды, нәтижесінде агент тек негізгі бөлікті және қосымша файлдарды көреді
Әртүрлі агент жүйелері Skill мазмұнын әртүрлі жолмен көрсетуді таңдай алады. Мысалы, кейбір жүйелер файл иерархиясын мүлде көрсетпеуді таңдауы мүмкін, бұл модельге файлдық жүйе операциялары арқылы иерархияны табуды қалдырады. Басқа жүйелер модельге белгілі бір қысқартуға және/немесе тереңдік шегіне дейін бүкіл файл ағашының картасын беруді таңдауы мүмкін. Контекстті таза ұстау үшін Computer шақыру контекстінен толық файл иерархияларын алып тастайды; алайда, бұл әр Skill үшін қайта анықталуы мүмкін.
Skill — бұл прогрессивті құрылым
Skill-дер прогрессивті болып табылады. Computer-де контекст шығындарының үш түрлі деңгейі бар және біз әртүрлі кезеңдерде үшеуін де көтереміз:
Деңгей | Не жүктеледі | Бюджет | Қашан төлейсіз |
Индекс | name: әрбір жасырын емес Skill үшін сипаттама | Әр Skill үшін ~100 токен | Әр сеанс, әр пайдаланушы, әрқашан төленеді |
Жүктеу | Толық SKILL.md денесі | ~5 000 токен | ~5 000 токен |
Орындалу уақыты | scripts/, references/, assets/, subskills, FORMATTING.md, SPECIAL_CASES.md ішіндегі файлдар | Шектелмеген | Тек агент оларды оқыған кезде |
Skill контекстінің үш деңгейі: индекс, толық Skill жүктемесі және орындалу уақытындағы анықтама файлдары.
Computer барлық қолжетімді Skill үшін атауы мен сипаттамасы бар Skill индексін құрады. Бұл үшін бюджет әр Skill үшін шамамен 100 токенді құрайды (қысқа болса, тіпті жақсы). Бұл өте тығыз, өйткені сіз бұл шығынды әр сеанста, әр пайдаланушы үшін төлейсіз. Бұл әңгіменің басында жүйелік шақыруға (system prompt) енгізіледі. Модель «load_skill()» шақыру керектігін шешу үшін бірқатар аталған Skill-дер мен сипаттамаларға қол жеткізе алады. Бұл индекске кіру шегі өте жоғары. Сіздің Skill-іңіз өте пайдалы болуы керек, ал сипаттамасы өте тығыз және қысқа болуы тиіс, өйткені бәрі бұл құнды әрқашан төлеп жатыр.
Агент жүйесі Skill-ді жүктегеннен кейін, толық SKILL.md денесі болады. Идеал жағдайда негізгі мәтін 5 000 токеннен аспауы керек. Тіпті сонда да әр сөйлемнің маңызды болғанын қалайсыз, өйткені Skill-ді жүктегеннен кейін, әңгіменің қалған бөлігі ықшамдау шегіне жеткенше оны төлеуі керек. Көптеген тредтер үш пен бес түрлі Skill арасында кез келгенін жүктеп, бұл құнды көбейтеді. Көп қажетсіз мәліметтері бар Skill-дер басқа Skill-дерді, сондай-ақ жалпы агенттік мүмкіндіктерді нашарлататыны сөзсіз. Қысқаша айтканда, егер сіздің Skill-іңіз жүктеліп, дұрыс әрекет етпесе, бұл босқа кеткен контекст.
Прогрессияның соңғы деңгейі — скрипттер немесе арнайы жағдайлар, мысалы, субскиллдер немесе пішімдеу. Бұл шектелмеген шартты тармақталған логиканы орналастырғыңыз келетін жер. Агент оны тек қажет болған кезде ғана пайдаланады, яғни мұнда орналастырғыңыз келетін нәрсе үшін әлдеқайда төмен шек бар.
Индексте әрбір токен маңызды. Жүктелген Skill денесі бос ұсталады, ал орындалу уақыты ең еркін. Бұл 20 000 токен немесе нөл токен болуы мүмкін. Бұл модельдің контекстін прогрессивті түрде кеңейту туралы ойлануға болатын деңгей.
Skill қашан қажет?
Агенттер командасынан белгілі бір сала немесе қолдану жағдайы үшін Skill шынымен қажет пе деген сұрақ жиі қойылады. Бізде алғашқы принциптердің өзінен нақты жауап өте сирек болады. Мұны анықтаудың жалпы жолы — агентті Skill-сіз бастау, бірнеше негізгі сұрауларды орындау, содан кейін агенттің жақсы жұмыс істеп жатқанын не істемей жатқанын анықтау.
Skill қажет болғанда
Дайындалған модельдер үшін таратуда болатын көптеген тапсырмалар бар. Бұл әрекетті шақырудағы бір сөйлеммен жасай алмайтын белгілі бір жолмен өзгертуді қаласаңыз ғана Skill қолдануыңыз керек. Сондықтан, егер агент арнайы контекстсіз қателік жіберсе немесе іске қосу кезінде өте тұрақты болуыңыз керек кейбір сәйкессіздіктер немесе детерминизм болмауы орын алса, сізге Skill қажет.
Сіздің біліміңіз тұрақты болуы мүмкін, бірақ оқу деректерінде болмауы мүмкін. Шектеулер немесе кәсіпорынға тән жұмыс процестері болуы мүмкін, немесе бұл талғам мәселесі болуы мүмкін. Мысалы, бізде Computer-де Генри Модисетт (біздің дизайн бөлімінің басшысы) жазған дизайнға қатысты бірнеше Skill бар. Бұл Skill-дерде әрбір токеннің болуының себебі — Генридің веб-сайттар мен PDF файлдарын жасауға келгенде өте жақсы талғамы бар. Генри қандай қаріптерді қолдану керектігін және қандай қаріптерді қолданбау керектігін, бұл қаріптердің қалай сезілетінін және модель оқу деректерінен ғана үйрене алмайтын басқа да пікір мәселелерін көрсетеді.
Skill қажет емес кезде
Біз инженерлер ретімен орындалуы тиіс бірқатар git пәрмендерін жазған көптеген Skill-дерді көреміз. Бұл қажет емес, өйткені модель бұны қалай жасау керектігін бұрыннан біледі, яғни бұл тамаша құжаттама болып табылады, бірақ нашар Skill болып шығады.
Біз Skill-дер жүйелік шақырудағы (system prompt) нұсқауларды қайталайтын мысалдарды көреміз. Ол үшін Skill қажет емес. Сұраулардың көпшілігіне қатысты білім жаһандық контекстке енгізілуі керек, шартты түрде жүктелген Skill-ге емес.
Егер оны сақтай алатын уақытыңыздан тезірек өзгеретін нәрсе болса, сізге Skill қажет емес. Мысалы, егер сіз кейбір қашықтағы MCP соңғы нүктесіне кіріп жатсаңыз және оның құралдары немесе бұл құралдардың нұсқалары жиі өзгеретін болса, оларды Skill-ге енгізбеуіңіз керек. Егер оны жасасаңыз, соңында жай ғана ауытқу пайда болады және модель қателіктер жібереді.
Әрбір Skill — бұл салық
Skill-дегі әрбір сөйлемге қолдануға болатын пайдалы тест мынау: «Бұл нұсқаулық болмаса, агент бұл қате істер ме еді?» Егер сөйлем онда болуы міндетті болмаса, ол жерде болуға шыдамайды, өйткені бәрі бұл құнды әр жолы төлеп жатыр. Skill қосу не қоспау туралы шешім қабылдаған кезде, әр сеанс пен әр пайдаланушы токендерді талап ететін бұл салықты есте сақтаңыз.
Француз тілінде әлдеқайда жақсы естілетін келесі атақты дәйексөз «Мен бұл хатты тек оны қысқартуға уақытым болмағандықтан ғана ұзарттым» деп шамамен аударылады.
« 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
Паскаль сияқты, сіз әр Skill-ге уақыт бөлуіңіз керек. Қысқа Skill жазу қиын. Егер сіздің Skill-іңізді жазу оңай болса, ол шамадан тыс ұзын немесе болмауы тиіс. Жақсы Skill мүмкіндігінше қысқа болады.
Skill генерациясын бір ретте-ақ аяқтауға тырысып, бес минутта PR жіберетін болсаңыз, нәтижелердің сапасы, әдетте, төмен болады. Шын мәнінде, ерте зерттеулер көрсеткендей, егер сіз Skill жазу үшін LLM-дерді қолдансаңыз, LLM бұдан пайда көрмейтін болуы мүмкін: «Өздігінен жасалған Skill-дер орта есеппен ешқандай пайда бермейді, бұл модельдер өздері тұтынудан пайда көретін процедуралық білімді сенімді түрде авторлай алмайтынын көрсетеді.»
Skill қалай құруға болады
Басқаша айтқанда, сіз жазған кез келген Skill-ге өз пікіріңізді енгізуіңіз керек. Келесі қадамдарды орындаңыз.
0-қадам: Evals (Бағалауларды) жазу
Бағалаулардың кейбірін алдымен жазыңыз. Бағалау жағдайларын келесі көздерден алуға болады:
Нақты пайдаланушы сұраулары: өндірістен немесе сенім тобынан үлгі алу
Белгілі сәтсіздіктер: Skill болмағандықтан агент сәтсіздікке ұшырады
Көршілес шатасулар: Домен шекарасына жақын, бірақ басқа Skill-ге бағыттайды
Кем дегенде, қажет болған кезде Skill-дің жүктелетінін тексеріп жатқаныңызға көз жеткізуіңіз керек. Идеал жағдайда, олардың кейбірін, бәлкім, өндірістік ортадан үлгі аласыз. Сондай-ақ белгілі қате жағдайларын қарастыруға болады: бәлкім, Skill жазуды бастаған себебіңіз — сіз байқаған нақты сәтсіздік немесе бәлкім, сіз рефакторинг жасап жатқырсыз және бір Skill қамтитын екі жақын доменде қандай да бір шатасу бар.
Ұқсас теріс және оң мысалдардан бастаңыз. Теріс мысалдар өте қуатты және оң мысалдарға қарағанда маңыздырақ болуы мүмкін.
1-қадам: Сипаттама
Бұл Skill-дегі ең қиын жол. Бұл құжаттама емес, бағыттау триггері. Атауы мен сипаттамасын дұрыс алу үшін Skill мазмұны маңызды емес. Сізді тек Skill жүктеліп, дұрыс нүктелерде енгізілгені және басты сәтсіздік режимі болып табылатын мақсаттан тыс жанама әсерлері жоқтығы қызықтырады. Қосымша Skill қосқан сайын, әрбір басқа Skill-ді сәл нашарлатып алу қаупі бар, сондықтан регрессияны азайтып жатқаныңызға көз жеткізуіңіз керек.
Тағы да айта кетейік, нашар сипаттама Skill не істейтінін немесе не үшін пайдалы екенін сипаттайды. Жақсы сипаттама агент Skill-ді қашан жүктеу керектігін айтады. Мысалы, pull request-терді бақылауға арналған бірдеңеңіз бар делік. Skill не істейтінін жазбаңыз. Инженерлер өздерінің PR жұмыс істейтініне көз жеткізгісі келгенде ренжігенде айтатын сөздерін жазыңыз, мысалы, «бала күту» немесе «CI қарау» немесе «мұның орындалуын қамтамасыз ету».
Міне, жылдам бақылау тізімі:
"Load when..." басталады
50 немесе одан аз сөзді мақсат етіңіз
Пайдаланушының ниетін сипаттайды, идеалды түрде нақты сұраулардан
Жұмыс процесін қорытындыламайды
Нақты сұраулар — 80-20 ережесінде қамти алатын нәрселер. Әдетте, екі немесе үш мысал жақсы жұмыс істейді. Дәл және тек қажетінше қосу оңай емес.
2-қадам: Денені жазу
Содан кейін Skill-дің өзінің мазмұнын жазыңыз. Бұл 0-қадам немесе 1-қадам емес екенін ескеріңіз.
Жұмыс процестерін LLM-ге жеткізу жұмыс процестерін әріптеске немесе тіпті орындау уақыты жүйесіне жеткізуден мүлде өзгеше. Жаңа бағдарламалық құралды үйрену кезінде инженер құжаттаманы оқуы, тәжірибесі бар біреуден нұсқау алуы және құралды қалай пайдалану керектігін үйренуі қажет болуы мүмкін. Сонымен қатар, кем дегенде бір жыл бұрын болған кез келген бағдарламалық құрал үшін оның атауын атасаңыз жеткілікті және LLM-де өзіне қажет барлық ақпарат болады.
Денені жазған кезде анық нәрселерді өткізіп жіберіңіз. Көптеген инженерлер біреу орындауы тиіс әрбір пәрменді тізімдейтін readme.md файлдарын жазуда көп тәжірибеге ие. Skill жазып жатқанда оған қайта оралу оңай, өйткені бұл құжаттама жазып жатқандай сезіледі, бірақ мұны жасасаңыз, сіздің Skill қоқыс болып қалады. Сондықтан пәрмендер тізбегін жазбаңыз.
Мысалы, «git log # commit таңдау; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;» деп жазудың қажеті жоқ
Оның орнына «Commit-ті таза бұтаққа (branch) cherry-pick арқылы көшіріңіз. Ниетті сақтай отырып, қайшылықтарды шешіңіз. Егер ол таза түрде орындалмаса, не себепті екенін түсіндіріңіз» деп жазыңыз.
Модель соңғысымен, әсіресе қиындықтар туындаған кезде, біріншісінің тым нұсқамалық пәрмендер тізбегіне қарағанда әлдеқайда жақсы жұмыс жасайды. Шамадан тыс шектемеңіз немесе тым қатаң нұсқамалық болмаңыз, бұл нәзік болады, оның орнына бірнеше тәсіл жұмыс істей алатын жерде икемді болыңыз. Тағы да айта кетейік, адамдар үшін жақсы құжаттама көбінесе модельдер үшін нашар құжаттама болып табылады.
Содан кейін проблемаларға (gotchas) немесе теріс мысалдарға назар аударыңыз. Бұлар өте жоғары сигнал беретін мазмұн болып табылады, өйткені олар жиі модельге не істеу керектігін емес, не істемеу керектігін бағыттайды. Егер агент қателік жіберген сайын жол қоссаңыз, оны іске қосу арқылы үйренесіз және проблемалар органикалық түрде өседі.
Соңында, егер қандай да бір бөлік шартты немесе мазмұны жағынан өте ауыр болса, оны хаб болып табылатын SKILL.md файлынан шығарып, спицтердің (spokes) біріне қойыңыз. Оны біртіндеп жүктеуге болатын қосымша файлға қойыңыз, мұны келесі кезекте қарастырамыз.
3-қадам: Иерархияны пайдаланыңыз
Скрипт, сілтемелер болған кезде немесе қандай da бір арнайы құралды пайдаланып жатқанда Skill иерархиясын пайдаланыңыз:
scripts/ Агент әр іске қосу сайын қайта ойлап табатын детерминистік логика | Қайта құруға емес, құрастыруға код беріңіз |
references/ Шарт орындалғанда ғана жүктелетін ауыр құжаттар | "Егер API non-200 қайтарса, api-errors.md оқыңыз" |
assets/ Агент көшіріп алып, толтыратын шығыс үлгілері | report-template.md, шығыс схемалары |
config.json Бірінші рет іске қосу кезіндегі пайдаланушыны орнату | Slack арнасын сұраңыз, сақтаңыз және келесі жолы қайта пайдаланыңыз |
Skill ішіндегі сценарийлерді, анықтамаларды, активтерді және конфигурацияны пайдалану бойынша ұсыныстар.
Негізгі Skill-ден шартты немесе тармақталатын кез келген нәрсе үшін оны қалтаға бөліңіз. Сондай-ақ әсіресе күрделі Skill-дер үшін көп деңгейлі иерархияны пайдалануға болатынын есте сақтаңыз. Бұлар үшін функционалдықтың монолитті түрде немесе Skill жиынтығы ретінде іске асырылуы тиіс пе деген сұраққа мұқият ойлануыңыз керек (мүмкін depends: негізіндегі жүктеу қатынастарымен).
4-қадам: Итерациялау
Содан кейін бұтақта (branch) бірқатар итерациялар жасаңыз. Skill жоқ негізгі бұтақтан бастаңыз, кейбір итерацияларды жасаңыз, басты сұраулар жиынтығын құрыңыз және бірқатар бағалауларды орындаңыз. Skill кодын шолатын кез келген адам бағалау жиынтығымен бірге бір өзгерістер жиынтығын жібергеніңіз үшін сізге алғыс айтады. Қатарынан келетін қосымша өзгерістерді шолу (жаңа проблемадан басқа) өте қиын, сондықтан оны барынша азайтуға тырысыңыз.
Сіз көптеген шағын сөз өзгерістерін жасайтын шығарсыз. Сипаттамалардағы шағын сөз өзгерістері бағыттауға елеулі әсер етуі мүмкін (соның ішінде басқа Skill-дерге жанама әсерлері бар), сондықтан барлық бұл жұмысты 5-қадамға дейін орындаңыз.
5-қадам: Жіберу
Оны жіберіңіз.
Skill қалай қолдау көрсету керек
Skill жазғаннан кейін, оған техникалық қолдау көрсетуіңіз керек.
Проблемалардың маховигі (Gotchas Flywheel)
Бұдан бастап сіздің проблемалар тізіміңіз өсуге немесе көп өзгеруге бейім. Біз бағаланбаған PR-лар жасайтын, мысалы, сипаттаманы өзгертетін инженерлерді жиі көреміз. Егер сіз Skill біріктірілгеннен кейін сипаттаманы өзгертіп жатсаңыз, дұрыс жолда емессіз. Егер сіз Skill-дің бағытталуын шешетін нәрсеге өзгерістер енгізіп жатсаңыз, өзгерістерді қолдайтын кейбір бағалауларды жазуыңыз керек.
Skill-дер негізінен қосылатын болып табылады. Проблемалар бөлімі уақыт өте келе ең көп құндылық жинайды:
Агент бірдеңеде сәтсіздікке ұшырайды → Проблема қосу
Агент Skill-ді мақсаттан тыс жүктейді → Сипаттаманы қатайтып, теріс бағалауларды қосу
Агент тиіс болған кезде Skill-ді жүктемейді → Кілт сөздер мен оң бағалауларды қосу
Жүйелік нұсқаулық өзгерістері → Қайшылық немесе телнұсқалық бар-жоғын тексеру
Ішкі тестілеуде немесе өндірісте жалғыз сәтсіздік жағдайын байқап, проблема қосу оңай. Бұл теріс мысал, сондықтан ол нақты нұсқауды өзгертпейді, бірақ ол модельге «Эй, мынандай белгілі қате бар» деп хабарлайды.
80-20 ережесінен 99.9% немесе 99.99% сәттілік көрсеткішіне жетуге ауысқан кезде, бұл проблема тізімін өсіру оңай. Осы теріс мысалдарды көргенде, проблемалар бөліміне негізінен қосымша мәліметтер қосуыңыз керек. Сіз ұзағырақ нұсқаулар қоспауыңыз немесе сипаттаманы өзгертпеуіңіз керек.
Бағалау жиынтықтары (Eval Suites)
Perplexity компаниясында біз әртүрлі нәрселерді тексеру үшін көптеген бағалау жиынтықтарын іске қосамыз. Skill жүктеу және Skill файлын оқу бар, бұл Skill жүктеудің өзінің дәлдігін, толықтығын (recall) және тыйым салынған тексерулерін тексереді. Агент қажет болған кезде Skill-ді бағыттай ма? Бұлар жаңа Skill-дердің қолданыстағы шекараларды бұзбайтынына көз жеткізеді.
Тиісті прогрессивті жүктеуді тексере алатын бағалаулар да бар. Агент Skill жүктей алады, бірақ ол қосымша файлды немесе файлдарды оқи ма? Мысалы, егер сізде қаржылық сұрауларға арналған қаржылық Skill болса, ол арнайы FORMATTING.md файлын оқи ма?
Сондай-ақ домендер шегіндегі соңына дейін тапсырманы орындауды тексетін Skill-дер үшін бағалаулар бар. Біз толық агент циклін іске қосамыз және жақсы анықталған критерийлер жиынтығы негізінде нәтижелерді бағалау үшін LLM төрешісін пайдаланамыз.
Соңында, бұл бағалауларды әртүрлі модельдерге қарсы іске қосу маңызды. Computer кем дегенде үш түрлі оркестрлеу моделі отбасын қолдайды: GPT, Claude Opus және Claude Sonnet. Әртүрлі әрекетті алмағаныңызға көз жеткізу үшін Skill жүктеуді және домендік Skill-дерді осы әртүрлі агент оркестрлеушілеріне қарсы іске қосқыңыз келеді. Skill-дерге келгенде Sonnet пен GPT әртүрлі әрекет етеді.
Соңғы ойлар мен қорытындылар
Қаншалықты көп Skill құрсаңыз, оларды құруда соншалықты жақсара түсесіз. Егер сіз күнделікті өмірде атқарып жүрген тапсырмаларды Skill көмегімен автоматтандырмасаңыз немесе қайта өндірілетін етуге тырыспасаңыз, дереу бастаңыз.
Skill құру әрекеті сізді көбірек Skill құруға жақсартады, сонымен қатар олар бизнес процестерін автоматтандыруда өте жақсы. Егер сіз апта сайын стендап алдында, әр спринттің соңында немесе инженер ретінде күнделікті, апта сайынғы немесе тіпті тоқсан сайынғы негізде жасайтын кез келген нәрсені сипаттай алсаңыз, уақытыңызды қайтарып алу үшін Skill жазуыңыз керек.
Постмортемдерді автоматтандыра аласыз ба? Pull request-терді тексере аласыз ба? Өзіңіз жасай алатын кез келген тапсырма үшін бірінші кезеңді Agent Skill етіп жасай аласыз. Бұл сіздің уақытыңызды айтарлықтай үнемдейді.
Дегенмен, Skill оңай емес екенін немесе әрқашан қажет бола бермейтінін есте сақтаңыз. Азырақ болғаны жақсы. Бірнеше басқа қорытындылар:
Skill алдында бағалауларды жазыңыз. Жанама, бірақ бөлек skill-дер үшін теріс мысалдар мен тыйым салынған жүктемелерді қосыңыз.
Сипаттама — бұл қиын бөлік. "Load when..." (әр сөз назарды талап етеді).
Проблемалар — бұл өте жоғары құнды мазмұн. Жұқа болып бастаңыз, агент сәтсіздікке ұшыраған сайын өсіріңіз.
Жаңа Skill қосу арқылы бұрыннан бар басқа Skill-дерді бұзу оңай екенін есте сақтаңыз, тіпті оған тиіспеген болсаңыз да (қашықтықтағы әрекеттен сақ болыңыз).
Skill жазып және оған техникалық қолдау көрсеткен сайын барлық қолжетімді құралдарды пайдаланыңыз. Көбірек білгіңіз келсе, Agent Skills веб-сайтында көптеген жақсы мысалдар бар, ал біздің ішкі репозиторийіміз де, қоғамдық экожүйе де жақсы жобаланған Skill-дердің көптеген мысалдарын қамтиды.
Дәйексөз
@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}
}