Короткий ответ: Context engineering для AI-агентов — это дисциплина выбора того, что агент видит на каждом шаге: системные инструкции, инструменты, извлечённые данные, память и предыдущий диалог, — чтобы модель получала минимальный набор высокосигнальных токенов, нужных для верного действия. Это преемник prompt engineering. Prompt engineering оптимизировал одно сообщение; context engineering оптимизирует всю информационную среду, в которой работает агент, на протяжении многих шагов. Причина, почему это важно, контринтуитивна: добавление контекста обычно делает агентов хуже, а не лучше. У моделей конечный бюджет внимания, и качество падает по мере заполнения окна — измеримый эффект, который исследователи теперь называют «context rot». Довести агента до продакшена — это во многом работа по управлению этим окном.

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

От prompt engineering к context engineering

Prompt engineering задавал один вопрос: как сформулировать запрос, чтобы модель дала то, что нужно? Этот вопрос имел смысл, когда взаимодействие было одним ходом — одно тщательно подобранное сообщение, один ответ. Он по-прежнему полезен. Но агент — это не один ход. Агент работает в цикле: читает цель, вызывает инструмент, читает результат, рассуждает, вызывает следующий инструмент и повторяет — иногда десятки раз. К десятому шагу исходный промпт составляет малую долю того, что модель на самом деле читает.

Context engineering задаёт другой вопрос: из всего, что агент мог бы видеть прямо сейчас, что ему действительно нужно — и что стоит убрать? Команда Applied AI в Anthropic, формализовавшая термин в сентябре 2025 года, сформулировала цель точно: найти «наименьший возможный набор высокосигнальных токенов, который максимизирует вероятность желаемого результата». Акцент на наименьшем — и есть весь сдвиг. Prompt engineering был о том, чтобы добавить правильные слова. Context engineering так же часто — о том, чтобы убрать неправильные.

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

Context rot: почему больше контекста делает агентов хуже

Когда агент не справляется, инстинкт — дать ему больше: больше примеров, больше документов, больше истории, больше инструментов. Этот инстинкт, как правило, ошибочен, и теперь это можно измерить.

Исследование Chroma 2025 года формализовало явление под названием context rot: по мере добавления токенов на вход LLM качество вывода падает. В исследовании протестировали 18 фронтир-моделей на возрастающих длинах контекста — деградировала каждая. Важно, что деградация была не только про достижение предела длины. Исследование показало, что семантически похожий, но нерелевантный контент активно сбивал модели с пути — текст-дистрактор, выглядевший релевантным, уводил ответы в сторону сильнее, чем объяснялось одной лишь длиной.

Цифры хуже, чем предполагает большинство команд. По данным исследований, модели показывали заметную деградацию точности задолго до заявленных пределов — некоторые уже около 1000 токенов, а модель, рассчитанная на 200K токенов контекста, может начать деградировать ближе к 50K. Агентная производительность на моделях с заявленными окнами в 1M+ токенов, по сообщениям, резко падает уже около 100K токенов. Заявленное контекстное окно — это вместимость, а не обещание качества на всей этой вместимости.

И это не нишевая инженерная забота — это ведущая причина провалов. По сообщаемым оценкам, значительная доля корпоративных провалов с ИИ в 2025 году связана с дрейфом контекста или потерей памяти при многошаговом рассуждении. Это совпадает с более широким разрывом между хайпом и продакшеном: Gartner прогнозирует, что более 40% агентных ИИ-проектов будут свёрнуты к 2027 году, а большинство оценок относит долю агентных инициатив, так и не дошедших до продакшена, к более чем 80%. Модель редко бывает проблемой. Проблема обычно — контекст вокруг неё.

Бюджет внимания: почему «меньше — значит лучше» здесь буквально

Причина context rot механическая, а не загадочная. Трансформер распределяет внимание по всем токенам в своём окне. По мере роста окна внимание размазывается тоньше — каждому токену достаётся меньшая доля фиксированного бюджета. Одно релевантное предложение становится статистически труднее найти, когда оно окружено десятками тысяч низкосигнальных токенов. Модель не «забыла» важную деталь — она её разбавила.

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

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

Четыре стратегии: write, select, compress, isolate

Сообщество практиков — опираясь на широко цитируемую формулировку LangChain — сошлось на четырёх стратегиях управления контекстом агента. Это не конкурирующие подходы; продакшен-агент обычно использует все четыре.

  1. Write (записывать) — сохранять контекст вне окна. Вместо того чтобы нести всё в промпте, агент записывает состояние, заметки или промежуточные результаты во внешнее хранилище (черновик, объект состояния, постоянное хранилище) и подтягивает их обратно лишь при необходимости. Окно остаётся компактным, и ничего не теряется.
  2. Select (выбирать) — подтягивать только то, что нужно текущему шагу. Это извлечение, сделанное осознанно: достать релевантные документы, релевантные воспоминания и даже релевантные инструменты для этого шага, а не загружать всё по умолчанию. Выбор трёх нужных инструментов из сорока не даёт определениям инструментов вытеснить саму задачу.
  3. Compress (сжимать) — оставлять только токены, нужные для действия. Длинные диалоги суммаризируются; многословные выводы инструментов дистиллируются до сути перед повторным входом в окно. Сжатие меняет небольшую контролируемую потерю детали на крупный прирост плотности сигнала.
  4. Isolate (изолировать) — разделять контекст по границам. Когда задача состоит из нескольких разных работ — изучить большую кодовую базу, разобрать длинный документ, написать резюме — передача всех их одному агенту засоряет его окно. Изоляция даёт каждой подзадаче своего агента с чистым контекстом, а затем объединяет результаты. Каждый суб-агент работает в чистом воздухе.

