AI Engineering Course

Context Engineering

Лекция 6

Фокус: контекстное окно, токены, стратегии, memory

Содержание

1. Два разработчика

$3 vs $0.30 — в чём разница

2. Токен — атом контекста

BPE, валюта, расходы

3. Контекстное окно

Зоны, позиции, bias

4. Что съедает контекст

Пожиратели и кривая деградации

5. Стратегии управления

Вход, история, структура работы

6. Memory

Контекст за пределами сессии

7. Подводные камни

4 типичные ловушки

8. Итоги и практика

Выводы и задание

Часть 1

Два разработчика, одна задача

Одна модель, один инструмент — результат отличается на порядок

Один и тот же инструмент — разный результат

Разработчик 1

$3.00 за задачу

4 итерации, каждая — уточнение, откат, повтор. Модель путается в контексте, забывает ранние инструкции, генерирует лишнее.

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

Разработчик 2

$0.30 за задачу

1 итерация. Чёткая структура запроса, нужный контекст подан заранее, лишнее отсечено. Модель сразу попала в цель.

Результат: чистый, готовый к коммиту. Без правок.

Разница не в модели и не в промпте. Разница — в управлении контекстом.

Context Engineering: определение

Context Engineering — осознанное проектирование того, что попадает в контекстное окно модели: что подать, в каком объёме, в каком порядке — и что отсечь.

Prompt Engineering

Фокус на формулировке запроса. «Как спросить». Один текст, одна попытка.

Context Engineering

Фокус на всём контекстном окне. «Что модель видит в момент генерации». Системный промпт, история, файлы, tool outputs, memory — всё вместе.

Prompt Engineering — подмножество Context Engineering. Хороший промпт необходим, но недостаточен: если контекст забит мусором, формулировка не спасёт.

Метафора: контекст = расчётный счёт

Расчётный счёт

Контекстное окно модели — фиксированный бюджет. У Claude Sonnet — 200K токенов. Каждый токен, отправленный в окно, тратит из этого бюджета.

Валюта — токен

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

Задача context engineer'а: максимизировать полезную информацию на единицу бюджета. Не «впихнуть побольше», а подать нужное в нужном объёме.

Часть 2

Токен — атом контекста

Прежде чем управлять — нужно понимать единицу измерения

Что такое токен

Токен — минимальная единица текста, которую видит модель. Не буква, не слово — нечто среднее. Токенизатор разбивает любой текст на последовательность токенов из фиксированного словаря.

Английский: ~1 токен = 0.75 слова (4 символа)
Русский: ~1 токен = 0.5 слова (дороже из-за кириллицы)
Код: скобки, отступы, ключевые слова — каждый элемент отдельный токен

Пример токенизации

"Привет, мир!"

→ ["При", "вет", ",", " мир", "!"] — 5 токенов

"Hello world"

→ ["Hello", " world"] — 2 токена

Русский текст в ~1.5-2 раза дороже английского по токенам.

BPE: как строится словарь токенов

Byte Pair Encoding (BPE)

Алгоритм, которым обучается токенизатор. Начинает с отдельных байтов и шаг за шагом склеивает самые частые пары.

Шаг 1

Начинаем с байтов: каждый символ — отдельный токен

→

Шаг 2

Находим самую частую пару (например, t+h) и склеиваем в один токен

→

Шаг 3

Повторяем до нужного размера словаря (~100K токенов)

→

Результат

Частые слова = 1 токен, редкие = несколько

BPE строит словарь по обучающим данным. Английского текста в них больше всего → английские слова компактнее. Кириллица, иероглифы, редкий код — дороже.

Что сколько стоит в токенах

Контент	Объём	Токены (примерно)	Доля окна 200K
Системный промпт (средний)	~2 000 слов	~3 000	1.5%
AGENTS.md / CLAUDE.md	~1 500 слов	~2 500	1.2%
Файл исходного кода (300 строк)	~5 000 символов	~2 000	1%
Вывод `ls -la` (50 файлов)	~3 000 символов	~1 200	0.6%
Полный `package.json`	~2 000 символов	~800	0.4%
Stack trace (ошибка)	~1 500 символов	~600	0.3%
10 раундов диалога	~8 000 слов	~12 000	6%
Вся кодовая база (средний проект)	~500 файлов	~500 000+	250%+

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

