Поток задач

Поток задач — это уровень оркестрации над фоновыми задачами. Поток представляет собой долговечную запись многоэтапной работы с собственным статусом, состоянием JSON, счётчиком ревизий и связанными записями задач. Потоки сохраняются при перезапусках Gateway; отдельные задачи остаются единицей обособленной работы.

Когда использовать поток задач

Режимы синхронизации

Управляемый режим

Управляемый поток имеет контроллер: код плагина, который создаёт поток через API потока задач среды выполнения плагина, указывая цель и обязательный идентификатор контроллера, а затем явно управляет им.

• Каждый этап выполняется как фоновая задача, созданная в рамках потока; ключ владельца потока и источник инициатора передаются дочерним задачам.
• Контроллер переводит поток между состояниями running, waiting и конечными состояниями, а также сохраняет произвольное состояние этапа в формате JSON в записи потока.
• При каждой мутации передаётся ожидаемая ревизия потока. Запись с устаревшей ревизией отклоняется из-за конфликта ревизий, а не перезаписывает более новое состояние.
• После запроса отмены новые дочерние задачи отклоняются, а поток завершается со статусом cancelled, когда не остаётся активных дочерних задач.

Пример: поток еженедельного отчёта, который (1) собирает данные, (2) формирует отчёт и (3) доставляет его, используя по одной фоновой задаче на этап:

Поток: weekly-report  Этап 1: gather-data     → задача создана → успешно завершена  Этап 2: generate-report → задача создана → успешно завершена  Этап 3: deliver         → задача создана → выполняется

Зеркальный режим

OpenClaw автоматически создаёт зеркальный поток с одной задачей при запуске обособленного выполнения ACP или субагента (задачи уровня сеанса с доставляемым результатом). Запись потока зеркально отражает единственную базовую задачу — её статус, цель и временные показатели, — поэтому обособленные запуски получают стабильный дескриптор потока для просмотра статуса и повторных попыток без контроллера. В CLI для зеркальных потоков отображается режим синхронизации task_mirrored.

Статусы потоков

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

Записи потоков сохраняются в общей базе данных состояния 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 flow list [--status <status>] [--json] # Показать сведения об определённом потокеopenclaw tasks flow show <lookup> [--json] # Отменить выполняющийся поток и его активные задачиopenclaw tasks flow cancel <lookup>

Потоки также проверяются командами openclaw tasks audit (выявляет устаревшие или повреждённые потоки) и openclaw tasks maintenance (завершает зависшие отмены и удаляет конечные потоки через 7 дней).

Шаблон надёжного запланированного рабочего процесса

Для повторяющихся рабочих процессов, таких как сводки рыночной аналитики, рассматривайте расписание, оркестрацию и проверки надёжности как отдельные уровни:

1. Используйте запланированные задачи для управления временем запуска.
2. Используйте постоянный сеанс Cron, если рабочий процесс должен опираться на предыдущий контекст.
3. Используйте Lobster для детерминированных этапов, шлюзов подтверждения и токенов возобновления.
4. Используйте поток задач для отслеживания многоэтапного выполнения, включая дочерние задачи, ожидания, повторные попытки и перезапуски Gateway.

Пример конфигурации Cron:

openclaw cron add \  --name "Сводка рыночной аналитики" \  --cron "0 7 * * 1-5" \  --tz "America/New_York" \  --session session:market-intel \  --message "Запустите рабочий процесс Lobster market-intel. Перед созданием сводки проверьте актуальность источников." \  --announce \  --channel slack \  --to "channel:C1234567890"

Используйте --session session:<id> вместо isolated, если повторяющемуся рабочему процессу необходима целенаправленно сохраняемая история, сводки предыдущих запусков или постоянный контекст. Используйте isolated, если каждый запуск должен начинаться с чистого состояния, а всё необходимое состояние явно задано в рабочем процессе.

Внутри рабочего процесса размещайте проверки надёжности перед этапом создания сводки с помощью LLM:

name: market-intel-briefsteps:  - id: preflight    command: market-intel check --json  - id: collect    command: market-intel collect --json    stdin: $preflight.json  - id: summarize    command: market-intel summarize --json    stdin: $collect.json  - id: approve    command: market-intel deliver --preview    stdin: $summarize.json    approval: required  - id: deliver    command: market-intel deliver --execute    stdin: $summarize.json    condition: $approve.approved

Рекомендуемые предварительные проверки:

• Доступность браузера и выбор профиля, например openclaw для управляемого состояния или user, когда требуется авторизованный сеанс Chrome. См. раздел «Браузер».
• Учётные данные API и квота для каждого источника.
• Сетевая доступность необходимых конечных точек.
• Необходимые инструменты включены для агента, например lobster, browser и llm-task.
• Для Cron настроено место назначения при сбое, чтобы ошибки предварительных проверок были видны. См. раздел «Запланированные задачи».

Рекомендуемые поля происхождения данных для каждого собранного элемента:

{  "sourceUrl": "https://example.com/report",  "retrievedAt": "2026-04-24T12:00:00Z",  "asOf": "2026-04-24",  "title": "Пример отчёта",  "content": "..."}

Настройте рабочий процесс так, чтобы он отклонял или помечал устаревшие элементы до создания сводки. Этап LLM должен получать только структурированный JSON, и ему следует указать сохранять sourceUrl, retrievedAt и asOf в выходных данных. Используйте задачу LLM, когда внутри рабочего процесса необходим этап модели с проверкой по схеме.

Для многократно используемых командных или общественных рабочих процессов упакуйте CLI, файлы .lobster и все инструкции по настройке в виде Skills или плагина и опубликуйте их через ClawHub. Храните защитные ограничения конкретного рабочего процесса в этом пакете, если только в API плагина не отсутствует необходимая универсальная возможность.

Связь потоков с задачами

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

Связанные материалы

• Фоновые задачи — журнал обособленной работы, которую координируют потоки
• CLI: задачи — справочник команд CLI для openclaw tasks flow
• Обзор автоматизации — краткий обзор всех механизмов автоматизации
• Задания Cron — запланированные задания, которые могут передавать работу потокам