Контекст для современных ИИ-агентов: меньше инструкций, лучше результат

Современные ИИ-агенты часто работают лучше, если получают меньше, но более точных инструкций.

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

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

Что такое проектирование контекста?

Промпт — это текущая просьба:

Добавь 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-макет страницы;
  • схема или описание типов;
  • короткий список критериев качества.

Например, вместо фразы «сделай новую карточку в стиле сайта» дайте ссылку на существующий компонент карточки и его тесты. Код и структурированные материалы точнее обычного описания.

Простая очистка инструкций

Просмотрите инструкции агента и отнесите каждую строку к одной группе:

  1. Критически важное правило — оставить, особенно если оно связано с безопасностью или необычной особенностью проекта.
  2. Очевидно из репозитория — удалить.
  3. Деталь конкретной задачи — перенести в отдельный навык или руководство.
  4. Поведение инструмента — перенести в описание инструмента.
  5. Дубликат или противоречие — оставить одну главную версию.

До:

Используй TypeScript.
Всегда изучай существующие файлы.
Никогда не угадывай типы.
Запускай тесты.
Используй список действий для релиза...
[ещё 150 строк]

После:

Следуй существующей архитектуре TypeScript.
Не редактируй сгенерированные файлы в `dist/`.
После изменения кода запускай `npm test`.
Только для релиза используй `docs/release.md`.

Практическое правило

Хороший контекст — короткий, уместный и легко доступный.

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

Современному агенту нужно направление, но не нужно заранее принимать за него каждое решение.


Источник: Thariq Shihipar, Anthropic — «The new rules of context engineering for Claude 5 generation models».