Эта страница переведена с английской документации. Команды, идентификаторы и примеры не изменены. Среда выполнения 7.24.4 · SDK 2.6.7. Английский оригинал

Режим цикла и запланированные задачи

Статус: активно Область: текущее состояние Последняя проверка: 2026-08-27 Владелец: среда выполнения ax-code

У AX Code три сочетаемых примитива автоматизации:

/loop — повторяющиеся запросы

/loop <interval> <prompt>   start (interval like 30s, 5m, 1h)
/loop status                show runs, busy-skips, and the prompt
/loop stop                  stop the loop

Примеры:

/loop 5m check CI for new failures and fix any you find
/loop 30m drain the review queue

Правила:

• Границы интервала: от 30 секунд до 24 часов. Один цикл на сессию — запуск нового заменяет старый.
• Тик, который срабатывает, пока сессия занята, пропускается и считается, но никогда не ставится в очередь: циклы не могут накапливать ходы.
• Каждый тик — обычный ход запроса: разрешения, вопросы, автономные потолки и шлюзы завершения применяются. При выключенном автономном режиме тик просто останавливается на первом запросе разрешения.
• Жёсткий потолок 500 запусков на цикл, затем цикл сам останавливается с уведомлением.
• Циклы живут только в процессе бэкенда: перезапуск они не переживают. Для долговечных расписаний используйте запланированные задачи ниже.

Сочетание /goal с /loop

/goal владеет целью («все тесты зелёные, открытых замечаний рецензии нет»); /loop даёт пульс, который продолжает проверять. Сначала создание цели запускает отдельного автора плана, который сохраняет рецензируемый контракт в .ax-code/goals/ (или в каталоге данных AX, если проект — не git worktree). Если планирование не удаётся, цель остаётся на паузе — /goal resume повторяет её. Проверки диапазона Git, которые меряют diff этой цели, используют HEAD на момент плана ({BASELINE}), а не origin/main, если цель не называет этот удалённый репозиторий. Завершение цели остаётся закрытым проверкой: агент не может пометить цель завершённой после правок без успешного прогона проверки, а когда план есть, он должен также дать свидетельства по каждому критерию приёмки.

/goal keep main green: fix any CI failure the loop finds
/loop 10m check CI status and act on failures

Гарантия цели включается по согласию

/goal <objective> стартует сразу: он не прикрепляет замороженный контракт приёмки, поэтому завершение судится по рабочему плану, который ведёт агент (ожидающие дела), плюс успешная проверка после последнего изменения. /goal view (и «Показать подробности цели» в диалоге цели) говорит об этом явно — «Нет контракта гарантии», — так что состояние никогда не нужно выводить самому.

/goal --assure <objective> сначала запускает автора плана, который замораживает критерии приёмки, ссылки на источники и исполнимые проверки; завершение тогда также требует текущей успешной квитанции по каждой требуемой проверке (verify_project с его идентификатором goalCheck). Используйте это, когда «готово» цели должно быть доказуемым, а не описанным.

--assure сочетается с флагами бюджета в любом порядке (/goal --assure --budget 500000 <objective>). /goal replace <objective> сохраняет гарантию, когда у заменяемой цели есть действительный контракт, поэтому замена не может молча ослабить цель, которая уже была гарантирована.

Бюджеты и потолки цели

Активная цель снимает потолок автоматического продолжения на запуск (session.max_continuations) — запуск продолжается, пока цель не завершена, не заблокирована, не поставлена на паузу или не ограничена бюджетом. Что ограничивает её вместо этого:

• Бюджет токенов (/goal --budget N …): когда он исчерпан, агент получает один ход завершения, затем цель становится budget_limited.
• Бюджет времени (/goal --time-budget 30m …): предел по стенным часам в секундах, минутах (m) или часах (h), сочетается с бюджетом токенов в любом порядке. Он ограничивает прошедшую работу, которую бюджет токенов не видит: удалённые задания обучения, долгие вызовы инструментов, зависания провайдера. Тот же ход завершения и переход budget_limited применяются, когда он срабатывает.
• Накопительный потолок шагов: запуски активной цели делят предохранитель Super-Long в max_steps × 40 шагов всего (20 000 по умолчанию) вместо обычного автономного потолка max_steps × (max_continuations + 1). Переопределите через session.max_total_steps.
• Обнаружение цикла гибели, потолки радиуса поражения и прерыватель хода только из инструментов по-прежнему действуют всё время.

CLI цели (безголовый)

То же управление целью доступно вне TUI под ax-code goal:

