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

Агентът в най-простата си форма представлява LLM, който извиква инструменти в цикъл. Този цикъл работи за кратки задачи. Дайте му задача, която продължава час и включва 200 извиквания на инструменти, и той се проваля по 2 предвидими начина. Ръководството за дизайн на AWS Samples за автономни облачни кодиращи агенти ги назовава директно: плитките агенти страдат от препълване на контекста, разсейват се (загуба на целта) и не поддържат състояние за дълги периоди. Слоят, който решава този проблем, не е моделът. Това е хъpнесът, който AWS описва като отговорен за управлението на всичко освен модела.

Тази статия разглежда този слой. Компактирането, стратегията за паметта, бюджетирането на контекста и състоянието на задачите са механизмите, които превръщат плиткия цикъл в дълбок агент. Разглеждаме как LangChain Deep Agents, Claude Code, Manus, OpenAI Codex и Amazon Bedrock AgentCore реализират всеки от тях, включително конкретните прагове, с които се доставят.

Защо по-големият прозорец не решава проблема

Очевидното решение е по-голям контекстен прозорец. Данните показват, че той помага по-малко от очакваното. Докладът на Chroma за разпадането на контекста оцени 18 LLM модела, включително GPT-4.1, Claude 4, Gemini 2.5 и Qwen3, и установи, че производителността става все по-ненадеждна с увеличаването на дължината на входа, дори при прости задачи за извличане. Ръководството на Anthropic за инженеринг на контекста обяснява механизма: вниманието създава n² двойки взаимовръзки за n токена, така че всеки добавен токен изчерпва краен „бюджет на вниманието“. Контекстът е ресурс с намаляваща възвръщаемост, а не контейнер.

За агентския цикъл това е по-лошо, отколкото звучи. Manus съобщава, че типичната задача изисква около 50 извиквания на инструменти, а съотношението между входните и изходните токени е близо до 100:1. Всяко наблюдение попада в контекста и остава там. Първоначалната инструкция се измества към средата на прозореца, точно там, където припомнянето се влошава. Загубата на целта не е само грешка на модела. Тя е очакваният резултат от неуправляван контекст при достатъчно дълга задача.

Механизъм 1: Бюджетиране на контекста и изнасяне

Първата задача на хърнеса е да реши какво изобщо да не влиза в прозореца. Deep Agents използва 2 правила за изнасяне с конкретни числови прагове. Когато отговорът от инструмент надхвърли 20 000 токена, той се записва във файловата система и се заменя с път към файла плюс преглед на първите 10 реда. Когато контекстът на сесията надхвърли 85% от прозореца на модела, по-старите извиквания на инструменти за запис и редактиране, чието пълно файлово съдържание вече се намира на диска, се съкращават до указател. Едва когато изнасянето изчерпи възможностите си, хърнесът преминава към обобщаване.

Claude Code прилага същото бюджетиране към съдържанието, което се зарежда преди първия въпрос. Автоматичната памет е ограничена до първите 200 реда или 25 KB. Схемите на MCP инструментите по подразбиране остават отложени, като се посочват само имената на инструментите, а пълните схеми се зареждат при поискване чрез търсене на инструменти. След компактиране всеки повторно прочетен файл над 5 000 токена се връща като препратка към пътя, а не като съдържание. Симулацията на контекстния прозорец в документацията на Claude Code показва конкретната полза: изследователски подагент прочита 6 100 токена от файлове и връща резултат от 420 токена на родителския агент.

Този модел с подагенти е бюджетиране на ниво архитектура. Ръководството на Anthropic отбелязва, че всеки подагент може да изразходва десетки хиляди токени в проучване, но връща дестилирано обобщение, често от 1 000 до 2 000 токена. Урокът на AWS AgentCore изгражда точно това: координатор стартира паралелно 3 браузърни подагента, всеки в собствен MicroVM, а аналитичен подагент получава само структурираните им резултати. AWS съобщава за очаквана продължителност от 4 до 6 минути и отбелязва, че последователната обработка би отнела до 3 пъти повече време.

