Kontekstisuunnittelu pitkän aikavälin AI-agenteille

Yhdessä Arizen analyysi, arXiv-julkaisu konteksti-ikkunan ylivuodosta, Redisin tuotantoympäristöjen selitys ja Atlanin ohjauskehysten suunnittelua koskeva vertailu osoittavat käytännön muutokseen agenttisuunnittelussa. Pitkäkestoisia agentteja arvioidaan yhä vähemmän mallin konteksti-ikkunan koon ja yhä enemmän sitä ympäröivän ohjauskerroksen perusteella. Arize tekee muutoksesta konkreettisen. Se nimeää julkaistuja agenttityökaluja ja muisti-/ohjauskehysjärjestelmiä, kuten Pi, OpenClaw, Claude Code ja Letta, esimerkkeinä ohjauskehystason kontekstisuunnittelusta, ja kuvaa interaktiivista simulaattoria, joka näyttää 200K-tokenin ikkunan täyttymisen.

Viitatuissa lähteissä saatavilla olevat julkiset yksityiskohdat ovat epätasaisia. Arize antaa konkreettisia toteutuslukuja Pi:lle, OpenClaw’lle, Claude Code’lle ja Letta’lle. Tutkimusjulkaisu konteksti-ikkunan ylivuodon ratkaisemisesta AI-agenteissa antaa yleisemmän mekanismin sellaisten työkalutulosteiden käsittelyyn, jotka voivat ylittää minkä tahansa käytännöllisen ikkunan. Redisin selitys konteksti-ikkunan ylivuodosta tiivistää tuotantoympäristöjen oireet: kovat API-virheet, hiljainen laadun heikkeneminen, työkalutulosteiden kertyminen ja pidempi viive promptien kasvaessa. Atlanin vertailu prompt-, konteksti- ja ohjauskehityksestä tarjoaa hyödyllisen pinometaforan: prompt-suunnittelu muotoilee viestin, kontekstisuunnittelu muotoilee sen, mitä malli näkee, ja ohjauskehityssuunnittelu muotoilee koko agenttiympäristön.

Tärkeä uutinen ei ole se, että konteksti-ikkunat ovat liian pieniä. Rakentajat tietävät sen jo. Hyödyllisempi havainto on, että viitatut agenttijärjestelmät lähentyvät neljään ohjauskehysmekanismiin, jotka pitävät työn hengissä sen jälkeen, kun litterointi lakkaa olemasta turvallinen totuuden lähde.

Pinnallinen agentti lukee tiedostoja, kutsuu työkaluja, liittää tuloksen perään ja toivoo, että malli selviää. Ohjauskehys edellä rakennettu agentti estää tai muotoilee suuret syötteet uudelleen ennen kuin ne päätyvät mallille.

Selkeämpi tapa lukea ensimmäinen rajoitusjoukko on:

• Pi: tiedostojen luku pysähtyy 2 000 riviin tai 50KB:hen sen mukaan, kumpi tulee ensin vastaan. Palautettu sisältö sisältää jatkovihjeen, joka kertoo mallille, mikä rivialue näytettiin ja miten jatkaa komennoilla offset ja limit. OpenClaw perii tämän käyttäytymisen ja lisää sitten erilliset katot: bootstrap-tiedostot rajoitetaan 12 000 merkkiin per tiedosto ja 60 000 merkkiin yhteensä. Työkalutulokset saavat vielä oman budjettinsa: 16 000 merkkiä tai 30% konteksti-ikkunasta sen mukaan, kumpi on pienempi.

Claude Code käyttää kahden portin mallia. Arizen mukaan se tarkistaa 256KB:n tavukaton ennen tiedoston avaamista ja laskee sitten tuloksen tokenit 25 000 tokenin budjettia vasten lukemisen jälkeen. Jopa katon alle jäävissä tiedostoissa se palauttaa oletuksena 2 000 riviä alusta ja katkaisee yli 2 000 merkin pituiset rivit. Jos malli lukee saman tiedostoalueen uudelleen eikä tiedosto ole muuttunut, Claude Code voi palauttaa tyngän koko sisällön toistamisen sijaan.

Tämä ei ole pelkkää optimointia. Se muuttaa epäonnistumistapaa. Sen sijaan että yksi suuri luku syrjäyttäisi tehtävän, ohjauskehys muuttaa “lue kaikki” -pyynnön muotoon “lue hallittu siivu”. Jos malli tarvitsee lisää, se voi pyytää sitä. Rakentajille, jotka suunnittelevat agenttien ohjauskehyksiä alusta asti, tämä on ensimmäinen puolustuslinja: älä koskaan anna raakamuotoisen ulkoisen datan muuttua oletuksena litteroinniksi.

Seuraava kaava on käsitellä kontekstia näkymäalueena, ei tallennustilana.

Pi ja Claude Code tarjoavat sivutuksen komentojen offset ja limit kautta. OpenClaw lisää joissakin kohdissa alun/lopun katkaisun ja säilyttää alun ja lopun silloin, kun keskiosalla on epätodennäköisemmin merkitystä. Arizen mukaan OpenClaw käyttää liian suurille bootstrap-tiedostoille 75% alku / 25% loppu -jakoa ja voi säilyttää työkalutuloksista sekä alun että lopun, kun loppu näyttää tärkeältä, kuten virheiden, sulkevien JSON-aaltosulkeiden tai yhteenvetomaisilta vaikuttavien avainsanojen kohdalla.

Letta menee pidemmälle pitämällä tiedostot promptin ulkopuolella. Ladatut tiedostot jäsennetään, pilkotaan ja upotetaan vektoritietokantaan, jolloin agentti saa suoran katselun, tarkan haun ja semanttisen haun. Kun tiedosto on auki kontekstissa, Letta näyttää hallitun näkymän, jonka koko skaalautuu mallin kontekstin mukaan: 5 000 merkkiä 8K-kontekstille, 15 000 32K:lle, 25 000 128K:lle ja 40 000 200K+:lle. Myös samanaikaisesti avoinna olevien tiedostojen määrä skaalautuu: pienillä malleilla 3:sta erittäin suurilla jopa 15:een, ja LRU-käytäntö poistaa vähiten äskettäin käytetyt tiedostot.

Tämä on sama suunnitteluidea kuin tuotantokäytön RAG:n taustalla: älä tunge koko korpusta promptiin, vaan hae olennainen osa. Ero on siinä, että agenttien ohjauskehysten on tehtävä sitä jatkuvasti tiedostojen, työkalutulosteiden, muistin ja välisuunnitelmien yli. Sama rajoite koskee RAG-järjestelmiä: haku ei ole vain relevanssia, vaan myös riittävän kontekstibudjetin säilyttämistä varsinaiseen päättelyvaiheeseen.

Redis tekee aiheeseen liittyvän huomion: suuremmat konteksti-ikkunat eivät poista kontekstinhallinnan tarvetta. Järjestelmäpromptit, haetut dokumentit, keskusteluhistoria ja työkalutulosteet kilpailevat kaikki samasta tilasta. Jo ennen kovan rajan täyttymistä mallien suoritus voi heikentyä, kun olennainen tieto hautautuu pitkiin syötteisiin.

Ylivuoto on ilmeinen epäonnistuminen. Tavoitteen katoaminen on hiljaisempaa. Agentilla on yhä tilaa vastata, mutta se unohtaa alkuperäisen tavoitteen, ohittaa rajoitteen tai alkaa optimoida paikallista alitehtävää.

Siksi tiivistyksellä on merkitystä. Huonosti tehtynä yhteenveto korvaa sotkuisen mutta uskollisen historian siistillä mutta hävikillisellä tarinalla. Hyvin tehtynä se säilyttää tehtävän tilan, viimeaikaisen työn, odottavat kohteet ja työkalukutsujen eheyden.

Arize raportoi, että Pi käynnistää tiivistyksen, kun arvioidut kontekstitokenit ylittävät konteksti-ikkunan miinus varatokenit, oletusvaran ollessa 16 384 tokenia. Se säilyttää viimeisimmät noin 20 000 tokenia ja tiivistää vanhemman sisällön synteettiseksi käyttäjäviestiksi, joka lisätään säilytetyn hännän alkuun. Se myös välttää katkaisemasta työkalukutsu/työkalutulos-pareja.

OpenClaw lisää aggressiivisemman historiakäytännön. Kun historia ylittää 50% konteksti-ikkunasta, se jakaa viestit yhtä suuriin tokenimassaltaan oleviin paloihin, pudottaa vanhimman palan, tiivistää pudotetun sisällön vaiheittaisella monivaiheisella yhteenvedolla ja korjaa työkalukutsujen ja tulosten parituksen. Se tekee myös esitiivistysflushin: hiljainen agenttinen vuoro antaa agentille mahdollisuuden tallentaa tilaa muistitiedostoihin ennen kuin historia katoaa. Erikseen se karsii muistissa olevia työkalutuloksia soft-trim- ja hard-clear-käyttäytymisellä 5 minuutin välimuistin TTL:llä.

Claude Code tiivistää lähellä ikkunan loppua. Arizen mukaan sen laukaisin on efektiivinen konteksti-ikkuna miinus 13 000 tokenin puskuri, mikä asettaa tiivistyksen noin 167K tokeniin 200K-kontekstin mallissa. Sen yhteenvetoprompti pyytää jäsenneltyjä osioita, jotka kattavat ensisijaisen pyynnön, tekniset käsitteet, tiedostot ja koodin, virheet ja korjaukset, ongelmanratkaisun, käyttäjäviestit, odottavat tehtävät, nykyisen työn ja seuraavan askeleen. Tiivistyksen jälkeen se voi liittää uudelleen enintään 5 äskettäin luettua tiedostoa tokenibudjetin puitteissa.

Kaava on selvä: tiivistys ei ole “tee keskustelusta yhteenveto”. Se on tarkistuspisteen tallentamista. Pitkäkestoinen agentti tarvitsee tallennustiedoston vastineen: tavoitteen, rajoitteet, päätökset, avoimet kahvat, tuoreen näytön ja seuraavan toiminnon.

Joitakin tulosteita ei pitäisi koskaan sijoittaa konteksti-ikkunaan lainkaan.

arXiv-julkaisu konkretisoi tämän materiaalitieteen työnkululla. Yksi työkalu luo molekyylille elektronisen hilarakenteen: 3D-matriisin, jonka mitat ovat 128 × 128 × 128 ja joka sisältää yhteensä 2 097 152 float32-elementtiä. Tämä tuloste ylittää laajasti käytettyjen LLM:ien konteksti-ikkunan reilusti. Seuraava työkalu kuitenkin tarvitsee hilan syötteenä.

Ehdotettu ratkaisu on tallentaa suuret arvot mallikontekstin ulkopuolelle ja palauttaa lyhyitä tunnisteita eli osoittimia. Työkalukääreet tarkistavat syötteistä, ovatko ne raakaarvoja vai muistipolkuja. Liian suuret tulosteet tallennetaan ajonaikaiseen muistiin polun alle, ja myöhemmät työkalut voivat vastaanottaa osoittimen ja ratkaista sen sisäisesti. Malli käsittelee viittauksia, kun taas ohjauskehys säilyttää koko datan. Julkaisun mukaan yhdessä vertailevassa kokeessa, jossa molemmat menetelmät onnistuivat, osoitinpohjainen lähestymistapa käytti noin seitsemän kertaa vähemmän tokeneita kuin perinteinen työnkulku.

Tämä on selkein erottelu päättelyn ja datan kuljettamisen välillä. Mallin ei tarvitse “nähdä” 2 miljoonan elementin matriisia välittääkseen sen toiselle työkalulle. Sen tarvitsee tietää, että matriisi on olemassa, mitä se edustaa ja minkä operaation pitäisi käyttää sitä seuraavaksi.

Sama logiikka pätee tieteellisten taulukoiden ulkopuolellakin. Suuret JSON-vastaukset, PDF:t, lokit, upotukset, mediatiedostot ja tietokantaviennit kuuluvat usein tallennustilaan, eivät promptiin. MCP-työkalujen tai mukautettujen API-connectorien ympärille rakennetuissa järjestelmissä osoittimien välittämisen pitäisi olla ensisijainen suunnitteluvalinta, ei paikkaus ensimmäisen ylivuodon jälkeen.

200K-tokenin konteksti-ikkuna tuntuu suurelta, kunnes agentti alkaa toimia. Järjestelmäprompti, työkalumääritykset, muutama haettu dokumentti, tiedostoluvut, lokit, virhejäljet ja yhteenvedot voivat kuluttaa sen odotettua nopeammin. Käytännöllinen kehys ei ole se, kuinka suurelta ikkuna näyttää paperilla, vaan kuinka nopeasti agentit käyttävät sitä ajon aikana. Redisin agenttimuistia koskeva ohjeistus viittaa ulkoiseen, kestävään muistiin tilalle, jonka pitäisi säilyä kutsujen yli, kun taas Atlanin kontekstisuunnittelun kehystys erottaa paremmat promptit paremmasta kontekstin kokoamisesta. Yhdessä ne kohtelevat konteksti-ikkunaa vähemmän varastona ja enemmän rajattuna työjoukkona.

Syvempi opetus on, että konteksti-ikkuna on niukka ajonaikainen resurssi. Sen käsitteleminen “muistina” on hyödyllistä, mutta vain jos ohjauskehys toimii käyttöjärjestelmän tavoin: allokoi, poistaa, sivuttaa, tiivistää, deduplikoi ja säilyttää. Atlanin kerroserottelu on tässä hyödyllinen. Prompt-suunnittelu ei voi korjata tiedostonlukijaa, joka kaataa seuraavaan kutsuun 80 000 epäolennaista tokenia. Kontekstisuunnittelu voi parantaa työjoukkoa. Ohjauskehityssuunnittelu päättää, suojataanko tuo työjoukko alun perinkään.

