Context Engineering: как управлять контекстом для AI-моделей и агентов

У Claude контекстное окно на 200 000 токенов. У Gemini - до двух миллионов. Но качество ответов начинает деградировать задолго до заполнения окна. Размер окна не решает проблему контекста - он её маскирует.

Промпт-инжиниринг учит как спросить. Context engineering - что дать модели перед вопросом. И второе определяет качество ответа сильнее, чем первое.

Андрей Карпати сформулировал это так: «Context engineering - the delicate art and science of filling the context window with just the right information for the next step». Тоби Лютке, CEO Shopify, популяризировал сам термин, а Gartner в июле 2025 прямо заявил: «Context engineering is in, and prompt engineering is out».

Здесь - конкретные техники, модели и паттерны. То, что реально работает при ежедневном использовании AI-агентов в разработке.

Промпт vs контекст: где проходит граница

Аналогия, которая хорошо объясняет разницу: вы нанимаете эксперта-консультанта.

Промпт - ваш вопрос: «Как мне поступить?» Контекст - досье, которое вы ему даёте перед вопросом.

Можно идеально сформулировать вопрос, но если в досье 500 страниц нерелевантных документов - даже сильный эксперт запутается. И наоборот: дайте ровно те 2 страницы, которые нужны - даже простой вопрос даст точный ответ.

Промпт-инжиниринг отвечает на вопросы: как сформулировать задачу, какую роль дать модели, в каком формате попросить ответ. Context engineering - на другие: дать 100 отзывов или выбрать 15 репрезентативных? Весь файл на 500 строк или только строки 45–80? Всю документацию или извлечь факты?

Техническая аналогия ещё точнее. LLM - это CPU. Контекстное окно - RAM. Вы - операционная система, которая решает, что загрузить в рабочую память. Задача - загрузить ровно те данные, которые нужны для текущей операции.

Почему больше контекста - хуже

Это контринтуитивно, но подтверждено исследованиями.

Деградация контекста (Context Rot)

Исследование Chroma (2025) показало: точность ответов LLM падает по мере роста количества токенов в контексте, даже если окно далеко от заполнения.

Механизм: внимание модели - фиксированный ресурс. Сумма весов внимания всегда равна 1. Больше токенов - меньше внимания каждому фрагменту. Как фонарик: чем шире луч, тем слабее свет в каждой точке. И чем сложнее задача, тем сильнее деградация.

Потеря в середине (Lost in the Middle)

Исследование показало частный случай: производительность LLM падает на 30%+, когда важная информация оказывается в середине длинного контекста. Модель отлично «видит» начало и конец, а середина - слепая зона.

Практический вывод: размещайте важное в начале или в конце контекста. Системный промпт - в начале. Примеры (few-shot) - в конце.

Экономика

Каждый токен стоит денег, и модель перечитывает весь контекст при каждом запросе (LLM stateless):

• Input: ~$3 за 1M токенов (Claude Sonnet)
• 100K контекста x 100 запросов/день = ~$30/день = $900/месяц

Context engineering - это и оптимизация бюджета.

Галлюцинации от избытка

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

Шесть слоёв контекста

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

┌─────────────────────────────────────────┐
│  1. SYSTEM - кто ты и как себя вести    │  ← Постоянный (начало)
├─────────────────────────────────────────┤
│  2. PROJECT - контекст проекта          │  ← Полупостоянный
├─────────────────────────────────────────┤
│  3. TASK - конкретная задача            │  ← Для каждой задачи
├─────────────────────────────────────────┤
│  4. DIFF / КОД - релевантные фрагменты │  ← Для каждой задачи
├─────────────────────────────────────────┤
│  5. ACCEPTANCE CRITERIA - критерии      │  ← Для каждой задачи
├─────────────────────────────────────────┤
│  6. ПРИМЕРЫ (Few-shot) - образцы        │  ← Опционально (конец)
└─────────────────────────────────────────┘

System: роль и поведение

Кто модель и как себя вести. Всегда в самом начале.

Ты - опытный backend-разработчик на Python и FastAPI.
Отвечай кратко. Используй type hints. Не добавляй зависимости без запроса.

Сюда идёт роль, стиль ответов, ограничения. Сюда не идут детали конкретной задачи - для этого слой 3.

Project: контекст проекта

Стек, структура, архитектурные решения, конвенции кода. Этот слой переиспользуется между задачами. В Claude Code он живёт в файле CLAUDE.md - агент читает его автоматически при каждом запуске.

Task: что делать

Чёткое описание задачи, зачем это нужно, и - что часто забывают - что не нужно делать.

