State és memory

Miért érdekel ez téged?

A chat history nem egyenlő memóriával. A beszélgetési előzmény csak nyers napló arról, mi hangzott el — a memória ezzel szemben az, amit tudatosan kiválasztasz, feldolgozol, tárolsz és a megfelelő pillanatban visszatöltesz. A kettő összekeverése az egyik leggyakoribb ok, amiért az agentek vagy „elfelejtenek" fontos dolgokat, vagy megfulladnak a saját múltjukban.

Gondolj a különbségre úgy, mint egy értekezlet hangfelvétele és a jegyzőkönyve közti eltérésre. A hangfelvétel (chat history) mindent tartalmaz, kronologikusan, szerkesztetlenül — de ha minden döntéshez visszahallgatnád, sosem érnél a végére. A jegyzőkönyv (memória) csak azt őrzi meg, ami később számít: a döntéseket, a felelősöket, a határidőket. Egy jó agent nem a teljes felvételt cipeli magával, hanem folyamatosan jegyzőkönyvet ír magának.

Ez a fejezet arról szól, milyen fajta memóriákat különböztetünk meg, mit szabad és mit kell megjegyezni, és hogyan tartják életben magukat az órákig-napokig futó agentek anélkül, hogy egyetlen hálózati hiba tönkretenné az egész munkájukat.

A memória tervezése szorosan összefonódik a 2. Context engineering fejezettel: a memória a forrás, a context assembly pedig az, ami minden model call előtt eldönti, mennyi és melyik memória kerüljön ténylegesen a context window-ba.

Miért a memória az agentek legnehezebb része

Egy egyszerű chatbotnál a memória kérdése triviális: az egész beszélgetés belefér a context window-ba, és kész. A probléma akkor kezdődik, amikor az agent túllépi ezt a méretet — egy 200 000 tokenes context window is megtelik pár óra alatt, ha minden tool-eredményt, minden köztes gondolatot és minden felhasználói üzenetet nyersen megőrzöl. Egy tipikus kódoló agent egyetlen közepes feladat során 30-60 tool-hívást tesz (fájl olvasás, keresés, teszt futtatás), és ezek eredménye könnyen 100 000+ tokent tesz ki.

Két rossz szélsőség létezik. Az egyik a „mindent elfelejtek" agent: minden fordulónál tiszta lappal indul, ezért újra és újra megkérdezi ugyanazt, elveszti a szálat, és nem tanul. A másik a „mindent megjegyzek" agent: a context window megtelik zajjal, a fontos információ elvész a lényegtelen között (ez a context rot, lásd 2. Context engineering), a költség és a latency az egekbe szökik. A jó memóriaréteg pontosan e két véglet között egyensúlyoz — és ez tervezési, nem véletlen döntés.

Memóriatípusok

A „memória" nem egyetlen doboz. Több, funkciójában eltérő rétegre bontható — és production rendszerben ezeket külön is kell tárolni, frissíteni és visszatölteni. Mindegyikhez odaírtam egy konkrét példát, hogyan tölti fel és használja egy agent.

