Инженеринг на контекста за AI агенти с дълъг хоризонт

Взети заедно, анализът на Arize, статията в arXiv за препълване на прозореца на контекста, обяснението за продукционна среда на Redis и сравнението на инженеринг на обвивки на Atlan сочат към практическа промяна в дизайна на агенти. Дълго работещите агенти се оценяват все по-малко според размера на прозореца на контекста на модела и все повече според контролния слой около него. Arize прави тази промяна конкретна. Той посочва пуснати агентни инструменти и системи за памет/обвивки, включително Pi, OpenClaw, Claude Code и Letta, като примери за инженеринг на контекста на ниво обвивка, и описва интерактивен симулатор, който показва как прозорец от 200K token-а се запълва.

Публичните подробности, налични в цитираните източници, са неравномерни. Arize дава конкретни имплементационни числа за Pi, OpenClaw, Claude Code и Letta. Изследователска статия за решаване на препълването на прозореца на контекста при AI агенти дава по-общ механизъм за обработка на изходи от инструменти, които могат да надхвърлят всеки практически прозорец. Обяснението на Redis за препълване на прозореца на контекста обобщава симптомите в продукционна среда: твърди API грешки, тиха деградация на качеството, натрупване на изходи от инструменти и по-голяма латентност с нарастването на prompt-овете. Сравнението на Atlan за prompt, контекст и инженеринг на обвивки предоставя полезната метафора със стека: prompt инженерингът оформя съобщението, инженерингът на контекста оформя това, което моделът вижда, а инженерингът на обвивката оформя цялата среда на агента.

Важната новина не е, че прозорците на контекста са твърде малки. Създателите вече знаят това. По-полезният извод е, че цитираните агентни системи се сближават около четири механизма на обвивката, които поддържат работата жива, след като транскриптът престане да бъде надежден източник на истина.

Повърхностният агент чете файлове, извиква инструменти, добавя резултата и се надява моделът да се справи. Агент, проектиран първо около обвивката, блокира или преоформя големи входове, преди да достигнат до модела.

По-ясен начин да се прочете първият набор от ограничения е:

• Pi: четенето на файлове спира при 2 000 реда или 50KB, което настъпи първо. Върнатото съдържание включва подсказка за продължение, която казва на модела кой диапазон от редове е показан и как да продължи с offset и limit. OpenClaw наследява това поведение, след което добавя отделни тавани: bootstrap файловете са ограничени до 12 000 знака на файл и общо 60 000 знака. Резултатите от инструменти получават друг бюджет от 16 000 знака или 30% от прозореца на контекста, което е по-малко.

Claude Code използва дизайн с две врати. Според Arize той проверява лимит от 256KB в байтове преди отваряне на файл, след което брои token-ите в резултата спрямо бюджет от 25 000 token-а след прочитането. Дори за файлове под лимита по подразбиране връща 2 000 реда от началото и отрязва редове, по-дълги от 2 000 знака. Ако моделът прочете повторно същия диапазон от файл и файлът не е променен, Claude Code може да върне заместител вместо да повтаря пълното съдържание.

Това не е просто оптимизация. То променя режима на провал. Вместо да позволи на едно голямо четене да изтласка задачата, обвивката превръща „прочети всичко“ в „прочети контролиран отрязък“. Ако моделът има нужда от още, може да го поиска. За екипи, които проектират агентни обвивки от нулата, това е първата линия на защита: никога не позволявайте сурови външни данни да се превръщат в транскрипта по подразбиране.

Следващият модел е контекстът да се третира като viewport, а не като хранилище.

Pi и Claude Code предоставят пагинация чрез offset и limit. OpenClaw добавя отрязване на начало/край на някои места, като запазва началото и края, когато средата е по-малко вероятно да има значение. Arize казва, че OpenClaw използва разделяне 75% начало / 25% край за прекалено големи bootstrap файлове и може да запази както началото, така и края за резултати от инструменти, когато краят изглежда важен, например грешки, затварящи JSON скоби или ключови думи, приличащи на обобщение.

Letta отива по-далеч, като държи файловете извън prompt-а. Качените файлове се парсват, разделят на chunks и се вграждат във vector store, което дава на агента директен преглед, точно търсене и семантично търсене. Когато файл е отворен в контекст, Letta показва управляван изглед, чийто размер се мащабира според контекста на модела: 5 000 знака за 8K контекст, 15 000 за 32K, 25 000 за 128K и 40 000 за 200K+. Броят на едновременно отворените файлове също се мащабира — от 3 за малки модели до 15 за много големи, с LRU политика, която изважда най-отдавна използваните файлове.

Това е същата дизайнерска идея зад продукционния RAG: не натъпквайте целия корпус в prompt-а; извлечете частта, която има значение. Разликата е, че агентните обвивки трябва да го правят непрекъснато, през файлове, изходи от инструменти, памет и междинни планове. Същото ограничение важи и за RAG системите: извличането не е само въпрос на релевантност, а и на запазване на достатъчно бюджет на контекста за самата стъпка на разсъждение.

Redis прави свързана забележка: по-големите прозорци на контекста не премахват нуждата от управление на контекста. Системните prompt-ове, извлечените документи, историята на разговора и изходите от инструменти се конкурират за едно и също пространство. Дори преди да се достигне твърд лимит, моделите могат да се влошат, когато релевантната информация бъде заровена в дълги входове.

Препълването е очевидният провал. Загубата на целта е по-тиха. Агентът все още има място да отговори, но забравя първоначалната цел, пропуска ограничение или започва да оптимизира локална подзадача.

Точно тук компактирането има значение. Направено лошо, обобщаването заменя разхвърляна, но вярна история с подреден, но загубен разказ. Направено добре, то запазва състоянието на задачата, скорошната работа, чакащите елементи и целостта на извикванията на инструменти.

Arize съобщава, че Pi задейства компактиране, когато прогнозните token-и на контекста надхвърлят прозореца на контекста минус резервните token-и, с резерв по подразбиране от 16 384 token-а. Той запазва най-скорошните приблизително 20 000 token-а и обобщава по-старото съдържание в синтетично потребителско съобщение, добавено пред запазения край. Освен това избягва разрязване през двойки извикване на инструмент/резултат от инструмент.

OpenClaw добавя по-агресивна политика за историята. Когато историята надхвърли 50% от прозореца на контекста, той разделя съобщенията на token chunks с еднаква маса, премахва най-стария chunk, обобщава премахнатото съдържание чрез поетапно многопроходно обобщаване и поправя сдвояването на извиквания/резултати от инструменти. Той също извършва flush преди компактиране: тих агентен ход дава на агента шанс да запази състояние във файлове с памет, преди историята да изчезне. Отделно от това той окастря резултатите от инструменти в паметта със soft-trim и hard-clear поведение при 5-минутен cache TTL.

Claude Code компактира близо до края на прозореца. Arize казва, че неговият тригер е ефективният прозорец на контекста минус буфер от 13 000 token-а, което поставя компактирането около 167K token-а за модел с 200K контекст. Неговият prompt за обобщаване иска структурирани секции, покриващи основната заявка, технически концепции, файлове и код, грешки и поправки, решаване на проблеми, потребителски съобщения, чакащи задачи, текуща работа и следваща стъпка. След компактиране той може да прикачи отново до 5 наскоро прочетени файла в рамките на token бюджет.

Моделът е ясен: компактирането не е „обобщи чата“. То е checkpointing. Дълго работещият агент се нуждае от еквивалент на save файл: цел, ограничения, решения, отворени handles, скорошни доказателства и следващо действие.

Някои изходи изобщо не трябва да се поставят в прозореца на контекста.

Статията в arXiv прави това конкретно чрез работен процес от науката за материалите. Един инструмент генерира електронна grid структура за молекула: 3D матрица с размери 128 × 128 × 128, общо 2 097 152 float32 елемента. Този изход далеч надхвърля прозореца на контекста на широко използваните LLM-и. Но следващият инструмент има нужда от grid-а като вход.

Предложеното решение е големите стойности да се съхраняват извън контекста на модела и да се връщат кратки идентификатори, или указатели. Обвивките на инструментите проверяват входовете, за да видят дали са сурови стойности или пътища в паметта. Изходите, които са твърде големи, се съхраняват в runtime памет под път, а по-късните инструменти могат да получат указателя и да го разрешат вътрешно. Моделът манипулира препратки, докато обвивката запазва пълните данни. В един сравнителен експеримент, в който и двата метода успяват, подходът с указатели използва приблизително седем пъти по-малко token-и от традиционния работен процес според статията.

Това е най-чистото разделяне между разсъждение и пренос на данни. Моделът не трябва да „вижда“ матрица с 2 милиона елемента, за да я подаде на друг инструмент. Той трябва да знае, че матрицата съществува, какво представлява и коя операция трябва да я консумира след това.

Същата логика важи и извън научните масиви. Големи JSON отговори, PDF файлове, логове, embeddings, медийни файлове и експорти от бази данни често принадлежат в хранилище, не в prompt-а. За системи, изградени около MCP инструменти или custom API connectors, подаването чрез указатели трябва да бъде първокласен дизайнерски избор, а не кръпка след първото препълване.

