Automation
Фонові завдання
Фонові завдання відстежують роботу, що виконується поза основним сеансом розмови: запуски ACP, створення субагентів, виконання завдань cron та операції, ініційовані через CLI.
Завдання не замінюють сеанси, завдання cron або Heartbeat — це журнал активності, який фіксує, яка відокремлена робота виконувалася, коли саме та чи була вона успішною.
Коротко
- Завдання — це записи, а не планувальники: cron і Heartbeat визначають, коли виконується робота, а завдання відстежують, що сталося.
- ACP, субагенти, усі завдання cron та операції CLI створюють завдання. Цикли Heartbeat цього не роблять.
- Кожне завдання проходить стани
queued → running → terminal(succeeded, failed, timed_out, cancelled або lost). - Завдання cron залишаються активними, доки середовище виконання cron володіє завданням; якщо стан середовища виконання в пам’яті втрачено, обслуговування завдань спочатку перевіряє збережену історію запусків cron і лише потім позначає завдання як втрачене.
- Завершення працює на основі надсилання подій: відокремлена робота після завершення може надіслати сповіщення безпосередньо або активувати сеанс запитувача чи Heartbeat, тому цикли опитування стану зазвичай є неправильним підходом.
- Ізольовані запуски cron і завершення субагентів у міру можливості закривають відстежувані вкладки браузера та процеси дочірнього сеансу перед остаточним службовим очищенням.
- Доставлення ізольованого cron пригнічує застарілі проміжні відповіді батьківського агента, доки робота дочірніх субагентів ще завершується, і надає перевагу остаточному виводу дочірнього агента, якщо він надходить до доставлення.
- Сповіщення про завершення доставляються безпосередньо в канал або ставляться в чергу до наступного Heartbeat.
openclaw tasks listпоказує всі завдання;openclaw tasks auditвиявляє проблеми.- Термінальні записи зберігаються 7 днів (записи
lost— 24 години), після чого автоматично видаляються.
Швидкий початок
Перегляд і фільтрування
# Перелік усіх завдань (спочатку найновіші)openclaw tasks list # Фільтрування за середовищем виконання або станомopenclaw tasks list --runtime acpopenclaw tasks list --status runningПеревірка
# Показати відомості про конкретне завдання (за ID завдання, ID запуску або ключем сеансу)openclaw tasks show <lookup>Скасування та сповіщення
# Скасувати активне завдання (завершує дочірній сеанс)openclaw tasks cancel <lookup> # Змінити політику сповіщень для завданняopenclaw tasks notify <lookup> state_changesАудит і обслуговування
# Запустити аудит справностіopenclaw tasks audit # Попередньо переглянути або застосувати обслуговуванняopenclaw tasks maintenanceopenclaw tasks maintenance --applyПотік завдання
# Перевірити стан TaskFlowopenclaw tasks flow listopenclaw tasks flow show <lookup>openclaw tasks flow cancel <lookup>Що створює завдання
| Джерело | Тип середовища виконання | Коли створюється запис завдання | Стандартна політика сповіщень |
|---|---|---|---|
| Фонові запуски ACP | acp |
Створення дочірнього сеансу ACP | done_only |
| Оркестрація субагентів | subagent |
Створення субагента через sessions_spawn |
done_only |
| Завдання cron (усі типи) | cron |
Кожне виконання cron (в основному сеансі та ізольоване) | silent |
| Операції CLI | cli |
Команди openclaw agent, що виконуються через Gateway |
silent |
| Завдання агента з медіа | cli |
Запуски image_generate/music_generate/video_generate із сеансом |
silent |
Стандартні сповіщення для cron і медіа
Завдання cron (в основному сеансі та ізольовані) використовують політику сповіщень silent: вони створюють записи для відстеження, але не генерують власних сповіщень про завдання; шлях доставлення контролює cron.
Запуски image_generate, music_generate і video_generate, пов’язані із сеансом, також використовують політику сповіщень silent. Вони все одно створюють записи завдань, але завершення повертається початковому сеансу агента як внутрішня активація, щоб агент міг написати подальше повідомлення та самостійно прикріпити готові медіафайли. Агент-запитувач дотримується свого звичайного контракту видимих відповідей: автоматична остаточна відповідь, якщо це налаштовано, або message(action="send") разом із NO_REPLY, якщо сеанс вимагає відповідей через інструмент повідомлень. Якщо сеанс запитувача вже неактивний або його активна активація завершується помилкою, а агент завершення не отримує частину або всі згенеровані медіафайли, OpenClaw надсилає ідемпотентне пряме резервне повідомлення лише з відсутніми медіафайлами до початкової цілі каналу.
Захист від одночасного створення медіа
Поки завдання створення медіа, пов’язане із сеансом, залишається активним, image_generate, music_generate і video_generate захищають від випадкових повторних спроб: повторення виклику для того самого запиту повертає стан відповідного активного завдання замість запуску дубліката, тоді як інший запит може запустити власне завдання. Використовуйте action: "status", якщо потрібен явний запит перебігу виконання або стану з боку агента.
Що не створює завдань
- Цикли Heartbeat в основному сеансі; див. Heartbeat
- Звичайні цикли інтерактивного чату
- Прямі відповіді
/command
Життєвий цикл завдання
stateDiagram-v2
[*] --> queued
queued --> running : агент запускається
running --> succeeded : успішне завершення
running --> failed : помилка
running --> timed_out : перевищено час очікування
queued --> cancelled : оператор скасовує
running --> cancelled : оператор скасовує
queued --> lost : базовий стан відсутній > 5 хв
running --> lost : базовий стан відсутній > 5 хв| Стан | Що він означає |
|---|---|
queued |
Створено, очікує запуску агента |
running |
Цикл агента активно виконується |
succeeded |
Успішно завершено |
failed |
Завершено з помилкою |
timed_out |
Перевищено налаштований час очікування |
cancelled |
Зупинено оператором через openclaw tasks cancel або запуск було перервано |
lost |
Середовище виконання втратило авторитетний базовий стан після 5 хвилин очікування |
Переходи відбуваються автоматично: події життєвого циклу запуску агента (початок, завершення, помилка) оновлюють стан завдання; керувати ним вручну не потрібно.
Завершення запуску агента є авторитетним для активних записів завдань. Успішний відокремлений запуск завершується зі станом succeeded, звичайні помилки запуску — зі станом failed, перевищення часу очікування — зі станом timed_out, а скасування чи переривання — зі станом cancelled. Коли завдання переходить у термінальний стан, пізніші сигнали життєвого циклу не можуть знизити його стан: скасоване оператором або вже позначене як failed/timed_out/lost завдання зберігає цей стан, навіть якщо згодом надходить сигнал про успішне завершення.
Стан lost залежить від середовища виконання:
- Завдання ACP: лише активний внутрішньопроцесний цикл ACP у Gateway підтверджує, що запуск досі виконується; самих лише збережених метаданих сеансу недостатньо. Автономний аудит CLI діє консервативно й ніколи не відновлює завдання ACP.
- Завдання субагентів: базовий дочірній сеанс зник зі сховища цільового агента або містить позначку відновлення після перезапуску.
- Завдання cron: середовище виконання cron більше не відстежує завдання як активне, а збережена історія запусків cron не містить термінального результату цього запуску. Автономний аудит CLI не вважає власний порожній внутрішньопроцесний стан середовища виконання cron авторитетним.
- Завдання CLI: завдання з ID запуску або ID джерела використовують активний контекст запуску, тому залишкові записи дочірнього сеансу чи сеансу чату не зберігають їх активними після зникнення запуску, яким володів Gateway. Застарілі завдання CLI без ідентифікатора запуску й надалі використовують дочірній сеанс як резервний варіант. Запуски
openclaw agent, що працюють через Gateway, також завершуються на основі результату свого запуску, тому завершені запуски не залишаються активними, доки засіб очищення не позначить їх якlost.
Доставлення та сповіщення
Коли завдання переходить у термінальний стан, OpenClaw сповіщає вас. Існує два шляхи доставлення:
Пряме доставлення — якщо завдання має цільовий канал (requesterOrigin), повідомлення про завершення надсилається безпосередньо до цього каналу (Discord, Slack, Telegram тощо). Натомість завершення групових і канальних завдань спрямовуються через сеанс запитувача, щоб батьківський агент міг написати видиму відповідь. Для завершень субагентів OpenClaw також зберігає прив’язану маршрутизацію гілки або теми, якщо вона доступна, і може заповнити відсутній to або обліковий запис зі збереженого маршруту сеансу запитувача (lastChannel / lastTo / lastAccountId), перш ніж відмовитися від прямого доставлення.
Доставлення через чергу сеансу — якщо пряме доставлення завершується помилкою або джерело не задано, оновлення додається до черги як системна подія в сеансі запитувача та відображається під час наступного Heartbeat.
Отже, звичайний робочий процес ґрунтується на надсиланні подій: один раз запустіть відокремлену роботу, а потім дозвольте середовищу виконання активувати вас або сповістити про завершення. Опитуйте стан завдання лише тоді, коли потрібні налагодження, втручання або явний аудит.
Політики сповіщень
Керуйте обсягом сповіщень про кожне завдання:
| Політика | Що доставляється |
|---|---|
done_only (типово) |
Лише термінальний стан (succeeded, failed тощо) |
state_changes |
Кожен перехід стану й кожне оновлення перебігу виконання |
silent |
Нічого (типово для завдань cron, CLI та створення медіа) |
Змініть політику під час виконання завдання:
openclaw tasks notify <lookup> state_changesДовідник CLI
tasks list
openclaw tasks list [--runtime <acp|subagent|cron|cli>] [--status <status>] [--json]Стовпці виводу: завдання, тип, стан, доставлення, запуск, дочірній сеанс, зведення. Команда openclaw tasks без аргументів працює так само, як openclaw tasks list.
tasks show
openclaw tasks show <lookup> [--json]Токен пошуку приймає ID завдання, ID запуску або ключ сеансу. Показує повний запис, зокрема час, стан доставлення, помилку та термінальне зведення.
tasks cancel
openclaw tasks cancel <lookup>Для завдань ACP і субагентів ця команда завершує дочірній сеанс; скасування ACP і cron спрямовуються через активний Gateway (tasks.cancel). Для завдань, відстежуваних через CLI, скасування записується в реєстрі завдань (окремого дескриптора дочірнього середовища виконання немає). Стан переходить у cancelled, і за потреби надсилається сповіщення.
tasks notify
openclaw tasks notify <lookup> <done_only|state_changes|silent>tasks audit
openclaw tasks audit [--severity <warn|error>] [--code <name>] [--limit <n>] [--json]Виявляє експлуатаційні проблеми завдань і TaskFlow в одному звіті. Виявлені проблеми також відображаються в openclaw status.
Результати перевірки завдань:
| Виявлена проблема | Серйозність | Умова виникнення |
|---|---|---|
stale_queued |
попередження | Перебуває в черзі понад 10 хвилин |
stale_running |
помилка | Виконується понад 30 хвилин |
lost |
попередження/помилка | Зник власник завдання в середовищі виконання; збережені втрачені завдання спричиняють попередження до cleanupAfter, а потім стають помилками |
delivery_failed |
попередження | Доставлення не вдалося, а політика сповіщень не має значення silent |
missing_cleanup |
попередження | Завершальне завдання без часової позначки очищення |
inconsistent_timestamps |
попередження | Порушення хронології (наприклад, завершення перед початком) |
Виявлені проблеми TaskFlow:
| Виявлена проблема | Серйозність | Умова виникнення |
|---|---|---|
restore_failed |
помилка | Не вдалося відновити реєстр потоків зі SQLite |
stale_running |
помилка | Виконуваний потік не просувався понад 30 хвилин |
stale_waiting |
попередження | Потік, що очікує, не просувався понад 30 хвилин |
stale_blocked |
попередження | Заблокований потік не просувався понад 30 хвилин |
cancel_stuck |
попередження | Скасування запитано понад 5 хвилин тому, активних дочірніх завдань немає, але стан усе ще не завершальний |
missing_linked_tasks |
попередження/помилка | Застарілий керований потік без пов’язаних завдань або стану очікування |
blocked_task_missing |
попередження | Заблокований потік посилається на ідентифікатор завдання, якого більше не існує |
обслуговування завдань
openclaw tasks maintenance [--json]openclaw tasks maintenance --apply [--json]Використовуйте цю команду для попереднього перегляду або застосування узгодження, установлення часових позначок очищення та видалення застарілих записів для завдань, стану TaskFlow і рядків реєстру сеансів застарілих запусків cron.
Узгодження враховує середовище виконання:
- Завдання ACP потребують активного внутрішньопроцесного ходу в Gateway; завдання підагентів перевіряють свій дочірній сеанс, що забезпечує їх виконання.
- Завдання підагентів, дочірній сеанс яких має мітку відновлення після перезапуску, позначаються як втрачені, а не вважаються сеансами виконання, які можна відновити.
- Завдання Cron перевіряють, чи середовище виконання cron досі володіє завданням, а потім відновлюють завершальний стан зі збережених журналів запусків cron або стану завдання, перш ніж установити
lost. Лише процес Gateway є авторитетним джерелом для набору активних завдань cron у пам’яті; автономний аудит CLI використовує довготривалу історію, але не позначає завдання cron як втрачене лише через те, що цей локальний набір порожній. - Завдання CLI з ідентифікатором запуску перевіряють активний контекст запуску-власника, а не лише рядки дочірнього сеансу чи сеансу чату.
Очищення після завершення також враховує середовище виконання:
- Після завершення підагента система за можливості закриває відстежувані вкладки браузера та процеси дочірнього сеансу, перш ніж продовжити очищення після оголошення.
- Після завершення ізольованого запуску cron система за можливості закриває відстежувані вкладки браузера та процеси сеансу cron до повного завершення запуску.
- Доставлення ізольованого запуску cron за потреби очікує завершення подальшої роботи дочірніх підагентів і не оголошує застарілий текст підтвердження батьківського завдання.
- Доставлення результату завершення підагента використовує лише останній видимий текст асистента з дочірнього сеансу. Виведення
tool/toolResultне переноситься до тексту результату дочірнього завдання. Завершальні невдалі запуски повідомляють про стан помилки без повторного відтворення збереженого тексту відповіді. - Помилки очищення не приховують фактичний результат завдання.
Під час застосування обслуговування OpenClaw також видаляє рядки реєстру сеансів cron:<jobId>:run:<runId>, старші за 7 днів, зберігаючи рядки для завдань cron, які виконуються зараз, і не змінюючи рядки сеансів, не пов’язаних із cron.
перелік | перегляд | скасування потоків завдань
openclaw tasks flow list [--status <status>] [--json]openclaw tasks flow show <lookup> [--json]openclaw tasks flow cancel <lookup>Токен пошуку потоку приймає ідентифікатор потоку або ключ власника. Використовуйте ці команди, коли вас цікавить оркеструвальний TaskFlow, а не окремий запис фонового завдання.
Дошка завдань чату (/tasks)
Використовуйте /tasks у будь-якому сеансі чату, щоб переглядати фонові завдання, пов’язані з цим сеансом. Дошка показує до п’яти активних і нещодавно завершених завдань із середовищем виконання, станом, часовими даними та відомостями про перебіг або помилку.
Якщо поточний сеанс не має видимих пов’язаних завдань, /tasks натомість показує локальні для агента лічильники завдань, щоб надати загальний огляд без розкриття відомостей про інші сеанси.
Для повного операторського реєстру використовуйте CLI: openclaw tasks list.
Інтерфейс керування
Вебінтерфейс керування має сторінку Tasks на бічній панелі з активними та нещодавніми фоновими завданнями, що оновлюються в реальному часі. Використовуйте її, щоб перевіряти перебіг, відкривати пов’язані сеанси, оновлювати реєстр або скасовувати завдання в черзі та завдання, що виконуються.
Панелі чату також мають згортану бічну панель Background tasks, обмежену агентом відповідної панелі: завдання та підагенти, що виконуються, з елементом керування зупинкою, розділ завершених завдань і посилання View transcript на дочірній сеанс кожного завдання. Відкрийте її за допомогою перемикача активності в заголовку панелі або плавучої кнопки активності в однопанельному чаті.
Інтеграція зі станом (навантаження завданнями)
openclaw status містить короткий рядок стану завдань:
Завдання 2 активні · 1 у черзі · 1 виконується · 1 проблема · аудит чистий · 6 відстежуютьсяЗведення підраховує активну роботу (queued + running), невдачі (failed + timed_out + lost), виявлені аудитом проблеми та загальну кількість відстежуваних записів; корисне навантаження JSON також розбиває кількість за середовищем виконання (acp, subagent, cron, cli).
І /status, і інструмент session_status використовують знімок завдань, що враховує очищення: активні завдання мають пріоритет, прострочені рядки приховуються, а завершальні завдання відображаються лише протягом короткого періоду після завершення (5 хвилин), із фокусом на помилках, коли активної роботи не залишилося. Завдяки цьому картка стану показує те, що важливо саме зараз.
Зберігання та обслуговування
Де зберігаються завдання
Записи завдань і стан доставлення зберігаються у спільній базі даних стану OpenClaw SQLite:
~/.openclaw/state/openclaw.sqlite (таблиці: task_runs, task_delivery_state, flow_runs)Установіть OPENCLAW_STATE_DIR, щоб перемістити весь кореневий каталог стану з типового розташування ~/.openclaw; шлях до спільної бази даних переміститься разом із ним.
Реєстр завантажується в пам’ять під час першого використання та зберігає кожну зміну назад у SQLite, тому записи переживають перезапуски Gateway. Зростання WAL обмежується типовим порогом автоматичних контрольних точок SQLite і періодичними контрольними точками PASSIVE; під час завершення роботи та явного обслуговування контрольні точки використовують TRUNCATE, щоб звичайне закриття звільняло простір WAL, не змушуючи фоновий засіб очищення очікувати на активних читачів.
Застарілі супровідні сховища зі старіших установок (tasks/runs.sqlite, flows/registry.sqlite) імпортуються до спільної бази даних командою openclaw doctor.
Автоматичне обслуговування
Засіб очищення запускається кожні 60 секунд (перший прохід — приблизно через 5 секунд після запуску Gateway) і виконує чотири дії:
Узгодження
Перевіряє, чи активні завдання досі мають авторитетне забезпечення середовища виконання. Завдання ACP потребують активного внутрішньопроцесного ходу, завдання підагентів використовують стан дочірнього сеансу, завдання cron — володіння активним завданням разом із довготривалою історією запусків, а завдання CLI з ідентифікатором запуску — контекст запуску-власника. Якщо стан забезпечення відсутній понад 5 хвилин (30 хвилин для нативних завдань підагентів без дочірнього сеансу), завдання позначається як lost.
Відновлення сеансів ACP
Закриває завершальні або осиротілі одноразові сеанси ACP, що належать батьківському процесу, а також закриває застарілі завершальні або осиротілі постійні сеанси ACP лише тоді, коли активної прив’язки до розмови більше немає.
Установлення часових позначок очищення
Установлює часову позначку cleanupAfter для завершальних завдань (час завершення + період зберігання). Протягом періоду зберігання втрачені завдання все ще відображаються в аудиті як попередження; після завершення строку cleanupAfter або за відсутності метаданих очищення вони стають помилками.
Видалення
Видаляє записи після дати cleanupAfter.
Зв’язок завдань з іншими системами
Завдання та TaskFlow
TaskFlow — це рівень оркестрації потоків над фоновими завданнями. Один потік може координувати кілька завдань протягом свого життєвого циклу за допомогою керованого або дзеркального режиму синхронізації. Використовуйте openclaw tasks для перевірки окремих записів завдань і openclaw tasks flow для перевірки оркеструвального потоку.
Завдання та cron
Визначення завдань Cron, стан виконання та історія запусків зберігаються у спільній базі даних стану OpenClaw SQLite. Кожне виконання cron створює запис завдання — і в основному сеансі, і в ізольованому — з політикою сповіщень silent, тому запуски cron відстежуються, але не створюють власних сповіщень про завдання.
Див. Завдання Cron.
Завдання та Heartbeat
Запуски Heartbeat є ходами основного сеансу — вони не створюють записів завдань. Після завершення завдання воно може спричинити пробудження Heartbeat, щоб ви швидко побачили результат.
Див. Heartbeat.
Завдання та сеанси
Завдання може посилатися на childSessionKey (де виконується робота) і requesterSessionKey (хто її запустив). Його agentId визначає агента, який виконує роботу, а поля запитувача та власника зберігають контекст запуску й керування. Сеанси є контекстом розмови, а завдання — рівнем відстеження активності поверх нього.
Завдання та запуски агента
runId завдання посилається на запуск агента, який виконує роботу. Події життєвого циклу агента (початок, завершення, помилка) автоматично оновлюють стан завдання — вам не потрібно керувати життєвим циклом вручну.
Пов’язані матеріали
- Автоматизація — короткий огляд усіх механізмів автоматизації
- CLI: завдання — довідник команд CLI
- Heartbeat — періодичні ходи основного сеансу
- Заплановані завдання — планування фонової роботи
- TaskFlow — оркестрація потоків над завданнями
