Контекстна інженерія всередині оболонки: 4 механізми, що запобігають переповненню контексту та втраті мети в завданнях із довгим горизонтом

Агент у своїй найпростішій формі — це LLM, який циклічно викликає інструменти. Такий цикл працює для коротких завдань. Дайте йому завдання, що триває годину й потребує 200 викликів інструментів, — і він зламається двома передбачуваними способами. Посібник AWS Samples із проєктування автономних хмарних агентів для написання коду прямо називає їх: поверхневі агенти страждають від переповнення контексту, відволікаються (втрачають ціль) і не підтримують стан протягом тривалих періодів. Рівень, який це виправляє, — не модель. Це оболонка, яку 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 КБ. Схеми інструментів 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 для вставлення вмісту перед продовженням роботи моделі. Коли ви пишете там власні інструкції, вони повністю замінюють типовий запит, тож запит для компактування — це повноцінний інженерний артефакт, а не налаштування.

Механізм 3: стан списку завдань і повторне проговорювання

Компактування захищає ціль у момент узагальнення. Стан списку завдань захищає її на кожному проміжному кроці. Manus прямо описав цей прийом: його агент створює todo.md і переписує його крок за кроком, позначаючи виконані пункти. Переписування списку повторює цілі наприкінці контексту, переміщуючи глобальний план у нещодавній діапазон уваги моделі та зменшуючи дрейф через ефект «загубленого в середині». Зміна архітектури не потрібна. Це природна мова, використана для зміщення власної уваги моделі.

Докази щодо стану списку завдань не є однозначними. Deep Agents постачався з інструментом write_todos за замовчуванням до версії 0.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 рядками та переміщуйте довідкові матеріали в навички або правила, прив’язані до шляхів, які завантажуються лише за потреби.

Інтерактивне пояснення: спостерігайте, як заповнюється вікно на 200 тис.

Наведений нижче симулятор запускає завдання міграції з 60 кроків у контекстному вікні на 200 тис. токенів. Увімкніть 4 механізми, встановіть поріг компактування та натисніть «Запустити». Коли все вимкнено, вікно переповнюється ще до завершення половини завдання. Коли ввімкнено винесення даних, компактування, повторне проговорювання списку завдань і делегування субагентам, те саме завдання завершується, а ціль усе ще перебуває в нещодавньому діапазоні уваги. Кількість токенів наведено для ілюстрації; пороги відповідають типовим значенням Deep Agents.

Перевірка того, чи справді оболонка утримує ціль

Керування контекстом корисне лише в тому разі, якщо агент усе ще може завершити завдання та відновити деталі, яких більше не бачить. LangChain підтримує цільові оцінювання саме для цього: тести, які запускають узагальнення посеред завдання й перевіряють, чи продовжує агент рухатися до своєї мети, а також випадки «голки в копиці сіна», коли факт було втрачено під час узагальнення і його потрібно відновити через пошук у файловій системі. Щоб згенерувати достатньо подій для порівняння варіантів запиту, команда запускає узагальнення на рівні 10–20% вікна замість типових 85%, а для вивчення ефекту на terminal-bench-2 із Claude Sonnet 4.5 використовувала поріг 25%.

За словами LangChain, слідкувати потрібно за втратою цілі: агентом, який одразу після підсумку просить уточнення або помилково оголошує завдання завершеним. AgentCore Evaluations постачається з оцінювачем успішності цілі, який може оцінювати ті самі трасування. Якщо ви запускаєте оболонку й ще не примусово виконували компактування під час тесту, ви досі не знаєте, що саме вилучає ваш запит для узагальнення.

Основні висновки

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