Главная задача context engineering - дать модели ровно те данные, которые нужны для решения, и убрать то, что мешает. Если контекста мало, модель начинает угадывать. Если контекста слишком много, она теряет фокус, тратит токены, цепляется за устаревшие факты или смешивает разные задачи.
В ИИ-агентах контекст нужно проектировать как рабочую среду. Один узел получает инструкции для классификации, другой - фрагменты базы знаний, третий - результат инструмента и правила approval. Так агент становится предсказуемее, а ошибки легче отлаживать.
Хороший контекст обычно состоит из нескольких слоев: роль и цель, ограничения, актуальные данные, важная память, доступные tools, формат ответа, критерии качества и fallback. Эти слои лучше собирать программно, а не складывать все в один огромный промпт.
Context engineering особенно важен для RAG, long-term memory, multi-agent систем и продуктов с юридическими, финансовыми или клиентскими рисками. Там нужно не только получить красивый ответ, но и понимать, какие источники использовались, какие правила сработали и почему агент выбрал действие.
Примеры
- Перед ответом поддержки агент получает только актуальный тариф клиента, последние обращения, фрагменты базы знаний и правило, когда нужен handoff.
- Для SQL-агента в контекст добавляют схему таблиц, column dictionary, ограничения на чтение данных и формат безопасного запроса.
- В RAG-сценарии модель видит не весь документ, а релевантные chunks с citations и инструкцию не отвечать без источников.
- Для code review агент получает diff, описание задачи, результаты CI, правила проекта и список файлов, которые нельзя менять.
- В multi-agent workflow supervisor передает следующему агенту короткий state: цель, что уже сделано, ошибки инструментов и открытые вопросы.
- После длинного диалога context compression оставляет в prompt только решения, запреты, факты и ссылки на исходные сообщения.
Где используется
- проектирование системного промпта
- сборка контекста для ИИ-агента
- RAG по базе знаний и документам
- долговременная память и summary memory
- tool calling и передача результатов инструментов
- структурированный вывод через JSON schema
- guardrails и ограничения действий
- multi-agent workflow и handoff
- снижение расхода токенов
- отладка качества через traces и evals
Связанные термины
Частые вопросы
Чем context engineering отличается от prompt engineering?
Prompt engineering работает с формулировкой инструкции. Context engineering проектирует весь набор данных вокруг модели: prompt, память, RAG, tools, state, ограничения и формат ответа.
Почему нельзя просто дать модели больше контекста?
Большой контекст дороже, медленнее и не всегда лучше. Модель может потерять важные детали, использовать устаревшие факты или смешать разные части задачи.
Что входит в хороший контекст агента?
Цель, роль, ограничения, актуальные данные, нужная память, доступные инструменты, результаты проверок, источники, формат ответа и fallback при нехватке данных.
Как context engineering связан с RAG?
RAG отвечает за поиск релевантных фрагментов, а context engineering решает, какие из них положить в prompt, в каком виде, с какими citations и правилами ответа.
Как понять, что контекст собран плохо?
Модель задает лишние вопросы, придумывает факты, игнорирует важные ограничения, отвечает не в том формате или использует старую информацию вместо актуальной.
Как тестировать context engineering?
Нужны evals на типовых сценариях, traces с полным собранным контекстом, проверки источников, тесты на нехватку данных и сравнение разных вариантов сборки prompt.
