Agentų įrankių projektavimas, tobulinimas ir priežiūra „Perplexity“

„Perplexity“ pažangių agentų produktai remiasi žinių ir sričių ekspertinės kompetencijos pagrindu, pateiktu moduliniuose Agent Skills įrankiuose. Savo techninėse aplinkose palaikome kruopščiai atrinktą įrankių biblioteką. Šie įrankiai apima daugelį bendrosios paskirties paslaugų programų, kurios maitina Perplexity Computer; specifines sritis finansų, teisės ir sveikatos apsaugos srityse; bei labai ilgą modulių uodegą, skirtą vartotojų poreikiams patenkinti. Kai kurie įrankiai kviečiami retai, tačiau kai yra kviečiami, jie yra kritiškai svarbūs. Siekiant užtikrinti nuosekliai puikią vartotojo patirtį, „Perplexity“ agentų komandos teikia pirmenybę įrankio kokybei lygiai taip pat, kaip ir kodo kokybei.

Nuojautos ir geriausia praktika, reikalingos aukštos kokybės įrankiui sukurti, iš esmės skiriasi nuo tų, kurios reikalingos kuriant tradicinę programinę įrangą. Agentų komanda peržiūri daug „pull“ užklausų iš puikių inžinierių, kurie kuria įrankius savo darbo metu. Rezultatas beveik visada yra daugybė komentarų ir pasiūlymų dėl pakeitimų. Taip yra todėl, kad daugelis naudingų kodavimo šablonų kuriant įrankius tampa antišablonais.

Pavyzdžiui, jei paimsite keletą aforizmų iš PEP20 – „Python“ dzeno, greitai paaiškėja, kad geros „Python“ kodo rašymo praktikos skiriasi nuo geros įrankių kūrimo praktikos. Iš 20 išminties eilučių bent pusė yra visiškai neteisingos arba aktyviai klaidinančios rašant įrankius. Štai penkios iš jų:

Penki kontrastai tarp Python „Zen“ ir straipsnio gairių, skirtų rašyti Skill.

Šis vadovas yra dokumentas, kurį inžinieriai visoje „Perplexity“ naudoja kurdami ir peržiūrėdami įrankius. Mes taip pat viešai išleidžiame šį vadovą, kad mūsų atradimai ir išmoktos pamokos galėtų būti naudingos platesnei bendruomenei. Nesvarbu, ar esate inžinierius, kasdieniame darbe kuriantis gamybinius įrankius, „Computer“ vartotojas, norintis susikurti savo įrankį geriausiai žinomoje srityje, ar abu – šis vadovas skirtas jums.

Kas yra įrankis?

Kai rašote įrankį, nerašote paprastos senos programinės įrangos (net jei įrankiai dabar yra pagrindinių agentų sistemų loginių variklių dalis). Greičiau kuriate kontekstą modeliams ir jų aplinkoms. Įrankis turi skirtingus apribojimus ir skirtingus projektavimo principus. Jei parašysite įrankį taip, kaip rašote kodą, jums nepasiseks.

Įrankis yra bent jau keturi dalykai, ypač kalbant apie tai, kaip juos kuriame „Perplexity“.

Įrankis yra katalogas

Įrankis nėra tik vienas SKILL.md failas. Daugeliu atvejų įrankis apima kelis failus. Aplanke, pavadintame jūsų įrankio vardu, galite turėti:

SKILL.md: įžanginė informacija ir instrukcijos

scripts/: kodas, kurį vykdo agentas, o ne išranda iš naujo

references/: sunkūs dokumentai, įkeliami sąlyginai

assets/: šablonai, schemos ir duomenys

config.json: pirmojo paleidimo vartotojo sąranka

Šis šerdies ir stipinų modelis leidžia išlaikyti įrankius labai sutelktus ir glaustus, o aplanko struktūrą galima naudoti labai kūrybiškai. Kartais ypač sudėtingi įrankiai naudingi naudojant kelių lygių hierarchiją, kad modelis geriau orientuotųsi. Tarkime, įrankiui reikia žinių apie 300 temų, kurias galima sugrupuoti į 20 dalykinių sričių. Patikimai pasirinkti tinkamą temą iš 300 yra neišspręstas iššūkis net ir šiandienos geriausiems pažangiausiems modeliams. Modeliui daug lengvesnė pasirinkimo problema yra susitelkti į vieną iš 20 sričių, o ne rinktis iš 15 temų toje srityje.

