От написания промптов к проектированию контекста. Или один очень обширный материал по Context Engineering

Прелюдия 1

Это длиннопост, после которого, я надеюсь, у вас сформируется устойчивый фундамент по работе с контекстом и современными агентными интерфейсами

Прелюдия 2

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

Прелюдия 3

То, что написано ниже — достаточно тяжелый материал, если у вас нет понимания работы агентов и того, как работают LLM, то будет тяжело. Но не бесполезно)
Для начинающих у меня есть отичная статья Просто и подробно о том, как работают ChatGPT и другие GPT подобные модели. С картинками.

Прелюдия 4

Основные концепты я буду рассказывать на примере Claude Code, так как они являются двигателями моды в агентной разработке. Но остальные агенты работают примерно также

Прелюдия 5

Я много где использую английские термины и генерирую картинки через ChatGPT, не наказывайте строго 🥺

---

TL;DR. Промпт инжиниринг в том виде, в котором он был популярен в 2025 уже мёртв. В современных агентных инструментах, таких как Claude Code, Codex и упасибогCursor = ваш текст это ~0,03% контекста. Все остальное — это system prompt, CLAUDE.md, память, MCP, skills, история, tool results. И созданы они, чтобы съедать ваши лимиты и тратить ваши деньги 😈

Что внутри этого лонгрида

• Акт 1. Контекстное окно как поверхность внимания.
  Context rot + reasoning shift — как длинный контекст может резать рассуждения до 50% без предупреждения

• Акт 2. Про квадратичную сложность attention и почему «больше токенов» стоит O(n²)

• Акт 3. Про 7 слоев контекста — от pretrained весов и до редактируемых system prompt, CLAUDE.md, MEMORY.MD, Skills, MCP и файлов по вызову

• Акт 4. Про agent loop и harness. А еще про promt caching, spec-driven подход, subagents, agent teams и 4 типа токенов и их реальная цена

• Акт 5. Что отличает новичка от мастера и 6 action items на понедельник — что положить в проект сегодня вечером

Кому актуально: Всем, кто работает с Claude Code / Codex / Cursor и всем тем, кто внезапно стал упираться в лимиты

---

Акт 1. 0,03% и 99,97%

Так как эта статья про то, что именно сидит в этих 99,97%, то с этого и начнем

А еще начнем с моей любимой цитаты, вокруг которой и будет выстроено дальнейшее выступление

Good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome

Вокруг слов, выделенных жирным, и выстроена вся современная работа с LLM

System PromptCLAUDE.md / настройки проектаMemory.md (файлы памяти из прошлых сессий)Tool definitions (описания всех доступных инструментов)Subagents + Skills + MCPsЗагруженные файлы / RAG-результатыИстория диалога (всё, что вы написали раньше)Результаты вызовов инструментовВАШ ПРОМПТ

Контекстное окно как поверхность внимания

О контекстном окне полезно думать как о рабочем столе, на котором лежит всё, что модель должна учитывать одновременно

Если на столе много мусора — тяжело понять, за что браться. Если только то, что относится к задаче — работать проще.

Внимание (attention) у модели — конечный ресурс: для каждого токена сумма весов softmax по всему контексту равна 1. Чем длиннее окно, тем меньше веса в среднем приходится на каждый отдельный токен — а на практике распределение ещё и неравномерное: первые токены и хвост получают непропорционально много (attention sinks), середина проваливается.

У длинного контекста есть две проблемки, и они работают одновременно

Первая и самая очевидная — Context rot. Когда внимание моделей размазывается

Чем больше случайных токенов в запросе к модели, тем сложнее ей отвечать релевантно

Это приводит к тому, что модели

• зацикливаются на уже обсуждённых точках

• забывают детали из начала разговора

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

• дают всё более размытые ответы

Вторая и менее очевидная — Reasoning shift

Есть немало наблюдений, что многие модели распределяют ресурсы между обработкой контекста и рассуждением — контекст растёт, рассуждения сокращаются.

На что это конкретно может влиять

• Меньше промежуточных рассуждений — модель сразу перескакивает к выводу

• Меньше самопроверки

• Сокращение альтернативных ответов — одна гипотеза вместо трех

• Уверенные, но не факт что правильные ответы — они звучат увереннее, хотя обоснованы хуже

Получается, что вы хотите более точных ответов и подгружаете больше документов. Объём растёт → reasoning сокращается → ответ выглядит увереннее, но обоснован хуже. И вы не узнаёте — со стороны выглядит нормально

Контекст — один из главных рычагов управления inference compute

Чем меньше токенов — тем меньше вычислений, тем быстрее ответ, тем ниже стоимость и тем выше точность. Это не четыре независимых преимущества — это одно и то же.

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

---

Акт 2. Почему всё так устроено

Attention Is All You Need

В июне 2017 года восемь исследователей Google выложили статью «Attention Is All You Need». В ней они предложили архитектуру Transformer — и именно она лежит в основе всех современных LLM: GPT, Claude, Gemini, Llama, DeepSeek. Буква T в GPT — это и есть Transformer.

Чтобы понять, почему это важно, нужно понять, как вообще работает LLM. Для этого нужно вернуться в 2017 год и посмотреть, как изменился фундаментальный принцип работы LLM.

Что было ДО 2017

