Команда AI for Devs подготовила перевод статьи об инженерии контекста — новом ключевом подходе в построении AI-агентов. Если раньше все говорили о prompt engineering, то теперь на первый план выходит умение управлять ограниченным ресурсом — контекстом. Уплотнение, заметки, подагенты, динамическая подгрузка данных — всё это формирует новое искусство работы с LLM.

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

После нескольких лет, когда всё внимание в прикладном ИИ было сосредоточено на prompt engineering, на первый план вышел новый термин — context engineering. Теперь работа с языковыми моделями всё меньше сводится к поиску правильных слов и фраз для промптов и всё больше — к ответу на более широкий вопрос: «какая конфигурация контекста с наибольшей вероятностью приведёт к нужному поведению модели?»

Под контекстом понимается набор токенов, включённых при генерации ответа большой языковой моделью (LLM). Инженерная задача здесь — максимально эффективно использовать эти токены в условиях ограничений LLM, чтобы стабильно получать нужный результат. Умелая работа с LLM требует мышления в терминах контекста, то есть понимания всей совокупности состояния, доступного модели в данный момент, и тех потенциальных действий, которые оно может вызвать.

В этой статье мы рассмотрим зарождающееся искусство context engineering и предложим уточнённую ментальную модель для построения управляемых и эффективных агентов.

Context engineering vs. prompt engineering

В Anthropic мы рассматриваем context engineering как естественное продолжение prompt engineering. Prompt engineering описывает методы написания и организации инструкций для LLM с целью получения оптимальных результатов (см. нашу документацию для обзора и полезных стратегий по prompt engineering). Context engineering же охватывает набор стратегий по отбору и поддержанию оптимального набора токенов (информации) во время инференса LLM, включая всё то, что может попасть туда помимо самих промптов.

На ранних этапах работы с LLM основная часть инженерии сводилась к написанию промптов, так как большинство кейсов за пределами повседневного общения требовали оптимизированных промптов для задач классификации «с одного примера» или генерации текста. Как следует из названия, ключевой акцент prompt engineering — на том, как писать эффективные промпты, особенно системные. Однако по мере того как мы движемся к созданию более мощных агентов, работающих в многократных циклах инференса и на более длинных временных горизонтах, нужны стратегии управления всем состоянием контекста: системными инструкциями, инструментами, Model Context Protocol (MCP), внешними данными, историей сообщений и т.д.

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

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

Почему context engineering важен для построения сильных агентов

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

Хотя у одних моделей эта деградация проявляется мягче, чем у других, она характерна абсолютно для всех. Поэтому контекст следует рассматривать как ограниченный ресурс с убывающей отдачей. Как и у человека, у которого есть предел рабочей памяти, у LLM существует «бюджет внимания», расходуемый при обработке больших объёмов контекста. Каждый новый токен уменьшает этот бюджет, усиливая необходимость тщательно отбирать те токены, которые будут доступны модели.

Этот дефицит внимания связан с архитектурными ограничениями LLM. Они построены на трансформерах, где каждый токен может взаимодействовать с каждым другим токеном в пределах контекста. Это создаёт n² парных связей при n токенах.

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

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

Эти особенности делают вдумчивый context engineering необходимым условием при создании по-настоящему сильных агентов.

Анатомия эффективного контекста

Так как LLM ограничены конечным «бюджетом внимания», грамотный context engineering означает поиск минимального набора токенов с максимальным «сигналом», которые повышают вероятность дост��жения нужного результата. Реализовать этот принцип на практике намного сложнее, чем сказать, но в следующем разделе мы разберём, как он работает применительно к разным составляющим контекста.

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

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

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

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

На одном краю спектра мы видим хрупкие промпты с жёстко прописанными if-else условиями, а на другом — чрезмерно общие промпты, которые ложно предполагают наличие общего контекста.