• Working memory — az aktuális context Az éppen aktív feladathoz tartozó információ, ami most a context window-ban van: a jelenlegi cél, a legutóbbi tool-eredmény, a következő lépés terve. Feltöltés és használat: egy kódoló agent a working memory-ban tartja az éppen szerkesztett fájlt, a most kapott hibaüzenetet és a soron következő lépést; amint a feladat lezárul, ez az állapot eldobható. Analógia: az íróasztalon fekvő piszkozatfüzet — kéznél van, amíg dolgozol rajta, de nem archívum. Élettartama másodpercektől percekig terjed, és jellemzően a legdrágább hely, mert minden model call-nál újra elküldöd.
• Conversation memory — a beszélgetési előzmény A felhasználóval folytatott párbeszéd menete az adott munkameneten belül. Feltöltés és használat: egy ügyfélszolgálati agent megjegyzi, hogy három üzenettel korábban megadtad a rendelésszámodat (#4521), így nem kérdezi meg újra. Minden fordulóval bővül, és ha túl hosszúra nő, összefoglalással tömöríted (lásd 2. Context engineering) — ez már nem nyers history, hanem tudatosan karbantartott memória. Tipikus stratégia: az utolsó N fordulót szó szerint megtartod, a régebbieket pedig egy folyamatosan frissülő összefoglalóba tömöríted.
• Episodic memory — korábbi konkrét események Múltbeli, jól körülhatárolt események és interakciók, akár munkameneteken átívelve. Feltöltés és használat: egy asszisztens eltárolja, hogy „múlt kedden a felhasználó átrakta a megbeszélést, és a délelőttöt kérte" — időbélyeggel, diszkrét eseményrekordként. Amikor legközelebb hasonló helyzet adódik, ezt az epizódot előhívja. Ez az emlékezet arról, hogy mi történt és mikor. Az episodic memory teszi lehetővé a „few-shot magamtól" mintát: az agent a saját múltbeli sikeres megoldásait hozza vissza példaként egy hasonló új feladathoz.
• Semantic memory — tartós tények és tudás Időtől független, stabil tények a felhasználóról, a domainről, a világról. Feltöltés és használat: az agent eltárolja, hogy „a felhasználó cége az Allianz, a DevOps csapatban dolgozik, és a Pythont preferálja" — kulcs-érték párokként vagy tényállításokként, relevancia szerint visszakeresve. Analógia: úgy tudod, hogy Párizs Franciaország fővárosa, hogy közben nem emlékszel, mikor tanultad — ez a tudás elvált a megtanulás epizódjától. Az episodic és semantic közti határ nem éles: egy epizódból („tegnap azt mondta, utálja a hosszú válaszokat") idővel semantic ténnyé desztillálódhat („preferálja a tömör választ").
• Procedural memory — hogyan kell valamit végrehajtani Betanult eljárások, lépéssorok, skillek. Feltöltés és használat: egy DevOps agent megtanulja, hogy „a release-hez először lefuttatjuk a teszteket, aztán taggeljük a verziót, majd elindítjuk a pipeline-t", és ezt újrahasználható eljárásként tárolja el. Ez rokon a 8. Protokollok fejezet skill-fogalmával: nem egyetlen tényt, hanem egy komponált munkafolyamatot jegyez meg. A gyakorlatban a procedural memory sokszor nem is adatbázisban, hanem szövegként (playbook, runbook, skill-leírás) él, amit az agent a system promptba vagy egy tool-ba tölt be.
• Artifact memory — létrehozott fájlok, tervek, kódok Az agent által előállított kimenetek: dokumentumok, tervek, kódrészletek, táblázatok. Feltöltés és használat: egy kutató agent a 3. lépésben megírt jelentés-piszkozatot object storage-ba menti egy azonosítóval, hogy a 7. lépésben át tudja írni ahelyett, hogy az egészet újragenerálná. Nem a szöveget cipeli a contextben, hanem a referenciát — a tartalmat csak akkor tölti vissza, amikor épp dolgozik rajta. Ez ugyanaz az elv, mint amikor egy IDE-ben nem az összes fájlt tartod nyitva, csak azt, amin épp dolgozol, de a többi egy kattintásra elérhető.
• Execution state — hol tart a workflow A folyamat pillanatnyi állapota: melyik lépésnél tart, mi kész, mi van hátra, mire vár. Feltöltés és használat: egy ötlépéses onboarding agent rögzíti, hogy „a 2. lépés kész az 5-ből, a 3. lépéshez emberi jóváhagyásra várunk". Pontosan ez az az állapot, amitől egy összeomlás vagy újraindítás után folytatni lehet a munkát, nem elölről kezdeni — erről szól a fejezet utolsó nagy szekciója. Az execution state különbözik a többitől: nem „tudás", hanem a folyamat könyvelése, és a helyessége kritikus, míg egy semantic tény enyhe pontatlansága sokszor elviselhető.

Rövid táv vs hosszú táv: melyik hol lakik

A hét memóriatípus két nagy csoportba esik. A rövid távú (working, conversation, execution state az aktuális futásra) a context window-ban vagy egy gyorsan elérhető állapotobjektumban él, a feladat élettartamáig. A hosszú távú (episodic, semantic, procedural, artifact) külső, tartós tárban, és munkameneteken, sőt felhasználókon átível. A kettő közti mozgás — mikor emelsz egy rövid távú emléket hosszú távúvá (konszolidáció), és mikor húzol vissza egy hosszú távút a contextbe (retrieval) — a memóriamérnökség lényege.

A táblázatból a lényeg: nincs egyetlen „memória-adatbázis". Egy komoly agent-rendszerben egyszerre fut egy relációs DB (execution state, provenance), egy vektorindex (episodic/semantic retrieval) és egy object store (artifactok) — mindegyik a saját hozzáférési mintájára optimalizálva.

Hogyan néz ki egy memóriarekord a gyakorlatban

Nem elég a nyers tényt eltárolni — köré metaadatot is teszel, hogy később súlyozni, szűrni és auditálni tudd. Egy tipikus semantic memóriarekord így néz ki:

memory = {
    "id": "mem_8f3a",
    "tenant_id": "org_allianz",        # kötelező izolációs szűrő
    "user_id": "user_142",
    "type": "semantic",
    "fact": "A felhasználó a Pythont preferálja a Java helyett.",
    "embedding": [...],                # szemantikus kereséshez
    "source": "conversation:sess_991", # provenance: honnan jött
    "confidence": 0.8,                 # mennyire bízunk benne
    "created_at": "2026-07-10T09:12Z",
    "valid_until": None,               # TTL / lejárat, ha van
    "superseded_by": None,             # verziózás: mi váltotta le
}

Amit tanulj belőle: a fact mező önmagában szinte értéktelen. A tenant_id teszi biztonságossá, a source és confidence auditálhatóvá, a created_at és superseded_by pedig időben kezelhetővé. A metaadat nem dekoráció — ez teszi a nyers tényt megbízható memóriává.

Amit tudnod kell

A memóriaréteg megépítése nem az „ments el mindent" reflexről szól — az adatvédelmi rémálom lenne, és rontaná a minőséget is. A valódi mérnöki kérdések ezek:

• Mit szabad megjegyezni Csak azt, ami később bizonyíthatóan hasznos, és amit jogilag is megtarthatsz: tartós preferenciák, stabil tények, döntések, létrehozott artifactok. A múló, érzékeny vagy egyszer használatos adat (jelszó, bankkártyaszám, alkalmi kérés) nem való a hosszú távú memóriába. Alapelv: a memória célja a jövőbeli döntés támogatása, nem a teljes múlt archiválása. Konkrét teszt: „ha ezt egy hét múlva visszahoznám, segítene egy döntésben?" Ha nem, ne írd be.
• Mit kell elfelejteni A working memory-t a feladat végén, a beszélgetési előzmény régi részét összefoglalás után, az elavult vagy visszavont tényeket pedig aktívan. A felejtés nem hiba, hanem funkció: nélküle a memória zajossá, ellentmondásossá és drágává válik. Tervezz be TTL-t (lejárati időt) és explicit törlési útvonalat minden memóriatípushoz. Az emberi memória is felejt — és pontosan ez teszi használhatóvá; nem akarsz mindenre emlékezni, amit valaha láttál.
• Hogyan történik a memory retrieval A visszakeresés jellemzően szemantikus keresés (embedding-alapú), metaadat-szűréssel és recency-súlyozással kombinálva — ugyanaz az eszköztár, mint a 4. RAG retrievalnél, csak a korpusz itt az agent saját memóriája. A cél nem az összes emlék visszaöntése, hanem a néhány valóban releváns kiválasztása az aktuális feladathoz. Egy gyakori pontszám-képlet: score = relevance × recency × confidence, ahol mindhárom tényezőt külön hangolod.
• Hogyan kerülöd el a memory poisoningot A memory poisoning az, amikor egy támadó (vagy egy hibás forrás) hamis tényt csempész a tartós memóriába, amit az agent később igazként használ. Analógia: hamis emlék elültetése — utólag nehéz megkülönböztetni a valóditól. Védekezés: a beírás előtt validálj, jelöld a forrást, ne tekintsd automatikusan igaznak a felhasználói vagy retrieval-eredetű állításokat. Ez komoly biztonsági kérdés — részletesen a 15. AI Security fejezetben.
• Hogyan verziózod a memóriát A tények változnak, ezért a memóriarekordokat ne felülírd, hanem verziózd: tartsd meg, mikor és mi alapján keletkezett egy állítás, és melyik váltotta le. Így visszakövethető, miért „gondolta" az agent adott pillanatban azt, amit — és egy hibás beírás visszagörgethető anélkül, hogy az egész memóriát újra kellene építeni. Ez ugyanaz az append-only szemlélet, mint a git commit history: nem törlöd a múltat, hanem új réteget teszel rá.
• Hogyan kezeled az elavult tényeket A „a felhasználó a marketingen dolgozik" tény igaz lehetett tavaly, de ma már nem. Az elavulást kezeld időbélyeggel és konfliktusfeloldással: ha új tény ellentmond a réginek, az újabb és megbízhatóbb forrás nyer, a régit pedig archiváld, ne csak töröld. A frissesség maga is metaadat, amit a retrievalnél súlyozhatsz. Vigyázz a némán elavuló tényekre is: nem mond ellent semmi, csak egyszerűen már nem igaz — ezekre a TTL a védelem.
• Hogyan tárolod a provenance-t Minden memóriadarabhoz tartozzon provenance: honnan származik (melyik beszélgetés, melyik dokumentum, melyik tool), mikor, milyen megbízhatósággal. Provenance nélkül nem tudod eldönteni, megbízhatsz-e egy emlékben, nem tudod auditálni, és a poisoninget sem tudod visszakeresni. Ez ugyanaz az elv, mint a 2. Context engineering context provenance-e. A provenance az a metaadat, ami egy incidens után lehetővé teszi a kérdést: „honnan vette az agent ezt a hamis tényt?"
• Hogyan választod szét a tenantokat Multi-tenant rendszerben az egyik ügyfél memóriája soha nem szivároghat át a másikéhoz. A tenant-azonosítót tedd a tárolás és a retrieval kötelező szűrőjévé — ne csak a lekérdezésbe, hanem az adatréteg izolációjába is. A cross-tenant leakage az egyik legsúlyosabb, bizalmat romboló hiba (lásd 15. AI Security). A legbiztosabb, ha a tenant-szűrés nem opcionális paraméter, hanem a lekérdező réteg alapértelmezetten kikényszeríti — így egy elfelejtett WHERE tenant_id = ? nem vezethet szivárgáshoz.
• Hogyan működik a consent és deletion A felhasználónak joga van tudni, mit jegyez meg róla az agent, és joga van törölni azt (GDPR „right to be forgotten"). Ehhez a memóriának kereshetőnek, felhasználóhoz köthetőnek és törölhetőnek kell lennie — beleértve a származékokat is (pl. embeddingek, összefoglalók). A törlés ne csak „logikai flag" legyen, ha a jog valódi eltávolítást kíván. Külön csapda: ha egy régi összefoglalóba már „beleégett" egy tény, a forrásrekord törlése önmagában nem elég — a származékot is frissítened kell.
• Hogyan foglalod össze a hosszú folyamatokat Egy órákig futó agentnél a nyers előzmény réges-rég kilógna a context window-ból. A megoldás a hierarchikus összefoglalás: a lépéseket rendszeresen tömöríted egy magasabb szintű állapotleírásba (mi a cél, mi kész, mi a következő), a részleteket pedig artifact- vagy episodic memóriába teszed. Így a working memory kicsi és fókuszált marad, miközben a részletek elérhetők, ha kellenek. Ez a „piramis" szerkezet: felül a rövid állapotösszefoglaló, alatta rétegenként egyre részletesebb, igény szerint lehívható tartalom.

A memória írási útvonala: mikor és hogyan konszolidálsz

A hosszú távú memóriába kétféleképp kerülhet tartalom. Az explicit írásnál a felhasználó vagy egy tool kifejezetten kéri („jegyezd meg, hogy allergiás vagyok a mogyoróra"). Az implicit (más néven reflektív) írásnál az agent maga dönti el a beszélgetés végén, mi érdemes megjegyzésre — jellemzően egy külön model call desztillálja ki a tényeket a fordulóból. Az implicit út erősebb, de veszélyesebb: itt csúszik be a legtöbb zaj és a legtöbb poisoning-kockázat, ezért ide kell a legszigorúbb validáció.

def consolidate_memory(session, tenant_id, user_id):
    # 1. Egy LLM kivonatolja a megjegyzendő tényeket a beszélgetésből
    candidates = extract_facts(session.messages)

    for fact in candidates:
        if not is_durable_and_safe(fact):   # PII? egyszer használatos? -> skip
            continue

        existing = memory_store.find_similar(
            tenant_id=tenant_id, user_id=user_id, fact=fact
        )
        if existing and contradicts(existing, fact):
            # nem felülírjuk: verziózunk
            memory_store.supersede(existing.id, new_fact=fact)
        elif not existing:
            memory_store.insert(fact, source=session.id, confidence=0.8)

Amit tanulj belőle: a konszolidáció három lépés — kivonatolás, szűrés (biztonság és tartósság), majd összevetés a meglévővel. A naiv verzió mindezt kihagyja, és egyszerűen mindent beír — pontosan így lesz a memória pár hét alatt zajos és ellentmondásos.

Gyakori hibák a memóriakezelésben

• Nyers history összekeverése memóriával A leggyakoribb hiba: az egész chat historyt visszatöltik minden hívásnál, és ezt nevezik „memóriának". Ez a context window gyors megtelését, romló minőséget és fölösleges költséget okoz. A history nyers napló; a memória tudatosan kiválasztott, tömörített kivonat.
• Minden tool-eredmény tartós tárba mentése Egy időjárás-lekérdezés eredményét nem kell hetekig megőrizni. A tranziens, gyorsan avuló adatot tartsd a working memory-ban, és hagyd elmúlni — a tartós tárba csak a döntéshez később is releváns tudás kerüljön.
• Validáció nélküli implicit írás Ha az agent minden fordulóból automatikusan, ellenőrzés nélkül tényeket ír a semantic memóriába, előbb-utóbb ellentmondó vagy hamis állítások halmozódnak fel — és ezek később magabiztos hibás válaszokká válnak.
• A tenant-szűrő elfelejtése egyetlen lekérdezésben Elég egy retrieval út, ahol lemarad a tenant_id szűrő, és máris cross-tenant leakage keletkezik. Ezért kell a szűrést a data access rétegbe kikényszeríteni, nem az egyes lekérdezésekre bízni.

Long-running agentek

Amint egy agent túllép a néhány másodperces kérés-válasz cikluson és percekig, órákig vagy akár napokig fut — közben tool-okat hív, emberi jóváhagyásra vár, külső eseményekre reagál —, a klasszikus distributed systems problémák a nyakadba szakadnak. Az execution state ekkor már nem kényelmi funkció, hanem túlélési feltétel. A legtöbb ide tartozó fogalom közös a 13. Production architektúra distributed systems alapjaival; itt agent-nézőpontból nézzük őket.

• Checkpoint Az agent állapotának pillanatképe egy jól definiált ponton, tartós tárba mentve. Analógia: a videojáték mentési pontja — ha elesel, nem a pálya elejéről kezdesz, hanem a legutóbbi checkpointtól. Minden nem triviális lépés után érdemes checkpointot írni. A checkpoint gyakorisága kompromisszum: túl sűrűn drága és lassít, túl ritkán sok elveszett munkát kockáztat egy összeomláskor.
• Resumability A képesség, hogy a folyamat egy checkpointból folytatható legyen, ne csak elölről indítható. Ehhez az állapotnak teljesnek és determinisztikusan visszatölthetőnek kell lennie: a betöltés után az agentnek pontosan onnan kell tudnia dolgozni, ahol abbahagyta. Csapda: ha az állapot rejtett függőségeket tartalmaz (pl. egy nyitott hálózati kapcsolat vagy egy in-memory cache), a resume nem lesz tiszta — csak a serializálható állapotra támaszkodj.
• Durable execution Olyan végrehajtási modell, ahol a folyamat állapota automatikusan és megbízhatóan fennmarad összeomlás, újraindítás vagy deploy után is. A modern orchestration frameworkök (pl. Temporal, LangGraph) ezt kínálják: a kódod „normálisan" fut, a keretrendszer viszont minden lépést naplóz és visszajátszható állapotot tart fenn. A fő feltétel: a lépéseknek determinisztikusnak vagy legalább replay-biztosnak kell lenniük, különben a visszajátszás más eredményt ad.
• Event log A folyamat során történt események append-only naplója. Ebből az állapot bármikor újraépíthető (event sourcing), és teljes, auditálható nyoma marad annak, mi történt és milyen sorrendben — ami az agentek nemdeterminizmusa mellett aranyat ér a hibakeresésnél. Az event log és a checkpoint kiegészítik egymást: a log a teljes történet, a checkpoint pedig egy anyagosított pillanatkép, amiről gyorsan indulhatsz.
• State machine A folyamat explicit állapotokra és megengedett átmenetekre bontása (pl. tervezés → végrehajtás → jóváhagyásra vár → kész). Így minden pillanatban egyértelmű, hol tart az agent és milyen lépés következhet — sokkal biztonságosabb, mint egy szabadon csordogáló loop. Az explicit state machine ráadásul a human-in-the-loop pontok természetes helye: a „jóváhagyásra vár" egy valódi állapot, amiben a folyamat órákig, kockázatmentesen ülhet.
• Lease és distributed lock Ha ugyanazon a feladaton több worker is dolgozhatna, a lease (időzített, megújítható „bérlet") és a distributed lock biztosítja, hogy egyszerre csak egy csinálja. Enélkül két agent-példány párhuzamosan hajtaná végre ugyanazt a műveletet — pl. kétszer küldene ki egy emailt. A lease az egyszerű lockkal szemben lejár: ha a worker meghal a lock elengedése nélkül, a bérlet lejártakor egy másik átveheti — így nem ragad be örökre a feladat.
• Retry policy Előre definiált szabály arra, mit tegyünk hiba esetén: hányszor próbálkozunk újra, milyen (exponenciális) backoffal, és mely hibák számítanak egyáltalán retryable-nek. A tranziens hálózati hibát újra lehet próbálni; egy validációs hibát nem érdemes. Adj a backoffhoz jittert (véletlen szórást), különben egy közös kiesés után az összes worker egyszerre próbálkozik újra, és megismétli a terhelési csúcsot.
• Timeout Minden lépéshez és a teljes folyamathoz is felső időkorlát. Enélkül egy beragadt tool-hívás vagy egy sosem érkező emberi jóváhagyás örökre lefoglalná az erőforrásokat. A timeout lejárta jól definiált átmenet a state machine-ben, nem véletlenszerű összeomlás. Két szint kell: rövid lépés-timeout (pl. egy API-hívásra másodpercek) és hosszú folyamat-timeout (pl. egy jóváhagyásra órák-napok).
• Cancellation A folyamat rendezett leállításának képessége — ha a felhasználó meggondolja magát, vagy egy felettes folyamat megszakítja. A cancellation jelet propagálni kell a futó tool-hívásokig és alfolyamatokig, hogy ne maradjanak árva, tovább dolgozó részek. A rendezett cancellation gyakran együtt jár compensationnel: nem elég megállni, a már megtett, mellékhatásos lépéseket vissza is kell csinálni.
• Dead-letter queue Az a hely, ahová a többszöri próbálkozás után is feldolgozhatatlan feladatok kerülnek, hogy ne blokkolják a sort, de ne is vesszenek el. Analógia: a postán a „kézbesíthetetlen küldemények" polca — nem dobod ki, hanem félreteszed emberi vizsgálatra. A DLQ méretének növekedése önmagában is riasztási jel: ha hirtelen sok feladat kerül ide, valami rendszerszintű hiba van.
• Compensation Ha egy többlépéses folyamat félúton elbukik, a már végrehajtott lépéseket vissza kell csinálni (saga-minta): pl. ha lefoglaltuk a szállodát, de a repülőjegy foglalása elhasalt, a szállodát le kell mondani. Az LLM-agenteknél különösen fontos, mert egy lépés mellékhatásai gyakran a külvilágban (más rendszerekben) csapódnak le. Minden mellékhatásos lépéshez tervezz be egy párját: a foglaláshoz a lemondást, a létrehozáshoz a törlést.
• Partial result persistence A részeredmények folyamatos, tartós mentése, hogy egy késői hiba se tegye tönkre a korábban elvégzett, drága munkát. Egy 50 dokumentumot feldolgozó agentnél a 48. dokumentumnál bekövetkező hiba nem dobhatja el az első 47 eredményét — azokat már rég le kellett menteni. Ez különösen fontos, ha minden lépés drága LLM-hívás: az elveszett részeredmény nem csak időt, hanem valódi pénzt is jelent.

A gyakorlatban ez azt jelenti, hogy az agent állapotát nem a memóriában (RAM) tartod, hanem minden fontos lépés után egy tartós store-ba írod — így bármikor visszatölthető és folytatható:

def run_agent(task_id: str):
    state = store.load(task_id) or {"step": 0, "results": []}

    for step in range(state["step"], len(PLAN)):
        try:
            result = execute_step(PLAN[step], state)
        except TransientError:
            raise  # a retry policy majd újrapróbálja innen

        state["results"].append(result)
        state["step"] = step + 1
        store.save(task_id, state)   # checkpoint minden lépés után

    return state["results"]

Ha a folyamat a 3. lépésnél összeomlik, az újraindítás a mentett állapotból a 3. lépéstől folytatódik — az első kettő eredménye már biztonságban van a store-ban. Amit tanulj belőle: a checkpoint helye nem véletlen — közvetlenül a mellékhatás után és a következő lépés előtt mentesz, hogy egy összeomlás soha ne hagyjon félbeszakadt, nem könyvelt műveletet.

Idempotencia: miért ez a resumability alapja

A resume és a retry egyik legalattomosabb problémája: mi történik, ha egy lépés lefutott, de a checkpoint mentése előtt omlott össze a rendszer? Újraindításkor az agent azt hiszi, a lépés még hátra van, és újra lefuttatja. Ha az adott lépés emailt küld, kétszer küldi. Ha fizetést indít, kétszer fizet.

A megoldás az idempotencia: minden mellékhatásos műveletet úgy tervezz, hogy a kétszeri végrehajtás ugyanazt az eredményt adja, mint az egyszeri. A gyakorlatban ez egy idempotencia-kulcs, amit a művelet mellé küldesz — a fogadó oldal (pl. a fizetési szolgáltató) ebből felismeri az ismétlést, és nem hajtja végre másodszor.

Human-in-the-loop mint tartós állapot

A long-running agentek egyik leggyakoribb esete: az agent eljut egy pontig, ahol emberi jóváhagyás kell (pl. „elküldhetem ezt az emailt az ügyfélnek?"), és ott várakozik. Ez nem lehet egy blokkoló input() hívás egy futó processben — az az első deploynál vagy összeomlásnál elveszne. Ehelyett a „jóváhagyásra vár" egy explicit, tartós állapot a state machine-ben: az agent checkpointot ír, felfüggeszti magát, és a jóváhagyás megérkezésekor (akár órákkal később, akár másik gépen) egy külső esemény ébreszti fel a mentett állapotból.

Döntési szempontok: mikor kell durable execution framework?

Nem minden agentnek kell Temporal vagy LangGraph szintű infrastruktúra. A saját, kézzel írt checkpoint-logika teljesen elég lehet egyszerű esetekben — a framework a folyamat összetettségével arányosan térül meg.

Összefoglalás

A chat history nem memória: az előzmény nyers napló, a memória pedig tudatos döntés arról, mit tartasz meg és mikor töltöd vissza. A memóriát rétegekre bontjuk — working, conversation, episodic, semantic, procedural, artifact és execution state —, és mindegyiket máshol tároljuk, más ritmusban frissítjük, és csak a releváns szeletét töltjük vissza a véges context window-ba. A rövid távú rétegek a contextben élnek, a hosszú távúak külső tárban, és a kettő közti mozgás — a konszolidáció és a retrieval — a memóriamérnökség lényege.

A jó memóriaréteg nem az „ments el mindent" elvről szól, hanem a tudatos megőrzésről és felejtésről: validált beírás a poisoning ellen, verziózás és provenance a visszakövethetőségért, tenant-szeparáció és consent/deletion a biztonságért és a jogszabályokért. A long-running agenteknél pedig az execution state distributed systems fegyverzetet kap — checkpoint, resumability, durable execution, idempotencia, compensation —, mert egy órákig tartó munkát nem teheti tönkre egyetlen hálózati hiba, és egy retry sem okozhat duplikált mellékhatást. Ha ezt jól csinálod, az agented nem felejt, nem fullad meg a múltjában, és túléli a valós világ zaját.