Proiectarea, rafinarea și menținerea skill-urilor de agent la Perplexity

Produsele de tip agent de frontieră ale Perplexity se bazează pe o fundație de cunoștințe și expertiză în domeniu, ambalate în Agent Skills modulare. Menținem o bibliotecă selectată cu atenție de Skill-uri în medile noastre tehnice. Aceste Skill-uri inclund multe dintre utilitățile cu scop general care alimentează Perplexity Computer; capabilități specifice pe verticale în domenii precum finanțe, drept și sănătate; și o coadă foarte lungă de module pentru satisfacerea nevoilor utilizatorilor. Unele Skill-uri sunt apelate rar, dar sunt esențiale când sunt apelate. Pentru a asigura o experiență de utilizare excelentă în mod constant, echipa de agenți Perplexity prioritizează calitatea Skill-urilor la fel de mult ca și calitatea codului.

Intuițiile și bunele practici necesare pentru a dezvolta un Skill de înaltă calitate diferă semnificativ de cele necesare pentru a construi software tradițional. Echipa de agenți revizuiește numeroase pull request-uri de la ingineri excelenți care dezvoltă Skill-uri în cursul muncii lor. Rezultatul este aproape întotdeauna reprezentat de numeroase comentarii și sugestii de revizuire. Acest lucru se datorează faptului că multe modele utile pentru scriere codului devin antipattern-uri în crearea de Skill-uri.

De exemplu, dacă preiei unele dintre aforismele din PEP20 – The Zen of Python, devine rapid clar că scrierea unui cod Python bun este diferită de scrierea unor Skill-uri bune. Dintre cele 20 de rânduri de înțelepciune, cel puțin jumătate sunt complet greșite sau induc în mod activ în eroare atunci când scrii Skill-uri. Iată cinci dintre ele:

Cinci contraste între Zen of Python și ghidul articolului pentru scrierea Skill-urilor.

Acest ghid este documentul pe care inginerii din cadrul Perplexity îl folosesc atunci când dezvoltă și revizuiesc Skill-uri. De asemenea, lansăm acest ghid publicului pentru ca descoperirile și învățămintele noastre să poată aduce beneficii comunității mai largi. Fie că ești un inginer care proiectează Skill-uri de producție în munca ta de zi cu zi, un utilizator Computer care dorește să dezvolte propriul Skill într-un domeniu pe care îl cunoști cel mai bine, sau ambele, acest ghid este pentru tine.

Ce este un Skill?

Când scrii un Skill, nu scrii software simplu și vechi (chiar dacă Skill-urile fac acum parte din motoarele logice principale pentru sistemele de agenți). Mai degrabă, construiești context pentru modele și mediile acestora. Un Skill are constrângeri diferite și principii de proiectare diferite. Dacă scrii un Skill așa cum scrii cod, vei eșua.

Un Skill înseamnă cel puțin patru lucruri, în special în contextul modului în care le construim la Perplexity.

Un Skill este un director

Un Skill nu este doar un singur fișier SKILL.md. În multe cazuri, un Skill include mai multe fișiere. Sub directorul numit după Skill-ul tău, s-ar putea să ai:

SKILL.md: frontmatter și instrucțiuni

scripts/: cod pe care agentul îl rulează, nu îl reinventează

references/: documentație grea, încărcată condiționat

assets/: șabloane, scheme și date

config.json: configurarea utilizatorului la prima rulare

Acest model hub-and-spoke îți permite să menții Skill-urile foarte concentrate și bine structurate, iar structura de directoare poate fi utilizată într-un mod foarte creativ. Uneori, Skill-urile deosebit de intricate beneficiază de mai multe niveluri de ierarhie pentru a ajuta modelul să navigheze mai bine. Să presupunem că un Skill necesită cunoștințe în 300 de subiecte, care pot fi grupate în 20 de domenii tematice. Alegerea fiabilă a subiectului corect dintre 300 este o provocare nerezolvată chiar și pentru cele mai bune modele de frontieră de astăzi. Este o problemă de alegere mult mai ușoară pentru un model să se concentreze pe una dintre cele 20 de zone, decât printre cele 15 subiecte din cadrul acelei zone.