Kaip vieną iš pavyzdžių, kaip daugiapakopė hierarchija suteikia vertės, mūsų komanda praėjusį mokesčių sezoną taikė tris teminio įdėjimo lygius įrankiuose, valdančiuose „Computer“ JAV pajamų mokesčio galimybes. Atsižvelgiant į mokesčių įstatymų sudėtingumą, ši hierarchija buvo absoliučiai nepakeičiama: ankstyvuosiuose testuose pateikus modeliui vieną aplanką, kuriame buvo visi 1 945 JAV vidaus pajamų kodekso straipsniai, rezultatas buvo prastesnis nei išvis neįkėlus įrankio. Informacijos organizavimas į loginius padalinius buvo būtinas norint užtikrinti didelio tikslumo skaitymo operacijas.

Vis dėlto ši hierarchija nebuvo nemokama. Didėjantys hierarchijos lygiai reikalauja vis didesnio informacinės architektūros priežiūros lygio, kad būtų galima valdyti atsirandantį netiesiogikumą. Sukūrėme greitojo žinyno vadovus, pasirinktines paieškos paslaugų programas ir kitus įrankius, kurie padėtų modeliui rasti informaciją su minimaliu netiesiogikumu. Šiuo atveju sunkus kuravimo darbas galiausiai davė teigiamą galutinį rezultatą: įrankį, kuris leido modeliams atlikti su mokesčiais susijusias užduotis daug pajėgiau nei naudojant vien bendruosius įrankius.

Padidinti

Įrankis yra formatas

Įrankis yra formatas. Pagrindinis šakninis SKILL.md failas turi turėti ir pavadinimą, ir aprašą. Be to, įrankis turi tiksliai atitikti katalogo, kuriame jis yra, pavadinimą. Pavadinimas turi būti sudarytas tik iš mažųjų raidžių, be tarpų, ir gali naudoti brūkšnelius. Aprašas yra nukreipimo trigeris. Tai dažna gedimo vieta: aprašas nėra vidinė dokumentacija apie tai, ką įrankis daro. Jis prilygsta instrukcijoms modeliui, kada įkelti įrankį. Todėl dažnai matysite „Įkelti, kai“, o ne „Šis įrankis daro“. Tai svarbu dėl to, kaip daugelis realizacijų įterpia aprašą į modelio kontekstą.

Įžanginėje informacijoje taip pat yra „depends:“, kuris leidžia kurti hierarchines įrankių priklausomybes, ir „metadata:“, kuris naudojamas peržiūroms ir vertinimams. Skirtingos agentų sistemos gali netgi apibrėžti savo įžanginės informacijos laukus, naudojamus tam tikroms sistemoms būdingu būdu. Kaip alternatyvą, su įrankiu susijusius metaduomenis galima supakuoti į papildomą JSON arba YAML konfigūracijos failą. Tai pageidautina kuriant agentų sistemas, kurios turi palengvinti skirtingų tipų vykdymo laiko elgseną vienam įrankiui, neužteršiant modelio konteksto smulkmenomis. Galiausiai, panašų elgseną galima pasiekti skaitant pašalinant įrankio įžanginės informacijos laukus. „Computer“ naudoja šią metodologiją, kuri leidžia išlaikyti konfigūraciją šakniniame SKILL.md faile. Analizės logikoje reikia ypatingo dėmesio detalėms, ir gali būti naudinga įdiegti sąlyginį šalinimą, jei modelyje yra tam tikrų laukų, kuriuos naudinga turėti modelio kontekste.

Įrankis yra kviečiamas

Įrankis yra kviečiamas. Agentas įkelia įrankį vykdymo metu. Svarbu tai, kad įrankiai ne visada yra įtraukti į kontekstą. Pagal numatytuosius nustatymus dauguma agentų sistemų išskleidžia įrankius palaipsniui, atsižvelgiant į konkrečius poreikius.

„Computer“ įrankių įgyvendinime yra bent trys konteksto išlaidų lygiai. Štai procesas:

„Computer“ iškviečia load_skill(name="...")

