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

Что такое контекст-инжиниринг

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

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

Целевая архитектура

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

flowchart LR
    A["Системный промпт"] --> E["Рабочий контекст запроса"]
    B["Файл проекта: CLAUDE.md / AGENTS.md"] --> E
    C["Скиллы и тематические инструкции"] -.->|подгружаются по необходимости| E
    D["Референсы: код, тесты, макеты, рубрики"] -.->|подключаются под задачу| E
    F["Память агента"] --> E
    E --> G["Ответ и действия"]

Ориентиры по объёму, от которых можно отталкиваться: системный промпт собственного агента — до 150 строк, файл проекта — 40–80 строк, один файл скилла — до 200 строк, дальше делите на несколько. Это не нормативы, а порог, за которым стоит спросить себя, что из написанного действительно меняет поведение модели.

Кто владеет правилом

Когда слои противоречат друг другу, модель тратит рассуждение на разрешение конфликта вместо задачи. Anthropic приводит случай из собственных транскриптов: «оставляй документацию там, где уместно» в одном месте против «НЕ ДОБАВЛЯЙ комментарии» в другом, и модель вынуждена выбирать сама.

Распределение владельцев снимает большую часть таких конфликтов.

Если правило появилось в двух слоях, удаляйте его из более общего, а не уточняйте в обоих.

Чеклист быстрой проверки

Пройдите по своему контексту за пять минут.

Что изменилось за поколение моделей

Anthropic убрала больше 80% системного промпта Claude Code для моделей уровня Claude Opus 5 и Claude Fable 5 без измеримой потери на внутренних оценках по коду. OpenAI в рекомендациях по GPT-5.6 приводит близкий результат: облегчённые системные промпты дали примерно 10–15% к оценкам кодинг-агента при сокращении числа токенов на 41–66% и стоимости на 33–67%.

Правила против суждения

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

Замена — правило, которое описывает критерий, а не действие:

# Было
По умолчанию не пиши комментарии. Никогда не пиши многоабзацные
docstring или многострочные блоки комментариев, максимум одна
короткая строка.

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

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

Интерфейсы вместо примеров

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

Ниже синтетический пример, собранный по мотивам Todo-инструмента Claude Code: статус задан перечислением, а правило «одна задача в работе» живёт в описании инструмента.

# Слабый интерфейс + костыль в промпте
tool: update_task(payload: string)
системный промпт: «в payload передавай JSON вида
{"status": "in_progress"}, статусы бывают pending,
in_progress, completed»

# Выразительный интерфейс
tool: update_task(task_id: string, status: "pending" |
  "in_progress" | "completed")
описание: «Обновляет статус задачи. В статусе in_progress
держите не более одной задачи одновременно.»

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

Прогрессивное раскрытие

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

AGENTS.md              # 40–80 строк: назначение, подводные камни, карта файлов
docs/
  verification.md      # как проверять работу перед завершением
  release.md           # процедура релиза
  data-model.md        # неочевидные связи в схеме данных
  incident.md          # что делать при падении прод-окружения

В ядре остаётся маршрутизация:

## Карта инструкций
Перед проверкой изменений — docs/verification.md
Перед релизом — docs/release.md
При работе со схемой данных — docs/data-model.md

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

Референсы вместо описаний

Модель лучше понимает артефакт, чем его пересказ. HTML-макет даёт более точный результат, чем текстовое описание вёрстки или скриншот. Набор тестов работает как спецификация поведения. Функция из соседнего репозитория работает как образец для порта.

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

Слои автономии и остановки

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

Для запросов ответить, объяснить, проверить, диагностировать или
спланировать: изучите нужные материалы и сообщите результат.
Не вносите изменения, если об этом не просят.

Для запросов изменить, построить или починить: внесите локальные
изменения в рамках задачи и запустите неразрушающую валидацию,
не спрашивая заранее.

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

