English简体中文繁體中文日本語EspañolPortuguês (BR)한국어DeutschFrançaisالعربيةItalianoTiếng ViệtNederlandsTürkçeУкраїнськаBahasa IndonesiaPolskiفارسیไทย
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this pageOpen in PerplexityAsk questions about this page

Automation

Фонові завдання

Фонові завдання відстежують роботу, яка виконується поза вашим основним сеансом розмови: запуски ACP, породження субагентів, ізольовані виконання завдань Cron і операції, ініційовані з CLI.

Завдання не замінюють сеанси, завдання Cron або Heartbeat - вони є журналом активності, який записує, яка відокремлена робота відбулася, коли саме та чи була вона успішною.

TL;DR

  • Завдання - це записи, а не планувальники - Cron і Heartbeat вирішують, коли виконується робота, а завдання відстежують, що сталося.
  • ACP, субагенти, усі завдання Cron і операції CLI створюють завдання. Цикли Heartbeat цього не роблять.
  • Кожне завдання проходить через queued → running → terminal (succeeded, failed, timed_out, cancelled або lost).
  • Завдання Cron залишаються активними, доки середовище виконання Cron усе ще володіє завданням; якщо стан середовища виконання в пам’яті зник, супровід завдань спочатку перевіряє стійку історію запусків Cron, перш ніж позначити завдання як втрачене.
  • Завершення керується push-механізмом: відокремлена робота може сповіщати напряму або будити сеанс запитувача/Heartbeat після завершення, тому цикли опитування статусу зазвичай є неправильною формою.
  • Ізольовані запуски Cron і завершення субагентів у режимі best-effort прибирають відстежувані вкладки браузера/процеси для свого дочірнього сеансу перед остаточним службовим обліком очищення.
  • Ізольована доставка Cron пригнічує застарілі проміжні відповіді батьківського сеансу, доки робота нащадкового субагента ще завершується, і надає перевагу фінальному виводу нащадка, якщо він надходить до доставки.
  • Сповіщення про завершення доставляються напряму в канал або ставляться в чергу для наступного Heartbeat.
  • openclaw tasks list показує всі завдання; openclaw tasks audit виявляє проблеми.
  • Термінальні записи зберігаються 7 днів, після чого автоматично очищаються.

Швидкий старт

Список і фільтрація

bash
# List all tasks (newest first)openclaw tasks list # Filter by runtime or statusopenclaw tasks list --runtime acpopenclaw tasks list --status running

Перегляд

bash
# Show details for a specific task (by ID, run ID, or session key)openclaw tasks show <lookup>

Скасування та сповіщення

bash
# Cancel a running task (kills the child session)openclaw tasks cancel <lookup> # Change notification policy for a taskopenclaw tasks notify <lookup> state_changes

Аудит і супровід

bash
# Run a health auditopenclaw tasks audit # Preview or apply maintenanceopenclaw tasks maintenanceopenclaw tasks maintenance --apply

Потік завдання

bash
# Inspect TaskFlow stateopenclaw 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 Запуски music_generate/video_generate на основі сеансу silent
Типові сповіщення для Cron і медіа

Завдання Cron в основному сеансі типово використовують політику сповіщень silent - вони створюють записи для відстеження, але не генерують сповіщення. Ізольовані завдання Cron також типово мають silent, але вони помітніші, бо виконуються у власному сеансі.

Запуски music_generate і video_generate на основі сеансу також використовують політику сповіщень silent. Вони все одно створюють записи завдань, але завершення передається назад до початкового сеансу агента як внутрішнє пробудження, щоб агент міг сам написати наступне повідомлення та прикріпити готове медіа. Завершення в групах/каналах дотримуються звичайної політики видимої відповіді, тож агент використовує інструмент повідомлень, коли цього вимагає доставка з джерела. Якщо агент завершення не надає доказ доставки через інструмент повідомлень у маршруті лише з інструментами, OpenClaw надсилає резервне повідомлення про завершення напряму в початковий канал замість того, щоб залишити медіа приватним.

Запобіжник для одночасного video_generate

Поки завдання video_generate на основі сеансу ще активне, інструмент також працює як запобіжник: повторні виклики video_generate у тому самому сеансі повертають статус активного завдання замість запуску другого одночасного генерування. Використовуйте action: "status", коли потрібен явний перегляд прогресу/статусу з боку агента.

