openclaw cron
Керуйте завданнями Cron для планувальника Gateway.
Швидке створення завдань
openclaw cron create є псевдонімом для openclaw cron add. Для нових завдань спочатку вказуйте розклад, а потім prompt:
--webhook <url>, коли завдання має надіслати завершене корисне навантаження через POST замість доставки в ціль чату:
--command для детермінованих завдань у стилі shell, які мають виконуватися всередині OpenClaw cron без запуску ізольованого виконання агента/моделі:
Командні завдання Cron — це створена адміністратором автоматизація Gateway. Для їх створення, редагування,
видалення або ручного запуску потрібен
operator.admin; запланований запуск
пізніше виконується в процесі Gateway, а не як виклик інструмента агента tools.exec.
tools.exec.* і підтвердження exec і надалі керують exec-інструментами, видимими для моделі.--command <shell> зберігає argv: ["sh", "-lc", <shell>]. Використовуйте --command-argv '["node","scripts/report.mjs"]' для точного виконання argv. Командні завдання захоплюють stdout/stderr, записують звичайну історію Cron і маршрутизують вивід через ті самі режими доставки announce, webhook або none, що й ізольовані завдання. Команда, яка виводить лише NO_REPLY, пригнічується.
Сеанси
--session приймає main, isolated, current або session:<id>.
Ключі сеансів
Ключі сеансів
mainприв’язується до основного сеансу агента.isolatedстворює нову стенограму та ідентифікатор сеансу для кожного запуску.currentприв’язується до активного сеансу на момент створення.session:<id>закріплюється за явним постійним ключем сеансу.
Семантика ізольованих сеансів
Семантика ізольованих сеансів
Ізольовані запуски скидають навколишній контекст розмови. Маршрутизація каналів і груп, політика надсилання/черги, підвищення прав, походження та прив’язка середовища виконання ACP скидаються для нового запуску. Безпечні налаштування та явні вибрані користувачем перевизначення моделі або автентифікації можуть переноситися між запусками.
Доставка
openclaw cron list і openclaw cron show <job-id> попередньо показують розв’язаний маршрут доставки. Для 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доставляє фінальну відповідь як fallback лише тоді, коли агент не надіслав її напряму до розв’язаної цілі.webhookнадсилає завершене корисне навантаження на URL.noneвимикає fallback-доставку runner.
cron add|create --webhook <url> або cron edit <job-id> --webhook <url>, щоб налаштувати доставку через webhook. Не поєднуйте --webhook із прапорцями доставки в чат, такими як --announce, --no-deliver, --channel, --to, --thread-id або --account.
cron edit <job-id> може прибрати окремі поля маршрутизації доставки за допомогою --clear-channel, --clear-to, --clear-thread-id і --clear-account (кожен із них відхиляється, якщо поєднаний із відповідним прапорцем установлення). На відміну від --no-deliver, який лише вимикає fallback-доставку runner, ці параметри видаляють збережене поле, щоб завдання знову розв’язувало цю частину маршруту зі значень за замовчуванням.
--announce — це fallback-доставка runner для фінальної відповіді. --no-deliver вимикає цей fallback, але не видаляє інструмент агента message, коли доступний маршрут чату.
Нагадування, створені з активного чату, зберігають поточну ціль доставки чату для fallback-доставки оголошення. Внутрішні ключі сеансів можуть бути в нижньому регістрі; не використовуйте їх як джерело істини для чутливих до регістру ідентифікаторів провайдерів, таких як ідентифікатори кімнат Matrix.
Доставка збоїв
Сповіщення про збої розв’язуються в такому порядку:delivery.failureDestinationу завданні.- Глобальне
cron.failureDestination. - Основна ціль оголошення завдання (коли явну ціль для збоїв не встановлено).
Завдання основного сеансу можуть використовувати
delivery.failureDestination лише тоді, коли основний режим доставки — webhook. Ізольовані завдання приймають його в усіх режимах.ok; ненульовий код виходу, сигнал, тайм-аут або тайм-аут без виводу записує error і
може запустити той самий шлях сповіщення про збій.
Якщо ізольований запуск завершується тайм-аутом до першого запиту моделі, openclaw cron show
і openclaw cron runs включають помилку, специфічну для фази, наприклад
setup timed out before runner start або
stalled before first model call (last phase: context-engine).
Для провайдерів, що працюють через CLI, передмодельний watchdog залишається активним, доки не почнеться зовнішній
хід CLI, тому зависання пошуку сеансу, hook, автентифікації, prompt і налаштування CLI
повідомляються як передмодельні збої Cron.
Планування
Одноразові завдання
--at <datetime> планує одноразовий запуск. Дати й час без зміщення трактуються як UTC, якщо ви також не передали --tz <iana>, який інтерпретує локальний час у заданому часовому поясі.
Одноразові завдання за замовчуванням видаляються після успіху. Використовуйте
--keep-after-run, щоб зберегти їх.Повторювані завдання
Повторювані завдання використовують експоненційний backoff повторних спроб після послідовних помилок: 30s, 1m, 5m, 15m, 60m. Розклад повертається до нормального після наступного успішного запуску. Пропущені запуски відстежуються окремо від помилок виконання. Вони не впливають на backoff повторних спроб, алеopenclaw cron edit <job-id> --failure-alert-include-skipped може ввімкнути для сповіщень про збої повторні повідомлення про пропущені запуски.
Для ізольованих завдань, які націлені на локально налаштованого провайдера моделі, Cron виконує легку попередню перевірку провайдера перед запуском ходу агента. Loopback, приватно-мережеві та .local провайдери api: "ollama" перевіряються за /api/tags; локальні OpenAI-сумісні провайдери, такі як vLLM, SGLang і LM Studio, перевіряються за /models. Якщо endpoint недоступний, запуск записується як skipped і повторюється за пізнішим розкладом; відповідні недіючі endpoints кешуються на 5 хвилин, щоб багато завдань не навантажували той самий локальний сервер.
Примітка: завдання Cron, очікуваний стан середовища виконання та історія запусків зберігаються у спільній базі даних стану SQLite. Застарілі файли jobs.json, jobs-state.json і runs/*.jsonl імпортуються один раз і перейменовуються з суфіксом .migrated. Після імпорту редагуйте розклади за допомогою openclaw cron add|edit|remove, а не редагуванням JSON-файлів.
Ручні запуски
openclaw cron run <job-id> за замовчуванням виконує примусовий запуск і повертається щойно ручний запуск поставлено в чергу. Успішні відповіді містять { ok: true, enqueued: true, runId }. Використовуйте повернений runId, щоб переглянути пізніший результат:
--wait, коли скрипт має блокуватися, доки саме цей поставлений у чергу запуск не запише термінальний статус:
--wait CLI все одно спочатку викликає cron.run, а потім опитує cron.runs для поверненого runId. Команда завершується з 0 лише тоді, коли запуск завершується зі статусом ok. Вона завершується ненульовим кодом, коли запуск завершується з error або skipped, коли відповідь Gateway не містить runId, або коли спливає --wait-timeout. --poll-interval має бути більшим за нуль.
Використовуйте
--due, коли хочете, щоб ручна команда виконувалася лише якщо завдання наразі належить виконати. Якщо --due --wait не ставить запуск у чергу, команда повертає звичайну відповідь без запуску замість опитування.Моделі
cron add|edit --model <ref> вибирає дозволену модель для завдання. cron add|edit --fallbacks <list> задає fallback-моделі для окремого завдання, наприклад --fallbacks openrouter/gpt-4.1-mini,openai/gpt-5; передайте --fallbacks "" для суворого запуску без fallback. cron edit <job-id> --clear-fallbacks видаляє перевизначення fallback для окремого завдання. cron edit <job-id> --clear-model видаляє перевизначення моделі для окремого завдання, щоб завдання дотримувалося звичайного пріоритету вибору моделі Cron (збережене перевизначення сеансу Cron, якщо воно є, інакше модель агента/за замовчуванням); його не можна поєднувати з --model. cron add|edit --thinking <level> задає перевизначення thinking для окремого завдання; cron edit <job-id> --clear-thinking видаляє його, щоб завдання дотримувалося звичайного пріоритету thinking Cron, і його не можна поєднувати з --thinking.
Cron --model — це основна модель завдання, а не перевизначення /model сеансу чату. Це означає:
- Налаштовані fallback моделей і надалі застосовуються, коли вибрана модель завдання дає збій.
- Корисне навантаження
fallbacksдля окремого завдання замінює налаштований список fallback, коли воно присутнє. - Порожній список fallback для окремого завдання (
--fallbacks ""абоfallbacks: []у корисному навантаженні/API завдання) робить запуск Cron суворим. - Коли завдання має
--model, але список fallback не налаштовано, OpenClaw передає явне порожнє перевизначення fallback, щоб основна модель агента не додавалася як прихована ціль повторної спроби. - Попередні перевірки локального провайдера проходять налаштовані fallback перед позначенням запуску Cron як
skipped.
openclaw doctor повідомляє про завдання, у яких уже встановлено payload.model, включно з кількістю просторів імен провайдерів і невідповідностями з agents.defaults.model. Використовуйте цю перевірку, коли поведінка автентифікації, провайдера або білінгу відрізняється між живим чатом і запланованими завданнями.
Пріоритет моделей ізольованого Cron
Ізольований Cron розв’язує активну модель у такому порядку:- Перевизначення Gmail-hook.
--modelдля окремого завдання.- Збережене перевизначення моделі сеансу Cron (коли користувач вибрав його).
- Вибір моделі агента або моделі за замовчуванням.
Швидкий режим
Швидкий режим ізольованого Cron дотримується розв’язаного вибору живої моделі. Конфігурація моделіparams.fastMode застосовується за замовчуванням, але збережене перевизначення сеансу fastMode все одно має перевагу над конфігурацією. Коли розв’язаний режим — auto, граничне значення використовує значення params.fastAutoOnSeconds вибраної моделі, за замовчуванням 60 секунд.
Повторні спроби перемикання живої моделі
Якщо ізольований запуск викидаєLiveSessionModelSwitchError, Cron зберігає переключеного провайдера й модель (а також перевизначення профілю автентифікації після перемикання, якщо воно є) для активного запуску перед повторною спробою. Зовнішній цикл повторних спроб обмежено двома повторними спробами перемикання після початкової спроби, після чого він переривається замість нескінченного циклу.
Вивід запуску та відмови
Пригнічення застарілих підтверджень
Ізольовані ходи Cron пригнічують застарілі відповіді, що складаються лише з підтвердження. Якщо перший результат є лише проміжним оновленням статусу, і жоден дочірній запуск субагента не відповідає за остаточну відповідь, Cron один раз повторно надсилає prompt для отримання реального результату перед доставкою.Пригнічення мовчазних токенів
Якщо ізольований запуск cron повертає лише беззвучний токен (NO_REPLY або no_reply), cron пригнічує як пряме вихідне доставлення, так і резервний шлях поставленого в чергу підсумку, тому в чат нічого не публікується.
Структуровані відмови
Ізольовані запуски cron використовують метадані структурованої відмови у виконанні з вбудованого запуску як авторитетний сигнал відмови. Вони також враховують обгорткиUNAVAILABLE вузла-хоста, коли вкладене структуроване повідомлення про помилку починається з 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 у payload) і мігрує резервні webhook-завдання notify: true з cron.webhook до явного доставлення через Webhook. Завдання, які вже оголошують у чат, зберігають це доставлення та отримують місце призначення Webhook для завершення. Коли cron.webhook не задано, інертний маркер верхнього рівня notify видаляється для завдань без цілі міграції (наявне доставлення зберігається без змін), тому doctor --fix більше не повторює попередження про них.Типові редагування
Оновіть налаштування доставлення без зміни повідомлення:--light-context застосовується лише до ізольованих завдань ходу агента. Для запусків cron полегшений режим залишає початковий контекст порожнім замість вставлення повного початкового набору робочого простору.
Створіть командне завдання з точними argv, cwd, env, stdin і обмеженнями виводу:
Типові команди адміністратора
Ручний запуск та перевірка:openclaw cron list за замовчуванням показує всі відповідні завдання. Передайте --agent <id>, щоб показати лише завдання, чий ефективний нормалізований ідентифікатор агента збігається; завдання без збереженого ідентифікатора агента враховуються як налаштований агент за замовчуванням.
openclaw cron get <job-id> повертає збережений JSON завдання напряму. Використовуйте cron show <job-id>, коли потрібен зручний для читання вигляд із попереднім переглядом маршруту доставлення.
cron list --json і cron show <job-id> --json містять поле верхнього рівня status для кожного завдання, обчислене з enabled, state.runningAtMs і state.lastRunStatus. Значення: disabled, running, ok, error, skipped або idle. Це віддзеркалює зручний для читання стовпець стану, щоб зовнішні інструменти могли читати стан завдання без повторного обчислення.
Записи cron runs містять діагностику доставлення з призначеною ціллю cron, розв’язаною ціллю, надсиланнями інструменту повідомлень, використанням резервного механізму та станом доставлення.
Перенацілювання агента та сеансу:
openclaw cron add попереджає, коли --agent пропущено для завдань ходу агента, і повертається до агента за замовчуванням (main). Передайте --agent <id> під час створення, щоб закріпити конкретного агента.
Налаштування доставлення: