Эффективный контекст-инжиниринг для AI-агентов

Контекст — это критически важный, но конечный ресурс для AI-агентов. Команда Applied AI в Anthropic опубликовала разбор того, как правильно собирать и поддерживать контекст, который питает агентские системы. Статья заменяет фокус с «как написать промпт» на более широкий вопрос: «какая конфигурация контекста с наибольшей вероятностью приведёт к желаемому поведению модели».

Контекст-инжиниринг vs промпт-инжиниринг

В Anthropic рассматривают контекст-инжиниринг как естественное развитие промпт-инжиниринга.

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

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

Почему контекст-инжиниринг важен для способных агентов

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

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

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

Техники вроде position encoding interpolation позволяют работать с более длинными последовательностями, но с некоторой деградацией в понимании позиций токенов. Эти факторы создают градиент производительности, а не жёсткий обрыв.

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

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

Системные промпты

Системные промпты должны быть предельно ясными и использовать простой прямой язык на правильной высоте (Goldilocks zone) для агента.

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

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

Инструменты

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

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

Примеры

Few-shot prompting остаётся сильной рекомендацией. Но команды часто заталкивают в промпт длинный список крайних случаев, пытаясь сформулировать каждое правило, которому должна следовать LLM. Это не рекомендуется. Лучше курировать набор разнообразных канонических примеров, которые эффективно передают ожидаемое поведение. Для LLM примеры — это «картинки», стоящие тысячи слов.

Общая рекомендация: будьте вдумчивы и держите контекст информативным, но плотным.

Контекстный поиск и agentic search

В статье «Building effective AI agents» команда Anthropic выделила разницу между LLM-воркфлоу и агентами. С тех пор определение упростилось: агенты — это LLM, автономно использующие инструменты в цикле.

Сейчас наблюдается сдвиг в том, как инженеры проектируют контекст для агентов. Многие AI-нативные приложения используют retrieval на основе эмбеддингов для pre-inference подгрузки важного контекста. По мере перехода к более агентским подходам команды всё чаще дополняют эти системы стратегиями «just in time».

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

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

Автономная навигация и поиск также дают progressive disclosure — возможность для агента инкрементально обнаруживать релевантный контекст через исследование. Каждое взаимодействие даёт контекст, который информирует следующее решение: размеры файлов указывают на сложность; соглашения об именовании намекают на назначение; временные метки могут быть прокси релевантности.

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

Гибридная стратегия

В определённых условиях самые эффективные агенты могут применять гибридную стратегию: получать часть данных заранее для скорости и проводить дальнейшее автономное исследование по своему усмотрению. Claude Code — агент, использующий эту гибридную модель: файлы CLAUDE.md наивно загружаются в контекст заранее, а примитивы вроде glob и grep позволяют навигировать по среде и извлекать файлы just-in-time, обходя проблемы устаревших индексов и сложных синтаксических деревьев.

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

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

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

Ждать больших окон контекста может казаться очевидной тактикой, но скорее всего в обозримом будущем окна любого размера будут подвержены context pollution и проблемам релевантности информации. Для эффективной работы агентов на длинных горизонтах Anthropic разработали три техники: compaction, structured note-taking и multi-agent architectures.

Compaction

Compaction — это практика взятия разговора, приближающегося к лимиту окна контекста, суммаризации его содержимого и перезапуска нового окна с этой суммаризацией.

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

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

Один из безопасных лёгких штрихов compaction — очистка результатов инструментов. Когда инструмент был вызван глубоко в истории сообщений, зачем агенту видеть сырой результат снова?

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

Structured note-taking, или agentic memory — это техника, при которой агент регулярно пишет заметки, сохраняемые в памяти вне окна контекста. Эти заметки подтягиваются обратно в окно контекста в более поздние моменты.

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

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

В рамках запуска Sonnet 4.5 был выпущен memory tool в публичной бете на Claude Developer Platform, который упрощает хранение и консультацию информации вне окна контекста через файловую систему.

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

Sub-agent архитектуры дают другой способ обойти ограничения контекста. Вместо одного агента, пытающегося поддерживать состояние через весь проект, специализированные субагенты могут обрабатывать фокусные задачи с чистыми окнами контекста. Главный агент координирует с высокоуровневым планом, пока субагенты выполняют глубокую техническую работу или используют инструменты для поиска релевантной информации. Каждый субагент может исследовать экстенсивно, используя десятки тысяч токенов или больше, но возвращает только сжатое, дистиллированное резюме своей работы (часто 1 000–2 000 токенов).

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

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

• Compaction поддерживает разговорный поток для задач, требующих интенсивного двустороннего общения.
• Note-taking отлично подходит для итеративной разработки с чёткими вехами.
• Multi-agent архитектуры справляются со сложными исследованиями и анализом, где параллельное исследование окупается.

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

Заключение

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

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