Когда первая волна внедрения AI-агентов упирается в практику, всплывает неожиданная вещь: агент может исправно ходить в инструменты и при этом «глупеть» ровно в тот момент, когда ему дают больше данных. Вы увеличиваете контекстное окно - и качество ответов не растёт, а проседает. Это не дефект конкретной модели, а фундаментальное свойство того, как работают языковые модели.
Разработка на LLM всё больше смещается от «как написать промпт» к «какую конфигурацию контекста подать в каждый момент». Это направление называют context engineering - и именно здесь решаются и качество, и расход токенов, и безопасность корпоративных данных. Разберём, почему контекст - конечный ресурс, как им управлять и где граница того, что не должно попасть в окно агенту.
Контекст - конечный ресурс, а не «просто длинный промпт»
Промпт-инжиниринг отвечает на вопрос «как написать инструкцию». Контекст-инжиниринг - на более широкий вопрос: «что вообще оказалось в окне у модели в этот момент, и приведёт ли это к нужному поведению». Разница становится заметна на агентах, которые ходят в цикле: с каждым шагом генерируется всё больше данных, потенциально релевантных для следующего шага, и эти данные нужно циклически обрезать.
Идея «просто увеличь окно» решает узкое место по памяти, но не решает проблему внимания. Каждый добавленный токен съедает часть внимания модели. Чем больше токенов в окне - тем меньше точность извлечения информации и дальних связей.
Почему агент деградирует на длинном контексте
Языковые модели устроены на трансформерах, где каждый токен может «общаться» с каждым. Это даёт примерно n² парных связей при длине контекста n. Чем длиннее окно - тем сильнее размывается внимание, и модель теряет способность удерживать дальние зависимости.
Есть и наблюдаемый эффект, который исследователи называют context rot: по мере роста числа токенов падает точность, с которой модель восстанавливает информацию из этого контекста. График у разных моделей разный, но общая кривая одинакова: сначала плато, потом неизбежное проседание. Поэтому контекст стоит считать ресурсом с убывающей предельной отдачей и распоряжаться токенами как бюджетом.
Из чего складывается контекст агента
Чтобы управлять контекстом, сначала разложите его на компоненты:
- Системный промпт. Держите минимальный набор инструкций, который полностью описывает поведение. Не хардкодьте хрупкую логику «if/else», но и не давайте размытые формулировки, которые предполагают общий контекст. Идеал - минимальный промпт, который работает на сильной модели, и точечные добавки по мере нахождения провалов.
- Инструменты (tools). По каждому инструменту модель всегда видит описание, даже если не вызывала его. Лишние инструменты раздувают контекст и создают неоднозначность выбора. Держите минимально жизнеспособный набор инструментов - это упрощает и обслуживание, и сжатие контекста на длинных задачах.
- История сообщений и внешние данные. Это самая быстро растущая часть. Здесь и нужна стратегия подгрузки (ниже).
То, какие инструменты попадают в контекст и какие права они несут, напрямую пересекается с безопасностью. Подача агенту полного каталога инструментов со всеми scope одновременно увеличивает и поверхность атаки, и шум в контексте.
Стратегии подгрузки: заранее vs just-in-time
Классический подход - заранее достать все «релевантные» данные и впихнуть их в окно. На практике это быстро упирается в потолок: корпоративные данные нельзя целиком загрузить, а то, что загружено заранее, часто нерелевантно и раздувает внимание.
Альтернатива - just-in-time: агент держит лёгкие идентификаторы - пути файлов, сохранённые запросы, ссылки - и подгружает данные в окно по мере надобности через инструменты. Метаданные (структура каталогов, имена файлов, таймстампы) служат сигналами, по которым агент решает, что читать. Это позволяет не держать весь корпус в памяти, а вытаскивать нужное на лету.
Лучше всего работает гибрид: немного подгрузить заранее для скорости, остальное отдать агенту на исследование. Явные файлы-инструкции (вроде CLAUDE.md у Claude Code) попадают в контекст сразу, тогда как объёмные данные агент достаёт сам через поиск. Минус у исследования на лету один - оно медленнее, чем чтение готовых данных.
Долгие задачи: компрессия, память, субагенты
Когда задача длиннее контекстного окна, одного окна не хватает. Три рабочие техники:
- Компрессия (compaction). Когда контекст приближается к лимиту, модель резюмирует самое важное, а сырые результаты инструментов отбрасывает. Сохраняются решения, нерешённые баги, ключевые детали - лишний вывод инструментов вычищается. Настраивайте промпт компрессии на реальных трейсах: сначала максимум точности (ничего не потерять), потом точность за счёт вычистки лишнего.
- Агентная память (structured note-taking). Агент регулярно пишет заметки в файл вне контекстного окна и подтягивает их назад по мере работы. Это даёт персистентную память с минимальными накладными расходами: прогресс и зависимости переживают десятки инструментальных шагов и даже сброс контекста.
- Субагенты. Вместо одного агента с распухшим окном - несколько специализированных: каждый исследует свою область с чистым контекстом, а ведущему возвращает только сжатое резюме. Сырые результаты исследований остаются внутри субагента, а не попадают ведущему.
Выбор между техниками зависит от задачи: диалоговая непрерывность - компрессия, итеративная разработка - заметки, параллельное исследование - субагенты.
Граница контекста как граница безопасности
Контекст - это не только про качество, но и про то, что покидает периметр. Всё, что попало в окно, в принципе способно выйти наружу - и не только через ответ, но и через tool descriptions, если в них зашиты чужие инструкции.
Централизованное управление доступом к инструментам и секретам напрямую влияет на то, что вообще может оказаться в контексте. Когда каждый разработчик подключает MCP-серверы локально с полным набором scope и своими токенами, объём потенциально утекающих данных определяется количеством ноутбуков. Когда доступ выдаётся через единую точку с правами конкретного пользователя и без локальных секретов, граница контекста становится управляемой.
Где Codenik: компактный контекст как управляемый слой
Контекст-инжиниринг и безопасность сходятся в одном принципе: агенту нужно отдать наименьший набор высокосигнальных токенов. Codenik работает ровно на этой границе. Он собирает контекст для агента через управляемый слой: выдаёт только одобренные инструменты, прячет секреты корпоративных систем от runtime агента, привязывает каждый вызов к правам пользователя и пишет аудит.
В результате «компактный контекст» - не рецепт на бумаге, а поведение по умолчанию: агент получает точечный набор инструментов и данных вместо дампа, а инженер получает видимость того, что именно попало в окно. Подробнее о модели доступа - в статье «Права доступа для AI-агентов».
Короткий вывод
Хороший контекст - это не самый большой и не самый подробный, а наименьший набор высокосигнальных токенов, который приводит к нужному поведению. Агенты деградируют по мере роста окна, поэтому контекст нужно проектировать: держать системный промпт и инструменты минимальными, подгружать данные just-in-time, а на долгих задачах использовать компрессию, память и субагентов.
И отдельно: граница контекста - граница безопасности. Отдавая агенту мало, но точно, вы одновременно улучшаете качество и сужаете поверхность утечки корпоративных данных.