Skip to main content
Task Flow — це рівень оркестрації над фоновими завданнями. Потік — це довговічний запис багатоетапної роботи з власним станом, станом JSON, лічильником ревізій і пов’язаними записами завдань. Потоки зберігаються після перезапусків Gateway; окремі завдання залишаються одиницею від’єднаної роботи.

​
Коли використовувати Task Flow

​
Режими синхронізації

​
Керований режим

Керований потік має контролер: код Plugin, який створює потік через API Task Flow середовища виконання Plugin із ціллю та обов’язковим ідентифікатором контролера, а потім явно керує ним.
  • Кожен етап виконується як фонове завдання, створене в межах потоку; ключ власника потоку та походження запитувача передаються дочірнім завданням.
  • Контролер переводить потік між станами running, waiting і кінцевими станами та зберігає довільний стан етапу у форматі JSON у записі потоку.
  • Кожна зміна передає очікувану ревізію потоку. Запис із застарілою ревізією відхиляється як конфлікт ревізій, а не перезаписує новіший стан.
  • Після запиту скасування нові дочірні завдання відхиляються, а потік завершується зі станом cancelled, коли жодне дочірнє завдання більше не активне.
Приклад: потік щотижневого звіту, який (1) збирає дані, (2) створює звіт і (3) доставляє його, по одному фоновому завданню на етап:

​
Дзеркальний режим

OpenClaw автоматично створює дзеркальний потік з одним завданням, коли починається від’єднаний запуск ACP або субагента (завдання в межах сеансу з результатом, який можна доставити після завершення). Запис потоку віддзеркалює своє єдине базове завдання — стан, ціль і часові параметри — тому від’єднані запуски отримують стабільний дескриптор потоку для перегляду стану та повторних спроб без контролера. Дзеркальні потоки відображають режим синхронізації task_mirrored у CLI.

​
Стани потоків

​
Довговічний стан і відстеження ревізій

Записи потоків зберігаються у спільній базі даних стану SQLite (~/.openclaw/state/openclaw.sqlite, таблиця flow_runs) разом із записами завдань, тому прогрес зберігається після перезапусків Gateway. Кожен запис збільшує revision потоку; паралельні записувачі, які передають застарілу очікувану ревізію, отримують конфлікт і мають повторно прочитати дані. Зростання WAL обмежується автоматичними контрольними точками SQLite та періодичними пасивними контрольними точками, а під час завершення роботи застосовуються контрольні точки з усіченням. Застарілу допоміжну базу flows/registry.sqlite зі старіших установлень імпортує openclaw doctor.

​
Поведінка під час скасування

openclaw tasks flow cancel установлює для потоку постійний намір скасування, скасовує його активні дочірні завдання та забороняє нові керовані дочірні завдання. Коли жодне дочірнє завдання більше не активне, потік завершується зі станом cancelled — негайно або під час циклу обслуговування, якщо дочірнім завданням потрібно більше часу для завершення. Намір зберігається, тому скасований потік залишається скасованим, навіть якщо Gateway перезапуститься до завершення всіх дочірніх завдань.

​
Команди CLI

Потоки також перевіряються командами openclaw tasks audit (виявлення застарілих або пошкоджених потоків) і openclaw tasks maintenance (завершує завислі скасування та видаляє кінцеві потоки через 7 днів).

​
Шаблон надійного запланованого робочого процесу

Для повторюваних робочих процесів, як-от огляди ринкової аналітики, розглядайте розклад, оркестрацію та перевірки надійності як окремі рівні:
  1. Використовуйте заплановані завдання для визначення часу.
  2. Використовуйте постійний сеанс Cron, якщо робочий процес має спиратися на попередній контекст.
  3. Використовуйте Lobster для детермінованих етапів, шлюзів схвалення та токенів відновлення.
  4. Використовуйте Task Flow для відстеження багатоетапного запуску в дочірніх завданнях, очікуваннях, повторних спробах і перезапусках Gateway.
Приклад структури Cron:
Використовуйте --session session:<id> замість isolated, коли повторюваному робочому процесу потрібні свідомо збережена історія, підсумки попередніх запусків або постійний контекст. Використовуйте isolated, коли кожен запуск має починатися з чистого стану, а весь необхідний стан явно визначено в робочому процесі. У робочому процесі розміщуйте перевірки надійності перед етапом підсумовування за допомогою LLM:
Рекомендовані попередні перевірки:
  • Доступність браузера та вибір профілю, наприклад openclaw для керованого стану або user, коли потрібен автентифікований сеанс Chrome. Див. Браузер.
  • Облікові дані API та квота для кожного джерела.
  • Доступність необхідних кінцевих точок через мережу.
  • Увімкнення необхідних інструментів для агента, як-от lobster, browser і llm-task.
  • Налаштоване місце призначення для повідомлень про помилки Cron, щоб невдалі попередні перевірки були помітними. Див. Заплановані завдання.
Рекомендовані поля походження даних для кожного зібраного елемента:
Налаштуйте робочий процес так, щоб він відхиляв або позначав застарілі елементи перед підсумовуванням. Етап LLM має отримувати лише структурований JSON, і йому слід доручити зберігати sourceUrl, retrievedAt і asOf у вихідних даних. Використовуйте Завдання LLM, коли в робочому процесі потрібен етап моделі з перевіркою за схемою. Для багаторазово використовуваних командних або спільнотних робочих процесів упакуйте CLI, файли .lobster і всі примітки щодо налаштування як skill або Plugin та опублікуйте їх через ClawHub. Зберігайте специфічні для робочого процесу запобіжні обмеження в цьому пакеті, якщо тільки в API Plugin немає потрібної універсальної можливості.

​
Зв’язок потоків із завданнями

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

​
Пов’язані матеріали