Agent memory: mit tároljunk, és mit felejtsünk el?

Mi a memória, és mi nem az?

A leggyakoribb félreértés, hogy a hosszú kontextusablak memória. Nem az. A kontextusablak az, ami egy futásban elfér a modell előtt; a memória az, ami futások között megmarad. Erről a különbségről szól a token és a context window poszt részletesen.

A bevett felosztás hatókör szerint kettő:

• Rövid távú memória — egyetlen munkamenethez kötött. A beszélgetés menete, mentési pontokkal megőrizve, hogy a szál bármikor folytatható legyen.
• Hosszú távú memória — munkameneteken és beszélgetéseken átívelő, névterekbe rendezve, bármikor és bármelyik szálból elérhető.

Típus szerint pedig három:

Ez a hármas azért hasznos, mert mindháromnak más a helyes lejárati ideje. A szemantikus tény elavul (megváltozik a beosztás, a cégnév, a preferencia). Az epizodikus emlék nem elavul, hanem irrelevánssá válik. A procedurális szabály pedig addig érvényes, amíg a munkafolyamat nem változik — és akkor egyszerre kell cserélni, nem kopni.

Mikor írjon az agent?

Két lehetőség van, és ez tervezési döntés, nem részletkérdés:

• Futás közben (a „forró úton"): amit az agent megtanult, azonnal elérhető. Cserébe nő a késleltetés, és bonyolultabb lesz a rendszer.
• Háttérben, aszinkron módon: nincs késleltetés, de el kell dönteni, mikor és milyen gyakran fusson az összegző lépés.

A gyakorlati kompromisszum általában az, hogy a tényírás megy a forró úton (rövid, olcsó), az összefoglalás és a rendezés a háttérben.

A mérés: a memória a leggyengébb agentes képesség

Itt egy szokatlanul jó független forrás áll rendelkezésre. Egy egyetemi kutatócsoport függvényhívási ranglistája külön kategóriában méri a memóriát, és három memóriastratégiát mér ugyanazon a modellen:

• kulcs-érték tárolás — az agent címkézett rekeszekbe ír és onnan olvas,
• vektoros visszakeresés — a tárolt darabok jelentés szerint kereshetők (erről szól az embedding és a vektoros keresés poszt),
• rekurzív összefoglalás — az agent időről időre újraírja a sajátját, tömörebben.

Az eredmény (2026 áprilisi állapot, 109 modell):

(Saját számítás a nyilvános ranglista adattáblájából. A ranglista rendszeresen frissül.)

Három dolog olvasható ki ebből, és mindhárom mérésből jön:

1. A memória nagyságrenddel gyengébb, mint a többi agentes képesség. Ugyanazok a modellek, amelyek egyetlen függvényhívásnál 86–91%-ot érnek el, memóriafeladatokon 29–74%-on végeznek. A teljes mezőny átlaga egyik stratégiánál sem éri el a 30%-ot.

2. Átlagosan a rekurzív összefoglalás nyer — 28,2% a vektoros 18,6%-ával és a kulcs-érték 13,9%-ával szemben. Ez első ránézésre meglepő: az összefoglalás veszít információt, mégis jobb. A magyarázat az, hogy a nyers tárolás nemcsak az információt őrzi meg, hanem a zajt is, és az agentnek magának kell kitalálnia, mit kérjen le.

3. De nincs univerzálisan jó architektúra. Nézd meg a táblázat negyedik sorát: ugyanaz a modell, két különböző működési módban. Függvényhívásos módban a vektoros stratégia nyer nála (63,23%), méghozzá tizenkét ponttal az összefoglalás előtt — miközben a mezőny többségénél pont fordítva van. A memóriaarchitektúra és a modell nem független választás. Ha modellt váltasz, a memóriastratégiádat újra meg kell mérni.

Ezt egy második, akadémiai mérés is alátámasztja: egy 500 kérdésből álló, kifejezetten hosszú távú memóriára tervezett benchmark on a kereskedelmi asszisztensek és a hosszú kontextusú modellek 30%-os pontosságesést mutattak, amikor több munkameneten át kellett megjegyezniük valamit.

A gyártói számok — és mit érnek

Két számsor kering erről, mindkettőt érdemes ismerni, és mindkettőt a helyén kezelni.

Az egyik modellszolgáltató közlése szerint a memóriaeszköz és a kontextusszerkesztés együtt 39%-os javulást adott az alapesethez képest; a kontextusszerkesztés önmagában 29%-ot. Egy 100 körös keresési feladaton pedig olyan munkafolyamatokat tett befejezhetővé, amik egyébként elfogyó kontextus miatt elbuknának — 84%-kal kevesebb token mellett. (Belső, nem publikált kiértékelés; mintanagyság és módszertan nélkül.)

Egy memóriaterméket fejlesztő csapat tanulmánya szerint a saját megoldásuk 26%-os relatív javulást ad egy bírálómodellel mért metrikán, 91%-kal alacsonyabb késleltetés és 90%-nál nagyobb tokenmegtakarítás mellett a teljes kontextus átadásához képest. (A szerzők a mért terméket fejlesztő cégnél dolgoznak. A javulást bírálómodell méri, nem objektív helyesség.)

A 84% és a 90% mögött ugyanaz az igazság áll, és ezt érdemes elvinni akkor is, ha a pontos számokat nem hisszük el: a memória elsősorban költségeszköz. Nem attól lesz okosabb az agent, hogy emlékszik — hanem attól olcsóbb és hosszabban futóképes, hogy nem kell mindent minden körben újra elé tenni.

A memória mint támadási felület

Ez a fejezet az, amit a legtöbb bevezetés kihagy, pedig itt a legnagyobb a kockázat. A memória definíció szerint átviszi a bizalmat egyik futásból a másikba — vagyis egyetlen sikeres támadás tartós hatást ér el.

A legfontosabb mérés ebben a témában azért az, ami, mert a támadónak nincs hozzáférése a memóriához. Csak kérdezni tud, és nézni a választ. Egy 2025 márciusi tanulmány pontosan ezt vizsgálta: áthidaló lépésekkel köti össze az áldozat későbbi kérdését egy káros gondolatmenettel, majd fokozatosan eltünteti az explicit utasításokat, amíg csak az ártalmatlannak látszó emlék marad.

A támadás költsége: áldozat-cél páronként 10–15 lekérdezés. Nem nulladik napi sérülékenység, nem kiszivárgott kulcs — hétköznapi használat.

Egy másik, 2024-es vizsgálat a memóriába és a tudásbázis ba rejtett hátsó ajtót mérte három valós agenttípuson: 80% fölötti támadási sikerarány, 0,1%-nál kisebb mérgezési arány mellett, és 1%-nál kisebb hatással a normál működésre. Ez utóbbi a lényeg: a mérgezett memóriájú agent jól viselkedik, amíg a kiváltó feltétel be nem következik.

Három dokumentált eset, ami ugyanezt a mintát mutatja élesben:

2025. február. Egy kutató megmutatta, hogy egy nem megbízható dokumentum összefoglalása közben az asszisztens elhelyezhet egy feltételes utasítást: ha a felhasználó később kimond egy adott szót, akkor mentsen el valamit a hosszú távú memóriába. A modell ilyenkor azt hiszi, hogy a felhasználó közvetlen kérését teljesíti. A bizonyító példában becenév, hamis életkor és egy nyilvánvalóan valótlan világkép került be. A gyártó minősítése: „alacsony valószínűségű és alacsony hatású, visszaélésszerű kockázat." A kutató nem így látta.

2026. május. Egy biztonsági csapat leírt egy esetet, ahol egy hétköznapi fejlesztői munkafolyamat — tároló klónozása, egy csomag telepítésének jóváhagyása — elért a tartós memóriáig, a globális beállításokig, és befolyásolta a legmagasabb bizalmi szintű utasításréteget is. Az összefoglalásuk pontosan írja le, miért más ez, mint egy sima injekció: egyetlen alkalmi cselekvés alakította a modell jövőbeli viselkedését munkameneteken, projekteken, sőt újraindításokon át. A gyártó javítása tanulságos: kivette a felhasználói emlékeket a rendszerpromptból, vagyis a magas bizalmi szintű rétegből.

2026. július. A legfrissebb eset azért fontos, mert ott a memória maga a szivárgási csatorna. A rendszer a korábbi beszélgetésekből néhány bekezdésnyi összefoglalót készít a felhasználóról, és ezt minden új beszélgetésbe beteszi. A támadó egy olyan weboldalt üzemeltetett, ami betűrendbe szervezett hivatkozásokat kínált — a modell pedig betűről betűre végignavigálva kibetűzte az adatot. Kiszivárgott a teljes név, a munkáltató és a szülőváros. Ez utóbbit a felhasználó soha nem mondta ki: a rendszer egy helyi rendezvény említéséből következtette ki, és az emlékbe már a következtetés került be.

Ez az utolsó részlet az, amit érdemes megjegyezni: a memóriában nem az van, amit mondtál, hanem amit a modell kikövetkeztetett belőle. És az esetben a szülőváros egy biztonsági kérdés válasza is volt.

A védekezés itt nem a memórián belül van, hanem a kijárati oldalon — erről szól a legkevesebb jogot kapó agent poszt részletesen, a bemeneti oldalról pedig a prompt injection alapjai című írás ad áttekintést.

A memóriaírás adatkezelés

Ezt sokan meglepetésként élik meg, pedig egyenesen következik a jogszabály szövegéből: az uniós adatvédelmi rendelet az adatkezelés fogalmában a tárolást kifejezetten nevesíti. Vagyis ha az agent személyes adatot ír a memóriájába, az önmagában adatkezelés — jogalappal, céllal, megőrzési idővel, dokumentációval.

Négy alapelv van, ami közvetlenül fordítható tervezési döntéssé:

Ehhez jön az elszámoltathatóság: a megfelelést bizonyítani is kell tudni. Az agent memóriájáról tehát legyen leírt megőrzési szabályzat — akkor is, ha a memória mindössze egy JSON-fájl.

És van egy pont, ami az architektúrára közvetlen követelményt támaszt. A törléshez való jog nem áll meg egyetlen rekordnál: a rendelet kifejezetten kiterjeszti a személyes adat másolataira és replikációira is. Egy agentnél ez azt jelenti, hogy egy törlési kérés beérkezésekor tudni kell, melyik összefoglalóba, melyik vektorindexbe és melyik korábbi futás kontextusába került be az adat.

Ez technikailag nehéz — és pont ezért érdemes a memóriát forrásmegjelöléssel írni: melyik beszélgetésből, mikor, milyen jogalappal. Utólag ezt nem lehet rekonstruálni. Arról, hogy az adat fizikailag hol áll meg, az EU-s adattárolás témájú poszt szól bővebben.

(Az uniós adatvédelmi testület 2024 decemberében véleményt adott ki az AI-modellek adatvédelmi szempontjairól. Kifejezetten agent-memóriára szóló hatósági iránymutatást nem találtam — ez a terület jogilag még nyitott.)

Mit felejtsünk el?

Öt önálló alap, és mindegyikhez tartozik konkrét mechanizmus:

1. IDŐ SZERINT
   Töröld azokat a memóriafájlokat, amiket régóta nem
   OLVASOTT senki. Figyelem: hozzáférés szerint, nem
   írás szerint - a régi, de folyton használt emlék jó.

2. MÉRET SZERINT
   Legyen felső korlát a fájlméretre, és arra is,
   hány karaktert ad vissza egy olvasás. Korlát nélkül
   a memória feléli a kontextusablakot.

3. TARTALOM SZERINT
   Az érzékeny adatot ÍRÁS ELŐTT szűrd ki, kódból.
   A modell "általában megtagadja" - ez nem garancia.

4. JOGALAP SZERINT
   Amikor a cél megszűnik, az adat is. A pontatlan
   adatot késedelem nélkül javítani vagy törölni kell.

5. BIZALMI SZINT SZERINT
   A memória tartalmát ne told fel a rendszerprompt
   szintjére. Ott a modell utasításként kezeli.

Az ötödik pont a legkevésbé nyilvánvaló, és a legdrágább hiba. Ha a memória a rendszerprompt része, akkor a támadó egy sikeres beírással tartós utasítást szerzett, nem csak tartós adatot. A fentebb említett javítás pontosan ezt fordította vissza.

A how-to

1. ÍRD LE, MIT TÁROLSZ - MIELŐTT TÁROLNÁD
   Mezőnként: mi, miért, meddig, honnan jött.
   Ha ez nincs meg, a memóriád nem szabályozható.

2. VÁLASSZ STRATÉGIÁT, DE MÉRD IS MEG
   Alapértelmezésben rekurzív összefoglalás.
   De modellváltáskor a sorrend felborulhat.

3. KÜLÖN TÁROLD A TÉNYT ÉS A KÖVETKEZTETÉST
   "Ezt mondta" és "ebből arra jutottam" nem
   ugyanaz a megbízhatóság, és nem is ugyanaz a
   jogi helyzet.

4. AZ ÍRÁS LEGYEN SZŰK, AZ OLVASÁS TÁG
   Kevés dolgot ments, de amit mentesz, azt
   találja meg. A fordítottja tölti tele a
   kontextust zajjal.

5. LEJÁRAT MINDEN MEZŐRE
   Alapértelmezett élettartam nélkül a memória
   monoton nő, és a régi hibák sosem kopnak ki.

6. LEGYEN "MIT TUDSZ RÓLAM" GOMB
   A felhasználó lássa és törölhesse. Ez egyszerre
   jogi kötelezettség és a legjobb hibakeresés.

7. NÉZD ÁT A MEMÓRIÁT, MINT A NAPLÓT
   Havonta egyszer olvasd el, mi gyűlt össze.
   A mérgezett emlék jól viselkedik - amíg nem.

A hatodik pont üzletileg is a legjobb befektetés. Amikor a felhasználó szembesül azzal, mit tárol róla a rendszer, kétféle reakció jön: vagy kijavítja (és onnantól jobb az agent), vagy megijed (és akkor túl sokat tároltál). Mindkettő hasznos információ.

Tipikus félreértések

• „A hosszú kontextusablak kiváltja a memóriát." Nem. A kontextusablak egy futáson belül tart, a memória futások között. És a hosszú kontextus önmagában is romlik — erről a subagent és a párhuzamos munka poszt hoz méréseket.
• „A memóriától okosabb lesz az agent." Elsősorban olcsóbb és hosszabban futóképes lesz. A pontosság javulására a legerősebb számok gyártói vagy érdekelt forrásból jönnek.
• „Mentsünk el mindent, a szűrés ráér." A mérés szerint a nyers tárolás a leggyengébb stratégia, a jog szerint pedig szükségtelen adatot nem tárolhatsz. Ez a ritka eset, amikor a két szempont ugyanabba az irányba mutat.
• „A modell úgysem ír ki érzékeny adatot." A dokumentáció óvatos megfogalmazása szerint „általában megtagadja". Erős garanciához kódból kell szűrni, írás előtt.
• „A memóriát csak az támadhatja, aki hozzáfér." A mérés szerint 98,2%-os beírási sikerarány érhető el pusztán lekérdezésekkel, tizenöt kérdésből.
• „Ha törlöm a rekordot, törölve van." A rekord összefoglalókba, vektorindexekbe és korábbi futások nyomvonalába is bekerült. A törléshez tudni kell, hova.

Amit érdemes elvinni

A memória a legkevésbé megoldott része az agenteknek. A számok ezt egyértelműen mutatják: a mezőny átlaga egyik stratégiánál sem éri el a 30%-ot, és modellenként más architektúra nyer — vagyis itt nincs bevált recept, csak mérés.

A gyakorlati következmény ezért nem az, hogy „ne használj memóriát", hanem hogy a memóriát kezeld úgy, mint egy adatbázist, nem úgy, mint egy kényelmi funkciót. Van sémája, van megőrzési ideje, van hozzáférés-szabályozása, és időnként át kell nézni, mi került bele.

És a legolcsóbb ellenőrzés, amit ma megtehetsz: olvasd el, mit tárol rólad a mindennap használt asszisztensed. Nagy eséllyel lesz benne olyan következtetés, amit soha nem mondtál ki — és nagy eséllyel lesz olyan is, ami már nem igaz.

Hogy miért romlik a megbízhatóság a lépésszámmal, arról az agent-megbízhatóság matematikája poszt szól; a kontextus tudatos összeállításáról pedig a context engineering című írás szól.