Context Engineering

Проектирование контекста для LLM: от управления токенами до архитектуры памяти агентов

18 марта 2026

Prompt engineering учит правильно формулировать запрос. Context engineering решает другую задачу: какая информация должна попасть в контекстное окно модели, в каком объёме и в какой момент. Разница между «хорошо написанным промптом» и «системой, которая стабильно решает задачи» - именно в инженерии контекста. За три года между запуском GPT-3.5 и появлением агентных IDE отрасль прошла путь от «давайте всё запихнём в промпт» через «давайте достанем релевантное из векторной базы» к «давайте спроектируем, как контекст рождается, живёт и умирает на протяжении многошаговой задачи». Эта статья разбирает, как и почему дисциплина появилась, какие у контекста режимы отказа, как выбирать между just-in-time и предзагрузкой, какие техники работают на длинных задачах и чем измерять качество контекста в продакшне.

Context engineering как дисциплина: откуда взялась Context engineering vs prompt engineering Контекстное окно как дефицитный ресурс Режимы отказа контекста и как их диагностировать Шесть компонентов context engineering Проектирование системных промптов Дизайн инструментов Just-in-time vs. предзагрузка: рамка решения Техники для длинных задач с доказательной базой Инструментарий и измерение Антипаттерны context engineering Практические рекомендации Источники

Context engineering как дисциплина: откуда взялась

Context engineering - дисциплина проектирования архитектуры, которая подаёт LLM нужную информацию в нужный момент. Anthropic формулирует ключевой вопрос так: «какая конфигурация контекста с наибольшей вероятностью приведёт к желаемому поведению модели?» Контекст включает всё, что модель «видит» при генерации ответа: системный промпт, инструкции, описания инструментов, внешние данные, историю сообщений и результаты вызовов инструментов. Каждый из этих элементов занимает токены в конечном контекстном окне.

Дисциплина не появилась из теоретических соображений. Она выросла из накопившегося опыта неудач RAG-систем 2023-2024 годов и признания, что модели большего размера сами по себе не создают лучших AI-систем. Надёжность зависит от того, как информация проходит через систему, а не от размера модели или изобретательности промпта.

Прародитель - оригинальная RAG-статья. В 2020 году Patrick Lewis с коллегами из Facebook AI Research опубликовали «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks» (NeurIPS 2020). Идея простая и оказавшаяся очень продуктивной: вместо того чтобы хранить все знания в параметрах модели, держать их во внешнем индексе и подтягивать релевантные фрагменты в контекст в момент генерации. Эта статья дала отрасли архитектурный шаблон retrieve-then-generate, на котором следующие три года выросло целое поколение продуктов - от чат-ботов с базой знаний до Q&A над приватными документами. Но шаблон оказался обманчиво простым: первая волна RAG-внедрений показала, что качественное извлечение - отдельная инженерная задача, а не «возьмите любой векторный поиск».

Karpathy и фрейм контекстного окна. В мае 2023 года Andrej Karpathy на Microsoft Build выступил с лекцией «State of GPT», где впервые широко популяризовал метафору контекстного окна как «рабочей памяти» модели и предупредил аудиторию: всё, что попало в это окно, влияет на вывод, и потому отбор содержимого окна - такая же инженерная задача, как обучение модели. Эта лекция важна не как источник новых идей, а как момент, когда сообщество разработчиков получило общий словарь: «context window», «in-context learning», «few-shot». Karpathy позже сформулировал известный тезис, что software 3.0 - это «программирование контекстом», и эта рамка плотно прижилась.

Lance Martin и серия «Context Engineering» в LangChain. С 2024 года Lance Martin (LangChain) в серии постов на блоге компании последовательно вводил термин «context engineering» как обобщение того, что раньше называлось «retrieval», «prompt design», «memory management» по отдельности. Его аргумент: эти три практики решают одну и ту же задачу - управление содержимым контекстного окна - и должны проектироваться вместе. Серия зафиксировала переход от «у нас есть RAG-пайплайн» к «у нас есть контекстная архитектура».

