Контекстная инженерия: как не сломать контекст агента

Контекстная инженерия (context engineering), это работа с тем, что лежит в окне модели во время задачи. Качество ответов падает задолго до физического предела окна, это показал замер Chroma на 18 моделях.

Работа сводится к трём решениям: что положить в окно, что убрать, что подгрузить по требованию. Anthropic называет контекст конечным ресурсом с убывающей отдачей (Effective context engineering for AI agents).

От контекста зависит, закончит агент задачу или начнёт повторять одни и те же действия.

Чем контекстная инженерия отличается от промпт инжиниринга

Промпт отвечает за одну реплику, контекст отвечает за всю сессию. Промпт инжиниринг подбирает формулировку запроса. Контекстная инженерия решает, что уходит в модель на каждом шаге: история переписки, файлы, результаты вызовов инструментов, описания самих инструментов.

Разница видна на длинной задаче. Хорошо сформулированный запрос не поможет агенту, у которого окно занято историей переписки и описаниями всех подключённых инструментов.

Почему качество падает раньше, чем кончается окно

Деградация на длинном входе идёт неровно, провалами, и начинается задолго до предела окна. В замере Chroma это видно на 18 моделях, среди них Claude, GPT, Gemini и Qwen. Это явление называют context rot. Chroma делает базу для векторного поиска, то есть интерес у компании в этой теме прямой, и замер стоит читать с поправкой на это.

Anthropic объясняет эту потерю качества через бюджет внимания: он у модели ограничен, и каждый новый токен его тратит. Чем длиннее контекст, тем строже приходится отбирать, что в него класть.

Большое окно работу с контекстом не отменило. С большим окном ошибки в подборе контекста проявляются позже, но обходятся дороже. За лишнее в окне вы платите на каждом шаге.

Как ломается контекст

Дрю Бройниг разделил ошибки длинного контекста на четыре вида и дал им названия (How Long Contexts Fail).

1) Отравление. В контекст попала ошибка или галлюцинация, и агент дальше ссылается на неё как на факт. Пример из разбора: агент на Gemini, игравший в Pokemon, выдумал несуществующее состояние игры и добивался невозможной цели.

2) Отвлечение. Контекст разросся настолько, что модель ориентируется на историю и перестаёт опираться на то, чему её обучили. Тот же агент после 100 000 токенов начал повторять свои прошлые действия вместо новых стратегий.

3) Путаница. В контексте лежит лишнее, и модель использует это в ответе. Бройниг ссылается на Berkeley Function-Calling Leaderboard: при большом наборе подключённых инструментов модели иногда вызывают не тот.

4) Столкновение. Новая информация противоречит тому, что уже лежало в промпте. Бройниг ссылается на совместную работу Microsoft и Salesforce: качество падает на 39%, когда задачу выдают по частям за несколько ходов вместо целой сразу.

Четвёртый вид неприятнее остальных, потому что так устроен обычный диалог. Условие уточняется по ходу дела, а в контексте агента остаются все прежние версии условия.

Если разговор ушёл в сторону, в чате и в агенте надёжнее собрать условие заново и начать с чистого контекста, чем дописывать очередное уточнение. Накопленная история при этом теряется. В чате платформы для этого откройте новую сессию.

Чем чинят разросшийся контекст

Anthropic описывает три приёма для долгих задач. Те же три встроены в Claude Agent SDK и в deep agents у LangChain.

1) Сжатие истории. Старые сообщения заменяются сводкой: что была за задача, что сделано, что дальше. Разговор продолжается, а история занимает в окне столько, сколько занимает сводка.

2) Внешние заметки. Агент пишет выводы в файлы и читает их, когда нужно. Такая память лежит вне окна и переживает и сжатие, и перезапуск сессии.

3) Изоляция через субагентов. Тяжёлая работа уходит отдельному агенту со своим чистым окном, наверх возвращается только результат.

Изоляция стоит дороже двух первых приёмов. Её используют, чтобы главный агент довёл задачу до конца: качество восстанавливается, но растут расходы. Мультиагентные схемы тратят в 3-10 раз больше токенов, чем один агент, из-за дублирования контекста и накладных расходов на координацию (статья Anthropic).

На каких порогах включается сжатие

В deep agents у LangChain пороги на сентябрь 2026 года такие (context engineering в deep agents).

1) Результат вызова инструмента больше 20 000 токенов (порог по умолчанию) в историю целиком не кладётся. Он уходит в файл, в контексте остаётся путь и первые десять строк.

2) Сжатие включается по умолчанию на 85% от max_input_tokens модели, свежими остаются последние 10% токенов.

3) Если профиля модели нет, работает запасной порог 170 000 токенов и шесть последних сообщений.

Первые два порога стоят заметно раньше предела окна. Это тот же вывод, что и у замера Chroma, только в коде deep agents.

Anthropic называет удаление старых результатов вызовов инструментов самой безопасной формой сжатия: эти результаты агент уже использовал. Опасно другое: из окна пропадает нужное дальше, а достать его уже неоткуда.

Сжимать историю или держать целиком

Единого ответа на сентябрь 2026 года нет. В инструментах Anthropic и LangChain сжатие включается раньше предела окна. Луи Бушар пишет, что в его команде сжимать историю перестали, причина в кэше промпта (Context Engineering in 2026).