„Computer“ nukopijuoja įrankio katalogą į izoliuotą vykdymo „sandbox“

„Computer“ rekursyviai automatiškai įkelia priklausomybes, nurodytas žymoje „depends:“

Tada „Computer“ pašalina įžanginę informaciją, todėl agentas mato tik pagrindinį tekstą ir papildomus failus

Skirtingos agentų sistemos gali pasirinkti rodyti įrankio turinį įvairiais būdais. Pavyzdžiui, kai kurios sistemos gali nuspręsti išvis nerodyti failų hierarchijos, palikdamos modeliui patiems atrasti hierarchiją per failų sistemos operacijas. Kitos sistemos gali pasirinkti suteikti modeliui viso failų medio žemėlapį iki tam tikro sutrumpinimo ir (arba) gylio ribos. Kad kontekstas būtų švarus, „Computer“ praleidžia pilnas failų hierarchijas iš iškvietimo konteksto; tačiau tai galima pakeisti kiekvienam įrankiui atskirai.

Įrankis yra progresyvusis

Įrankiai yra progresyvūs. „Computer“ yra trys skirtingi konteksto išlaidų lygiai, ir visus tris patiriame įvairiais etapais:

Trys Skill konteksto lygiai: rodyklė, visas Skill įkėlimas ir vykdymo laiko informaciniai failai.

„Computer“ sukuria įrankių indeksą, kuriame yra kiekvieno galimo įrankio pavadinimas ir aprašas. Biudžetas tam yra apie 100 žetonų vienam įrankiui (trumpesnis yra dar geriau). Jis toks griežtas, nes šią kainą mokate kiekvienoje sesijoje, už kiekvieną vartotoją. Tai įterpiama į sistemos raginimą pačioje pokalbio pradžioje. Modelis turi prieigą prie krūvos įvardintų įrankių ir aprašų, kad galėtų nuspręsti, ar iškviesti „load_skill()“. Patekimo į šį indeksą kartelė yra itin aukšta. Jūsų įrankis turi būti labai naudingas, o aprašas – itin tankus ir trumpas, nes visi šią kainą moka visą laiką.

Kai agentų sistema įkelia įrankį, pateikiamas visas SKILL.md tekstas. Idealiu atveju pagrindinis tekstas neviršija 5 000 žetonų. Net ir tada norite, kad kiekvienas sakinys būtų svarbus, nes įkėlę įrankį, likusioje pokalbio dalyje turite už tai sumokėti, kol pasieksite suspaudimo ribą. Daugelis gijų įkelia nuo trijų iki penkių skirtingų įrankių, padaugindamos šią kainą. Įrankiai su daug nereikalingo turinio beveik neabejotinai pablogins kitų įrankių, taip pat ir bendrus agento gebėjimus. Trumpai tariant, jei jūsų įrankis įkeliamas ir neatlieka to, kas reikia, tai yra švaistomas kontekstas.

Galutinis progresavimo lygis yra scenarijai arba specialieji atvejai, pavyzdžiui, subįrankiai arba formatavimas. Čia norite įdėti neribotą sąlyginę šakotąją logiką. Agentas ją naudos tik tada, kai reikės, o tai reiškia, kad čia norimai įdėti turiniui taikoma kur kas žemesnė kartelė.

Indekse kiekvienas žetonas yra svarbus. Įkelto įrankio tekstas yra laisvesnis, o vykdymo laikas – pats laisviausias. Tai galėtų būti 20 000 žetonų arba nulis žetonų. Tai lygis, kuriame galbūt galvojate apie modelio konteksto išplėtimą progresyviu būdu.

Kada jums reikia įrankio?

Agentų komandos dažnai prašoma pareikšti nuomonę, ar tam tikrai sričiai ar naudojimo atvejui tikrai reikia įrankio. Labai retai turime vienareikšmišką atsakymą tik remdamiesi pirminiais principais. Vienintelis būdas tai tikrai išsiaiškinti – pradėti darbą su agentu be įrankio, paleisti kelias pagrindines užklausas ir tada išsiaiškinti, ar agentas atlieka gerą darbą.

Kai jums reikia įrankio