Доминировали Recurrent Neural Networks. Они обрабатывали текст последовательно: слово за словом. И после каждого слова эта нейросеть обновляла «скрытое состояние» — компактный вектор, в который «сжималась» вся история.

Что предложил Transformer

Главная идея — self-attention. Каждое слово в предложении одновременно «смотрит» на все остальные слова и решает, насколько каждое из них релевантно. Никакой цепочки. Всё параллельно

Именно этот механизм позволил нам прийти к тому уровню развития нейросетей, на котором они сейчас. Но и он накладывает фундаментальное ограничение в размерах контекстного окна

Аttention в своем исходном виде — это O(n²) по длине последовательности. Каждый из N токенов смотрит на каждый из остальных, поэтому связей не N, а N×N.

На 1K токенов будет миллион операций, а на 1M уже целый триллион. Поэтому «давайте засунем больше файлов в модель» стоит не линейно, а квадратично — и прожектор внимания неизбежно размывается. Современные оптимизации (Flash Attention, sliding window, sparse attention) бьются за экономию вычислений, но квадратичность как закон не отменяют

---

Акт 3. Из чего собирается контекст

Сначала про Pretrained Data — сильно туда погружаться не буду, у Карпаты есть 3-часовой разбор «Deep Dive into LLMs», где разобраны основные понятия. По сути, это дистиллированное сжатие всего интернета с cutoff на конкретный момент времени, иногда Soul-документ, которым, например, дофайнтюнивают многие модели Claude

Именно веса определяют

• какие Q/K/V-проекции создаются (матрицы весов W_Q, W_K, W_V)

• как эти проекции трансформируются в FFN-блоках (Feed-Forward Networks)

На выходе последнего слоя получается вектор, который через матрицу unembedding (тоже веса) превращается в распределение вероятностей по всему словарю ~100+K токенов

И уже из этого распределения выбирается следующий токен (greedy / sampling / top-p)

Познавательная минутка
Один NVIDIA H100 — это 80 GB видеопамяти. Для модели в 1 триллион параметров (формат float16) нужно 25 GPU только чтобы веса поместились. Это не считая KV-cache для вашего контекста. Поэтому Claude Opus и GPT-4 физически не могут работать на вашем компьютере — они живут в дата-центрах. Локальные модели (Llama 3.1 70B на M3 Pro в int4-квантизации) — это другая категория моделей с другим характером и другой «конституцией». Когда речь о приватности или цене, выбор локальной модели = выбор другого Слоя 0

Веса — это образование, контекст — рабочий стол.

А если хотите лучше разобраться с принципом работы весов, то вот тут можете поиграться с GPT-2 моделью

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

Слово «формировать» здесь точнее, чем «контролировать». Полного контроля у нас тоже нет: System Prompt и Tool definitions пишет харнесс (Claude Code в нашем случае). В Claude Code это несколько килобайт системного промпта от Anthropic плюс несколько десятков встроенных инструментов (Read, Write, Bash, Grep и далее по списку — точный перечень меняется от версии к версии, актуальный — в tools-reference). Всё это занимает первые тысячи токенов окна ещё до того, как мы успеваем что-то сказать

Зато всё остальное — CLAUDE.md, память между сессиями, Skills, MCP-серверы, что и когда подгружается из файлов, как режется история диалога — это уже наша зона. И именно про неё дальше пойдёт разговор

Например, вот визуализация моего /context в Claude Code. Справа написано, сколько токенов и что занимает еще до отправки первого сообщения

Ну, поихали

CLAUDE.md 

CLAUDE.md в корне репозитория — это первое, что Claude Code кладёт в контекст после системного промпта и до любого пользовательского сообщения. И главная ошибка при работе с ним — превращать его в простыню «всё, что я хочу, чтобы агент знал»

Познавательная минутка
CLAUDE.md читает только Claude Code. Codex читает AGENTS.md, а Gemini читает GEMINI.md. Если вы хотите, чтобы все три агента правильно работали с вашим репозиторием, то у вас должны быть все 3 файла. И механизм их синхронизации между собой

# Проект: <одна строка>## Архитектура — стек, ключевые директории## Правила — конвенции коммитов, стиля, тестов## Что НЕ делать — границы, типичные ошибки

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

MEMORY.md для памяти между сессиями

Подгружается вместе с CLAUDE.md

Память в Claude Code — это не просто выжимка из разговора, как это было раньше. Теперь это аккуратный индекс с подписанными папками, где каждый файл имеет тип, имя и описание

Четыре типа памяти, разделённые по назначению:

• user — кто пользователь: роль, опыт, технические предпочтения.

• feedback — обратная связь после ошибок: «не делай X», «продолжай делать Y». Самое ценное, что можно положить в память.

• project — контекст проекта: дедлайны, архитектурные решения, ограничения.

• reference — ссылки на внешние системы: где Notion, какой репо с фикстурами.

У Memory есть механизм AutoDream

AutoDream — экспериментальный механизм фоновой консолидации памяти между сессиями, по принципу REM-сна: между сессиями читает все файлы памяти, находит дубли и противоречия, склеивает связанное в саммари. Запускается либо с вашей стороны либо автоматически раз в 24 часа или после 5-10 turns.

Ниже пример страницы Memory одного из моих проектов. Оранжевым показаны ссылки на файлы, где каждый из пунктов написан подробно

….

Сейчас допишу часть 2