Tämä muuttaa myös tapaa, jolla tiimien pitäisi arvioida agentteja. Demoprompti ei riitä. Pitkän aikavälin arvioinnin pitäisi sisältää kasvavia litterointeja, toistuvia tiedostolukuja, suuria työkalutulosteita, epäonnistuneita työkalukutsuja, jatkamista tiivistyksen jälkeen ja tehtäviä, joissa oikea seuraava askel riippuu varhaisesta rajoitteesta. Oppaamme agenttien kontekstisuunnitteluun käsittelee ongelman mallipuolen versiota; ohjauskehyskerroksessa siitä tulee operatiivinen.

Ensiksi, aseta budjetit jokaiselle kontekstilähteelle. Tiedostoilla, työkalutulosteilla, haetuilla paloilla, muistilisäyksillä ja keskusteluhistorialla pitäisi kaikilla olla eksplisiittiset rajat. Yksi globaali tokenien enimmäismäärä on liian karkea.

Toiseksi, tee katkaisusta toimintakelpoista. Jos ohjauskehys leikkaa sisältöä, mallin pitäisi tietää, minkä alueen se näki ja miten pyytää lisää. Hiljainen katkaisu on hylkäystä pahempi, koska se synnyttää itsevarmaa työtä puuttuvan datan varaan.

Kolmanneksi, tiivistä tilan, älä proosan, ympärille. Yhteenvetojen pitäisi säilyttää käyttäjän tavoite, rajoitteet, päätökset, odottavat tehtävät, kosketetut tiedostot, merkitykselliset työkalutulokset ja välitön seuraava askel. Työkalukutsuparien pitäisi pysyä ehjinä.

Neljänneksi, siirrä suuret arvot pois promptista. Tallenna ne, nimeä ne ja välitä osoittimet työkalujen kautta. Tämä on erityisen tärkeää agenteille, jotka kutsuvat API:eja, käsittelevät dokumentteja tai koordinoivat moniagenttijärjestelmiä.

Lopuksi, testaa tavoitteen katoamista erillään ylivuodosta. Agentti voi pysyä kovan ikkunan alla ja silti ajautua harhaan. Oikea kysymys ei ole vain “hyväksyikö API promptin?” Se on “palveleeko seuraava toiminto yhä alkuperäistä tehtävää?”

Alla oleva yhteenveto muuntaa nämä kaavat nopeaksi tarkistuslistaksi ennen FAQ-osiota.

• Pitkän aikavälin agentit epäonnistuvat sekä kontekstin ylivuodon että tavoitteen katoamisen kautta, joten ohjauskehyksen on hallittava muutakin kuin promptin pituutta.
• Tuotantokäytön agenttijärjestelmät käyttävät kovia budjetteja tiedostoille, työkalutulosteille ja historialle ennen kuin raakadata päätyy mallille.
• Sivutus, haku ja hallitut näkymät käsittelevät kontekstia rajallisena näkymäalueena pysyvän tallennustilan sijaan.
• Tiivistys toimii parhaiten tarkistuspisteenä: se säilyttää tavoitteet, rajoitteet, päätökset, odottavan työn ja työkalukutsujen eheyden.
• Suuret työkalutulosteet kuuluvat usein ulkoiseen tallennustilaan, ja työkalujen välillä kannattaa välittää lyhyitä osoittimia sen sijaan, että promptiin lisätään täydet arvot.

Tämä osio vastaa pitkän aikavälin agenttien kontekstisuunnittelun käytännön kysymyksiin: mikä vuotaa yli, miten tavoitteet katoavat ja mitkä ohjauskehysten kaavat pitävät työn raiteillaan.

Kontekstin ylivuoto tapahtuu, kun agentin kertynyt prompti, historia, haettu data, tiedostot ja työkalutulosteet ylittävät mallin käyttökelpoisen konteksti-ikkunan tai heikentävät laatua ennen kovan rajan saavuttamista.

Tavoitteen katoaminen tapahtuu, kun alkuperäinen tehtävä on yhä jossakin litteroinnissa mutta ei enää ohjaa agentin seuraavaa toimintoa, usein pitkien historioiden tai huonon yhteenvedon jälkeen.

Ne asettavat lähdekohtaisia budjetteja, sivuttavat tiedostolukuja, hakevat vain olennaiset näkymät, tiivistävät historian tilan ympärille, deduplikoivat toistuvat luvut ja tallentavat suuret tulosteet promptin ulkopuolelle.

Osoittimet antavat mallin viitata ajonaikaiseen muistiin tallennettuihin suuriin arvoihin, kuten matriiseihin, lokeihin tai PDF:iin, samalla kun myöhemmät työkalut ratkaisevat koko datan sijoittamatta sitä konteksti-ikkunaan.

Eivät. Suuremmat ikkunat auttavat, mutta järjestelmäpromptit, työkalumääritykset, haetut dokumentit, lokit ja historia kilpailevat silti tilasta, ja olennainen tieto voi hautautua ennen kovan rajan täyttymistä.