Kontextustervezés hosszú távú AI-ügynökökhöz

Együtt nézve az Arize elemzése, a kontextusablak-túlcsordulásról szóló arXiv-tanulmány, a Redis éles környezetre szánt magyarázó anyaga és az Atlan harness-engineering összehasonlítása gyakorlati fordulatot jelez az ügynöktervezésben. A hosszú ideig futó ügynököket egyre kevésbé a modell kontextusablakának mérete alapján ítélik meg, és egyre inkább az azt körülvevő vezérlőréteg alapján. Az Arize ezt a fordulatot kézzelfoghatóvá teszi. Megnevez kiadott ügynöki eszközöket és memória-/harness-rendszereket, köztük a Pi-t, az OpenClaw-t, a Claude Code-ot és a Lettát, mint a harness-szintű kontextustervezés példáit, és leír egy interaktív szimulátort, amely megmutatja, hogyan telik meg egy 200K tokenes ablak.

Az idézett forrásokban elérhető nyilvános részletek egyenetlenek. Az Arize konkrét implementációs számokat ad a Pi, az OpenClaw, a Claude Code és a Letta esetében. Egy kutatási tanulmány az AI-ügynökök kontextusablak-túlcsordulásának megoldásáról általánosabb mechanizmust ad olyan eszközkimenetek kezelésére, amelyek bármely gyakorlati ablakot meghaladhatnak. A Redis kontextusablak-túlcsordulásról szóló magyarázója összefoglalja az éles rendszerekben jelentkező tüneteket: kemény API-hibák, csendes minőségromlás, eszközkimenetek felhalmozódása és hosszabb késleltetés a promptok növekedésével. Az Atlan prompt-, kontextus- és harness-engineeringről szóló összehasonlítása hasznos rétegmetaforát ad: a prompt engineering az üzenetet formálja, a kontextustervezés azt, amit a modell lát, a harness engineering pedig a teljes ügynökkörnyezetet.

A fontos hír nem az, hogy a kontextusablakok túl kicsik. Az építők ezt már tudják. Hasznosabb megállapítás, hogy az idézett ügynökrendszerek négy harness-mechanizmus felé konvergálnak, amelyek életben tartják a munkát azután is, hogy az átirat már nem biztonságos igazságforrás.

Egy felszínes ügynök fájlokat olvas, eszközöket hív, hozzáfűzi az eredményt, és reméli, hogy a modell megbirkózik vele. Egy harness-first ügynök blokkolja vagy átformálja a nagy bemeneteket, mielőtt azok elérnék a modellt.

Az első korlátkészlet tisztább olvasata:

• Pi: a fájlolvasások 2.000 sornál vagy 50KB-nál állnak meg, attól függően, melyik jön előbb. A visszaadott tartalom tartalmaz egy folytatási tippet, amely megmondja a modellnek, melyik sortartomány jelent meg, és hogyan folytathatja a offset és limit használatával. Az OpenClaw örökli ezt a viselkedést, majd külön korlátokat ad hozzá: a bootstrap fájlok fájlonként 12.000 karakterre, összesen 60.000 karakterre vannak korlátozva. Az eszközeredmények újabb keretet kapnak: 16.000 karaktert vagy a kontextusablak 30%-át, attól függően, melyik kisebb.

A Claude Code kétkapus kialakítást használ. Az Arize szerint fájl megnyitása előtt ellenőriz egy 256KB-os byte-korlátot, majd az olvasás után a 25.000 tokenes kerethez viszonyítva tokenekben számolja meg az eredményt. Még a korlát alatti fájloknál is alapértelmezés szerint az elejétől számított 2.000 sort adja vissza, és levágja a 2.000 karakternél hosszabb sorokat. Ha a modell újraolvassa ugyanazt a fájltartományt, és a fájl nem változott, a Claude Code a teljes tartalom megismétlése helyett egy stubot is visszaadhat.

Ez nem puszta optimalizálás. Megváltoztatja a hibamódot. Ahelyett, hogy egyetlen nagy olvasás kiszorítaná a feladatot, a harness a „mindent olvass el” utasítást „olvass el egy kontrollált szeletet” műveletté alakítja. Ha a modellnek többre van szüksége, kérheti. Azoknak az építőknek, akik nulláról terveznek ügynökharness-eket, ez az első védelmi vonal: soha ne engedd, hogy a nyers külső adat alapértelmezés szerint maga legyen az átirat.

A következő minta az, hogy a kontextust nézetablakként kezeljük, nem tárhelyként.

