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

Материал опирается на официальные источники и редакционный анализ; описанные наблюдения не являются заявлением о личном тестировании.

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

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

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

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

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

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

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

Один владелец для каждого правила

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

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

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

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

Что изменилось в новых поколениях моделей

Anthropic сообщила, что убрала более 80% системного промпта Claude Code для моделей вроде Claude Opus 5 и Claude Fable 5 без измеримой потери на внутренних оценках по коду. Это подтверждает возможность существенного сокращения накопленных инструкций, но не обещает тот же результат для другого агента.

Актуальное руководство OpenAI по GPT‑6 Astra рекомендует проверять скиллы и другие файлы, доступные модели, включая AGENTS.md. GPT‑6 Astra лучше следует длинным инструкциям, но чувствительнее к неясным и конфликтующим указаниям. OpenAI также советует явно задавать требуемую автономию, стиль ответа, правила использования субагентов и объём проверки.

Критерии вместо лишних абсолютов

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

Anthropic заменила его критерием соответствия окружению:

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

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

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

Интерфейсы инструментов вместо промптов-костылей

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

# Слабый интерфейс + пояснение в общем промпте
tool: update_task(payload: string)
системный промпт: «Передавай JSON со status; допустимы pending,
in_progress и completed»

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

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

Прогрессивное раскрытие инструкций и инструментов

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

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

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

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

Claude Code загружает полное содержимое скилла при его вызове или автоматическом выборе по релевантности, а в начале сессии обычно показывает модели его название и описание. Здесь MCP означает механизм подключения внешних сервисов и инструментов к агенту. Полные схемы MCP-инструментов могут оставаться отложенными до обращения к конкретному инструменту. Такое разделение снижает постоянную стоимость контекста, хотя описания доступных скиллов и имена инструментов всё равно занимают некоторое место.

Память как отдельный слой

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

Это продуктовая возможность Claude Code, а не универсальное свойство любого агента. В собственном контуре заранее определите, какая память существует, кто может её изменять, как долго она хранится и когда попадает в контекст.

Референсы вместо пересказов

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

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

Границы автономии и остановки

Современные модели лучше справляются с длинными многошаговыми задачами, но ожидаемую инициативу лучше задавать явно. Актуальная документация OpenAI отмечает, что GPT‑6 Astra может чаще задавать уточняющие вопросы, если дополнительный ответ способен изменить результат. Для автономного агента полезно описать, какие пробелы он закрывает разумным предположением, а где обязан остановиться.

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

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

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

Добавьте условие остановки:

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

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

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

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

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

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

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

# Основные команды
Проверка: make verify
Миграции: make migrate

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

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

Процедура безопасного сокращения контекста

Меняйте по одной группе инструкций, чтобы связать результат с конкретной правкой.

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

Что проверять первым

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

Что сохранять

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

Как измерить результат

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

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

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

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

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

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

Источники

• The new rules of context engineering for Claude 5 generation models — официальный блог Anthropic, 24 июля 2026 года
• Extend Claude Code — официальная документация о CLAUDE.md, скиллах, инструментах, субагентах и хуках
• Model guidance — официальные рекомендации OpenAI для GPT‑6 Astra и предыдущих моделей
• Models — актуальный каталог моделей OpenAI

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

Следующий шаг

Чтобы подробнее разобрать изменения именно в Claude 5, прочитайте Новые правила контекст-инжиниринга для моделей Claude 5.

Связанные материалы

• Статья: Как мы мигрировали AGENTS.md под GPT‑5.6 Sol и не потеряли контроль
• Блог: Anthropic выпустил официальное руководство по промптингу Fable
• База знаний: Рекомендации по промптингу для GPT‑5.6 Sol

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

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