Mindenki AI-ügynököt (AI agent-et) akar. Kevesen teszik fel a kérdést, hogy kell-e neki. Ebben a posztban sorban végigmegyünk azon, mi az agent és az agentic rendszer, mik a skillek és a pluginok, hogyan lehet egy ágensnek fix tudást és szigorú guidelineokat adni, miért drágák az agentic workflow-k, és mikor nyer egy saját gépi tanulási modell, egy automatizációs rendszer vagy a saját fejlesztésű DocAudit rendszerünk.

Röviden

• Az AI-ügynök olyan nagy nyelvi modell (LLM), amely eszközöket hív, és a saját lépéseit egy ciklusban maga dönti el, sőt léteznek autonóm ágens rendszerek, amelyek a ciklusok sorrendjét és kivitelezését is eldöntik (pl.: Claude Cowork, OpenClaw). Az agentic rendszer ennél tágabb fogalom: ide tartoznak a rögzített lépésű workflow-k is.

• A skill egy mappa, benne egy SKILL.md fájllal: szakmai tudás és eljárás, amit az agent csak akkor tölt be, ha a feladat megkívánja. Ettől olcsóbb és pontosabb, mint mindent a promptba tölteni, viszont nem egy szigorú megkötés, hanem csak egy újabb prompt részlet.

• A plugin csomagolási réteg: skilleket, hookokat, subagenteket és MCP-szervereket egyetlen telepíthető egységbe fog össze.

• A szigorú szabályokat nem a promptba írjuk, hanem rétegezzük: prompt és skill (puha), hook, séma-validáció és jogosultság (kemény), emberi jóváhagyás és audit trail (ellenőrzés).

• Az agentic rendszerek futása drága és nem determinisztikus. Ahol a feladat előre leírható, ott workflow vagy saját ML/DS modell jobb.

• Saját megoldásunk az Agentic rendszerek problémáira: DocAudit. Nem „még egy ágens rendszer", hanem dokumentumalapú, auditálható workflow-platform. Skillenként választható, hogy sima kód, saját ML-modell, LLM vagy agent hajtja végre a lépést, így az LLM csak ott fut, ahol tényleg kell.

1. Mi az AI-ügynök (agent), mi az agentic rendszer, és miért jó?

Az alapok

Egy nagy nyelvi modell (LLM) önmagában szöveget kap, és szöveget ad vissza. Magától nem tud keresni az interneten, fájlt megnyitni vagy kódot futtatni. Képzelj el egy szakértő óraművest, akinek vekkert kell készítenie eszközök nélkül.

Akkor miért tudnak ezek a platformok mégis feladatokat végrehajtani? A különböző AI-asszisztens-platformok (például ChatGPT, Claude, Gemini vagy a Grok) azért képesek erre, mert a körítést ők rakják a modell mellé. A keresőt, a fájlkezelést, a kódfuttatót és minden egyéb eszközt a modell magától nem képes kezelni, a platform adja hozzá ezeket a funkciókat.

Az agentic AI (ágensalapú MI) erre épít. Az LLM eszközöket kap, és ezekkel végrehajt feladatokat, ezt hívják function calling-nak. A legtöbb ágens rendelkezik bizonyos szintű autonómiával, például a modell meghív egy keresőt, megnyit egy dokumentumot, lefuttat egy scriptet, majd a kapott eredmény alapján dönt a következő lépésről. Ezáltal az Agentic rendszerek két legfontosabb jellemzője a Tool Calling és az Autonómia.

Az Anthropic a fogalmat két részre bontja (Building effective agents):

Az agentic rendszer mindkettőt magában foglalja. A tágabb csoportba tartoznak a rögzített lépésű workflow-k, a szűkebb-be a teljesen önjáró ágensek, amik maguktól tudják iterálni a lépéseket. Az ágens lényege az Anthropic megfogalmazásában, hogy minden lépésnél „ground truth”-t kap a környezetből (például egy eszközhívás eredményét vagy egy kódfuttatás kimenetét), és ebből ítéli meg, hol tart.

