Mi az AI agent: öt klasszikus típus, két rivális definíció

A terület legrégebbi példája egy porszívó egy két négyzetből, A-ból és B-ből álló világban, ahol mindkettő vagy tiszta, vagy piszkos.¹ Minden tankönyvben túléli, mert ez a legkisebb világ, amelyben egy agentnek igaza lehet vagy tévedhet.

A percept egy pár — hol vagyok, és piszkos-e itt —, a műveletek pedig SUCK, LEFT és RIGHT. Az egész program egy sor.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

Futtasd le a két négyzetből álló világ összes kezdőkonfigurációján:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

Ez egy egyszerű reflex agent: kizárólag az aktuális percept alapján cselekszik, bármi előzmény emléke nélkül. Ez nem játékkategória — egy termosztát is ilyen, és ugyanilyen egy nyelvi modell egyetlen hívása is, ha nincs hozzá kapcsolt beszélgetés.

Most törd el úgy, ahogy a valóság teszi. Egy valódi porszívórobotnak koszérzékelője és ütközője van, nem pedig a szőnyeg alá címkézett A négyzete. Vedd ki a helyet a perceptből, és semmi máson ne változtass:

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

Ugyanaz a program, két négyzet. Az egyik kezdőállapotból három lépés alatt végez; egy másikból ötszázszor nekihajt a jobb oldali falnak, és menne tovább, amíg le nem merül az akkumulátor. Nem képes érzékelni a különbséget a két helyzet között, ezért nem is tud bennük másképp cselekedni. Russell és Norvig egy sorban mondják ki az általános eredményt: részlegesen megfigyelhető környezetekben az infinite loopok gyakran elkerülhetetlenek az egyszerű reflex agentek számára.¹

Van egy javítás, amely egy sorba és nulla memóriába kerül; érdemes megmérni, mielőtt bármi okosabbhoz nyúlnánk.

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

Kétezer futtatás egy teljesen piszkos folyosón, három méretben, végig ugyanazzal a seedelt generátorral:

A randomizálás teljesen eltünteti a loopot. De ára is van: nyolc szobához tizenöt mozdulat kell, ha tudod, mit csinálsz, ez az agent pedig átlagosan 68,7-et tesz meg, és egyszer 306-ig jutott. Ez az egész fejezet kicsiben. Minden hozzáadott képesség helyességet vásárol egy olyan esetben, amelyet az előző agent nem tudott kezelni, és olyan pénznemben számláz érte, amelyet először meg kell nevezned.

Egy agent szenzorokon keresztül érzékeli a környezetét, és aktuátorokon keresztül cselekszik. Az agent program a perceptekről műveletekre képező függvény — a fenti összes listing ilyen. A percept sequence mindaz, amit eddig érzékelt, és egy egyszerű reflex agent ebből mindent figyelmen kívül hagy az utolsó elem kivételével.

A racionalitás az a szó, amelyet a legtöbb cikk rosszul használ, és ha helyesen használod, a fejezet többi része is használhatóvá válik. Egy agent önmagában nem racionális vagy irracionális. Russell és Norvig szerint a racionális agent minden lehetséges percept sequence esetén azt a műveletet választja, amely várhatóan maximalizálja a teljesítménymérőjét, az adott sequence bizonyítékai és bármilyen beépített tudása alapján.¹ A teljesítménymérő nincs az agentben: a tervezőhöz tartozik, a racionalitás pedig csak ehhez képest értelmezhető.

A specifikációt hagyományosan négy dologként írják fel: PEAS — performance measure, environment, actuators, sensors.

Figyeld meg, melyik sor lóg ki. Szinte minden csapat, amely 2026-ban agenteket épít, leírja az E-t, az A-t és az S-t — az eszközsémákat, az integrációkat, az üzenetformátumot —, mert a kód ezek nélkül nem fut. Szinte senki nem írja le a P-t. Enélkül annak, hogy „az agentünk jól teljesít”, nincs ellenőrizhető jelentése, a „racionális” pedig egyáltalán nem alkalmazható a rendszerre, csak egy demóra. A 29. fejezet arról szól, hogyan lesz a P-ből szám, és ezért létezik.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