Хороший пример:

Задача: Добавить rate limiting для /users.
Контекст: эндпоинт не защищён, боты перегружают.
Требования: 100 req/min на IP, Redis для счётчиков, 429 при превышении.
Не нужно: менять логику эндпоинта, добавлять авторизацию.

Плохой пример: «Сделай rate limiting».

Diff/Код: только релевантное

Давайте только те фрагменты кода, которые относятся к задаче. Не весь файл. Указывайте путь и строки: app/api/users.py, строки 45–60.

Acceptance Criteria: когда остановиться

Чёткие, проверяемые условия. Модель знает, когда остановиться, только если вы ей скажете. Без критериев она будет либо недоделывать, либо переделывать.

- [ ] При превышении лимита - статус 429
- [ ] Заголовок Retry-After в ответе
- [ ] Unit-тесты покрывают edge cases

Примеры (Few-shot): в конце

Для нестандартных форматов вывода или специфичного стиля. Размещать в конце контекста - модель лучше «видит» финал.

Что вредно класть в контекст

Несколько антипаттернов, которые гарантированно ухудшают результат:

• Весь код проекта - сигнал тонет в шуме
• Противоречивые инструкции - «используй Redux» + «используй Context API» = модель путается
• Устаревшие примеры - код с deprecated API модель воспроизведёт буквально
• Размытые формулировки - «сделай лучше» не даёт модели направления

Четыре стратегии управления контекстом

LangChain и Anthropic предлагают фреймворк: вся работа с контекстом сводится к четырём действиям.

Стратегия	Что делает	Пример
Write	Сохранять вовне	Scratchpads, MEMORY.md, файлы прогресса
Select	Извлекать только релевантное	RAG, grep, поиск по коду
Compress	Сжимать	Compaction, суммаризация, очистка tool results
Isolate	Изолировать задачи	Субагенты с чистым контекстом

Все техники, описанные ниже - частные случаи одной из четырёх.

Персистентность: мост между сессиями

Каждая сессия с AI-агентом начинается с чистого листа. Новое контекстное окно - нулевая память о предыдущей работе. Anthropic использует аналогию «инженер-сменщик»: каждый новый инженер, приходя на смену, ничего не помнит о работе предыдущего. Если предыдущий не оставил записей - новому придётся всё делать заново.

Простые файлы

Самая базовая форма памяти - markdown-заметки, которые агент пишет для самого себя в будущем. Claude Code использует для этого MEMORY.md: агент автоматически записывает туда паттерны проекта, решения, архитектурные заметки.

Git как память

Коммиты с осмысленными сообщениями - лог изменений и точки восстановления. Агент может экспериментировать, зная, что всегда можно откатиться.

Структурированные заметки

Эволюция простых файлов. Агент ведёт структурированную базу знаний, а не плоский лог. Паттерн: write_to_notes(topic, content) + read_from_notes(topic) - внешний «жёсткий диск» памяти.

Пример от Anthropic: агент, играющий в Pokemon, записал «тренировал Пикачу 1234 шага, 8 из 10 уровней». После сброса контекста прочитал свои заметки и продолжил с того же места.

Scratchpad

Рабочая память внутри текущей сессии. Агент «думает вслух» - хранит промежуточные результаты, гипотезы, план. Отличие от файлов состояния: scratchpad - рабочая память, файлы - долгосрочное хранение.

Простая мысль, но она меняет подход: не заставляйте модель всё помнить. Дайте ей блокнот.

Сжатие контекста (Compaction)

Когда контекст заполняется, его можно сжать. Модель получает всю историю и делает резюме. Старый диалог отбрасывается, в начало нового контекста помещается сжатая версия.

Ручное сжатие в логических точках (после завершения фичи) надёжнее автоматического. Есть ещё безопасная форма: очистка результатов инструментов - убираем из истории объёмные выводы команд, оставляя только факт выполнения.

Таск-трекеры

Для долгосрочных проектов работает паттерн «Инициализатор + Исполнитель». Первый агент не пишет код - он создаёт структурированный список задач в JSON: description, status, dependencies. Каждый следующий агент читает список, берёт pending-задачу, выполняет, обновляет статус, коммитит.

Субагенты: изоляция как стратегия

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

Три преимущества:

1. Чистота контекста. Субагент не загрязнён историей основного агента. У основного может быть 85% окна занято - субагент начнёт с 5%.
2. Специализация. Можно использовать разные модели или системные промпты для разных субагентов.
3. Параллелизация. Несколько субагентов могут работать одновременно.