Токен как валюта: фиксированные и переменные расходы

Фиксированные расходы

Платим каждый запрос, нельзя уменьшить до нуля:

Системный промпт
AGENTS.md / CLAUDE.md
Описания инструментов (tools schema)
Правила и constraints

Обычно ~5-15% окна.

Переменные расходы

Растут с каждым ходом сессии:

История диалога (user + assistant)
Вывод инструментов (file reads, shell output)
Промежуточные рассуждения модели
Файлы, подгруженные по ходу работы

Основной потребитель. Именно здесь — рычаг оптимизации.

Правило: минимизируй фиксированные, контролируй переменные. Контекст, который не помогает текущей задаче, — это шум, за который ты платишь.

Часть 3

Контекстное окно

Не буфер, а структура с зонами

Зоны контекстного окна

Контекстное окно — максимальное количество токенов, которые модель видит одновременно. Всё, что за пределами, для модели не существует. Внутри — шесть чётких зон:

Зона	Что в ней	Кто контролирует
System prompt	Инструкции инструмента, rules, skills	Инструмент + вы (CLAUDE.md, AGENTS.md)
MCP-схемы	Описания подключённых MCP-серверов и их tools	Инструмент
История диалога	Сообщения пользователя + ответы модели	Накапливается автоматически
Tool calls + результаты	Вызовы инструментов и их выходные данные	Агент
Текущий запрос	Ваше последнее сообщение	Вы
Ответ модели	Генерируемый текст	Модель

Это не техническое ограничение, которое скоро «уберут». Это принципиальное устройство трансформерной архитектуры.

Фиксированные vs переменные расходы контекста

Фиксированные = «аренда офиса»

System prompt, MCP-схемы — присутствуют в каждой сессии, независимо от задачи.

Сократить: оптимизировать system prompt, подключать только нужные MCP-серверы.

Переменные = «операционные расходы»

История диалога, результаты вызовов инструментов — растут с каждым шагом агента.

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

Ответ модели = «зарплата»

Генерируемый текст — отдельная статья расходов.

Влиять можно лишь косвенно: через чёткость задачи и инструкции по формату вывода.

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

Primacy/recency bias + размеры окон 2026

Primacy/recency bias

Модель уделяет больше внимания началу и концу контекста. Середина длинного окна усваивается хуже.

Инструкция в system prompt весит больше, чем та же инструкция в середине истории
Критическая информация — в начало (system prompt) или конец (свежее сообщение)
Где лежит информация — не менее важно, чем что в ней написано

Модель	Контекстное окно
Claude 3.x / 4.x	200 000 (Opus 4.6 / Sonnet 4.6 — до 1 000 000)
GPT-4.1	1 000 000 токенов
Gemini 1.5 / 2.x	1–2 000 000 токенов
GLM 5.1	200 000 токенов

Большое окно не устраняет bias: середина миллионного контекста усваивается не лучше, чем середина двухсоттысячного.

Часть 4

Что съедает контекст

Главные пожиратели — не ваши промпты

Иллюзия контроля

Ваш запрос: 50 токенов

В окне уже лежат:

15 000 токенов — system prompt
8 000 токенов — MCP-схемы
40 000 токенов — накопленная история

50 токенов = 0.08% от того, что видит модель

Большую часть «голоса» в разговоре имеют не ваши слова, а то, что заложено заранее или накопилось в процессе.

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

1. Результаты вызовов инструментов

Read файла — 2-5K токенов за вызов. Ответ MCP-сервера — 10-20K. За сессию десятки вызовов — все результаты оседают в истории.

2. Накопленная история

После 20-30 шагов — легко 100K+ токенов. 80% объёма — устаревшие результаты инструментов из ранних шагов, которые уже не нужны.

3. Фиксированные накладные расходы

10 MCP-серверов × 50 tools = тысячи токенов описаний. Присутствуют в каждом запросе. Не накапливаются — но всегда здесь.

4. Избыточная вежливость модели

Пересказ задачи, вводные фразы, повтор запроса «для ясности» — 5-15% каждого ответа. Не несут полезной нагрузки, но оседают в истории.

Два разработчика: другой взгляд + кривая деградации

Разработчик 1

12 MCP-серверов «на всякий случай»

Расплывчатый запрос

30 шагов → 80K устаревших результатов

Контекст переполнен, модель теряет фокус

$3.00 — посредственный результат

Разработчик 2

3 целевых MCP-сервера

Конкретный запрос

1 проход — компактная история

Модель держит фокус на задаче

$0.30 — чистое решение

Кривая деградации

Качество не падает плавно по мере заполнения контекста.

До 60-70% заполнения — работа приемлемая
После этой отметки — резкий скачок ухудшения
Модель забывает инструкции, повторяет сделанное, путается

Это скачок, а не наклон. К 70% — либо завершайте, либо сбрасывайте контекст.

Часть 5

Стратегии управления

Сокращение входа · Управление историей · Структура работы

5.1 Сокращение входа — «не клади лишнее»

Целевые вызовы инструментов

Read с offset и limit — нужный фрагмент, а не весь файл. Grep с конкретным паттерном и фильтром по типу файла.

500 vs 5 000 токенов за один вызов. Умножьте на десятки вызовов в сессии.

Гигиена MCP-серверов

Каждый подключённый MCP-сервер — фиксированные расходы в каждом запросе.

10 лишних серверов — тысячи «холостых» токенов. Подключайте только нужные для текущей сессии.

System prompt как бюджетная строка

500 строк правил — ~3-5K токенов постоянного расхода.

Если инструкция не влияет на каждую сессию — выносите в skill или отдельный файл.

5.2 Управление историей — «чисти за собой»

Новая сессия как инструмент

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

Артефакты на диске: файлы, конспекты, записи о решениях — обеспечивают передачу контекста без мусора.

Compact: сигнал vs шум

compact сжимает накопленную историю в резюме.

Если история — 80% устаревших результатов инструментов — потери невелики. Если плотная и каждый шаг нёс решение — потери ощутимы.

Что теряется при сжатии

Суммаризатор сохраняет: «что сделано», «к чему пришли».

Теряет: точные имена файлов, номера строк, результаты конкретных вызовов. Критические решения должны жить в файлах на диске.

5.3 Структура работы — «думай до того, как начал»

Декомпозиция для контекста

Разбиение задачи на подзадачи — это про чистое окно для каждого субагента.

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

«Делегируем не потому что быстрее, а потому что один агент не удержит весь контекст»

Порядок имеет значение

Сначала — контекст, потом — задача. Не наоборот.

Если начинаете с задачи, а детали потом — модель уже построила первичное представление без части вводных.

Primacy/recency bias на практике: важная информация — до формулировки требования.

Одна задача на сессию

К третьей просьбе в той же сессии контекст забит артефактами первых двух.

Модель отвечает на третью задачу сквозь фильтр двух предыдущих.

Открытая сессия не сохраняет «фокус» — она накапливает помехи.

Сводная таблица стратегий

Стратегия	На что влияет	Порядок экономии
Read/Grep с ограничениями	Переменные расходы на tool calls	5-10x за один вызов
Подключать только нужные MCP-серверы	Фиксированные расходы (каждый запрос)	1-5 тысяч токенов на запрос
Краткий и точный system prompt / AGENTS.md	Фиксированные расходы (каждый запрос)	2-4 тысячи токенов на запрос
Новая сессия вместо накопления истории	Переменные расходы (история диалога)	Десятки тысяч токенов
Compact при шумной истории	Переменные расходы (история диалога)	30-70% объёма истории
Декомпозиция на субагентов	Полный объём контекста задачи	Чистое окно для каждой части
Порядок: контекст → задача	Качество понимания при фиксированном объёме	Качественный, не количественный эффект

Принцип: экономить на шуме, не на сигнале. Устаревшие результаты инструментов — шум. Подробное описание задачи и ограничений — сигнал.

