Kontextusromlás hosszan futó ügynököknél: törlés, tömörítés, memória és al-ügynökök

A context rot (kontextromlás) az LLM pontosságának csökkenése a bemenet hosszának növekedésével, jóval azelőtt, hogy a kontextusablak megtelne. Egy 1M tokenes ablak nem jelenti azt, hogy a modell a milliomodik tokent ugyanolyan jól használja, mint a századikat. Egy chatnél ez alig számít. Egy órákig futó ügynöknél, amely minden elolvasott fájlt és minden lefuttatott parancsot hozzáfűz, ez a fő oka annak, hogy a minőség a feladat vége felé leromlik.

Ez a cikk összegyűjti a bizonyítékokat, elmagyarázza, miért az ügynököket érinti leginkább, és végigveszi a négy, a gyakorlatban működő eszközt: a régi eszközeredmények törlését, a tömörítést (compaction), az ablakon kívüli jegyzeteket és memóriát, valamint a saját kontextussal dolgozó al-ügynököket. Mindegyiknél bemutatja a Claude és az OpenAI API jelenlegi mechanizmusait, és azokat a harness-mintákat, amelyek egy hosszú futást koherensen tartanak.

Mit mutat a kutatás

Három kutatási irány mutat ugyanabba az irányba. Egyik sem ügynökterhelést vizsgál, ami inkább arra utal, hogy a valódi ügynökök még rosszabbul járnak:

A Chroma jelentése két, ügynököknél fontos részlettel egészíti ki ezt. A zavaró elemek, vagyis a relevánsnak tűnő, de nem releváns tartalmak, a kontextus növekedésével egyre jobban ártanak, és a vizsgált Claude modellek ilyen kétértelműség mellett inkább tartózkodtak a választól, mint hogy találgassanak. Ráadásul, a megérzéssel ellentétben, a modellek jobban teljesítettek összekevert szénakazalon, mint összefüggő szövegen. A jelentés következtetése a hasznos rész: nem az számít leginkább, hogy a releváns információ benne van-e a kontextusban, hanem az, hogyan van tálalva.

Miért az ügynököket érinti leginkább

Az ügynökhurok minden eszközhívást és minden eszközeredményt hozzáfűz az előzményekhez, és a következő körben az egészet visszaküldi. Két óra munka után a kontextus nagyrészt elavult fájlolvasásokból, régi tesztkimenetekből és felülírt tervekből áll: pontosan abból a zavaró elemekkel teli, kevés jelet hordozó bemenetből, amelyet a fenti tanulmányok büntetnek. Az Anthropic kontextustervezési útmutatója ezt "figyelmi keretnek" nevezi: egy transformer minden tokent minden más tokennel kapcsolatba hoz, n tokennél n² párt, így minden újabb token hígítja a fontos tokenekre jutó figyelmet. Az útmutató munkaszabálya: a következő lépéshez "a lehető legkisebb, nagy jeltartalmú tokenhalmazt" kell megtalálni.

A második probléma a költség. Az előzmények minden tokenjét minden körben újra kiszámlázzák; a gyorsítótárazás ezt enyhíti (lásd a prompt cachingről és útválasztásról szóló cikket), de egy csak növekvő kontextus minden későbbi lépést lassabbá, drágábbá és pontatlanabbá is tesz.

Négy eszköz: törlés, tömörítés, kiszervezés, elkülönítés

Régi eszközeredmények törlése

Az Anthropic az eszközeredmények törlését "a tömörítés egyik legbiztonságosabb, legkíméletesebb formájának" nevezi: ha az ügynök már elolvasott egy fájlt és cselekedett is alapján, a teljes fájltartalomnak ritkán kell bent maradnia. A Claude API-ban ez a kontextusszerkesztés (context editing, béta fejléc: context-management-2025-06-27). A clear_tool_uses_20250919 stratégia egy küszöb felett lép életbe (alapértelmezésben 100 000 bemeneti token), megtartja a legutóbbi eszközhasználatokat (alapértelmezésben 3-at), a régebbi eredményeket pedig helyőrzőre cseréli:

response = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    betas=["context-management-2025-06-27"],
    tools=tools,
    messages=messages,
    context_management={"edits": [{
        "type": "clear_tool_uses_20250919",
        "trigger": {"type": "input_tokens", "value": 30000},
        "keep": {"type": "tool_uses", "value": 3},
        "clear_at_least": {"type": "input_tokens", "value": 5000},
        "exclude_tools": ["web_search"],   # results you never want dropped
    }]},
)

Két beállítás érdemel figyelmet. Az exclude_tools azokat az eredményeket védi, amelyeket az ügynök nem tud olcsón újra előállítani. A clear_at_least azért létezik, mert a törlés a módosítás pontjától érvényteleníti a gyorsítótárazott prompt-előtagot; ha egy törlési kör csak néhány száz tokent szabadít fel, a gyorsítótár újraírása többe kerül, mint amennyit megtakarít. Egy külön clear_thinking_20251015 stratégia ugyanezt teszi a régi thinking blokkokkal.

