Agentide oskuste kujundamine, lihvimine ja hooldamine Perplexity's

Perplexity eesliini agentide tooted põhinevad oskusteabel ja valdkondlikul ekspertiisil, mis on pakendatud modulaarsetesse Agent Skills moodulitesse. Hoiame oma tehnilistes keskkondades hoolikalt kureeritud oskuste teeki. Need oskused hõlmavad paljusid üldotstarbelisi utiliite, mis toetavad süsteemi Perplexity Computer; vertikaalispetsiifilisi võimalusi sellistes valdkondades nagu rahandus, õigusteadus ja tervishoid; ning väga pikka moodulite rida kasutajate vajaduste rahuldamiseks. Mõnda oskust kutsutakse harva, kuid need on kutsumisel kriitilise tähtsusega when. Järjepidevalt suurepärase kasutuskogemuse tagamiseks peab Perplexity agentide meeskond oskuste kvaliteeti sama oluliseks kui koodi kvaliteeti.

Kvaliteetse Skill väljatöötamiseks vajalikud intuitsioonid ja parimad tavad erinevad märkimisväärselt traditsioonilise tarkvara ehitamiseks vajalikest. Agentide meeskond vaatab läbi palju tõmbepäringuid (pull request) suurepärastelt inseneridelt, kes arendavad oma töös Skill-e. Tulemuseks on peaaegu alati arvukalt kommentaare ja ettepanekuid muudatusteks. Selle põhjus on, et paljud kasulikud mustrid koodi kirjutamiseks muutuvad Skill loomisel vastandmustriteks.

Kui võtta näiteks mõned aforismid teosest PEP20 – The Zen of Python, saab kiiresti selgeks, et hea Pythoni koodi kirjutamine erineb heade Skill-ide kirjutamisest. 20-st tarkuseterast on vähemalt pooled Skill-ide kirjutamisel täiesti valed või aktiivselt eksitavad. Siin on neist viis:

Viis vastandust Pythoni zen’i ja artikli juhiste vahel Skillsi kirjutamiseks.

See juhend on dokument, mida Perplexity insenerid Skill-ide arendamisel ja ülevaatamisel kasutavad. Avaldame selle juhendi ka laiemale avalikkusele, et meie avastused ja õppimiskogemused saaksid aidata laiemat kogukonda. Olenemata sellest, kas olete insener, kes kujundab oma igapäevatöös tootmiskõlblikke Skill-e, või Computer-i kasutaja, kes soovib arendada oma Skill-i teile kõige paremini teada olevas valdkonnas, või mõlemat, on see juhend teie jaoks.

Mis on Skill?

Kui kirjutate Skill-i, ei kirjuta te tavalist vana tarkvara (isegi kui Skill-id on nüüd agentide süsteemide peamiste loogikamootorite osa). Pigem ehitate mudelitele ja nende keskkondadele konteksti. Skill-il on erinevad piirangud ja erinevad disainipõhimõtted. Kui kirjutate Skill-i samamoodi nagu koodi, siis ebaõnnestute.

Skill on vähemalt neli asja, eriti arvestades seda, kuidas me neid Perplexity-s ehitame.

Skill on kataloog

Skill ei ole pelgalt üks SKILL.md fail. Paljudel juhtudel sisaldab Skill mitut faili. Teie Skill-i järgi nime saanud kataloogis võib teil olla:

SKILL.md: päisesisu ja juhised

scripts/: kood, mida agent käivitab, mitte ei mõtle uuesti välja

references/: põhjalikud dokumendid, mis laaditakse tingimuslikult

assets/: mallid, skeemid ja andmed

config.json: kasutaja esmase käivitamise seadistus

See jaotur-ja-kodara muster võimaldab hoida Skill-id väga keskendunud ja tihedad ning kaustastruktuuri saab kasutada väga loomingulisel viisil. Mõnikord on eriti keerulistest Skill-idest kasu mitmest hierarhia tasemest, et aidata mudelil paremini navigeerida. Oletame, et Skill nõuab teadmisi 300 teema kohta, mida saab rühmitada 20 ainevaldkonda. Õige teema usaldusväärne valimine 300 hulgast on lahendamata väljakutse isegi tänapäevaste parimate piirimudelite jaoks. Mudeli jaoks on palju lihtsam valikuprobleem keskenduda ühele 20 valdkonnast kui 15 teemale selle valdkonna sees.