Drew Breunig и формулировка «context rot». Параллельно Drew Breunig в эссе «How Long Contexts Fail» дал имя явлению, которое многие наблюдали, но не умели обсуждать: по мере роста длины контекста модель начинает деградировать в специфических измерениях, и просто «увеличение окна» не решает проблему. Термин «context rot» закрепился в индустрии как короткое обозначение целого семейства failure modes (см. ниже).

Anthropic и оформление дисциплины. К осени 2025 года Anthropic в посте «Effective context engineering for AI agents» формализовал название дисциплины и собрал в одном месте практики, которые уже использовались в Claude Code: just-in-time retrieval, compaction, sub-agent архитектура, structured note-taking. Этот пост стал общеупотребительной точкой отсчёта - не потому, что Anthropic «изобрёл» context engineering, а потому, что они первыми системно описали его как отдельную инженерную практику с конкретными приёмами и trade-offs.

Полезный исторический урок: дисциплина возникла из failures, а не из success. RAG в 2023 году обещал «дайте нам ваши документы и получите Q&A», и это обещание массово не сбылось - точнее, сбылось на демо и сломалось в продакшене. Из разбирательств с тем, почему сломалось, выросли отдельные практики - chunking-стратегии, hybrid search, reranking, query rewriting, evaluation harness - которые сначала жили под зонтиком «advanced RAG», а потом перегруппировались в более широкое понятие, включающее не только retrieval, но и память, инструменты, управление длинными задачами. Это типовой паттерн: новая дисциплина рождается, когда практики из соседних областей перестают укладываться в исходные ярлыки.

Context engineering vs prompt engineering

Prompt engineering фокусируется на формулировке инструкций: как задать вопрос, чтобы получить нужный ответ. Context engineering строит инфраструктуру, которая соединяет модель с внешними данными.

Аналогия: prompt engineering - это как вы задаёте вопрос, а context engineering - это обеспечить модель нужным учебником, калькулятором и заметками до того, как она начнёт отвечать. Riley Goodside, один из ранних публичных prompt-инженеров, в 2022-2023 годах детально документировал технику «всё умещается в один длинный промпт» - и его же опыт в дальнейших проектах показал, где эта техника ломается: на длинных задачах, где состояние не помещается в контекст, и на динамичных данных, где «длинный промпт» устаревает быстрее, чем его успевают написать.

Prompt Engineering Context Engineering
Фокус Формулировка запроса Архитектура информационного потока
Масштаб Один запрос Система из нескольких inference-вызовов
Управляет Тоном, форматом, стилем ответа Какие данные попадают в окно и когда
Результат Лучший ответ на конкретный вопрос Стабильная система, решающая класс задач
Эволюция Ручная итерация промптов Архитектурные решения по памяти, retrieval, инструментам

Prompt engineering не исчезает - он становится одним из компонентов context engineering. Хорошо сформулированный промпт внутри плохо спроектированного контекста не спасёт систему.

Контекстное окно как дефицитный ресурс

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

Исследования показывают эффект context rot: по мере роста числа токенов модель теряет точность извлечения информации. Архитектура трансформера требует n² попарных связей для n токенов, что делает длинные последовательности прогрессивно сложнее для обработки. Модели остаются «способными» на длинных контекстах, но точность снижается.

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

Практическое следствие, которое стоит вынести отдельно: рост окна модели с 8K до 200K и далее до 1M+ токенов не отменяет дисциплину, а смещает её акценты. Раньше задача звучала «как уместить нужное в маленькое окно». Сейчас она звучит «как не утопить нужное в большом окне» - модель с 1M контекстом, в которую запихнули весь репозиторий, по поведению часто хуже, чем модель с 200K, в которую загрузили только релевантные файлы.

Режимы отказа контекста и как их диагностировать

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