Pár példa agentic rendszerekre felhasználásuk szerint

Ezek a típusok gyakorlatilag az LLM mellé a „körítést” kínálják, nem az AI-fejlesztés a speciális benne, hanem a kód, ami meghívja az AI réteget. Az ágensek lényege a modell köré épített eszközkészletben rejlik, és vezérlést a saját rendszeredben is megépítheted, nem csak a nagy platformok kiváltsága.

Miért jó, ha van agentic rendszer?

• Eszközhasználat: Nemcsak beszél, hanem cselekszik is: keres, számol, ír, hív, ellenőriz.

• Rugalmasság: Ahol nem lehet előre lerajzolni a döntési fát (kutatás, hibakeresés, komplex ügyintézés), ott az agent alkalmazkodik.

• Skálázható emberi jellegű munka: Sok kicsi feladatot képes párhuzamosan végezni. Az Anthropic multi-agent kutatórendszere például 90,2%-kal szárnyalta túl az egyetlen ágenst a belső kutatási teszten (forrás).

Mivel az AI sosem alszik, és könnyen skálázódik, ezért egy működő prototípus összerakása órák, legrosszabb esetben napok kérdése, míg hagyományos fejlesztéssel ez elhúzódhat hetekig.

2. Mik azok az agentic skillek, és miért jobbak, mint mindent a promptba tenni?

A skill egy mappa, amelyben egy SKILL.md fájl és opcionálisan scriptek, referenciafájlok, sablonok is vannak. Az Anthropic fejlesztette ki, és 2025. december 18-án nyílt szabványként tették közzé (Agent Skills Explained). Az Agent Skills specifikáció ma az agentskills.io oldalon él.

Az ágens induláskor csak a skill nevét és rövid leírását látja, skillenként nagyságrendileg kevesebb mint száz token táplálódik be így a modell kezdeti kontextusába (forrás). A teljes SKILL.md csak akkor töltődik be, ha a feladat illeszkedik rá. A hivatkozott fájlok és scriptek pedig csak akkor, ha a végrehajtás közben kellenek. Így a modell nem veszik el az utasítások hálózatában és csak akkor kapja meg a kívánt információt, amikor szüksége van rá. Egy skill három szintből áll:

1. Metaadat (név, leírás): mindig a kontextusban, szinte ingyen.

2. Utasítások (SKILL.md törzse): csak aktiváláskor.

3. Erőforrások (scriptek, referenciák, sablonok): csak szükség esetén.

A csatolt scriptek ráadásul úgy futnak le, hogy a tartalmuk nem kerül be a kontextusablakba. Ez azért fontos, mert a hosszú szöveg és instrukció halmazokban az LLM-ek hajlamosak „elveszni”, ezért romolhat az effektivitásuk, és minden felesleges token, amit felhasznál pénzbe kerül. A skill legnagyobb előnye, hogy ember által olvasható, verziózható, megosztható és cserélhető utasítás csomag, ami fájl szinten könnyen szerkeszthető. A szakértő (jogász, könyvelő, auditor) maga is megírhatja, így a fejlesztőnek nem muszáj hozzányúlnia a kódhoz. Az ökoszisztéma gyorsan terjed: az OpenAI, a Google, a GitHub Copilot és a Cursor is átvette a szabványt

3. Hogyan adj szigorú guidelineokat és fix tudást egy agentnek?

A nagy nyelvi modellek alapvető igazsága, hogy egy prompt nem szabály, hanem kérés. Az LLM valószínűségi modell, ezért amit „szigorúan” a promptba írsz, azt is megszegheti. Ha valami nem sérülhet, azt ne a modellre bízzuk. A gyakorlatban különböző jogosultsági és validációs rétegeket definiálunk:

A Claude Code dokumentációja pontosan így osztja fel a szerepeket: a CLAUDE.md az always-on kontextusért, a skillek az igény szerinti tudásért, a subagentek az izolációért, a hookok pedig az automatizálásért felelnek (Extend Claude Code).

Ugyanez igaz a kész, általános eszközökre is. A Claude Cowork például sok mindenre képes, de megfelelő keretrendszer (harness) nélkül kiszámíthatatlan. A biztonságos munkavégzés miatt muszáj jogosultságokat, szabályokat és ellenőrzött munkafolyamatokat definiálni a modell köré.

4. Mik azok a pluginok?

A plugin egy összecsomagolt fél-ágens rendszer. A Claude Code dokumentációja szerint a plugin skilleket, hookokat, subagenteket és MCP-szervereket (Model Context Protocol: egy olyan általános keretrendszer, ami integrálja a modelleket külső eszközökhöz és instrukciókhoz) fog össze egyetlen telepíthető egységbe (Extend Claude Code; Plugins reference). A plugin szintén csak kérésre töltődik be a modell kontextusába (például /my-plugin:review), így több plugin is megfér egymás mellett.

Plugin nélkül is mindegyik elem önállóan működik. A plugin akkor éri meg, ha több elemet együtt, egy csapatnak, egy paranccsal szeretnél kiadni. Például egy pénzügyi audit plugin, amelyben ott vannak a számlaellenőrző skillek, a tiltott műveleteket blokkoló hookok és a könyvelőrendszerhez csatlakozó MCP-szerver. A pluginok gyakorlatilag összecsomagolnak minden olyan réteget, amitől az LLM egy ágenssé válhat. Tökéletesek arra, hogy cégen belül mindenkinek a Coding Agentje ugyanazon elvek alapján működjön.

Ha a csomagot nem egy fejlesztői eszközhöz, hanem a cég meglévő rendszereihez (ERP, CRM, dokumentumtár) kell kötni, az MCP-szerver vagy az API-integráció ugyanúgy a jogosultságkezelésen és a naplózáson múlik. Erről szól az AI-modul meglévő rendszerbe szolgáltatásunk.

5. Az agentic workflow-k hátrányai, és miért drágák

A költség

Az agentic rendszerek futtatása elég költséges tud lenni, és erről a hype ritkán beszél. Az Anthropic saját mérése szerint az ágensek átlagosan ~4× annyi tokent használnak, mint egy sima csevegés, a multi-agent rendszerek pedig kb. 15× annyit. A teljesítménykülönbség 80%-át a felhasznált tokenek mennyisége magyarázza (How we built our multi-agent research system; összefoglaló). A modern LLM-ek egyik fő funkciója a gondolkodási képességük, ezt hívják reasoningnek. A modell reasoning során lépésről lépésre végiggondolja a kért problémára a választ.

Reasoning során a modell nagyobb valószínűséggel ad helyes választ a problémánkra, viszont a folyamat során képes jelentős token költséget felhalmozni, illetve a feladat megoldása is lassabb lesz. Ha belegondolunk az emberek gondolkodás közben szintén alkalmazzák a „több szem, többet lát” elvet, vagyis a multi-agent rendszer részben azért jobb, mert többet költhet és gondolkozhat. Ez egyetlen gyártó mérése a saját kutatórendszeréről, nem általános szorzó, de jól mutatja a nagyságrendet.

Gartner figyelmeztetése

A Gartner előrejelzése szerint az agentic AI projektek több mint 40%-át 2027 végéig leállítják a növekvő költségek, a tisztázatlan üzleti érték vagy a nem megfelelő kockázatkezelés miatt. Szerintük sok „agentic” megoldásnak nincs is szüksége agentic megvalósításra, és csak mintegy 130 gyártó kínál valóban ágensalapú képességeket az állítólag több ezerből. A többi pedig „agent washing”, azaz átcímkézett chatbot vagy RPA (Gartner sajtóközlemény összefoglalva; agent washing).