Мы рекомендуем организовывать промпты в отдельные секции (например, <background_information>, <instructions>, ## Tool guidance, ## Output description и т.п.), используя техники вроде XML-тегов или Markdown-заголовков для их разграничения. Хотя стоит отметить, что по мере роста возможностей моделей точное форматирование промптов постепенно теряет решающее значение.

Как бы вы ни решили структурировать системный промпт, цель остаётся одной: минимальный набор информации, который полностью описывает ожидаемое поведение. (Важно: «минимальный» не означает «короткий» — агенту всё равно нужно дать достаточно данных заранее, чтобы он мог следовать нужному поведению.) Лучше всего начать с теста минимального промпта на самой сильной доступной модели, посмотреть, как он справляется с задачей, а затем добавлять ясные инструкции и примеры, чтобы закрывать сбои, обнаруженные в ходе первичного тестирования.

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

В статье Writing tools for AI agents – with AI agents мы обсуждали подходы к созданию инструментов, хорошо понимаемых LLM, без лишнего пересечения по функциям. Подобно функциям в продуманной кодовой базе, инструменты должны быть самодостаточными, устойчивыми к ошибкам и предельно ясными в плане предназначения. Параметры ввода должны быть описательными, недвусмысленными и использовать сильные стороны модели.

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

Примеры (или few-shot prompting) — это хорошо известная и по-прежнему крайне рекомендуемая практика. Однако нередко команды пытаются запихнуть в промпт длинный список крайних случаев, чтобы прописать каждое возможное правило для конкретной задачи. Мы не советуем этого делать. Вместо этого лучше тщательно отобрать разнообразный набор канонических примеров, которые наглядно демонстрируют ожидаемое поведение агента. Для LLM примеры — это те самые «картинки», которые стоят тысячи слов.

Общий совет для всех компонентов контекста (системные промпты, инструменты, примеры, история сообщений и пр.) — быть вдумчивым и делать контекст информативным, но при этом компактным. Теперь перейдём к теме динамического получения контекста во время выполнения.

Извлечение контекста и агентный поиск

В статье Building effective AI agents мы разбирали различия между рабочими процессами на основе LLM и агентами. С тех пор мы пришли к простому определению: агент — это LLM, которая автономно использует инструменты в цикле.

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

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

Вместо того чтобы заранее обрабатывать все релевантные данные, агенты, построенные по принципу «just in time», хранят лишь лёгкие идентификаторы (пути к файлам, сохранённые запросы, ссылки и т. д.) и используют эти ссылки, чтобы динамически подгружать данные в контекст во время работы с помощью инструментов. Агентное решение Anthropic для программирования — Claude Code — применяет именно этот подход для выполнения сложного анализа данных в больших базах. Модель может писать целевые запросы, сохранять результаты и использовать команды Bash вроде head и tail, чтобы анализировать большие объёмы данных, не загружая весь объект целиком. Такой подход напоминает работу человеческого мышления: мы обычно не запоминаем целые блоки информации, а организуем её во внешних системах вроде файловых структур, почтовых ящиков или закладок, чтобы доставать нужное по запросу.

Помимо экономии памяти, метаданные этих ссылок дают способ эффективно уточнять поведение — как явно, так и неявно. Для агента, работающего с файловой системой, файл test_utils.py в папке tests несёт иной смысл, чем файл с тем же названием в src/core_logic.py. Иерархия папок, соглашения об именовании и метки времени дают важные сигналы, которые помогают и людям, и агентам понять, как и когда использовать информацию.

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

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

В некоторых случаях наиболее эффективными оказываются агенты, использующие гибридную стратегию: ч��сть данных извлекается заранее для скорости, а затем агент по своему усмотрению продолжает автономное исследование. Граница «правильного» уровня автономии зависит от конкретной задачи. Claude Code реализует именно такую гибридную модель: файлы CLAUDE.md без изысков помещаются в контекст на старте, а примитивы вроде glob и grep позволяют агенту ориентироваться в окружении и подгружать файлы по требованию, эффективно обходя проблемы устаревшей индексации и сложных синтаксических деревьев.

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

Инженерия контекста для долгосрочных задач

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

Ждать увеличения контекстных окон кажется очевидной тактикой. Но, скорее всего, ещё долго любые окна будут подвержены «загрязнению контекста» и проблеме релевантности информации — особенно в сценариях, где требуется максимальная эффективность работы агента. Чтобы агенты могли успешно действовать на длинных временных горизонтах, мы разработали несколько техник, которые напрямую решают проблему загрязнения контекста: уплотнение, структурированные заметки и мультиагентные архитектуры.

Уплотнение (Compaction)

Уплотнение — это практика, при которой длинный диалог, приближающийся к лимиту контекстного окна, сворачивается в краткое содержание, после чего создаётся новое контекстное окно уже с этим сжатием. Обычно именно уплотнение служит первым инструментом context engineering, позволяя обеспечить более долгосрочную связность. По сути, уплотнение отфильтровывает содержимое контекстного окна максимально точно, чтобы агент мог продолжить работу с минимальными потерями в качестве.

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

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

Простой пример "низко висящих фруктов" — это очистка вызовов инструментов и их результатов. Если инструмент уже был вызван где-то далеко в истории, зачем агенту снова видеть его сырой вывод? Один из самых безопасных и лёгких приёмов уплотнения — очистка результатов инструментов. Эта возможность недавно появилась как отдельная функция на платформе Claude Developer.

Структурированное ведение заметок

Структурированное ведение заметок, или агентская память, — это приём, при котором агент регулярно фиксирует записи во внешнем хранилище, за пределами контекстного окна. Позже эти заметки подгружаются обратно в контекст.

Такая стратегия обеспечивает постоянную память с минимальными издержками. Например, Claude Code ведёт список дел, а ваш кастомный агент может поддерживать файл NOTES.md. Этот простой приём позволяет агенту отслеживать прогресс в сложных задачах, сохраняя ключевой контекст и зависимости, которые иначе затерялись бы среди десятков вызовов инструментов.

Хорошая иллюстрация — Claude, играющий в Pokémon: память превращает агента в гораздо более сильного игрока за пределами кода. Агент аккуратно ведёт подсчёты на протяжении тысяч шагов игры: фиксирует цели вроде «последние 1234 шага я прокачиваю покемона на Route 1, Пикачу получил +8 уровней из 10 нужных». Без какой-либо специальной подсказки о структуре памяти агент строит карты исследованных областей, помнит, какие ключевые достижения уже открыты, и ведёт стратегические заметки о боевых приёмах, помогая самому себе понимать, какие атаки лучше работают против конкретных соперников.

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

В рамках запуска Sonnet 4.5 мы представили инструмент памяти в публичной бете на платформе Claude Developer. Он упрощает хранение и использование информации вне контекста через файловую систему. Это позволяет агентам со временем накапливать собственные базы знаний, сохранять состояние проекта между сессиями и обращаться к прошлой работе без необходимости держать всё в контексте.

Архитектуры с подагентами

Архитектуры с подагентами предлагают ещё один способ обойти ограничения контекста. Вместо того чтобы один агент пытался удерживать всё состояние проекта, специализированные подагенты берут на себя узкие задачи в «чистых» контекстных окнах. Главный агент управляет процессом по общему плану, а подагенты выполняют глубокую техническую работу или используют инструменты для поиска релевантной информации. Каждый подагент может исследовать тему очень подробно, расходуя десятки тысяч токенов и больше, но возвращает только сжатое резюме своей работы (обычно 1000 – 2000 токенов).

Такой подход обеспечивает чёткое разделение ответственности: детализированный контекст поиска остаётся внутри подагентов, а главный агент сосредотачивается на синтезе и анализе результатов. Этот паттерн, подробно описанный в статье How we built our multi-agent research system, показал значительное преимущество по сравнению с одноагентными системами на сложных исследовательских задачах.

Выбор подхода зависит от характера задачи. Например:

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

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

Русскоязычное сообщество про AI в разработке

Друзья! Эту новость подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!

Заключение

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

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

Как работает Context Engineering в Claude и других агентах