Режим Описание Пример
Context Poisoning Ошибки накапливаются: агент переиспользует загрязнённую информацию Агент получил неверный результат API и строит дальнейшие решения на нём
Context Distraction Избыточная история заставляет модель опираться на устаревшие паттерны Агент повторяет подход, который уже не работает, потому что он есть в ранней истории
Context Confusion Нерелевантные инструменты или документы вводят модель в заблуждение 20 доступных инструментов, из которых 18 не нужны для текущей задачи
Context Clash Противоречивая информация создаёт конфликтующие предположения Системный промпт говорит одно, а извлечённый документ - противоположное
Lost in the Middle Модель пропускает информацию, расположенную в середине длинного контекста Релевантный документ в середине списка из 20 - модель отвечает, как будто его нет

Lost in the Middle - самый цитируемый результат экспериментов с длинным контекстом. Liu et al. (Stanford, «Lost in the Middle: How Language Models Use Long Contexts», 2023) показали систематическую U-образную кривую: модели хорошо извлекают информацию из начала и конца длинного контекста и значительно хуже из середины. Эффект воспроизводился на разных моделях и разных задачах. Практическое следствие для дизайна: критическую информацию (текущую задачу, недавно обновлённое состояние) держите в начале или конце окна, а не в середине большого блока ретривнутых документов.

Context distraction исследовали Shi et al. в работе «Large Language Models Can Be Easily Distracted by Irrelevant Context» (2023): достаточно вставить в промпт нерелевантный, но грамматически связный фрагмент, чтобы заметно деградировала точность на математических и логических задачах. Это объясняет, почему «больше контекста для надёжности» часто работает в обратную сторону: лишние факты не нейтральны, они активно конкурируют за внимание модели.

Диагностика на практике. Когда агент ведёт себя странно, первый вопрос - какой именно failure mode сработал. Полезный мини-чеклист:

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

Шесть компонентов context engineering

1. Агенты

AI-агенты используют LLM как движок рассуждений и оркестрируют решения между инструментами, памятью и базами знаний. Агент выступает одновременно потребителем и архитектором контекста: он решает, какая информация поднимается на поверхность на каждом шаге.

2. Аугментация запросов (Query Augmentation)

Пользовательский ввод в реальном мире - неполный и неоднозначный. Аугментация запросов переформулирует входные данные для разных downstream-систем: запрос в векторную базу данных требует одной формулировки, запрос к LLM - другой.

3. Извлечение (Retrieval)

Качественное извлечение - фундамент: «мусор на входе - мусор на выходе» действует напрямую. Критический trade-off - стратегия чанкинга:

4. Промптинг

Извлечённый контекст требует явных инструкций по его использованию. Техники: Chain-of-Thought (рассуждение по шагам), few-shot (примеры ожидаемого поведения), ReAct (цикл «рассуждение - действие - наблюдение»).

5. Память

Память агента состоит из трёх слоёв:

Эффективная система памяти - селективная: сохраняет только высокосигнальную информацию и периодически удаляет устаревшие записи.

6. Инструменты

Инструменты связывают мышление с действием: запросы к БД, вызовы API, получение актуальных данных. Model Context Protocol (MCP) стандартизирует интеграцию инструментов через универсальный JSON-RPC протокол, заменяя кастомные интеграции.

Проектирование системных промптов

Anthropic рекомендует калибровать системный промпт на «правильной высоте» - между двумя крайностями:

Практические рекомендации:

Дизайн инструментов

Хорошо спроектированные инструменты:

Если человек не может однозначно выбрать нужный инструмент из набора - AI-агент тоже не сможет. Раздутые наборы инструментов создают неоднозначные точки принятия решений.

Just-in-time vs. предзагрузка: рамка решения

Самый распространённый архитектурный выбор в context engineering - между двумя стратегиями:

Это не про «какая стратегия лучше», а про то, какие свойства задачи заставляют выбирать одну, а не другую. Полезная таблица для решения:

Характеристика задачи Pre-loaded Just-in-time
Релевантные документы известны до запуска Да - подаём сразу Излишне - не нужна динамика
Объём потенциально релевантных данных значительно больше окна Не работает - не уместится Естественный выбор
Latency критична (пользователь ждёт ответ за секунды) Лучше - один вызов модели Хуже - несколько round-trips
Документы быстро меняются между шагами Контекст устаревает Свежие данные на каждом шаге
Команда без LLM-эксплуатационного опыта Проще запустить Сложнее отладить