Механизъм 2: Компактиране

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

Реализациите се различават по отношение на това какво обещават да запазят. Подканата за компактиране на Claude Code запазва архитектурните решения, нерешените грешки и детайлите по реализацията, като отхвърля излишните резултати от инструментите. Веднага след компактирането тя прочита повторно до 5 от най-скоро променените файлове, зарежда правилата, съответстващи на тези файлове, и повторно вмъква извиканите тела на уменията, ограничени до 5 000 токена на умение и общо 25 000 токена. В документацията изрично се посочва, че подробните инструкции от началото на разговора може да бъдат изгубени, поради което постоянните правила трябва да се намират в CLAUDE.md в основната директория на проекта, откъдето се вмъкват повторно от диска. Потребителите могат да насочат процеса с /compact focus on the auth bug fix или да променят момента на задействане с /autocompact.

Deep Agents превърна запазването на целта в структурна функция. Неговото обобщение е структуриран документ със специални полета за намерението на сесията, създадените артефакти и следващите стъпки. Екипът на LangChain добави тези полета, след като експерименти с принудително обобщаване показаха, че промяната подобрява производителността. Пълният оригинален транскрипт също се записва във файловата система, така че факт, пропуснат в обобщението, може по-късно да бъде възстановен чрез read_file.

Компактирането вече е част и от API слоя. Responses API на OpenAI предлага компактиране от страна на сървъра чрез context_management с compact_threshold, както и самостоятелна крайна точка /responses/compact, която връща компактиран контекстен прозорец, съдържащ непрозрачен криптиран елемент за компактиране; OpenAI инструктира разработчиците да предават върнатия прозорец непроменен в следващото извикване. OpenAI посочва, че Codex разчита на този механизъм, за да поддържа дълготрайни задачи за програмиране. Платформата за разработчици на Claude предоставя редакция за управление на контекста compact_20260112 с персонализирани инструкции и опция pause_after_compaction за вмъкване на съдържание, преди моделът да продължи. Когато напишете персонализирани инструкции там, те изцяло заменят стандартната подканa, така че подканата за компактиране е истински инженерен артефакт, а не настройка.

Механизъм 3: Състояние на задачите и рецитиране

Компактирането защитава целта в момента на обобщаването. Състоянието на задачите я защитава на всеки междинен ход. Manus описва подхода ясно: агентът му създава todo.md и го пренаписва стъпка по стъпка, като отбелязва изпълнените елементи. Пренаписването на списъка рецитира целите в края на контекста, премествайки глобалния план в най-скорошния обхват на вниманието на модела и намалявайки отклонението от типа „изгубено в средата“. Не е необходима промяна в архитектурата. Това е естествен език, използван за насочване на собственото внимание на модела.

Данните за състоянието на задачите не са еднозначни. Deep Agents използваше инструмент write_todos по подразбиране до v0.7 през юли 2026 г., когато LangChain направи TodoListMiddleware опционален след оценявания в 3 категории задачи, които показаха малко по-добра награда и по-ниска цена при изключени задачи. LangChain все пак препоръчва повторното му включване за дълги многостъпкови задачи, по-малко способни модели и потребителски интерфейси, които показват напредъка. Claude Code поддържа списък със задачи и повторно вмъква от диска плана, написан в режим на планиране, след компактиране. Ръководството на Anthropic нарича общия модел структурирано водене на бележки: агентът записва NOTES.md или файл TODO извън прозореца и го зарежда повторно. В примера на Anthropic Claude Plays Pokémon се поддържат броячи в продължение на хиляди игрови стъпки, след което агентът прочита собствените си бележки след всяко нулиране на контекста и продължава многочасовите последователности.

Моделът зад всички тези подходи е, че целта съществува като променяем артефакт, а не само като съобщение в историята. Съобщенията остаряват и се обобщават. Файл, който се пренаписва на всеки няколко хода, винаги е актуален, винаги е кратък и оцелява при всяко нулиране. Дали това си струва разхода на токени за всеки ход зависи от модела и дължината на задачата, което е точно това, което са измерили оценяванията на Deep Agents.

