Ügynöki készségek tervezése, finomítása és karbantartása a Perplexitynél

A Perplexity határterületi ügynöktermékei a moduláris Agent Skills csomagban összegyűjtött tudásbázison és szakterületi szakértelmen alapszanak. Műszaki környezeteinkben gondosan válogatott Skill-könyvtárat tartunk fenn. Ezek a Skill-ek magukban foglalják a Perplexity Computer alapját képező számos általános célú segédprogramot; a pénzügy, a jog és az egészségügy területéhez kapcsolódó vertikális képességeket; valamint modulok igen hosszú sorát a felhasználói igények kielégítésére. Bizonyos Skill-ek ritkán kerülnek meghívásra, de meghívásuk során kritikus jelentőségűek. A folyamatosan kiváló felhasználói élmény biztosítása érdekében a Perplexity Ügynökcsapata ugyanolyan fontosnak tartja a Skill minőségét, mint a kódminőséget.

A magas minőségű Skill fejlesztéséhez szükséges intuíciók és best practice-ek jelentősen eltérnek a hagyományos szoftverek építéséhez szükségesektől. Az Ügynökcsapat számos pull requestet vizsgál át olyan kiváló mérnököktől, akik a munkájuk során Skill-eket fejlesztenek. Ennek eredménye szinte mindig számos megjegyzés és felülvizsgálati javaslat. Ennek az az oka, hogy a kódírás során hasznos minták közül sok ellenmintává válik a Skill-ek létrehozásakor.

Ha például átveszünk néhány aforizmát a PEP20 – The Zen of Python dokumentumból, hamar nyilvánvalóvá válik, hogy a jó Python-kód írása eltér a jó Skill-ek írásától. A 20 sornyi bölcsességből legalább a fele teljesen téves vagy aktívan félrevezető Skill-ek írásakor. Íme öt ezek közül:

Öt különbség a Python zenje és a Skills írására vonatkozó útmutatás között.

Ez az útmutató az a dokumentum, amelyet a Perplexity mérnökei használnak a Skill-ek fejlesztése és felülvizsgálata során. Ezt az útmutatót a nagyközönség számára is elérhetővé tesszük, hogy felfedezéseink és tanulságaink a szélesebb közösség javát szolgálhassák. Függetlenül attól, hogy Ön a napi munkája során termelési célú Skill-eket tervező mérnök, a saját területén leginkább ismert témában saját Skill fejlesztését célzó Computer-felhasználó, vagy mindkettő, ez az útmutató az Ön számára készült.

Mi az a Skill?

Amikor Skill-t ír, nem egyszerű, régi szoftvert ír (annak ellenére sem, hogy a Skill-ek ma már az ügynökrendszerek fő logikai motorjainak részét képezik). Ehelyett kontextust épít a modellek és környezetük számára. Egy Skill eltérő korlátokkal és eltérő tervezési elvekkel rendelkezik. Ha úgy ír egy Skill-t, mint a kódot, kudarcot vall.

Egy Skill legalább négy dolog, különösen annak a kontextusában, ahogyan a Perplexitynél építjük őket.

Egy Skill egy könyvtár

Egy Skill nem csupán egyetlen SKILL.md fájl. Sok esetben egy Skill több fájlt is magában foglal. A Skillről elnevezett könyvtár alatt a következőkkel találkozhat:

SKILL.md: frontmatter és utasítások

scripts/: kód, amelyet az ügynök futtat, nem pedig újra feltalál

references/: nehéz dokumentumok, feltételesen betöltve

assets/: sablonok, sémák és adatok

config.json: első futtatáskori felhasználói beállítás

Ez a központi és küllős (hub-and-spoke) minta lehetővé teszi, hogy a Skill-eket nagyon fókuszáltan és szorosan tartsa, és a mappaszerkezetet rendkívül kreatív módon lehet használni. Időnként a különösen bonyolult Skill-ek a hierarchia több szintjéből is profitálnak, hogy segítsenek a modellnek a jobb navigálásban. Tegyük fel, hogy egy Skill 300 témakör ismeretét igényli, amelyek 20 szakterületbe csoportosíthatók. A megfelelő téma megbízható kiválasztása 300 közül még a mai legjobb határterületi modellek számára is megoldatlan kihívás. A modell számára sokkal könnyebb választási probléma a 20 terület egyikére szűkíteni a kört, mint az adott területen belüli 15 téma közül választani.