Ca un exemplu despre cum ierarhia cu mai multe niveluri oferă valoare, echipa noastră a folosit trei niveluri de imbricare tematică în cadrul Skill-urilor care alimentează capabilitățile de impozit pe venit din SUA ale Computer în acest sezon fiscal. Această ierarhie a fost absolut indispensabilă având în vedere complexitatea legislației fiscale: în testele noastre timpurii, prezentarea modelului a unui singur folder care conținea toate cele 1.945 de secțiuni din Codul Veniturilor Interne al SUA a dus la o performanță mai slabă decât neîncărcarea deloc a Skill-ului. Organizarea informațiilor în subdiviziuni logice a fost indispensabilă pentru asigurarea unor operațiuni de citire de înaltă precizie.

Totuși, această ierarhie nu a fost gratuită. Nivelurile tot mai ridicate de ierarhie necesită niveluri tot mai ridicate de curatare în cadrul arhitecturii informaționale pentru a gestiona indircția rezultată. Am conceput ghiduri de referință rapidă, utilitare de căutare personalizate și alte instrumente pentru a sprijini modelul în localizarea informațiilor cu un minimum de indircție. În acest caz, efectuarea muncii dificile de curatare a produs în cele din urmă un rezultat final pozitiv: un Skill care a permis modelelor să efectueze sarcini legate de taxe mult mai competent decât folosind instrumente generale singure.

Extinde

Un Skill este un format

Un Skill este un format. Fișierul rădăcină principal SKILL.md trebuie să aibă atât un nume, cât și o descriere. În plus, Skill-ul trebuie să corespundă exact cu numele directorului în care se află Skill-ul. Numele trebuie să fie format în întregime din caractere minuscule, să nu conțină spații și poate folosi cratime. Descriere reprezintă declanșatorul de rutare. Acesta este un punct comun de eșec: descrierea nu este o documentație internă pentru ceea ce face Skill-ul. Se reduce la instrucțiuni pentru model despre momentul în care trebuie să încarce Skill-ul. Așadar, vei vedea frecvent „Load when” (Încarcă când), nu „This Skill does” (Acest Skill face). Acest lucru este important din cauza modului în care majoritatea implementărilor introduc descrierea în contextul modelului.

În cadrul frontmatter-ului, există de asemenea „depends:”, care îți permite să creezi dependențe ierarhice de Skill-uri, și „metadata:”, care este folosit pentru revizuiri și evaluări. Diferite sisteme de agenți pot chiar defini propriile câmpuri frontmatter, care urmează să fie utilizate într-un mod specific acelor sisteme. Ca alternativă, metadatele specifice unui Skill pot fi ambalate într-un fișier de configurare JSON sau YAML auxiliar. Acest lucru este de dorit atunci când se construiesc sisteme de agenți care trebuie să faciliteze diferite tipuri de comportament de runtime per Skill fără a polua contextul modelului cu detalii mărunte. În cele din urmă, un comportament similar poate fi obținut prin eliminarea frontmatter-ului Skill-ului la citire. Computer utilizează această metodologie, ceea ce permite ca configurația să fie păstrată în fișierul rădăcină SKILL.md. Este necesară o atenție deosebită la detalii în logica de parsare, și s-ar putea să dorești să implementezi eliminarea condiționată dacă există anumite câmpuri care sunt utile de avut în contextul modelului.

Un Skill este invocabil

Un Skill este invocabil. Agentul încarcă un Skill la runtime. Important este că Skill-urile nu sunt întotdeauna pachetate în context. În mod implicit, majoritatea sistemelor de agenți desfac Skill-urile în mod progresiv la o nevoie specifică.

