Három definíció, három határvonal
Az „agent" szót ma háromféle határvonallal használják, és érdemes tudni, melyiket hallod.
| Hol húzza meg a határt | Agent-e a chatbot? | |
|---|---|---|
| Az egyik nagy modellfejlesztő | ki irányítja a végrehajtás útját — előre megírt kód vagy a modell | nem, ha kódút vezérli |
| A másik | önállóan elvégzi-e a feladatot helyetted | kifejezetten nem |
| A benchmarkot építő egyetemi csapat | van-e ciklus egyáltalán | nem, mert nincs ciklus |
A második megfogalmazás a leghasznosabb, mert negatívan határol: az olyan alkalmazás, ami használ nyelvi modellt, de nem bízza rá a munkafolyamat vezérlését — egyszerű chatbot, egykörös lekérdezés, hangulatelemző —, nem agent.
Az elsőnél viszont a workflow és az agent nem ellentét, hanem ugyanannak a skálának a két vége. Ez nem szőrszálhasogatás: ha valaki „agentet" ad el neked, érdemes megkérdezni, melyik definíció szerint az.
Ami mind a háromban közös: ciklus, eszközök, és környezeti visszajelzés.
A ciklus: száz sor, ami mindent elmond
Van egy nyilvános, éles agent, amit kutatócsoportok és nagy technológiai cégek is használnak, és a hivatalos leírása szerint 74% fölött teljesít egy ismert szoftverfejlesztési benchmarkon. Az egész vezérlése kb. száz sor.
Kivonatolva, a valódi forrásból:
run():
üzenetek = [rendszerprompt, feladat] # két üzenettel indul
ciklus:
lépés()
ha az utolsó üzenet "kilépés" -> vége
lépés():
végrehajt(kérdez())
kérdez():
ha elérted a lépéskorlátot -> leállás
ha elérted a költségkeretet -> leállás
ha elérted az időkorlátot -> leállás
válasz = modell(üzenetek) # MODELLHÍVÁS
költség += válasz.költsége
üzenetekhez_fűz(válasz)
végrehajt(válasz):
kimenet = környezet.futtat(válasz.műveletei) # VÉGREHAJTÁS
üzenetekhez_fűz(megfigyelés(kimenet)) # a MEGFIGYELÉS visszakerül
Négy dolog látszik ebből, és mind a négy fontos.
Az első: a történet lineáris. Minden lépés hozzáfűzi az eredményt az előzőhöz. Semmi nem tűnik el, semmi nem tömörödik magától — a kontextus monoton nő.
A második: három leállási feltétel van, mind a háromnak korlát a neve. Lépésszám, költség, idő. Ennek a rendszernek az alapértelmezett költségkerete feladatonként három dollár — ez a legkonkrétabb publikált szám arra, mennyit szán egy komoly csapat egyetlen agent-futásra.
A harmadik: van egy negyedik kilépés is — három egymás utáni formátumhiba után a rendszer feladja. Nem próbálkozik a végtelenségig.
A negyedik, amit a rendszerprompt tesz hozzá: a modellnek minden válaszban pontosan egy parancsot kell kiadnia, és elé egy gondolatot kell írnia, amiben elmagyarázza, miért. Ez a „gondolat–cselekvés" pár nem a modell természetes viselkedése. Ki kell kényszeríteni.
Egy lépés, közelről
Érdemes megnézni, mi történik a hálózaton egyetlen eszközhívás alatt. A megfigyelési szabvány normatív példája pontosan ezt írja le:
agent-futás indul
|
+-- modellhívás <- "mit csináljak?"
|
+-- eszközhívás (kliens) <- a kérés elindul
| |
| +-- eszköz (szerver) <- a művelet tényleg lefut
|
+-- modellhívás <- "ezt kaptam, most mit csináljak?"
Egy eszközhívás két modellhívást jelent. Egyet előtte, egyet utána. Ez a legfontosabb dolog, amit az agentek költségéről tudni kell — és amiért egy tízlépéses feladat nem tízszer, hanem húszszor hívja a modellt.
A szabvány a hívás mellé rögzíti azt is, mi az eszköz neve, milyen argumentumokkal hívták, mi jött vissza, és melyik protokollverzióval. Ha ezt naplózod, egy hónap múlva is rekonstruálható a futás — ha nem, akkor nem.
Mennyi ez számokban?
Konkrét, közölt számok. Ahol gyártói közlésről van szó, azt kiírom, mert mintanagyságot és mérési protokollt egyikhez sem adtak meg.
- Az egyik modellfejlesztő saját mérése szerint az agentek nagyjából négyszer annyi tokent fogyasztanak, mint egy beszélgetés, a többagentes rendszerek pedig tizenötször annyit.
- Ugyanők saját skálázási ajánlása: egyszerű kérdésre egy agent, 3–10 eszközhívás; összehasonlításra 2–4 subagent, egyenként 10–15 hívás; összetett kutatásra tíznél több subagent.
- Egy subagent tipikusan tízezres nagyságrendű tokent használ el, és ebből 1 000–2 000 tokenes, sűrített összefoglalót ad vissza.
- És a fenti háromdolláros költségkeret: mai árakon nagyságrendileg másfél millió bemeneti vagy háromszázezer kimeneti token. Ennyi fér egy futásba.
Honnan jön a neve: a ReAct-minta
A gondolat–cselekvés váltogatás nem 2025-ös találmány. A mintát leíró tanulmány 2022 októberében jelent meg, és 2023-ban konferenciakiadványban is.
A lényege egyszerű: a modell nem szétválasztja a gondolkodást és a cselekvést, hanem váltogatja. A gondolat módosítja a tervet, a cselekvés külső forrásból hoz információt, és ez a kettő javítja egymást.
A mért eredmények akkor: egy háztartási szimulációs feladatkészleten 34 százalékpontos, egy webes vásárlási feladaton 10 százalékpontos abszolút javulás a korábbi módszerekhez képest — az utóbbinál mindössze egy-két példával a promptban.
Ez a minta ma is él: több no-code automatizáló eszközben külön „ReAct agent" csomópont van.
Mit nem tud az agent?
Ez a rész a legfontosabb, és minden állítás mögött mérés van.
Nem konzisztens. Van egy benchmark, ami nem azt méri, hogy egyszer sikerül-e a feladat, hanem hogy nyolcból nyolcszor sikerül-e. Amikor 2024-ben megjelent, az akkori legjobb rendszerek egyszeri próbálkozásra is 50% alatt teljesítettek, nyolcból nyolcszor pedig 25% alatt.
Azóta sokat javult — de nem tudjuk, mennyit. A mai élmezőny ugyanezen a feladatkészleten egyszeri próbálkozásra 85–88%. A nyolcból nyolcszor értéket viszont ma senki nem publikálja. Vagyis a képesség bizonyíthatóan nőtt, a következetességről nincs nyilvános adat — és pont az utóbbi dönti el, rábízhatsz-e valamit felügyelet nélkül.
Ahol új a feladat, ott ma is 50% körül van. Ugyanennek a benchmarkcsaládnak egy nehezebb, tudás-visszakeresésre épülő változatán a legjobb rendszerek 48–55% között teljesítenek.
A feladathossz a döntő tényező. Egy 2025 márciusi mérés szerint a modellek majdnem 100%-ban megoldják azt, ami embernek négy percnél rövidebb, és 10% alatt azt, ami négy óránál hosszabb. Ugyanez a mérés azt is megállapította, hogy a kezelhető feladathossz nagyjából hét hónaponként duplázódik — ez 2025 márciusi trendbecslés, nem mai tény.
És egy mechanikai ok, amiért a hosszú futás romlik. Mivel a ciklus minden lépésben hozzáfűzi az előzőt, a bemenet monoton nő. Egy 18 modellt vizsgáló mérés szerint pedig a teljesítmény egyre megbízhatatlanabb, ahogy a bemenet hosszabbodik — és már egyetlen zavaró elem is rontja az eredményt az alapesethez képest. Ezért nem az a megoldás, hogy „hagyjuk tovább futni".
Egy utolsó, nagyon kézzelfogható korlát ugyanennek az éles agentnek a promptjából: a könyvtárváltás és a környezeti változó nem marad meg, mert minden művelet új alhéjban fut. Az agent csak arra „emlékszik", amit visszaírtak neki szövegként.
Tipikus félreértések
- „Az agent gondolkodik, aztán cselekszik." Váltogatja a kettőt, és a gondolatot ki kell kényszeríteni a promptban — magától nem így válaszol.
- „Ha tovább futtatom, előbb-utóbb megoldja." A hosszabb futás hosszabb bemenetet jelent, a hosszabb bemenet pedig mérhetően megbízhatatlanabb kimenetet.
- „Egy lépés egy modellhívás." Kettő: egy a művelet előtt, egy az eredmény után.
- „Ha egyszer megoldotta, meg tudja oldani." A konzisztencia külön mérőszám, és pont arról nincs mai nyilvános adat.
- „Az agent emlékszik, mit csinált." Csak arra, ami a szövegben ott van. Ami a környezetben történt és nem került vissza szövegként, az nincs.
- „A chatbot is agent, csak okosabb." A ciklus, az eszközhasználat és a környezeti visszajelzés a különbség — nem a modell mérete.
Amit érdemes elvinni
Az agent egy ciklus, három leállási feltétellel és egy monoton növő szöveggel. Ha ezt a mondatot megjegyzed, a többi következik belőle: miért drága, miért romlik hosszú feladaton, és miért kell neki korlát.
A gyakorlati sorrend ebből: adj neki korlátot (lépés, költség, idő), adj neki eszközt ahelyett, hogy a tudásából dolgozzon, és naplózd minden lépését, mert utólag csak abból rekonstruálható, mi történt.
Hogy a lépésszám és a megbízhatóság hogyan függ össze — és miért bukik el egy húszlépéses feladat 98%-os lépéspontosság mellett is —, arról az agent-megbízhatóság matematikája poszt szól számolással; magáról az eszközhívás mechanizmusáról pedig a tool use és a function calling poszt.