Ugyanez saját harnessben is megoldható béta nélkül: az utolsó néhány eszközeredményt szó szerint tartsd meg, a régebbieket pedig cseréld egysoros helyőrzőre, például "src/order.ts elolvasva (412 sor), lásd a jegyzeteket". A helyőrző olvashatóan tartja a trajektóriát, a tömeget viszont kidobja.

Tömörítés: összefoglalás és folytatás

A tömörítés (compaction) a régebbi köröket egy összefoglalóra cseréli, és onnan folytatja. Az Anthropic leírja, hogyan csinálja a Claude Code: a modell összefoglalja az előzményeket, megtartja az architekturális döntéseket, a megoldatlan hibákat és a megvalósítási részleteket, a felesleges eszközkimeneteket pedig elveti. Mindkét nagy API kínálja már szerveroldalon:

• Claude, tokenküszöbnél (béta: compact-2026-01-12): add hozzá a compact_20260112 stratégiát a context_management.edits listához. Az alapértelmezett küszöb 150 000 bemeneti token, a minimum 50 000. Az instructions teljesen lecseréli az alapértelmezett összefoglaló promptot, a pause_after_compaction pedig az összefoglaló után megáll, hogy a legutóbbi köröket szó szerint visszailleszthesd.
• Claude, igény szerint (béta: compact-2026-09-04): küldd el a beszélgetést a "compaction": {"type": "summarize"} paraméterrel; a válasz egyetlen aláírt compaction blokk "compaction" értékű stop_reason mellett, és ez kerül a következő kérés elejére az összefoglalt üzenetek helyére. Az időzítésről az alkalmazásod dönt.
• OpenAI Responses API: állítsd be a context_management mezőt compact_threshold értékkel a responses.create hívásban, vagy hívd meg az önálló compact végpontot. A visszaadott compaction elem titkosított, és "nem emberi értelmezésre szánt"; store=false mellett a folyamat ZDR-barát.

response = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    betas=["compact-2026-01-12"],
    tools=tools,
    messages=messages,
    context_management={"edits": [{
        "type": "compact_20260112",
        "trigger": {"type": "input_tokens", "value": 120000},
        "instructions": (
            "Summarise for continuing this task in a new context window. Keep: the goal, "
            "constraints the user stated, decisions made and why, files changed, failing "
            "tests and their errors, open questions, the next step. Drop raw tool output."
        ),
    }]},
)
messages.append({"role": "assistant", "content": response.content})   # keep the compaction block

Az összefoglaló eleve veszteséges. Amit az alapértelmezett prompt elhagy, az általában később üt vissza: a felhasználó harmadik körben megadott megkötése, vagy az, hogy miért vetettetek el egy megközelítést. Írj saját utasításokat a saját területedre, az utolsó néhány kört tartsd meg szó szerint, és teszteld: futtass olyan feladatokat, amelyekhez a tömörítés előtti információ kell, és ellenőrizd, hogy az ügynök még tudja-e.

Jegyzetek és memória az ablakon kívül

Az Anthropic 2025 novemberi harness-cikke egyenesen fogalmaz: "a tömörítés nem elég". Még egy több kontextusablakon át futó frontier modell is hajlamos volt egy menetben megépíteni az alkalmazást, vagy túl korán késznek nyilvánítani a projektet. A megoldást a lemezen tárolt állapot hozta. Egy inicializáló munkamenet megír egy init.sh szkriptet, egy claude-progress.txt naplót és egy kezdeti git commitot; a példaalkalmazásukhoz emellett egy több mint 200 követelményből álló funkciólistát is, mindet bukóként jelölve. Minden későbbi munkamenet elolvassa a haladási fájlt és a git-előzményeket, egy funkción halad előre lépésenként, és strukturált frissítést hagy maga után.

Ez a kiszervezés eszköze, és kódoló ügynököknél erre támaszkodom a legjobban: egy tervfájl, egy haladási napló és kis commitok olcsók, túlélnek bármilyen tömörítést vagy összeomlást, és olvashatók annak az embernek, aki a munkát átnézi. Nem fájlalapú ügynököknél a Claude memóriaeszköze (memory_20250818) eszközként adja ugyanezt a mintát: a modell a /memories alatti fájlokat olvassa és írja, az alkalmazásod pedig ezeket a műveleteket egy általad felügyelt tárolón hajtja végre. Mivel a tároló a tiéd, a kezelőnek el kell utasítania a /memories kívüli útvonalakat. Hogy mit érdemes tárolni, és hogyan előzd meg a megmérgezést, arról az MI-ügynökök memóriájának tervezéséről szóló cikk szól.

Al-ügynökök: elkülönítés, ára van

Egy al-ügynök kap egy feladatot, saját tiszta kontextusablakot és saját eszközöket. Felderítés közben akár több tízezer tokent is elhasználhat, de az Anthropic megfogalmazásában "tömör, lepárolt összefoglalót ad vissza a munkájáról (gyakran 1000-2000 tokent)". A fő ügynök ablakába csak ez az összefoglaló kerül. Keresésigényes munkánál ez a legerősebb eszköz a romlás ellen, például ha egy nagy kódbázisban "meg kell találni minden helyet, ahol áfát számolunk".