Yra daug užduočių, kurios yra išmokytų modelių pasiskirstymo ribose. Įrankį turite taikyti tik tada, jei norite tam tikru būdu pakeisti šį elgesį, kurio negalite pakeisti, pavyzdžiui, vienu sakiniu savo raginime. Taigi, įrankio reikia, kai agentas suklystų be specialaus konteksto, arba jei yra kokių nors neatitikimų ar nedeterminizmo, kuriuos turite padaryti itin nuosekliais visuose paleidimuose.

Gali būti, kad jūsų žinios yra ilgalaikės, bet jų nėra mokymo duomenyse. Gali būti apribojimų ar įmonei specifinių darbo eigų, arba tai gali būti skonio reikalas. Pavyzdžiui, „Computer“ turime kelis su dizainu susijusius įrankius, kuriuos parašė Henry Modisett (mūsų dizaino vadovas). Priežastis, dėl kurios kiekvienas žetonas egzistuoja tuose įrankiuose, yra ta, kad Henry turi labai gerą skonį, kai kalbama apie svetainių ir PDF failų kūrimą. Henry nurodo, kokius šriftus naudoti ir kokių nenaudoti, kaip tie šriftai jaučiasi, ir kitus sprendimo reikalus, kurių modelis negali išmokti tik iš mokymo duomenų.

Kai jums nereikia įrankio

Matome daug įrankių, kuriuose inžinieriai parašė „git“ komandų seriją, kurią reikia įvykdyti iš eilės. Tai nereikalinga, nes modelis jau moka tai padaryti, o tai reiškia, kad tai puiki dokumentacija, bet prastas įrankis.

Matome pavyzdžių, kai įrankiai atkartoja instrukcijas iš sistemos raginimo. Tam įrankio nereikia. Žinios, kurios yra svarbios daugumai užklausų, turėtų būti įtrauktos į visuotinį kontekstą, o ne į sąlyginai įkeliamą įrankį

Jei kažkas keičiasi greičiau, nei galite tai prižiūrėti, įrankio nereikia. Pavyzdžiui, jei pasiekiate kokį nors nuotolinį MCP galinį punktą ir jo įrankiai arba tų įrankių versijos dažnai keičiasi, neturėtumėte jų įterpti į įrankį. Jei tai padarysite, galiausiai atsiras neatitikimų ir modelis padarys klaidų.

Kiekvienas įrankis yra mokestis

Štai naudingas testas, kurį galite taikyti kiekvienam savo įrankio sakiniui: „Ar agentas suklystų be šios instrukcijos?“ Jei sakinys neturi būti ten, jis negali sau leisti ten būti, nes visi šią kainą moka kiekvieną kartą. Kai sprendžiate, ar pridėti įrankį, ar ne, prisiminkite šį mokestį, kai kiekviena sesija ir kiekvienas vartotojas kainuoja žetonus.

Ši garsi citata, kuri prancūzų kalba skamba daug geriau, apytiksliai išversta reiškia: „Šį laišką padariau ilgesnį tik todėl, kad neturėjau laiko padaryti jo trumpesnio.“

„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 m.

Kaip ir Paskalis, turite skirti laiko kiekvienam įrankiui. Parašyti trumpą įrankį yra sunku. Jei jūsų įrankį parašyti lengva, jis turbūt yra per ilgas arba jo neturėtų būti. Geras įrankis yra toks trumpas, kiek įmanoma.

Jei pastebėsite, kad bandote vienu ypu sugeneruoti įrankį ir per penkias minutes pateikiate PR, rezultatai beveik neabejotinai bus prastesni. Tiesą sakant, ankstyvieji tyrimai parodė, kad jei naudojate didelius kalbos modelius (LLM) įrankiams rašyti, LLM tikriausiai iš toho negaus naudos: „Savarankiškai sugeneruoti įrankiai vidutiniškai nesuteikia jokios naudos, o tai rodo, kad modeliai negali patikimai sukurti procedūrinių žinių, iš kurių vartojimo jie gauna naudos.“

Kaip sukurti įrankį

Kitaip tariant, turite įterpti savo nuomonę į bet kurį parašytą įrankį. Atlikite šiuos veiksmus.

0 veiksmas: parašykite vertinimus

Pirmiausia parašykite keletą vertinimų. Vertinimo atvejų galite gauti iš:

Realių vartotojų užklausų: pavyzdžiai iš gamybinės aplinkos arba jūsų pasitikėjimo rato

Žinomų gedimų: agentas suklupo, nes įrankis neegzistavo

Kaimyninių painiavų: arti jūsų srities ribos, bet nukreipia į kitą įrankį

Bent jau turėtumėte įsitikinti, kad išbandote, jog įrankis įkeliamas, kai jo reikia. Idealiu atveju paimate keletą pavyzdžių, galbūt iš gamybinės aplinkos. Taip pat galite apsvarstyti žinomus klaidų atvejus: galbūt visa priežastis, dėl kurios nusprendėte parašyti įrankį, yra tam tikra pastebėta klaida, arba galbūt atliekate refaktoringą ir yra tam tikros painiavos dviejose artimose srityse, kurias apima vienas įrankis.

Pradėkite nuo panašių neigiamų ir teigiamų pavyzdžių. Neigiami pavyzdžiai yra nepaprastai galingi ir gali būti svarbesni už teigiamus pavyzdžius.

1 veiksmas: aprašas

Tai sunkiausia įrankio eilutė. Tai nukreipimo trigeris, o ne dokumentacija. Kad pavadinimas ir aprašas būtų teisingi, jums nerūpi įrankio turinys. Jums rūpi tik tai, ar įrankis yra įkeliamas ir įterpiamas reikiamuose taškuose bei neturi nepageidaujamų šalutinių poveikių, o tai yra pagrindinis gedimo būdas. Kiekvieną kartą, kai pridėdate papildomą įrankį, rizikuojate padaryti kiekvieną kitą įrankį šiek tiek prastesniu, todėl turite užtikrinti, kad sumažintumėte regresiją.

Vėlgi, blogas aprašas aprašo, ką įrankis daro arba kodėl jis yra naudingas. Geras aprašas nurodo, kada agentas turėtų įkelti įrankį. Pavyzdžiui, tarkime, kad turite kažką pull užklausų stebėjimui. Nerašykite, ką įrankis daro. Parašykite, ką inžinieriai sako, kai jie yra nusivylę ir nori, kad užtikrintumėte, jog jų PR veikia, pavyzdžiui, „prižiūrėti“, „stebėti CI“ arba „užtikrinti, kad tai praeitų“.

Štai trumpas kontrolinis sąrašas:

Prasideda „Įkelti, kai...“

Nukreipti į 50 žodžių ar mažiau

Aprašo vartotojo ketinimą, idealiai iš realių užklausų

Neapibendrina darbo eigos

Realios užklausos yra tai, ką galite apimti 80-20 taisyklėje. Paprastai gerai veikia du ar trei pavyzdžiai. Nėra lengva pridėti lygiai tiek, kiek reikia, ir tik tai.

2 veiksmas: parašykite tekstą

Tada parašykite paties įrankio turinį. Atkreipkite dėmesį, kad tai nėra 0 arba 1 veiksmas.

Darbo eigų perdavimas LLM visiškai skiriasi nuo darbo eigų perdavimo kolegai ar net jūsų vykdymo sistemai. Mokydamasis naujo programinės įrangos įrankio, inžinierius gali turėti paskaityti dokumentaciją, gauti patarimų iš patirtį turinčio asmens ir išmokti naudotis įrankiu. Tuo tarpu beveik bet kokiam programinės įrangos įrankiui, gyvuojančiam bent metus, tereikia paminėti jo pavadinimą, ir LLM turi visą reikiamą informaciją.

Rašydami tekstą, praleiskite akivaizdžius dalykus. Daugelis inžinierių turi daug patirties rašydami „readme.md“ failus, kuriuose išvardijama kiekviena komanda, kurią kažkas turi paleisti. Rašant įrankį lengva prie tego grįžti, nes atrodo, kad rašote dokumentaciją, bet jei tai padarysite, jūsų įrankis bus šiukšlė. Taigi, nerašykite komandų serijos.

Pavyzdžiui, nereikia rašyti: „git log # rasti commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;“

Vietoj to parašykite: „Perkelkite „commit“ į švarią šaką (cherry-pick). Išspręskite konfliktus išsaugodami ketinimą. Jei negali sklandžiai praeiti, paaiškinkite kodėl.“

