Эффективный контекст-инжиниринг для ИИ-агентов
Контекст — критически важный, но конечный ресурс для ИИ-агентов. В этой статье мы разбираем стратегии эффективного отбора и управления контекстом, который питает агентов.
После нескольких лет, когда в прикладном ИИ в центре внимания был промпт-инжиниринг, на первый план вышел новый термин — контекст-инжиниринг. Разработка на основе языковых моделей всё меньше сводится к поиску правильных слов и формулировок для промптов и всё больше — к ответу на более широкий вопрос: «какая конфигурация контекста с наибольшей вероятностью вызовет нужное нам поведение модели?»
Контекст — это набор токенов, которые попадают в модель при сэмплировании из большой языковой модели (LLM). Инженерная задача состоит в том, чтобы оптимизировать полезность этих токенов с учётом присущих LLM ограничений и стабильно добиваться нужного результата. Эффективное «укрощение» LLM часто требует мышления в терминах контекста — то есть учёта целостного состояния, доступного модели в каждый момент, и того, какое поведение это состояние способно породить.
В этой статье мы исследуем зарождающееся искусство контекст-инжиниринга и предлагаем уточнённую ментальную модель для создания управляемых и эффективных агентов.
Контекст-инжиниринг против промпт-инжиниринга
В Anthropic мы рассматриваем контекст-инжиниринг как естественное развитие промпт-инжиниринга. Промпт-инжиниринг — это методы написания и организации инструкций для LLM ради наилучшего результата. Контекст-инжиниринг — это набор стратегий отбора и поддержания оптимального набора токенов (информации) в процессе инференса LLM, включая всю прочую информацию, которая может туда попасть помимо самих промптов.
На заре разработки на LLM промптинг был крупнейшей составляющей работы ИИ-инженера, поскольку большинство сценариев вне повседневного чата требовали промптов, оптимизированных под одноразовую классификацию или генерацию текста. Как следует из названия, главный фокус промпт-инжиниринга — то, как писать эффективные промпты, особенно системные. Однако по мере того как мы переходим к более способным агентам, работающим на протяжении множества шагов инференса и более длинных временных горизонтов, нам нужны стратегии управления всем состоянием контекста (системные инструкции, инструменты, Model Context Protocol (MCP), внешние данные, история сообщений и т. д.).
Агент, работающий в цикле, порождает всё больше данных, которые могут оказаться полезными на следующем шаге инференса, и эту информацию нужно циклически отсеивать. Контекст-инжиниринг — это искусство и наука отбора того, что попадёт в ограниченное контекстное окно из постоянно растущей вселенной возможной информации.
В отличие от дискретной задачи написания промпта, контекст-инжиниринг итеративен, и фаза отбора происходит каждый раз, когда мы решаем, что передать модели.
Почему контекст-инжиниринг важен для создания способных агентов
Несмотря на скорость и способность обрабатывать всё большие объёмы данных, мы заметили, что LLM, как и люди, в определённый момент теряют фокус или начинают путаться. Исследования по бенчмаркам вида «иголка в стоге сена» выявили понятие деградации контекста (context rot): по мере роста числа токенов в контекстном окне способность модели точно извлекать информацию из этого контекста снижается.
Одни модели деградируют мягче других, но эта особенность проявляется у всех. Поэтому контекст следует рассматривать как конечный ресурс с убывающей предельной отдачей. Как у людей с ограниченным объёмом рабочей памяти, у LLM есть «бюджет внимания», который они расходуют при разборе больших объёмов контекста. Каждый новый токен в той или иной мере истощает этот бюджет, из-за чего критически важно тщательно отбирать доступные модели токены.
Этот дефицит внимания вытекает из архитектурных ограничений LLM. LLM построены на архитектуре трансформера, где каждый токен может «внимать» каждому другому токену во всём контексте. Это порождает n² попарных связей для n токенов.
С ростом длины контекста способность модели улавливать эти попарные связи размывается, создавая естественное напряжение между размером контекста и фокусом внимания. Кроме того, модели формируют свои паттерны внимания на распределениях обучающих данных, где короткие последовательности обычно встречаются чаще длинных. Это значит, что у моделей меньше опыта и меньше специализированных параметров для зависимостей на всю ширину контекста.
Приёмы вроде интерполяции позиционного кодирования позволяют моделям обрабатывать более длинные последовательности, адаптируя их к меньшему контексту, на котором они изначально обучались, — хотя и с некоторой потерей понимания позиции токенов. Из-за этих факторов возникает градиент производительности, а не резкий обрыв: модели остаются весьма способными на длинных контекстах, но могут показывать сниженную точность при извлечении информации и рассуждениях на большие дистанции по сравнению с работой на коротких контекстах.
Всё это означает, что продуманный контекст-инжиниринг необходим для создания способных агентов.
Анатомия эффективного контекста
Поскольку LLM ограничены конечным бюджетом внимания, хороший контекст-инжиниринг — это поиск наименьшего возможного набора высокосигнальных токенов, которые максимизируют вероятность нужного исхода. На практике это куда сложнее, чем на словах, но ниже мы разбираем, что этот принцип означает для разных составляющих контекста.
Системные промпты должны быть предельно ясными и написанными простым, прямым языком, подающим идеи на правильной высоте для агента. Правильная высота — это «зона Златовласки» между двумя типичными провалами. На одном полюсе инженеры зашивают в промпты сложную, хрупкую логику, чтобы вызвать точное поведение агента. Такой подход рождает хрупкость и со временем усложняет сопровождение. На другом полюсе инженеры дают расплывчатые, слишком общие указания, которые не дают модели конкретных сигналов о нужном результате или ложно предполагают наличие общего контекста. Оптимальная высота балансирует: достаточно конкретно, чтобы эффективно направлять поведение, и достаточно гибко, чтобы дать модели сильные эвристики для этого поведения.
На одном конце спектра — хрупкие, зашитые вручную if-else промпты, на другом — промпты, которые слишком обобщены или ложно предполагают общий контекст.
Мы рекомендуем разбивать промпты на отдельные секции (например, <background_information>, <instructions>, ## Tool guidance, ## Output description и т. п.) и использовать приёмы вроде XML-тегов или заголовков Markdown для разграничения этих секций — хотя точное форматирование промптов, вероятно, становится всё менее важным по мере роста способностей моделей.
Как бы вы ни решили структурировать системный промпт, стремитесь к минимальному набору информации, который полностью описывает ожидаемое поведение. (Учтите, что «минимальный» не обязательно значит «короткий»; вам всё равно нужно заранее дать агенту достаточно информации, чтобы он придерживался нужного поведения.) Лучше начать с тестирования минимального промпта на лучшей доступной модели, посмотреть, как он справляется с задачей, а затем добавлять чёткие инструкции и примеры для улучшения результата на основе провалов, найденных в ходе первичного тестирования.
Инструменты позволяют агентам взаимодействовать со средой и подтягивать новый, дополнительный контекст по ходу работы. Поскольку инструменты определяют контракт между агентами и их пространством информации и действий, крайне важно, чтобы они способствовали эффективности — как за счёт токеноэкономичной отдачи информации, так и за счёт поощрения эффективного поведения агента.
В статье «Writing tools for AI agents — with AI agents» мы обсуждали создание инструментов, которые хорошо понятны LLM и минимально пересекаются по функциональности. Как и функции в хорошо спроектированной кодовой базе, инструменты должны быть самодостаточными, устойчивыми к ошибкам и предельно ясными в части предназначения. Входные параметры точно так же должны быть описательными, недвусмысленными и играть на сильных сторонах модели.
Один из самых частых провалов — раздутые наборы инструментов, которые покрывают слишком много функций или создают неоднозначность в выборе инструмента. Если инженер-человек не может однозначно сказать, какой инструмент следует применить в конкретной ситуации, нельзя ждать, что ИИ-агент справится лучше. Как мы обсудим ниже, отбор минимально жизнеспособного набора инструментов также ведёт к более надёжному сопровождению и очистке контекста на длинных взаимодействиях.
Приведение примеров, также известное как few-shot-промптинг, — хорошо известная лучшая практика, которую мы по-прежнему настоятельно советуем. Однако команды часто набивают в промпт длинный список пограничных случаев, пытаясь прописать каждое возможное правило, которому LLM должна следовать в конкретной задаче. Мы этого не рекомендуем. Вместо этого советуем отобрать набор разнообразных, канонических примеров, которые эффективно передают ожидаемое поведение агента. Для LLM примеры — это «картинки», стоящие тысячи слов.
Наш общий совет по всем составляющим контекста (системные промпты, инструменты, примеры, история сообщений и т. д.) — быть вдумчивыми и держать контекст информативным, но плотным. А теперь перейдём к динамическому извлечению контекста во время выполнения.
Извлечение контекста и агентный поиск
В статье «Building effective AI agents» мы подчёркивали различия между рабочими процессами на основе LLM и агентами. С тех пор мы пришли к простому определению агентов: LLM, автономно использующие инструменты в цикле.
Работая с нашими клиентами, мы видим, что отрасль сходится на этой простой парадигме. По мере роста способностей базовых моделей растёт и уровень автономии агентов: более умные модели позволяют агентам самостоятельно ориентироваться в тонких проблемных пространствах и восстанавливаться после ошибок.
Сейчас мы наблюдаем сдвиг в том, как инженеры думают о проектировании контекста для агентов. Сегодня многие ИИ-приложения используют ту или иную форму извлечения на основе эмбеддингов до инференса, чтобы вытащить важный контекст, над которым агенту предстоит рассуждать. По мере перехода к более агентным подходам мы всё чаще видим, как команды дополняют эти системы извлечения стратегиями контекста «точно в срок» (just in time).
Вместо того чтобы обрабатывать все релевантные данные заранее, агенты, построенные по принципу «точно в срок», хранят лёгкие идентификаторы (пути к файлам, сохранённые запросы, веб-ссылки и т. п.) и используют эти ссылки, чтобы динамически загружать данные в контекст во время выполнения с помощью инструментов. Агентное решение Anthropic для кодинга — Claude Code — использует этот подход для сложного анализа данных на больших базах. Модель может писать точечные запросы, сохранять результаты и применять Bash-команды вроде head и tail для анализа больших объёмов данных, ни разу не загружая полные объекты данных в контекст. Этот подход отражает человеческое мышление: мы, как правило, не запоминаем целые массивы информации, а вводим внешние системы организации и индексации — файловые системы, почтовые ящики, закладки — чтобы извлекать нужную информацию по запросу.
Помимо экономии на хранении, метаданные этих ссылок дают механизм эффективного уточнения поведения — как явно заданный, так и интуитивный. Для агента, работающего в файловой системе, наличие файла test_utils.py в папке tests подразумевает иное назначение, чем файл с тем же именем в src/core_logic/. Иерархии папок, соглашения об именовании и временные метки — всё это важные сигналы, помогающие и людям, и агентам понять, как и когда использовать информацию.
Позволяя агентам самостоятельно перемещаться и извлекать данные, мы также включаем постепенное раскрытие (progressive disclosure) — то есть даём агентам возможность инкрементально находить релевантный контекст через исследование. Каждое взаимодействие даёт контекст, который информирует следующее решение: размеры файлов намекают на сложность; соглашения об именовании — на назначение; временные метки могут служить прокси для релевантности. Агенты собирают понимание слой за слоем, удерживая в рабочей памяти лишь необходимое и опираясь на стратегии ведения заметок для дополнительной устойчивости. Это самоуправляемое контекстное окно держит агента сфокусированным на релевантных подмножествах, а не тонущим в исчерпывающей, но потенциально нерелевантной информации.
Разумеется, есть компромисс: исследование во время выполнения медленнее, чем извлечение заранее подготовленных данных. Более того, требуется продуманная и осмысленная инженерия, чтобы у LLM были правильные инструменты и эвристики для эффективной навигации по её информационному ландшафту. Без должного руководства агент может впустую тратить контекст, неправильно применяя инструменты, заходя в тупики или не находя ключевую информацию.
В некоторых условиях самые эффективные агенты могут применять гибридную стратегию: часть данных извлекать заранее ради скорости, а дальнейшее автономное исследование вести по своему усмотрению. Граница «правильного» уровня автономии зависит от задачи. Claude Code — агент, использующий такую гибридную модель: файлы CLAUDE.md наивно подгружаются в контекст заранее, тогда как примитивы вроде glob и grep позволяют ему перемещаться по среде и извлекать файлы точно в срок, эффективно обходя проблемы устаревшего индексирования и сложных синтаксических деревьев.
Гибридная стратегия может лучше подходить для контекстов с менее динамичным содержимым — например, юридической или финансовой работы. По мере роста способностей моделей проектирование агентов будет двигаться к тому, чтобы позволять умным моделям действовать умно, со всё меньшей долей ручного отбора со стороны человека. Учитывая стремительный темп прогресса в этой области, совет «делай простейшее из того, что работает», вероятно, останется нашим лучшим для команд, строящих агентов поверх Claude.
Контекст-инжиниринг для задач с длинным горизонтом
Задачи с длинным горизонтом требуют, чтобы агент сохранял связность, контекст и целенаправленное поведение на протяжении последовательностей действий, где число токенов превышает контекстное окно LLM. Для задач, которые растягиваются от десятков минут до нескольких часов непрерывной работы — например, крупных миграций кодовых баз или объёмных исследовательских проектов, — агентам нужны специальные приёмы, чтобы обойти ограничение размера контекстного окна.
Ждать бо́льших контекстных окон может казаться очевидной тактикой. Но, вероятно, в обозримом будущем контекстные окна любого размера будут подвержены загрязнению контекста и проблемам с релевантностью информации — по крайней мере там, где нужна максимальная производительность агента. Чтобы агенты могли эффективно работать на протяжённых горизонтах, мы разработали несколько приёмов, напрямую адресующих эти ограничения: компактификацию, структурированное ведение заметок и мультиагентные архитектуры.
Компактификация
Компактификация (compaction) — это практика, при которой диалог, приближающийся к пределу контекстного окна, суммируется, а его содержимое переносится в новое контекстное окно в виде резюме. Компактификация обычно служит первым рычагом контекст-инжиниринга для повышения долгосрочной связности. По сути она с высокой точностью дистиллирует содержимое контекстного окна, позволяя агенту продолжать работу с минимальной потерей производительности.
В Claude Code, например, мы реализуем это, передавая историю сообщений модели, чтобы та суммировала и сжала наиболее критичные детали. Модель сохраняет архитектурные решения, нерешённые баги и детали реализации, отбрасывая избыточные результаты инструментов или сообщения. Затем агент может продолжить с этим сжатым контекстом плюс пятью последними файлами, к которым обращались. Пользователи получают непрерывность, не беспокоясь об ограничениях контекстного окна.
Искусство компактификации — в выборе того, что оставить, а что отбросить, поскольку слишком агрессивная компактификация может привести к потере тонкого, но критичного контекста, важность которого проявляется лишь позже. Инженерам, реализующим системы компактификации, мы советуем тщательно настраивать промпт на сложных трассах работы агента. Начните с максимизации полноты (recall), чтобы промпт компактификации улавливал каждую релевантную деталь трассы, а затем итеративно улучшайте точность (precision), убирая лишнее.
Пример низковисящего лишнего содержимого — очистка вызовов инструментов и их результатов: раз инструмент уже был вызван глубоко в истории сообщений, зачем агенту снова видеть сырой результат? Одна из самых безопасных и лёгких форм компактификации — очистка результатов инструментов, недавно выпущенная как функция на Claude Developer Platform.
Структурированное ведение заметок
Структурированное ведение заметок, или агентная память, — это приём, при котором агент регулярно пишет заметки, сохраняемые в память за пределами контекстного окна. Позже эти заметки подтягиваются обратно в контекст.
Такая стратегия даёт устойчивую память при минимальных накладных расходах. Будь то Claude Code, создающий список дел, или ваш собственный агент, ведущий файл NOTES.md, — этот простой паттерн позволяет агенту отслеживать прогресс в сложных задачах, сохраняя критичный контекст и зависимости, которые иначе потерялись бы за десятками вызовов инструментов.
Claude, играющий в Pokémon, демонстрирует, как память преображает возможности агента вне области кодинга. Агент ведёт точный подсчёт на протяжении тысяч игровых шагов, отслеживая цели вроде «последние 1234 шага я тренирую покемонов на Маршруте 1, Пикачу поднялся на 8 уровней из целевых 10». Без каких-либо подсказок о структуре памяти он строит карты исследованных регионов, помнит, какие ключевые достижения открыл, и ведёт стратегические заметки о боевых тактиках, помогающие ему понять, какие атаки лучше работают против разных противников.
После сбросов контекста агент читает собственные заметки и продолжает многочасовые последовательности тренировок или исследования подземелий. Эта связность через шаги суммирования делает возможными стратегии с длинным горизонтом, которые были бы недостижимы, держи агент всю информацию только в контекстном окне LLM.
В рамках запуска Sonnet 4.5 мы выпустили в публичной бете на Claude Developer Platform инструмент памяти (memory tool), который упрощает хранение и обращение к информации за пределами контекстного окна через файловую систему. Это позволяет агентам со временем накапливать базы знаний, сохранять состояние проекта между сессиями и обращаться к прежней работе, не удерживая всё в контексте.
Архитектуры суб-агентов
Архитектуры суб-агентов дают ещё один способ обойти ограничения контекста. Вместо того чтобы один агент пытался удерживать состояние всего проекта, специализированные суб-агенты могут решать сфокусированные задачи с чистыми контекстными окнами. Главный агент координирует работу по высокоуровневому плану, а суб-агенты ведут глубокую техническую работу или используют инструменты для поиска нужной информации. Каждый суб-агент может исследовать обширно, тратя десятки тысяч токенов и больше, но возвращает лишь сжатое, дистиллированное резюме своей работы (часто 1000–2000 токенов).
Такой подход достигает чёткого разделения ответственности: детальный поисковый контекст остаётся изолированным внутри суб-агентов, тогда как ведущий агент сосредоточен на синтезе и анализе результатов. Этот паттерн, описанный в статье «How we built our multi-agent research system», показал существенное улучшение по сравнению с одноагентными системами на сложных исследовательских задачах.
Выбор между этими подходами зависит от характеристик задачи. Например:
- Компактификация сохраняет ход диалога для задач, требующих активного обмена репликами;
- Ведение заметок хорошо подходит для итеративной разработки с чёткими вехами;
- Мультиагентные архитектуры справляются со сложными исследованиями и анализом, где параллельное исследование окупается.
Даже по мере того как модели продолжают улучшаться, задача поддержания связности на протяжённых взаимодействиях останется центральной для создания более эффективных агентов.
Заключение
Контекст-инжиниринг представляет собой фундаментальный сдвиг в том, как мы строим на LLM. По мере роста способностей моделей задача уже не в том, чтобы составить идеальный промпт, — а в том, чтобы вдумчиво отбирать, какая информация попадёт в ограниченный бюджет внимания модели на каждом шаге. Реализуете ли вы компактификацию для задач с длинным горизонтом, проектируете токеноэкономичные инструменты или даёте агентам исследовать среду точно в срок — руководящий принцип остаётся тем же: найти наименьший набор высокосигнальных токенов, максимизирующий вероятность нужного вам исхода.
Описанные приёмы будут развиваться вместе с моделями. Мы уже видим, что более умные модели требуют менее предписывающей инженерии, позволяя агентам действовать с большей автономией. Но даже по мере масштабирования способностей отношение к контексту как к ценному, конечному ресурсу останется центральным для создания надёжных, эффективных агентов.
Перевод статьи «Effective Context Engineering for AI Agents» из инженерного блога Anthropic (опубликована 29 сентября 2025 года). Авторы оригинала: команда Applied AI компании Anthropic — Prithvi Rajasekaran, Ethan Dixon, Carly Ryan и Jeremy Hadfield при участии Rafi Ayub, Hannah Moran, Cal Rueb и Connor Jennings.
