Why prompts stopped being enough

Промпт-инжиниринг оптимизирует одну строку: формулировку, роли, few-shot примеры. Пока продукт — это один вызов «вопрос → ответ», этого достаточно. Но агент работает циклами: модель рассуждает, вызывает инструмент, получает результат, рассуждает снова. На каждом шаге в окно попадает не только ваш промпт, а вся рабочая среда: системная инструкция, определения инструментов, история диалога, результаты вызовов, извлечённые документы и заметки памяти.

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

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

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

системный промпт .............   1 500 токенов
определения 20 инструментов ..  16 000 (по 500–1 200 на инструмент)
память и заметки проекта .....   2 000
история 40 сообщений .........  45 000
результаты инструментов ......  60 000 (логи, файлы, JSON)
извлечённые документы ........  20 000
итого ........................ ~145 000 токенов

Сам «промпт» — полторы тысячи токенов из ста сорока пяти, около одного процента. Всё остальное — контекст, который вы либо контролируете осознанно, либо он накапливается сам. Самая тяжёлая статья почти всегда — результаты инструментов: один необрезанный лог сборки или дамп JSON на 30 000 токенов моментально съедает пятую часть окна.

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

Маркетинг обещает окна в 200 тысяч и даже миллион токенов, и возникает соблазн «просто положить всё». Проблема в том, что заявленный размер окна — это предел приёма, а не гарантия качества. Классический бенчмарк «иголка в стоге сена» (needle in a haystack) модели проходят почти идеально, но он проверяет лишь поиск дословной строки. Исследование Chroma «Context Rot» (2025) на 18 моделях показало: даже на простых задачах качество монотонно падает с ростом длины входа, особенно когда ответ требует связать несколько фрагментов или в тексте есть похожие на ответ дистракторы.

Причины фундаментальные. Внимание трансформера сравнивает каждый токен с каждым — попарных связей становится квадратично больше, а «бюджет внимания» размазывается. Обучающих данных с очень длинными последовательностями мало, поэтому модели хуже калиброваны на дальние зависимости. Отсюда эффект «lost in the middle» из работы Liu et al.: факты в начале и в конце окна модель использует заметно лучше, чем в середине.

Важный вывод для практики: нерелевантный документ в контексте — не нейтральный балласт, а активный вред. Дистрактор перетягивает внимание, и модель может опереться на него вместо нужного источника. Минимальный набор высокорелевантных токенов стабильно обыгрывает полный дамп «на всякий случай».

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

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

При этом контекст-инжиниринг включает промпт-инжиниринг, а не заменяет его: системный промпт — это часть контекста, и требования к нему даже растут. Он должен быть коротким, стабильным (мы увидим в следующем уроке, что это критично для кэша) и находиться на «правильной высоте»: не жёсткая логика if-else на все случаи жизни и не размытое «будь полезным», а ясные эвристики поведения. Курс дальше строится именно так: сначала бюджет окна, затем источники контекста, потом компрессия, кодинг-агенты, продакшен и измерение качества.