Modeliui seksis daug geriau su pastaruoju variantu nei su per daug preskriptyvia pirmojo komandų seka, ypač kai kas nors pakrypsta ne ta linkme. Nebūkite per daug direktyvūs ar preskriptyvūs, nes tai yra trapu, o būkite lankstūs ten, kur gali veiktis keli metodai. Vėlgi, gera dokumentacija žmonėms dažniausiai yra bloga dokumentacija modeliams.

Tada sutelkite dėmesį į spąstus arba neigiamus pavyzdžius. Tai itin didelio signalo turinys, nes jie dažnai nukreipia modelį, ko nedaryti. Jei kiekvieną kartą, kai agentas suklumpa, pridedate po eilutę, mokysitės jį paleisdami, o spąstai augs natūraliai.

Galiausiai, jei yra kokia nors dalis, kuri yra sąlyginė arba turi labai daug turinio, išimkite ją iš SKILL.md, kuris yra šerdis, ir įdėkite į vieną iš stipinų. Įdėkite ją į papildomą failą, kurį galima palaipsniui įkelti, prie kurio pereisime kitame žingsnyje.

3 veiksmas: naudokite hierarchiją

Pasinaudokite įrankio hierarchija, kai turite skriptą, nuorodas arba naudojate tam tikrą įrankį:

Rekomenduojami scenarijų, nuorodų, išteklių ir konfigūracijos naudojimo būdai Skill viduje.

Bet kuriam dalykui, kuris yra sąlyginis arba išsišakojantis nuo pagrindinio įrankio, išskirkite jį į aplanką. Taip pat prisiminkite, kad daugiapakopė hierarchija gali būti naudojama ypač sudėtingiems įrankiams. Joms norėsite gerai apmąstyti, ar funkcionalumas turėtų būti įgyvendintas monolitiškai, ar kaip įrankių rinkinys (galbūt naudojant depends: pagrįstus įkėlimo ryšius).

4 veiksmas: kartokite

Tada atlikite daugybę iteracijų šakoje. Pradėkite pagrindinėje šakoje be įrankio, atlikite kelias iteracijas, sukurkite pagrindinių užklausų rinkinį ir paleiskite krūvą vertinimų. Kiekvienas, peržiūrintis jūsų įrankio kodą, padėkos jums už vieno pakeitimų rinkinio su vertinimų rinkiniu pateikimą. Peržiūrėti iš eilės eančius laipsniškus pakeitimus (išskyrus naujus spąstus) yra labai sunku, todėl stenkitės tai sumažinti.

Tikriausiai atliksite daug nedidelių žodžių pakeitimų. Maži žodžių pakeitimai aprašuose gali turėti milžinišką poveikį nukreipimui (įskaitant šalutinį poveikį kitiems įrankiams), todėl atlikite visą šį darbą prieš 5 veiksmą.

5 veiksmas: išleiskite

Išleiskite tai.

Kaip prižiūrėti įrankį

Dabar, kai parašėte įrankį, turite jį prižiūrėti.

Spąstų smagratis

Nuo šiol jūsų spąstų sąrašas linkęs labai augti arba keistis. Dažnai matome inžinierius, kurie pateikia PR, kurie nebuvo įvertinti, pavyzdžiui, keičia aprašą. Jei keičiate aprašą po to, kai jūsų įrankis buvo sujungtas, esate ne kelyje. Jei darote pakeitimus dalykui, kuris nusprendžia, ar nukreipti jūsų įrankį, turite parašyti keletą vertinimų, kurie palaiko šiuos pakeitimus.

Įrankiai iš esmės yra pildomi. Spąstų skyrius laikui bėgant įgyja daugiausia vertės:

Agentas suklumpa kažkur → Pridėti spąstus

Agentas įkelia įrankį ne į tikslą → Sugriežtinti aprašą ir pridėti neigiamų vertinimų

Agentas neįkelia įrankio, kai turėtų → Pridėti raktažodžius ir teigiamus vertinimus

Sistemos raginimo pakeitimai → Patikrinti, ar nėra nesutarimų ar dubliavimo

Lengva pastebėti vieną gedimo atvejį vidaus testavime arba gamybinėje aplinkoje ir pridėti spąstus. Tai neigiamas pavyzdys, todėl jis nelabai keičia aiškių nurodymų, bet jis leidžia modeliui žinoti: „Ei, čia yra žinomas gedimas.“