В Claude Code субагенты запускаются через Task tool. Основной агент описывает задачу, субагент получает её в чистом контексте, выполняет работу и возвращает структурированный результат. Расход контекста основного агента - минимальный.

MCP и налог на инструменты

MCP (Model Context Protocol) - открытый стандарт, который определяет, как AI-агенты обнаруживают и вызывают инструменты. Каждый MCP-сервер добавляет описания своих инструментов в контекст. И каждое описание стоит токенов.

Проблема видна сразу, как только начинаешь работать всерьёз: подключите 5-10 MCP-серверов (GitHub, Slack, база данных, аналитика, мониторинг) - и получите десятки тысяч токенов описаний инструментов в каждом запросе, даже если ни один из них не вызывается.

Решение - ленивая загрузка. Claude Code использует Tool Search: описания инструментов загружаются только по требованию, когда агент решает, что инструмент может понадобиться. Экономия порядка 85% токенов. Для других агентов существуют аналогичные подходы: lazy-mcp, MetaMCP.

Принципы дизайна инструментов:

• Самодостаточность: описание содержит всё необходимое для использования. Модель не читает ваш README.
• Однозначность: вместо data - user_email, вместо process - validate_payment.
• Минимализм: один инструмент = одна атомарная операция. Если описание > 200 слов - инструмент делает слишком много.

Иерархия памяти

Контекст в реальных инструментах - не один файл, а многоуровневая система. Документация Claude Code описывает иерархию:

• System prompt - базовые инструкции (всегда загружен)
• Settings - пользовательские настройки
• CLAUDE.md - инструкции проекта (загружается из корня репозитория)
• Rules - модульные инструкции, могут быть path-specific (загружаются только при работе с определёнными файлами)
• Skills - целые папки с инструкциями и скриптами, которые агент загружает по своему выбору
• Auto Memory - память, которую агент формирует сам для себя

Мартин Фаулер предлагает полезное различие: Instructions (приказы - «напиши тест для этой функции») vs Guidance (общие правила - «все тесты должны быть независимыми друг от друга»). CLAUDE.md и правила - в основном Guidance. Промпты в чате - Instructions.

Работа с большими документами

PDF на 50 страниц нельзя просто скормить модели. Нужна стратегия.

Чанкинг

Разбиение на части по 1500–3000 токенов с перекрытием 10–20%. Семантический чанкинг (по главам и разделам) работает заметно лучше разбиения по фиксированной длине.

Contextual Retrieval от Anthropic решает проблему вырванного из контекста чанка: перед индексацией каждому фрагменту добавляется описание - откуда он и о чём раздел в целом. Результат: минимум 35% снижение ошибок поиска, а в комбинации с reranking - до 67%.

Извлечение фактов

Вместо работы с полным текстом - структурированный список фактов и цифр из каждого чанка. Компактнее и точнее для задач анализа.

Map-Reduce

Для очень больших документов: разбить на чанки, суммаризировать каждый (MAP), собрать мини-саммари в финальное (REDUCE). MAP-фазу можно параллелить - ускорение пропорционально числу воркеров.

RAG vs длинный контекст

С ростом окон (Gemini 2M) возникает вопрос: нужен ли ещё RAG? Исследование (arXiv:2501.01880) показывает: зависит от задачи.

RAG побеждает: корпус огромный (> 1M токенов), нужна актуальность, бюджет ограничен.

Длинный контекст побеждает: нужен синтез из разных частей, понимание структуры, документ < 200K.

Гибрид (рекомендуется): RAG для отбора, длинный контекст для анализа. По стоимости разница ощутимая: полный 2M-контекст на каждый запрос обходится в десятки раз дороже, чем RAG-выборка + 50K релевантного контекста.

Где это не работает

Было бы нечестно остановиться на плюсах.

Context engineering не исправит плохую модель

Если модель не умеет писать код на Rust - никакой контекст не поможет. Context engineering работает в пределах возможностей модели. Если задача сама по себе слишком сложна для текущего поколения моделей, стоит разбить её на подзадачи или использовать другой подход.

Overhead на подготовку контекста

Собрать идеальный контекст-пакет из шести слоёв для каждого запроса - дорого по времени. Для быстрых вопросов («как работает эта функция?») это избыточно. Context engineering окупается на повторяемых задачах и при работе с агентами, которые выполняют десятки операций в цепочке.

Compaction теряет информацию

Сжатие контекста - компромисс. Модель решает, что оставить, а что выбросить. Иногда выбрасывает важное. Ручное сжатие в логических точках надёжнее, но требует внимания оператора.

