Context Engineering — что это и как им управлять

Введение

Любая задача контекст-инжиниринга — это поиск минимального набора токенов, который стабильно дает результат. Контекст — это вся информация, которая попадает в модель до того, как она дает ответ. И моя любимая формулировка звучит так: хороший контекст-инжиниринг — это поиск наименьшего количества возможных вариаций высокосигнальных токенов, которые максимизируют вероятность нашего желаемого outcome. В этой фразе каждое слово важное. За каждым словом стоит довольно большой технологический пласт. СКАЧАТЬ ПРЕЗЕНТАЦИЮ

Почему эпоха «магических промптов» заканчивается

Раньше, особенно в 2024–2025 годах, очень популярна была идея prompt engineering в ее упрощенном виде: надо просто найти правильные слова. Люди продавали целые наборы «идеальных промптов», подборки из пятисот запросов для маркетинга, программирования, продаж, чего угодно. Была вера в то, что существует магическая комбинация токенов, которая откроет модель и заставит ее выдавать нужный результат.

Сейчас эта история постепенно уходит в прошлое. Люди становятся чуть умнее и начинают понимать, что промпт — это только маленькая часть всей системы. Особенно если мы говорим не о простом чате, а о сложных проектах, продуктах, агентных сценариях, коде, инструментах, памяти и так далее. Чем сложнее ваша система, тем меньше весит именно тот кусок текста, который вы вручную вписали в input.

Если говорить грубо, в большой современной сессии ваш ручной промпт может занимать от нуля до одного процента от всего реального контекста. И надеяться, что именно этот один процент целиком определяет результат, уже наивно. Поэтому сегодня важнее не искать «идеальные слова», а понимать, как устроен весь контекст вокруг этих слов.

Промпт — это не контекст

Когда я говорю «контекст», я имею в виду не только ваш последний вопрос в чате. Контекст — это гораздо более широкая конструкция.

Если разобрать современную агентную сессию, например в Claude Code, Codex или похожих системах, то там есть несколько слоев.

Во-первых, это веса модели. То, что уже запечено в самой модели и на что мы никак не влияем.

Во-вторых, это системный промпт.

В-третьих, memory — слой памяти, который появился сравнительно недавно.

Дальше идут tools: ваш код, интеграции, MCP-серверы, поисковые механизмы, инструменты, которыми агент умеет пользоваться.

Потом — skills, если вы их сделали.

Потом — файлы проекта, которые модель вытаскивает по мере надобности, то есть just in time.

И только в самом конце находится история вашего диалога, которую большинство людей и воспринимает как «весь контекст».

На деле большая часть того, что реально влияет на ответ, пользователю вообще не видна. И многие просто игнорируют все, что находится выше уровня обычного чата. Они подключают кучу серверов, навешивают интеграции, ставят все подряд, а потом удивляются, почему у них уже на старте сессии занято полконтекстного окна. Я много раз видел, как люди поднимали себе столько всего, что у них уже в начале сессии было забито сто или двести тысяч токенов. Это просто огромный перерасход.

Контекстное окно — это не «память», а поверхность внимания

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

Сейчас мне кажется намного полезнее думать о контекстном окне как о поверхности внимания. Это примерно как ваш рабочий стол. Если у вас на столе лежит много мусора, нерелевантных документов, папок, лишних файлов, вам тяжело понять, за что вообще браться. Если же на столе лежит только то, что относится к текущей задаче, работать проще: сигнал сильнее, шум меньше.

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

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

Почему «больше контекста» не значит «лучше результат»

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

Во всех графиках и экспериментах, которые я видел, общий тренд один: чем больше токенов мы загружаем в контекст, тем ниже вероятность того, что модель найдет именно тот факт или именно тот ответ, который нам нужен.

Если вы просто пишете текст, это может быть не так заметно. Но если вы пишете код, это становится очень критично. Там достаточно, чтобы одна функция, один класс, одна зависимость или одна важная связь потерялись в шуме, и модель начнет работать хуже. Люди жалуются: «Модель стала плохо писать код». А потом смотришь на их проект — и там просто свалка. Документация, мусор, лишние файлы, бессмысленные инструкции, случайные хвосты от старых задач.

Я обычно советую задавать себе простой вопрос: а смог бы человек решить эту задачу с теми входными данными, которые вы сейчас даете модели? Если человеку с этим трудно, то и модели будет трудно. Значит, проблема не только в модели. Значит, ваша упаковка данных и документов просто недостаточно хороша.

Attention, reasoning и две деградации длинного контекста

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

У длинного контекста, как я это вижу, есть две основные деградации.

Первая — это обычный context rot. Чем больше токенов, тем меньше внимания можно выделить на действительно важные куски.

Вторая — это деградация reasoning. Когда у модели включен thinking или reasoning-режим, у нее есть дополнительный бюджет на обдумывание. Но чем больше у вас вход, тем меньше остается бюджета на само рассуждение. То есть модель тратит ресурсы не на то, чтобы хорошо подумать, а на то, чтобы просто переварить весь этот объем.

Я недавно наткнулся на большое исследование, где автор сравнивал текущие модели Anthropic и делал вывод, что у них заметно просели reasoning-блоки примерно тогда же, когда начались сильные ограничения по лимитам. У меня есть ощущение, что это связано с тем, что они одновременно обучают новые большие модели и им банально не хватает ресурсов. В таком сценарии первое, что начинают поджимать, — это thinking. Поэтому, когда у вас включен reasoning, я бы держал в голове простую вещь: с высокой вероятностью его тоже могут «душить», и чем больше у вас контекст, тем меньше реальный бюджет на это размышление.

Еще более любопытная штука: когда они выкатывали очередные обновления, они зашифровали thinking-блоки. Официальная аргументация такая: чтобы люди не пытались инжектить свои промпты внутрь механизма мышления. Но есть и другой взгляд: что это сделали еще и для того, чтобы со стороны нельзя было так легко увидеть, насколько реально просел внутренний thinking. Раньше можно было читать эти размышления, сейчас в Claude Code вы их уже не видите. Они закодированы и недоступны пользователю. Мне кажется, это не случайность.

Почему это так тяжело считать

Если совсем по-простому, механизм внимания опирается на перемножение матриц. И вот здесь начинается фундаментальная вычислительная стоимость всего происходящего.

Когда модель генерирует следующий токен, она соотносит токены друг с другом. Если у вас сто токенов на входе, это уже одна математика. Если сорок тысяч — это уже совсем другая. А если миллион — тем более. И проблема в том, что рост здесь не линейный, а квадратичный. Это не так, что мы просто увеличили контекст в десять раз и получили в десять раз большую стоимость. Мы получили n².

Именно поэтому я скептически смотрю на все рассказы о «настоящем миллионе токенов». Да, формально у вас может быть миллион. Но если посчитать реальную вычислительную цену честно, становится понятно, что это не может работать без компромиссов. Скорее всего, там режут окно на части, синтетически собирают, как-то перераспределяют внимание, делают инженерные трюки. То есть это не тот «миллион», в котором каждый следующий токен одинаково качественно учитывается. После определенного объема качество все равно будет падать.

И в этом смысле контекст-инженер управляет inference compute. Чем меньше токенов, тем меньше вычислений, тем быстрее ответ, тем ниже стоимость и тем выше точность. Именно поэтому писать в один чат все подряд — про здоровье, про работу, про код, про личное — плохая идея. И складывать в один проект кучу файлов, а потом говорить модели «прочитай все» — тоже плохая идея.

Веса модели: фундамент, который мы не трогаем

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

На это мы почти не влияем. Да, кто-то любит обучать свои модели, баловаться с маленькими экспериментальными вариантами. На простом уровне это действительно не так уж и сложно. Но если мы говорим о полноценных больших моделях, это месяцы обучения и огромные мощности.

Иногда модели дотюнивают под регион. Поэтому условный Yandex GPT, Sber GPT, Mistral, китайские модели или любые региональные сборки могут вести себя чуть по-разному. У меня даже был забавный пример с Telegram Translator. Если туда закинуть определенные политические формулировки про Тайвань, Си Цзиньпина и площадь Тяньаньмэнь и нажать Fix, он, по моим наблюдениям, не просто «исправляет» текст, а начинает выдавать идеологически правильную для Китая версию. Из этого можно сделать вполне правдоподобный вывод, что под капотом там стоит китайская синтетика.

