Готовимся к Astra: OpenAI советует проверить старые скиллы, урезать лишние тесты и отдельно прописать стиль

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

OpenAI начала развёртывание GPT‑6 Astra: сначала модель получают отдельные организации, затем доступ обещан пользователям Plus, Pro, Business и Enterprise, а также разработчикам через API, Azure и AWS Bedrock.

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

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

Собрал главное и добавил короткую стартовую инструкцию, которую можно положить в свой харнесс.

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

OpenAI отдельно предупреждает про AGENTS.md, скиллы и другие файлы, которые модель читает перед работой. Astra чувствительнее к содержащимся там указаниям, поэтому старый мусор, забытые ограничения и неясная иерархия могут начать влиять на результат сильнее.

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

Удалять всё вслепую не нужно. OpenAI советует провести аудит доступных модели файлов, убрать конфликты и явно прописать приоритеты. Например: прямое указание пользователя важнее общего правила из скилла.

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

указание повлияло на решение.

Astra чаще просит уточнение, когда ответ действительно способен изменить результат. Для опасной операции это полезно. В рутинной задаче агент может остановиться там, где от него ждали разумного предположения и продолжения работы.

OpenAI рекомендует заранее описать границу автономности:

Официальная логика простая:

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

Ещё одна важная мелочь: формулировки вроде «можешь поправить?» или «помоги перенести» лучше явно считать поручением к действию. Иначе модель способна ответить планом, объяснить, что она умеет это делать, и аккуратно оставить работу пользователю.

По наблюдениям OpenAI, Astra любит подробные ответы, Markdown, списки и повторяющиеся формулировки. Если продукту нужен другой голос, его придётся закрепить явно.

Компания советует заранее определить:

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

Да, OpenAI фактически приложила промпт против нейрослопа. В нём модель просят писать прямее, не забивать выводы канцелярскими связками, не плодить придуманные составные термины и не строить каждый абзац по схеме «дело не в X, дело в Y».

Для редакционных задач это особенно полезно. Стиль больше нельзя оставлять на уровне «напиши живо». Нужны конкретные правила, примеры удачных текстов и список привычек, которые редактор потом всё равно будет вычищать руками.

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

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

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

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

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

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

Для разработчиков OpenAI дала отдельный список изменений:

Проверить нужно следующее:

• Название модели: gpt-6-astra.
• API для инструментов: использовать Responses API.
• Reasoning effort: после none или minimal начать с low; в остальных случаях сохранить текущий рабочий уровень.
• Старые параметры: убрать temperature, top_p, top_logprobs и другие несовместимые настройки.
• Размышление по ходу хода: использовать configuration_update вместо разрыва запроса.
• Кэширование: проверить prompt_cache_options.ttl со значением 30m.
• Резидентность данных в ЕС: доступна через Standard; fast и priority недоступны.

Astra поддерживает Chat Completions, но для вызова инструментов OpenAI требует Responses API. У модели также нет режима reasoning none.

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

Управление во время работы. Через WebSocket можно прислать новое требование или исправление посреди длинной задачи. Responses API сохраняет уже выполненную работу и продолжает с учётом обновления.

Смена глубины рассуждения без потери кэша. configuration_update позволяет повысить effort для сложного этапа и снизить его для рутинного продолжения, не переписывая исходный префикс запроса.

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

Ниже моя сокращённая сборка рекомендаций OpenAI. Это не официальный перевод промпта, а практичная версия для старта:

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

Я бы не начинал с переписывания всех промптов. Сначала взял бы набор реальных задач и прогнал три варианта:

1. текущая модель с текущим харнессом;
2. Astra с текущим харнессом;
3. Astra после аудита скиллов и добавления новых правил.

Сравнивать стоит не только качество финального ответа. Полезнее считать незапланированные паузы, лишние вопросы, количество tool calls, ненужные тесты, стоимость законченной задачи и долю результатов, которые можно использовать без ручной переделки.

Так станет видно, где прирост дала сама модель, а где его съели старые инструкции.

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

OpenAI прямо говорит о пяти местах, где поведение нужно настраивать: инициатива, иерархия инструкций, стиль, делегация и тестирование. Простая замена model запустит Astra. Хороший результат потребует ещё и ревизии всего, что она читает до начала работы.

Пишу об Astra постоянно в Telegram — @AlexnVibe. Подписывайтесь.

• OpenAI — Model guidance: Using GPT‑6 Astra
• OpenAI — GPT‑6 Astra: A new generation of intelligence