Az agent washing az átláthatóság hiányának egyik formája: a vásárló nem látja, mi van valójában a címke mögött, azonban van egy másik eset is, amikor nem látjuk, hogy mi készült géppel. Az EU AI Act 50. cikke 2026. augusztus 2-án lépett hatályba, és azt írja elő, hogy az AI-jal generált szöveget, képet és hangot gépi úton olvasható módon meg kell jelölni. Hogy ez a gyakorlatban hogyan működik, és mit bizonyít vagy mit nem bizonyít egy vízjel, azt külön cikkben írtuk le: AI írta? Hamarosan bizonyítható lesz!

A hátrányok

1. Drága futás. Minden extra LLM-hívás pénz, és a költség nem lineárisan nő, mert a kontextust minden lépésnél újra átadjuk.

2. Lassú. A lépések egymásra várnak. Az Anthropic szerint az agentic rendszerek általában késleltetést és költséget cserélnek jobb teljesítményre.

3. Nem determinisztikus. Ugyanarra a bemenetre másik útvonalat választhat. Auditnál ez komoly gond.

4. Halmozódó hibák. Egy korai tévedés végigfut a láncon.

5. Nehéz költségkorlátot szabni. A workflow költsége előre becsülhető, az ágensé kevésbé (összefoglaló).

6. Hallucináció. Az LLM magabiztosan tévedhet, és nyelvi modellként a tokenizálás miatt alapvető feladatokban is hibázhat (a klasszikus példa: hány „r” betű van a „strawberry” szóban). A mai modellek sok feladatban az embert is felülmúlják, mégis elhasalnak olyan problémákon, amelyeket egy ember könnyen megold. Ezért érdemes óvatosan kezelni az olyan állításokat, hogy egy új modell „emberfeletti”, vagy hogy már elérte az általános mesterséges intelligenciát (AGI). Hogy egy benchmark mit mér és mit nem, azt az ARC-AGI és a GPT-6 Astra példáján mutattuk be: Mit jelent egy AI-benchmark?

7. Üzemeltetési teher. Monitorozás, evaluáció, verziózás, biztonsági felülvizsgálat: ezek sokszor drágábbak, mint maga a fejlesztés.

Mivel lehet olcsóbbá tenni?

A költség két irányból csökkenthető. Az egyik a feladatok szétválasztása: az egyszerű lépéseket kód vagy ML-modell végzi vagy egy kisebb modell végzi, a nagy modell csak a nehéz, nyelvi döntéseket hozza. A másik a futtatás helye. Egy helyben futó nyílt modellnél nincs tokendíj, cserébe hardvert kell venni és üzemeltetni.

Hogy mennyibe kerül egy AI-szerver és a felhős megoldás, mekkora modellt futtat egy adott gép, és hány felhasználót bír ki, azt külön cikkben számoltuk végig: Mennyibe kerül a saját vállalati AI?. A konklúziója röviden az, hogy a saját hardver akkor térül meg, ha tartósan terhelve van, ezért a legtöbb cégnél a felhő a jó első lépés, a helyi rendszer pedig akkor jön, amikor a használat már kiszámítható. Ahol az adat nem hagyhatja el a céget, ott az on-premise AI-megoldásunk a járható út.

6. Nem minden AI generatív: a gépi tanulás (ML) és a data science (DS)

Ez a vonal kevésbé ismert, de sok feladatra sokkal olcsóbb, pontosabb és szakmaibb megoldás, mint egy agent.

Gépi tanulás (machine learning): Olyan statisztikai algoritmusok fejlesztése és vizsgálata, amelyek adatokból tanulnak, és a tanultakat korábban nem látott adatokra is általánosítják, vagyis kifejezett programozás nélkül hajtanak végre feladatokat. Ez nem generatív AI, mint a ChatGPT vagy a képgenerálók, hanem saját fejlesztésű, célzott modell.

