Dizajniranje, preciziranje i održavanje veština agenata na kompaniji Perplexity

Kako Perplexity piše, pregleda i održava veštine agenata, plus vodič koji naši inženjeri koriste za njihovu izgradnju.

AutoriPerplexity Engineering

Perplexityjevi vodeći agentski proizvodi počivaju na osnovi znanja i stručnosti iz domena, upakovanoj u modularne Skillove za agente. Održavamo pažljivo kuriranu biblioteku Skillova kroz naša tehnička okruženja. Ovi Skillovi obuhvataju mnoge uslužne alate opšte namene koji pokreću Perplexity Computer; mogućnosti specifične za pojedine vertikale u oblastima kao što su finansije, pravo i zdravstvo; kao i veoma dugačak rep modula za rešavanje korisničkih potreba. Neki Skillovi se retko pozivaju, ali su kritični kada se pozovu. Da bi obezbedio dosledno odlično korisničko iskustvo, tim za agente u Perplexityju daje prednost kvalitetu Skillova jednako kao i kvalitetu koda.

Intuicije i najbolje prakse koje su potrebne za razvoj visokokvalitetne veštine značajno se razlikuju od onih koje su potrebne za izgradnju tradicionalnog softvera. Tim agenata pregledava brojne zahteve za povlačenje (pull requests) od odličnih inženjera koji razvijaju veštine tokom svog rada. Rezultat su skoro uvek brojni komentari i predlozi za reviziju. To je zato što mnogi korisni obrasci za pisanje koda postaju protivobrasci u kreiranju veština.

Na primer, ako uzmete neke od aforizama iz PEP20 – Zen Pythona, brzo postaje jasno da je pisanje dobrog Python koda drugačije od pisanja dobrih Skillova. Od 20 redova mudrosti, najmanje polovina je potpuno pogrešna ili aktivno obmanjujuća kada se pišu Skillovi. Evo pet od njih:

Zen Pitona (Zen of Python)

Zen veština

Jednostavno je bolje nego složeno

Veština je fascikla, a ne datoteka. Složenost je funkcija.

Eksplicitno je bolje nego implicitno

Aktivacija je implicitno podudaranje obrazaca. Progresivno otkrivanje.

Retko je bolje nego gusto

Kontekst je skup. Maksimalan signal po tokenu.

Posebni slučajevi nisu dovoljno posebni da bi prekršili pravila

Zamke JESU posebni slučajevi (one su sadržaj najveće vrednosti).

Ako je primenu lako objasniti, možda je to dobra ideja

Ako je lako objasniti, model to već zna. Izbrišite to.

Pet kontrasta između Zen of Python i smernica iz članka za pisanje Skillova.

Ovaj vodič je dokument koji inženjeri širom kompanije Perplexity koriste prilikom razvoja i pregleda veština. Takođe objavljujemo ovaj vodič u javnosti kako bi naša otkrića i saznanja mogla da koriste široj zajednici. Bilo da ste inženjer koji dizajnira produkcijske veštine u svom svakodnevnom radu, korisnik računara koji želi da razvije sopstvenu veštinu u oblasti koju najbolje poznajete, ili oboje, ovaj vodič je za vas.

Šta je veština?

Kada pišete veštinu, ne pišete običan stari softver (čak iako su veštine sada deo glavnih logičkih endžina za sisteme agenata). Umesto toga, gradite kontekst za modele i njihova okruženja. Veština ima drugačija ograničenja i drugačije principe dizajniranja. Ako pišete veštinu kao što pišete kod, doživećete neuspeh.

Veština je najmanje četiri stvari, posebno u kontekstu načina na koji ih gradimo u kompaniji Perplexity.

Veština je direktorijum

Veština nije samo jedna SKILL.md datoteka. U mnogim slučajevima, veština uključuje nekoliko datoteka. Pod direktorijumom nazvanim po vašoj veštini, možda imate:

SKILL.md: uvodni tekst (frontmatter) i uputstva

scripts/: kod koji agent pokreće, a ne izmišlja ponovo