Это хороший пример того, что претрейн и дотюнинг реально влияют на поведение модели, даже если пользователь этого не видит.

Системный промпт и поведенческая рамка

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

Например, если вы в конфиге меняете language, это не какая-то магическая перепрошивка модели. Вы просто меняете кусок текста в системном промпте, который говорит: этот пользователь предпочитает такой-то язык. Все. Модель может на это смотреть, а может и не смотреть. Иногда она все равно уедет в английский или в другой язык, потому что это инструкция, а не жесткая проводка.

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

Есть еще и отдельный пласт поведенческой рамки. Я для себя иногда называю это условной «душой» модели. Смысл в том, что одной только языковой статистики уже недостаточно. Если модель предобучена на интернете, а в интернете огромное количество агрессии, войн, насилия и прочего шума, то дальше ей нужно отдельно объяснять, что в человеческом мире считается допустимым, а что нет. Это не просто список запретов в духе «не говори рецепт пороха». Это скорее попытка передать модели набор поведенческих норм, как родители передают ребенку: вот так лучше не делать, а так лучше делать.

Memory: от персонализации к рабочей памяти проекта

Когда memory только появлялась, это выглядело как довольно сырой механизм персонализации. ChatGPT мог подхватывать какие-то факты о вас и складывать их в память. Проблема в том, что туда часто попадало слишком много мусора.

У Claude Code история пошла чуть дальше. Там появился механизм dreaming. И мне эта штука кажется очень интересной. Раньше память у него работала примерно так же: вы что-то делаете, мимоходом говорите системе, что вы на Linux, что у вас другой часовой пояс, что в Safari что-то работает хуже, и она складирует это как лог — дата, время, запись, дата, время, запись.

Потом они добавили dreaming. Это экспериментальный режим, который симулирует что-то вроде фазы быстрого сна. Когда активность низкая, агент берет этот лог и начинает его переупаковывать: что важно, что неважно, что надо вынести в структурированную память, а что можно оставить в сыром логе. В итоге из простой свалки записей получается более-менее нормальная индексация.

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

При этом как именно он решает, что важно, а что не важно, до конца не прозрачно. По ощущениям, роль играет повторяемость, возможно стрессовые сигналы, какие-то особенности поведения. Я видел обсуждения и небольшие исследования о том, что агрессивные или эмоциональные формулировки тоже могут оставлять след в том, как система ранжирует важность. Насколько это буквально правда, я утверждать не берусь, но как гипотеза это вполне обсуждается.

Tools: скрытая цена агентности

Когда люди начинают работать с агентами, они часто не понимают, насколько дорогой слой — это tools.

Tools — это все, что агент должен уметь: работать с файлами, искать по коду, дергать bash, делать web search, web fetch, запускать planning, обращаться к другим агентам, искать сообщения, передавать команды и так далее. Чтобы агент мог этим пользоваться, ему нужно все это описать.

И это описание занимает контекст. Много контекста. Именно поэтому агентная система дороже обычного чата уже на старте. Вы еще ничего толком не сделали, а у вас уже ушли токены на системный промпт и definitions всех этих тулов.

Отсюда отдельная проблема — MCP-серверы. Они сами по себе полезны, но каждый такой сервер тоже весит. Если вы подключаете много MCP-серверов, особенно тяжелых, вы просто съедаете себе контекст. Я видел оценки, где один GitHub MCP может занимать весом примерно столько же, сколько все встроенные tools Claude Code. Поэтому оркестрация MCP — это вообще не шутка. Если вы часто этим пользуетесь, полезно иногда просто открыть контекст и посмотреть: а не слишком ли у вас там всего навешано.

Skills: новый формат передачи знания агенту

Скиллы, по сути, стали новым форматом промптинга. Раньше вы каждый раз вручную переносили знания в промпт. Теперь вы можете завернуть их в skill.