Există cel puțin trei niveluri de costuri de context în modul în care am implementat Skill-urile în Computer. Iată procesul:

Computer apelează load_skill(name="...")

Computer copiază directorul Skill-ului în sandbox-ul de execuție izolat

Computer încarcă automat în mod recursiv dependențele din eticheta „depends:”

Apoi, Computer elimină frontmatter-ul, iar agentul vede astfel doar corpul și fișierele suplimentare

Diferite sisteme de agenți pot alege să expună conținutul Skill-ului în moduri diferite. De exemplu, unele sisteme ar putea alege să nu expună deloc ierarhia de fișiere, lăsând la latitudinea modelului să descopere ierarhia prin operațiuni pe sistemul de fișiere. Alte sisteme pot alege să ofere modelului o mapare a întregului arbore de fișiere până la o anumită limită de trunchiere și/sau adâncime. Pentru a menține contextul curat, Computer omite ierarhiile complete de fișiere din contextul de invocare; totuși, acest lucru poate fi suprascris pentru fiecare Skill în parte.

Un Skill este progresiv

Skill-urile sunt progresive. În Computer, există trei niveluri diferite de costuri de context, și le suportăm pe toate trei în diferite etape:

Cele trei niveluri ale contextului Skill-ului: indexul, încărcarea completă a Skill-ului și fișierele de referință de runtime.

Computer construiește un index de Skill-uri care conține numele și descrierea pentru fiecare Skill disponibil. Bugetul pentru aceasta este de aproximativ 100 de tokeni per Skill (mai scurt este chiar mai bine). Este atât de restrâns deoarece plătești acest cost în fiecare sesiune, pentru fiecare utilizator. Acesta este injectat în promptul de sistem chiar la începutul conversației. Modelul are acces la o serie de Skill-uri numite și descrieri, astfel încât să poată decide dacă să apeleze „load_skill()”. Ștacheta pentru a intra în acest index este extrem de ridicată. Skill-ul tău trebuie să fie foarte util, iar descrierea trebuie să fie extrem de densă și concisă, deoarece toată lumea plătește costul tot timpul.

După ce sistemul de agenți încarcă Skill-ul, există corpul complet SKILL.md. În mod ideal, textul corpului nu depășește 5.000 de tokeni. Chiar și așa, vrei ca fiecare propoziție să conteze, deoarece odată ce încarci un Skill, restul conversației trebuie să plătească acest cost până când atingi limita de compactare. Multe fire încarcă între trei și cinci Skill-uri diferite, multiplicând acest cost. Skill-urile cu mult conținut inutil vor degrada aproape sigur alte Skill-uri, precum și capabilitățile generale ale agenților. Pe scurt, dacă Skill-ul tău se încarcă și nu face lucrul corect, acesta este context irosit.

Nivelul final de progresie îl reprezintă scripturile sau cazurile speciale, cum ar fi subskill-urile sau formatarea. Acesta este locul unde vrei să pui logică ramificată condiționată nelimitată. Agentul o va folosi doar atunci când are nevoie, ceea ce înseamnă că există o ștachetă mult mai joasă pentru ceea ce vrei să pui aici.

În index, fiecare token este important. Corpul de Skill încărcat este mai relaxat, iar runtime-ul este cel mai relaxat. Acesta ar putea fi de 20.000 de tokeni sau de zero tokeni. Acesta este nivelul la care s-ar putea să te gândești să extinzi contextul modelului într-o manieră progresivă.

Când ai nevoie de un Skill?

Echipa de agenți este adesea întrebată să își dea cu părerea dacă un Skill este cu adevărat necesar pentru un anumit domeniu sau caz de utilizare. Foarte rar avem un răspuns definitiv bazat doar pe principiile fundamentale. Singura modalitate de a ne da seama cu adevărat este să începi cu agentul tău fără Skill, să rulezi mai multe interogări principale și apoi să îți dai seama dacă agentul face o treabă bună.