Що не створює завдань
  • Цикли Heartbeat - основний сеанс; див. Heartbeat
  • Звичайні інтерактивні цикли чату
  • Прямі відповіді /command

Життєвий цикл завдання

stateDiagram-v2
    [*] --> queued
    queued --> running : agent starts
    running --> succeeded : completes ok
    running --> failed : error
    running --> timed_out : timeout exceeded
    running --> cancelled : operator cancels
    queued --> lost : session gone > 5 min
    running --> lost : session gone > 5 min
Статус Що це означає
queued Створено, очікує запуску агента
running Цикл агента активно виконується
succeeded Успішно завершено
failed Завершено з помилкою
timed_out Перевищено налаштований тайм-аут
cancelled Зупинено оператором через openclaw tasks cancel
lost Середовище виконання втратило авторитетний базовий стан після 5-хвилинного пільгового періоду

Переходи відбуваються автоматично - коли пов’язаний запуск агента завершується, статус завдання оновлюється відповідно.

Завершення запуску агента є авторитетним для активних записів завдань. Успішний відокремлений запуск фіналізується як succeeded, звичайні помилки запуску фіналізуються як failed, а результати тайм-ауту або переривання фіналізуються як timed_out. Якщо оператор уже скасував завдання або середовище виконання вже записало сильніший термінальний стан, як-от failed, timed_out або lost, пізніший сигнал успіху не понижує цей термінальний статус.

lost враховує середовище виконання:

  • Завдання ACP: зникли базові метадані дочірнього сеансу ACP.
  • Завдання субагентів: базовий дочірній сеанс зник зі сховища цільового агента.
  • Завдання Cron: середовище виконання Cron більше не відстежує завдання як активне, а стійка історія запусків Cron не показує термінального результату для цього запуску. Офлайн-аудит CLI не вважає власний порожній стан середовища виконання Cron у процесі авторитетним.
  • Завдання CLI: завдання з run id/source id використовують живий контекст запуску, тому залишкові рядки дочірніх сеансів або сеансів чату не підтримують їх активними після того, як запуск, яким володіє Gateway, зникає. Застарілі завдання CLI без ідентичності запуску все ще повертаються до дочірнього сеансу. Запуски openclaw agent на основі Gateway також фіналізуються за результатом свого запуску, тому завершені запуски не залишаються активними, доки прибиральник позначить їх як lost.

Доставка та сповіщення

Коли завдання досягає термінального стану, OpenClaw сповіщає вас. Є два шляхи доставки:

Пряма доставка - якщо завдання має цільовий канал (requesterOrigin), повідомлення про завершення надходить прямо в цей канал (Telegram, Discord, Slack тощо). Завершення групових і канальних завдань натомість маршрутизуються через сеанс запитувача, щоб батьківський агент міг написати видиму відповідь. Для завершень субагентів OpenClaw також зберігає прив’язану маршрутизацію гілки/теми, коли вона доступна, і може заповнити відсутній to / обліковий запис зі збереженого маршруту сеансу запитувача (lastChannel / lastTo / lastAccountId) перед тим, як відмовитися від прямої доставки.

Доставка через чергу сеансу - якщо пряма доставка не вдається або origin не задано, оновлення ставиться в чергу як системна подія в сеансі запитувача й з’являється під час наступного Heartbeat.

Це означає, що звичайний робочий процес є push-орієнтованим: один раз запустіть відокремлену роботу, а потім дозвольте середовищу виконання розбудити вас або сповістити про завершення. Опитуйте стан завдання лише тоді, коли потрібні налагодження, втручання або явний аудит.

Політики сповіщень

Керуйте тим, скільки повідомлень ви отримуєте про кожне завдання:

Політика Що доставляється
done_only (типово) Лише термінальний стан (succeeded, failed тощо) - це типове значення
state_changes Кожен перехід стану та оновлення прогресу
silent Нічого

Змініть політику, поки завдання виконується:

bash
openclaw tasks notify <lookup> state_changes

Довідник CLI

tasks list
bash
openclaw tasks list [--runtime <acp|subagent|cron|cli>] [--status <status>] [--json]

Стовпці виводу: Task ID, Kind, Status, Delivery, Run ID, Child Session, Summary.