references/: teški dokumenti, učitani uslovno

assets/: šabloni, šeme i podaci

config.json: podešavanje korisnika pri prvom pokretanju

Ovaj šablon u obliku glavčine i žbica (hub-and-spoke) omogućava vam da veštine održavate veoma usmerenim i čvrstim, a strukturu fascikli možete koristiti na vrlo kreativan način. Ponekad, posebno složene veštine imaju koristi od više nivoa hijerarhije kako bi se pomoglo modelu da se bolje snalaženju. Pretpostavimo da veština zahteva znanje iz 300 tema, koje se mogu grupisati u 20 oblasti predmeta. Pouzdano biranje prave teme među 300 je nerešen izazov čak i za najbolje današnje granične modele. To je mnogo lakši problem izbora za model da se usredsredi na jednu od 20 oblasti, nego među 15 tema unutar te oblasti.

Kao jedan primer kako višestepena hijerarhija pruža vrednost, naš tim je koristio tri nivoa ugnježdavanja tema unutar veština koje pokreću mogućnosti poreza na dohodak u SAD za računar tokom ove poreske sezone. Ova hijerarhija je bila apsolutno neophodna s obzirom na složenost poreskog zakona: u našim ranim testovima, predstavljanje modela sa jednom fasciklom koja sadrži svih 1.945 odeljaka Poreskog zakona SAD rezultiralo je lošijim učinkom nego uopšte ne učitavanje veštine. Organizovanje informacija u logičke podpodeljenja bilo je neophodno za osiguranje visoko preciznih operacija čitanja.

Ipak, ova hijerarhija nije došla besplatno. Povećanje nivoa hijerarhije zahteva povećane nivoe kuriranja kroz informacionu arhitekturu radi upravljanja rezultujućom indirektnošću. Osmislili smo brze referentne vodiče, prilagođene uslužne programe za pretragu i druge alate koji podržavaju model u pronalaženju informacija uz minimalnu indirektnost. U ovom slučaju, obavljanje teškog posla kuriranja na kraju je dalo pozitivan krajnji rezultat: veštinu koja je omogućila modelima da obavljaju zadatke u vezi sa porezima mnogo sposobnije nego korišćenjem samo opštih alata.

Poreski kalkulator za Schedule C napravljen pomoću Computerovih Skillova vezanih za poreze.

Veština je format

Veština je format. Osnovna korenasta SKILL.md datoteka mora imati i naziv i opis. Štaviše, veština mora tačno da se poklapa sa nazivom direktorijuma u ​​kojem se veština nalazi. Naziv mora biti napisan isključivo malim slovima, bez razmaka, i može koristiti crtice. Opis je okidač za rutiranje. Ovo je uobičajena tačka kvara: opis nije interna dokumentacija za ono što veština radi. Ona predstavlja uputstva za model o tome kada treba da učita veštinu. Dakle, često ćete videti „Učitaj kada“, a ne „Ova veština radi“. Ovo je važno zbog načina na koji većina implementacija ubacuje opis u kontekst modela.

Unutar uvodnog teksta postoji i „depends:“, što vam omogućava da kreirate hijerarhijske zavisnosti veština, i „metadata:“, što se koristi za preglede i procene. Različiti sistemi agenata mogu čak definisati svoja sopstvena polja uvodnog teksta, koja će se koristiti na način specifičan za te sisteme. Kao alternativa, metapodaci specifični za veštinu mogu se upakovati u pomoćnu JSON ili YAML konfiguracionu datoteku. Ovo je poželjno kada se grade sistemi agenata koji treba da olakšaju različite vrste ponašanja u toku izvršavanja po veštini bez zagađivanja konteksta modela sitnicama. Konačno, slično ponašanje se može postići uklanjanjem uvodnog teksta veštine pri čitanju. Računar koristi ovu metodologiju, koja omogućava da se konfiguracija sačuva u korenastoj SKILL.md datoteci. Pažljiva pažnja posvećena detaljima je neophodna u logici parsiranja, i možda ćete želeti da implementirate uslovno uklanjanje ako postoje određena polja koja je korisno imati unutar konteksta modela.