Суждение — в комбинации. Write и select держат окно релевантным; compress и isolate держат его малым. Устойчивый агент применяет их непрерывно, а не один раз на этапе проектирования.

Что на самом деле живёт в контекстном окне агента

Чтобы инженерить контекст, нужно видеть его как многослойную вещь. На любом шаге окно агента обычно содержит:


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

Context engineering на протяжении долгоживущего агента

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

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

Этот жизненный цикл — ещё и место, где context engineering встречается с остальной работой по доведению агента до продакшена. Те же многошаговые прогоны, что гниют, нужно трассировать и наблюдать, чтобы увидеть, где окно пошло не так, и те же провалы становятся кейсами в вашем eval-харнессе, чтобы доказать, что изменение контекста действительно помогло. Context engineering — одна из граней той же дисциплины, что наблюдаемость и evals: сделать поведение агента читаемым, измеримым и улучшаемым, а не надеяться, что оно удержится.

Частые ошибки, которые мы видим

Несколько ошибок с контекстом встречаются снова и снова, и у них общий корень: отношение к контексту как к тому, во что добавляют, а не к тому, что курируют.

Первая — сваливание. Команды извлекают всё, что может быть релевантным, и предоставляют модели разбираться. Она не может — нерелевантный материал не сидит тихо, он сбивает с пути. Это провал «Dumb RAG»: извлечение, которое достаёт правдоподобно-связанный, но неверный контекст и ухудшает ответ.

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

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

Четвёртая — путать память с историей. Хранить полную стенограмму — это не память; это накопительство. Память — это осознанный выбор того, что должно сохраниться (несколько устойчивых фактов), а не отказ что-либо выбрасывать.

Как к этому подходит Moai Team

Мы относимся к контекстному окну как к главной инженерной поверхности агента, а не как к мысли постфактум, когда промпт уже написан. С первого прототипа мы явно определяем, что содержит каждый слой контекста и почему каждый токен в окне оправдывает своё место. Мы проектируем извлечение так, чтобы выбирать узко, а не сваливать широко, выставляем наименьший полезный набор инструментов на каждом шаге и встраиваем уплотнение и очистку в долгоживущих агентов, чтобы они не гнили за сессию. Мы связываем это с наблюдаемостью, чтобы видеть, что было в окне на любом плохом прогоне, и с evals, чтобы изменение контекста было измерено, а не предположено. Цель — не остроумный промпт, выигрывающий демо. Цель — агент, чей контекст остаётся высокосигнальным на тысячном реальном запросе так же, как на первом, — что в конечном счёте и значит «продакшен».

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

Что такое context engineering для AI-агентов?

Context engineering для AI-агентов — это дисциплина курирования всего, что модель видит на каждом шаге работы агента: системных инструкций, определений инструментов, извлечённых данных, памяти и истории диалога, — чтобы она получала минимальный набор высокосигнальных токенов, нужных для верного действия. Это шире, чем prompt engineering, который оптимизирует лишь одно сообщение; context engineering управляет всей информационной средой на протяжении многих шагов.

Чем context engineering отличается от prompt engineering?

Prompt engineering оптимизирует то, как вы формулируете один запрос. Context engineering оптимизирует всё, что агент видит на протяжении всего многошагового прогона, — и часто означает убирать токены, а не добавлять. Промпт — лишь один компонент контекста; остальные (инструменты, извлечённые данные, история, память) могут сломать агента, даже когда промпт безупречен. По мере того как агент проходит много шагов, context engineering значит куда больше, чем формулировка промпта.

Что такое context rot?

Context rot — это измеримое явление, формализованное исследованием Chroma 2025 года: качество вывода LLM падает по мере добавления токенов на вход. Тестирование 18 фронтир-моделей показало, что деградировала каждая по мере роста контекста, и что семантически похожий, но нерелевантный контент активно сбивал их с пути. Многие модели деградируют задолго до заявленных пределов контекста — поэтому простое «дать агенту больше контекста» обычно делает его хуже.

Каковы четыре стратегии context engineering?

Write (сохранять контекст во внешнее хранилище, чтобы окно оставалось компактным), select (подтягивать только документы, воспоминания и инструменты, нужные текущему шагу), compress (суммаризировать историю и вывод инструментов, оставляя лишь существенные токены) и isolate (разделять задачу между отдельными агентами, чтобы каждый работал в чистом окне). Продакшен-агенты обычно используют все четыре вместе, а не выбирают одну.

Moai Team строит AI-агентов с контекстом, спроектированным с первого прототипа, — узкое извлечение, компактные наборы инструментов и встроенное уплотнение, — чтобы они оставались надёжными на тысячном реальном запросе, а не только на демо. Запланировать звонок.