Lost in the Middle работает и в обратную сторону

Можно настолько увлечься размещением «важного в начале и конце», что середина станет свалкой нерелевантного. Лучше сократить контекст, чем надеяться на позиционирование.

Субагенты добавляют задержку

Делегирование субагенту - это отдельный API-вызов с отдельным контекстом. При сложной задаче один субагент запускает десятки запросов. Для real-time сценариев это бывает слишком медленно.

Ленивая загрузка инструментов - не бесплатна

Tool Search экономит контекст, но добавляет шаг поиска. Если агент ищет инструмент перед каждым действием - это лишние запросы и время. Баланс между количеством инструментов в контексте и частотой поиска приходится настраивать.

Типичные ошибки

Три ошибки, которые встречаются чаще остальных:

1. Копировать весь файл вместо релевантного фрагмента. Модель получает 500 строк, а нужны были строки 45–60. Остальные 440 строк - чистый шум.
2. Не указывать, что НЕ нужно делать. Без ограничений модель будет рефакторить весь файл, когда просили поправить одну функцию.
3. Забывать про acceptance criteria. Модель не знает, когда остановиться. Результат - либо недоделанный, либо переусложнённый ответ.

Чеклист

Практический чеклист для каждого серьёзного запроса к модели.

Перед запросом:

• Есть ли источник истины (документация, код, данные) в контексте?
• Описано ли чётко, что нужно сделать?
• Указан ли формат ответа?
• Указано ли, что НЕ нужно делать?

В промпте:

• «Отвечай только на основе предоставленного контекста»
• «Если не знаешь - скажи, что не знаешь»

После ответа:

• Проверены ли факты?
• Существуют ли упомянутые функции и библиотеки?
• Не приписаны ли характеристики одного объекта другому?

Вместо итогов

Пять принципов, которые стоит запомнить:

1. Меньше = лучше. Качество и релевантность контекста важнее количества. Цель - наименьший набор токенов с самым сильным сигналом.
2. Структурируйте. Шесть слоёв: System, Project, Task, Code, Criteria, Examples. Важное - в начало и конец.
3. Сохраняйте. Персистентность = мост между сессиями. Файлы состояния, structured notes, git.
4. Изолируйте. Субагенты с чистым контекстом для специализированных задач.
5. Сжимайте. Compaction и очистка tool results, когда контекст разрастается.

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

FAQ

При каком количестве токенов деградация контекста становится практически заметной и есть ли порог для мониторинга?

Ряд бенчмарков (включая исследования Chroma и других) показывает измеримое падение точности начиная примерно с 20–30K токенов для задач со сложными рассуждениями, с более резким падением после 50K. Для простых задач извлечения порог выше — около 80–100K. Практическое правило мониторинга: если средний контекст превышает 40K токенов на запрос и вы наблюдаете нестабильное качество — размер контекста первая переменная для анализа. Расчёт $900/месяц в статье предполагает 100K токенов; большинство продакшн-агентов могут сократить это на 60–70% через выборочный RAG-поиск без измеримого снижения качества.

Как ленивая загрузка инструментов в Claude Code достигает экономии 85% токенов и каков фактический механизм?

Без ленивой загрузки полная схема каждого MCP-сервера внедряется в системный промпт при каждом запросе — 10 серверов по 5 инструментов при ~200 токенах на описание инструмента дают 10 000 токенов накладных расходов на каждый вызов, независимо от того, какие инструменты реально используются. Tool Search откладывает внедрение схемы: агент сначала отправляет семантический поисковый запрос для нахождения релевантных имён инструментов (~50 токенов), затем загружает только описания подходящих инструментов (~400 токенов для 2 инструментов). Экономия 85% получается за счёт устранения полного дампа схемы для 8–9 неиспользуемых инструментов в типичном запросе.

Когда использовать ручное сжатие контекста вместо автоматического и какая информация обычно теряется?

Ручное сжатие в логических точках (завершение фичи, после прохождения тест-сьюта) надёжнее, потому что вы контролируете, что попадёт в резюме. Автоматическое сжатие срабатывает при заполнении окна и суммаризирует то, что есть на момент триггера — включая незаконченные рассуждения, временное отладочное состояние или противоречивые инструкции из пивотов середины сессии. Наиболее распространённая потеря — архитектурные решения, принятые в диалоге: «давай не используем здесь Redux, потому что X» выживает в ручном резюме, но отбрасывается автоматическим сжатием, которое воспринимает его как временный чат, а не обязывающее ограничение.