Контекст для современных ИИ-агентов: меньше инструкций, лучше результат
Современные ИИ-агенты часто работают лучше, если получают меньше, но более точных инструкций.
Это кажется нелогичным. Старым моделям требовались подробные правила, повторяющиеся предупреждения и примеры почти для каждого действия. Новые модели лучше понимают структуру проекта, намерение пользователя и подходящий способ решения. Избыток инструкций теперь может замедлять работу и создавать противоречия.
Разберём, как упростить контекст для программного агента и при этом не потерять важные ограничения.
Что такое проектирование контекста?
Промпт — это текущая просьба:
Добавь endpoint, который возвращает текущего пользователя.
Контекст — всё остальное, что видит агент: системные инструкции, правила репозитория, навыки, память, исходный код, описания инструментов, тесты и макеты.
Проектирование контекста — организация этой информации так, чтобы агент получил нужные сведения в нужный момент.
Цель не в том, чтобы написать самый большой файл с инструкциями. Нужно дать достаточно информации для правильного решения и не спрятать задачу среди не относящихся к ней правил.


1. Заменяйте жёсткие правила понятной целью
Жёсткие правила защищают от ошибок, но мешают в допустимых нестандартных ситуациях.
Слишком жёстко:
Никогда не добавляй комментарии. Никогда не создавай документацию.
Лучше:
Следуй стилю, именованию и плотности комментариев в соседнем коде.
Создавай документацию, только если она нужна для задачи.
Второй вариант описывает ожидаемый результат и позволяет агенту использовать сам проект как образец.
Строгие правила всё же нужны там, где цена ошибки высока: секреты, production-данные, разрушающие команды, юридические требования и необратимые изменения.
2. Проектируйте понятные инструменты вместо длинных примеров
Примеры полезны, но иногда заставляют агента копировать один сценарий, даже если другой лучше. Хороший интерфейс сам подсказывает способ использования.
Неясный инструмент:
update_task(task)
Более понятный:
update_task(
status: "pending" | "in_progress" | "completed",
summary: string
)
Если одновременно может выполняться только одна задача, укажите это один раз в описании инструмента. Допустимые значения и правила состояния будут понятны без нескольких примеров диалогов.

3. Загружайте подробные инструкции только по необходимости
Не стоит помещать инструкции по deployment, миграции базы, code review, текстам интерфейса и аварийным ситуациям в один огромный файл.
Оставьте в корневом файле короткую карту:
Это сайт на Hugo.
После изменения контента или layout запускай `hugo --gc --minify`.
Для миграции читай `docs/migration-guide.md`.
Для релиза используй навык deployment.
Такой подход называется постепенным раскрытием: сначала агент получает небольшую карту, затем загружает подробное руководство только для текущей задачи.
Пример структуры:
AGENTS.md
docs/
architecture.md
migration-guide.md
skills/
verify-site/
publish-release/
Карта доступна сразу, но подробный файл занимает контекст лишь тогда, когда действительно нужен.
4. Храните правило рядом с инструментом
Повтор одного правила в системном промпте, руководстве репозитория и описании инструмента расходует место и усложняет обновление.
Оставьте один главный источник:
Инструмент: delete_preview
Описание: удаляет сгенерированный preview. Никогда не применяй к исходному контенту.
При изменении правила достаточно исправить одно место. Кроме того, агент увидит инструкцию именно в момент выбора инструмента.

5. Используйте точные материалы как образец
Иногда готовый материал объясняет цель лучше дополнительного текста.
Полезные образцы:
- тесты с ожидаемым поведением;
- существующий API с нужным дизайном;
- HTML-макет страницы;
- схема или описание типов;
- короткий список критериев качества.
Например, вместо фразы «сделай новую карточку в стиле сайта» дайте ссылку на существующий компонент карточки и его тесты. Код и структурированные материалы точнее обычного описания.
Простая очистка инструкций
Просмотрите инструкции агента и отнесите каждую строку к одной группе:
- Критически важное правило — оставить, особенно если оно связано с безопасностью или необычной особенностью проекта.
- Очевидно из репозитория — удалить.
- Деталь конкретной задачи — перенести в отдельный навык или руководство.
- Поведение инструмента — перенести в описание инструмента.
- Дубликат или противоречие — оставить одну главную версию.
До:
Используй TypeScript.
Всегда изучай существующие файлы.
Никогда не угадывай типы.
Запускай тесты.
Используй список действий для релиза...
[ещё 150 строк]
После:
Следуй существующей архитектуре TypeScript.
Не редактируй сгенерированные файлы в `dist/`.
После изменения кода запускай `npm test`.
Только для релиза используй `docs/release.md`.
Практическое правило
Хороший контекст — короткий, уместный и легко доступный.
Дайте агенту компактную карту проекта. Сохраните строгие ограничения там, где ошибка дорого стоит. Перенесите специальные инструкции в отдельные руководства. Сделайте параметры инструментов понятными. Используйте реальный код, тесты и макеты, если они точнее передают цель.
Современному агенту нужно направление, но не нужно заранее принимать за него каждое решение.
Источник: Thariq Shihipar, Anthropic — «The new rules of context engineering for Claude 5 generation models».