Механизъм 4: Стратегия за паметта между сесиите

Последната част е това, което се запазва след края на задачата. Claude Code повторно вмъква CLAUDE.md от основната директория на проекта и автоматичната памет от диска след всяко компактиране. AgentCore Memory съхранява събития и изпълнява конфигурирани стратегии за извличане във фонов режим, така че координаторът може да извика инструмент за припомняне при следващото изпълнение, вместо да прави повторно проучване. AWS предупреждава, че без конфигурирана поне 1 стратегия за извличане необработените събития се съхраняват, но от тях не се извлича нищо за търсене. Файловият инструмент за памет на Anthropic служи за същата цел в платформата Claude.

Ограничението е, че постоянният контекст не е безплатен. Проучването на ETH Zurich, което отразихме през февруари, установи, че контекстните файлове на хранилището като AGENTS.md по принцип не подобряват успеваемостта на задачите, като същевременно увеличават разходите за извеждане: генерираните от LLM файлове са увеличили разходите с 20% и 23% при 2-та бенчмарка, а файловете, добавени от разработчици, с до 19%. Паметта, която се зарежда при всяка сесия, е постоянен данък върху бюджета на вниманието. Документацията на Claude Code дава съответния съвет: поддържайте CLAUDE.md под 200 реда и преместете справочния материал в умения или правила, ограничени до конкретни пътища, които се зареждат само при необходимост.

Интерактивно обяснение: вижте как се запълва прозорец от 200K

Симулаторът по-долу изпълнява задача за миграция от 60 стъпки през прозорец от 200K токена. Включете или изключете 4-те механизма, задайте прага за компактиране и натиснете „Изпълни“. Когато всичко е изключено, прозорецът се препълва, преди задачата да е наполовина завършена. Когато са включени изнасянето, компактирането, рецитирането на задачите и делегирането към подагенти, същата задача завършва, като целта все още се намира в скорошния обхват на вниманието. Броят на токените е илюстративен; праговете съответстват на стандартните настройки на Deep Agents.

Проверка дали хърнесът действително запазва целта

Управлението на контекста е полезно само ако агентът все още може да завърши задачата и да възстанови детайли, които вече не вижда. LangChain поддържа целеви оценявания именно за това: тестове, които задействат обобщаване по време на задачата и проверяват дали агентът продължава към целта си, както и случаи тип „игла в купа сено“, при които даден факт е обобщен и трябва да бъде възстановен чрез търсене във файловата система. За да генерира достатъчно събития за сравняване на варианти на подканите, екипът задейства обобщаването при 10 до 20% от прозореца вместо при стандартните 85% и използва праг от 25% с Claude Sonnet 4.5 върху terminal-bench-2, за да проучи ефекта.

Провалът, за който трябва да се следи според LangChain, е отклонението от целта: агент, който иска уточнение непосредствено след обобщение или неправилно обявява задачата за завършена. AgentCore Evaluations предоставя оценител за успеваемост на целта, който може да оценява същите следи. Ако използвате хърнес и не сте предизвикали компактиране в тест, все още не знаете какво пропуска подканата ви за обобщение.

Основни изводи

• Плитките агенти се провалят заради препълване на контекста и загуба на целта; решението се намира в хърнеса, а не в модела.
• Първо бюджетирайте: Deep Agents изнася резултатите от инструменти над 20 000 токена и премахва старите редакции при 85% от прозореца.
• Компактирането трябва да посочва какво запазва; Deep Agents добавя полета за намерението на сесията и следващите стъпки, а Claude Code прочита повторно 5 скорошни файла.
• Рецитирането на задачите запазва целта в края на контекста, но оценяванията на Deep Agents v0.7 показват, че това не е безусловна полза.
• Постоянната памет изразходва внимание: ETH Zurich измери с 20 до 23% по-високи разходи за извеждане при генерирани от LLM контекстни файлове.