Példa: egy modell, amely egy feladat leírása alapján eldönti, hogy ki vagy mi végezze el. Ember, AI vagy programkód. Ezt egy nagy nyelvi modell is meg tudja oldani, de drágán és lassan, mert az LLM minden feladat megoldására lett kitalálva, nem csak erre az egyre. Egy erre betanított kis modell ezredannyiból, ezredmásodpercek alatt dönt és pontosabban. Ilyen a Jev is.

Data science: Az a tudományág, amely statisztikát, tudományos számítástechnikát, algoritmusokat, programozást és vizualizációt alkalmaz arra, hogy tudást nyerjen ki zajos, strukturált vagy strukturálatlan adatokból. A data scientist kódot ír, és statisztikai ismeretek alapján összegzi az adatokat. A data science ott a leghasznosabb, ahol nagy mennyiségű, folyamatosan keletkező adat áll rendelkezésre, és a döntéseket gyorsan, sokszor kell meghozni:

• Pénzügy és bankszektor: csalásfelderítés és hitelkockázat-értékelés több millió tranzakción.

• Energetika: fogyasztás- és terhelés-előrejelzés okosmérők adataiból.

• Gyártás és ipar: prediktív karbantartás gépek szenzoradataiból, hibák előrejelzése a meghibásodás előtt.

• Egészségügy: orvosi képalkotó felvételek elemzése, amely a szakembert támogatja a döntésben.

• Logisztika és kiskereskedelem: keresletelőrejelzés, készletoptimalizálás, útvonaltervezés.

• Távközlés: hálózati forgalom elemzése, hibák és ügyfélelvándorlás előrejelzése.

Példa: egy bank naponta több millió kártyatranzakciót dolgoz fel, és mindegyikről ezredmásodpercek alatt el kell döntenie, gyanús-e. Mivel a bank minden tranzakcióját naplózza, és utólag azt is tudja, melyik bizonyult csalásnak (például ügyfélpanasz vagy visszaterhelés alapján), az adatokból statisztikai mintázatok nyerhetők ki. Ilyen például a tranzakciós sebesség: az ellopott kártyákat gyakran rövid idő alatt sok vásárlásra használják, sokszor apró összegű „teszt tranzakciókkal" kezdve, ami élesen eltér egy átlagos ügyfél szokásaitól. A modell nem egyetlen szabályt alkalmaz, hanem sok jelet mérlegel egyszerre: a napszakot, az elmúlt óra tranzakcióinak számát, az elmúlt 24 óra költését, és azt, hogy a kártya fizikailag jelen volt-e a vásárláskor. Erre egy célzottan betanított modell alkalmas: gyors, olcsó, mérhető a pontossága. Egy nagy nyelvi modell ugyanezt lassabban és tranzakciónként sokszorosáért tenné, ráadásul a döntése nem lenne reprodukálható. (forrás)

Fontos, hogy ez csak elegendő és jó minőségű adattal működik. A nagy mennyiség önmagában nem elég: ha az adat hiányos, torz vagy nincs megfelelően címkézve, a modell is rossz lesz.

Mi a különbség az ágens alapú rendszerek és az ML/DS rendszerek között?

Konklúzió

Nem haszontalan az agentic rendszer sem: ott, ahol nincs elég adat vagy a feladat túl változatos, nagyon jó kiindulópont egy ágens workflow kialakítása. A trükk az, hogy tudjuk, mikor érdemes az LLM-et kiváltani egy célzott modellel. A legjobb rendszerek keverik a kettőt: az LLM csak a nehéz, nyelvi döntéseket hozza, a tömeges és egyszerű lépéseket ML-modell vagy sima kód végzi. Ezt tapasztaljuk a saját munkánkban is: nem érdemes minden feladatot egyetlen „legjobb” modellre bízni, az évente tíz- vagy százezres dokumentumszámnál pedig egy kisebb, célzott modell a jobb választás (Mit jelent egy AI-benchmark?). Az Anthropic tanácsa egyszerű: keresd a lehető legegyszerűbb megoldást, és csak akkor bonyolítsd, ha kell. Ez akár azt is jelentheti, hogy egyáltalán nem építesz agentic rendszert. Ha a döntési fát le tudod rajzolni, építsd meg kódban, és optimalizáld az egyes csomópontokat (Anthropic összefoglaló).