Az ár a koordináció. A Cognition "Don't Build Multi-Agents" írása amellett érvel, hogy teljes ügynök-trace-eket kell megosztani, nem egyes üzeneteket, mert a műveletek implicit döntéseket hordoznak, és azok az al-ügynökök, amelyek nem látják egymás döntéseit, ellentmondó eredményeket adnak. Az én szabályom: al-ügynököt csak olvasó felderítésre és tényeket visszaadó kutatásra; mindenhez, ami ír, egyetlen, teljes kontextussal dolgozó ügynököt. A mikor éri meg a multi-ügynökös rendszer című cikk részletesebb.

Eleve kevesebbet tölts be

A legolcsóbban kezelhető token az, amelyik be sem kerül. Az Anthropic "just in time" kontextust ír le: az ügynök könnyű azonosítókat tart meg (fájlútvonalakat, mentett lekérdezéseket, linkeket), és csak akkor tölt be adatot, amikor szükség van rá, head, tail és célzott lekérdezések segítségével, ahelyett, hogy egész objektumokat olvasna be. A többit az eszközök kialakítása végzi:

• Az eszközkimenetet alapból lapozd és csonkold, egyértelmű jelzéssel arról, hogyan lehet többet kérni.
• Összefoglalót és hivatkozást adj vissza, ne nyers adathalmazt: "143 egyező rendelés, az első 10 lent, lekérdezés-azonosító: q_17".
• A stabil utasítások legyenek rövidek és elöl, az aktuális cél és a megkötések pedig a kontextus végén, ahol a Lost in the Middle eredményei szerint a modellek a legjobban figyelnek.
• Visszakeresés a teletömés helyett. A hosszú kontextus és a keresés közötti mérlegelést a RAG 2026-ban című cikk tárgyalja; kódoló ügynököknél a tokentakarékos eszközökről szóló cikk bizonyítékok alapján rangsorolja a lehetőségeket.

Mérd a saját ügynöködben

A kontextusromlás a saját terhelésed tulajdonsága, ezért ott mérd. Három olcsó jel:

1. Naplózd a körönkénti bemeneti tokeneket a trace-ekben, és ábrázold a feladatsikert annak a kontextusméretnek a függvényében, amelynél az adott feladat véget ért. Ha a felső tartományokban esik a siker, túl magas a küszöböd.
2. Ültess el korán egy megkötést, és teszteld későn. Egy eval feladat, amely az első körben kimond egy szabályt ("a fizetési modulhoz soha ne nyúlj"), és egy tömörítés után van rá szükség, megmutatja, hogy az összefoglalód megtartja-e a lényeget.
3. Hasonlítsd össze egy friss munkamenettel. A sikertelen késői lépéseket futtasd újra egy új munkamenetben, amely csak a jegyzeteket és a haladási fájlt kapja meg. Ha ott sikerül, a probléma a kontextus volt, nem a modell.

Ezek az ellenőrzések közvetlenül beilleszthetők a meglévő trajektória-evalokba és trace-ekbe; az ügynök-observability OpenTelemetryvel című cikk megmutatja, hogyan rögzítsd a tokenszámokat spanonként.

Ellenőrzőlista

1. A kontextusablakot pontossági keretként kezeld, ne tárolási korlátként.
2. Lapozd és csonkold az eszközkimeneteket; hivatkozásokat és összefoglalókat adj vissza.
3. Először a régi eszközeredményeket töröld, kivételt téve a drágán újra előállítható eredményekkel.
4. Területspecifikus utasításokkal tömöríts, a legutóbbi köröket tartsd meg szó szerint, és a teljes választ fűzd hozzá, hogy a compaction blokk megmaradjon.
5. A terveket, a haladást és a döntéseket lemezen vagy memóriatárban tartsd, amelyet az ügynök minden munkamenet elején elolvas.
6. Al-ügynököt rövid összefoglalót visszaadó, olvasó felderítésre használj; az írást hagyd egyetlen, teljes kontextusú ügynöknél.
7. Az aktuális célt és a megkötéseket tedd a kontextus végére.
8. Mérd a sikert a kontextusméret függvényében, és teszteld, hogy a korai megkötések túlélik-e a tömörítést.

Ha az ügynökeid hosszú feladatoknál leromlanak, és második véleményt szeretnél a harnessről, nézd meg az AI engineering oldalt.

Források

1. Chroma: Context Rot: How Increasing Input Tokens Impacts LLM Performance (Jul 2025)
2. Liu et al.: Lost in the Middle: How Language Models Use Long Contexts (2023)
3. Modarressi et al.: NoLiMa: Long-Context Evaluation Beyond Literal Matching (2025)
4. Anthropic: Effective context engineering for AI agents (Sep 2025)
5. Anthropic: Effective harnesses for long-running agents (Nov 2025)
6. Claude API docs: Compaction at a token threshold
7. Claude API docs: Compaction on demand
8. Claude API docs: Context editing
9. Claude API docs: Memory tool
10. OpenAI API docs: Compaction
11. Cognition: Don't Build Multi-Agents