A Pi és a Claude Code lapozást tesz elérhetővé a offset és limit segítségével. Az OpenClaw bizonyos helyeken head/tail csonkolást ad hozzá, megtartva az elejét és a végét, amikor a közepe valószínűleg kevésbé számít. Az Arize szerint az OpenClaw a túlméretes bootstrap fájloknál 75% head / 25% tail felosztást használ, és az eszközeredményeknél is megtarthatja a headet és a tailt, ha a tail fontosnak tűnik, például hibák, záró JSON kapcsos zárójelek vagy összegzésszerű kulcsszavak esetén.

A Letta tovább megy azzal, hogy a fájlokat a prompton kívül tartja. A feltöltött fájlokat feldolgozza, darabolja és beágyazza egy vektortárba, így az ügynök közvetlen megtekintést, pontos keresést és szemantikus keresést kap. Amikor egy fájl nyitva van a kontextusban, a Letta kezelt nézetet mutat, amelynek mérete a modell kontextusával skálázódik: 5.000 karakter 8K kontextusnál, 15.000 32K-nál, 25.000 128K-nál és 40.000 200K+ esetén. Az egyszerre megnyitható fájlok száma is skálázódik, kis modelleknél 3-tól nagyon nagy modelleknél 15-ig, LRU-szabállyal kidobva a legrégebben elért fájlokat.

Ugyanez a tervezési gondolat áll az éles RAG mögött is: ne tömd az egész korpuszt a promptba; keresd vissza azt a részt, amely számít. A különbség az, hogy az ügynökharness-eknek ezt folyamatosan kell csinálniuk, fájlokon, eszközkimeneteken, memórián és köztes terveken át. Ugyanez a korlát vonatkozik a RAG-rendszerekre is: a visszakeresés nemcsak a relevanciáról szól, hanem arról is, hogy elegendő kontextuskeretet őrizzünk meg a tényleges következtetési lépéshez.

A Redis kapcsolódó megállapítást tesz: a nagyobb kontextusablakok nem szüntetik meg a kontextuskezelés szükségességét. A rendszerpromptok, a visszakeresett dokumentumok, a beszélgetési előzmények és az eszközkimenetek mind ugyanazért a helyért versenyeznek. Még mielőtt elérnénk egy kemény korlátot, a modellek teljesítménye romolhat, ahogy a releváns információk eltemetődnek a hosszú bemenetekben.

A túlcsordulás a nyilvánvaló hiba. A célvesztés csendesebb. Az ügynöknek még van helye válaszolni, de elfelejti az eredeti célt, kihagy egy megkötést, vagy elkezd egy lokális részfeladatra optimalizálni.

Itt számít a tömörítés. Rosszul végrehajtva az összegzés a kusza, de hű előzményt egy rendezett, de veszteséges történettel váltja fel. Jól végrehajtva megőrzi a feladat állapotát, a friss munkát, a függőben lévő elemeket és az eszközhívások integritását.

Az Arize beszámolója szerint a Pi akkor indít tömörítést, amikor a becsült kontextustokenek száma meghaladja a kontextusablak mínusz tartaléktokenek értékét, alapértelmezés szerint 16.384 tokenes tartalékkal. Megtartja a legutóbbi nagyjából 20.000 tokent, a régebbi tartalmat pedig szintetikus felhasználói üzenetté összegzi, amelyet a megtartott tail elé illeszt. Emellett kerüli az eszközhívás/eszközeredmény párok átvágását.

Az OpenClaw agresszívebb előzménypolitikát ad hozzá. Amikor az előzmények meghaladják a kontextusablak 50%-át, az üzeneteket azonos token-tömegű darabokra osztja, eldobja a legrégebbi darabot, a kidobott tartalmat lépcsőzetes, többmenetes összegzéssel tömöríti, és kijavítja az eszközhívás/eredmény párosításokat. Előtömörítési flush-t is végez: egy csendes agentic kör lehetőséget ad az ügynöknek, hogy az állapotot memóriafájlokba mentse, mielőtt az előzmények eltűnnek. Külön, a memóriában lévő eszközeredményeket is metszi soft-trim és hard-clear viselkedéssel, 5 perces cache TTL mellett.