Just-in-time на практике

Anthropic Claude Code - канонический пример just-in-time подхода. Агент навигирует по файловой системе и анализирует кодовые базы, не загружая целые объекты в контекст: вместо этого он использует Read, Glob, Grep как инструменты. Размеры файлов сигнализируют о сложности, имена указывают на назначение, timestamps подсказывают релевантность. Контекст «открывается прогрессивно» - по мере того, как агент решает, что именно ему нужно посмотреть. Подход публично описан в блоге Anthropic Engineering и виден в открытом исходнике CLI.

Aider (Paul Gauthier, open-source) использует промежуточную стратегию - так называемую repo-map технику. Aider не загружает в контекст ни весь репозиторий, ни «только то, что попросит модель» - вместо этого он строит компактную карту репозитория (имена файлов, символы, структура импортов) и подаёт её модели как навигационный артефакт. Модель решает по карте, какие файлы запросить целиком. Документация: aider.chat/docs/repomap.

Cursor IDE в публичной документации описывает многоуровневую стратегию: для коротких диалогов работает обычная история, для запросов с явной ссылкой на файл (через @-mentions) - pre-loaded подгрузка, для агентного режима - комбинация semantic search по индексу проекта плюс инструменты для чтения файлов по запросу модели. Ссылка: docs.cursor.com.

Cline и Continue.dev - open-source IDE-расширения, которые пошли по схожему пути: контекст собирается из активного файла, выделения, диагностики LSP, плюс инструменты для агентского чтения остального проекта. Они интересны как доказательство, что just-in-time подход воспроизводим вне крупных вендоров и не требует проприетарной инфраструктуры. Cline: github.com/cline/cline; Continue.dev: docs.continue.dev.

Pre-loaded на практике

Классический RAG для Q&A над документацией - всё ещё абсолютно валидный шаблон, и большинство production-внедрений LLM в корпоративных продуктах живут именно по нему. Стек обычно состоит из эмбеддинг-модели (OpenAI text-embedding-3, Cohere embed-v3, voyageai), векторного хранилища (pgvector, Chroma, Weaviate, Qdrant) и оркестратора (LlamaIndex, LangChain), который собирает retrieval-пайплайн с reranking. Этот шаблон описан в десятках туториалов; стилизованный пример типичного внедрения - корпоративный support-бот, который ретривит топ-5 фрагментов из knowledge base и подаёт их в промпт. Этот пример не цитирует конкретную компанию - это стилизованный пример на основе типичных паттернов, потому что архитектура повторяется почти везде с минимальными вариациями.

Гибридные модели

На практике большинство production-агентов гибридны: семантический поиск даёт первичную выборку, инструменты позволяют дозапрашивать недостающее. Граница зависит от характеристик задачи и динамичности контента. Полезный принцип: pre-load то, что нужно гарантированно (текущая задача, активный файл, последняя ошибка), и оставьте just-in-time для всего остального.

Техники для длинных задач с доказательной базой

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

Compaction (сжатие контекста)

При приближении к лимиту контекстного окна - суммаризировать содержимое и реинициализировать с конденсированным резюме. Принципы:

Доказательство в продакшене: Claude Code реализует это через команду /compact, которая сжимает историю разговора с сохранением последних прочитанных файлов и активных задач. Компактация - не «отдалённая идея», а ежедневная практика для пользователей, которые ведут длинные сессии разработки. Аналогичные механизмы есть в Cursor (auto-summarize при подходе к лимиту) и в Cline (manual context window cleanup).

Structured note-taking (структурированные заметки)

Агент ведёт внешние файлы памяти (NOTES.md, TODO-списки, plan.md), которые регулярно обновляет и перечитывает при сбросе контекста. Это обеспечивает:

Доказательство в продакшене: Claude Code использует CLAUDE.md как persistent context, который автоматически подтягивается в начало каждой сессии, и активно работает с TODO-списками через TodoWrite-инструмент. Devin от Cognition Labs построен вокруг идеи постоянной памяти агента: scratchpad-файлы, в которых агент фиксирует план и промежуточные результаты, переживают переходы между шагами и серверные перезапуски. Стилизованный пример пользы заметок - long-running рефакторинг, где агент за 30+ шагов несколько раз возвращается к собственному плану, чтобы свериться с приоритетами; типичный паттерн воспроизводится в любой агентной IDE и описан как «стилизованный пример на основе типичных паттернов».

Sub-agent архитектура

Специализированные подагенты выполняют фокусные задачи с чистым контекстным окном. Подагент может потратить тысячи токенов на исследование, но вернуть конденсированное резюме в 1000-2000 токенов. Основной агент координирует высокоуровневый план и синтезирует результаты.

Доказательство в продакшене: Claude Code предоставляет Task-инструмент, через который основной агент делегирует подзадачи специализированным подагентам с собственным контекстом. GitHub Copilot Workspace, представленный в 2024 году, в preview-режиме реализует сходную идею - «спецификация - план - реализация» как стадии с собственными контекстами. Devin и аналогичные «agentic» системы используют sub-agent architecture как способ удержать контекст основного агента в управляемых пределах.

Когда что использовать

Техника Лучше всего подходит для Производственные примеры
Compaction Разговорные задачи с интенсивным обменом сообщениями Claude Code /compact, Cursor auto-summarize
Note-taking Итеративная разработка с чёткими milestone-ами CLAUDE.md, Devin scratchpad, TODO-инструменты
Sub-agents Исследование и анализ с возможностью параллельного выполнения Claude Code Task, Copilot Workspace stages

Инструментарий и измерение

Любой инженерной дисциплине нужен измерительный аппарат. Без него «улучшения промпта» индустриально неотличимы от суеверия. Context engineering - не исключение; ниже - те инструменты, которые сложились в стандартный набор за 2023-2025 годы.

Трассировка и наблюдение

LangSmith (LangChain) - индустриальный стандарт для трассировки LLM-приложений. Каждый вызов модели и каждый retrieval сохраняется как trace; можно посмотреть, какой именно контекст был подан в окно, какой ответ вернулся, сколько токенов израсходовано. Документация: docs.smith.langchain.com. Открытые альтернативы - Langfuse и Helicone; принцип одинаковый.

Anthropic в своих инструментах (Claude Console, Workbench) предоставляет аналогичную картину - распределение токенов по типам контента (system, user, tool result, generated) и утилизация контекстного окна по сессии. Без этой картины нельзя осмысленно говорить о «бюджете токенов» - можно только догадываться.

Хранение и индексация

Стандартный набор векторных хранилищ:

Оркестрация retrieval-пайплайнов

LlamaIndex и LangChain - две основные библиотеки для сборки retrieval-пайплайнов. LlamaIndex исторически глубже в retrieval-стратегиях (sub-question query, recursive retriever, hybrid search), LangChain - шире по охвату (агенты, инструменты, интеграции). На практике они часто соседствуют. Документация: docs.llamaindex.ai, python.langchain.com.

Качественные метрики

Минимальный набор, который должен быть в production-системе с context engineering:

Главное правило измерения: метрики собираются с самого начала, а не «когда дойдут руки». Без исторических данных любое сравнение «до и после» сводится к субъективному ощущению.

Антипаттерны context engineering

Большинство неработающих LLM-систем ломаются не на «модель плохая», а на типовых архитектурных ошибках в обращении с контекстом. Список ниже стоит пройти как чеклист до того, как обвинить модель.

Prompt-stuffing без retrieval. Соблазн «давайте просто запихнём весь репозиторий или всю документацию в промпт» очень велик, особенно с появлением 1M-контекстов. Проблема в том, что без relevance-фильтрации модель платит вниманием за каждый токен и быстро упирается в context rot и lost-in-the-middle. Внешне это выглядит как «модель всё знает, но отвечает мимо». Решение - retrieval, даже если окно позволяет обойтись без него.