Провайдер кэширует начало запроса, и повторно отправленные токены стоят заметно дешевле новых. Размер скидки у каждого провайдера свой, Бушар в своих расчётах берёт разницу примерно в 50 раз. Пока история дописывается новыми сообщениями, прежняя её часть идёт по цене кэша. После пересборки истории в сводку начало запроса меняется, кэш сбрасывается, и следующий запрос оплачивается по полной ставке.

Сжатие экономит место в окне, кэш экономит деньги, а сжатие сбрасывает кэш. Бушар сам пишет, что его довод работает не всегда. Кэш не вечен, срок жизни у каждого провайдера свой.

Решение принимается по режиму работы. Плотная сессия без длинных пауз, кэш важнее сжатия. Работа урывками, с паузами длиннее срока жизни кэша, сжатие важнее: платить полную ставку за историю, которая всё равно выпала из кэша, смысла нет.

Нужно ли грузить агенту всё заранее

Загружать на старте всю документацию, все инструкции и описания всех инструментов не нужно. Работает обратное, подгрузка по требованию: агент получает способ достать данные и читает то, что нужно текущему шагу.

Этот приём называется progressive disclosure, его видно на навыках (skills). У навыка есть короткая шапка с названием и описанием, и на старте агент читает только её. Полный текст подтягивается тогда, когда навык относится к делу (Agent Skills у Anthropic).

Готовые файлы формата SKILL.md для Claude Code и Cursor собраны в разделе навыков платформы.

При настройке своего агента постоянно держите в промпте только то, что нужно в каждой задаче: соглашения команды, правила проекта, формат ответов. Остальное лежит рядом и подгружается по требованию. Цена этого в лишних шагах: токенов уходит меньше, но ответ приходит позже, и в коротких задачах это может не окупиться.

Что сделать руками уже сегодня

1) Сжатие по своей команде. В Claude Code это /compact, она собирает историю в сводку без всякого порога (команды Claude Code). Замеренного порога для ручного вызова я не встречал, поэтому сжатие удобно вызывать при смене задачи: часть работы закончена, следующая ещё не начата.

2) Сжатие автоматом. В API Claude оно включается параметром в запросе: по достижении порога (150 000 входных токенов по умолчанию, минимум для настройки 50 000) модель делает сводку, и всё, что было до неё, API в следующих запросах отбрасывает (сжатие в API). На сентябрь 2026 года функция в бете, сама сводка стоит денег и считается отдельной строкой в расходе.

3) Память между сессиями. Отдельный инструмент памяти в API Claude работает в паре со сжатием: сжатие держит активный контекст небольшим, память хранит то, что должно пережить сводку (инструмент памяти). Файлы памяти лежат на вашей стороне: модель запрашивает операцию с файлом, выполняет её ваш код.

4) Middleware у LangChain. SummarizationMiddleware заменяет старые сообщения сводкой и оставляет хвост: порог задаётся параметром trigger, длина хвоста параметром keep (встроенные middleware). В deep agents он настроен на 85% от max_input_tokens, а в LangChain без deep agents порог задаётся руками, без trigger сжатие не сработает. Рядом лежит ContextEditingMiddleware, он удаляет старые результаты вызовов инструментов и сводку не делает.

5) Схемы инструментов. Они уходят в промпт на каждом шаге, даже если инструмент ни разу не вызван. Отключение неиспользуемых инструментов уменьшает базовый размер запроса на всю сессию.

Пятый пункт проверяется первым. Он не требует менять архитектуру и даёт эффект на каждом шаге до конца сессии.

Какой порог ставить на стартовый контекст

Я собрал агента под работу с текстами и видео. В начале каждой сессии он читает три файла: правила проекта, общий журнал и список открытых задач. Суммарный вес этих трёх файлов держится в пределах 125 КБ и замеряется командой перед закрытием сессии. Когда порог пробит, подробности переносятся в отдельные файлы по проектам, а в общем журнале остаётся только последняя запись.

Второй порог стоит на чтении. Файл тяжелее 60 КБ целиком в контекст не читается, такое чтение отменяется до вызова инструмента, а нужный кусок берётся по смещению и длине. Порог появился из-за расшифровок: текст часовой записи весит от 150 до 450 КБ, а контекст сессии уходит в модель заново на каждом шаге. Вместо чтения целиком работают два инструмента: один даёт выжимку по темам, другой ищет таймкод фразы, оба читают файл сами и возвращают агенту только результат.

Оба числа, это пороги одного проекта, отраслевой рекомендацией они не служат. Ценность здесь в самом приёме: порог задан числом, замеряется командой и проверяется в конце каждой сессии. На глаз он не оценивается.

Коротко

Что такое контекстная инженерия? Работа с тем, что лежит в окне модели во время задачи: что положить, что убрать, что подгрузить по требованию.

Почему длинный контекст ухудшает ответы? Качество падает задолго до предела окна, это показал замер Chroma на 18 моделях. Бюджет внимания у модели ограничен.

Как ломается контекст? Четырьмя способами по разбору Бройнига: отравление, отвлечение, путаница и столкновение новых данных со старыми.

Сжимать историю или нет? Сжатие экономит место в окне, но сбрасывает кэш промпта. При плотной работе выгоднее кэш, при работе урывками выгоднее сжатие.

Что сделать первым делом? Отключить неиспользуемые инструменты: их схемы уходят в запрос на каждом шаге, даже когда инструменты не вызываются.