Példaként arra, hogy a többszintű hierarchia hogyan biztosít értéket, csapatunk a legutóbbi adóbevallási szezonban a Computer amerikai személyi jövedelemadó-képességeit támogató Skill-ek keretében három szintre terjedő tematikus beágyazást alkalmazott. Ez a hierarchia az adójogszabályok összetettsége miatt teljesen nélkülözhetetlen volt: korai tesztjeink során, amikor a modellnek egyetlen, az Egyesült Államok Belső Adóbehajtási Kódexének (U.S. Internal Revenue Code) mind az 1 945 szakaszát tartalmazó mappát mutattunk be, rosszabb teljesítményt eredményezett, mint a Skill egyáltalán nem történő betöltése. Az információk logikai alosztályokba rendezése elengedhetetlen volt a nagy pontosságú olvasási műveletek biztosításához.

Ugyanakkor ez a hierarchia nem volt ingyen. Az emelkedő hierarchiaszintek az információs architektúra mentén növekvő szintű kurátori munkát igényelnek az ebből fakadó közvetettség kezelésére. Gyorsreferencia-útmutatókat, egyéni keresési segédprogramokat és egyéb eszközöket dolgoztunk ki, hogy támogassuk a modellt az információk minimális közvetettséggel történő megtalálásában. Ebben az esetben a kurátori munka nehéz elvégzése végső soron pozitív végeredményt hozott: olyan Skillt, amely lehetővé tette a modellek számára, hogy az adózással kapcsolatos feladatokat sokkal alkalmasabban hajtsák végre, mint önmagában az általános eszközök használatával.

Nagyítás

Egy Skill egy formátum

Egy Skill egy formátum. Az alapvető gyökér SKILL.md fájlnak névvel és leírással is rendelkeznie kell. Ezenkívül a Skillnek pontosan le kell képeznie azt a könyvtárnevet, amelyben a Skill található. A névnek kizárólag kisbetűkből kell állnia, nem tartalmazhat szóközt, és kötőjeleket használhat. A leírás az útválasztási trigger. Ez egy gyakori hibaforrás: a leírás nem belső dokumentáció arról, hogy mit csinál a Skill. Ez lényegében útmutatás a modell számára arról, hogy mikor kell betölteni a Skillt. Így gyakran fogja látni a „Load when” (Betöltés, ha) kifejezést a „This Skill does” (Ez a Skill ezt csinálja) helyett. Ez azért fontos, mert a legtöbb megvalósítás beilleszti a leírást a modellkontextusba.

A frontmatteren belül található még a „depends:” is, amely lehetővé teszi hierarchikus Skill-függőségek létrehozását, valamint a „metadata:”, amelyet felülvizsgálatokhoz és értékelésekhez használnak. A különböző ügynökrendszerek akár saját frontmatter-mezőket is definiálhatnak, amelyeket az adott rendszerekre jellemző módon használnak. Alternatív megoldásként a Skill-specifikus metaadatok egy kiegészítő JSON- vagy YAML-konfigurációs fájlba csomagolhatók. Ez akkor kívánatos, ha olyan ügynökrendszereket építenek, amelyeknek Skillenként különböző típusú futásidejű viselkedést kell megkönnyíteniük anélkül, hogy a modell kontextusát apróságokkal terhelnék. Végül hasonló viselkedés érhető el a Skill frontmatter olvasás közbeni eltávolításával is. A Computer ezt a módszertant alkalmazza, amely lehetővé teszi a konfiguráció megőrzését a gyökér SKILL.md fájlban. A elemzési logikában gondos odafigyelés szükséges a részletekre, és érdemes lehet feltételes eltávolítást megvalósítani, ha vannak olyan mezők, amelyek hasznosak a modell kontextusán belül.

Egy Skill meghívható

Egy Skill meghívható. Az ügynök futásidőben tölti be a Skillt. Fontos, hogy a Skill-ek nincsenek mindig kötegelve a kontextusba. Alapértelmezés szerint a legtöbb ügynökrendszer specifikus igény esetén fokozatosan kibontja a Skill-eket.

A kontextusköltségeknek legalább három szintje létezik abban a formában, ahogyan a Skill-eket bevezettük a Computerben. Íme a folyamat:

A Computer meghívja a load_skill(name="...") függvényt

A Computer átmásolja a Skill könyvtárat az izolált futtatási sandboxba

A Computer rekurzívan automatikusan betölti a függőségeket a „depends:” címkében

A Computer ezután eltávolítja a frontmattert, így az ügynök csak a törzset és a további fájlokat látja

A különböző ügynökrendszerek dönthetnek úgy, hogy különböző módon teszik közzé a Skill tartalmát. Például előfordulhat, hogy egyes rendszerek egyáltalán nem teszik közzé a fájlhierarchiát, hanem a modellre bízzák a hierarchia felfedezését fájlrendszerműveleteken keresztül. Más rendszerek dönthetnek úgy, hogy a teljes fájlfa leképezését megadják a modellnek egy bizonyos csonkítási és/vagy mélységi határig. A kontextus tisztaságának megőrzése érdekében a Computer kihagyja a teljes fájlhierarchiát a meghívási kontextusból; ez azonban Skillenként felülbírálható.

Egy Skill progresszív

A Skill-ek progresszívak. A Computerben a kontextusköltségeknek három különböző szintje létezik, és mind a hármat viseljük a különböző szakaszokban:

A Skill-kontekstus három szintje: index, teljes Skill-betöltés és futásidejű referenciafájlok.

A Computer olyan Skill-indexet épít, amely tartalmazza az összes elérhető Skill nevét és leírását. Ennek költségvetése körülbelül 100 token Skillenként (a rövidebb még jobb). Azért ennyire szigorú, mert ezt a költséget minden munkamenetben, minden egyes felhasználóért megfizeti. Ez a beszélgetés legelején bekerül a rendszerpromptba. A modell hozzáfér egy csomó elnevezett Skillhez és leíráshoz, így eldöntheti, hogy meghívja-e a „load_skill()” függvényt. Ebbe az indexbe bekerülni rendkívül nehéz. A Skillnek nagyon hasznosnak kell lennie, és a leírásnak rendkívül sűrűnek és tömörnek kell lennie, mivel mindenki folyamatosan fizeti a költséget.

Miután az ügynökrendszer betöltötte a Skillt, elérhetővé válik a teljes SKILL.md törzs. Ideális esetben a törzsszöveg nem haladja meg az 5 000 tokent. Még ekkor is azt szeretné, hogy minden mondat számítson, mert amint betölt egy Skillt, a beszélgetés hátralévő részének ezt meg kellfizetnie a tömörítési határ eléréséig. Számos szál három és öt különböző Skill között tölt be tetszőlegesen, megsokszorozva ezt a költséget. A sok sallangot tartalmazó Skill-ek szinte biztosan rontják a többi Skillt, valamint az általános ügynöki képességeket. Röviden: ha a Skill betöltődik, és nem a helyes dolgot teszi, az elpazarolt kontextus.

A fejlődés utolsó szintje a szkriptek vagy különleges esetek, például az al-készségek vagy a formázás. Itt érdemes elhelyezni a korlátlan feltételes elágazó logikát. Az ügynök csak akkor fogja használni, amikor szüksége van rá, ami azt jelenti, hogy sokkal alacsonyabb a küszöb ahhoz, amit itt el szeretne helyezni.

Az indexben minden token fontos. A betöltött Skill törzs nyugodtabb, és a futásidő a legnyugodtabb. Ez lehet 20 000 token vagy nulla token. Ez az a szint, amelyen elgondolkodhat a modell kontextusának progresszív kiterjesztésén.

Mikor van szükség Skillre?

Az Ügynökcsapatot gyakran kérik fel arra, hogy mondjon véleményt arról, hogy egy adott domainhez vagy use case-hez valóban szükség van-e Skillre. Nagyon ritkán van végleges válaszunk pusztán az alaptételekből. Az egyetlen módja annak, hogy erre rájöjjön, ha az ügynökkel kezdi a Skill nélkül, futtat néhány fő lekérdezést (hero query), majd kideríti, hogy az ügynök jól végzi-e a dolgát.

Mikor van szükség Skillre