Când ai nevoie de un Skill

Există multe sarcini care se află în distribuție pentru modelele antrenate. Trebuie să aplici un Skill doar dacă vrei să schimbi acest comportament într-un anumit mod specific pe care nu îl poți face, să zicem, cu o singură propoziție în promptul tău. Așadar, ai nevoie de un Skill atunci când agentul va înțelege greșit fără un context special, sau dacă există vreo incertitudine sau non-determinism pe care trebuie să le menții extrem de consistente între rulări.

S-ar putea ca cunoștințele tale să fie durabile, dar să nu se afle în datele de antrenament. Ar putea exista limite sau flux de lucru specifice unei companii, sau ar putea fi o chestiune de gust. De exemplu, avem mai multe Skill-uri legate de design în Computer scrise de Henry Modisett (șeful nostru de design). Motivul pentru care fiecare token există în acele Skill-uri este că Henry are un gust foarte bun când vine vorba de proiectarea site-urilor web și a fișierelor PDF. Henry specifică ce fonturi să folosești și ce fonturi să nu folosești, cum se simt acele fonturi și alte chestiuni de judecată pe care modelul nu le poate învăța doar din datele de antrenament.

Când nu ai nevoie de un Skill

Vedem multe Skill-uri în care inginerii au scris o serie de comenzi git care trebuie executate în ordine. Acest lucru este inutil deoarece modelul știe deja cum să facă asta, ceea ce înseamnă că reprezintă o documentație excelentă, dar un Skill slab.

Vedem exemple în care Skill-urile recapitulează instrucțiuni din promptul de sistem. Nu ai nevoie de un Skill pentru asta. Cunoștințele relevante pentru majoritatea cererilor ar trebui să fie incluse în contextul global, nu într-un Skill încărcat condiționat

Dacă există ceva care se schimbă mai repede decât îl poți menține, nu ai nevoie de un Skill. De exemplu, dacă accesezi vreun endpoint MCP la distanță și uneltele sale sau versiunile acelor unelte se schimbă frecvent, nu ar trebui să le injectezi într-un Skill. Dacă faci asta, vei ajunge doar la o nepotrivire, iar modelul va face greșeli.

Fiecare Skill este o taxă

Iată un test util pe care îl poți aplica fiecărei propoziții din Skill-ul tău: „Ar înțelege greșit agentul acest lucru fără această instrucțiune?” Dacă propoziția nu trebuie să fie acolo, nu își permite să fie acolo deoarece toată lumea plătește acest cost de fiecare dată. Când decizi dacă să adaugi sau nu un Skill, amintește-ți această taxă prin care fiecare sesiune și fiecare utilizator costă tokeni.

Următorul citat celebru, care sună mult mai bine în franceză, se traduce aproximativ prin „Nu am făcut această scrisoare mai lungă decât pentru că nu am avut timpul necesar să o fac mai scurtă.”

« 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

La fel ca Pascal, trebuie să investești timp în fiecare Skill. Este greu să scrii un Skill scurt. Dacă Skill-ul tău este ușor de scris, probabil că este prea lung sau nu ar trebui să existe. Un Skill bun este pe cât de scurt poate fi.

Dacă te trezești încercând să generezi un Skill dintr-o singură încercare și trimițând PR-uri în cinci minute, rezultatele vor fi aproape sigur sub așteptări. De fapt, cercetările timpurii au arătat că, dacă folosești LLM-uri pentru a scrie Skill-uri, LLM-ul probabil nu va beneficia de pe urma acestui lucru: „Skill-urile auto-generate nu oferă niciun beneficiu în medie, arătând că modelele nu pot autoriza în mod fiabil cunoștințele procedurale din a căror consumare beneficiază.”

Cum să construiești un Skill

Spus altfel, trebuie să îți injectezi propria opinie în orice Skill pe care îl scrii. Urmează acești pași.

Pasul 0: Scrie evaluările (Evals)