A Claude Code az ablak vége közelében tömörít. Az Arize szerint a kiváltó feltétel az effektív kontextusablak mínusz egy 13.000 tokenes puffer, ami egy 200K kontextusú modellnél körülbelül 167K tokennél indít tömörítést. Az összegző prompt strukturált szakaszokat kér, amelyek lefedik az elsődleges kérést, a technikai fogalmakat, a fájlokat és kódot, a hibákat és javításokat, a problémamegoldást, a felhasználói üzeneteket, a függőben lévő feladatokat, az aktuális munkát és a következő lépést. Tömörítés után legfeljebb 5 nemrég olvasott fájlt tud újracsatolni tokenkereten belül.

A minta világos: a tömörítés nem „a chat összefoglalása”. Ez checkpointolás. Egy hosszú ideig futó ügynöknek egy mentési fájl megfelelőjére van szüksége: célra, megkötésekre, döntésekre, nyitott handle-ökre, friss bizonyítékokra és a következő műveletre.

Bizonyos kimeneteket egyáltalán nem szabad a kontextusablakba helyezni.

Az arXiv-tanulmány ezt egy anyagtudományi munkafolyamattal teszi konkréttá. Az egyik eszköz elektronikus rácsszerkezetet generál egy molekulához: egy 128 × 128 × 128 méretű 3D mátrixot, összesen 2.097.152 float32 elemmel. Ez a kimenet messze meghaladja a széles körben használt LLM-ek kontextusablakát. A következő eszköznek viszont szüksége van a rácsra bemenetként.

A javasolt megoldás az, hogy a nagy értékeket a modellkontextuson kívül tároljuk, és rövid azonosítókat, vagyis mutatókat adunk vissza. Az eszközburkolók megvizsgálják a bemeneteket, hogy nyers értékekről vagy memóriaútvonalakról van-e szó. A túl nagy kimeneteket futásidejű memóriában, egy útvonal alatt tárolják, a későbbi eszközök pedig megkaphatják a mutatót, és belsőleg feloldhatják. A modell hivatkozásokat kezel, miközben a harness megőrzi a teljes adatot. Egy összehasonlító kísérletben, ahol mindkét módszer sikeres volt, a tanulmány szerint a mutatóalapú megközelítés nagyjából hétszer kevesebb tokent használt, mint a hagyományos munkafolyamat.

Ez a legtisztább elválasztás a következtetés és az adatmozgatás között. A modellnek nem kell „látnia” egy 2 millió elemes mátrixot ahhoz, hogy továbbadja egy másik eszköznek. Azt kell tudnia, hogy a mátrix létezik, mit képvisel, és melyik műveletnek kell legközelebb felhasználnia.

Ugyanez a logika a tudományos tömbökön túl is érvényes. A nagy JSON-válaszok, PDF-ek, naplók, embeddingek, médiafájlok és adatbázis-exportok gyakran tárhelyre valók, nem a promptba. Az MCP-eszközökre vagy egyedi API-connectorokra épülő rendszereknél a mutatók továbbításának elsőrangú tervezési döntésnek kell lennie, nem az első túlcsordulás utáni foltnak.

Egy 200K tokenes kontextusablak nagynak tűnik, amíg egy ügynök el nem kezd cselekedni. Egy rendszerprompt, eszközdefiníciók, néhány visszakeresett dokumentum, fájlolvasások, naplók, hibanyomok és összegzések a vártnál gyorsabban elfogyaszthatják. A gyakorlati keret nem az, mekkorának látszik az ablak papíron, hanem az, milyen gyorsan költik el az ügynökök futásidőben. A Redis ügynökmemóriára vonatkozó útmutatása külső, tartós memória felé mutat olyan állapotokhoz, amelyeknek hívások között is fenn kell maradniuk, míg az Atlan kontextustervezési kerete elválasztja a jobb promptokat a jobb kontextus-összeállítástól. Együtt a kontextusablakot kevésbé raktárként, inkább korlátozott munkakészletként kezelik.

A mélyebb tanulság az, hogy a kontextusablak szűkös futásidejű erőforrás. Hasznos „memóriaként” kezelni, de csak akkor, ha a harness operációs rendszerként viselkedik: allokál, kilakoltat, lapoz, tömörít, deduplikál és perzisztál. Az Atlan rétegkülönbsége itt hasznos. A prompt engineering nem tud megjavítani egy fájlolvasót, amely 80.000 irreleváns tokent zúdít a következő hívásba. A kontextustervezés javíthatja a munkakészletet. A harness engineering dönti el, hogy ez a munkakészlet eleve védve van-e.