• ax-code goal status [--json] — показать текущую цель (-s/--session, чтобы выбрать сессию; по умолчанию единственная возобновляемая цель проекта, ошибка, если выбор был бы неоднозначным).
• ax-code goal pause / ax-code goal clear — поставить на паузу или очистить.
• ax-code goal resume — возобновить цель и вести её безголовым образом, пока она не устоится. Без --attach проект поднимается в том же процессе; с --attach http://localhost:4111 ведётся уже работающий сервер. Коды выхода следуют контракту безголовой цели: 0 завершено, 3 заблокировано, 4 ограничено бюджетом, 6 пауза или нетерминальное состояние, 1 ошибка сессии, 124 тайм-аут простоя (--idle-timeout-ms, по умолчанию 10 минут). События идут в stdout как JSONL (--event-log PATH их тоже записывает), а итоговая строка Goal <status>: <objective> идёт в stderr.

Когда запуск цели приближается к потолку шагов, агент получает однократное предупреждение о сходимости: проверить и завершить цель или оставить чистую передачу. Если потолок всё же достигнут, цель ставится на паузу — не считается неудачей — и её можно снова взять через /goal resume (сначала поднимите session.max_total_steps, если нужно больше запаса).

Запланированные задачи — долговечные, в разговоре

Попросите агента напрямую; он использует инструменты schedule_task, list_scheduled_tasks и manage_scheduled_task:

• «Напомни мне в 14:30 проверить развёртывание.»
• «Каждый будний день в 9:00 суммируй новые сбои CI.»
• «Покажи мои запланированные задачи.» / «Поставь на паузу задачу сводки CI.»

Изменения расписания, созданные и управляемые агентом, запрашивают разрешение schedule. Запуск только для чтения не может изменить или запустить расписание. Для создания без присмотра в безголовом режиме используйте явную команду ax-code schedule или настройте явное разрешение schedule для агента; широкие разрешения с подстановкой изменения расписания не разрешают.

Теми же задачами можно управлять из оболочки, не открывая TUI:

ax-code schedule list                 # status, next run, schedule, id, title
ax-code schedule show <id>            # details plus the five most recent runs
ax-code schedule runs <id>            # run history: fired, failed, skipped and why
ax-code schedule pause|resume <id>
ax-code schedule delete <id>
ax-code schedule run <id>             # trigger now; requires a live runtime

pause/resume/delete идут через управляемую среду выполнения проекта, когда она работает (эффект сразу, живые обновления TUI), и иначе пишут базу данных проекта напрямую. run нужен живой бэкенд — запустите его через ax-code runtime start, — потому что разовый процесс CLI не должен брать работу, которую не сможет закончить. Все подкоманды чтения принимают --json.

Расписания поддерживают разовые запуски, ежедневное и еженедельное время и выражения cron из 5 полей, каждое с необязательным часовым поясом IANA. Задачи сохраняются в базе данных проекта и срабатывают, пока для проекта работает бэкенд AX Code (обход планировщика 60 с, атомарный захват — задача срабатывает один раз, даже если открыто несколько бэкендов). Продвижение расписания и вставка в долговечную очередь делят одну транзакцию базы, поэтому сбой не может продвинуть наступление, не оставив работу для восстановления. Разовые команды вроде ax-code run и ax-code stats не захватывают подоспевшие задачи. Запустите постоянный бэкенд через ax-code runtime start, чтобы их отправить.

Пропущенные наступления по умолчанию равны catchUpPolicy: "run_once": после простоя AX Code сливает любой задел в один запуск. Используйте "skip", когда устаревшую работу нужно продвинуть без запуска. Задача также может задать maxRunDurationMs от одной секунды до 72 часов; просроченный по времени запуск отменяется и записывается как неудачный.

Чтобы работа переживала перезапуски процесса и хоста, запускайте бэкенд под супервизором. Примеры systemd, launchd и PM2 и точную семантику восстановления см. в Долгих операциях.

Долгие запуски без присмотра

Для многочасовых автономных сессий режим Super-Long добавляет сроки запуска (до 72 ч), темп запросов и настройку уплотнения. Он включается сам для моделей, чьи объявленные возможности поддерживают долгую работу агента (модели рассуждения с контекстом 1 млн, такие как Qwen 3.7+ Max/Plus на маршрутах Alibaba и GLM 5.x на маршрутах z.ai), и его можно принудить на сессию, на проект или через AX_CODE_SUPER_LONG. Вовлечённость запуска пишется в журнал (super-long run engaged), а темп провайдера начинается только после окна отсрочки от старта запуска (по умолчанию 2 часа, super_long.pacing_grace_minutes), чтобы продуктивная ранняя фаза агентного запуска сохраняла полную пропускную способность вызовов инструментов; хвост марафона темпируется по объявленному уровню предела частоты модели.