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

Anthropic даёт чёткое определение: контекст — это набор токенов, передаваемый модели при инференсе, а контекстная инженерия — набор стратегий для «курирования и поддержания оптимального набора токенов». Оптимальным считается минимальный набор высокозначимых токенов. Это принципиально отличает её от промпт-инжиниринга: последний отвечает только за инструкцию (что делать, в каком формате), тогда как контекстная инженерия охватывает всё — системные инструкции, историю сообщений, документы, описания инструментов, результаты их вызовов и данные из памяти.

КомпонентНазначениеРоль в контекстной инженерии
RAGДобавление релевантных фрагментов из базы знаний в контекстИсточник знаний, которые включаются в контекст
MCPСтандартизация доступа к внешним данным и инструментам (tools, resources, prompts)Канал доступа, через который контекстная инженерия получает данные
Контекстная инженерияСборка и поддержание оптимального набора токенов из всех доступных источниковУправление целостностью и релевантностью контекста

Важно различать смежные понятия. RAG (Retrieval-Augmented Generation) — это способ добавления внешних знаний из базы: приложение находит релевантные фрагменты и передаёт их в контекст. MCP (Model Context Protocol) — это протокол, стандартизирующий подключение модели к внешним источникам и инструментам (tools, resources, prompts). Контекстная инженерия находится над ними: она решает, как именно из этих компонентов собрать контекст для следующего вызова. Другими словами, RAG приносит знания, MCP открывает каналы, а контекстная инженерия управляет сборкой.

Из чего же состоит контекст типичного LLM-агента? Можно выделить несколько слоёв:

— Пользовательский запрос: текущая задача, с которой пришёл пользователь. — Системный промпт: базовые правила роли, формата, ограничений. — Tools (тулы): описания доступных инструментов с названиями, параметрами и docstring. — Few-shot примеры: несколько готовых пар «запрос — ответ» для демонстрации поведения. — История диалога: предыдущие сообщения и действия. — Результаты вызовов инструментов и RAG-документы: данные, полученные от внешних источников.

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

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