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

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

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper

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

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

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

Я много где использую английские термины и генерирую картинки через 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 и всем тем, кто внезапно стал упираться в лимиты

Так как эта статья про то, что именно сидит в этих 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), середина проваливается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На 1K токенов будет миллион операций, а на 1M уже целый триллион. Поэтому «давайте засунем больше файлов в модель» стоит не линейно, а квадратично — и прожектор внимания неизбежно размывается.

Современные оптимизации (Flash Attention, sliding window, sparse attention) бьются за экономию вычислений, но квадратичность как закон не отменяют

Визуализации оптимизаций контекстного окна

На генерацию каждого следующего токена влияют два блока — что было в pretrained data и что находится в Context Window в данный момент времени

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

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

На выходе последнего слоя получается вектор, который через матрицу 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

Ну, поихали

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

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

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

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

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

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

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

MEMORY.md — индекс, грузится в каждую сессию целиком. Сами файлы — в .claude/memory/, подгружаются по description из фронтматтера.

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

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

Это механизм, созданный тоже антропиками, который позволяет по команде загружать в модель определенное поведение или команду

Skill устроен как книга на полке. У книги есть корешок (имя + description, до 1 536 символов) — это и грузится в контекст всегда. Само содержимое (SKILL.md — процесс, инструкции, шаги) подгружается только когда харнесс по описанию решает, что эта книга сейчас нужна. Ну или когда мы сами его вызываем

Anthropic рекомендует упаковывать в скиллы всё, что является процессом: TDD, code review, commit‑style, deployment runbook, конкретный workflow вашей команды

Если коротко, то это протокол для общения AI‑модели с внешними сервисами

Subagent — это отдельная сессия с собственным контекстным окном. Основной агент обращается к нему как к инструменту: «сходи проанализируй X», получает обратно только финальный текст. Внутренний контекст субагента (что он читал, чем рассуждал, какие 50 файлов открывал по пути) в основной контекст не попадает

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

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

В отличие от MCP и Skills, файлы и результаты поиска по коду — это динамическая часть контекста, которая формируется во время работы. Каждый Read и Grep добавляет в контекст ровно тот кусок, который вы или модель попросили прочитать

И да, «давайте на всякий случай скормим модели весь репозиторий» — это антипаттерн

Что работает:

Каждый Read и Grep это решение, сколько внимания вы отдаёте этому куску ценой отвлечения от всего остального

История диалога не растёт бесконечно — даже на 1KK окне у вас рано или поздно срабатывает compaction. Это хук (не модель решает — харнесс автоматически), который вызывается при достижении порога контекста

На той же картинке ниже видно Autocompact buffer, который резервирует часть контекстного окна и запустит /compact, когда вы подберетесь к его границе. Autocompact buffer можно отключить в /config

Что происходит при autocompact или /compact

Минус: модель сама решает, что важно — и иногда выкидывает то, что вы как раз хотели сохранить.

Чтобы избежать потери нужной вам информации при /compact, то вот вам лайфхак. Команда /compact в Claude Code принимает свободный текст

/compact оставь подробно последние 20 сообщений про авторизацию, остальное сожми до решений и архитектурных правил

Так вы превращаете дефолтный compact в кастомный — под задачу, а не общий. Этим часто пренебрегают, а зря. Разница между «модель сократила историю наугад» и «модель сократила историю по вашим правилам» — порядок качества дальнейшей работы.

Альтернатива compact это /clear — новая сессия с чистого листа. Стоит чаще, чем кажется: если задача поменялась, лучше открыть новый контекст и притащить туда нужное явно через CLAUDE.md, memory, конкретный Read), чем тащить шлейф прошлого.

Потому что он решает задачу до того момента, пока не посчитает эту задачу решенной. Следовательно, вместо простого «Вопрос» => «Ответ», как в чатах. Агенты пытаются решить поставленную задачу и ради одного ответа могут дернуть модель и 5 и 10 и 15 раз

