Чем самостоятельнее становится агент, тем заметнее цена старых инструкций. Многостраничный AGENTS.md, десятки skills с расплывчатыми описаниями и обязательное чтение половины репозитория могут не повышать качество, а тратить контекст и мешать модели выбрать правильный следующий шаг.
В заметке о GPT-6 Astra OpenAI предлагает пересмотреть привычную практику промптинга. Главная мысль проста: сильной модели не нужно описывать каждый поворот. Ей нужна понятная среда, в которой легко найти релевантные знания, безопасно принять решение и довести работу до проверяемого результата.
Skills должны быть маршрутизаторами, а не энциклопедиями
Skill обычно хранится в Markdown-файле и описывает повторяемый рабочий процесс: миграцию базы, деплой, работу с конкретным API, подготовку документа или внутренний регламент. Это полезный формат, пока skill помогает в нужный момент, а не загружается при любом совпадении слов.
Проблема начинается с описаний, которые пытаются охватить всю соседнюю область. Например, фраза «используй при работе с базами данных, запросами, моделями или хранением» подтолкнёт агента открывать skill даже для небольшой правки SQL-запроса. В итоге контекст заполняется инструкциями, не связанными с задачей.
Гораздо полезнее описание с точной границей: «используй при добавлении или изменении миграции, а также при проверке плана её rollout». Оно не рассказывает содержание skill целиком, зато хорошо отвечает на вопрос: когда его нужно открыть.
Это важный сдвиг в мышлении. Описание skill не должно быть рекламным текстом с максимальным числом ключевых слов. Его задача похожа на хороший роутинг: привести агента к нужной инструкции и не привести туда без причины.
Progressive disclosure сохраняет контекст для работы
OpenAI отдельно выделяет progressive disclosure, или постепенное раскрытие деталей. У большого skill может быть много сценариев, исключений, команд, примеров и исторических решений. Загружать их все ради одной небольшой правки бессмысленно.
Рабочая структура выглядит так:
- корневой
SKILL.mdкоротко объясняет назначение и точки входа; - специфичные сценарии лежат в отдельных файлах;
- повторяемая механика уходит в скрипты;
- агент читает только ветку, которая относится к текущей задаче.
Такой подход не означает «прятать знания». Наоборот, знания становятся доступнее, потому что их легче найти и применить. Модель не тратит внимание на правила деплоя, когда исправляет опечатку, и не читает документацию по базе, когда меняет текст интерфейса.
Для команд это ещё и способ уменьшить противоречия. Чем больше инструкций загрузили одновременно, тем выше шанс, что две из них по-разному описывают приоритеты или требуют лишних действий.
AGENTS.md не должен быть складом старых тревог
AGENTS.md особенно важен, потому что действует почти во всех задачах в репозитории. Поэтому в него легко попадают следы прошлых проблем: запреты, обязательные чтения, длинные чеклисты и требования, написанные под старые поколения моделей.
Типичный антипример: требовать перед каждым изменением открыть архитектурный документ, описание базы и инструкцию по деплою. Для изменения одной строки это создаёт лишнюю задержку и съедает контекст. Вместо этого полезнее дать навигацию: архитектурный документ нужен для границ сервисов, документация по базе нужна при изменении схемы, а правила деплоя нужны при подготовке релиза.
Разница не формальная. Первый вариант заставляет агента действовать по шаблону, второй помогает ему определить, что действительно относится к текущей задаче.
Сильные модели уже лучше понимают, какие сведения им нужны. Поэтому хороший AGENTS.md сегодня должен быть картой проекта и набором чётких границ, а не попыткой заменить модели способность рассуждать.
Границы решений важнее тотальных запретов
Когда агент однажды сделал слишком много без разрешения, естественная реакция команды - добавить жёсткое правило: «ничего не делай без подтверждения». Это может защитить от риска, но одновременно останавливает безопасную работу, которую агент мог бы завершить самостоятельно.
Вместо общей тревожной формулы полезнее описывать реальные decision boundaries:
- какие действия безопасно выполнять локально;
- когда требуется согласование;
- что относится к production, деньгам, данным или внешним коммуникациям;
- какие проверки агент может запускать сам;
- где он должен остановиться и показать результат человеку.
Например, локальные тесты на одноразовых фикстурах можно прямо разрешить запускать и повторять, пока агент исправляет ошибку по поставленной задаче. А изменение production-данных, публикация поста или отправка сообщения клиенту остаются отдельными действиями с подтверждением.
Такой подход не ослабляет безопасность. Он делает её понятной для модели и для человека: агент не просит разрешения на каждый безобидный шаг, но не переходит границу там, где цена ошибки высока.
Определяй готовность до начала работы
OpenAI отмечает ещё одну особенность: Astra может быть тщательной, но возвращаться за ревью уже после первой реализации. Если задача должна закончиться работающим и проверенным результатом, это стоит сказать явно.
Фраза «добавь авторизацию» оставляет много пространства для трактовки. Агент может написать код и остановиться. Формулировка «добавь авторизацию, запусти локальный сценарий, проверь основной поток, исправь найденные ошибки и прогони затронутые тесты» задаёт более полезный финиш.
Здесь не нужно превращать задачу в пошаговую инструкцию на сотню пунктов. Важнее назвать критерий done: что должно работать, чем это проверить и в какой момент действительно пора возвращаться к человеку.
Это особенно полезно для агентных задач, где «первый рабочий вариант» и «завершённая работа» - разные состояния. Второе включает запуск, проверку, исправление поломок и понятный отчёт о результате.
Что можно проверить в своих инструкциях уже сейчас
Новая модель - хороший повод провести не переписывание всего с нуля, а короткий аудит.
- Посмотреть на descriptions у skills. Понятно ли по одной строке, в какой ситуации skill нужен?
- Разделить объёмные инструкции на короткий роутер и подробные ветки по сценариям.
- Убрать из
AGENTS.mdобязательное чтение материалов «на всякий случай». - Пересмотреть запреты, которые появились из-за особенностей старых моделей. Они защищают от реального риска или просто останавливают работу?
- Для типовых задач определить, что считается готовым: код, запуск, тесты, проверка результата, отчёт.
Главный вывод не в том, что промпты и skills больше не нужны. Они нужны, но их роль меняется. Раньше они часто служили костылями для модели. Теперь это инфраструктура принятия решений: компактные указатели, релевантный контекст, ясные границы и проверяемое завершение задачи.
Вывод
Сильный агент не становится полезнее от максимального количества правил. Он становится полезнее, когда может быстро отличить важное от фонового, понимает предел своих полномочий и знает, что работа не закончена, пока результат не проверен.
Поэтому при переходе на новые модели стоит спрашивать не только «что они умеют». Не менее важный вопрос: какие инструкции мы всё ещё носим с собой от времени, когда агенту приходилось объяснять каждый шаг?
Источник: OpenAI Developers: Rethinking skills and prompts for GPT-6 Astra.
