> Miért romlik az LLM pontossága a kontextus növekedésével, és hogyan tartja pályán a hosszú ügynökfutást a törlés, a tömörítés, a jegyzet és az al-ügynök.
>
> Web page: https://balazscsorba.com/hu/blog/context-rot-compaction-long-running-agents · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/context-rot-compaction-long-running-agents.md) · [Deutsch](https://balazscsorba.com/de/blog/context-rot-compaction-long-running-agents.md)
> Author: Balázs Csorba · Published: 2026-10-16 · Keywords: context rot, context rot LLM, compaction AI agents, context engineering, long-running agents context window, Claude compaction API, context editing clear tool results, OpenAI responses compaction, lost in the middle LLM, agent context management, sub-agents context isolation

[Blog](https://balazscsorba.com/hu/blog)/MI-ágensek

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

Miért romlik az LLM pontossága a kontextus növekedésével, és hogyan tartja pályán a hosszú ügynökfutást a törlés, a tömörítés, a jegyzet és az al-ügynök.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 16.·10 perc olvasás

-   Context rot
-   Compaction
-   Context engineering
-   Long-running agents
-   Agent memory

![Egy ügynök kontextusmérete a körökkel nő, de a régi eszközeredmények törlése és a tömörítés egy sávban tartja, ahelyett, hogy az ablakhatárig nőne.](https://balazscsorba.com/images/blog/context-rot-compaction-long-running-agents/cover.webp?v=eed9d8fcac)

## A lényeg röviden

-   A kontextusromlás a pontosság csökkenése a bemenet növekedésével: a NoLiMán 13 hosszú kontextusú modellből 11 a rövid kontextusú alapszintje felére sem jutott 32K tokennél.
-   Az ügynököket érinti leginkább, mert a hurok minden eszközhívást és eredményt hozzáfűz, és elavult, zavaró tartalommal tölti meg az ablakot.
-   Először a régi eszközeredményeket töröld; a Claude kontextusszerkesztése ezt szabály alapján végzi, a clear\_at\_least pedig gondoskodik róla, hogy megérje a gyorsítótár újraírása.
-   A tömörítés a Claude-nál és az OpenAI-nál szerveroldalon foglalja össze a régebbi köröket, de veszteséges, ezért írj területspecifikus utasításokat, és a legutóbbi köröket tartsd meg szó szerint.
-   A tervek, a haladási fájlok és a git túlélnek bármilyen tömörítést; al-ügynököt olvasó felderítésre használj, az írást pedig hagyd egyetlen, teljes kontextusú ügynöknél.

Ezen az oldalon

1.  [Mit mutat a kutatás](https://balazscsorba.com/#what-is-context-rot)
2.  [Miért az ügynököket érinti leginkább](https://balazscsorba.com/#why-agents-rot-faster)
3.  [Négy eszköz: törlés, tömörítés, kiszervezés, elkülönítés](https://balazscsorba.com/#four-levers)
4.  [Régi eszközeredmények törlése](https://balazscsorba.com/#clear-tool-results)
5.  [Tömörítés: összefoglalás és folytatás](https://balazscsorba.com/#compaction)
6.  [Jegyzetek és memória az ablakon kívül](https://balazscsorba.com/#notes-and-memory)
7.  [Al-ügynökök: elkülönítés, ára van](https://balazscsorba.com/#sub-agents)
8.  [Eleve kevesebbet tölts be](https://balazscsorba.com/#just-in-time-context)
9.  [Mérd a saját ügynöködben](https://balazscsorba.com/#measuring-context-rot)
10.  [Ellenőrzőlista](https://balazscsorba.com/#checklist)
11.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

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:

Tanulmány

Felállás

Eredmény

**Lost in the Middle** (Liu és tsai., 2023)

Több dokumentumos kérdés-válasz és kulcs-érték visszakeresés, a releváns elem különböző pozíciókban

A pontosság akkor a legnagyobb, ha a releváns információ az elején vagy a végén van, középen jelentősen romlik, még hosszú kontextusú modelleknél is

**NoLiMa** (Modarressi és tsai., ICML 2025)

Tű a szénakazalban, ahol a kérdés és a tű alig osztozik szavakon; 13 modell, legalább 128K kontextus ígérettel

32K tokennél 13 modellből 11 a rövid kontextusú alapszintje 50%-a alá esett; a GPT-4o 99,3%-ról 69,7%-ra

**Context Rot** (Chroma, 2025. július)

18 modell, köztük GPT-4.1, Claude 4, Gemini 2.5 és Qwen3, kontrollált egyszerű feladatokon

A teljesítmény a bemenet növekedésével egyre megbízhatatlanabb; a LongMemEvalon minden modell jelentősen jobb volt a fókuszált, ~300 tokenes promptokkal, mint a teljes, ~113K tokenes promptokkal

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](https://balazscsorba.com/hu/blog/agent-loop-explained) 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](https://balazscsorba.com/hu/blog/llm-cost-latency-prompt-caching-routing) 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

Eszköz

Mit csinál

Mi vész el

Mikor nyúlj hozzá

tagchildren

Szabály alapján eltávolítja a régi eszközeredményeket (opcionálisan a bemeneteket vagy a thinkinget is)

A nyers kimenet, amelyet az ügynök általában újra le tud kérni

Az eszközkimenetek uralják a kontextust; első és legolcsóbb lépés

tagchildren

A régebbi köröket a modell által írt összefoglalóra cseréli

A részletek, amelyeket az összefoglaló nem őrzött meg

Hosszú oda-vissza, amelynek egy beszélgetésnek kell maradnia

tagchildren

Az ügynök jegyzeteket, terveket és haladási naplót ír fájlba vagy memóriatárba

Semmi, ha az ügynök vissza is olvassa őket

Több munkamenetes munka világos mérföldkövekkel

tagchildren

Egy al-ügynök a saját ablakában kutat, és rövid összefoglalót ad vissza

Az al-ügynök gondolatmenete; a koordináció nehezebb

Széles keresés vagy kutatás, amely elárasztaná a fő ablakot

Szemléltető ábra, nem mérés: a törlés lassítja a növekedést, a tömörítés egy sávban tartja a kontextust. Mindkettő célja, hogy ott maradj, ahol a modell pontos, ne csak a határ alatt.

## 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
```

**A teljes választ fűzd hozzá**

A compaction blokk a válasz tartalmában van. Ha a ciklusod csak a válasz szövegét fűzi hozzá, a tömörítés állapota csendben elvész, és a következő kérés ismét a teljes előzményt küldi. A költséget is számold: a tömörítés egy extra mintavételi lépés, amely külön bejegyzésként jelenik meg a usage iterációkban, és beleszámít a rate limitbe.

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](https://balazscsorba.com/hu/blog/ai-agent-memory-design) 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](https://balazscsorba.com/hu/blog/multi-agent-systems-when-worth-it) 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](https://balazscsorba.com/hu/blog/rag-2026-hybrid-agentic-long-context) című cikk tárgyalja; kódoló ügynököknél a [tokentakarékos eszközökről](https://balazscsorba.com/hu/blog/token-saving-tools-coding-agents-top-20) 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](https://balazscsorba.com/hu/blog/agent-observability-opentelemetry) 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](https://balazscsorba.com/hu/expertise/ai-engineer) oldalt.

## Források

1.  [Chroma: Context Rot: How Increasing Input Tokens Impacts LLM Performance (Jul 2025)](https://research.trychroma.com/context-rot)
2.  [Liu et al.: Lost in the Middle: How Language Models Use Long Contexts (2023)](https://arxiv.org/abs/2307.03172)
3.  [Modarressi et al.: NoLiMa: Long-Context Evaluation Beyond Literal Matching (2025)](https://arxiv.org/abs/2502.05167)
4.  [Anthropic: Effective context engineering for AI agents (Sep 2025)](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
5.  [Anthropic: Effective harnesses for long-running agents (Nov 2025)](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)
6.  [Claude API docs: Compaction at a token threshold](https://platform.claude.com/docs/en/build-with-claude/compaction-threshold)
7.  [Claude API docs: Compaction on demand](https://platform.claude.com/docs/en/build-with-claude/compaction-on-demand)
8.  [Claude API docs: Context editing](https://platform.claude.com/docs/en/build-with-claude/context-editing)
9.  [Claude API docs: Memory tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool)
10.  [OpenAI API docs: Compaction](https://platform.openai.com/docs/guides/compaction)
11.  [Cognition: Don't Build Multi-Agents](https://cognition.ai/blog/dont-build-multi-agents)

## Gyakori kérdések

Mi a kontextusromlás (context rot)?

A kontextusromlá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. Az olyan tanulmányok, mint a Lost in the Middle, a NoLiMa és a Chroma Context Rot jelentése, azt mutatják, hogy a modellek egyenetlenül használják a hosszú bemenetet, és a lényegtelen vagy zavaró tartalom felhalmozódásával egyre megbízhatatlanabbak lesznek.

Mi a tömörítés (compaction) az MI-ügynököknél?

A tömörítés a beszélgetés régebbi részét a modell által írt összefoglalóra cseréli, és onnan folytatja, így egy hosszú feladat kisebb, fókuszáltabb kontextusba fér. A Claude API tokenküszöbnél vagy igény szerint kínálja, az OpenAI Responses API pedig tömörítési küszöbbel vagy önálló compact végponttal.

Elég a tömörítés ahhoz, hogy egy hosszan futó ügynök pályán maradjon?

Önmagában általában nem. Az Anthropic szerint az ügynökök tömörítéssel is hajlamosak voltak egyszerre túl sokat vállalni, vagy túl korán késznek nyilvánítani a munkát. Egy elmentett terv, egy haladási napló, egy funkciólista és git commitok, amelyeket minden munkamenet elején elolvasnak, tették koherenssé a hosszú futásokat.

Mi a különbség a kontextusszerkesztés és a tömörítés között?

A kontextusszerkesztés szabály alapján távolít el bizonyos tartalmakat, például régi eszközeredményeket vagy thinking blokkokat, összefoglalás nélkül. A tömörítés a régebbi köröket egy rövidebb blokkba foglalja össze. A törlés olcsóbb és biztonságosabb; a tömörítés többet megőriz a beszélgetés értelméből, de elveszíti azokat a részleteket, amelyeket az összefoglaló nem rögzít.

Használjak al-ügynököket a kontextusromlás ellen?

Olvasó felderítésre igen: egy al-ügynök a saját ablakában kereshet, és nagyjából 1000-2000 tokenes összefoglalót adhat vissza. Olyan munkához, amely ír vagy változtat, maradj egyetlen, teljes kontextusú ügynöknél, mert az egymás döntéseit nem látó al-ügynökök gyakran ellentmondó eredményeket adnak.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Böngészőágensek E2E-teszteléshez: írják az ágensek a Playwright-teszteket, ne futtassák](https://balazscsorba.com/hu/blog/browser-agents-e2e-testing-playwright)
-   [Az A2A protokoll: agent cardok, taskok, és a helye az MCP mellett](https://balazscsorba.com/hu/blog/a2a-protocol-agent-interoperability)
-   [Egy senior MI-ügynökökkel vagy egy csapattal: mit mondanak a bizonyítékok](https://balazscsorba.com/hu/blog/ai-assisted-development-economics)
-   [Spec-driven fejlesztés kódoló ügynököknek: a terv a kód előtt](https://balazscsorba.com/hu/blog/spec-driven-development-coding-agents)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)