--- read_when: - Вы хотите понять, как Task Flow связан с фоновыми задачами - Вы встречаете Task Flow или openclaw tasks flow в примечаниях к выпуску или документации - Вы хотите проверить или управлять сохраняемым состоянием потока summary: Уровень оркестрации Task Flow над фоновыми задачами title: Поток задач x-i18n: generated_at: "2026-07-13T19:29:35Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 24 provider: openai source_hash: 5ccc6acf58b4b44c2989e3061bff08dabce8ef385706102360c756a1286ddd1b source_path: automation/taskflow.md workflow: 16 --- Поток задач — это уровень оркестрации над [фоновыми задачами](/ru/automation/tasks). Поток представляет собой долговечную запись многоэтапной работы с собственным статусом, состоянием JSON, счётчиком ревизий и связанными записями задач. Потоки сохраняются при перезапусках Gateway; отдельные задачи остаются единицей обособленной работы. ## Когда использовать поток задач | Сценарий | Использование | | ----------------------------------------------- | ------------------------------------------------------- | | Одиночное фоновое задание | Обычная задача | | Многоэтапный конвейер под управлением кода плагина | Поток задач (управляемый) | | Обособленный запуск ACP или субагента | Поток задач (зеркальный, создаётся автоматически) | | Однократное напоминание | Задание Cron | ## Режимы синхронизации ### Управляемый режим Управляемый поток имеет контроллер: код плагина, который создаёт поток через API потока задач среды выполнения плагина, указывая цель и обязательный идентификатор контроллера, а затем явно управляет им. - Каждый этап выполняется как фоновая задача, созданная в рамках потока; ключ владельца потока и источник инициатора передаются дочерним задачам. - Контроллер переводит поток между состояниями `running`, `waiting` и конечными состояниями, а также сохраняет произвольное состояние этапа в формате JSON в записи потока. - При каждой мутации передаётся ожидаемая ревизия потока. Запись с устаревшей ревизией отклоняется из-за конфликта ревизий, а не перезаписывает более новое состояние. - После запроса отмены новые дочерние задачи отклоняются, а поток завершается со статусом `cancelled`, когда не остаётся активных дочерних задач. Пример: поток еженедельного отчёта, который (1) собирает данные, (2) формирует отчёт и (3) доставляет его, используя по одной фоновой задаче на этап: ``` Поток: weekly-report Этап 1: gather-data → задача создана → успешно завершена Этап 2: generate-report → задача создана → успешно завершена Этап 3: deliver → задача создана → выполняется ``` ### Зеркальный режим OpenClaw автоматически создаёт зеркальный поток с одной задачей при запуске обособленного выполнения ACP или субагента (задачи уровня сеанса с доставляемым результатом). Запись потока зеркально отражает единственную базовую задачу — её статус, цель и временные показатели, — поэтому обособленные запуски получают стабильный дескриптор потока для просмотра статуса и повторных попыток без контроллера. В CLI для зеркальных потоков отображается режим синхронизации `task_mirrored`. ## Статусы потоков | Статус | Значение | | ----------- | -------------------------------------------------------------------------- | | `queued` | Создан, выполнение ещё не началось | | `running` | Поток активно выполняется | | `waiting` | Управляемый поток приостановлен согласно метаданным ожидания (таймер, внешнее событие) | | `blocked` | Этап завершился без пригодного результата; `blockedTaskId`/сводка указывают, какой именно | | `succeeded` | Успешно завершён | | `failed` | Завершён с ошибкой | | `cancelled` | Запрошена отмена, и все дочерние задачи завершены | | `lost` | Поток потерял своё авторитетное базовое состояние | ## Долговечное состояние и отслеживание ревизий Записи потоков сохраняются в общей базе данных состояния SQLite (таблица `~/.openclaw/state/openclaw.sqlite`, `flow_runs`) вместе с записями задач, поэтому прогресс сохраняется при перезапусках Gateway. Каждая запись увеличивает `revision` потока; параллельные процессы записи, передавшие устаревшую ожидаемую ревизию, получают конфликт и должны повторно прочитать данные. Рост WAL ограничивается автоматическими контрольными точками SQLite и периодическими пассивными контрольными точками, а при завершении работы выполняются контрольные точки с усечением. Устаревший вспомогательный файл `flows/registry.sqlite` из старых установок импортируется командой `openclaw doctor`. ## Поведение при отмене `openclaw tasks flow cancel` устанавливает для потока сохраняемое намерение отмены, отменяет его активные дочерние задачи и запрещает создание новых управляемых дочерних задач. Когда активных дочерних задач не остаётся, поток завершается со статусом `cancelled` — немедленно либо во время служебного прохода, если дочерним задачам требуется больше времени для завершения. Намерение сохраняется, поэтому отменённый поток остаётся отменённым, даже если Gateway перезапустится до завершения всех дочерних задач. ## Команды CLI ```bash # Вывести активные и недавние потоки openclaw tasks flow list [--status ] [--json] # Показать сведения об определённом потоке openclaw tasks flow show [--json] # Отменить выполняющийся поток и его активные задачи openclaw tasks flow cancel ``` | Команда | Описание | | --------------------------------- | ----------------------------------------------------------------------- | | `openclaw tasks flow list` | Отслеживаемые потоки с режимом синхронизации, статусом, ревизией, контроллером и количеством задач | | `openclaw tasks flow show ` | Просмотреть один поток по идентификатору потока или ключу владельца, включая связанные задачи | | `openclaw tasks flow cancel ` | Отменить выполняющийся поток и его активные задачи | Потоки также проверяются командами `openclaw tasks audit` (выявляет устаревшие или повреждённые потоки) и `openclaw tasks maintenance` (завершает зависшие отмены и удаляет конечные потоки через 7 дней). ## Шаблон надёжного запланированного рабочего процесса Для повторяющихся рабочих процессов, таких как сводки рыночной аналитики, рассматривайте расписание, оркестрацию и проверки надёжности как отдельные уровни: 1. Используйте [запланированные задачи](/ru/automation/cron-jobs) для управления временем запуска. 2. Используйте постоянный сеанс Cron, если рабочий процесс должен опираться на предыдущий контекст. 3. Используйте [Lobster](/ru/tools/lobster) для детерминированных этапов, шлюзов подтверждения и токенов возобновления. 4. Используйте поток задач для отслеживания многоэтапного выполнения, включая дочерние задачи, ожидания, повторные попытки и перезапуски Gateway. Пример конфигурации Cron: ```bash 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:` вместо `isolated`, если повторяющемуся рабочему процессу необходима целенаправленно сохраняемая история, сводки предыдущих запусков или постоянный контекст. Используйте `isolated`, если каждый запуск должен начинаться с чистого состояния, а всё необходимое состояние явно задано в рабочем процессе. Внутри рабочего процесса размещайте проверки надёжности перед этапом создания сводки с помощью LLM: ```yaml name: market-intel-brief steps: - 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. См. раздел [«Браузер»](/ru/tools/browser). - Учётные данные API и квота для каждого источника. - Сетевая доступность необходимых конечных точек. - Необходимые инструменты включены для агента, например `lobster`, `browser` и `llm-task`. - Для Cron настроено место назначения при сбое, чтобы ошибки предварительных проверок были видны. См. раздел [«Запланированные задачи»](/ru/automation/cron-jobs#delivery-and-output). Рекомендуемые поля происхождения данных для каждого собранного элемента: ```json { "sourceUrl": "https://example.com/report", "retrievedAt": "2026-04-24T12:00:00Z", "asOf": "2026-04-24", "title": "Пример отчёта", "content": "..." } ``` Настройте рабочий процесс так, чтобы он отклонял или помечал устаревшие элементы до создания сводки. Этап LLM должен получать только структурированный JSON, и ему следует указать сохранять `sourceUrl`, `retrievedAt` и `asOf` в выходных данных. Используйте [задачу LLM](/ru/tools/llm-task), когда внутри рабочего процесса необходим этап модели с проверкой по схеме. Для многократно используемых командных или общественных рабочих процессов упакуйте CLI, файлы `.lobster` и все инструкции по настройке в виде Skills или плагина и опубликуйте их через [ClawHub](/ru/clawhub). Храните защитные ограничения конкретного рабочего процесса в этом пакете, если только в API плагина не отсутствует необходимая универсальная возможность. ## Связь потоков с задачами Потоки координируют задачи, а не заменяют их. Один поток может управлять несколькими фоновыми задачами на протяжении своего жизненного цикла. Используйте `openclaw tasks` для просмотра отдельных записей задач и `openclaw tasks flow` для просмотра оркестрирующего потока. ## Связанные материалы - [Фоновые задачи](/ru/automation/tasks) — журнал обособленной работы, которую координируют потоки - [CLI: задачи](/ru/cli/tasks) — справочник команд CLI для `openclaw tasks flow` - [Обзор автоматизации](/ru/automation) — краткий обзор всех механизмов автоматизации - [Задания Cron](/ru/automation/cron-jobs) — запланированные задания, которые могут передавать работу потокам