Scrie mai întâi câteva dintre evaluări. Poți obține cazuri de evaluare din:

Interogări reale ale utilizatorilor: eșantioane din producție sau din grupul tău de încredere

Eșecuri cunoscute: Agentul a eșuat deoarece Skill-ul nu exista

Confuzie cu vecinii: Aproape de limita domeniului tău, dar direcționează către un alt Skill

Cel puțin, ar trebui să te asiguri că testezi dacă Skill-ul se încarcă atunci când este necesar. În mod ideal, eșantionezi unele dintre acestea, poate dintr-un mediu de producție. De asemenea, ai putea lua în considerare cazurile de eroare cunoscute: poate că întregul motiv pentru care ai pornit la scrierea Skill-ului este un eșec specific pe care l-ai observat sau poate că refactorizezi și există o anumită confuzie în două domenii apropiate care sunt acoperite de un singur Skill.

Începe cu exemple negative și pozitive similare. Exemplele negative sunt extrem de puternice și pot conta mai mult decât exemplele pozitive.

Pasul 1: Descrierea

Aceasta este cea mai dificilă linie din Skill. Este un declanșator de rutare, nu o documentație. Pentru a nimeri numele și descrierea, nu îți pasă de conținutul Skill-ului. Te interesează doar dacă Skill-ul este încărcat și injectat la punctele corecte și nu are efecte secundare nedorite, care reprezintă modul principal de eșec. De fiecare dată când adaugi un Skill suplimentar, riști să faci fiecare alt Skill puțin mai slab, așa că trebuie să te asiguri că minimizezi regresia.

Din nou, o descriere proastă descrie ceea ce face Skill-ul sau de ce este util. O descriere bună spune când ar trebui ca agentul să încarce Skill-ul. De exemplu, să zicem că ai ceva pentru monitorizarea pull request-urilor. Nu scrie ceea ce face Skill-ul. Scrie ceea ce spun inginerii când sunt frustrați și vor să te asiguri că PR-ul lor funcționează, cum ar fi „babysit” (supraveghează), „watch CI” (urmărește CI) sau „make sure this lands” (asigură-te că este integrat).

Iată o listă de verificare rapidă:

Începe cu „Load when...” (Încarcă când...)

Țintește 50 de cuvinte sau mai puțin

Descrie intenția utilizatorului, ideal din interogări reale

Nu rezumă fluxul de lucru

Interogările reale sunt ceea ce poți acoperi într-o regulă 80-20. De obicei, două sau trei exemple funcționează bine. Nu este ușor să adaugi exact și doar atât cât ai nevoie.

Pasul 2: Scrie corpul

Apoi, scrie conținutul Skill-ului în sine. Observă că acesta nu este Pasul 0 sau Pasul 1.

Comunicarea fluxurilor de lucru către un LLM este complet diferită de comunicarea fluxurilor de lucru către un coleg sau chiar către sistemul tău de runtime. Când învață o unealtă software nouă, un inginer ar putea avea nevoie să citească documentația, să obțină un tur ghidat de la cineva cu experiență și să învețe cum să folosească unealta. Între timp, pentru aproape orice unealtă software care există de cel puțin un an, trebuie doar să îi menționezi numele, iar LLM-ul are toate informațiile de care are nevoie.

Când scrii corpul, sari peste lucrurile evidente. Mulți ingineri au o experiență bogată în scrierea fișierelor readme.md care listează fiecare comandă pe care cineva trebuie să o ruleze. Este ușor să revii la asta atunci când scrii un Skill deoarece se simte ca și cum ai scrie documentație, dar dacă faci asta, Skill-ul tău va fi un gunoi. Așadar, nu scrie o serie de comenzi.

De exemplu, nu trebuie să scrii, „git log # găsește commit-ul; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

În schimb, scrie: „Aplică prin cherry-pick commit-ul pe o ramură curată. Rezolvă conflictele păstrându-ți intenția. Dacă nu se poate integra curat, explică de ce.”