У скилла есть имя, описание, список доступных тулов и правила вызова. И что важно: в контекст обычно грузится не весь скилл целиком, а метаданные. То есть модель знает, что такой скилл существует, за что он отвечает, когда его вызывать и чем он может пользоваться. Благодаря этому можно держать у себя много скиллов и не убивать контекст сразу всем объемом.

У Claude, например, есть Skill Creator и Evaluator. Creator помогает собрать скилл. Evaluator может прогнать сравнение в песочнице и показать, есть ли вообще значимый эффект: лучше ли работает задача со скиллом, чем без него, можно ли скилл улучшить, насколько он реально дает прирост.

И да, я уже вижу, как люди начинают продавать знания именно в виде скиллов. Условный маркетолог может не просто консультировать руками, а завернуть свой подход в skill и продавать его компании как продукт. С точки зрения масштаба это логично: консультацию агенту может проводить уже не человек, а упакованное знание самого человека.

Проектные инструкции: Claude.md, Agent.md и синхронизация

У меня в каждом репозитории лежит проектный Claude.md. Там не гигантская простыня, а скорее индексация: где лежит дизайн-система, где архитектура, где продуктовые вопросы, как устроен пайплайн, где что искать. Мне хочется, чтобы это был один главный ориентир по проекту.

Есть корневой Claude.md, есть проектный, можно еще делать файлы в подпапках, но я обычно так не делаю. Мне не нравится распылять контроль по разным уровням, потому что потом это труднее чистить и синхронизировать.

Поскольку я периодически работаю с разными агентами, у меня есть hook, который при изменении Claude.md дублирует изменения в Agent.md и аналогичные файлы под другие системы. То есть я сознательно держу эти инструкции синхронизированными. Не потому, что это красиво, а потому, что мне не хочется каждый раз объяснять агенту: «Пожалуйста, пойди почитай вон тот файл». Если можно сделать так, чтобы нужная информация уже была у всех одинаково, я делаю именно так.

Можно ли решить это symlink’ами? Возможно. Я просто не копал это достаточно глубоко и решил задачу грубее: отдельным sync-навыком, который дублирует изменения строка в строку.

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

Очень важная тема — субагенты.

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

Потом это разрослось до ролей, персонажей, teams, skill-like агентов, но базовая цель была очень простая: не засирать основной контекст. Именно поэтому у меня есть куча субагентов под разные задачи — лид-дизайнеры, тестировщики и так далее. Но я все равно смотрю на них прежде всего как на механизм изоляции и фильтрации.

То есть субагент — это не просто «еще один умный помощник». Это способ не гонять все подряд через одно общее окно.

Как реально работает агентный loop

Обычный чат заканчивает работу в момент, когда дал вам ответ. Агент так не работает.

Если вы дали задачу, например, найти что-то в репозитории, модель сначала получает весь контекст: системный промпт, memory, Claude.md, tools, skills, сообщения, все, что нужно. Потом она начинает генерировать токены ответа. Если по ходу оказывается, что для решения нужен tool, она идет в definitions тулов, выбирает подходящий, например bash, проверяет permissions, вызывает инструмент, получает результат и потом… снова отправляет все это в модель на новый перерасчет.

Вот это и есть loop.

Агент работает циклом: получить задачу, подумать, выбрать tool, получить результат, снова прогнать это через модель, снова проверить, нужен ли еще tool, и только потом отрендерить финальный ответ.

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

Хуки, status line и compact

Еще одна недооцененная часть архитектуры — hooks.

Status line — это тоже hook. Он привязывается к input и output, обновляется, когда модель отвечает, и позволяет выводить полезную телеметрию: лимиты, контекстное окно, остаток до пиковых часов, незакоммиченные изменения, многое другое.

Memory reload тоже завязан на hook. Dreaming — тоже. Автокомпакт — тоже.

Compact — это вообще очень важная штука. Когда контекст забивается до определенного порога, срабатывает hook, который говорит: пора делать compact. И по сути агент берет историю сессии, схлопывает ее в более короткий пересказ по своим правилам и начинает дальше работать уже не с полной историей, а с ее компактной версией.