Есть очень классный сайт, на котором хорошо показан Claude Code Agent Loop

https://ccunpacked.dev/#agent‑loop

Например, вы написали

Проверь, почему упал последний деплой prod?

И агент за это сделает 3 tool uses — для пользователя это выглядит как один ответ, «Claude подумал и ответил». На самом деле там 4 раздельных HTTP‑запроса к /v1/messages, между которыми harness (Claude Code) зовет разные инструменты

USER ──▸ человек, прислал текст HARNESS ──▸ процесс на твоей стороне (Claude Code, SDK, кастомный код). Делает HTTP-запросы к Anthropic, выполняет тулы, рендерит ответ. MODEL ──▸ серверная сторона Anthropic. Stateless: ничего не помнит между вызовами. TOOLS ──▸ реальные функции (read_file, bash, get_logs, ...). Живут в harness.

╭────────────────────────────────────────────────────────────────────────────────╮│ [ 1. USER -> HARNESS (Claude Code / API client) ] ││ ││ Текст: "Почему упал последний деплой prod?" ││ ││ Harness формирует запрос к /v1/messages со списком tools. ││ В payload идёт: system prompt, tool definitions, user message. │╰────────────────────────────────────────────────────────────────────────────────╯ │ ▾╭────────────────────────────────────────────────────────────────────────────────╮│ [ 2. HARNESS -> MODEL (call #1, prefill, then decode) ] ││ ││ Input tokens: system ~3500, tools ~2000, user ~20 -> ~5520 ││ Prefill: один forward pass, заполняет KV-cache на 5520 токенов ││ Decode: "Проверю статус деплоя." затем tool_use(get_deploy_status) ││ ││ stop_reason = "tool_use" <- модель сама остановилась ││ usage: input=5520, output=22 │╰────────────────────────────────────────────────────────────────────────────────╯ │ ▾╭────────────────────────────────────────────────────────────────────────────────╮│ [ 3. HARNESS executes TOOL #1 (get_deploy_status) ] ││ ││ Harness видит stop_reason="tool_use", парсит tool_use block, ││ вызывает реальный код или API. Модель в этот момент не работает. ││ ││ Tool returns: {"id":"deploy-7af2","status":"failed", ││ "started":"2026-04-26T09:15Z","duration":"42s"} │╰────────────────────────────────────────────────────────────────────────────────╯ │ ▾╭────────────────────────────────────────────────────────────────────────────────╮│ [ 4. HARNESS -> MODEL (call #2, prefill_diff, then decode) ] ││ ││ Harness отправляет ВСЮ историю заново, добавив: ││ - предыдущий assistant message (текст и tool_use_1) ││ - tool_result_1 ││ ││ Input tokens: 5520 (старое), 22 (asst), 60 (result) -> ~5602 ││ С prompt caching: prefill считается только для дельты ~82 токенов ││ Decode: "Деплой упал. Посмотрю логи." затем tool_use(get_logs) ││ ││ stop_reason = "tool_use" │╰────────────────────────────────────────────────────────────────────────────────╯ │ ▾╭────────────────────────────────────────────────────────────────────────────────╮│ [ 5. HARNESS executes TOOL #2 (get_logs) ] ││ ││ Tool returns 800 токенов лога: ││ "ERROR: failed to bind :8080, address in use" ││ "ERROR: container stopped after 3 restart attempts" ││ ... │╰────────────────────────────────────────────────────────────────────────────────╯ │ ▾╭────────────────────────────────────────────────────────────────────────────────╮│ [ 6. HARNESS -> MODEL (call #3, prefill_diff, then decode) ] ││ ││ Input tokens: 5602, 24 (asst), 800 (result) -> ~6426 ││ С prompt caching: дельта ~824 токена ││ Decode: "Похоже, порт занят. Проверю последний коммит." ││ затем tool_use(git_log) ││ ││ stop_reason = "tool_use" │╰────────────────────────────────────────────────────────────────────────────────╯ │ ▾╭────────────────────────────────────────────────────────────────────────────────╮│ [ 7. HARNESS executes TOOL #3 (git_log) ] ││ ││ Tool returns: ││ "abc123 chore, add nginx sidecar (Igor, 2h ago)" │╰────────────────────────────────────────────────────────────────────────────────╯ │ ▾╭────────────────────────────────────────────────────────────────────────────────╮│ [ 8. HARNESS -> MODEL (call #4, prefill_diff, then decode) ] ││ ││ Input tokens: 6426, 28 (asst), 40 (result) -> ~6494 ││ Decode: "Деплой упал из-за nginx-sidecar коммита abc123, ││ он биндит тот же порт 8080. Откатить или сменить порт." ││ ││ stop_reason = "end_turn" <- модель решила, что закончила │╰────────────────────────────────────────────────────────────────────────────────╯ │ ▾╭────────────────────────────────────────────────────────────────────────────────╮│ [ 9. HARNESS -> USER ] ││ ││ Финальный ответ модели передаётся пользователю. ││ Всего: 4 вызова модели, 3 tool execution, 1 пользовательское сообщение. │╰────────────────────────────────────────────────────────────────────────────────╯

1. Тулы исполняет харнесс, не модель. Модель только генерирует JSON‑блок с именем тулa и аргументами. Реальный bash, read_file, HTTP‑запрос — это код в харнессе. Между этими двумя мирами модель ничего не видит, кроме того, что харнесс потом вернёт как tool_result.

2. История сообщений растёт. Round 1 = 5520 токенов. Round 4 = 6494. И харнесс заливает в модель все 4 раза полный диалог, а не только дельту. Т.е. это около 22 000 токенов за 4 прохода. Учитывая, что для нас это выглядит как одна операция

3. Tool definitions сидят в каждом запросе. Если у тебя 10 MCP‑тулов на ~15K токенов описаний, то эти 15K включаются в каждый из 4 вызовов = около 60 тысяч токенов потрачено на описания тулов, из которых реально вызвано 3 штуки.

Давайте посмотрим, как в деталях выглядят наши запросы к модели в этой ситуации.

Вызовы 1 и 2 покажу детально, остальные в таблице

╭────────────────────────────────────────────────────────────────────────────────╮│ ROUND 1 ││ ││ total = 5520 tokens | cacheable prefix = первые 3 сегментов ││ дельта этого раунда = 5520 токенов ││ ││ SYS TOOLS USR ││ [##############################][################][#] ││ 3500 2000 20 ││ ││ # = в кеше предыдущего раунда (cache_control hit, 10% от базовой цены) ││ * = новые токены раунда: ││ 100% если просто добавлены без cache_control ││ 125% (5-min TTL) или 200% (1-hour TTL) если помечены cache_control ││ (тогда становятся cached prefix для следующих раундов) │╰────────────────────────────────────────────────────────────────────────────────╯ │ ▾╭────────────────────────────────────────────────────────────────────────────────╮│ ROUND 2 ││ ││ total = 5602 tokens | cacheable prefix = первые 3 сегментов ││ дельта этого раунда = 82 токенов ││ ││ SYS TOOLS USRA1 T1 ││ [##############################][################][#][*][*] ││ 3500 2000 20 22 60 ││ ││ # = в кеше предыдущего раунда (cache_control hit, 10% от базовой цены) ││ * = новые токены раунда: ││ 100% если просто добавлены без cache_control ││ 125% (5-min TTL) или 200% (1-hour TTL) если помечены cache_control ││ (тогда становятся cached prefix для следующих раундов) │╰────────────────────────────────────────────────────────────────────────────────╯

Все это выше лишь подводка к тому, что без caching агентные циклы экономически нерентабельны. В типичном агентном loop 95–96% всех input‑токенов — это cache reads

Вот математика того, во что это превращается со включённым кешем:

╭────────────────────────────────────────────────────────────────────────────────╮ │ COST ARITHMETIC (write = 125% от базового input) │ │ │ │ Сравнение стоимости ввода (4 вызова модели), в "эффективных токенах": │ │ │ │ без cache с prompt cache (write 125%, read 10%) │ │ Round 1 write 5520 5520 x 1.25 = 6900 (полный cache write) │ │ Round 2 5602 552 read , 103 write (82 x 1.25) = ~655 │ │ Round 3 6426 560 read , 1030 write (824 x 1.25) = ~1590 │ │ Round 4 6494 643 read , 85 write (68 x 1.25) = ~728 │ │ ИТОГО 24042 ~9873 (экономия ~2.4x) │ │ │ │ Cache write дороже обычного ввода (125%), но READ потом стоит 10%. │ │ Окупается, если префикс реально переиспользуется >= 2 раз. │ │ На длинных диалогах (10-20 раундов) экономия достигает 5-10x. │ ╰────────────────────────────────────────────────────────────────────────────────╯

Видно, какая колоссальная разница между Cache Read и Input tokens

Цифры графиков Cache Read находится слева, а Input tokens справа. 30к и 100кк

У клода есть два типа кеша на 5 минут и на 1 час

Запись в 5 минутный кеш стоит 125% от цены обычного input токена

А запись в 1 часовой кеш стоит уже 200% от цены обычного токена. Не важно, платите ли вы за API или у вас подписка

На 5m TTL: каждая пауза > 5 мин → cache miss → re-write 10 × (1M × 125%) = 12.5M write tokens На 1h TTL: пауза < 60 мин → кеш жив → read 1 × (1M × 200%) + 9 × (1M × 10%) = 11M эффективных токенов НО: 1M токенов лежат в hot-storage все 60 минут подряд

Anthropic'ам приходится физически держать ваш 1M‑префикс в KV‑cache на GPU, готовым к чтению, весь час. Миллион таких пользователей могут занять десятки петабайт RAM на горячем хранении одновременно. Поэтому они и режут доступы к своим дата центрам как могут

Например, если у вас в окне 900K токенов, потом вы ушли на час, потом прислали сообщение — это >900K токенов write по полной, что съест значительный% rate‑limit«. Цена для пользователя — каждая пауза >5 минут превращает следующий запрос в полный re‑write всего префикса. »

Например вот, для пользователей с подписками Антропики с конца марта переключили default кеш с 1h на 5m

Разница в стоимости без кеширования, с кешированием и с кешированием + compact

В Anthropic API не один тип токенов — четыре, и каждый имеет свою цену. Это знание прямо влияет на счёт:

Thinking — это output, и его невидимость не делает его бесплатным. В одной сессии с включённым thinking легко получить в 2–3 раза больше output‑токенов, чем у видимого ответа

Открывает Claude Code, набирает в командной строке что то типо такого и ждет ответа

> Напиши мне REST API для моей задачи (текст задачи)

У него

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

Подготавливает среду один раз:

├── CLAUDE.md — архитектура, стек, правила, «что НЕ делать» ├── ~/.claude/memory/ — user/feedback/project/reference, формат Why+How ├── .claude/skills/ — рабочие процессы (TDD, debugging, review) ├── .claude/agents/ — субагенты для тяжёлого ресерча ├── .mcp.json — только нужные MCP, остальное отключено └── .claude/settings.json — хуки, permissions, статус-лайн

В каждой сессии при этом происходит уже не разговор, а работа системы по контракту:

Что получает в результате: стабильный, воспроизводимый результат. Тот же проект через неделю — те же правила. Новый человек в команде получает работающего агента сразу, без устной передачи знаний. Счёт за токены и расход квоты не растут пропорционально объёму работы — растут пропорционально новизне

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

Или

Фсё!

Канал с гайдами и контентом по claude code, выкладываем новости (когда режут лимиты в 10 раз) и какие инструменты через claude реализуем для проектов, канал: https://t.me/claudedevolper