A feladatkörnyezeteket további hét tengely mentén osztályozzák, amelyek közül itt öt határozza meg a nehézség nagy részét: teljesen vagy részlegesen megfigyelhető, determinisztikus vagy nem, epizodikus vagy szekvenciális, statikus vagy dinamikus, ismert vagy ismeretlen.¹ Egy agent, amely valódi eszközökkel beszél valódi hálózaton, mind az öt kemény sarkában van — még temperature nullán is nem determinisztikus (17. fejezet), és, ez az alulértékelt rész, ismeretlen, mert nincs megbízható modelled arról, hogy a saját eszközeid mit tesznek a világgal. Ezért kell a 23. fejezet loopjának jobban a hibakezelés, mint a tervezés.

A valódi padlók nem egydimenziósak, ezért emeljük a világot alaprajzzá. A kettőskeresztek falak, a csillagok koszfoltok, a robot pedig a középső kamrából indul:

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

A kézenfekvő fejlesztés a memória. Az agent térképet tart fenn: minden négyzetről, amelyen már állt, és minden négyzetről, ahol megszólalt az ütköző. A szabálya az, hogy belép egy szomszédos, még meg nem látogatott négyzetre — jobbra, aztán le, aztán balra, aztán fel —, és visszalép, amikor körülötte már minden ismert. Ez egy modellalapú reflex agent: belső állapotot tart fenn a percept historyból, ezért tud olyan alapján cselekedni, amit éppen nem lát.

Ez valódi javulás, és még mindig nem elég:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

Ötezer mozdulat, a padló fele sosem látszik. A térkép helyes, a szabályok helyesek. Amit az agent nem tud megtenni: a térképet arra használni, hogy eljusson valahová. A szabályai mindig csak erre válaszolnak: „a négy szomszédom közül melyikbe lépjek”, ezért amint elfogynak mellette a meg nem látogatott négyzetek, nincs módja kifejezni a gondolatot, hogy nyolc lépésre van egy meg nem látogatott négyzet, és szeretnék ott állni. Tudja, hol van. Nem tudja, hol szeretne lenni.

A célalapú agent a világról alkotott modellje mellett tartalmazza annak a helyzetnek a leírását is, amelyet létre akar hozni, és műveleteket úgy választ, hogy műveletsorozatok között keres, amíg nem talál olyat, amely ott ér véget. A célok a műveletválasztást lookupból kereséssé alakítják.

A cél: „ne maradjon piszkos négyzet”. A keresés breadth-first séta a legközelebbi piszkos négyzethez, és a visszaadott út a terv.

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

Huszonhét mozdulat, tiszta padló. De nézd az akkumulátor oszlopot és a terv utolsó szakaszát. A 0. oszlop szőnyeges: egy szőnyeges négyzeten áthaladni hat akkumulátoregységbe kerül, egy csempés négyzeten egybe. Az agent a 0. oszlopon ment haza, mert az négy mozdulat nyolc helyett, és ez a négy szőnyeges mozdulat 24-be került, miközben a nyolcmozdulatos kerülő 13-ba került volna.

Nem tud mást tenni. A cél bináris teszt: a padló tiszta, vagy nem. Minden terv, amely tiszta padlóval ér véget, ugyanúgy kielégíti, ezért amikor több is sikeres, az agentnek nincs mi alapján választania közöttük. Ahhoz, hogy az egyik sikert előnyben részesítse a másikkal szemben, szám kell a kimenetek fölött, ez a szám pedig egy hasznossági függvény. Az agent, amely ezt maximalizálja, utility-based agent.

A kód változása egyetlen tag a keresésben. A breadth-first search a mozdulatokat számolja; számolja helyette a költséget, és máris Dijkstra-algoritmusod és egy másik agented van:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

Négy extra mozdulat, tizeneggyel kevesebb akkumulátoregység: huszonegy százalékkal olcsóbb. Ugyanaz a cél, ugyanaz a térkép, ugyanaz a kód egyetlen tag kivételével. A két agent csak abban különbözik, miben próbál jó lenni, és más útvonalon mennek haza.

Ez az első pont is, ahol az agentnek olyasmire van szüksége, amit nem tud előállítani. Valakinek el kell döntenie, mennyit ér egy akkumulátoregység egy mozdulathoz képest. A hasznosság a teljesítménymérő olyan formában, amellyel az agent számolni tud, és ennek megírása a tervező dolga. Amikor az emberek azt mondják, hogy egy agent „rossz dolgot optimalizált”, szinte sosem bugra gondolnak. Arra gondolnak, hogy ezt a sort gondatlanul írták meg.

Most térjen vissza a kosz. Négy szoba négy különböző ütemben piszkolódik újra, az agent pedig sosem kapja meg ezeket az ütemeket. Tickenként egy szobát látogat meg, és csak azt a szobát látja. A teljesítménymérő a piszkosan töltött szoba-tickek száma 4.000 tick alatt — az alacsonyabb jobb.