Modelul va face o treabă mult mai bună cu acesta din urmă decât cu seria de comenzi excesiv de prescriptivă a primului, mai ales atunci când lucrurile merg prost. Nu fi inflexibil și nu fi excesiv de prescriptiv, ceea ce este fragil, ci fii flexibil acolo unde mai multe abordări pot funcționa. Din nou, documentația bună pentru oameni este cel mai adesea documentație proastă pentru modele.

Apoi, concentrează-te pe capcane sau exemple negative. Acestea reprezintă conținut cu un semnal extrem de ridicat, deoarece ghidează adesea modelul în ceea ce privește ce să nu facă. Dacă adaugi o linie de fiecare dată când agentul dă greș, vei învăța rulându-l, iar capcanele vor crește în mod organic.

În cele din urmă, dacă există vreo porțiune care este condiționată sau extrem de grea în conținut, scoate-o din SKILL.md, care este hub-ul, și pune-o într-unul dintre brațe (spokes). Pune-o într-un fișier accesoriu care poate fi încărcat progresiv, în care vom aprofunda în continuare.

Pasul 3: Folosește ierarhia

Folosește ierarhia de Skill-uri atunci când ai un script, referințe sau folosești o unealtă specifică:

Utilizări recomandate pentru scripturi, referințe, resurse și configurare într-un Skill.

Pentru orice este condiționat sau se ramifică din Skill-ul principal, extrage-l într-un folder. Reține, de asemenea, că ierarhia cu mai multe niveluri poate fi utilizată pentru Skill-uri deosebit de intricate. Pentru acestea, vei dori să te gândești cu atenție dacă funcționalitatea ar trebui implementată monolitic sau ca o colecție de Skill-uri (probabil cu relații de încărcare bazate pe depends:).

Pasul 4: Iterează

Apoi, fă o serie de iterări pe o ramură. Începe pe ramura principală fără Skill, fă câteva iterări, construiește-ți setul de interogări principale și rulează o serie de evaluări. Oricine îți revizuiește codul de Skill îți va mulțumi pentru trimiterea unui singur set de modificări complet cu un set de evaluare. Revizuirea modificărilor incrementale consecutive (cu excepția unei noi capcane) este foarte dificilă, așa că încearcă să minimizezi acest lucru.

Probabil că vei face multe modificări mici de cuvinte. Modificările mici de cuvinte în descrieri pot avea un impact disproporționat asupra rutării (inclusiv efecte secundare asupra altor Skill-uri), așa că fă toată această muncă înainte de Pasul 5.

Pasul 5: Lansează

Lansează-l.

Cum să menții un Skill

Acum că ai scris un Skill, trebuie să îl menții.

Volanta capcanelor (Gotchas Flywheel)

Din acest moment, lista ta de capcane tinde să crească sau să se schimbe mult. Vedem adesea ingineri care fac PR-uri care nu sunt evaluate, de exemplu, schimbă descrierea. Dacă schimbi descrierea după ce Skill-ul tău a fost îmbinat, te-ai abătut de la drum. Dacă faci modificări la elementul care decide dacă să direcționeze Skill-ul tău, trebuie să scrii câteva evaluări care să susțină modificările.

Skill-urile sunt în mare parte aditive. Secțiunea de capcane acumulează cea mai mare valoare în timp:

Agentul eșuează la ceva → Adaugă o capcană

Agentul încarcă greșit Skill-ul → Îngustează descrierea și adaugă evaluări negative

Agentul nu încarcă Skill-ul când ar trebui → Adaugă cuvinte cheie și evaluări pozitive

Promptul de sistem se schimbă → Verifică dacă există divergențe sau duplicare

Este ușor să observi un singur caz de eșec în testarea internă sau în producție și să adaugi o capcană. Este un exemplu negativ, deci nu schimbă cu adevărat ghidarea explicită, dar îi permite modelului să știe: „Hei, există acest eșec cunoscut.”