Számos olyan feladat létezik, amely a betanított modellek eloszlásán belül van. Csak akkor kell Skillt alkalmaznia, ha valamilyen specifikus módon meg akarja változtatni ezt a viselkedést, amit mondjuk nem tud egyetlen mondattal megtenni a promptban. Tehát akkor van szükség Skillre, ha az ügynök különleges kontextus nélkül elrontja, vagy ha van valamilyen következetlenség vagy nem-determinizmus, amelyet rendkívül konzisztenssé kell tennie a futtatások során.

Előfordulhat, hogy a tudása tartós, de nincs benne a betanítási adatokban. Lehetnek határidők vagy vállalatspecifikus munkafolyamatok, vagy ízlés kérdése is lehet. Például a Computerben több, a designhoz kapcsolódó Skillünk is van, amelyeket Henry Modisett (a design vezetőnk) írt. Az ok, amiért minden token létezik ezekben a Skill-ekben az, hogy Henrynek nagyon jó ízlése van a weboldalak és PDF-ek tervezése terén. Henry megadja, hogy milyen betűtípusokat kell használni és melyeket nem, hogyan érződnek ezek a betűtípusok, valamint egyéb olyan ítélkezési kérdéseket, amelyeket a modell nem tud pusztán a betanítási adatokból megtanulni.

Mikor nincs szükség Skillre

Számos olyan Skillt látunk, amelyekben a mérnökök egy sor sorrendben végrehajtandó git-parancsot írtak. Ez felesleges, mert a modell már tudja, hogyan kell ezt csinálni, ami azt jelenti, hogy kiváló dokumentációt, de rossz Skillt eredményez.

Olyan példákat is látunk, ahol a Skill-ek megismétlik a rendszerprompt utasításait. Ehhez nincs szükség Skillre. A kérések többsége szempontjából releváns tudást a globális kontextusba kell belefoglalni, nem pedig egy feltételesen betöltött Skillbe

Ha valami olyan gyorsan változik, hogy azt nem tudja fenntartani, akkor nincs szüksége Skillre. Ha például valamilyen távoli MCP-végpontot ér el, és annak eszközei vagy az eszközök verziói gyakran változnak, akkor ezeket ne illessze be egy Skillbe. Ha ezt teszi, csak driftet kap, és a modell hibákat fog elkövetni.

Minden Skill egy adó

Íme egy hasznos teszt, amelyet a Skill minden mondatára alkalmazhat: „Elrontaná ezt az ügynök ezen utasítás nélkül?” Ha a mondatnak nem kell ott lennie, nem engedheti meg magának, hogy ott legyen, mert mindenki minden egyes alkalommal kifizeti ezt a költséget. Amikor arról dönt, hogy hozzáad-e egy Skillt vagy sem, emlékezzen erre az adóra, amelyben minden munkamenet és minden felhasználó tokenekbe kerül.

A következő híres idézet, amely franciául sokkal jobban hangzik, nagyjából úgy fordítható, hogy „Csak azért készítettem hosszabbra ezt a levelet, mert nem volt időm rövidebbre szabni.”

« 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

Pascals-hoz hasonlóan időt kell fektetnie minden egyes Skillbe. Nehéz rövid Skillt írni. Ha a Skillt könnyű megírni, akkor valószínűleg túl hosszú, vagy nem kellene léteznie. Egy jó Skill olyan rövid, amennyire csak lehet.

Ha azt veszi észre, hogy ötszörre próbál meg egy lépésben (one-shot) Skill-generálást végezni és PR-okat feltölteni öt perc alatt, az eredmények szinte biztosan gyengébbek lesznek. Valójában a korai kutatások kimutatták, hogy ha LLM-eket használ a Skill-ek írására, az LLM valószínűleg nem profitál belőle: „Az önmaguk által generált Skill-ek átlagosan semmilyen előnyt nem nyújtanak, ami azt mutatja, hogy a modellek nem képesek megbízhatóan szerzői szinten létrehozni azt a eljárási tudást, amelynek fogyasztásából profitálnak.”

Hogyan építsünk Skillt

Más szóval, bele kell vinnie a saját véleményét minden általaírt Skillbe. Kövesse ezeket a lépéseket.

0. lépés: Az eval-ok megírása

Először írjon meg néhány eval-t. Az értékelési eseteket a következőkből szerezheti be:

Valós felhasználói lekérdezések: mintavétel a production környezetből vagy a szellemi köréből (brain trust)

