Контекстная инженерия для ИИ-агентов: что на самом деле попадает в окно контекста

Содержание

Опубликовано в августе 2026 года.

TL;DR: Контекстная инженерия — это дисциплина решать, какие токены заслуживают места в окне контекста агента на каждом шаге — системные инструкции, определения инструментов, извлечённые данные и история разговора конкурируют за одно и то же ограниченное пространство. Промпт-инжиниринг спрашивает как это сформулировать; контекстная инженерия спрашивает что модели на самом деле нужно знать прямо сейчас. Типичный сбой — обычно не слишком мало контекста, а слишком много: устаревшая история, нерелевантные схемы инструментов и извлечённые документы, которые никто не запрашивал, всё это разбавляет сигнал и увеличивает стоимость. Я применяю фиксированный бюджет по каждой категории, урезаю историю раньше идентичности и резюмирую перед тем, как обрезать.

Взгляд оператора: Агенты, которых сложнее всего было отлаживать, ломались не потому, что модель была слабой. Они ломались, потому что я позволил окну контекста превратиться в ящик со всяким хламом: шесть схем инструментов, которые задаче не требовались, история разговора, ушедшая на 40 ходов от исходного запроса, извлечённый документ, технически релевантный и практически бесполезный. Исправление промпта не помогало. Исправление того, что стояло перед промптом, — помогало.

Промпт-инжиниринг дал вам работающего агента. Контекстная инженерия — то, что удерживает его работающим, когда он обрабатывает реальный объём, реальную историю и реальные крайние случаи — и это навык, которому я теперь уделяю больше времени, чем формулировке промпта.

Промпт-инжиниринг и контекстная инженерия — не одна и та же работа

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

Это различие важно на практике, а не только в терминологии. Если я пишу тщательно выверенный промпт и даю агенту пять нерелевантных схем инструментов и сорок ходов устаревшей истории, формулировка уже не имеет значения — модель рассуждает над контекстом, который в основном шум. Каждый мой агент, перешедший от «работает в демо» к «работает в 3 часа ночи на странном вводе», добился этого исправлением того, что было в окне, а не переформулировкой инструкций внутри него.

Четыре вещи, конкурирующие за место

На каждом ходу четыре категории борются за одно и то же ограниченное пространство:

1. Системные инструкции — идентичность, правила, формат вывода. См. пять слоёв, которые я использую для системных промптов — это единственная категория, которая должна оставаться практически неизменной, потому что кэширование промптов окупается только тогда, когда префикс не сдвигается.
2. Определения инструментов — схемы каждого инструмента, который агент мог бы вызвать в этом ходу, независимо от того, нужен он ему или нет.
3. Извлечённые данные — всё, что тянется из базы данных, векторного хранилища или вызова API: память, документы, записи клиентов.
4. История разговора или запуска — что уже произошло в этой сессии или запуске.

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

Ошибка почти всегда — это слишком много, а не слишком мало

Когда агент ведёт себя плохо, инстинкт подсказывает добавить больше контекста — больше инструкций, больше фона, больше истории «на всякий случай». По моему опыту, чаще всё наоборот.

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

Устаревшая история разговора. Агент поддержки, тянущий 60 ходов истории из трёх не связанных между собой инцидентов давности, не «помнит клиента» — он разбавляет текущий запрос нерелевантным шумом и иногда действует на основании того, что уже неверно. Это именно тот сбой, который должна предотвращать эпизодическая память с ограниченным окном, и стоит проверить, действительно ли ваше окно ограничено или незаметно выросло без предела.

Извлечённые документы, которые никто не запрашивал. Семантический поиск, возвращающий топ-10 «наиболее похожих» фрагментов вместо топ-2 релевантных, хоронит ответ под правдоподобно выглядящим отвлечением. Больше извлечённого контекста — не значит больше сигнала: после определённой точки становится активно хуже, потому что модели приходится работать больше, чтобы найти важную часть.

Инструкции, повторяемые на всякий случай. Я вижу это в промптах, повторяющих одно и то же правило четырьмя разными способами, потому что более ранняя версия агента однажды его проигнорировала. Это сигнал, что правило нужно было переместить раньше в промпте или закрепить структурно (ограничение в схеме инструмента, шаг валидации) — а не сигнал заполнять контекст повторами.

Бюджет, который я реально применяю

На 30+ продакшн-агентах я устанавливаю явный токен-бюджет по каждой категории до постройки агента, а не после того, как он начинает вести себя плохо:

Порядок в последнем столбце — это и есть реальная модель принятия решений: сначала история, затем ширина извлечения, затем область инструментов, и системные инструкции — последними. Историю дешевле всего сжать без потери корректности — резюме из двух предложений о том, «что произошло в ходах 1-30», обычно несёт ту же операционную ценность, что и полная расшифровка. Урезать системные инструкции опаснее всего, потому что именно там живёт реальное поведение агента.

