Gyakori üzemeltetési probléma, hogy egy ügynök (agent) hatalmas kontextusablakkal rendelkezik — például 200 ezer tokennel — mégis fontos utasításokat figyelmen kívül hagy. A bemutatott esetben a ténylegesen szükséges 400 tokenes utasítások a 142 ezeredik pozíció alatt rejtőztek, hat eszközdefiníció, négy referenciadokumentum és egy felesleges márkaútmutató mögött. Az üzemzavar legtöbbször azért következik be, mert a prompt egyszerűen túl nagy lett és a lényeg belefulladt.
A javasolt megoldás: skills (készségek) — egyszerű fájlok és mappák sorozata, amelyek meghatározzák, hol lakik a kontextus és mikor töltődik be. Ez nem a nagyobb modellről, nagyobb ablakról vagy bonyolultabb lekérdező rendszerről szól, hanem arról, hogy a kontextust szervezetten, igény szerint szolgáltassuk.
A skill mappa mint egység
Egy skill nem osztály vagy regisztrált eszköz, hanem egy merevlemezen lévő mappa, amiben kötelezően egy SKILL.md fájl található. A SKILL.md az egyetlen kötelező elem; opcionálisak a referenciaszövegek (references), sablonok és márkaanyagok (assets), valamint a végrehajtható kódot tartalmazó script-ek (scripts). Minden a fájlrendszerben marad, így verziózható Git-ben, diffelhető pull requestekben, másolható projektek között és publikálható GitHub-on. A formátum maga a szerződés.
Ugyanez a SKILL.md formátum működik több futtatókörnyezettel: Claude Code, Codex, Gemini CLI, Cursor, Agent Development Kit, LangChain és más ügynök-keretrendszerek. Egy mappa, több környezet.
Az első két sor: keresési index
Minden SKILL.md elején YAML frontmatter van két mezővel: név és leírás. Ezek nem csupán metaadatok: szolgálnak a keresési indexként. A munkamenet kezdetén az ügynök betölti minden telepített skill nevét és leírását — ez nagyjából 100 token per skill. A részletes body, a referenciák és a script-ek továbbra is a lemezen maradnak.
Amikor bejön egy kérés, a modell átvizsgálja a saját katalógusát és eldönti, melyik skillt nyissa meg a leírás alapján. Ha a leírás túl általános, a skill sosem aktiválódik; ha a leírás célzott és kulcsszavakkal pontosít, a skill pontosan akkor fut, amikor kell. Ezért a rövid, de jól megfogalmazott leírás a legfontosabb része a skillnek.
Progresszív feltárás (progressive disclosure)
Egy skill tartalmazhat tízezernyi tokent instrukciókból és referenciákból. Ha egy ügynök 20 skillel van telepítve, az összes skill teljes szövege több teljes kontextusablaknyi „holt súlyt” jelenthet a felhasználó bármely bemenete előtt. A progresszív feltárás három betöltési rétegre osztja ezt:
- L1 — metadata: név és leírás. Mindig betöltődik munkamenetkezdéskor. Körülbelül 100 token per skill.
- L2 — instructions: a SKILL.md törzse (body). Csak akkor töltődik be, ha a leírás egyezik a feladat szándékával. Jellemzően néhány ezer token.
- L3 — references: a references/, assets/ és scripts/ tartalma. Csak akkor töltődik be, ha az L2 utasítás explicit módon hivatkozik rá.
Ezzel az eljárással egy 20 skillt tartalmazó ügynök azonos előzetes költséget futtat, mint egyetlen skilles ügynök: minden további skill csak L1 költséget jelent addig, amíg az nem aktiválódik. Fontos csapda: a progresszív feltárás akkor működik, ha tényleg használják a rétegeket. Ha minden példát és hosszú esettanulmányt bedobjuk a SKILL.md-be, az body felfúvódik és minden aktiválásnál fizetni kell érte. Ajánlatos a SKILL.md-t röviden tartani és a hosszú segédanyagokat a references/ könyvtárba helyezni.
Az ügynök útválaszt — a modell dönt
Érkezik egy kérés: az ügynök ugyanúgy jár el, ahogy egy ember nézné a szerszámosládát: felcímkézi, kiválasztja, kinyitja. Példa: a felhasználó azt mondja, "takarítsd ki ezt a kusza CSV-t és távolítsd el a duplikált sorokat." A modell átvizsgálja a leírásokat: a pdf-forms és brand-voice alacsony egyezést mutat, míg a data-clean: CSV cleanup, dedup, nulls erős egyezést — ekkor betöltődik a data-clean body és megkezdődik a munka.
Két fontos részlet:
- A meccs nem vektoralapú visszakeresés. A modell közvetlenül a saját kontextusában levő leírások alapján dönt — nincs embedding lépés, nincs külön hasonlósági pontszám vagy routing réteg. Az LLM maga a router.
- A meccs exkluzív. Feladatonként csak egy skill aktiválódik; a többiek L1-en maradnak és a body-juk soha nem kerül a kontextusablakba. A szükségtelen skillek költsége gyakorlatilag nulla.
Ez különbözteti meg a skill-eket a hagyományos eszközöktől vagy függvényhívásoktól, amelyek jellemzően mindig láthatók és mindig költséget jelentenek.
Kompozíció anélkül, hogy felfújná a kontextust
Skálázva: egy ügynök nyolc skill-lel, majd egy munkamenet során három különböző feladattal. Azokat a skilleket, amelyeket nem használtak, csak L1 költség terheli. A body költség csak azon feladatoknál merül fel, amelyek tényleg igénylik.
A minta szervezési előnyöket is hoz: csapatok függetlenül szállíthatnak skilleket. A data teamhez tartozhat a data-clean és sql-runner, a design teamhez a brand-voice és deck-build, a platform csapat integrálja az ügynököt. Nincs központi koordináció, nincs folyamatos prompt-merge vagy rendszerprompt újraépítés minden új képességnél.
A szerző viszonyításképp megemlíti: a skill-ek az ügynökök számára azt csinálják, amit az npm csinált a JavaScript-nek — kis, fókuszált, komponálható egységek tiszta interfésszel. Ahogy a csomagkezelő megnyerte a JavaScript ökoszisztémát, hasonló forma győzedelmeskedhet az ügynökök világában is.
Gyakorlati javaslat
Ha ügynökökkel dolgozol és még nem írtál skillt, válassz egy heti munkafolyamatot és hozd létre hozzá az első skillt: egy mappa, egy SKILL.md, verziózás Git-ben. Figyeld, hogyan aktiválódik az ügynök, és mérd a hatást. A formátum egyszerű fájlokból áll, de a nyújtotta leverage jelentős.
Összefoglalva: a kulcs az, hogy a kontextust ne egyszerre töltsük be, hanem a modell döntésén alapuló, lépcsőzetes betöltéssel hordozzuk az információt, így a fontos 400 tokenes utasítások nem fognak elvészni egy 200k tokenes ablakban.