Ismert hibák: Az ügynök azért hibázott, mert a Skill nem létezett

Szomszédos zavar: Közel van a domain határához, de egy másik Skillre irányít át

Legalábbis meg kell győződnie arról, hogy teszteli a Skill betöltődését, amikor szükséges. Ideális esetben mintát vesz ezek közül, talán egy production környezetből. Megfontolhatja az ismert hibaeseteket is: talán az egész oka annak, hogy hozzáfogott a Skill megírásához, egy általa észlelt specifikus hiba, vagy talán refaktorál, és valamilyen zavar van két közeli domainben, amelyet egy Skill fed le.

Kezdje hasonló negatív és pozitív példákkal. A negatív példák rendkívül erősek, és fontosabbak lehetnek, mint a pozitív példák.

1. lépés: A leírás

Ez a Skill legnehezebb sora. Ez egy útválasztási trigger, nem pedig dokumentáció. Ahhoz, hogy a nevet és a leírást helyesen határozza meg, nem a Skill tartalma számít. Csak az számít, hogy a Skill a megfelelő pontokon töltődjön be és illeszkedjen be, és mentes legyen a céltévesztő mellékhatásoktól, ami az első számú hibaforrás. Minden alkalommal, amikor egy további Skillt ad hozzá, fennáll annak a kockázata, hogy minden másik Skillt kissé rosszabbá tesz, ezért meg kell győződnie arról, hogy minimalizálja a regressziót.

Ismétlem, a rossz leírás azt írja le, hogy mit csinál a Skill, vagy miért hasznos. A jó leírás azt mondja meg, hogy az ügynöknek mikor kell betöltenie a Skillt. Tegyük fel például, hogy van valami a pull requestek monitorozásához. Ne írja le, hogy mit csinál a Skill. Írja le, hogy mit mondanak a mérnökök, amikor frusztráltak, és azt akarják, hogy győződjön meg arról, hogy a PR-juk működik, olyan kifejezésekkel, mint a „babysit” (dajkálás), „watch CI” (CI figyelése) vagy „make sure this lands” (biztosítsd, hogy ez átmenjen).

Íme egy gyors ellenőrzőlista:

Így kezdődik: „Load when...” (Betöltés, ha...)

Célozzon meg legfeljebb 50 szót

Leírja a felhasználó szándékát, ideális esetben valós lekérdezésekből

Nem foglalja össze a munkafolyamatot

A valós lekérdezések azok, amelyeket egy 80-20-as szabály keretében lefedhet. Általában kettő vagy három példa jól működik. Nem könnyű pontosan és kizárólag annyit hozzáadni, amennyire szüksége van.

2. lépés: A törzs megírása

Ezután írja meg magának a Skillnek a tartalmát. Figyeljen arra, hogy ez nem a 0. vagy az 1. lépés.

A munkafolyamatok kommunikálása egy LLM felé teljesen eltér a munkafolyamatok kollégának vagy akár a futásidejű rendszernek történő kommunikációjától. Új szoftvereszköz tanulásakor előfordulhat, hogy egy mérnöknek el kell olvasnia a dokumentációt, bemutatót kell kapnia valakitől, aki rendelkezik tapasztalattal, és meg kell tanulnia a eszköz használatát. Eközben szinte minden olyan szoftvereszköz esetében, amely legalább egy éve létezik, elég csak megemlíteni a nevét, és az LLM-ben megvan az összes szükséges információ.

A törzs írásakor hagyja ki a nyilvánvaló dolgokat. Sok mérnöknek bőséges tapasztalata van readme.md fájlokírásában, amelyek felsorolják az összes olyan parancsot, amelyet valakinek le kell futtatnia. Könnyű visszatérni ehhez, amikor Skillt ír, mert olyan érzés, mintha dokumentációt írna, de ha ezt teszi, a Skill szemét lesz. Szóval ne írjon ki egy sor parancsot.

Például nem kell azt írnia, hogy „git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

Ehelyett írja azt: „Válassza ki (cherry-pick) a commitot egy tiszta ágra. Oldja meg a konfliktusokat a szándék megőrzésével. Ha nem tud tisztán átmenni, magyarázza meg, miért.”

