# Context Engineering: гайд по управлению контекстным окном LLM и агентов

> Что такое context engineering и как управлять контекстным окном LLM: 6-слойная структура контекста, 4 стратегии, персистентность, субагенты. Практический гайд с примерами из Claude Code.
> Author: Roman Belov · Published: 2026-02-23 · Source: https://futurecraft.pro/ru/blog/context-engineering-guide/

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

[Промпт-инжиниринг](/ru/blog/prompt-engineering-system/) учит *как спросить*. Context engineering — *что дать* модели перед вопросом. И второе определяет качество ответа сильнее, чем первое.

Андрей Карпати [сформулировал](https://x.com/karpathy/status/1937902205765607626) это так: «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)](https://research.trychroma.com/context-rot) показало: точность ответов LLM падает по мере роста количества токенов в контексте, даже если окно далеко от заполнения.

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

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

[Исследование](https://arxiv.org/abs/2307.03172) показало частный случай: производительность LLM падает на 30%+, когда важная информация оказывается в середине длинного контекста. Модель отлично «видит» начало и конец, а середина — слепая зона.

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

### Экономика

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

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

Context engineering — это и [оптимизация бюджета на LLM](/ru/blog/ai-cost-optimization/).

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

При большом контексте модель пытается «использовать всё» и начинает находить ложные связи между несвязанными частями. Данные о компании 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](https://blog.langchain.com/context-engineering-for-agents/) и Anthropic предлагают фреймворк: вся работа с контекстом сводится к четырём действиям.

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

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

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

Каждая сессия с AI-агентом начинается с чистого листа. Новое контекстное окно — нулевая память о предыдущей работе. [Anthropic](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) использует аналогию «инженер-сменщик»: каждый новый инженер, приходя на смену, ничего не помнит о работе предыдущего. Если предыдущий не оставил записей — новому придётся всё делать заново.

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

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

### Git как память

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

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

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

[Пример от Anthropic](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents): агент, играющий в Pokemon, записал «тренировал Пикачу 1234 шага, 8 из 10 уровней». После сброса контекста прочитал свои заметки и продолжил с того же места.

### Scratchpad

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

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

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

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

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

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

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

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

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

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

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

В Claude Code субагенты запускаются через Task tool. Основной агент описывает задачу, субагент получает её в чистом контексте, выполняет работу и возвращает структурированный результат. Расход контекста основного агента — минимальный. Как из субагентов собрать рабочую систему — в гайде по [многоагентной архитектуре](/ru/blog/multi-agent-architecture/).

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

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

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

Решение — ленивая загрузка. Claude Code использует Tool Search: описания инструментов загружаются только по требованию, когда агент решает, что инструмент может понадобиться. Экономия порядка 85% токенов. Для других агентов существуют аналогичные подходы: lazy-mcp, MetaMCP. Как написать собственный MCP-сервер для production — в [отдельном разборе](/ru/blog/mcp-production-custom-servers/).

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

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

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

Контекст в реальных инструментах — не один файл, а многоуровневая система. [Документация Claude Code](https://code.claude.com/docs/en/memory) описывает иерархию:

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

[Мартин Фаулер](https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html) предлагает полезное различие: **Instructions** (приказы — «напиши тест для этой функции») vs **Guidance** (общие правила — «все тесты должны быть независимыми друг от друга»). CLAUDE.md и правила — в основном Guidance. Промпты в чате — Instructions.

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

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

### Чанкинг

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

[Contextual Retrieval от Anthropic](https://www.anthropic.com/news/contextual-retrieval) решает проблему вырванного из контекста чанка: перед индексацией каждому фрагменту добавляется описание — откуда он и о чём раздел в целом. Результат: минимум 35% снижение ошибок поиска, а в комбинации с reranking — до 67%.

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

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

### Map-Reduce

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

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

С ростом окон (Gemini 2M) возникает вопрос: нужен ли ещё RAG? [Исследование (arXiv:2501.01880)](https://arxiv.org/abs/2501.01880) показывает: зависит от задачи — подробный разбор с decision framework и расчётами стоимости смотрите в статье [контекстный инжиниринг против RAG](/ru/blog/context-engineering-vs-rag/).

**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, когда контекст разрастается.

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

---

*Нужна помощь с context engineering и оптимизацией AI-агентов? Я помогаю стартапам внедрять AI-решения и строить продукты — [belov.works](https://belov.works).*