Контекстная Инженерия: Что Это Такое и Как Я Использую Её для Создания Лучших ИИ-Агентов

Оглавление

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

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

[Заметка оператора] Я управляю более чем 30 агентами в производстве. Улучшение, которое за последний год дало наибольший результат, — это не лучшая модель и не более сложный фреймворк, а осознанность в том, что попадает в контекстное окно, а что остаётся за его пределами. Контекстная инженерия теперь — это основной навык, который я ищу при оценке работы с агентами.

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

Почему «инженерия промптов» стала неправильным фреймом

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

Это верно до определённой степени. Хорошо написанный системный промпт необходим. Но поведение модели определяется всем, что находится в контекстном окне — а не только вашим системным промптом. На него влияют:

• История разговора (что происходило в предыдущих ходах)
• Документы или данные, которые вы извлекли и вставили
• Результаты вызовов инструментов, которые модель видела до сих пор
• Количество токенов и позиция каждого фрагмента информации

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

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

Контекстная инженерия — это дисциплина принятия решений о том, какая информация попадает в контекстное окно модели, в каком порядке, в какой момент разговора.

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

Контекстная инженерия — это практика обращения с этим окном как с ресурсом, управляемым осознанно:

• Что модели нужно знать для выполнения этого шага?
• Что ей нужно было знать на предыдущем шаге, но больше не нужно?
• Что стабильно от запуска к запуску, а что динамично для каждого запроса?
• Где в окне должен появиться каждый фрагмент информации?

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

Четыре слоя, которые я проектирую

Каждый агент, который я создаю, имеет четыре отдельных слоя контекста. Я думаю о каждом из них отдельно.

Слой 1: Системный промпт

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

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

1. Для чего этот агент? (Модели нужна чёткая область, а не расплывчатая миссия.)
2. Что должен делать, когда входные данные неоднозначны или неполны?
3. Что он никогда не должен делать? (Негативные ограничения важны.)

Держите системный промпт минимальным. Каждое ненужное предложение — это накладные расходы, которые конкурируют с динамическим контентом, где происходит реальное рассуждение.

Практический совет: если вы используете Claude с API, применяйте cache_control к своему системному промпту. Большой, стабильный системный промпт в кэше стоит примерно 10% от того, что стоил бы некэшированный за ход.

Слой 2: История разговора

В многоходовом агенте история разговора динамична и растёт с каждым ходом. Без управления она становится главным источником раздувания контекста.

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

Что я делаю:

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

Слой 3: Извлечённый контент

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

Два принципа, которые я применяю:

Извлекать только то, что актуально для текущего шага. Не вставляйте документ на 50 страниц, если текущему шагу нужен только один раздел.

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

Слой 4: Выводы инструментов

В агентском цикле модель вызывает инструменты и получает результаты. Эти результаты накапливаются. И в отличие от истории разговора, люди редко думают об их управлении.

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

Бюджет контекста: что включать и что исключать

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

• Что модели нужно знать прямо сейчас для выполнения этого шага?
• Что можно опустить или резюмировать, не теряя ничего важного?
• Что дублируется между слоями?

Цель — заполнить окно максимально информативными данными на каждом шаге, а не быть исчерпывающим.

Три ошибки контекстной инженерии, которые я допустил в производстве

1. Плавающие метки времени в стабильном префиксе. Я помещал Текущая дата: {{дата}} в верхнюю часть системного промпта. Эта строка меняется каждый день, что бесшумно аннулировало мой кэш промптов каждые 24 часа. Перемещайте нестабильную информацию — метки времени, идентификаторы пользователей — в конец контекста, после стабильного префикса.

2. Отношение к выводам инструментов как к только-добавляемым. Я запускал агентские циклы, где каждый результат вызова инструмента оставался в контексте. К 8-му ходу модель рассуждала из контекста, который на 80% состоял из устаревших выводов инструментов.

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

Мой рабочий процесс контекстной инженерии на практике

Перед написанием единой строки кода агента я набрасываю слои контекста:

Системный промпт:        ~500 токенов, стабильный, кэшированный
Бюджет истории:          ~2000 токенов макс., резюмируется после каждого шага
Извлечённый контекст:    ~1000-3000 токенов за шаг, только актуальные фрагменты
Бюджет выводов:          только текущий шаг, резюмируется вперёд

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

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

В чём разница между инженерией промптов и контекстной инженерией?

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

Насколько большим должен быть системный промпт?

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

Важнее ли контекстная инженерия для одних моделей, чем для других?

Она важна для всех, но ставки выше с меньшими моделями. Большая фронтирная модель иногда может восстановиться от плохо структурированного контекста; меньшая модель с более жёстким бюджетом — нет.

Как узнать, работает ли моя контекстная инженерия?

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

Должен ли я всегда сжимать или резюмировать историю?

Для коротких транзакционных агентов: нет. Для многоходовых агентов с более чем 5-6 обменами: да, всегда. Практическое правило, которое я использую: как только бюджет истории превышает 30% от общего бюджета контекста, я начинаю резюмировать.