Kai pereinate nuo 80-20 prie 99,9% arba 99,99% sėkmės rodiklio, šį spąstų sąrašą nesunku išplėsti. Matydami šiuos neigiamus pavyzdžius, turėtumėte daugiausia pildyti spąstų skyrių. Neturėtumėte pridėti ilgesnių instrukcijų ar keisti aprašo.

Vertinimų rinkiniai

„Perplexity“ vykdome daug vertinimų rinkinių, kad patikrintume skirtingus dalykus. Yra įrankių įkėlimas ir įrankių failų skaitymas, kuris patikrina pačio įrankio įkėlimo tikslumą, atspindį ir draudžiamus patikrinimus. Ar agentas nukreiptų jūsų įrankį tada, kai privalo? Tai užtikrina, kad nauji įrankiai nesulaužytų esamų ribų.

Taip pat yra vertinimų, kurie gali patikrinti tinkamą progresyvų įkėlimą. Agentas gali įkelti įrankį, bet ar jis skaito papildomą failą ar failus? Pavyzdžiui, jei turite finansų įrankį finansų užklausoms, ar jis skaito specialų FORMATTING.md failą?

Taip pat yra įrankių vertinimų, kurie išbando užduočių užbaigimą nuo galo iki galo srityse. Vykdome visą agentų ciklą ir naudojame LLM teisėją, kad įvertintume rezultatus pagal gerai apibrėžtų kriterijų rubriką.

Galiausiai svarbu atlikti šiuos vertinimus su skirtingais modeliais. „Computer“ palaiko bent tris skirtingas orkestravimo modelių šeimas: „GPT“, „Claude Opus“ ir „Claude Sonnet“. Norite paleisti savo įrankio įkėlimą ir srities įrankius prieš šiuos skirtingus agentų orkestratorius, kad užtikrintumėte, jog negausite skirtingo elgesio. „Sonnet“ ir „GPT“ elgiasi gana skirtingai, kai kalbama apie įrankius.

Galutinės mintys ir išvados

Kuo daugiau įrankių sukursite, tuo geriau juos kursite. Jei neautomatizuojate ir nebandote padaryti kasdienių užduočių labiau atkuriamomis naudojant įrankius, pradėkite nedelsdami.

Įrankių kūrimo veiksmas padeda geriau kurti daugiau įrankių, be to, jie nepaprastai gerai automatizuoja verslo procesus. Jei galite apibūdinti tai, ką darote kiekvieną savaitę prieš savo susitikimą stovint, kiekvieno sprinto pabaigoje, ar bet ką, ką darote kaip inžinierius kasdien, kas savaitę ar net kas ketvirtį, turėtumėte rašyti įrankį, kad atgautumėte savo laiką.

Ar galite automatizuoti pomortem analizes? Ar galite peržiūrėti pull užklausas? Bet kuriai užduočiai, kurią galite atlikti, galite bent jau užtikrinti, kad pirmasis etapas būtų agento įrankis. Tai sutaupys jums daug laiko.

Vis dėlto atminkite, kad įrankis nėra lengvas ar net visada būtinas. Mažiau yra daugiau. Kelios kitos išvados:

Parašykite vertinimus prieš įrankį. Įtraukite neigiamus pavyzdžius ir draudžiamus įkėlimus gretimiems, bet skirtingiems įrankiams.

Aprašas yra sunki dalis. „Įkelti, kai...“ (kiekvienas žodis kainuoja dėmesį).

Spąstai yra nepaprastai vertingas turinys. Pradėkite plonai, augkite agentui suklupus.

Prisiminkite, kad lengva sugadinti kitus jau egzistuojančius įrankius pridedant naują įrankį, net jei jo nepalietėte (saugokitės veiksmų per atstumą).

Kaskart rašydami ir prižiūrėdami įrankį, naudokite visus galimus įrankius. Jei norite sužinoti daugiau, Agent Skills svetainėje pateikiama daug gerų pavyzdžių, o tiek mūsų vidaus saugykla, tiek viešoji ekosistema turi daug gerai suprojektuotų įrankių pavyzdžių.

Citata

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