Прозорец на контекста от 200K token-а изглежда голям, докато агентът не започне да действа. Системен prompt, дефиниции на инструменти, няколко извлечени документа, четения на файлове, логове, traces на грешки и обобщения могат да го изконсумират по-бързо от очакваното. Практическата рамка не е колко голям изглежда прозорецът на хартия, а колко бързо агентите го харчат по време на изпълнение. Насоките на Redis за памет на агенти сочат към външна, устойчива памет за състояние, което трябва да оцелява между извикванията, докато рамката на Atlan за инженеринг на контекста отделя по-добрите prompt-ове от по-доброто сглобяване на контекст. Заедно те третират прозореца на контекста по-малко като склад и повече като ограничен работен набор.

По-дълбокият урок е, че прозорецът на контекста е оскъден runtime ресурс. Да се третира като „памет“ е полезно, но само ако обвивката се държи като операционна система: заделя, изважда, страницира, компактира, дедупликира и съхранява устойчиво. Разграничението на Atlan между слоевете е полезно тук. Prompt инженерингът не може да поправи четец на файлове, който изсипва 80 000 нерелевантни token-а в следващото извикване. Инженерингът на контекста може да подобри работния набор. Инженерингът на обвивката решава дали този работен набор изобщо е защитен.

Това променя и начина, по който екипите трябва да оценяват агентите. Демо prompt не е достатъчен. Оценяването за дълъг хоризонт трябва да включва нарастващи транскрипти, повторни четения на файлове, големи изходи от инструменти, неуспешни извиквания на инструменти, възобновявания след компактиране и задачи, при които правилната следваща стъпка зависи от ранно ограничение. Нашето ръководство за инженеринг на контекста за агенти покрива версията на този проблем от страна на модела; слоят на обвивката е мястото, където той става оперативен.

Първо, поставете бюджети за всеки източник на контекст. Файловете, изходите от инструменти, извлечените chunks, записите в паметта и историята на разговора трябва да имат отделни явни лимити. Един общ максимален брой token-и е твърде груб инструмент.

Второ, направете отрязването actionable. Ако обвивката отреже съдържание, моделът трябва да знае кой диапазон е видял и как да поиска още. Тихото отрязване е по-лошо от отказ, защото създава уверена работа върху липсващи данни.

Трето, компактирайте около състоянието, не около прозата. Обобщенията трябва да запазват целта на потребителя, ограниченията, решенията, чакащите задачи, докоснатите файлове, резултатите от инструменти, които имат значение, и непосредствената следваща стъпка. Двойките извиквания на инструменти трябва да останат непокътнати.

Четвърто, преместете големите стойности извън prompt-а. Съхранявайте ги, именувайте ги и подавайте указатели през инструментите. Това е особено важно за агенти, които извикват APIs, обработват документи или координират multi-agent systems.

Накрая, тествайте за загуба на целта отделно от препълването. Един агент може да остане под твърдия прозорец и пак да се отклони. Правилният въпрос не е само „API-то прие ли prompt-а?“ А „следващото действие все още ли служи на първоначалната задача?“

Обобщението по-долу превръща тези модели в кратък checklist преди FAQ.

• Агентите с дълъг хоризонт се провалят както чрез препълване на контекста, така и чрез загуба на целта, затова обвивката трябва да управлява повече от дължината на prompt-а.
• Продукционните агентни системи използват твърди бюджети за файлове, изходи от инструменти и история, преди суровите данни да достигнат до модела.
• Пагинацията, търсенето и управляваните изгледи третират контекста като ограничен viewport, а не като постоянно хранилище.
• Компактирането работи най-добре като checkpointing: то запазва цели, ограничения, решения, чакаща работа и целостта на извикванията на инструменти.
• Големите изходи от инструменти често принадлежат във външно хранилище с кратки указатели, подавани между инструменти, вместо пълни стойности в prompt-а.

Този раздел отговаря на практическите въпроси зад инженерингa на контекста за агенти с дълъг хоризонт: какво се препълва, как се губят целите и кои модели на обвивката държат работата в правилната посока.

Препълването на контекста се случва, когато натрупаният prompt, историята, извлечените данни, файловете и изходите от инструменти на агента надхвърлят използваемия прозорец на контекста на модела или влошат качеството, преди да бъде достигнат твърдият лимит.

Загубата на целта се случва, когато първоначалната задача все още присъства някъде в транскрипта, но вече не насочва следващото действие на агента, често след дълги истории или лошо обобщаване.

Те задават бюджети по източник, страницират четенията на файлове, извличат само релевантни изгледи, компактират историята около състоянието, дедупликират повторните четения и съхраняват големи изходи извън prompt-а.

Указателите позволяват на модела да се позовава на големи стойности, съхранявани в runtime памет, като матрици, логове или PDF файлове, докато downstream инструментите разрешават пълните данни, без да ги поставят в прозореца на контекста.

Не. По-големите прозорци помагат, но системните prompt-ове, дефинициите на инструменти, извлечените документи, логовете и историята все още се конкурират за пространство, а релевантната информация може да бъде заровена, преди да се достигне твърд лимит.