GPT-6 Astra останавливается? Как сократить AGENTS.md и Skills
Диагностика лишних остановок Astra: как увидеть цепочку инструкций, убрать конфликтующие approval gates, сузить Skills и проверить эффект на одной задаче.
Содержание
Если GPT-6 Astra чаще, чем GPT-5.6 Sol, останавливается и задаёт вопрос, сначала проверьте, действительно ли ответ способен изменить результат. В таком случае уточнение оправданно. Если же модель спрашивает разрешение перед чтением файла, предлагает план вместо уже разрешённой правки или запускает весь test suite после изменения текста, вероятная причина — загруженные инструкции: AGENTS.md, вложенный override или слишком широкий Skill.
OpenAI прямо описывает обе стороны поведения Astra. Модель чаще уточняет решения, которые могут повлиять на итог, и одновременно точнее следует длинным инструкциям. Из-за этого неясное или конфликтующее правило в Skill либо AGENTS.md сильнее влияет на ход задачи. Решение — увидеть реальную цепочку, оставить в ней только постоянные правила и проверить новый вариант на том же fixture.
Если вам ещё нужен доступ к точной модели для повторного прогона, на 6 сентября 2026 года gpt-6-astra есть в группе GPT BetterToken и подключается к официальному Codex через custom provider и Responses API.
Подключить GPT-6 Astra к Codex через BetterToken
Текущая конфигурация приведена в Codex Docs BetterToken. BetterToken отвечает здесь только за API-подключение; то, какие инструкции загружает Codex и когда Astra задаёт вопрос, определяется вашей конфигурацией и задачей.
Сначала найдите все правила, которые модель действительно видит
Codex собирает инструкцию один раз при старте сессии. По официальной схеме AGENTS.md он читает:
- глобальный
AGENTS.override.mdили, если override нет, глобальныйAGENTS.md; - по одному instruction-файлу в каждой директории от корня проекта до текущей рабочей папки: сначала
AGENTS.override.md, затемAGENTS.md, затем настроенныеproject_doc_fallback_filenames, пока не найдётся первый непустой файл; - более близкие к текущей папке правила позже в цепочке и поэтому могут переопределить ранние.
Codex пропускает пустые файлы. Для объединённых project instructions действует лимит project_doc_max_bytes, по умолчанию 32 KiB. Длинный root-файл способен вытеснить инструкции из более узкой папки, хотя именно они нужны текущей задаче.
Начните новый сеанс из той же директории и попросите Codex перечислить загруженные источники инструкций по порядку. Официальная документация предлагает такой диагностический запуск:
codex --ask-for-approval never "List the instruction sources you loaded."Затем проверьте значение project_doc_fallback_filenames и найдите не только AGENTS.md и overrides, но и каждый fallback-файл, который мог быть выбран в текущем пути. Отдельно запишите активный список Skills и источник каждого выбранного Skill: Codex может обнаруживать их не только в репозитории, но и в user, admin и system locations. Не редактируйте файлы, пока не записали исходную цепочку: иначе вы не сможете объяснить, какая правка изменила поведение.
Разметьте правила по четырём вопросам
Для каждой инструкции заполните короткую таблицу:
| Поле | Вопрос |
|---|---|
| Scope | Для всех репозиториев, этого проекта или одной папки действует правило? |
| Trigger | В какой конкретной задаче оно должно включаться? |
| Action | Что именно Codex должен сделать? |
| Stop | Должна ли инструкция останавливать работу и ждать ответа пользователя? |
Фразы без ясного trigger чаще всего создают лишние остановки:
Always ask before making changesзаставляет спрашивать даже перед обратимой локальной правкой.Use every relevant skillможет загрузить несколько пересекающихся процессов.Run all tests before finishingрасширяет проверку независимо от размера изменения.Do not make assumptionsзапрещает заполнить рутинный пробел, хотя выбор не меняет результат.- два разных файла одновременно говорят «эта инструкция имеет высший приоритет».
Сохраните stop condition только там, где без решения пользователя результат действительно может стать другим: необратимое удаление, публикация, платная операция, выбор несовместимой архитектуры или отсутствующий секрет. Чтение файлов, локальная правка и целевой тест обычно не нуждаются в отдельном подтверждении, если задача уже поручена.
Короткий AGENTS.md: постоянные правила вместо сценария на все случаи
Плохой root-файл пытается описать каждый возможный шаг:
AGENTS.md
- Always ask the user before changing any file.
- Always create a detailed plan and wait for approval.
- Use all available skills that may be relevant.
- Run the full test suite after every change.
- Never make assumptions.
- Never stop until everything in the repository is fixed.В этих правилах конфликтуют автономность, область задачи и тестирование. Последняя строка ещё и расширяет поручение на весь репозиторий.
Более полезный вариант фиксирует результат и границы:
AGENTS.md
## Working agreement
- Complete the user's requested outcome with the smallest correct change.
- Treat the user's current instruction as higher priority than reusable workflow guidance.
- Make routine, reversible assumptions when they do not change the requested outcome; state material assumptions.
- Ask only when a missing choice would materially change the result or authorization.
- Preserve unrelated work and do not expand scope to optional cleanup.
- Run checks proportionate to the changed behavior; broaden only when evidence justifies it.
- Stop after the requested result and relevant checks are complete.Это не универсальный шаблон. Добавьте команды проекта, формат commit и реальные запреты, если они действуют постоянно. Правила конкретного сервиса поместите ближе к его директории. Если используете временный AGENTS.override.md, помните: в той же директории он заменяет AGENTS.md, а не дополняет его. Перенесите в override все обязательные правила из вытесняемого файла либо используйте вложенный AGENTS.md для более узкого scope; после эксперимента удалите временный override.
Что оставить в AGENTS.md, а что вынести
AGENTS.md подходит для соглашений, которые применяются почти к каждой задаче в данном scope:
- границы репозитория и ownership;
- основной package manager и обязательная команда проверки;
- правила сохранения пользовательских изменений;
- условия, требующие согласования;
- формат краткого финального отчёта.
Редкий многошаговый процесс лучше хранить в Skill — файле с переиспользуемыми инструкциями для конкретной работы. Детерминированное преобразование, которое каждый раз должно давать один и тот же результат, лучше вынести в script или hook. Большая справка относится в references/, чтобы не загружаться до выбора Skill.
Получается простое распределение:
| Содержание | Место |
|---|---|
| Постоянное правило для всех задач проекта | root AGENTS.md |
| Правило только для одной папки или сервиса | вложенный AGENTS.md или AGENTS.override.md |
| Редкий повторяемый процесс с отдельным trigger | один узкий Skill |
| Парсинг, форматирование, валидация schema | script или hook |
| Подробная справка и примеры | references/ выбранного Skill |
Сузьте Skills и их descriptions
Codex Skills используют progressive disclosure. Сначала модель видит название и description, а полный SKILL.md читает только после выбора Skill. Поэтому широкий description вроде «используй для любых задач разработки» способен активировать процесс там, где он не нужен.
Каждый Skill должен отвечать за одну работу. В description поставьте trigger и границы в первую строку:
---
name: release-preview
description: >-
Use only when the user asks to build a local release preview; do not publish,
deploy, push, or change production state.
---В самом SKILL.md оставьте imperative steps, точные inputs, outputs и реальные stop conditions. Большие примеры вынесите в reference, а механическое действие — в script:
Release preview
## Inputs
- One validated article payload.
- A clean local preview checkout.
## Workflow
1. Build the preview from the supplied payload.
2. Verify title, body, links, and images locally.
3. Return the preview path and stop.
## Stop conditions
- The payload is missing or invalid.
- The task requires production publication; request separate authorization.Проверьте description несколькими prompts: один должен активировать Skill, два соседних — нет. Если два Skills запускаются на одно и то же поручение, разделите triggers или объедините дубли. Если правило требуется только внутри одного Skill, удалите его из root AGENTS.md, чтобы модель не видела две версии.
Настройте инициативу, приоритеты и проверку явно
В руководстве по Astra OpenAI рекомендует явно задать четыре поведения:
- выполнять подразумеваемое поручение до готового результата, а не останавливаться на плане;
- трактовать пользовательскую инструкцию как приоритетную по отношению к общим рекомендациям Skill;
- задавать вопрос только тогда, когда ответ материально меняет результат;
- выбирать проверки по риску изменения, не повторяя широкие suites без нового основания.
Не копируйте длинный блок в каждый Skill. Один короткий working agreement на подходящем уровне работает лучше нескольких слегка разных версий. Узкие исключения размещайте рядом с тем кодом или процессом, которому они принадлежат.
Также задайте правило subagents только в том случае, если ваш процесс ими пользуется. Astra может делегировать реже, чем требуется конкретному harness; фраза «всегда используй несколько агентов» создаст противоположную проблему на маленьких задачах. Укажите trigger: независимые подзадачи, достаточный объём и понятный способ объединить результаты.
Сравните до и после на одном fixture
Возьмите небольшую задачу, которую можно принять без вкусовой оценки. Например:
Update one configuration field in docs/setup.md, preserve all unrelated files,
run the Markdown link check for that file, and report the changed path.Запустите её из одной директории с одной моделью, одинаковыми permissions и чистым состоянием. Для варианта «до» и «после» запишите:
- сколько вопросов было задано до первой правки;
- требовался ли ответ пользователя для продолжения;
- какие instruction files и Skills были загружены;
- какие команды проверки реально выполнялись;
- создан ли нужный diff без посторонних изменений.
Улучшение — это не ноль вопросов любой ценой. Хороший результат задаёт вопрос при существенном выборе, продолжает работу при рутинном решении, запускает достаточную проверку и сохраняет границы поручения. Если после сокращения поведение не изменилось, проверьте текущую директорию, nested override, дубликаты Skill и перезапуск сессии: Codex собирает цепочку при старте.
Мы не выполняли такой controlled replay на пользовательском репозитории при подготовке статьи, поэтому не обещаем фиксированного сокращения числа вопросов. Метод даёт наблюдаемый способ отделить поведение модели от конкретной инструкции — и оставить только те правила, которые действительно улучшают результат.
