--- read_when: - Вам нужны запланированные задания и пробуждения - Вы отлаживаете выполнение Cron и журналы summary: Справочник CLI для `openclaw cron` (планирование и запуск фоновых заданий) title: Cron x-i18n: generated_at: "2026-06-28T22:42:30Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: fa81e555d35b8982d1de9703c68dfb66aa9ad39407d46555eb0143e3cc5f52f5 source_path: cli/cron.md workflow: 16 --- # `openclaw cron` Управляйте заданиями Cron для планировщика Gateway. Выполните `openclaw cron --help`, чтобы увидеть весь набор команд. См. концептуальное руководство [Задания Cron](/ru/automation/cron-jobs). ## Быстрое создание заданий `openclaw cron create` — это псевдоним для `openclaw cron add`. Для новых заданий сначала укажите расписание, а затем промпт: ```bash openclaw cron create "0 7 * * *" \ "Summarize overnight updates." \ --name "Morning brief" \ --agent ops ``` Используйте `--webhook `, когда задание должно отправлять готовую полезную нагрузку через POST вместо доставки в целевой чат: ```bash openclaw cron create "0 18 * * 1-5" \ "Summarize today's deploys as JSON." \ --name "Deploy digest" \ --webhook "https://example.invalid/openclaw/cron" ``` Используйте `--command` для детерминированных заданий в стиле оболочки, которые должны выполняться внутри OpenClaw cron без запуска изолированного запуска агента/модели: Командные задания Cron — это администраторская автоматизация Gateway. Создание, редактирование, удаление или ручной запуск таких заданий требует `operator.admin`; запланированный запуск затем выполняется в процессе Gateway, а не как вызов инструмента агента `tools.exec`. `tools.exec.*` и подтверждения exec по-прежнему управляют видимыми модели инструментами exec. ```bash openclaw cron create "*/15 * * * *" \ --name "Queue depth probe" \ --command "scripts/check-queue.sh" \ --command-cwd "/srv/app" \ --announce \ --channel telegram \ --to "-1001234567890" ``` `--command ` сохраняет `argv: ["sh", "-lc", ]`. Используйте `--command-argv '["node","scripts/report.mjs"]'` для выполнения с точным argv. Командные задания захватывают stdout/stderr, записывают обычную историю Cron и направляют вывод через те же режимы доставки `announce`, `webhook` или `none`, что и изолированные задания. Команда, которая выводит только `NO_REPLY`, подавляется. ## Сеансы `--session` принимает `main`, `isolated`, `current` или `session:`. - `main` привязывается к основному сеансу агента. - `isolated` создает новую расшифровку и идентификатор сеанса для каждого запуска. - `current` привязывается к активному сеансу на момент создания. - `session:` закрепляет явный постоянный ключ сеанса. Изолированные запуски сбрасывают окружающий контекст разговора. Маршрутизация канала и группы, политика отправки/очереди, повышение привилегий, источник и привязка runtime ACP сбрасываются для нового запуска. Безопасные предпочтения и явно выбранные пользователем переопределения модели или аутентификации могут переноситься между запусками. ## Доставка `openclaw cron list` и `openclaw cron show ` показывают предварительный просмотр разрешенного маршрута доставки. Для `channel: "last"` предварительный просмотр показывает, был ли маршрут разрешен из основного или текущего сеанса либо завершится закрытым отказом. Цели с префиксом провайдера могут устранять неоднозначность неразрешенных каналов объявлений. Например, `to: "telegram:123"` выбирает Telegram, когда `delivery.channel` опущен или равен `last`. Только префиксы, объявленные загруженным Plugin, являются селекторами провайдера. Если `delivery.channel` задан явно, префикс должен соответствовать этому каналу; `channel: "whatsapp"` с `to: "telegram:123"` отклоняется. Сервисные префиксы, такие как `imessage:` и `sms:`, остаются синтаксисом цели, принадлежащим каналу. Изолированные задания `cron add` по умолчанию используют доставку `--announce`. Используйте `--no-deliver`, чтобы оставить вывод внутренним. `--deliver` остается устаревшим псевдонимом для `--announce`. ### Владение доставкой Доставка сообщений изолированного Cron в чат совместно выполняется агентом и runner: - Агент может отправлять напрямую с помощью инструмента `message`, когда доступен маршрут чата. - `announce` выполняет резервную доставку финального ответа только тогда, когда агент не отправил его напрямую в разрешенную цель. - `webhook` отправляет готовую полезную нагрузку по URL. - `none` отключает резервную доставку runner. Используйте `cron add|create --webhook ` или `cron edit --webhook `, чтобы настроить доставку через Webhook. Не сочетайте `--webhook` с флагами доставки в чат, такими как `--announce`, `--no-deliver`, `--channel`, `--to`, `--thread-id` или `--account`. `cron edit ` может сбрасывать отдельные поля маршрутизации доставки с помощью `--clear-channel`, `--clear-to`, `--clear-thread-id` и `--clear-account` (каждый отклоняется при сочетании с соответствующим флагом установки). В отличие от `--no-deliver`, который только отключает резервную доставку runner, эти флаги удаляют сохраненное поле, чтобы задание снова разрешало эту часть маршрута из значений по умолчанию. `--announce` — это резервная доставка runner для финального ответа. `--no-deliver` отключает этот резервный путь, но не удаляет инструмент агента `message`, когда доступен маршрут чата. Напоминания, созданные из активного чата, сохраняют живую целевую доставку чата для резервной доставки объявлений. Внутренние ключи сеансов могут быть в нижнем регистре; не используйте их как источник истины для чувствительных к регистру идентификаторов провайдера, таких как идентификаторы комнат Matrix. ### Доставка сбоев Уведомления о сбоях разрешаются в таком порядке: 1. `delivery.failureDestination` в задании. 2. Глобальный `cron.failureDestination`. 3. Основная цель объявлений задания (когда явное место назначения для сбоев не задано). Задания основного сеанса могут использовать `delivery.failureDestination` только когда основной режим доставки — `webhook`. Изолированные задания принимают его во всех режимах. Примечание: изолированные запуски Cron считают сбои агента уровня запуска ошибками задания даже тогда, когда полезная нагрузка ответа не создается, поэтому сбои модели/провайдера все равно увеличивают счетчики ошибок и запускают уведомления о сбоях. Командные задания Cron не запускают изолированный ход агента. Нулевой код выхода записывает `ok`; ненулевой выход, сигнал, тайм-аут или тайм-аут отсутствия вывода записывает `error` и может запустить тот же путь уведомления о сбое. Если изолированный запуск истекает по тайм-ауту до первого запроса модели, `openclaw cron show` и `openclaw cron runs` включают ошибку, специфичную для фазы, например `setup timed out before runner start` или `stalled before first model call (last phase: context-engine)`. Для провайдеров на базе CLI сторожевой таймер до модели остается активным до начала внешнего хода CLI, поэтому зависания поиска сеанса, hook, аутентификации, промпта и настройки CLI сообщаются как сбои Cron до модели. ## Планирование ### Одноразовые задания `--at ` планирует одноразовый запуск. Даты и время без смещения считаются UTC, если вы также не передаете `--tz `, который интерпретирует локальное время в указанном часовом поясе. Одноразовые задания по умолчанию удаляются после успешного выполнения. Используйте `--keep-after-run`, чтобы сохранить их. ### Повторяющиеся задания Повторяющиеся задания используют экспоненциальную задержку повторных попыток после последовательных ошибок: 30 с, 1 мин, 5 мин, 15 мин, 60 мин. Расписание возвращается к норме после следующего успешного запуска. Пропущенные запуски отслеживаются отдельно от ошибок выполнения. Они не влияют на задержку повторных попыток, но `openclaw cron edit --failure-alert-include-skipped` может включить повторные уведомления о пропущенных запусках в оповещения о сбоях. Для изолированных заданий, которые нацелены на локально настроенного провайдера модели, cron выполняет легкую предварительную проверку провайдера перед запуском хода агента. Провайдеры `api: "ollama"` для loopback, частной сети и `.local` проверяются по `/api/tags`; локальные OpenAI-совместимые провайдеры, такие как vLLM, SGLang и LM Studio, проверяются по `/models`. Если конечная точка недоступна, запуск записывается как `skipped` и повторяется по более позднему расписанию; совпадающие неработающие конечные точки кэшируются на 5 минут, чтобы множество заданий не перегружало один и тот же локальный сервер. Примечание: задания Cron, ожидающее runtime-состояние и история запусков хранятся в общей базе данных состояния SQLite. Устаревшие файлы `jobs.json`, `jobs-state.json` и `runs/*.jsonl` импортируются один раз и переименовываются с суффиксом `.migrated`. После импорта редактируйте расписания с помощью `openclaw cron add|edit|remove`, а не путем редактирования JSON-файлов. ### Ручные запуски `openclaw cron run ` по умолчанию запускает принудительно и возвращается сразу после постановки ручного запуска в очередь. Успешные ответы включают `{ ok: true, enqueued: true, runId }`. Используйте возвращенный `runId`, чтобы проверить последующий результат: ```bash openclaw cron run openclaw cron runs --id --run-id ``` Добавьте `--wait`, когда скрипт должен блокироваться до тех пор, пока именно этот поставленный в очередь запуск не запишет терминальный статус: ```bash openclaw cron run --wait --wait-timeout 10m --poll-interval 2s ``` С `--wait` CLI все равно сначала вызывает `cron.run`, затем опрашивает `cron.runs` по возвращенному `runId`. Команда завершается с `0` только когда запуск заканчивается со статусом `ok`. Она завершается с ненулевым кодом, когда запуск заканчивается с `error` или `skipped`, когда ответ Gateway не содержит `runId` или когда истекает `--wait-timeout`. `--poll-interval` должен быть больше нуля. Используйте `--due`, когда хотите, чтобы ручная команда запускалась только если задание сейчас подлежит выполнению. Если `--due --wait` не ставит запуск в очередь, команда возвращает обычный ответ без запуска вместо опроса. ## Модели `cron add|edit --model ` выбирает разрешенную модель для задания. `cron add|edit --fallbacks ` задает резервные модели для задания, например `--fallbacks openrouter/gpt-4.1-mini,openai/gpt-5`; передайте `--fallbacks ""` для строгого запуска без резервных вариантов. `cron edit --clear-fallbacks` удаляет переопределение резервных моделей для задания. `cron edit --clear-model` удаляет переопределение модели для задания, чтобы задание следовало обычному приоритету выбора модели Cron (сохраненное переопределение cron-сеанса, если оно есть, иначе модель агента/по умолчанию); его нельзя сочетать с `--model`. Если модель не разрешена или не может быть разрешена, cron завершает запуск с явной ошибкой валидации вместо отката к выбору модели агента задания или модели по умолчанию. Cron `--model` — это **основная модель задания**, а не переопределение `/model` для чат-сеанса. Это означает: - Настроенные резервные модели по-прежнему применяются при сбое выбранной модели задания. - Поле `fallbacks` в полезной нагрузке задания заменяет настроенный список резервных моделей, когда присутствует. - Пустой список резервных моделей для задания (`--fallbacks ""` или `fallbacks: []` в полезной нагрузке/API задания) делает запуск Cron строгим. - Когда у задания есть `--model`, но список резервных моделей не настроен, OpenClaw передает явное пустое резервное переопределение, чтобы основная модель агента не добавлялась как скрытая цель повторной попытки. - Предварительные проверки локального провайдера проходят по настроенным резервным моделям перед тем, как пометить запуск Cron как `skipped`. `openclaw doctor` сообщает о заданиях, в которых уже задан `payload.model`, включая счетчики пространств имен провайдеров и несовпадения с `agents.defaults.model`. Используйте эту проверку, когда поведение аутентификации, провайдера или биллинга отличается между живым чатом и запланированными заданиями. ### Приоритет модели изолированного Cron Изолированный Cron разрешает активную модель в таком порядке: 1. Переопределение Gmail-hook. 2. `--model` для задания. 3. Сохраненное переопределение модели cron-сеанса (когда пользователь выбрал его). 4. Выбор модели агента или модели по умолчанию. ### Быстрый режим Быстрый режим изолированного Cron следует разрешенному выбору живой модели. Конфигурация модели `params.fastMode` применяется по умолчанию, но сохраненное переопределение сеанса `fastMode` все равно имеет приоритет над конфигурацией. Когда разрешенный режим равен `auto`, порог использует значение `params.fastAutoOnSeconds` выбранной модели, по умолчанию 60 секунд. ### Повторные попытки переключения живой модели Если изолированный запуск выбрасывает `LiveSessionModelSwitchError`, cron сохраняет переключенного провайдера и модель (а также переопределение переключенного профиля аутентификации, если оно есть) для активного запуска перед повторной попыткой. Внешний цикл повторных попыток ограничен двумя повторными попытками переключения после начальной попытки, затем прерывается вместо бесконечного цикла. ## Вывод запуска и отказы ### Подавление устаревших подтверждений Изолированные ходы Cron подавляют устаревшие ответы, состоящие только из подтверждения. Если первый результат — лишь промежуточное обновление статуса и ни один дочерний запуск субагента не отвечает за итоговый ответ, cron один раз повторно запрашивает настоящий результат перед доставкой. ### Подавление silent token Если изолированный запуск Cron возвращает только silent token (`NO_REPLY` или `no_reply`), cron подавляет как прямую исходящую доставку, так и резервный путь сводки в очереди, поэтому в чат ничего не отправляется. ### Структурированные отказы Изолированные запуски Cron используют структурированные метаданные отказа в выполнении из встроенного запуска как авторитетный сигнал отказа. Они также учитывают обертки `UNAVAILABLE` хоста Node, когда вложенное структурированное сообщение об ошибке начинается с `SYSTEM_RUN_DENIED` или `INVALID_REQUEST`. Cron не классифицирует прозу финального вывода или похожие на отказ с запросом одобрения фразы как отказы, если встроенный запуск также не предоставляет структурированные метаданные отказа, поэтому обычный текст ассистента не считается заблокированной командой. `cron list` и история запусков показывают причину отказа вместо того, чтобы сообщать о заблокированной команде как об `ok`. ## Хранение Хранение и очистка настраиваются в конфигурации: - `cron.sessionRetention` (по умолчанию `24h`) удаляет завершенные сессии изолированных запусков. - `cron.runLog.keepLines` удаляет сохраненные строки истории запусков SQLite для каждого задания. `cron.runLog.maxBytes` по-прежнему принимается для совместимости со старыми файловыми журналами запусков. ## Миграция старых заданий Если у вас есть задания Cron, созданные до текущего формата доставки и хранения, выполните `openclaw doctor --fix`. Doctor нормализует устаревшие поля Cron (`jobId`, `schedule.cron`, поля доставки верхнего уровня, включая устаревшее `threadId`, а также псевдонимы доставки `provider` в полезной нагрузке) и мигрирует резервные задания Webhook с `notify: true` из `cron.webhook` в явную доставку Webhook. Задания, которые уже отправляют объявления в чат, сохраняют эту доставку и получают назначение Webhook для завершения. Когда `cron.webhook` не задан, инертный маркер верхнего уровня `notify` удаляется для заданий без цели миграции (существующая доставка сохраняется без изменений), поэтому `doctor --fix` больше не продолжает повторно предупреждать о них. ## Частые изменения Обновить настройки доставки без изменения сообщения: ```bash openclaw cron edit --announce --channel telegram --to "123456789" ``` Отключить доставку для изолированного задания: ```bash openclaw cron edit --no-deliver ``` Включить облегченный контекст начальной загрузки для изолированного задания: ```bash openclaw cron edit --light-context ``` Объявлять в определенный канал: ```bash openclaw cron edit --announce --channel slack --to "channel:C1234567890" ``` Объявлять в тему форума Telegram: ```bash openclaw cron edit --announce --channel telegram --to "-1001234567890" --thread-id 42 ``` Создать изолированное задание с облегченным контекстом начальной загрузки: ```bash openclaw cron create "0 7 * * *" \ "Summarize overnight updates." \ --name "Lightweight morning brief" \ --session isolated \ --light-context \ --no-deliver ``` `--light-context` применяется только к изолированным заданиям агентского хода. Для запусков Cron облегченный режим оставляет контекст начальной загрузки пустым вместо внедрения полного набора начальной загрузки рабочей области. Создать командное задание с точными argv, cwd, env, stdin и ограничениями вывода: ```bash openclaw cron create "*/30 * * * *" \ --name "Position export" \ --command-argv '["node","scripts/export-position.mjs"]' \ --command-cwd "/srv/app" \ --command-env "NODE_ENV=production" \ --command-input '{"mode":"summary"}' \ --timeout-seconds 120 \ --no-output-timeout-seconds 30 \ --output-max-bytes 65536 \ --webhook "https://example.invalid/openclaw/cron" ``` ## Частые команды администрирования Ручной запуск и проверка: ```bash openclaw cron list openclaw cron list --agent ops openclaw cron get openclaw cron show openclaw cron run openclaw cron run --due openclaw cron run --wait --wait-timeout 10m openclaw cron run --wait --wait-timeout 10m --poll-interval 2s openclaw cron runs --id --limit 50 openclaw cron runs --id --run-id ``` `openclaw cron list` по умолчанию показывает все подходящие задания. Передайте `--agent `, чтобы показать только задания, чей эффективный нормализованный идентификатор агента совпадает; задания без сохраненного идентификатора агента считаются заданиями настроенного агента по умолчанию. `openclaw cron get ` возвращает сохраненный JSON задания напрямую. Используйте `cron show `, когда нужен удобочитаемый вид с предварительным просмотром маршрута доставки. `cron list --json` и `cron show --json` включают поле верхнего уровня `status` для каждого задания, вычисленное из `enabled`, `state.runningAtMs` и `state.lastRunStatus`. Значения: `disabled`, `running`, `ok`, `error`, `skipped` или `idle`. Это отражает удобочитаемый столбец состояния, чтобы внешние инструменты могли читать состояние задания без повторного вычисления. Записи `cron runs` включают диагностические данные доставки с предполагаемой целью Cron, разрешенной целью, отправками инструмента сообщений, использованием резервного варианта и состоянием доставки. Переназначение агента и сессии: ```bash openclaw cron edit --agent ops openclaw cron edit --clear-agent openclaw cron edit --session current openclaw cron edit --session "session:daily-brief" ``` `openclaw cron add` предупреждает, когда `--agent` опущен для заданий агентского хода, и возвращается к агенту по умолчанию (`main`). Передайте `--agent ` при создании, чтобы закрепить конкретного агента. Настройки доставки: ```bash openclaw cron edit --announce --channel slack --to "channel:C1234567890" openclaw cron edit --webhook "https://example.invalid/openclaw/cron" openclaw cron edit --best-effort-deliver openclaw cron edit --no-best-effort-deliver openclaw cron edit --no-deliver ``` ## Связанные материалы - [Справочник CLI](/ru/cli) - [Запланированные задачи](/ru/automation/cron-jobs)