Pe măsură ce treci de la regula 80-20 la atingerea unei rate de succes de 99,9% sau 99,99%, este ușor să mărești această listă de capcane. Pe măsură ce vezi aceste exemple negative, ar trebui să adaugi în mare parte la secțiunea de capcane. Nu ar trebui să adaugi instrucțiuni mai lungi sau să schimbi descrierea.

Suite de evaluare (Eval Suites)

La Perplexity, rulăm multe suite de evaluare pentru a verifica diverse aspecte. Există încărcarea de Skill-uri și citirea de fișiere de Skill-uri, care verifică precizia, rechemarea (recall) și verificările interzise ale încărcării Skill-ului în sine. Va direcționa agentul Skill-ul tău atunci când trebuie? Acestea se asigură că noile Skill-uri nu sparg granițele existente.

De asemenea, există evaluări care pot verifica încărcarea progresivă corectă. Agentul ar putea încărca Skill-ul, dar citește fișierul sau fișierele accesorii? De exemplu, dacă ai un Skill financiar pentru interogări financiare, citește fișierul special FORMATTING.md?

Există, de asemenea, evaluări pentru Skill-uri care testează finalizarea sarcinilor de la un capăt la celălalt (end-to-end) în cadrul domeniilor. Rulăm bucla completă a agentului și folosim un judecător LLM pentru a nota rezultatele pe baza unei rubrici de criterii bine definite.

În cele din urmă, este important să rulezi aceste evaluări împotriva unor modele diferite. Computer acceptă cel puțin trei familii diferite de modele de orchestrare: GPT, Claude Opus și Claude Sonnet. Vrei să rulezi încărcarea Skill-urilor și Skill-urile de domeniu împotriva acestor diferiți orchestratori de agenți pentru a te asigura că nu obții un comportament diferit. Sonnet și GPT se comportă destul de diferit când vine vorba de Skill-uri.

Gânduri finale și concluzii

Cu cât construiești mai multe Skill-uri, cu atât vei deveni mai bun în a le construi. Dacă nu automatizezi sau nu încerci să faci mai reproductibile sarcinile pe care le faci zi de zi folosind Skill-uri, începe imediat.

Actul de a construi Skill-uri te face mai bun în construirea altor Skill-uri, dar, de asemenea, ele sunt extrem de bune la automatizarea proceselor de afaceri. Dacă poți descrie ceva ce faci în fiecare săptămână înainte de standup-ul tău, la sfârșitul fiecărui sprint sau orice faci ca inginer pe bază zilnică, săptămânală sau chiar trimestrială, ar trebui să scrii un Skill pentru a-ți recâștiga timpul.

Poți automatiza post-mortem-urile? Poți revizui pull request-uri? Orice sarcină pe care o poți face, poți cel puțin să ai ca primă trecere un Agent Skill. Îți va economisi timp semnificativ.

Acestea fiind spuse, amintește-ți că un Skill nu este ușor sau chiar necesar întotdeauna. Mai puțin înseamnă mai mult. Câteva alte concluzii:

Scrie evaluări înaintea Skill-ului. Include exemple negative și încărcări interzise pentru skill-uri adiacente, dar distincte.

Descrierea este partea dificilă. „Load when...” (fiecui cuvânt îi costă atenție).

Capcanele reprezintă conținut cu o valoare extrem de ridicată. Începe simplu, crește pe măsură ce agentul eșuează.

Amintește-ți că este ușor să strici alte Skill-uri preexistente adăugând un Skill nou, chiar dacă nu l-ai atins (ferește-te de acțiunea la distanță).

Folosește toate uneltele disponibile de fiecare dată când scrii și menții un Skill. Dacă vrei să afli mai multe, site-ul web Agent Skills are o mulțime de exemple bune, iar atât repository-ul nostru intern, cât și ecosistemul public conțin numeroase exemple de Skill-uri bine proiectate.

Citat

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