A tanuló agent a tankönyvi felbontásban a fentiek bármelyike plusz három rész: egy tanulóelem, amely megváltoztatja az agentet, egy kritikus, amely megmondja, hogyan teljesít az agent egy rögzített teljesítményszabványhoz képest, és egy problémagenerátor, amely olyan műveleteket javasol, amelyeket érdemes kipróbálni azért, amit taníthatnak.¹ Három policy ugyanabban a környezetben. Az első nem tanul; a második és a harmadik ugyanazt tanulja meg, és másképp használja.

A rejtett ütemek: 0,35 a konyhára, 0,05 az előszobára, 0,02 a dolgozószobára és 0,01 a padlásra — és az A tanuló megtalálta őket. Helyesen azonosította a konyhát a ház legpiszkosabb szobájaként, majd a szimuláció hátralévő részében minden tickben a konyhába ment, miközben a másik három örökre piszkos maradt. Ötször rosszabb, mint egyáltalán nem tanulni, és nincs elromolva.

A tanulság a hasznossági szakaszé. Az A tanuló azt maximalizálta, hogy „valószínűleg piszkos-e a szoba, amelyet most meglátogatok”. A teljesítménymérő ez volt: „piszkosan töltött szoba-tickek”. Különböző számok; a másodikat pontozta a kritikus, és senki sem mondta meg az agentnek. A B tanuló ugyanazt a megtanult ütemet megszorozza az utolsó látogatás óta eltelt idővel — vagyis a várhatóan megtalált koszt, nem pedig annak esélyét, hogy talál-e bármennyit —, és legyőzi a járőrt, amelyből indult.

Egy implementációs részlet döntötte el az eredményt. A B tanuló első verziójában egy szoba, ahol három látogatás alatt nem jelent meg kosz, pontosan nulla ütemet kapott — és nulla szorozva bármivel nulla, így soha többé nem látogatták meg, a becslést pedig sosem lehetett korrigálni. A tört simítása, sikerek plusz egy osztva próbák plusz kettővel, 11.895-ből 1.576-ot csinált. A „még nem figyeltük meg” és a „megmértük, és nulla lett” különböző állítások, és egy rendszer, amely ugyanabban a mezőben tárolja őket, olyan döntéseket hoz, amelyeket nem tud visszavonni.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

Mind az öt productionben van ma, más néven.

Két sor több mint analógia — pénzbe kerülő módon.

A chat olyan modellalapú reflex agent, amelynek a modellje nem belső. A tankönyvben az állapot egy változó az agent programon belül. Egy chatben ez a transcript: a te oldaladon él, minden hívásnál teljes egészében újraküldöd, és a modellen belül minden alkalommal nulláról épül újra. Ez a 16. fejezet négyzetes számlája, és ugyanaz az objektum, amelyet a tankönyv „állapot” feliratú dobozként rajzolt meg. Itt a különbség, egyetlen follow-up kérdésen mérve, az előtte lévő két üzenettel és azok nélkül:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

Ugyanaz a modell, ugyanaz a három szónyi felhasználói input, és a második a folyosórobot, amely a falnak hajt. Ebben a futásban nem voltak eszközök, tehát a 15 kitalált — de az állapot az, amitől a follow-up egyáltalán jelent valamit. Minden alkalommal újraépíted, és egy kétkörös beszélgetésben 2,3× input tokennel fizetsz érte. A 16. fejezet megmérte, hová jut ez a szorzó a negyvenedik körre.

A Reflexion olyan tanuló agent, amely nem a programját, hanem az inputját változtatja meg. A tankönyvi felbontásban a tanulóelem módosítja a teljesítményelemet. A Reflexion békén hagyja a súlyokat, és reflektív szöveget ír egy epizodikus bufferbe, amelyet a következő próbálkozás olvas.³ A tanulóelem egy prompt, a memória egy adatbázissor, a teljesítményelem egy fagyasztott modell — a diagram pedig változatlanul a tankönyvé.

És itt a megfeleltetés őszinte határa. Az öt típus az agent programot osztályozza. 2026-ban ez a program ketté van hasítva: egy része a te kódod, egy része olyan súlyokban van, amelyeket nem te tanítottál. Amikor egy modell magától dönt úgy, hogy eszközt hív, a célteszt a te programodban van, vagy a modellben? A taxonómiának nincs válasza, mert amikor írták, nem is lehetett volna máshol — és pontosan ennél a kérdésnél válik szét a két modern definíció.

A definíciók viselkedésről szóló érvek, és sokkal könnyebb megítélni őket, ha van előtted egy trace.

Az alábbi loop elküldi a beszélgetést egy modellnek; ha a válasz eszközhívást tartalmaz, végrehajtja az eszközt, hozzáfűzi az eredményt, és újra elküldi az egészet. Egy helyi Qwen2.5-0.5B-Instruct ellen fut, OpenAI-alakú endpoint mögött ezen a gépen — ez a 14. fejezet varrata, így a loopnak sem tudnia, sem érdekelnie nem kell, mi van a port mögött.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

Két sor hordozza az egész gondolatot, és mindkettő meg van jelölve; a többi könyvelés. Mindhárom viselkedés látszik egy futásban. Ha olyat kérdeznek tőle, amit maga is meg tud csinálni, a modell válaszol. Ha olyat kérdeznek tőle, amit nem tud, hív:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

És megáll — a harmadik viselkedés, és a legkönnyebb észre sem venni, mert úgy néz ki, mintha semmi sem történne. A loop azért ér véget, mert a 2. kör eszközhívás nélkül jött vissza. Ezt senki nem döntötte el; a modell tette, prózát kibocsátva. Ennek a programnak a terminációs feltétele egy hiány jele.

Még két futás megéri a helyet. Két város összehasonlítására kérve a modell mindkét eszközhívást kiadja egy körben, mindkét leolvasást visszakapja, és elrontja az összehasonlítást:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

Az eszközök működtek. A párhuzamos hívás működött. A loop működött. A válasz hamis, miközben mindkét helyes szám ott ül a transcriptben. Attól, hogy egy modellt loopba csomagolsz, még nem fog gondolkodni; csak megadod egy tévedő modellnek a képességet, hogy a tévedése alapján cselekedjen — ez előre a 30. fejezet, és a 29. fejezet fele.

Most töröld a megjelölt return részt, és hagyd, hogy a loop a plafonjáig fusson. Ugyanaz a kérdés, ugyanaz a modell:

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

Négyszer annyi input token, négyszer annyi wall clock idő, és egy befejezés, amelyben az agent elfelejtette, mit kérdeztek tőle, és a felhasználót faggatja egy olyan kérdésről, amelyre az első körben már válaszolt. A helyes válasz a 2. körben a képernyőn volt, és minden további kör rontotta a transcriptet.

Tehát az agent nem loop. Loop plusz egy szabály arra, hogyan lehet kilépni belőle, és ennek pontosan egy ilyen szabálya van. A 23. fejezet ötöt talál, és megmutatja, mi törik el, ha bármelyik hiányzik.

Idézve, nem átfogalmazva, mert a zavar az átfogalmazásokban készül.

Az első definíció ott húzza meg a határt, hogy ki irányítja a folyamatot. Az Anthropic Building effective agents című írása megnevezi a kétértelműséget, és állást foglal:

„Az Anthropicnál ezeket a változatokat mind agentic systemsként kategorizáljuk, de fontos architekturális különbséget teszünk workflowk és agentek között: a workflowk olyan rendszerek, amelyekben az LLM-eket és eszközöket előre definiált kódutak mentén orkestrálják. Az agentek ezzel szemben olyan rendszerek, amelyekben az LLM-ek dinamikusan irányítják saját folyamataikat és eszközhasználatukat, megtartva az irányítást afelett, hogyan hajtják végre a feladatokat.”⁴

A teszt a forráskódodra vonatkozó kérdés: ki választotta a következő lépést? Egy switch a programodban: workflow. A modell: agent. Ugyanez a dokumentum azt mondja, hogy az agentek „jellemzően csak LLM-ek, amelyek környezeti visszajelzés alapján eszközöket használnak egy loopban” — ami pontosan a fenti listing.

A második definíció ott húzza meg a határt, hogy mennyire független a felhasználótól. Az OpenAI A practical guide to building agents című anyaga így nyitja a definíciós oldalt:

„Míg a hagyományos szoftverek lehetővé teszik a felhasználóknak, hogy workflowkat egyszerűsítsenek és automatizáljanak, az agentek képesek ugyanezeket a workflowkat a felhasználók nevében, nagy fokú függetlenséggel végrehajtani. Az agentek olyan rendszerek, amelyek önállóan hajtanak végre feladatokat a nevedben.”⁵

Két mondattal később, ugyanazon az oldalon, kizárja ezt:

„Azok az alkalmazások, amelyek LLM-eket integrálnak, de nem használják őket a workflow-végrehajtás irányítására — gondolj egyszerű chatbotokra, single-turn LLM-ekre vagy sentiment classifierökre —, nem agentek.”⁵

Olvasd ezeket az idézeteket sorrendben. A nyitó mondatok a függetlenségnél húzzák meg a vonalat: elmegy-e ez a dolog, és befejezi-e helyettem a munkát? A negyedik a végrehajtás irányításánál húzza meg, ami pontosan az Anthropic vonala. Más tesztek, ugyanazon az oldalon, és vannak valódi rendszerek, amelyeknél nem ugyanazt mondják.

Alatta szókincsbeli ütközés van, és valódi meetingeken okoz vitákat. Az első dokumentumban a workflow egy architektúra, és ez az, ami nem agent. A másodikban a workflow „lépések sorozata, amelyet végre kell hajtani a felhasználó céljának eléréséhez” — maga a munka, amellyel minden agent rendelkezik. A „lecseréltük a workflowt agentre” az első definíció szerint koherens, a második szerint majdnem értelmetlen.

Három 2026-ban létező rendszer, mindkét definíció alatt.

A háromból kettő oldalt vált. Ez nem egyik dokumentum kudarca sem. Figyelmeztetés egy olyan meetingtípusra, ahol két ember, aki teljesen egyetért abban, mit csinál egy rendszer, egy órát tölt azzal, hogy vitatkozzon, minek nevezzék.

A definíciók azért ütköznek, mert mindkettő két független kérdést sűrít egyetlen szóba. Válaszd szét őket, és a nézeteltérésből táblázat lesz, ami hasznosabb, mint egy ítélet.

Mindegyik definíció másik cellát vitat, a másik kettő pedig egyáltalán nem vitás. Ezért amikor a címke számít — szerződésben, kockázati review-ban, postmortemben —, nem azt a két mondatot érdemes leírni, hogy „agent-e”, hanem ezt: ki választotta a következő lépést, és ki figyelte. Mindkettő megválaszolható a kód olvasásával, egyikhez sem kell senki definíciója, és együtt hordozzák mindazt a következményt, amelyet a címke helyettesített.

Ebből semmi sem új. Wooldridge és Jennings 1995-ben áttekintették az „agent” versengő jelentéseit;⁶ Franklin és Graesser 1996-ban feltették ennek a fejezetnek a kérdését, összegyűjtötték az akkor forgalomban lévő definíciókat, és azt találták, hogy nem értenek egyet.⁷ Egy 2023-as survey még mindig első elvekből definiálja az agenteket — „mesterséges entitások, amelyek érzékelik környezetüket, döntéseket hoznak és cselekszenek”⁸ —, mert nem volt kész, elfogadott modern definíció, amelyet idézhetett volna, a CoALA pedig részeket ír le, nem határt húz.⁹ Harminc évnyi meg nem egyezés azt mondja, hogy a szó egynél több munkát végez.

Most a következmény, amely a filozófia előtt érkezik: a számla.

Itt minden mérés ugyanazt az alakot veszi fel. Az egyszeri hívás 39 input tokenbe került; ugyanaz a kérdés egy eszközzel 420-ba, két híváson át; a loop a megállási szabály eltávolításával 1.688-ba, hat híváson át. A növekedés rosszabb, mint lineáris, mert az n. kör minden előző kört magával visz: ennek a hatkörös futásnak a prompt oszlopa 187, 238, 261, 302, 327, 373. A 16. fejezet levezette, hogy az összeg $\Theta(n^2)$, és illesztette a görbét egy valódi beszélgetésre. Egy agent minden feladatot ilyen beszélgetéssé alakít, akár látja ember, akár nem.

Ha ezeket a mért token-számokat egy kereskedelmi endpoint kapta volna a 16. fejezet által 2026. szeptember 6-án olvasott díjakkal — $2,00 millió input tokenenként és $12,00 millió output tokenenként —, a négy futás ára így alakulna:

A második sor az elsőhöz képest az a szám, amelyet érdemes megtartani. Hétszer és félszeres költség, rosszabb válaszért egy olyan kérdésre, amelyet a modell már eleve tudott. Semmi sem volt rosszul konfigurálva: létezett egy eszköz, ezért a modell használta — és a 18. fejezet megállapítása, hogy a katalógus ára fáj, nem a pontossága, itt kapja a legolcsóbb demonstrációját egy darabos katalógussal.

Ezért mindkét dokumentum hasznos fele az, amely arról szól, hogy ezt ne építsd meg. Az Anthropic nyers: találd meg a lehető legegyszerűbb megoldást, és csak akkor adj hozzá komplexitást, amikor szükség van rá, ami „akár azt is jelentheti, hogy egyáltalán nem építünk agentic systemeket”, mivel az agentic systemek „latenciát és költséget cserélnek jobb feladatteljesítményre”, és „sok alkalmazásnál az egyszeri LLM-hívások optimalizálása retrievallel és in-context példákkal általában elég”.⁴ Az agent melletti esete szűk: nyitott végű problémák, ahol nem tudod előre megjósolni a lépések számát, és nem tudsz hardcode-olt utat adni, olyan környezetben, amelyben megbízol, elfogadva a „magasabb költségeket és az egymásra rakódó hibák lehetőségét”.⁴ Az OpenAI szűrője ennek tükörképe — komplex ítélőképesség, karbantarthatatlan szabálykészletek, strukturálatlan adatok —, és ugyanoda fut ki: „különben egy determinisztikus megoldás is elegendő lehet”.⁵

Tehát ennek a fejezetnek a taxonómiájában: fix számú lépés fix sorrendben pipeline, és attól, hogy agentnek nevezed, nem lesz gyorsabb. Ha a lépések száma attól függ, mit találsz útközben, loopot akarsz — és ezt a rugalmasságot N hívással, négyzetes transcripttel és egy olyan rendszerrel vásárolod meg, amely egyszer helyett N-szer tévedhet.

Most már megvan a taxonómia, mindkét modern definíció, a két tengely, amely kompatibilissé teszi őket, és egy rövid loop, amely válaszol, hív és megáll.

Ennek a loopnak egy módja van a befejezésre: a modell abbahagyja az eszközök kérését. A 23. fejezet szándékosan töri el, hétszer, és minden törés hozzáad egy darabot. Lehetetlen feladat, és sosem ér véget — turn cap. Egy éjszaka futás, és megérkezik a számla — dollárkeret. Egy eszköz hibázik — hiba, amelyre a modell reagálhat. Ugyanaz a hívás kétszer — idempotency key. Egy fájl, amelyhez nem kellett volna nyúlnia — emberi jóváhagyás. Újraindítás félúton — session persistence. Egy eszköz három percig tart csendben — progress és cancellation. Ami kijön belőle, az egy harness, a fájl, amelyen a kurzus többi része fut.

Marad a kérdés, amelyről ennek a fejezetnek a vitatott átlója valójában szólt. Egy loopnak, amely maga dönti el a következő lépését, el kell döntenie, mikor álljon meg, és épp most néztük meg, mi történik, ha nem tudja: hat kör, négyszeres számla, és egy agent, amely a felhasználót faggatja egy olyan kérdésről, amelyet már megválaszolt. A megállás nem egyetlen feltétel. Hány van, és melyik tüzel először?

Lilian Weng LLM Powered Autonomous Agents (2023) című írása a language agent tervezésre, memóriára és eszközhasználatra bontásának legismertebb felosztása, és a két vendor-dokumentum melletti megfelelő következő olvasmány; három komponense ennek a kurzusnak a 23., 24. és 18. fejezete, ebben a sorrendben.

Ebben a fejezetben minden szám ezen a gépen készült, és semmi nem becslés. A folyosó, az alaprajz, az azon járó négy agent és a három járőr-policy a fenti TypeScript, Node 22-n futtatva; a randomizált agent számai egyenként 2.000 seedelt futás átlagai, a járőrszámok pedig 4.000 tickes egyszeri seedelt futások. A modell trace-ek a Qwen2.5-0.5B-Instruct modellből származnak, float32-ben CPU-n, greedy decodinggal, loopbacken kis helyi Python endpointtal kiszolgálva, amely betölti a súlyokat és OpenAI chat-completions alakban beszél — megint ugyanaz a varrat, a tenzorok a Python oldalon, a loop pedig a TypeScript oldalon —, így a token-számok annak a modellnek a tokenizeréből, a latenciák pedig annak a gépnek a méréséből jönnek. Az egyetlen máshonnan vett szám a költségtáblázat két ára, amelyek azok a díjak, amelyeket a 16. fejezet az OpenAI árazási oldaláról olvasott 2026. szeptember 6-án; itt a helyben mért token-számokra alkalmazzuk őket illusztrációként, nem megfigyelt számlaként.