Ühe näitena sellest, kuidas mitmetasandiline hierarhia väärtust loob, kasutas meie meeskond sel maksuhooajal Computer-i USA tulumaksu võimalusi tagavates Skill-ides kolme temaatilise pesastuse taset. See hierarhia oli maksuseaduste keerukust arvestades täiesti asendamatu: meie varajastes testides tõi mudelile üheainsa kausta esitamine, mis sisaldas kõiki USA sisemise tuluseadustiku (Internal Revenue Code) 1945 jaotist, kaasa halvema jõudluse kui Skill-i laadimata jätmine. Teabe korraldamine loogilisteks alajaotusteks oli ülioluline suure täpsusega lugemistoimingute tagamiseks.

Ometi ei tulnud see hierarhia tasuta. Kasvavad hierarhia tasemed nõuavad teabearhitektuuris üha suuremat kureerimistaset, et hallata tulenevat kaudsust. Lõime kiirjuhendid, kohandatud otsinguutiliidid ja muud tööriistad, et toetada mudelit teabe leidmisel minimaalse kaudsusega. Sel juhul andis kureerimise ränk töö lõpuks positiivse tulemuse: Skill, mis võimaldas mudelitel täita maksuga seotud ülesandeid palju pädevamalt kui pelgalt üldiste tööriistade kasutamine.

Suurenda

Skill on vorming

Skill on vorming. Peamisel juurfailil SKILL.md peab olema nii nimi kui ka kirjeldus. Lisaks peab Skill täpselt vastama kataloogi nimele, kus Skill asub. Nimi peab koosnema ainult väiketähtedest, ei tohi sisaldada tühikuid ja võib kasutada sidekriipse. Kirjeldus on marsruutimise päästik. See on tavaline ebaõnnestumise punkt: kirjeldus ei ole sisemine dokumentatsioon selle kohta, mida Skill teeb. See kujutab endast juhiseid mudelile selle kohta, millal Skill laadida. Seetõttu näete sageli fraasi „Laadi, kui...“, mitte „See Skill teeb...“. See on oluline viisi tõttu, kuidas enamik teostusi süstib kirjelduse mudeli konteksti.

Esilehe sisu (frontmatter) sees on ka „depends:“, mis võimaldab luua hierarhilisi Skill-i sõltuvusi, ja „metadata:“, mida kasutatakse ülevaatusteks ja hindamisteks. Erinevad agentsüsteemid saavad isegi määratleda oma esilehe väljad, mida kasutatakse nende süsteemide jaoks spetsiifilisel viisil. Alternatiivina saab Skill-i spetsiifilised metaindmed pakendada abistavasse JSON-i või YAML-i konfiguratsioonifaili. See on soovitav agentide süsteemide ehitamisel, mis peavad hõlbustama erinevat tüüpi käitusaegset käitumist Skill-i kohta, ilma et mudeli kontekst risustataks pisiasjadega. Lõpuks on sarnane käitumine saavutatav Skill-i esilehe eemaldamise teel lugemisel. Computer kasutab seda metoodikat, mis võimaldab konfiguratsiooni säilitada juurfailis SKILL.md. Analüüsiloogikas on vaja pöörata suurt tähelepanu detailidele ja võib-olla soovite rakendada tingimuslikku eemaldamist, kui teatud väljad on mudeli kontekstis kasulikud.

Skill on väljakutsutav

Skill on väljakutsutav. Agent laadib Skill-i käitusajal. Oluline on see, et Skill-e ei pakendata alati konteksti. Vaikimisi avavad enamik agentide süsteeme Skill-e järk-järgult vastavalt konkreetsele vajadusele.

Computer-is Skill-ide rakendamise viisis on vähemalt kolm kontekstikulude taset. Siin on protsess:

Computer kutsub esile funktsiooni load_skill(name="...")

Computer kopeerib Skill-i kataloogi isoleeritud täitmise liivakasti

Computer laadib siltides „depends:“ olevad sõltuvused rekursiivselt automaatselt

Seejärel eemaldab Computer esilehe ja agent näeb seega ainult põhiosa ja lisafaile

Erinevad agentsüsteemid võivad valida Skill-i sisu esitamise erineval viisil. Näiteks võivad mõned süsteemid valida failihierarhia esitamata jätmise, jättes mudelile ülesandeks failisüsteemi toimingute kaudu hierarhia avastada. Teised süsteemid võivad anda mudelile kogu failipuu kaardi kuni teatud kärpimise ja/või sügavuse piirini. Konteksti puhtana hoidmiseks jätab Computer väljakutsekontekstist välja täielikud failihierarhiad; seda saab aga Skill-ipõhiselt tühistada.

Skill on progressiivne

Skill-id on progressiivsed. Computer-is on kolm erinevat kontekstikulude taset ja me kanname neid kõiki eri etappides:

Skillsi konteksti kolm taset: indeks, täielik Skilli laadimine ja käitusaja viitefailid.

Computer ehitab Skill-i indeksi, millel on iga saadaoleva Skill-i nimi ja kirjeldus. Selle eelarve on umbes 100 tokenit Skill-i kohta (lühem on veelgi parem). See on nii kitsas, kuna maksate seda kulu igas seansis iga kasutaja eest. See süstitakse süsteemi viipasse vestluse alguses. Mudelil on juurdepääs hulgale nimetatud Skill-idele ja kirjeldustele, et see saaks otsustada, kas kutsuda esile „load_skill()“. Sellesse indeksisse saamise latti seatakse äärmiselt kõrgele. Teie Skill peab olema väga kasulik ja kirjeldus peab olema äärmiselt tihe ja napp, kuna kõik maksavad kulu kogu aeg.

Pärast seda, kui agentsüsteem on Skill-i laadinud, on olemas täielik SKILL.md põhiosa. Ideaalis ei ületa põhiosa tekst 5000 tokenit. Isegi siis soovite, et iga lause loeks, sest kui olete Skill-i laadinud, peab ülejäänud vestlus seda kulu kandma kuni tihenduspiirini. Paljud lõimed laadivad kolm kuni viis erinevat Skill-i, mitmekordistades seda kulu. Palju täitematerjaliga Skill-id halvendavad peaaegu kindlasti teisi Skill-e ja ka üldisi agendivõimeid. Lühidalt, kui teie Skill laaditakse ja see ei tee õiget asja, on see raisatud kontekst.

Progresseerumise viimane tase on skriptid või erijuhud, näiteks alamoskused või vormindamine. Siia soovite paigutada piiramatu tingimusliku hargneva loogika. Agent kasutab seda ainult siis, kui ta seda vajab, mis tähendab, et siia paigutatavale sisule on seatud palju madalam latt.

Indeksis on iga token oluline. Laaditud Skill-i põhiosa on vabam ja käitusaeg on kõige vabam. See võib olla 20 000 tokenit või null tokenit. See on tase, mille puhul võite mõelda mudeli konteksti laiendamisele progressiivsel viisil.

Millal on teil Skill-i vaja?

Agentide meeskonnal palutakse sageli avaldada arvamust selle kohta, kas konkreetse valdkonna või kasutusjuuhu jaoks on Skill-i tõeliselt vaja. Meil on harva ühest vastust pelgalt esmastest põhimõtetest lähtuvalt. Ainus viis selle väljaselgitamiseks on alustada oma agendiga ilma Skill-ita, käivitada mitu põhipäringut ja seejärel selgitada välja, kas agent teeb head tööd.

Millal on vaja Skill-i

On palju ülesandeid, mis on treenitud mudelite jaoks jaotuses. Peate Skill-i rakendama ainult siis, kui soovite seda käitumist muuta mingil konkreetsel viisil, mida te ei saa teha näiteks ühe lausega oma viibas. Seega on teil Skill-i vaja siis, ilma erikontekstita teeb agent vea või kui esineb ebajärjekindlust või mittedeterminismi, mida peate käitamiste vahel äärmiselt järjekindlana hoidma.

Võib juhtuda, et teie teadmised on vastupidavad, kuid neid ei ole treeningandmetes. Võib esineda piiranguid või ettevõttespetsiifilisi töövooge või võib see olla maitseküsimus. Näiteks on meil Computer-is mitu Henry Modisetti (meie disainijuht) kirjutatud disainiga seotud Skill-i. Põhjus, miks iga token nendes Skill-ides eksisteerib, on see, et Henryl on veebisaitide ja PDF-ide kujundamisel väga hea maitsekasutus. Henry määrab, milliseid fonte kasutada ja milliseid mitte, kuidas need fondid tunduvad (feel) ja muud otsustusküsimused, mida mudel ei saa õppida ainult treeningandmetest.

Millal te Skill-i ei vaja

Näeme palju Skill-e, millesse insenerid on kirjutanud rea git-käsusid, mida tuleb täitmiseks järjest käivitada. See on ebavajalik, kuna mudel juba teab, kuidas seda teha, mis tähendab, et see loob suurepärase dokumentatsiooni, kuid kehva Skill-i.

Näeme näiteid, kus Skill-id kordavad süsteemi viiba juhiseid. Te ei vaja selleks Skill-i. Suurema osa päringute jaoks olulised teadmised tuleks lisada globaalsesse konteksti, mitte tingimuslikult laaditud Skill-i.

Kui midagi muutub kiiremini, kui suudate seda hooldada, ei ole teil Skill-i vaja. Näiteks kui kasutate mingit eemaldas asuvat MCP lõpp-punkti ja selle tööriistad või nende tööriistade versioonid muutuvad sageli, ei tohiks te neid Skill-i süstida. Kui te seda teete, lõpeb see lihtsalt triivimisega ja mudel teeb vigu.

Iga Skill on maks

Siin on kasulik test, mida saate rakendada igale oma Skill-i lausele: „Kas agent teeks selle juhiseta vea?“ Kui lause ei pea seal olema, ei saa see endale lubada seal olemist, sest kõik maksavad seda kulu iga kord. Kui otsustate, kas lisada Skill või mitte, pidage meeles seda maksu, mille korral iga seanss ja iga kasutaja maksab tokeneid.

Järgmine kuulus tsitaat, mis kõlab prantsuse keeles palju paremini, tähendab ligikaudu: „Olen teinud selle kirja pikemaks ainult seetõttu, et mul ei olnud aega seda lühemaks teha.“

« 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

Nagu Pascal, peate ka teie investeerima aega igasse Skill-i. Lühikest Skill-i on raske kirjutada. Kui teie Skill-i on lihtne kirjutada, on see tõenäoliselt liiga pikk või ei tohiks seda olemas ollagi. Hea Skill on nii lühike kui võimalik.

Kui leiate, et proovite teha ühekordset (one-shot) Skill-i genereerimist ja esitada tõmbepäringuid viie minutiga, on tulemused peaaegu kindlasti keskpärased. Tegelikult on varajased uuringud näidanud, et kui kasutate LLM-e Skill-ide kirjutamiseks, ei pruugi LLM sellest kasu saada: „Ise genereeritud Skill-id ei paku keskmiselt mingit kasu, mis näitab, et mudelid ei suuda usaldusväärselt luua protseduurilisi teadmisi, mille tarbimisest nad kasu saavad.“

Kuidas ehitada Skill-i

Teisisõnu, peate süstima oma arvamuse igasse kirjutatavasse Skill-i. Järgige neid samme.

0. samm: kirjutage hindamiskomplektid (Evals)

Kirjutage kõigepealt mõned hindamistestid (evals). Saate hankida hindamisjuhte järgmistest allikatest:

Reaalsed kasutaja päringud: valim tootmisest või oma usaldusringist

Tuntud vead: Agent ebaõnnestus, kuna Skill-i polnud olemas

Naabri segadus: Teie domeeni piiri lähedal, kuid marsruuditakse teise Skill-i juurde

Vähemalt peaksite veenduma, et testite Skill-i laadimist vajaduse korral. Ideaalis võtate nendest valimi, võib-olla tootmiskeskkonnast. Võite kaaluda ka teadaolevaid veajuhte: võib-olla on kogu teie Skill-i kirjutamise põhjus tingitud konkreetsest veast, mida märkasite, või teete refaktoreerimist ja kahes lähedases valdkonnas, mida katab üks Skill, esineb segadust.

Alustage sarnaste negatiivsete ja positiivsete näidetega. Negatiivsed näited on äärmiselt võimsad ja võivad olla olulisemad kui positiivsed näited.

1. samm: kirjeldus

See on Skill-i kõige raskem rida. See on marsruutimise päästik, mitte dokumentatsioon. Nime ja kirjelduse õigeks saamiseks ei huvita teid Skill-i sisu. Teid huvitab ainult see, kas Skill laaditakse ja süstitakse õigetes kohtades ning see on vaba kõrvalmõjudest, mis on peamine ebaõnnestumise režiim. Iga kord, kui lisate täiendava Skill-i, riskite iga teise Skill-i veidi halvendamisega, nii et peate tagama regressiooni minimeerimise.

Veelkord, halb kirjeldus kirjeldab, mida Skill teeb või miks see kasulik on. Hea kirjeldus ütleb, millal agent peaks Skill-i laadima. Oletame näiteks, et teil on midagi tõmbepäringute (pull requests) jälgimiseks. Ärge kirjutage seda, mida Skill teeb. Kirjutage see, mida insenerid ütlevad, kui nad on pettunud ja soovivad, et te veenduksite, et nende tõmbepäring töötab, näiteks „kantselda“ (babysit), „jälgi CI-d“ (watch CI) või „veendu, et see jõuaks maabumiseni“ (make sure this lands).

Siin on kiire kontrollnimekiri:

Algab fraasiga „Laadi, kui...“ (Load when...)

Sihtige 50 sõna või vähem

Kirjeldab kasutaja kavatsust, ideaalis reaalsetest päringutest

Ei võta töövoogu kokku

Reaalsed päringud on see, mida saate katta 80-20 reegliga. Tavaliselt toimivad hästi kaks või kolm näidet. Täpselt ja ainult niipalju lisamine, kui vajate, ei ole lihtne.

2. samm: kirjutage põhiosa

Järgmisena kirjutage Skill-i sisu ise. Pange tähele, et see ei ole 0. ega 1. samm.

Töövoogude edastamine LLM-ile on täiesti erinev töövoogude edastamisest kolleegile või isegi teie käitussüsteemile. Uue tarkvaratööriista õppimisel võib insener vajada dokumentatsiooni lugemist, kogemustega inimeselt juhendi saamist ja tööriista kasutamise õppimist. Samal ajal peate peaaegu iga tarkvaratööriista puhul, mis on eksisteerinud vähemalt aasta, vaid mainima selle nime ja LLM-il on kogu vajalik teave olemas.

Põhiosa kirjutamisel jätke ilmselged asjad vahele. Paljudel inseneridel on palju kogemusi readme.md failide kirjutamisega, mis loetlevad üles iga käsu, mida keegi peab käivitama. Skill-i kirjutamisel on lihtne selle juurde tagasi pöörduda, kuna see tundub nagu dokumentatsiooni kirjutamine, kuid kui te seda teete, on teie Skill prügi. Seega ärge kirjutage välja käskude seeriat.

Näiteks ei pea te kirjutama: „git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;“

Selle asemel kirjutage: „Tehke commit'ile cherry-pick puhtale harule. Lahendage konfliktid, säilitades kavatsuse. Kui see ei saa puhtalt maabuda, selgitage miks.“