A modell sokkal jobban fog teljesíteni az utóbbival, mint az előbbi túlságosan előíró parancssorozatával, különösen akkor, amikor a dolgok rosszul sülnek el. Ne vasúti pályára kényszerítve vagy túlságosan előíró módon működjön, ami törékeny, hanem legyen rugalmas ott, ahol több megközelítés is működhet. Ismétlem, az embereknek szóló jó dokumentáció a modellek számára legtöbbször rossz dokumentáció.

Ezután összpontosítson a gotchákra vagy a negatív példákra. Ezek rendkívül magas szignálértékű tartalmak, mivel gyakran irányítják a modelt abban, hogy mit ne csináljon. Ha minden alkalommal hozzáad egy sort, amikor az ügynök megbotlik, a futtatás révén tanulni fog, és a gotchák organikus módon fognak növekedni.

Végül, ha van olyan rész, amely feltételes vagy rendkívül nehéz tartalmú, vegye ki a SKILL.md-ből, amely a központ (hub), és helyezze át valamelyik küllőbe (spoke). Helyezze el egy kiegészítő fájlban, amely fokozatosan betölthető, és amelyre rövidesen rátérünk.

3. lépés: A hierarchia használata

Használja ki a Skill hierarchiát, ha van szkriptje, referenciája vagy valamilyen specifikus eszközt használ:

Javasolt felhasználási módok szkriptek, hivatkozások, eszközök és konfiguráció számára egy Skillben.

Bármi olyan dologért, amely feltételes vagy elágazik a fő Skilltől, bontsa ki egy mappába. Ne feledje azt sem, hogy a többszintű hierarchia használható a különösen bonyolult Skill-ekhez. Ezeknél alaposan át kell gondolnia, hogy a funkcionalitást monolitikus módon vagy Skill-gyűjteményként (talán depends: alapú betöltési kapcsolatokkal) kell-e megvalósítani.

4. lépés: Iterálás

Ezután végezzen el egy csomó iterációt egy ágon (branch). Kezdje a main ágon Skill nélkül, végezzen el néhány iterációt, építse fel a fő lekérdezési készletet (hero query set), és futtasson le egy sor eval-t. A Skill-kódot felülvizsgáló bárki hálás lesz azért, ha egyetlen változtatási készletet (changeset) nyújt be egy értékelési készlettel együtt. Az egymást követő növekményes változások (kivéve egy új gotchát) felülvizsgálata rendkívül nehéz, ezért próbálja meg minimalizálni.

Valószínűleg sok apró szóváltoztatást fog végezni. A leírásokban szereplő apró szóváltoztatásoknak túlzott hatása lehet az útválasztásra (beleértve a többi Skillre gyakorolt áttételes hatásokat is), ezért végezze el az összes ilyen munkát az 5. lépés előtt.

5. lépés: Kiadás (Ship)

Küldje ki (Ship it).

Hogyan kell karbantartani egy Skillt

Most, hogy megírt egy Skillt, karban kell tartania azt.

A Gotchák lendkereke (The Gotchas Flywheel)

Ettől a ponttól kezdve a gotchák listája hajlamos növekedni vagy sokat változni. Gyakran látunk olyan mérnököket, akik olyan PR-okat készítenek, amelyeket például nem értékeltek, és megváltoztatják a leírást. Ha a Skill egyesítése után módosítja a leírást, akkor letért a helyes útról. Ha módosításokat hajt végre azon a dolgon, amely eldönti, hogy a Skill az útvonalra lépjen-e, akkor írnia kell néhány olyan eval-t, amely támogatja a változtatásokat.

A Skill-ek többnyire hozzáadós jellegűek (append-mostly). A gotchák szakasza gyűjti össze a legtöbb értéket idővel:

Az ügynök hibázik valamiben → Gotcha hozzáadása

Az ügynök célt tévesztve tölti be a Skillt → Leírás szűkítése és negatív eval-ok hozzáadása

Az ügynök nem tölti be a Skillt, amikor kellene → Kulcsszavak és pozitív eval-ok hozzáadása

A rendszerprompt megváltozik → Ütközés vagy duplikáció ellenőrzése

Könnyű észrevenni egyetlen hibaesetet a belső tesztelés során vagy a productionben, és hozzáadni egy gotchát. Ez egy negatív példa, szóval nem igazán változtatja meg az explicit útmutatást, de tudatja a modellel: „Hé, itt van ez az ismert hiba.”