Veština se može pozvati

Veština se može pozvati. Agent učitava veštinu u vreme izvršavanja. Važno je da veštine nisu uvek ugrađene u kontekst. Podrazumevano, većina sistema agenata razvija veštine progresivno prema specifičnim potrebama.

Postoje najmanje tri nivoa troškova konteksta u načinu na koji smo implementirali veštine u računaru. Evo procesa:

Računar poziva load_skill(name="...")

Računar kopira direktorijum veštine u izolovanu bezbednosnu zonu (sandbox) za izvršavanje

Računar rekurzivno automatski učitava zavisnosti u oznaci „depends:“

Računar zatim uklanja uvodni tekst i agent stoga vidi samo telo i dodatne datoteke

Različiti sistemi agenata mogu izabrati da izlože sadržaj veštine na različite načine. Na primer, neki sistemi mogu odlučiti da uopšte ne izlože hijerarhiju datoteka, prepuštajući modelu da otkrije hijerarhiju kroz operacije sa sistemom datoteka. Drugi sistemi mogu izabrati da daju modelu mapu celog stabla datoteka do određenog ograničenja skraćivanja i/ili dubine. Da bi kontekst bio čist, računar izostavlja pune hijerarhije datoteka iz konteksta pozivanja; međutim, ovo se može nadjačati za svaku veštinu posebno.

Veština je progresivna

Veštine su progresivne. U računaru postoje tri različita nivoa troškova konteksta, i mi snosimo sva tri u različitim fazama:

Nivo

Šta se učitava

Budžet

Kada plaćate

Indeks

naziv: opis za svaku veštinu koja nije skrivena

~100 tokena po veštini

Svaka sesija, svaki korisnik, uvek plaćeno

Učitaj

Puno telo SKILL.md datoteke

~5.000 tokena

~5.000 tokena

Vreme izvršavanja

Datoteke u skriptama (scripts/), referencama (references/), resursima (assets/), podveštinama, FORMATTING.md, SPECIAL_CASES.md

Neograničeno

Samo kada ih agent pročita

Tri nivoa konteksta Skillova: indeks, potpuno učitavanje Skilla i fajlovi za referencu tokom rada.

Računar gradi indeks veština koji ima naziv i opis za svaku dostupnu veštinu. Budžet za ovo je oko 100 tokena po veštini (kraće je još bolje). Toliko je tesno jer ove troškove plaćate u svakoj sesiji, za svakog korisnika. Ovo se ubacuje u sistemski odzivnik na samom početku razgovora. Model ima pristup gomili imenovanih veština i opisa tako da može da odluči da li će pozvati „load_skill()“. Prag za ulazak u ovaj indeks je izuzetno visok. Vaša veština treba da bude veoma korisna, a opis mora biti izuzetno zbijen i jezgrovit jer svi plaćaju troškove sve vreme.

Nakon što sistem agenata učita veštinu, tu je puno telo SKILL.md datoteke. U idealnom slučaju, tekst tela ne prelazi 5.000 tokena. Čak i tada, želite da svaka rečenica bude važna jer jednom kada učitate veštinu, ostatak razgovora mora da plati tu cenu dok ne stignete do granice sažimanja. Mnoge niti učitavaju između tri i pet različitih veština, što množi ove troškove. Veštine sa puno suvišnih delova skoro sigurno će degradirati druge veštine kao i ukupne sposobnosti agenata. Ukratko, ako se vaša veština učita i ne radi pravu stvar, to je izgubljeni kontekst.

Konačni nivo napredovanja su skripte ili posebni slučajevi, kao što su podveštine ili formatiranje. Ovde želite da smestite neograničenu uslovno granatu logiku. Agent će je koristiti samo kada mu zatreba, što znači da postoji mnogo niži prag za ono što želite da stavite ovde.

U indeksu je svaki token važan. Učitano telo veštine je opuštenije, a vreme izvršavanja je najopuštenije. Ovo može biti 20.000 tokena ili nula tokena. Ovo je nivo na kojem biste mogli razmisliti o proširenju konteksta modela na progresivan način.

Kada vam je potrebna veština?

Tim agenata se često pita da li je veština zaista potrebna za dati domen ili slučaj upotrebe. Vrlo retko imamo definitivan odgovor samo iz prvih principa. Jedini način da se ovo zaista shvati jeste da počnete sa svojim agentom bez veštine, pokrenete nekoliko ključnih upita (hero queries) i zatim shvatite da li agent radi dobar posao.

Kada vam je potrebna veština

Postoji mnogo zadataka koji su u distribuciji za obučene modele. Morate primeniti veštinu samo ako želite da promenite to ponašanje na neki specifičan način koji ne možete, recimo, jednom rečenicom u svom odzivniku. Dakle, potrebna vam je veština kada će agent pogrešiti bez posebnog konteksta, ili ako postoji neka nedoslednost ili nedeterminizam u odnosu na koji morate biti izuzetno dosledni u svim pokretanjima.

Može biti da je vaše znanje trajno, ali nije u podacima za obuku. Može doći do graničnih vrednosti ili radnih tokova specifičnih za preduzeće, ili to može biti stvar ukusa. Na primer, imamo nekoliko veština vezanih za dizajn u računaru koje je napisao Henri Modiset (naš šef dizajna). Razlog zašto svaki token postoji u tim veštinama jeste taj što Henri ima veoma dobar ukus kada je u pitanju dizajn veb-sajtova i PDF-ova. Henri navodi koje fontove treba koristiti, a koje fontove ne treba koristiti, kako se ti fontovi osećaju i druga pitanja prosuđivanja koja model ne može naučiti samo iz podataka za obuku.

Kada vam nije potrebna veština

Vidimo mnoge veštine u kojima su inženjeri napisali niz git komandi koje je potrebno izvršiti redom. To je nepotrebno jer model već zna kako to da uradi, što znači da je to odlična dokumentacija, ali loša veština.

Vidimo primere gde veštine rekapituliraju uputstva iz sistemskog odzivnika. Za to vam nije potrebna veština. Znanje relevantno za većinu zahteva treba da bude uključeno u globalni kontekst, a ne u uslovno učitanu veštinu

Ako postoji nešto što se menja brže nego što možete da ga održavate, veština vam nije potrebna. Na primer, ako pristupate nekoj udaljenoj MCP krajnjoj tački i njeni alati ili verzije tih alata se često menjaju, ne bi trebalo da ih ubacujete u veštinu. Ako to učinite, na kraju ćete dobiti odstupanje i model će praviti greške.

Svaka veština je porez

Evo korisnog testa koji možete primeniti na svaku rečenicu u vašoj veštini: „Da li bi agent pogrešio bez ovog uputstva?“ Ako rečenica ne mora da bude tu, ne može sebi priuštiti da bude tu jer svi plaćaju ovu cenu svaki put. Kada odlučujete da li ćete dodati veštinu ili ne, zapamtite ovaj porez u kojem svaka sesija i svaki korisnik koštaju tokene.

Sledeći čuveni citat, koji zvuči mnogo bolje na francuskom, grubo se prevodi kao „Ovo pismo sam napravio duže samo zato što nisam imao vremena da ga napravim kraćim.“

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

Baš kao i Paskal, morate uložiti vreme u svaku veštinu. Teško je napisati kratku veštinu. Ako je vašu veštinu lako napisati, verovatno je predugačka ili ne bi trebalo da postoji. Dobra veština je ona koja je kratka koliko god može da bude.

Ako primetite da pokušavate da generišete veštinu iz prvog puta i pošaljete PR-ove za pet minuta, rezultati će gotovo sigurno biti loši. Zapravo, rano istraživanje je pokazalo da ako koristite LLM-ove za pisanje veština, LLM verovatno neće imati koristi od toga: "Samostalno generisane veštine ne pružaju nikakvu prosečnu korist, što pokazuje da modeli ne mogu pouzdano da kreiraju proceduralno znanje od čijeg trošenja imaju koristi."

Kako izgraditi veštinu

Drugim rečima, morate uneti svoje mišljenje u svaku veštinu koju napišete. Sledite ove korake.

Korak 0: Napišite procene (Evals)

Prvo napišite neke od procena. Slučajeve procene možete pronaći iz:

Stvarni upiti korisnika: uzorak iz produkcije ili vašeg pouzdanog tima stručnjaka (brain trust)

Poznati neuspesi: Agent nije uspeo jer veština nije postojala

Zabuna sa susedima: Blizu granice vašeg domena, ali se rutira na drugu veštinu

U najmanju ruku, trebalo bi da se uverite da testirate da se veština učitava kada je to potrebno. U idealnom slučaju, uzorkujete neke od ovih, možda iz produkcijskog okruženja. Takođe biste mogli uzeti u obzir poznate slučajeve grešaka: možda je glavni razlog zašto ste krenuli da pišete veštinu zbog određenog neuspeha koji ste primetili ili možda vršite refaktorisanje i postoji neka zabuna u dva bliska domena koja su pokrivena jednom veštinom.

Počnite sa sličnim negativnim i pozitivnim primerima. Negativni primeri su izuzetno moćni i mogu biti važniji od pozitivnih primera.

Korak 1: Opis

Ovo je najteža linija u veštini. To je okidač za rutiranje, a ne dokumentacija. Da biste ispravno odredili naziv i opis, nije vas briga za sadržaj veštine. Stalo vam je samo do toga da li se veština učitava i ubacuje na pravim mestima i da li je oslobođena neželjenih sporednih efekata, što je režim kvara broj jedan. Svaki put kada dodate dodatnu veštinu, rizikujete da svaku drugu veštinu učinite malo lošijom, tako da morate osigurati da svedete regresiju na minimum.

Opet, loš opis opisuje šta veština radi ili zašto je korisna. Dobar opis govori kada agent treba da učita veštinu. Na primer, recimo da imate nešto za nadgledanje zahteva za povlačenje. Nemojte pisati šta veština radi. Napišite ono što inženjeri kažu kada su frustrirani i žele da se uverite da njihov PR radi, kao što su „pazi na decu“ („babysit“), „gledaj CI“ („watch CI“) ili „pobrini se da ovo prođe“ („make sure this lands“).

Evo brze kontrolne liste:

Počinje sa "Učitaj kada..." ("Load when...")

Cilj je 50 reči ili manje

Opisuje nameru korisnika, u idealnom slučaju iz stvarnih upita

Ne rezimira radni tok

Stvarni upiti su ono što možete pokriti u odnosu 80-20. Obično dva ili tri primera dobro funkcionišu. Nije lako dodati tačno i samo onoliko koliko vam je potrebno.

Korak 2: Napišite telo

Zatim, napišite sadržaj same veštine. Imajte na umu da ovo nije Korak 0 ili Korak 1.

Komunikacija radnih tokova sa LLM-om je potpuno drugačija od komunikacije radnih tokova sa kolegom, ili čak sa vašim sistemom za izvršavanje. Kada uči novi softverski alat, inženjer će možda morati da pročita dokumentaciju, dobije obilazak od nekoga sa iskustvom i nauči kako da koristi alat. U međuvremenu, za skoro svaki softverski alat koji postoji najmanje godinu dana, samo treba da pomenete njegovo ime i LLM ima sve informacije koje su mu potrebne.

Kada pišete telo, preskočite očigledne stvari. Mnogi inženjeri imaju dosta iskustva u pisanju readme.md datoteka koje navode svaku komandu koju neko treba da izvrši. Lako je vratiti se na to kada pišete veštinu jer se čini kao da pišete dokumentaciju, ali ako to uradite, vaša veština će biti smeće. Dakle, nemojte pisati niz komandi.

Na primer, ne morate da pišete: „git log # pronađi urezivanje (commit); git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;“