К политике автономии добавьте условие остановки, иначе агент будет наращивать циклы инструментов без пользы:

Решите запрос за наименьшее полезное число циклов инструментов,
но не позволяйте минимизации циклов перевешивать корректность
и полноту данных.

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

Эталонный шаблон контекста

Собранный пример, от которого можно отталкиваться.

Каркас системного промпта

Role: функция агента и продукт, в котором он работает
Personality: тон и стиль взаимодействия
Goal: видимый пользователю результат
Success criteria: что должно быть верно до финального ответа
Constraints: безопасность, данные, права доступа, побочные эффекты
Tools: какие инструменты использовать, когда и что не использовать
Output: разделы, длина, формат
Stop rules: когда повторить, откатиться, спросить или остановиться

Каркас файла проекта

# Назначение
Сервис выставления счетов. Монорепозиторий, три пакета.

# Подводные камни
- Все типы лежат в src/types.ts и больше нигде.
- Миграции применяются только через make migrate, напрямую psql ломает журнал.
- Тесты в packages/api требуют поднятого docker-compose.

# Карта инструкций
Проверка изменений — docs/verification.md
Релиз — docs/release.md

Процедура сокращения контекста

Сокращайте по шагам, иначе вы не поймёте, что именно дало эффект.

1. Зафиксируйте базовую линию: текущий промпт, текущий набор инструментов, текущий уровень усилий рассуждения.

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

2. Уберите одну группу: повторы, примеры, стилевые инструкции или неиспользуемые инструменты.
3. Прогоните тот же набор задач и сравните с базовой линией.
4. Если качество не просело, зафиксируйте изменение и переходите к следующей группе.
5. Если просело, верните минимальную точечную инструкцию, которая закрывает конкретную регрессию, а не весь удалённый блок.
6. Повторяйте, пока удаление перестанет проходить без потерь.

Что убирать в первую очередь

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

Что сохранять всегда

• Видимый пользователю результат и критерии успеха
• Условия остановки
• Ограничения по безопасности, данным и правам доступа
• Правила маршрутизации инструментов, когда маршрут зависит от контекста
• Требуемую форму вывода и правила валидации

Как проверить результат

Минимальный рабочий сценарий проверки после каждой правки контекста:

1. Соберите 10–20 реальных задач, покрывающих типичные и пограничные случаи.
2. Прогоните их на текущем контексте и запишите четыре величины: доля пройденных задач, число токенов, число вызовов инструментов, число запросов на подтверждение.
3. Внесите одно изменение и повторите прогон.
4. Признаком успеха считайте сохранение или рост доли пройденных задач при снижении остальных трёх величин.

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

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

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

Антипаттерны

• ❌ Файл-свалка. Один документ на 800 строк со всеми практиками команды
• ❌ Дублирование по слоям. Одно правило в системном промпте, в файле проекта и в описании инструмента
• ❌ Абсолюты по привычке. «Никогда» и «всегда» на стилевых предпочтениях
• ❌ Примеры вместо интерфейса. Три сценария вызова в промпте при слабой сигнатуре инструмента
• ❌ Описание вместо артефакта. Пересказ макета словами при наличии готового HTML
• ❌ Все инструменты открыты. Полный каталог в контексте на каждой задаче
• ❌ Правка вслепую. Переписывание промпта целиком без набора задач-оценок

Источники

• The new rules of context engineering for Claude 5 generation models — блог Claude, Anthropic
• Prompt guidance for GPT-5.6 — документация OpenAI для разработчиков

Проверено 28 июля 2026 года. Рекомендации привязаны к поколению моделей Claude 5 и GPT-5.6, при смене поколения их стоит перепроверить.

По теме

• Статья: Новые правила контекст-инжиниринга для моделей Claude 5
• Блог: Anthropic выпустил официальное руководство по промптингу Fable
• База знаний: Рекомендации по промптингу для GPT-5.6 Sol

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov