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

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

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

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

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

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

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 audit (выявляет устаревшие или повреждённые потоки) и openclaw tasks maintenance (завершает зависшие отмены и удаляет конечные потоки через 7 дней).

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

Для повторяющихся рабочих процессов, таких как сводки рыночной аналитики, рассматривайте расписание, оркестрацию и проверки надёжности как отдельные уровни:
  1. Используйте запланированные задачи для управления временем запуска.
  2. Используйте постоянный сеанс Cron, если рабочий процесс должен опираться на предыдущий контекст.
  3. Используйте Lobster для детерминированных этапов, шлюзов подтверждения и токенов возобновления.
  4. Используйте поток задач для отслеживания многоэтапного выполнения, включая дочерние задачи, ожидания, повторные попытки и перезапуски 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 и все инструкции по настройке в виде Skills или плагина и опубликуйте их через ClawHub. Храните защитные ограничения конкретного рабочего процесса в этом пакете, если только в API плагина не отсутствует необходимая универсальная возможность.

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

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

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