Ahogy halad a 80-20-as szabálytól a 99,9%-os vagy 99,99%-os sikerességi arány elérése felé, könnyű növelni ezt a gotcha-listát. Ahogy látja ezeket a negatív példákat, nagyrészt hozzá kell fűznie a gotcha szakaszhoz. Nem szabad hosszabb utasításokat hozzáadnia vagy megváltoztatnia a leírást.

Eval csomagok (Eval Suites)

A Perplexitynél számos eval csomagot futtatunk, amelyek különböző dolgokat ellenőriznek. Létezik Skill-betöltés és Skill-fájlolvasás, amely ellenőrzi magának a Skill-betöltésnek a pontosságát (precision), visszahívását (recall) és a tiltott ellenőrzéseket. Útvonalra tereli-e az ügynök a Skillt, amikor kellene? Ezek biztosítják, hogy az új Skill-ek ne törjék meg a meglévő határokat.

Olyan eval-ok is léteznek, amelyek ellenőrizni tudják a megfelelő progresszív betöltést. Lehet, hogy az ügynök betölti a Skillt, de beolvassa-e a kiegészítő fájlt vagy fájlokat? Ha például van egy pénzügyi Skillje a pénzügyi lekérdezésekhez, beolvassa-e a speciális FORMATTING.md fájlt?

Léteznek eval-ok olyan Skill-ekhez is, amelyek a domaineken belüli végpontok közötti (end-to-end) feladatok teljesítését tesztelik. Futtatjuk a teljes ügynökhurkot (agent loop), és egy LLM-bíráló segítségével osztályozzuk az eredményeket egy jól definiált kritériumokból álló értékelési rubrika alapján.

Végül fontos, hogy ezeket az eval-okat különböző modellekkel szemben is lefuttassuk. A Computer legalább három különböző vezénylési modellcsaládot támogat: a GPT-t, a Claude Opust és a Claude Sonnetet. Futtatnia kell a Skill-betöltést és a domain Skill-eket ezekkel a különböző ügynök-vezénylőkkel szemben, hogy biztosítsa a következetes viselkedést. A Sonnet és a GPT meglehetősen eltérően viselkedik a Skill-ek terén.

Végső gondolatok és tanulságok

Minél több Skillt épít, annál jobban fog menni az építésük. Ha nem automatizálja, vagy nem próbálja meg a mindennapi feladatait reprodukálhatóbbá tenni a Skill-ek használatával, kezdje el azonnal.

A Skill-ek építésének folyamata jobbá teszi Önt további Skill-ek építésében, ráadásul rendkívül alkalmasak az üzleti folyamatok automatizálására is. Ha le tud írni valamit, amit minden héten elvégez a standup előtt, minden sprint végén, vagy bármit, amit mérnökként napi, heti vagy akár negyedéves szinten tesz, akkor írnia kell egy Skillt, hogy visszavásárolja a idejét.

Tudja automatizálni a posztmortemeket? Tud pull requesteket felülvizsgálni? Bármilyen feladatot el tud végezni, legalább az első kört megteheti egy Agent Skill segítségével. Jelentős időt takarít meg vele.

Ennek ellenére ne feledje, hogy egy Skill nem könnyű, és nem is mindig szükséges. A kevesebb több. Néhány további tanulság:

Írjon eval-okat a Skill előtt. Tartalmazzon negatív példákat és tiltott betöltéseket a közeli, de eltérő Skill-ekhez.

A leírás a nehéz rész. „Load when...” (minden szó figyelmet emészt fel).

A gotchák rendkívül magas értékű tartalmak. Kezdje vékonyan, növekedjen az ügynök hibázásával.

Ne feledje, hogy egy új Skill hozzáadásával könnyen el lehet rontani más előre létező Skill-eket, még akkor is, ha nem érintette meg azokat (óvakodjon a távoli hatásoktól).

Használja az összes elérhető eszközt minden alkalommal, amikor Skillt ír és tart karban. Ha többet szeretne megtudni, az Agent Skills weboldal bőségesen kínál jó példákat, és a belső adattárunk, valamint a nyilvános ökoszisztéma is számos példát tartalmaz a jól megtervezett Skill-ekre.

Idézet

@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://www.perplexity.ai/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}