A mynds.ai megoldása: DocAudit

A magyar piacon a legnagyobb fókusz a dokumentumfeldolgozó ágensrendszereken van. Számtalan esetben az adataid különböző helyeken vannak, ezért nem kereshetők, nehezen hozzáférhetők, és valakinek végig kell olvasnia őket. Erre a megoldásunk a DocAudit.

Mi az a DocAudit?

A DocAudit a mynds.ai saját terméke: személyre szabható dokumentumfeldolgozás szakértői ellenőrzéssel. A lényege egy mondatban: a rendszer átvizsgál, a szakértő dönt. Nem az emberi munkát váltja ki, hanem megmutatja, hol van rá szükség.

1. Rendszerezés. A PDF, Word és szkennelt iratokat kategorizálja, és összekapcsolja az összetartozó adatokat.

2. Adatkinyerés. A feladathoz igazított szempontok szerint kinyeri a releváns adatokat.

3. Ellenőrzés. Az eredményt szabály- vagy checklist rendszer alapján vizsgálja.

4. Jelzés. Az anomáliákat, hiányokat és kockázatokat jelzi. Ami bizonytalan, az emberi ellenőrzésre kerül, az egyértelmű eredmények pedig gyorsan lezárhatók.

A visszajelzések alapján 80%-kal csökkent az ellenőrzésre fordított munkaidő, és 1000 dokumentum feldolgozható 10 óra alatt.

Kód, ML-modell, LLM és agent egy rendszerben

A DocAudit minden lépését egy skill hajtja végre, és a skill végrehajtási stratégiája elemenként választható. Az agent itt csak egy a lehetséges stratégiák közül, nem a rendszer alapja. A DocAudit tartalmazhat ML-réteget is, vagyis a skillek mögött saját, betanított modell is futhat.

Ez az a keverés, amiről a gépi tanulásról szóló részben írtunk: az LLM a nehéz, nyelvi döntéseket hozza, a tömeges és egyszerű lépéseket kód vagy ML-modell végzi. A modell skill-szinten választható, a helyi és a felhős modellek vegyíthetők, így az érzékeny adatot feldolgozó lépések futhatnak helyben, az on-premise megoldásokon is.

Miben más, mint egy átlagos agentic rendszer?

Az átlagos agentic rendszer egy LLM, amely eszközökkel és egy ciklussal dolgozik. Dokumentumok ellenőrzésére is meg lehet így építeni, de a fent leírt rétegeket (séma, jogosultság, emberi jóváhagyás, audit trail) ilyenkor neked kell hozzáépítened. A DocAudit ezeket a platform részeként adja, így a szabályok a rendszerben élnek, nem a promptban.

Mikor nem a DocAudit a jó választás?

Mi sem mindenre ajánljuk:

• Egyszeri, nyitott kérdés néhány dokumentummal (például egy szerződés összefoglalása): erre elég egy sima AI-asszisztens vagy egy agent. (kisebb AI-automatizálás)

• Nem dokumentumalapú és szemantikai értelmezési feladat (értesítés, adatátadás rendszerek között, riport): erre egy workflow-eszköz a jó választás, például az n8n, amelyre mi is építünk megoldásokat (n8n-automatizáció).

Hogyan kezdjünk hozzá?

Egy első konzultációval: megnézzük a problémát, és megmondjuk, mi a jó első lépés, akkor is, ha az nem a DocAudit. Ismertetőt kérek a DocAuditról vagy konzultációt kérek.