Umesto toga, napišite: „Prenesite urezivanje (cherry-pick) na čistu granu. Rešite sukobe čuvajući nameru. Ako ne može da prođe čisto, objasnite zašto.“

Model će obaviti mnogo bolji posao sa potonjim nego sa previše obavezujućim nizom komandi prethodnog, posebno kada stvari pođu po zlu. Nemojte forsirati niti biti previše obavezujući, što je krhko, već budite fleksibilni tamo gde više pristupa može da funkioniše. Opet, dobra dokumentacija za ljude najčešće je loša dokumentacija za modele.

Zatim se fokusirajte na zamke ili negativne primere. Ovo je sadržaj sa izuzetno visokim signalom jer često vode model u pogledu toga šta ne treba raditi. Ako dodate liniju svaki put kada agent posrne, učićete pokretanjem i zamke će rasti organski.

Na kraju, ako postoji bilo koji deo koji je uslovan ili izuzetno težak po sadržaju, izvadite ga iz SKILL.md datoteke, koja je glavčina (hub), i stavite ga u jednu od žbica. Stavite ga u pomoćnu datoteku koja se može progresivno učitavati, u šta ćemo zaroniti sledeće.

Korak 3: Koristite hijerarhiju

Iskoristite hijerarhiju veština kada imate skriptu, reference ili koristite neki specifičan alat:

skripte/ (scripts/) Deterministička logika koju bi agent izmišljao pri svakom pokretanju

Dajte mu kod za komponovanje, a ne za rekonstrukciju

reference/ (references/) Teški dokumenti koji se učitavaju samo kada je uslov ispunjen

"Pročitaj api-errors.md ako API vrati vrednost koja nije 200"

resursi/ (assets/) Šabloni izlaza koje agent kopira i popunjava

report-template.md, izlazne šeme

config.json Podešavanje korisnika pri prvom pokretanju

Zatražite Slack kanal, sačuvajte i ponovo koristite sledeći put

Preporučena upotreba skripti, referenci, resursa i konfiguracije unutar Skilla.

Za sve što je uslovno ili se grana iz glavne veštine, izdvojite to u fasciklu. Zapamtite takođe da se višestepena hijerarhija može koristiti za posebno složene veštine. Za ove ćete želeti da pažljivo razmislite o tome da li funkcionalnost treba da bude implementirana monolitno ili kao skup veština (možda sa odnosima učitavanja zasnovanim na depends:).

Korak 4: Ponavljajte (Iterate)

Zatim uradite gomilu iteracija na grani. Počnite na glavnoj grani bez veštine, uradite neke iteracije, izgradite svoj skup ključnih upita i pokrenite mnoštvo procena. Svako ko pregleda vaš kod veštine biće vam zahvalan na podnošenju jedne izmene kompletirane sa skupom procena. Pregled uzastopnih inkrementalnih promjena (osim nove zamke) je veoma težak, zato pokušajte da to svedete na minimum.

Verovatno ćete napraviti mnogo malih promena reči. Male promene reči u opisima mogu imati preveliki uticaj na rutiranje (uključujući efekte prelivanja na druge veštine), zato obavite sav taj posao pre Koraka 5.

Korak 5: Iskoristite / Pošaljite (Ship)

Pošaljite ga.

Kako održavati veštinu

Sada kada ste napisali veštinu, morate je održavati.

Zajamačni zamajac (The Gotchas Flywheel)

Od ove tačke pa nadalje, vaša lista zamki ima tendenciju da znatno raste ili se menja. Često viđamo inženjere koji prave zahteve za povlačenje (PR) koji nisu ocenjeni, na primer, menjaju opis. Ako menjate opis nakon što je vaša veština spojena, na pogrešnom ste putu. Ako pravite promene na onome što odlučuje da li će rutirati vašu veštinu, morate napisati neke procene koje podržavaju te promene.

Veštine su uglavnom aditivne (append-mostly). Odeljak sa zamkama sakuplja najviše vrednosti tokom vremena:

Agent ne uspeva u nečemu → Dodajte zamku

Agent učitava veštinu van cilja → Pritegnite opis i dodajte negativne procene

