Что такое context engineering
Термин распространился летом 2025 года и быстро вытеснил «prompt engineering» в разговорах об агентах. Промпт — одна формулировка запроса. Контекст — всё, что лежит в окне модели на каждом шаге работы: системные инструкции, описания инструментов, прочитанные файлы, вывод команд, предыдущие шаги.
У агента контекст постоянно меняется. Он прочитал файл — файл в контексте. Запустил тесты — в контексте их вывод на сотни строк. Через час работы окно заполнено, и решение о том, что туда попадает, влияет на результат сильнее, чем формулировка исходной задачи.
В статье Anthropic главный принцип сформулирован так: найти минимальный набор информации, который даёт нужный результат. Каждый лишний фрагмент мешает модели найти нужный.
Почему больше контекста не значит лучше
Окна моделей выросли до сотен тысяч и миллиона токенов. Можно было бы загрузить в агента весь репозиторий и всю документацию. На практике это ухудшает работу.
Явление называют context rot: чем больше токенов в окне, тем хуже модель находит и использует нужный фрагмент. Исследования на задачах «иголка в стоге сена» показывают, что точность падает с ростом контекста, даже когда окно формально не заполнено. У модели ограниченный бюджет внимания, и каждый лишний токен его расходует.
Для разработки из этого следуют практические выводы:
- файл инструкций на тысячу строк хуже короткого файла и ссылок на детали;
- полный вывод тестов на 500 строк хуже краткой сводки с упавшими тестами;
- длинная сессия, в которой агент решал три задачи подряд, хуже трёх коротких сессий.
Из чего складывается контекст агента в разработке
| Слой | Когда попадает в контекст | Пример |
|---|---|---|
| Правила проекта | Всегда, в начале сессии | AGENTS.md, CLAUDE.md, правила Cursor |
| Задача и спека | В начале задачи | Тикет, specs/report-export.md |
| Код | По мере работы, через поиск | Файлы, которые агент нашёл grep-ом и открыл |
| База знаний | По ссылке из правил или спеки | docs/architecture.md, ADR |
| Результаты инструментов | После каждого вызова | Вывод тестов, линтера, git diff |
| Внешние системы | Через MCP или CLI | Jira, Confluence, логи, база данных |
Задача context engineering — решить для каждого слоя, что загружать сразу, что по запросу и что не загружать вовсе.
Как управлять контекстом
Короткие правила, детали по ссылке
Файл правил загружается в каждую сессию, поэтому в нём только то, что нужно почти всегда: команды, структура, запреты. Детали архитектуры лежат в базе знаний, а в правилах — ссылка на них. Агент откроет документ, когда задача его коснётся. Как писать такие файлы — в статьях про AGENTS.md и CLAUDE.md.
Загрузка по требованию
Агенты для разработки не грузят весь репозиторий заранее. Claude Code, например, читает CLAUDE.md в начале сессии, а остальные файлы находит поиском по мере работы. Чтобы поиск работал, код должен легко находиться: понятные имена файлов и модулей, одна сущность — одно место, без копий логики в пяти сервисах.
Правила по путям
Правила для фронтенда не нужны агенту, который правит миграции базы. Вложенные AGENTS.md в каталогах, правила Cursor с масками файлов и правила Claude Code с полем paths подгружаются только при работе с нужной частью кода.
Сжатие шумного вывода
Тесты, линтеры и сборка выдают много текста. Скрипты-обёртки, которые печатают только упавшие тесты и первые строки ошибки, экономят контекст на каждом цикле «запустил — исправил». То же касается логов: агенту нужна выборка по задаче. Файл на сто мегабайт займёт весь контекст.
Короткие сессии и передача через файлы
Большую задачу делят на шаги. Результат каждого шага записывают в файл: план, список сделанного, открытые вопросы. Следующую сессию начинают с чистым контекстом и этим файлом. Так работают и спеки: план и задачи лежат в репозитории, и следующая сессия читает их оттуда.
Если сессия всё же длинная, агенты применяют сжатие: старую часть диалога заменяют краткой сводкой. Самый безопасный вариант сжатия — убрать из контекста старые результаты инструментов, которые уже отработаны.
Субагенты для поиска
Исследование кода можно отдать субагенту с собственным контекстом. Он прочитает двадцать файлов и вернёт основному агенту выжимку на страницу. Основной агент тратит контекст на решение. Подробнее о плюсах и рисках — в статье про мультиагентную разработку.
Корпоративный контекст: Jira, Confluence и головы людей
Главный пробел в контексте агента обычно лежит за пределами репозитория. Требования живут в Jira, знания в Confluence и головах разработчиков, архитектурные правила в истории code review. Агент до этого не дотягивается, и даже человек тратит часы, чтобы собрать картину.
Два способа закрыть пробел:
- Подключить источники. MCP-серверы и CLI дают агенту доступ к Jira, Confluence, Git-хостингу и логам. Подходит для живых данных: статус тикета, комментарии, инциденты.
- Перенести знания в репозиторий. Архитектурная карта, контракты и журнал решений в markdown рядом с кодом. Подходит для знаний, которые меняются вместе с кодом и должны проходить ревью.
DORA в модели AI-возможностей 2025 года выделяет доступ AI к внутренним данным как одно из семи условий, при которых AI даёт эффект. Без него инструменты дают общие ответы, которые не учитывают устройство вашей системы.
Как понять, что агенту не хватает контекста
- Агент пишет код, который уже есть в проекте в другом месте.
- Агент нарушает архитектурные договорённости, которые в команде «все знают».
- Агент задаёт вопросы, ответы на которые есть в документации.
- Агент ходит по кругу: исправляет одно, ломает другое.
- Ревьюеры пишут одни и те же замечания к разным PR от агентов.
Каждый такой случай — повод изменить правила, базу знаний или доступы. Этот цикл описан в статье про harness engineering.
База знаний для агентов в программе Праксора
На диагностике наш агент сканирует репозитории, а архитектор разбирает, где у вас живут требования и знания. В первой версии harness собираем архитектурную карту, контракты и журнал решений в git рядом с кодом. После пилота база знаний остаётся у вас и обновляется командой. Слои Harness
Вопросы
Чем context engineering отличается от prompt engineering?
Prompt engineering работает с формулировкой одного запроса. Context engineering управляет всем, что агент видит на каждом шаге: правилами, файлами, документацией, выводом инструментов и историей.
Нужен ли RAG, чтобы агент знал кодовую базу?
Для кода обычно хватает поиска по файлам, которым агенты пользуются сами. RAG и векторный поиск полезны для больших массивов документации вне репозитория.
Почему агент хуже работает в длинной сессии?
Контекст заполняется прочитанными файлами и выводом команд, и модель хуже находит в нём нужное. Большие задачи лучше делить на короткие сессии с передачей результата через файлы.
Сколько правил можно дать агенту?
Столько, сколько нужно почти в каждой задаче. Остальное выносят в базу знаний и правила по путям, которые загружаются только при работе с нужной частью кода.