Designing, refining, and maintaining agent skills at Perplexity

Perplexitys agentprodukter på grensen mellom forskning og praksis bygger på et fundament av praktisk kunnskap og domeneekspertise pakket inn i modulære Agent Skills. Vi vedlikeholder et nøye utvalgt bibliotek med Skills på tvers av våre tekniske miljøer. Disse Skills inkluderer mange av verktøyene for generelle formål som driver Perplexity Computer; bransjespesifikke funksjoner innen områder som finans, juss og helse; og en svært lang hale av moduler for å dekke brukerbehov. Enkelte Skills brukes sjelden, men er kritiske når de først brukes. For å sikre en konsekvent god brukeropplevelse prioriterer Perplexitys agentteam kvaliteten på Skills like høyt som kodekvaliteten.

Intuisjonene og beste praksis som kreves for å utvikle en Skill av høy kvalitet, skil seg vesentlig fra det som trengs for å bygge tradisjonell programvare. Agentteamet gjennomgår mange pull-forespørsler fra dyktige ingeniører som utvikler Skills i sitt daglige arbeid. Resultatet er nesten alltid en rekke kommentarer og forslag til revisjon. Dette skyldes at mange nyttige mønstre for skriving av kode blir til antipatterns ved opprettelse av Skills.

Hvis du for eksempel tar noen av aforismene fra PEP20 – The Zen of Python, blir det raskt klart at å skrive god Python-kode ikke er det samme som å skrive gode Skills. Av de 20 visdomslinjene er minst halvparten helt feil eller direkte misvisende når man skriver Skills. Her er fem av dem:

Fem kontraster mellom Python-zen og artikkelens veiledning for å skrive Skills.

Denne guiden er dokumentet som ingeniører på tvers av Perplexity bruker når de utvikler og gjennomgår Skills. Vi frigir også denne guiden til offentligheten slik at våre oppdagelser og lærdommer kan komme det bredere fellesskapet til gode. Enten du er en ingeniør som designer produksjons-Skills i ditt daglige arbeid, en Computer-bruker som ønsker å utvikle din egen Skill innen et felt du kan best, eller begge deler, så er denne guiden for deg.

Hva er en Skill?

Når du skriver en Skill, skriver du ikke vanlig gammel programvare (selv om Skills nå er en del av de sentrale logiske motorene for agentsystemer). Snarere bygger du kontekst for modeller og deres miljøer. En Skill har andre begrensninger og andre designprinsipper. Hvis du skriver en Skill slik du skriver kode, vil du mislykkes.

En Skill er minst fire ting, spesielt med tanke på hvordan vi bygger dem hos Perplexity.

En Skill er en katalog

En Skill er ikke bare en enkelt SKILL.md-fil. I mange tilfeller inneholder en Skill flere filer. Under katalogen som har navn etter din Skill, kan du ha:

SKILL.md: frontmatter og instruksjoner

scripts/: kode agenten kjører, ikke gjenoppfinn

references/: tunge dokumenter, lastes betinget

assets/: maler, skjemaer og data

config.json: førstegangs brukeroppsett

Dette hub-and-spoke-mønsteret lar deg holde Skills svært fokuserte og stramme, og man kan bruke mappestrukturen på en svært kreativ måte. Noen ganger har spesielt intrikate Skills nytte av flere nivåer av hierarki for å hjelpe modellen med å navigere bedre. Anta at en Skill krever kunnskap fordelt på 300 emner, som kan grupperes i 20 fagområder. Å velge riktig emne blant 300 på en pålitelig måte er en uoppløst utfordring selv for dagens beste grensestandardmodeller. Det er et mye enklere valgproblem for en modell å snevre inn på ett av 20 områder, enn blant de 15 emnene innenfor det området.

Som et eksempel på hvordan flernivåhierarki gir verdi, brukte teamet vårt tre nivåer av emnemessig nøsting i de Skills som drev Computers amerikanske inntektsskattemuligheter i den forrige skattemessen. Dette hierarkiet var helt uunnværlig gitt skattelovens kompleksitet: I våre tidlige tester resulterte det å presentere modellen med en enkelt mappe som inneholdt alle 1 945 seksjonene i USAs skattelovverk (Internal Revenue Code), i dårligere ytelse enn å ikke laste Skillen i det hele tatt. Å organisere informasjonen i logiske underavdelinger var uunnværlig for å sikre lesoperasjoner med høy presisjon.

Likevel kom ikke dette hierarkiet gratis. Økende nivåer av hierarki krever økende nivåer av kuratering på tvers av informasjonsarkitekturen for å håndtere den resulterende indirekteheten. Vi utarbeidet hurtigveiledninger, tilpassede søkeverktøy og andre verktøy for å støtte modellen i å finne informasjon med et minimum av indirektehet. I dette tilfellet produserte det å gjøre det harde arbeidet med kuratering til slutt et positivt sluttresultat: en Skill som lot modeller utføre skatterelaterte oppgaver mye bedre enn ved å bruke generelle verktøy alene.

Forstørr

En Skill er et format

En Skill er et format. Den sentrale rotfilen SKILL.md må ha både et navn og en beskrivelse. Videre må Skillen samsvare nøyaktig med katalognavnet som Skillen befinner seg i. Navnet må bestå av små bokstaver, ikke ha noen mellomrom, og kan bruke bindestreker. Beskrivelsen er rutingutløseren. Dette er et vanlig feilpunkt: beskrivelsen er ikke intern dokumentasjon for hva Skillen gjør. Den beløper seg til instruksjoner for modellen om når den skal laste Skillen. Derfor vil du ofte se «Last inn når» i stedet for «Denne Skillen gjør». Dette er viktig på grunn av måten de fleste implementeringer injiserer beskrivelsen i modellkonteksten på.

Inne i frontmatter finnes det også «depends:», som lar deg opprette hierarkiske Skill-avhengigheter, og «metadata:», som brukes til gjennomganger og evalueringer. Ulike agentsystemer kan til og med definere sine egne frontmatter-felt, som skal brukes på en måte som er spesifikk for de systemene. Som et alternativ kan Skill-spesifikk metadata pakkes inn i en ekstra JSON- eller YAML-konfigurasjonsfil. Dette er ønskelig når man bygger agentsystemer som må legge til rette for ulike typer kjøretidsadferd per Skill uten å forurense modellens kontekst med bagateller. Til slutt kan lignende oppførsel oppnås ved å fjerne Skill-frontmatter ved lesing. Computer bruker denne metoden, som gjør at konfigurasjonen kan bevares i rotfilen SKILL.md. Nøye oppmerksomhet på detaljer kreves i tolkningslogikken, og man kan ønske å implementere betinget fjerning hvis det er visse felt som er nyttige å ha i modellkonteksten.

En Skill kan påberopes

En Skill kan påberopes. Agenten laster inn en Skill ved kjøretid. Viktig nok er Skills ikke alltid inkludert i konteksten fra starten. Som standard folder de fleste agentsystemer ut Skills trinnvis ut fra spesifikke behov.

Det er minst tre nivåer av kontekstkostnader slik vi har implementert Skills i Computer. Her er prosessen:

Computer kaller load_skill(name="...")

Computer kopierer Skill-katalogen inn i det isolerte kjøringssandboksen

Computer autolaster avhengigheter rekursivt i «depends:»-taggen

Computer striper deretter frontmatter, slik at agenten bare ser brødteksten og de ekstra filene

Ulike agentsystemer kan velge å eksponere Skill-innhold på ulike måter. For eksempel kan noen systemer velge å ikke eksponere filhierarkiet i det hele tatt, og overlate til modellen å oppdage hierarkiet gjennom filsystemoperasjoner. Andre systemer kan velge å gi modellen en mapping av hele filtreet opp til en viss avskjærings- og/eller dybdegrense. For å holde konteksten ren utelater Computer fullstendige filhierarkier fra påberopelseskonteksten; dette kan imidlertid overstyres på per-Skill-basis.

En Skill er progressiv

Skills er progressive. I Computer finnes det tre forskjellige nivåer av kontekstkostnader, og vi pådrar oss alle tre på ulike stadier:

De tre nivåene av Skill-kontekst: indeks, full Skill-innlasting og referansefiler under kjøring.

Computer bygger en Skill-indeks som har navnet og beskrivelsen for hver tilgjengelig Skill. Budsjettet for dette er rundt 100 tokens per Skill (kortere er enda bedre). Det er så stramt fordi du betaler denne kostnaden i hver økt, for hver bruker. Dette injiseres i systemledeteksten helt i begynnelsen av samtalen. Modellen har tilgang til en rekke navngitte Skills og beskrivelser slik at den kan bestemme om den skal kalle «load_skill()». Listen for å komme inn i denne indeksen er ekstremt høy. Skillen din må være svært nyttig, og beskrivelsen må være ekstremt tett og konsis fordi alle betaler kostnaden hele tiden.

Etter at agentsystemet har lastet inn Skillen, kommer den fullstendige SKILL.md-brødteksten. Ideelt sett overstiger ikke brødteksten 5 000 tokens. Selv da ønsker du at hver setning skal telle, fordi når du først har lastet en Skill, må resten av samtalen betale den prisen til du når komprimeringsgrensen. Mange tråder laster inn alt fra tre til fem forskjellige Skills, noe som multipliserer denne kostnaden. Skills med mye fyllstoff vil nesten helt sikkert forringe andre Skills samt de helhetlige agentkapasitetene. Kort sagt, hvis din Skill lastes og den ikke gjør det rette, er det bortkastet kontekst.

Det siste nivået av progresjon er skript eller spesialtilfeller, som del-skills eller formatering. Dette er der du vil legge ubegrenset betinget forgreinet logikk. Agenten vil bare bruke det når den trenger det, noe som betyr at det er en mye lavere terskel for hva du vil legge her.

I indeksen er hvert token viktig. Den lastede Skill-brødteksten er mer avslappet, og kjøretiden er mest avslappet. Dette kan være 20 000 tokens eller null tokens. Dette er nivået der du kanskje tenker på å utvide modellens kontekst på en progressiv måte.

Når trenger du en Skill?

Agentteamet blir ofte bedt om å uttale seg om hvorvidt en Skill er genuint nødvendig for et gitt domene eller bruksområde. Svært sjelden har vi et definitivt svar basert på første prinsipper alene. Den eneste måten å finne ut av dette på er å starte med agenten din uten Skillen, kjøre flere helteforespørsler, og deretter finne ut om agenten gjør en god jobb.

Når du trenger en Skill

Det er mange oppgaver som er i distribusjon for trente modeller. Du trenger bare å bruke en Skill hvis du vil endre den oppførselen på en bestemt måte som du ikke kan med for eksempel én setning i ledeteksten din. Så du trenger en Skill når agenten vil gjøre feil uten spesiell kontekst, eller hvis det er en inkonsekvens eller ikke-determinisme som du trenger skal være ekstremt konsekvent på tvers av kjøringer.

Det kan være at kunnskapen din er holdbar, men ikke finnes i treningsdataene. Det kan være avcuttsdatoer eller bedriftsspesifikke arbeidsflyter, eller det kan være et spørsmål om smak. For eksempel har vi flere designtilknyttede Skills i Computer skrevet av Henry Modisett (vår sjef for design). Grunnen til at hvert token finnes i disse Skills, er fordi Henry har veldig god smak når det gjelder å designe nettsider og PDF-er. Henry spesifiserer hvilke skrifttyper som skal brukes og hvilke som ikke skal brukes, hvordan disse skrifttypene føles, og andre skjønnsspørsmål som modellen ikke kan lære fra treningsdata alene.

Når du ikke trenger en Skill

Vi ser mange Skills der ingeniører har skrevet en rekke git-kommandoer som må utføres i rekkefølge. Det er unødvendig fordi modellen allerede vet hvordan den skal gjøre det, noe som betyr at det blir god dokumentasjon, men en dårlig Skill.

Vi ser eksempler der Skills rekapitulerer instruksjoner fra systemledeteksten. Du trenger ikke en Skill for det. Kunnskap som er relevant for flertallet av forespørsler, bør inkluderes i global kontekst, ikke i en betinget lastet Skill

Hvis det er noe som endrer seg raskere enn du klarer å vedlikeholde det, trenger du ikke en Skill. For eksempel, hvis du treffer et eksternt MCP-endepunkt og verktøyene eller versjonene av disse verktøyene endrer seg hyppig, bør du ikke injisere dem i en Skill. Hvis du gjør det, vil du bare ende opp med avvik og modellen vil gjøre feil.

Hver Skill er en skatt

Her er en nyttig test du kan bruke på hver setning i din Skill: «Ville agenten gjort feil på dette uten denne instruksjonen?» Hvis setningen ikke trenger å være der, har den ikke råd til å være der fordi alle betaler denne kostnaden hver eneste gang. Når du bestemmer deg for å legge til en Skill eller ikke, må du huske denne avgiften der hver økt og hver bruker koster tokens.

Det følgende berømte sitatet, som høres mye bedre ut på fransk, kan omtrent oversettes til «Jeg har bare gjort dette brevet lengre fordi jeg ikke har hatt tid til å gjøre det kortere.»

« 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

Akkurat som Pascal må du bruke tid på hver Skill. Det er vanskelig å skrive en kort Skill. Hvis din Skill er enkel å skrive, er den sannsynligvis for lang eller burde ikke eksistere. En god Skill er så kort som den kan bli.

Hvis du oppdager at du prøver å lage generering av en Skill på ett forsøk og sender inn PR-er på fem minutter, vil resultatene nesten helt sikkert være under pari. Tidlig forskning har faktisk vist at hvis du bruker LLM-er til å skrive Skills, vil ikke LLM-en sannsynligvis ha nytte av det: «Selvgenererte Skills gir ingen nytte i gjennomsnitt, noe som viser at modeller ikke på en pålitelig måte kan forfatte den prosessuelle kunnskapen de har nytte av å konsumere.»

Hvordan bygge en Skill

Sagt på en annen måte, må du injisere din mening i enhver Skill du skriver. Følg disse trinnene.

Trinn 0: Skriv evalueringene (Evals)

Skriv noen av evalueringene først. Du kan hente evalueringstilfeller fra:

Reelle brukerforespørsler: eksempel fra produksjon eller din egen kompetansegruppe

Kjente feil: Agenten mislyktes fordi Skillen ikke fantes

Nabo-forvirring: Nær domenegrensen din, men rutes til en annen Skill

I det minste bør du forsikre deg om at du tester at Skillen lastes når det trengs. Ideelt sett henter du ut et utvalg av disse, kanskje fra et produksjonsmiljø. Du kan også vurdere kjente feiltilfeller: kanskje hele grunnen til at du satte i gang med å skrive Skillen er på grunn av en spesiell feil du merket deg, eller kanskje du refaktorerer og det er en viss forvirring i to nærliggende domener som dekkes av én Skill.

Til slutt er det viktig å kjøre disse evalueringene mot forskjellige modeller. Computer støtter minst tre forskjellige orkestreringmodelfamilier: GPT, Claude Opus og Claude Sonnet. Du vil kjøre din Skill-lasting og domenets Skills mot disse forskjellige agentorkestratorene for å sikre at du ikke får ulik oppførsel. Sonnet og GPT oppfører seg ganske annerledes når det kommer til Skills.

Trinn 1: Beskrivelsen

Dette er den vanskeligste linjen i Skillen. Det er en rutingutløser, ikke dokumentasjon. For å få navnet og beskrivelsen riktig, bryr du deg ikke om innholdet i Skillen. Du bryr deg bare om hvorvidt Skillen lastes og injiseres på de rette punktene og er fri for utilsiktede sideeffekter, som er feilmodus nummer én. Hver gang du legger til en ekstra Skill, risikerer du å gjøre hver andre Skill litt dårligere, så du må sørge for at du minimerer regresjon.

Igjen, en dårlig beskrivelse beskriver hva Skillen gjør eller hvorfor den er nyttig. En god beskrivelse sier når agenten skal laste Skillen. Si for eksempel at du har noe for overvåking av pull-forespørsler. Ikke skriv hva Skillen gjør. Skriv hva ingeniører sier når de er frustrerte og vil at du skal sørge for at PR-en deres fungerer, som «barnevakt» eller «overvåk CI» eller «sørg for at dette lander».

Her er en rask sjekkliste:

Starter med «Load when...»

Målrett mot 50 ord eller færre

Beskriver brukerens hensikt, helst fra reelle forespørsler

Oppsummerer ikke arbeidsflyten

Reelle forespørsler er det du kan dekke i en 80-20-regel. Vanligvis fungerer to eller tre eksempler bra. Det er ikke enkelt å legge til nøyaktig og bare så mye som du trenger.

Trinn 2: Skriv brødteksten

Deretter skriver du innholdet i selve Skillen. Merk at dette ikke er trinn 0 eller trinn 1.

Å kommunisere arbeidsflyter til en LLM er fullstendig forskjellig fra å kommunisere arbeidsflyter til en kollega, eller til og med til kjøretidssystemet ditt. Når en ingeniør lærer et nytt programvareverktøy, kan det hende vedkommende må lese dokumentasjonen, få en gjennomgang av noen med erfaring og lære å bruke verktøyet. I mellomtiden, for nesten alle programvareverktøy som har eksistert i minst ett år, trenger du bare å nevne navnet, og LLM-en har all informasjonen den trenger.

Når du skriver brødteksten, kan du hoppe over det åpenbare. Mange ingeniører har masse erfaring med å skrive readme.md-filer som lister opp hver kommando noen må kjøre. Det er lett å falle tilbake til det når du skriver en Skill fordi det føles som om du skriver dokumentasjon, men hvis du gjør det, vil Skillen din bli søppel. Så ikke skriv ut en rekke kommandoer.

Du trenger for eksempel ikke å skrive: «git log # finn commiten; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;»

Skriv i stedet: «Cherry-pick commiten til en ren gren. Løs konflikter og bevar hensikten. Hvis den ikke kan lande rent, forklar hvorfor.»

Modellen vil gjøre en mye bedre jobb med sistnevnte enn med førstnevntes altfor foreskrivende rekke av kommandoer, spesielt når ting går galt. Ikke kjør på skinner eller vær altfor foreskrivende, noe som er skjørt, men vær heller fleksibel der flere tilnærminger kan fungere. Igjen, god dokumentasjon for mennesker er som regel dårlig dokumentasjon for modeller.

Deretter bør du fokusere på feller eller negative eksempler. Disse er innhold med svært høye signaler fordi de ofte veileder modellen med hensyn til hva den ikke skal gjøre. Hvis du legger til en linje hver gang agenten feilberegner, vil du lære ved å kjøre den, og fellene vil vokse organisk.

Til slutt, hvis det er noen del som er betinget eller svært tung i innhold, tar du den ut av SKILL.md, som er huben, og plasserer den i en av eikene. Legg den i en tilbehørsfil som kan lastes inn progressivt, noe vi skal se nærmere på nå.

Trinn 3: Bruk hierarkiet

Utnytt Skill-hierarkiet når du har et skript, referanser, eller du bruker et spesifikt verktøy:

Foreslått bruk av skript, referanser, ressurser og konfigurasjon i en Skill.

For alt som er betinget eller forgrener seg fra hoved-Skillen, bryt det ut i en mappe. Husk også at flernivåhierarki kan brukes for spesielt intrikate Skills. For disse vil du ønske å vie nøye omtanke til om funksjonaliteten skal implementeres monolitisk eller som en samling av Skills (kanskje med depends:-baserte lastingsrelasjoner).

Trinn 4: Iterer

Deretter gjør du en rekke itereringer på en gren. Start på hovedgrenen uten noen Skill, gjør noen itereringer, bygg helteforespørselsettet ditt, og kjør en rekke evalueringer. Alle som gjennomgår Skill-koden din, vil takke deg for at du sender inn et enkelt endringssett komplett med et evalueringssett. Å gjennomgå etterfølgende inkrementelle endringer (bortsett fra en ny felle) er svært vanskelig, så prøv å minimere det.

Du kommer sannsynligvis til å gjøre mange små ordendringer. Små ordendringer i beskrivelser kan ha en uforholdsmessig stor innvirkning på ruting (inkludert avskallingseffekter på andre Skills), så gjør alt det arbeidet før trinn 5.

Trinn 5: Send ut (Ship)

Send den ut.

Hvordan vedlikeholde en Skill

Nå som du har skrevet en Skill, må du vedlikeholde den.

Fellesvinghjulet (Gotchas Flywheel)

Fra dette punktet av har listen din over feller en tendens til å vokse eller endre seg mye. Vi ser ofte ingeniører som lager PR-er som ikke er evaluert, for eksempel endrer beskrivelsen. Hvis du endrer beskrivelsen etter at Skillen din er flettet inn, er du på ville veier. Hvis du gjør endringer i tingen som bestemmer om Skillen din skal rutes, må du skrive noen evalueringer som støtter endringene.