tasks show
bash
openclaw tasks show <lookup>

Токен пошуку приймає ID завдання, ID запуску або ключ сеансу. Показує повний запис, зокрема час, стан доставки, помилку та термінальний підсумок.

tasks cancel
bash
openclaw tasks cancel <lookup>

Для завдань ACP і субагентів це завершує дочірній сеанс. Для завдань, відстежуваних CLI, скасування записується в реєстрі завдань (окремого дочірнього дескриптора середовища виконання немає). Статус переходить у cancelled, і за потреби надсилається сповіщення доставки.

tasks notify
bash
openclaw tasks notify <lookup> <done_only|state_changes|silent>
tasks audit
bash
openclaw tasks audit [--json]

Виявляє операційні проблеми. Знахідки також з’являються в openclaw status, коли виявлено проблеми.

Виявлення Серйозність Тригер
stale_queued warn У черзі понад 10 хвилин
stale_running error Виконується понад 30 хвилин
lost warn/error Власність над завданням із runtime-підтримкою зникла; збережені втрачені завдання попереджають до cleanupAfter, а потім стають помилками
delivery_failed warn Доставлення не вдалося, а політика сповіщень не є silent
missing_cleanup warn Термінальне завдання без часової позначки очищення
inconsistent_timestamps warn Порушення часової шкали (наприклад, завершено до початку)
обслуговування завдань
bash
openclaw tasks maintenance [--json]openclaw tasks maintenance --apply [--json]

Використовуйте це для попереднього перегляду або застосування узгодження, проставлення позначок очищення та видалення застарілих записів для завдань, стану Task Flow і застарілих рядків реєстру сеансів запусків cron.

Узгодження враховує runtime:

  • Завдання ACP/subagent перевіряють свій базовий дочірній сеанс.
  • Завдання subagent, дочірній сеанс яких має tombstone відновлення після перезапуску, позначаються як втрачені замість того, щоб оброблятися як відновлювані базові сеанси.
  • Завдання Cron перевіряють, чи cron runtime все ще володіє job, а потім відновлюють термінальний статус із збережених журналів запусків cron/стану job, перш ніж переходити до lost. Лише процес Gateway є авторитетним для набору активних job cron у пам’яті; офлайн-аудит CLI використовує довговічну історію, але не позначає завдання cron як втрачене лише тому, що цей локальний Set порожній.
  • Завдання CLI з ідентичністю запуску перевіряють live-контекст запуску власника, а не лише рядки дочірнього сеансу чи chat-session.

Очищення після завершення також враховує runtime:

  • Завершення subagent на основі best-effort закриває відстежувані вкладки браузера/процеси для дочірнього сеансу до того, як очищення оголошення продовжиться.
  • Завершення ізольованого cron на основі best-effort закриває відстежувані вкладки браузера/процеси для сеансу cron до повного завершення запуску.
  • Доставлення ізольованого cron за потреби очікує на подальші дії нащадка subagent і пригнічує застарілий текст підтвердження батьківського завдання замість оголошення його.
  • Доставлення завершення subagent надає перевагу найновішому видимому тексту асистента; якщо він порожній, воно переходить до очищеного найновішого тексту tool/toolResult, а запуски лише з тайм-аутом виклику інструмента можуть згортатися до короткого підсумку часткового прогресу. Термінальні невдалі запуски оголошують статус помилки без повторного відтворення захопленого тексту відповіді.
  • Збої очищення не маскують справжній результат завдання.

Під час застосування обслуговування OpenClaw також видаляє застарілі рядки реєстру сеансів cron:<jobId>:run:<uuid>, старші за 7 днів, зберігаючи рядки для поточних запущених cron jobs і не змінюючи рядки сеансів, не пов’язані з cron.

tasks flow list | show | cancel
bash
openclaw tasks flow list [--status <status>] [--json]openclaw tasks flow show <lookup> [--json]openclaw tasks flow cancel <lookup>

Використовуйте ці команди, коли вас цікавить оркеструвальний Task Flow, а не один окремий запис фонового завдання.

Дошка завдань чату (/tasks)

Використовуйте /tasks у будь-якому сеансі чату, щоб побачити фонові завдання, пов’язані з цим сеансом. Дошка показує активні та нещодавно завершені завдання з runtime, статусом, часом і деталями прогресу або помилки.