Никакой компактации. Long-running агентные сессии без compaction-механизма растут монотонно: история, результаты инструментов, промежуточные размышления. К концу сессии в окне столько шума, что свежий запрос конкурирует с тысячами старых токенов. Симптом - «утром агент работал, к вечеру стал тупее». Решение - явный механизм compaction по триггеру (доля окна, число сообщений, время сессии).

Sub-agent overuse. Обратная крайность: команда вдохновляется идеей подагентов и начинает делегировать любую мелочь. На простой задаче, которую основной агент решил бы за один шаг, появляется тройной round-trip с serialization/deserialization контекста и накладные расходы на координацию. Эвристика: подагент оправдан, если фокусная задача требует существенно отдельного контекста или если параллелизм даёт реальный выигрыш.

Few-shot примеры с устаревшими паттернами. Few-shot работает, потому что модель копирует паттерн из примеров. Если примеры устарели (старая API, deprecated подход, исправленный баг), модель честно скопирует устаревшее. Симптом - модель упорно пишет код в стиле, от которого команда отказалась полгода назад. Решение - привязка few-shot примеров к версионированному источнику и регулярный аудит.

Игнорирование needle-in-haystack деградации. Многие команды доверяют рекламным цифрам про «100% recall на 1M токенов» и проектируют систему, исходя из того, что модель прочитает любой документ в окне одинаково внимательно. Реальные бенчмарки (Lost in the Middle, NoLima, RULER) показывают U-образную или хуже кривую. Симптом - модель «не видит» документ, который явно есть в контексте. Решение - проектировать раскладку контекста с учётом позиционных эффектов и измерять retrieval-эффективность на реальных задачах.

Жёсткое кодирование context budget без измерения. «Выделим 8000 токенов на retrieval, 4000 на историю, 2000 на инструменты» - звучит инженерно, но в отсутствие измерений эти цифры взяты с потолка. Реальное распределение зависит от типа задачи; что работает для Q&A, не работает для кодинга. Решение - сначала собрать данные о реальном утилизации, потом выставлять бюджеты.

Контекст как git без git. Команды редко версионируют системный промпт и набор инструментов. Через полгода в Confluence лежит четыре версии «текущего промпта», в коде - ещё две, в продакшене - какая-то третья. Когда что-то ломается, никто не помнит, что именно поменялось. Решение - системные промпты, инструменты и шаблоны хранить в репозитории под git с теми же ревью-практиками, что и обычный код.

Эвристика для self-check: если на пункт «у нас этого нет, потому что не задумались» отвечает «да» - это техдолг с понятной стоимостью первого инцидента.

Практические рекомендации

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

Управление контекстным окном

  1. Относитесь к токенам как к бюджету - стратегически распределяйте место на высокосигнальную информацию
  2. Внедряйте селективную память - оценка важности при записи и периодическое удаление устаревших записей
  3. Оптимизируйте стратегию чанкинга - баланс между точностью (мелкие чанки) и контекстным богатством (крупные чанки)

Проектирование инструментов и промптов

  1. Начинайте с минимального промпта - добавляйте инструкции только по мере обнаружения реальных ошибок
  2. Структурируйте секции - XML-теги и заголовки позволяют модели эффективнее навигировать по промпту
  3. Используйте примеры вместо правил - diverse few-shot примеры демонстрируют желаемое поведение эффективнее, чем перечисление edge-кейсов
  4. Стандартизируйте интеграцию - MCP вместо кастомных интеграций для каждого инструмента

Архитектура агентов

  1. Используйте just-in-time retrieval - лёгкие идентификаторы вместо предзагрузки всего
  2. Создавайте циклы обратной связи - агент наблюдает за результатами и корректирует стратегию
  3. Выбирайте технику по задаче - compaction для диалогов, заметки для итеративной разработки, подагенты для параллельного исследования
По мере улучшения моделей они требуют всё меньше прескриптивной инженерии и допускают большую автономию агентов. Но обращение с контекстом как с ценным конечным ресурсом остаётся необходимым условием для надёжных систем.

Источники

Первоисточники и фундаментальные работы

Практики и отраслевые источники

Производственные системы и реализации

Инструментарий и измерение