Ez azt is megváltoztatja, hogyan kell a csapatoknak értékelniük az ügynököket. Egy demóprompt nem elég. A hosszú távú értékelésnek tartalmaznia kell növekvő átiratokat, ismételt fájlolvasásokat, nagy eszközkimeneteket, sikertelen eszközhívásokat, tömörítés utáni folytatásokat, valamint olyan feladatokat, ahol a helyes következő lépés egy korai megkötéstől függ. Az ügynökök kontextustervezéséről szóló útmutatónk a probléma modelloldali változatát tárgyalja; a harness-rétegben válik mindez működési kérdéssé.

Először is tegyél kereteket minden kontextusforrásra. A fájloknak, eszközkimeneteknek, visszakeresett daraboknak, memória-beszúrásoknak és beszélgetési előzményeknek egyaránt explicit korlátokkal kell rendelkezniük. Egyetlen globális maximális tokenszám túl durva eszköz.

Másodszor, tedd a csonkolást cselekvésre alkalmassá. Ha a harness levág tartalmat, a modellnek tudnia kell, melyik tartományt látta, és hogyan kérhet többet. A csendes csonkolás rosszabb, mint az elutasítás, mert magabiztos munkát eredményez hiányzó adatok alapján.

Harmadszor, állapot köré tömöríts, ne próza köré. Az összegzéseknek meg kell őrizniük a felhasználó célját, a megkötéseket, döntéseket, függőben lévő feladatokat, érintett fájlokat, a fontos eszközeredményeket és a közvetlen következő lépést. Az eszközhíváspároknak egyben kell maradniuk.

Negyedszer, vidd ki a nagy értékeket a promptból. Tárold őket, nevezd el őket, és adj át mutatókat az eszközök között. Ez különösen fontos azoknál az ügynököknél, amelyek API-kat hívnak, dokumentumokat dolgoznak fel, vagy többügynökös rendszereket koordinálnak.

Végül külön teszteld a célvesztést a túlcsordulástól. Egy ügynök maradhat a kemény ablak alatt, és mégis elsodródhat. A helyes kérdés nem csak az, hogy „elfogadta-e az API a promptot?” Hanem az is: „a következő művelet még mindig az eredeti feladatot szolgálja?”

Az alábbi összegzés ezeket a mintákat alakítja gyors ellenőrzőlistává a GYIK előtt.

• A hosszú távú ügynökök kontextustúlcsorduláson és célvesztésen keresztül is kudarcot vallanak, ezért a harnessnek nemcsak a prompt hosszát kell kezelnie.
• Az éles ügynökrendszerek kemény kereteket használnak fájlokra, eszközkimenetekre és előzményekre, mielőtt a nyers adat elérné a modellt.
• A lapozás, keresés és kezelt nézetek a kontextust korlátozott nézetablakként kezelik, nem állandó tárhelyként.
• A tömörítés checkpointolásként működik a legjobban: megőrzi a célokat, megkötéseket, döntéseket, függő munkát és az eszközhívások integritását.
• A nagy eszközkimenetek gyakran külső tárhelyre valók, rövid mutatókkal továbbadva az eszközök között, nem teljes értékként a promptban.

Ez a szakasz a hosszú távú ügynökök kontextustervezése mögötti gyakorlati kérdésekre válaszol: mi csordul túl, hogyan vesznek el a célok, és mely harness-minták tartják pályán a munkát.

Kontextustúlcsordulás akkor történik, amikor egy ügynök felhalmozott promptja, előzményei, visszakeresett adatai, fájljai és eszközkimenetei meghaladják a modell használható kontextusablakát, vagy már a kemény korlát elérése előtt rontják a minőséget.

Célvesztés akkor történik, amikor az eredeti feladat még valahol jelen van az átiratban, de már nem irányítja az ügynök következő műveletét, gyakran hosszú előzmények vagy gyenge összegzés után.

Forrásonkénti kereteket állítanak be, lapozzák a fájlolvasásokat, csak releváns nézeteket keresnek vissza, az előzményeket állapot köré tömörítik, deduplikálják az ismételt olvasásokat, és a nagy kimeneteket a prompton kívül tárolják.

A mutatók lehetővé teszik, hogy a modell futásidejű memóriában tárolt nagy értékekre hivatkozzon, például mátrixokra, naplókra vagy PDF-ekre, miközben a downstream eszközök feloldják a teljes adatot anélkül, hogy az bekerülne a kontextusablakba.

Nem. A nagyobb ablakok segítenek, de a rendszerpromptok, eszközdefiníciók, visszakeresett dokumentumok, naplók és előzmények továbbra is ugyanazért a helyért versenyeznek, és a releváns információk már a kemény korlát elérése előtt eltemetődhetnek.