Mudel teeb viimasega palju paremat tööd kui esimese ülemäära ettekirjutava käskude jadaga, eriti kui asjad lähevad valesti. Ärge suunake liiga rangelt ega olge ülemäära ettekirjutav, mis on habras, vaid olge paindlik seal, kus mitu lähenemist võivad toimida. Veelkord, hea dokumentatsioon inimestele on enamasti halb dokumentatsioon mudelitele.

Järgmisena keskenduge komistuskividele või negatiivsetele näidetele. Need on äärmiselt suure signaaliga sisu, kuna need juhivad mudelit sageli selles osas, mida mitte teha. Kui lisate rea iga kord, kui agent komistab, õpite seda käivitades ja komistuskivid kasvavad orgaaniliselt.

Lõpuks, kui mõni osa on tingimuslik või sisult äärmiselt raske, võtke see SKILL.md-st, mis on jaotur, ja pange see ühte kodaratest. Pange see lisafaili, mida saab progressiivselt laadida, mida käsitleme järgmisena.

3. samm: kasutage hierarhiat

Kasutage Skill-i hierarhiat, kui teil on skript, viited või kasutate mõnda spetsiifilist tööriista:

Soovitatavad kasutusviisid skriptide, viidete, varade ja seadistuse jaoks Skillis.

Kõigi tingimuslike või peamisest Skill-ist hargnevate asjade jaoks eraldage need kausta. Samuti pidage meeles, et mitmetasandilist hierarhiat saab kasutada eriti keerukate Skill-ide jaoks. Nende puhul peate hoolikalt läbi mõtlema, kas funktsionaalsus tuleks rakendada monoliitselt või Skill-ide kogumina (võimalik, et depends: põhiste laadimissuhetega).

4. samm: itereerige

Järgmisena tehke harul mitu iteratsiooni. Alustage peaharul ilma Skill-ita, tehke mõned iteratsioonid, ehitage oma põhipäringute komplekt ja käivitage hulk hindamisi. Kõik teie Skill-i koodi ülevaatavad inimesed tänavad teid ühtse muudatuskomplekti esitamise eest koos hindamiskomplektiga. Järjestikuste täiendavate muudatuste ülevaatamine (välja arvatud uus komistuskivi) on väga raske, nii et püüdke seda minimeerida.

Tõenäoliselt teete palju väikeseid sõnamuudatusi. Väikestel sõnamuudatustel kirjeldustes võib olla ülisuur mõju marsruutimisele (sealhulgas ülevoolumõjule teistele Skill-idele), seega tehke kogu see töö enne 5. sammu.

5. samm: saatke tootmisse (Ship)

Saatke see välja.

Kuidas hooldada Skill-i

Nüüd, olles Skill-i kirjutanud, peate seda hooldama.

Komistuskivide hoogratas (The Gotchas Flywheel)

Sellest hetkest alates kipub teie komistuskivide loend palju kasvama või muutuma. Näeme sageli inseneride poolt tehtud tõmbepäringuid, mis ei ole hinnatud (un-evaled), muudavad näiteks kirjeldust. Kui muudate kirjeldust pärast seda, kui teie Skill on liidetud, olete rajalt maas. Kui teete muudatusi asjas, mis otsustab, kas teie Skill marsruutida, peate kirjutama mõned hindamised, mis toetavad neid muudatusi.

Skill-id on peamiselt lisatavad (append-mostly). Komistuskivide jaotis kogub aja jooksul kõige rohkem väärtust:

Agent ebaõnnestub millegagi → Lisa komistuskivi

Agent laadib Skill-i valesse kohta → Tihendage kirjeldust ja lisage negatiivsed hindamised

Agent ei laadi Skill-i siis, kui peaks → Lisage märksõnad ja positiivsed hindamised

Süsteemi viip muutub → Kontrollige vastuolu või duplikaatide olemasolu

Sisemises testimises või tootmises on lihtne märgata ühte ebaõnnestumise juhtumit ja lisada komistuskivi. See on negatiivne näide, nii et see ei muuda tegelikult otsest juhist, vaid annab mudelile teada: „Hei, siin on selline teadaolev viga.“