Причем compact можно вызывать и вручную. И если делать это не просто командой compact, а с дополнительной инструкцией, можно повлиять на то, что именно он сохранит подробнее. Например, можно сказать: последний кусок важнее, сохрани его более детально. Тогда compact получится уже не стандартный, а подстроенный под вашу задачу.

Почему агентные системы так быстро начинают стоить дорого

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

Если агент не понял задачу или задача плохо упакована, loop может крутиться двадцать, тридцать раз. И каждый такой проход снова отправляет в модель весь контекст: системный промпт, tools, серверы, skills, сообщения, документы, все.

Из-за этого агент не просто становится дороже. Он еще и начинает тупеть по мере перерасхода, особенно если лимиты и thinking уже поджаты. Поэтому компании объективно заинтересованы в том, чтобы делать агентов чуть более ленивыми и чуть менее щедрыми на глубину размышления. Если качество ответа можно опустить не до катастрофы, а с 99% до 95%, для корпорации это уже может быть экономия на миллиарды.

Это неприятная, но важная реальность агентных систем.

Кэш — не просто ускорение, а экономическая основа всей системы

Если бы не было кэша, работа с агентами стоила бы в разы дороже.

Каждый раз, когда вы начинаете новую сессию, большой кусок контекста улетает в кэш: системный промпт, tools, Claude.md, память и так далее. Первая запись в кэш дороже, но следующие обращения к тем же данным стоят значительно дешевле. Именно поэтому повторная работа внутри одной сессии обходится системе и провайдеру намного легче, чем запуск всего с нуля.

При этом кэш ломается от изменений. Если вы поменяли какой-то слой выше — например, системный параметр вроде web search true/false, — у вас меняется хэш набора токенов, и нижележащие части приходится пересчитывать заново.

Поэтому важно понимать: кэш — это не абстракция, а то, что напрямую влияет и на деньги, и на лимиты. Если вы утром открыли продолжение очень длинной сессии, вы можете моментально сжечь огромный кусок лимита просто тем фактом, что поднимаете старый объем.

Новичок и контекст-инженер — это разные типы мышления

Когда люди только начинают работать с агентами, они обычно общаются с ними как с обычным чатом. Они пишут: «сделай функцию», «напиши эту штуку», «исправь вот это». Они не строят вокруг агента систему.

А хороший контекст-инженер как раз строит систему. Он думает про память, про кэш, про skills, про subagents, про MCP, про project docs, про hooks, про permissions, про агентные команды, про то, что лежит в корне репозитория, а что вообще не нужно тащить в окно.

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

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

Финальная формула

Если все это сжать в одну формулу, то она очень простая:

хороший результат = минимально необходимая мощность высокосигнальных токенов.

Выглядит просто, почти как школьная формула. Но за ней прячется огромная сложность: как именно выделить эти токены, как не утонуть в шуме, как не раздувать контекст, как не ломать кэш, как не тратить reasoning на мусор, как не засирать основной loop тем, что можно вынести в subagent, tool, memory или skill.

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

Если вы хотите реально научиться работать с агентами, не относитесь к ним как к помойке, куда можно свалить все подряд. Посмотрите, что у вас вообще лежит в проекте, как устроена память, есть ли мусор в инструкциях, нужны ли вам skills, есть ли смысл в субагентах, что происходит с кэшем, из чего состоит контекст. Большинство людей даже не доходят до этого слоя понимания.

А без этого хорошей инженерии контекста не будет.

Заключение

Все в итоге сводится к достаточно простой мысли: не надо пытаться победить модель одним «гениальным» промптом. Это почти всегда иллюзия.

Надо уметь собирать для нее правильную систему: что у нее в голове от претрейна, что лежит в системном промпте, что она тащит из memory, какие tools и MCP вы ей навесили, какие skills можно вызывать, как организованы ваши файлы, где нужно использовать subagent, где нужен compact, а где лучше вообще начать новую сессию.

Вот это и есть контекст-инжиниринг.

И чем раньше это станет для людей не набором «магических слов», а нормальной инженерной дисциплиной, тем быстрее появятся действительно сильные и стабильные результаты.