Прелюдия 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 Prompt
CLAUDE.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 и что находится в Context Window в данный момент времени

Сначала про 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

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

На 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 файла. И механизм их синхронизации между собой

У меня в каждом репозитории CLAUDE.md выглядит больше как карта проекта, а не как справочник. Минимальный скелет:

# Проект: <одна строка>

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

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

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

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

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

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

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

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

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

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

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

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

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

....

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