Контекст-инжиниринг вытесняет промпт-инжиниринг агентов

За последний год словарь разработчиков LLM-приложений заметно сдвинулся. В 2023-м все обсуждали, как правильно сформулировать промпт: роль, примеры, цепочку рассуждений. К концу 2024-го Andrej Karpathy и команда Anthropic начали говорить о другом термине — context engineering, управлении тем, что именно лежит в контекстном окне модели на каждом шаге. Для одиночного чата разница почти незаметна. Для агента, который делает десятки вызовов подряд, она определяет, доведёт ли он задачу до конца или зациклится и сожжёт токены впустую.

Разберём, чем эти два подхода отличаются на практике, где проходит граница и что менять в архитектуре, если вы строите не чат-бота, а агента.

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

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

Проблема в том, что промпт статичен. Вы пишете его один раз и надеетесь, что модель справится. В агентном сценарии модель вызывается в цикле: получила задачу, вызвала инструмент, получила результат, снова думает, снова вызывает. К десятому шагу контекстное окно¹ забито историей вызовов, результатами поиска, содержимым файлов и промежуточными рассуждениями. Ваш идеальный системный промпт — это первые 500 токенов из 120 000. Остальное — то, что накопилось само.

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

Контекст-инжиниринг: управление окном на каждом шаге

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

• Отбор релевантного (RAG²). Не подавать в окно весь корпус документов, а достать 3–5 фрагментов, релевантных текущему шагу.
• Сжатие истории. После N шагов свернуть старые вызовы инструментов в короткое резюме, оставив только выводы, а не сырые логи.
• Изоляция подзадач. Запускать вспомогательного агента с чистым окном под узкую задачу, а в основной контекст возвращать только результат.
• Структурирование. Выносить состояние (список задач, найденные факты) в отдельный блок, который переписывается, а не накапливается.
• Отсечение мусора. Убирать из окна результаты неудачных вызовов и повторы, чтобы модель не путалась.

Anthropic в инженерных заметках по агенту Claude описывает это как борьбу с «context rot» — деградацией качества по мере роста заполнения окна. Даже при формально доступных 200 000 токенов у Claude модель хуже удерживает инструкции в начале, когда середина забита данными. Эффект «потери в середине» (lost in the middle) для длинных контекстов подтверждался в исследованиях 2023–2024 годов, но конкретную величину проверяйте по актуальным бенчмаркам вашей модели — цифры разнятся между версиями.

Где проходит граница

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

Цена вопроса в деньгах

Токены стоят денег, и разница между аккуратным и небрежным контекстом измеряется прямо в счёте. Если агент на каждом из 20 шагов тащит в окно всю накопленную историю, объём входных токенов растёт квадратично: на десятом шаге вы платите за девять предыдущих, на двадцатом — за девятнадцать. При работе с моделями уровня GPT-4o или Claude Sonnet вход тарифицируется отдельно от выхода, и раздутый контекст легко удваивает стоимость задачи. Актуальные цены за миллион токенов смотрите на страницах OpenAI и Anthropic — они менялись несколько раз за 2024 год.

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

Кому это пригодится и кому нет

Пригодится, если вы строите:

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

Не пригодится (пока), если у вас:

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

Простой ориентир: если ваш сценарий укладывается в один-два вызова модели, вкладывайтесь в промпт. Если модель работает в цикле с инструментами — вкладывайтесь в контекст.

С чего начать перестройку

1. Залогируйте реальное содержимое окна перед каждым вызовом модели — часто оказывается, что половина токенов там мусор.
2. Введите сжатие истории: после порога по токенам сворачивайте старые шаги в резюме.
3. Вынесите состояние агента (задачи, факты) в отдельный переписываемый блок вместо накопления в диалоге.
4. Для многоисточниковых задач попробуйте суб-агентов с чистым окном, возвращающих только итог.
5. Замерьте стоимость задачи до и после — эффект виден в счёте сразу.

¹ Контекстное окно — максимальный объём токенов (примерно частей слов), который модель обрабатывает за один вызов: системный промпт, история диалога, данные и ответ вместе. У современных моделей это от десятков тысяч до 200 000+ токенов.

² RAG (retrieval-augmented generation) — подход, при котором перед генерацией система ищет релевантные фрагменты в базе данных или документах и подставляет их в контекст, вместо того чтобы полагаться только на знания модели.