Часть 6

Memory

Контекст за пределами одной сессии

6.1 Проблема + три уровня памяти

Новая сессия — чистый лист. Агент не знает про вчерашние решения, выбранный стек, согласованные ограничения. Каждое «переоткрытие» — потраченные токены и риск противоречия.

Уровень	Что хранит	Время жизни	Пример
Файлы проекта	Решения, правила	Пока в репо	CLAUDE.md, spec
Проектная память	Факты, предпочтения	Между сессиями	CC project memory
Персональная память	Роль, стиль	Между проектами	~/.claude/memory/

6.2 Что хранить / чего не хранить

Хранить

Решения, которые нельзя вывести из кода или git
Неочевидные предпочтения
Ссылки на внешние системы, не представленные в репозитории

Не хранить

Структуру проекта — можно получить за один вызов инструмента
Паттерны кода — модель видит их в файлах
Историю коммитов — доступна через git log

Принцип: Memory — кэш, не архив. Хранить то, что дорого получить заново.

6.3 Поддержка в инструментах

Claude Code

~/.claude/projects/<project>/memory/ — файлы с frontmatter, индекс MEMORY.md загружается в каждую сессию.

Дополнительные файлы подгружаются по ссылкам из индекса.

Kilo Code

Memory bank через файлы в .kilocode/rules/memory-bank/, per-workspace.

С 2026 года рекомендуется использовать AGENTS.md.

OpenCode

Сессии сохраняются локально; межсессионная память — через сторонние расширения (opencode-mem и др.).

Часть 7

Подводные камни

4 ловушки context engineering

Четыре ловушки

«Большое окно — можно не думать»

Проблема: окно в 1-2M токенов создаёт иллюзию, что управление контекстом необязательно.

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

«Переоптимизация контекста»

Проблема: стремление сократить каждый токен — телеграфный стиль, выброшенные детали.

Решение: экономить на шуме, не на сигнале. Подробное описание задачи — инвестиция, а не трата.

«Memory как свалка»

Проблема: в memory пишется всё подряд — тысячи токенов фиксированных расходов в каждой сессии.

Решение: memory — кэш, не архив. Регулярно пересматривайте, удаляйте устаревшее.

«Compact как волшебная кнопка»

Проблема: работа до упора, затем compact — и агент забывает ключевые детали.

Решение: compact — аварийный инструмент, не штатный. Лучше новая сессия с компактным резюме.

Часть 8

Итоги

Ключевые принципы и практика

Шесть ключевых выводов

1. Токен — атом контекста

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

2. Окно — структура, не буфер

Зоны, позиции, фиксированные и переменные расходы. Где лежит информация — не менее важно, чем что в ней написано.

3. Пожиратели — не промпты

Результаты вызовов инструментов, накопленная история, фиксированные расходы на system prompt и MCP-схемы — вот куда уходит бюджет.

4. Деградация скачком

Кривая деградации — главная причина, почему большое окно не спасает. К 70% заполнения уже нужно завершать или сбрасывать.

5. Экономить на шуме, не на сигнале

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

6. Memory — кэш, не архив

Хранить то, что дорого получить заново. Всё остальное — лишние фиксированные расходы.

Практическое задание — «Аудит контекста»

Аудит контекста

Подсчитайте распределение бюджета. Сколько токенов ушло на system prompt и MCP-схемы? На историю диалога? На результаты вызовов инструментов? На ваши сообщения?
Найдите три самых дорогих вызова инструментов. Можно ли было получить тот же результат дешевле — с параметрами offset/limit, более точным паттерном?
Определите момент деградации качества. На каком шаге ответы стали менее точными? Сколько процентов окна было занято?
Сформулируйте три правила для CLAUDE.md. Что нужно изменить в рабочем процессе для следующей аналогичной сессии?

Дальше

Лекция 7

RAG — embedding, vector store, retrieval. Когда контекстного окна не хватает — доставать нужное точечно.

Слайды · Лекция 1 Слайды · Лекция 2 Слайды · Лекция 3 Слайды · Лекция 4 Слайды · Лекция 5 Главная