Коли поточний сеанс не має видимих пов’язаних завдань, /tasks переходить до локальних для агента лічильників завдань, щоб ви все одно отримали огляд без розкриття деталей інших сеансів.

Для повного операційного журналу використовуйте CLI: openclaw tasks list.

Інтеграція статусу (навантаження завдань)

openclaw status містить короткий підсумок завдань:

Code
Tasks: 3 queued · 2 running · 1 issues

Підсумок повідомляє:

  • active - кількість queued + running
  • failures - кількість failed + timed_out + lost
  • byRuntime - розподіл за acp, subagent, cron, cli

І /status, і інструмент session_status використовують snapshot завдань, що враховує очищення: активним завданням надається перевага, застарілі завершені рядки приховуються, а нещодавні збої показуються лише тоді, коли активної роботи не залишилося. Це тримає картку статусу зосередженою на тому, що має значення зараз.

Зберігання та обслуговування

Де зберігаються завдання

Записи завдань зберігаються в SQLite за шляхом:

Code
$OPENCLAW_STATE_DIR/tasks/runs.sqlite

Реєстр завантажується в пам’ять під час запуску gateway і синхронізує записи в SQLite для довговічності між перезапусками. Gateway утримує журнал попереднього запису SQLite у межах, використовуючи стандартний поріг autocheckpoint SQLite, а також періодичні та завершальні checkpoints TRUNCATE.

Автоматичне обслуговування

Sweeper запускається кожні 60 секунд і виконує чотири дії:

  • Узгодження

    Перевіряє, чи активні завдання все ще мають авторитетну runtime-підтримку. Завдання ACP/subagent використовують стан дочірнього сеансу, завдання cron використовують володіння active-job, а завдання CLI з ідентичністю запуску використовують контекст запуску власника. Якщо цей базовий стан відсутній понад 5 хвилин, завдання позначається як lost.

  • Відновлення сеансів ACP

    Закриває термінальні або осиротілі одноразові сеанси ACP, якими володіє батьківський елемент, і закриває застарілі термінальні або осиротілі постійні сеанси ACP лише тоді, коли не залишається активної прив’язки розмови.

  • Проставлення позначок очищення

    Встановлює часову позначку cleanupAfter для термінальних завдань (endedAt + 7 днів). Протягом періоду зберігання втрачені завдання все ще відображаються в аудиті як попередження; після завершення cleanupAfter або коли метадані очищення відсутні, вони є помилками.

  • Видалення застарілих записів

    Видаляє записи після їхньої дати cleanupAfter.

    • Як завдання пов’язані з іншими системами

    Завдання і Task Flow

    Task Flow — це шар оркестрації потоків над фоновими завданнями. Один flow може координувати кілька завдань протягом свого життєвого циклу за допомогою керованих або дзеркальних режимів синхронізації. Використовуйте openclaw tasks, щоб перевіряти окремі записи завдань, і openclaw tasks flow, щоб перевіряти оркеструвальний flow.

    Див. Task Flow для подробиць.

    Завдання і cron

    Визначення cron job зберігається в ~/.openclaw/cron/jobs.json; стан виконання runtime зберігається поруч у ~/.openclaw/cron/jobs-state.json. Кожне виконання cron створює запис завдання — як main-session, так і ізольований. Завдання cron main-session за замовчуванням використовують політику сповіщень silent, тому вони відстежуються без створення сповіщень.

    Див. Cron Jobs.

    Завдання і heartbeat

    Запуски Heartbeat є ходами main-session — вони не створюють записів завдань. Коли завдання завершується, воно може ініціювати пробудження heartbeat, щоб ви швидко побачили результат.

    Див. Heartbeat.

    Завдання і сеанси

    Завдання може посилатися на childSessionKey (де виконується робота) і requesterSessionKey (хто його запустив). Сеанси — це контекст розмови; завдання — це відстеження активності поверх нього.

    Завдання і запуски агента

    runId завдання пов’язує його із запуском агента, який виконує роботу. Події життєвого циклу агента (start, end, error) автоматично оновлюють статус завдання — вам не потрібно керувати життєвим циклом вручну.

    Пов’язане

    Was this useful?