Резюмируйте перед тем, как обрезать

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

// workers/compact-history.ts

interface HistoryDigest {
  summary: string; // 2-3 предложения: что решено, разрешено или ещё открыто
  keyFacts: Record<string, string>; // стабильные факты, которые стоит хранить дословно
  turnCount: number; // сколько сырых ходов заменяет этот дайджест
}

async function compactIfNeeded(
  history: ConversationTurn[],
  env: Env
): Promise<{ digest: HistoryDigest | null; recent: ConversationTurn[] }> {
  const RECENT_WINDOW = 10;
  if (history.length <= RECENT_WINDOW) {
    return { digest: null, recent: history };
  }

  const toCompact = history.slice(0, -RECENT_WINDOW);
  const recent = history.slice(-RECENT_WINDOW);

  // Дешёвая модель для суммаризации почти всегда достаточна для этого шага
  const digest = await summarizeTurns(toCompact, env);
  return { digest, recent };
}

Это тот же принцип, что и стенд оценки, превращающий каждый производственный сбой в постоянный тестовый случай (см. стенд оценки, который я использую для выпуска ИИ-агентов): не отбрасывайте информацию, сжимайте её в форму, дешёвую для хранения и всё ещё полезную. Сырые ходы одноразовые. Факты внутри них — обычно нет.

Извлечение: меньше, но более релевантных результатов лучше, чем больше результатов

Та же дисциплина применима ко всему, что извлекается из векторного хранилища или базы данных. Соблазнительно извлекать щедро — топ-10, топ-20 — по теории, что больше контекста не может навредить. Может. Каждый нерелевантный фрагмент — это фрагмент, который модель должна прочитать, взвесить и отбросить, и достаточно большая куча почти-совпадений может перевесить единственный фрагмент, который реально отвечает на вопрос.

Моё значение по умолчанию — начинать с малого k (2-4) и расширять его только тогда, когда я могу показать на реальных случаях, что ответ действительно отсутствует при такой ширине — а не потому, что более широкая сеть кажется безопаснее. Если качество извлечения непостоянно, решение обычно в лучшем запросе или шаге ре-ранжирования, а не в большем k.

Свяжите это со стоимостью и корректностью

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

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

И поскольку изменение того, что находится в окне контекста, меняет поведение так же сильно, как изменение промпта, каждое изменение контекста проходит через тот же шлюз, что и изменение промпта: прогонять его через набор оценок, построенный на реальных производственных сбоях, прежде чем выпускать. Урезание истории или сужение ширины извлечения — именно тот тип «очевидно безопасного» изменения, которое тихо регрессирует крайний случай, если вы не проверите.

Итог оператора

Контекстная инженерия — это решение на каждом ходу, что заслуживает места в ограниченном окне — и стандартный сбой — включить слишком много, а не слишком мало. Держите системные инструкции стабильными и урезайте их в последнюю очередь. Ограничивайте определения инструментов текущим шагом. Извлекайте узко и расширяйте только с доказательствами. Компактизируйте историю в резюме перед тем, как отбросить её, и урезайте сначала самые старые сырые ходы. Затем проверяйте каждое изменение против ваших оценок, потому что изменения контекста меняют поведение точно так же, как изменения промпта — просто легче делать вид, что это не так.

Часто задаваемые вопросы

Что такое контекстная инженерия для ИИ-агентов?

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

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

Да. Промпт-инжиниринг оптимизирует формулировку инструкции. Контекстная инженерия оптимизирует всё остальное, что модель видит рядом с этой инструкцией — какие инструменты предоставлены, что извлечено и сколько истории переносится вперёд. Хорошо сформулированный промпт всё равно потерпит неудачу, если он окружён нерелевантными схемами инструментов или устаревшей историей.

Сколько истории разговора должен хранить ИИ-агент?

Меньше, чем вы думаете. Ограниченное скользящее окно (обычно 10-20 последних ходов) плюс сжатое резюме всего более старого обычно превосходит полную сырую расшифровку, потому что убирает шум, не теряя важные факты. Компактизируйте перед тем, как отбросить историю, а не просто обрезайте её.

Означает ли большее окно контекста, что мне нужно меньше контекстной инженерии?

Нет — это убирает жёсткий технический потолок, но не проблему стоимости или шума. Большее окно делает небрежность дешевле, но каждый нерелевантный токен всё равно разбавляет сигнал, который модели нужно обрабатывать, и всё равно стоит денег при каждом запросе, не попавшем в кэш. Дисциплина важна одинаково и при 200К токенов, и при 8К.

По теме: Как писать системные промпты ИИ-агентов, которые не ломаются в продакшене · Как добавить память ИИ-агенту · Кэширование промптов: снизьте расходы на Claude без смены модели · Стенд оценки, который я использую для выпуска ИИ-агентов

Нужна помощь в проектировании контекста и памяти агента? Свяжитесь со мной — я проектирую продакшн-системы агентов для операторских команд.