Skills er hovedsakelig tilføyelige (append-mostly). Felleseksjonen tilføres mest verdi over tid:

Agenten mislykkes på noe → Legg til en felle

Agenten laster Skillen feil plassert → Stram inn beskrivelsen og legg til negative evalueringer

Agenten laster ikke Skillen når den burde → Legg til nøkkelord og positive evalueringer

Systemledetekst endres → Sjekk for konflikt eller duplisering

Det er enkelt å merke seg et enkelt feiltilfelle i intern testing eller i produksjon og legge til en felle. Det er et negativt eksempel, så det endrer egentlig ikke eksplisitt veiledning, men det lar modellen vite: «Hei, det finnes denne kjente feilen.»

Når du beveger deg fra 80-20-regelen til å oppnå en suksessrate på 99,9 % eller 99,99 %, er det enkelt å la denne fellisten vokse. Når du ser disse negative eksemplene, bør du i hovedsak legge dem til i felleseksjonen. Du bør ikke legge til lengre instruksjoner eller endre beskrivelsen.

Evalueringssett (Eval Suites)

Hos Perplexity kjører vi mange evalueringssett for å sjekke ulike ting. Det finnes Skill-lasting og lesing av Skill-filer, som sjekker presisjonen, tilbakekallsraten og de forbudte sjekkene for selve Skill-lastingen. Vil agenten rute Skillen din når den skal? Disse sikrer at nye Skills ikke bryter eksisterende grenser.

Det finnes også evalueringer som kan sjekke for riktig progressiv lasting. Agenten kan laste inn Skillen, men leser den tilbehørsfilen eller -filene? For eksempel, hvis du har en finans-Skill for finansforespørsler, leser den den spesielle FORMATTING.md-filen?

Det finnes også evalueringer for Skills som tester for ende-til-ende-oppgavefullføring innenfor domener. Vi kjører hele agentløkken og bruker en LLM-dommer til å gradere resultatene basert på en rubrikk med godt definerte kriterier.

Til slutt er det viktig å kjøre disse evalueringene mot forskjellige modeller. Computer støtter minst tre forskjellige orkestreringsmodeller: GPT, Claude Opus og Claude Sonnet. Du bør kjøre innlasting av ferdigheter og domenesferdighytene mot disse forskjellige agentorkestratorene for å sikre at du ikke får ulik oppførsel. Sonnet og GPT oppfører seg ganske annerledes når det gjelder ferdigheter.

Siste tanker og konklusjoner

Jo flere Skills du bygger, jo flinkere blir du til å bygge dem. Hvis du ikke automatiserer eller prøver å gjøre oppgaver du gjør på daglig basis mer reproduserbare ved hjelp av Skills, kan du starte umiddelbart.

Selve handlingen det er å bygge Skills gjør deg flinkere til å bygge flere Skills, men i tillegg er de ekstremt gode til å automatisere forretningsprosesser. Hvis du kan beskrive noe du gjør hver uke før standup-møtet, på slutten av hver sprint, eller hva som helst du gjør som ingeniør på daglig, ukentlig eller til og med kvartalsvis basis, bør du skrive en Skill for å kjøpe deg tid tilbake.

Kan du automatisere postmortems? Kan du gjennomgå pull-forespørsler? Enhver oppgave du kan gjøre, kan du i det minste la første gjennomgang være en Agent Skill. Det vil spare deg for betydelig tid.

Når det er sagt, husk at en Skill ikke er enkel eller engang alltid nødvendig. Less is more. Noen andre hovedpunkter:

Skriv evalueringer før Skillen. Inkluder negative eksempler og forbudte lastinger for nærliggende, men distinkte Skills.

Beskrivelsen er det vanskelige. «Load when...» (hvert token koster oppmerksomhet).

Feller er innhold med ekstremt høy verdi. Start tynn, og la den vokse etter hvert som agenten feiler.

Husk at det er enkelt å ødelegge andre forhånd eksisterende Skills ved å legge til en ny Skill, selv om du ikke rørte den (pass deg for fjernvirkningsfeil).

Bruk alle tilgjengelige verktøy hver gang du skriver og vedlikeholder en Skill. Hvis du vil lære mer, har nettstedet til Agent Skills masse gode eksempler, og både vårt interne repositorium og det offentlige økosystemet inneholder mange eksempler på godt utformede Skills.

Sitering

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