Több mint egy jó prompt: az AI agentek 4 memóriatípusa

Ma már szinte mindenre ráírják, hogy agent. Ha egy chatbot tud eszközt hívni — például hozzáfér a naptáradhoz és létre tud hozni egy új eseményt a kérésedre —, több lépésben válaszol, vagy kapott egy hosszabb system promptot, már kész is a címke.

Ettől még nem lesz belőle valódi vállalati szintű AI agent. Egyszerűbb AI agentet könnyű megalkotni kódolás nélkül is, erről ebben a cikkemben írtam.

A különbség nem a felületen látszik, hanem a rendszer működésében. Egy hagyományos chat reaktív: kérdezel, válaszol, aztán a következő beszélgetésben sokszor kezdődik minden elölről. Egy jól megtervezett AI agent ennél többet tud. Nem csak az aktuális promptból dolgozik, hanem külön kezeli az aktuális kontextust, a tartós tudást, a végrehajtási mintákat és a korábbi tapasztalatokat.

Röviden: nem a prompt teszi az AI agentet, hanem a memóriaarchitektúra.

A CoALA, vagyis a Cognitive Architectures for Language Agents keretrendszer azért hasznos, mert ezt nem misztifikálja túl. Nem egyetlen nagy memóriáról beszél, hanem több, eltérő szerepű memóriatípusról. Ez sokkal használhatóbb mérnöki nézőpont, mint az a leegyszerűsítés, hogy “tegyünk mögé egy vector database-t, és kész”.

A legtöbb csapat itt rontja el

Amikor egy csapat AI agentet épít, jellemzően a modellre és a promptokra fókuszál. Finomítják az instrukciókat, hozzáadnak pár toolt, bekötnek valamilyen tudásbázist, és várják, hogy ebből majd megszülessen az önálló digitális munkatárs.

Csakhogy ha mindent ugyanabba a kontextusablakba próbálsz beletömni, abból nem agent lesz, hanem törékeny, demószintű prototípus.

Vállalati szintű felhasználásnál inkább arra érdemes fókuszálni, hogy milyen memóriát adunk az agentnek, mire, és milyen szabályok szerint.

Praktikusan négyféle agentmemóriát érdemes megkülönböztetni, és különböző helyzetekben tudatosan használni.

1. Munkamemória: amiben éppen gondolkodik

A munkamemória az agent aktuális munkaterülete. Ide kerül a futó beszélgetés, az aktív feladat, a friss utasítások, a megnyitott fájlok és minden, amire az adott pillanatban szüksége van.

Ez áll a legközelebb ahhoz, amit a legtöbben kontextusablakként ismernek. Gyors és közvetlenül elérhető, de átmeneti. Ha a session véget ér, ez a memória eltűnik, vagy legalábbis nem ugyanúgy áll rendelkezésre.

Sokan itt keverik össze a nagyobb kontextusablakot a jobb memóriával. Pedig a nagyobb ablak csak nagyobb munkapad. Nem helyettesíti a rendszerezett, tartós tudást. Sőt, ha túl sok mindent pakolsz bele, az agent egy idő után nem okosabb lesz, hanem szétesettebb. Nehezebben priorizál, rosszabbul idéz fel, és könnyebben elveszti a fókuszt.

Munkamemóriája minden chatbotnak van. Ettől még egyik sem lesz automatikusan agent.

2. Szemantikus memória: amit a világról és a projektről tud

A szemantikus memória a tartós tudás rétege. Ide tartoznak a szabályok, tények, definíciók, konvenciók, projektismeretek és dokumentációk. Ez az a memória, amiből az agent nem azt tudja meg, hogy mi történt az előbb, hanem azt, hogy mi igaz általában.

Elméletben ezt sokan tudásgráfokkal, vektoros adatbázisokkal vagy kifinomult RAG (retrieval-augmented generation) pipeline-okkal képzelik el. A gyakorlatban viszont a legtöbb jól működő rendszer ennél jóval prózaibb. Sokszor néhány jól karbantartott Markdown fájl többet ér, mint egy látványos, de zajos memóriaréteg.

Máskor viszont pont a strukturáltabb megoldás a jobb. Ha sok változó, kereshető tudást kell kezelni, akkor az adatok vektoros tárolása és előhívása, vagy a tudásgráfok használata teljesen indokolt lehet.

A lényeg nem az éppen divatos technológia ész nélküli alkalmazása, hanem az, hogy az agent megbízhatóan elő tudja-e hívni a releváns tudást a megfelelő pillanatban.

Szemantikus memória nélkül az agent minden alkalommal új embernek tűnik. Lehet, hogy nyelvileg meggyőző, de ugyanazokat a hibákat ismétli újra és újra.

3. Procedurális memória: ahogyan dolgozik

A szemantikus memória azt mondja meg, mit kell tudni. A procedurális memória azt, hogyan kell csinálni.

Ide tartoznak a készségek, munkafolyamat-leírások, ellenőrzőlisták és lépésről lépésre követhető eljárások. Egy jó agent nem csak dokumentációt olvas, hanem végrehajtható munkamintákkal is rendelkezik. Például arról, hogy:

• hogyan kell hibát reprodukálni;
• hogyan kell PR-t review-zni;
• hogyan kell release note-ot írni;
• hogyan kell egy nyers kutatási jegyzetből publikálható anyagot készíteni.

Ez a réteg azért kritikus, mert sok csapat túl sok mindent bíz a modell általános intelligenciájára. Azt feltételezik, hogy ha az LLM elég erős, majd magától kitalálja a helyes workflow-t.

Néha ez összejön, de következetesen szinte soha.

A jobb rendszerek ezért skill-eket adnak az agentnek. Nem mindet egyszerre, mert az csak feleslegesen terhelné a munkamemóriát. Először csak egy könnyű indexet lát a rendelkezésre álló skill-ekről, és csak akkor tölti be a részletes instrukciót, amikor a feladat ezt tényleg indokolja.

4. Epizodikus memória: amiből ténylegesen tanulni tud

Az epizodikus memória a múltbeli esetekről szól. Nem általános szabályokat tárol, hanem konkrét tapasztalatokat: mi történt, milyen döntés született, mi működött, mi bukott el, és mit kellene legközelebb másképp csinálni.

Ez az a réteg, amitől az agent kevésbé tűnik amnéziásnak.

A naiv megoldás az lenne, hogy mindent elmentünk: teljes chateket, teljes logokat, minden közbenső lépést. Ez azonban gyorsan használhatatlanná válik. A nyers múlt nem egyenlő a hasznos emlékezettel.

A jobb megközelítés a desztilláció. Nem a teljes 45 perces hibakeresést őrzöd meg, hanem a visszatérően értékes tanulságot. Például azt, hogy egy adott projektben a hitelesítési hibák rendszeresen a middleware rétegben jelentkeztek. Vagy azt, hogy egy stakeholder következetesen mást ért “kész” alatt, mint a delivery csapat. Definition of done — ismerős?

És itt jön a nehéz rész: nem csak az számít, mit tárol az agent, hanem az is, mikor hívja elő, és mikor felejti el. Ha nincs szelekció és elavuláskezelés, az agent nem tanulni fog, hanem felhalmozni.

A memória nem adatbázis, hanem döntési rendszer

Sok magyarázat túl hamar technológiai kérdéssé egyszerűsíti a memóriát. SQL, vektoros adatbázis, gráfok, RAG. Mintha a probléma csak annyi lenne, hol tároljuk az adatot.

Pedig nem az adattárolás a lényeg, hanem a jó döntés.

Mit érdemes megőrizni? Mi számít tartós tudásnak, és mi csupán zaj az aktuális munkamenetből? Mi legyen mindig kéznél, és mi az, ami csak akkor kerüljön elő, ha valóban releváns? Mi az, amit egy idő után el kell felejteni?

Ezek nem adatbázis-kérdések, hanem kőkemény, pénzben is kifejezhető termék- és rendszertervezési kérdések. A nagy kérdés a vállalatok számára az, hogy ez a pénz nyereségként vagy veszteségként realizálódik.

Nem minden agentnek kell ugyanaz a memória

Nem minden use case igényli mind a négy memóriaformát ugyanazzal a mélységgel.

Egy egyszerű ügyfélszolgálati agent, amely jól körülhatárolt folyamatokat visz végig, sokszor kiválóan működik munkamemóriával és procedurális memóriával. Nem kell neki gazdag epizodikus réteg, ha nincs valódi tanulási igény több munkameneten át.

Egy kódoló agent vagy egy komplex belső operációs agent viszont más kategória. Ott az agentnek tudnia kell, hogy:

• mi a projekt szabályrendszere;
• milyen workflow szerint dolgozzon;
• mit tanult a korábbi hibákból;
• mi az aktuális kontextus, amiben most lépnie kell.

Ott már mind a négy memória versenyelőny, nem extra.

A hasznos kérdés nem az, hogy van-e skill.md, hanem az, hogy mire emlékszik az agented

Az “AI agent” kifejezés körüli zaj részben azért ilyen nagy, mert túl sokan viselkedési címkeként használják. Ha a rendszer autonómnak tűnik, már agentnek hívják. Ez kényelmes, de komplex rendszerek tervezőinek nem mond sokat.

Ha tudjuk a választ arra, hogy az AI agentnek mit kell megőriznie, azt mikor kell előhívnia, és hogyan változtatja ez meg a következő döntését, akkor jó irányba tesszük meg az első lépéseket.

Ha a fentiekre viszont nincs válasz, akkor nagy eséllyel nem agentet építesz, csak egy ügyesebb chatfelületet.

Az igazán használható AI rendszerek nem attól lesznek jobbak, hogy még egy promptsort hozzájuk tudsz írni. Attól lesznek jobbak, hogy világosan szétválasztod: mi az aktuális kontextus, mi a tartós tudás, mi a végrehajtási rutin, és mi az a tapasztalat, amit érdemes megőrizni.

Ez az igazi rendszertervezés, nem promptolás-mágia — ami amúgy is egyre kevésbé releváns.

A csapatok többsége ma még modelleket választ. A kiemelkedő termékcsapatok viszont már memóriaarchitektúrát terveznek.