Agent ne učitava veštinu kada bi trebalo → Dodajte ključne reči i pozitivne procene

Promene sistemskog odzivnika → Proverite da li postoji sukob ili dupliranje

Lako je primetiti pojedinačni slučaj neuspeha u internom testiranju ili u produkciji i dodati zamku. To je negativan primer, tako da zapravo ne menja eksplicitna uputstva, ali daje do znanja modelu: „Hej, postoji ova poznata greška.“

Kako prelazite sa 80-20 na postizanje stope uspeha od 99,9% ili 99,99%, lako je proširiti ovu listu zamki. Kako vidite ove negativne primere, uglavnom biste trebali da dodajete u odeljak sa zamkama. Ne biste trebali dodavati duža uputstva niti menjati opis.

Paketi procena (Eval Suites)

U kompaniji Perplexity pokrećemo mnoge pakete procena da bismo proverili različite stvari. Postoje učitavanje veštine i čitanje datoteka veštine, što proverava preciznost, odziv (recall) i zabranjene provere samog učitavanja veštine. Da li će agent rutirati vašu veštinu kada bi trebalo? Ovo osigurava da nove veštine ne narušavaju postojeće granice.

Postoje i procene koje mogu proveriti ispravno progresivno učitavanje. Agent može učitati veštinu, ali da li čita pomoćnu datoteku ili datoteke? Na primer, ako imate finansijsku veštinu za finansijske upite, da li čita posebnu FORMATTING.md datoteku?

Postoje i procene za veštine koje testiraju završetak zadatka od početka do kraja unutar domena. Pokrećemo kompletnu petlju agenata i koristimo LLM sudiju da oceni rezultate na osnovu rubrike dobro definisanih kriterijuma.

Na kraju, važno je pokrenuti ove procene protiv različitih modela. Računar podržava najmanje tri različite porodice modela orkestracije: GPT, Claude Opus i Claude Sonnet. Želite da pokrenete učitavanje veštine i veštine domena protiv ovih različitih orkestratora agenata kako biste osigurali da ne dobijete drugačije ponašanje. Sonnet i GPT se ponašaju prilično različito kada su u pitanju veštine.

Konačne misli i zaključci

Što više veština izgradite, to ćete postajati bolji u njihovoj izgradnji. Ako ne automatizujete ili ne pokušavate da napravite više zadataka koji se mogu ponoviti, a koje obavljate na dnevnoj bazi koristeći veštine, počnite odmah.

Čin izgradnje veština čini vas boljim u izgradnji još veština, a uz to su izuzetno dobre u automatizaciji poslovnih procesa. Ako možete opisati nešto što radite svake nedelje pre sastanka (standup), na kraju svakog sprinta, ili bilo šta što radite kao inženjer na dnevnoj, nedeljnoj ili čak tromesečnoj bazi, trebalo bi da pišete veštinu da biste kupili svoje vreme nazad.

Možete li automatizovati posmrtne analize (postmortems)? Možete li pregledati zahteve za povlačenje? Bilo koji zadatak koji možete obaviti, možete imati barem da prva ruka bude veština agenta. Uštedeće vam značajno vreme.

Ipak, zapamtite da veština nije laka niti uvek neophodna. Manje je više. Nekoliko drugih zaključaka:

Napišite procene pre veštine. Uključite negativne primere i zabranjena učitavanja za susedne, ali različite veštine.

Opis je teži deo. "Učitaj kada..." (svaka reč košta pažnje).

Zamke su sadržaj izuzetno visoke vrednosti. Počnite tanko, rastite kako agent ne uspeva.

Zapamtite da je lako pokvariti druge prethodno postojeće veštine dodavanjem nove veštine, iako je niste dotakli (čuvajte se delovanja na daljinu).

Koristite sve dostupne alate svaki put kada pišete i održavate veštinu. Ako želite da saznate više, veb-sajt Agent Skills ima dosta dobrih primera, a i naše interno skladište i javni ekosistem sadrže mnogo primera dobro dizajniranih veština.

Citiranje

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