Liikudes 80-20-lt 99,9% või 99,99% õnnestumismäärani, on lihtne seda komistuskivide loendit kasvatada. Neid negatiivseid näiteid nähes peaksite komistuskivide jaotisele asju peamiselt lisama. Te ei tohiks lisada pikemaid juhiseid ega muuta kirjeldust.

Hindamiskomplektid (Eval Suites)

Perplexity-s käivitame palju hindamiskomplekte erinevate asjade kontrollimiseks. Olemas on Skill-i laadimine ja Skill-i failide lugemine, mis kontrollib Skill-i enda laadimise täpsust, tagasikutsumist ja keelatud kontrollide läbimist. Kas agent suunab teie Skill-i siis, kui see peab seda tegema? Need tagavad, et uued Skill-id ei riku olemasolevaid piire.

Olemas on ka hindamised, mis saavad kontrollida õiget progressiivset laadimist. Agent võib Skill-i laadida, aga kas see loeb lisafaili või -failid? Näiteks kui teil on finantspäringute jaoks finants-Skill, kas see loeb spetsiaalset FORMATTING.md faili?

Samuti on Skill-ide jaoks hindamisi, mis testivad otsast-otsani (end-to-end) ülesannete täitmist valdkondades. Käivitame täieliku agenditsükli ja kasutame hästi määratletud kriteeriumide rubriigi põhjal tulemuste hindamiseks LLM-i kohtunikku.

Lõpuks on oluline käivitada need hindamised erinevate mudelite vastu. Computer toetab vähemalt kolme erinevat orkestratsioonimudelite perekonda: GPT, Claude Opus ja Claude Sonnet. Soovite käivitada oma Skill-i laadimise ja valdkonna Skill-id nende erinevate agentide orkestreerijate vastu, et tagada ühesuguse käitumise säilimine. Sonnet ja GPT käituvad Skill-ide osas üsna erinevalt.

Lõppmõtted ja kokkuvõtted

Mida rohkem Skill-e ehitate, seda paremaks te nende ehitamisel saate. Kui te ei automatiseeri ega püüa Skill-ide abil teha korratavamateks ülesandeid, mida teete igapäevaselt, alustage kohe.

Skill-ide ehitamise tegevus teeb teid osavamaks uute Skill-ide ehitamisel, lisaks on need äärmiselt head äriprotsesside automatiseerimiseks. Kui suudate kirjeldada midagi, mida teete igal nädalal enne oma igapäevakoosolekut (standup), iga sprindi lõpus, või midagi, mida teete insenerina iga päev, nädal või isegi kvartal, peaksite oma aja tagasivõitmiseks kirjutama Skill-i.

Kas saate automatiseerida postmortem-analüüse? Kas saate vaadata üle tõmbepäringuid? Iga ülesande puhul, mida saate teha, saate vähemalt tagada, et esimene läbimine on Agent Skill. See säästab teilt märkimisväärselt aega.

Sellegipoolest pidage meeles, et Skill ei ole lihtne ega isegi alati vajalik. Vähem on rohkem. Mõned täiendavad tähelepanekud:

Kirjutage hindamised enne Skill-i. Lisage negatiivsed näited ja keelatud laadimised külgnevate, kuid erinevate skill-ide jaoks.

Kirjeldus on raske osa. „Laadi, kui...“ (kõik sõnad maksavad tähelepanu).

Komistuskivid on äärmiselt väärtuslik sisu. Alustage õhukeselt, kasvatage agendi ebaõnnestumiste käigus.

Pidage meeles, et uue Skill-i lisamisega on lihtne rikkuda teisi eelnevalt eksisteerinud Skill-e, isegi kui te seda ei puudutanud (olge ettevaatlik kaugmõju suhtes).

Kasutage kõiki saadaolevaid tööriistu iga kord, kui kirjutate ja hooldate Skill-i. Kui soovite rohkem teada saada, on Agent Skills veebisaidil palju häid näiteid ning nii meie sisemine repositoorium kui ka avalik ökosüsteem sisaldavad palju näiteid hästi kujundatud Skill-idest.

Tsitaat

@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}
}