Инженерия контекста: как удержать ИИ-агента в рамках задачи

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

Что такое инженерия контекста?

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

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

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

В инженерной статье от 29 сентября 2025 года Anthropic описывает эту работу как «отбор и поддержание оптимального набора токенов (информации) во время инференса LLM». Компания проводит границу между написанием инструкций и управлением более широким набором информации, поступающей к модели в ходе работы. Статья Anthropic об инженерии контекста.

В публикации от 2 июля 2025 года LangChain говорит о «наполнении контекстного окна именно той информацией, которая нужна на каждом шаге работы агента». Компания выделяет запись, отбор, сжатие и изоляцию: сохранить полезное состояние, найти нужные материалы, сократить оставшееся и отделить независимые исследования друг от друга. Статья LangChain об инженерии контекста.

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

Документация проверена 13 октября 2026 года: описанное ниже поведение инструментов сверено с актуальной документацией Anthropic и OpenAI. Разобранный пример иллюстрирует устройство системы, а не результаты испытаний в реальной эксплуатации.

Чем инженерия контекста отличается от промпт-инжиниринга?

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

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

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

Главный навык — определять границы контекста

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

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

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

Инженерия контекста для ИИ-агентов: основные приёмы

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

Сжимайте историю вокруг решений, а не только тем

В Claude Code, агенте Anthropic для работы с кодом, команда /context показывает использование контекста, а /compact сокращает диалог. Автоматическое управление сначала удаляет старые результаты инструментов, а затем при необходимости составляет сводку диалога. Документация прямо предупреждает: подробные инструкции из ранней части беседы могут потеряться. Управление контекстом в Claude Code.

Задайте цель сжатия. При разборе повторной отправки приветственных писем используйте /compact Preserve the current goal, change boundaries, relevant file paths, observed evidence, failed hypotheses, and the next unresolved question. Команда содержит указания для конкретной задачи, но не гарантирует сохранения каждой детали.

Прежде чем продолжать, убедитесь, что сводка по-прежнему различает наблюдения, предположения и то, что ещё не проверено. «Исследованы повторные отправки писем» — лишь обозначение темы. «Известно, что сервис принял запрос; путь обработки локального подтверждения ещё нужно проверить» — состояние, с которым можно работать дальше.

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

Загружайте данные тогда, когда они нужны

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

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

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

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

Сокращайте результаты инструментов до попадания в диалог

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

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

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

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

Поручайте отдельные исследования субагентам без наследования истории

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

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

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

Исполнители делают собственные запросы и тоже расходуют ресурсы. Они могут повторять уже проделанную работу, если в задании не указано решение, которое родительский агент успел принять. Используйте их, когда исследование можно отделить, а промежуточные результаты не нужно сохранять в основном контексте. Тесно связанные рассуждения ведите вместе. Подробности настройки — в статье о субагентах Claude Code.

Отведите файлам памяти небольшую и постоянную роль

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

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

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

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

Как эти приёмы работают в Claude Agent SDK и Codex

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

Claude Agent SDK: встройте агентный цикл в своё приложение

Claude Agent SDK предоставляет приложениям на Python и TypeScript инструменты, агентный цикл и управление контекстом, на которых построен Claude Code. Он подходит, когда вы встраиваете агента в продукт или автоматизацию, которой управляете сами. Обзор Agent SDK.

Когда окно приближается к пределу, SDK автоматически сжимает старую историю и выдаёт системное событие compact_boundary. Записывайте его в журнал вместе с результатами задач: так можно выявить сбои, возникающие после создания сводки. Субагенты SDK без форка держат промежуточную работу в собственных диалогах и возвращают итоговое сообщение. Агентный цикл SDK, субагенты SDK.

Явно задавайте загрузку инструкций проекта. Текущие настройки query() по умолчанию включают пользовательские и проектные источники. Если вы указываете settingSources в TypeScript или setting_sources в Python, добавьте project, когда нужен проектный CLAUDE.md; пустой массив не даст ему загрузиться. Этим управляют источники настроек, а не выбор предустановки системного промпта claude_code. Загрузка инструкций в SDK.

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

Codex: отделяйте инструкции репозитория от текущего диалога

Codex от OpenAI читает инструкции AGENTS.md до начала работы. Он объединяет глобальные указания с файлами проекта, двигаясь от корня репозитория к рабочему каталогу; более поздние указания имеют приоритет, а AGENTS.override.md получает приоритет в своём каталоге. Инструкции проекта для Codex.

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

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

Пример инженерии контекста: убираем лишнее у одного агента

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

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

1. 1

   Сохраните текущую задачу и постоянные ограничения

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

2. 2

   Замените массивы файлов картой источников

   Сохраните ссылки на signup-handler.ts, welcome-job.ts, тест повторных попыток и нужный файл лога. Эти имена приведены для примера. Читайте обработчик и воркер, когда они отвечают на следующий вопрос, а их зависимости изучайте по необходимости. Карта обеспечивает доступ к данным, но не заменяет их чтение.

3. 3

   Отфильтруйте результат инструмента вокруг сбоя

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

4. 4

   Выделите ограниченный поиск в отдельную задачу

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

5. 5

   Сожмите исследование в сводку, пригодную для продолжения

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

6. 6

   Соберите следующий запрос из оставшегося

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

Итоговая заметка по задаче может выглядеть так:

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

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

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

Шаблон сводки для передачи состояния задачи

Используйте заметку со следующими полями и заполняйте их реальными данными текущего запуска:

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

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

Размер контекста и стоимость: что считать отдельно

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

Два ограничения для инструкций из документации показывают, почему важны единицы измерения. В Codex лимит суммарного объёма документов проекта по умолчанию — 32 KiB, то есть 32 × 1,024 = 32,768 байт. Это лимит в байтах, а не бюджет токенов. Claude Code рекомендует, чтобы каждый CLAUDE.md занимал менее 200 строк; это рекомендация по написанию инструкций, а не жёсткий предел контекстного окна. Ни одно из этих чисел не позволяет предсказать экономию. Лимит инструкций Codex, рекомендации Claude Code по написанию инструкций.

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

Стоимость принятой задачи = общая стоимость рабочего процесса по всем попыткам ÷ количество задач, соответствующих критериям приёмки.

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

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

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

С чего начать управление контекстом LLM

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

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

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

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

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

Какие ожидания от инженерии контекста завышены?

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

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

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

Вопросы разработчиков, чьи агенты теряют нить задачи

Поможет ли инженерия контекста, если агент справляется на демонстрации, но сбоит в реальной работе?

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

Нужны ли для начала векторная база данных или мультиагентный фреймворк?

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

Как понять, что я убрал слишком много?

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

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

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