Как построить по‑настоящему автономного OpenClaw-агента: cron, очереди задач и Notion

Почему «поработай ночью» не работает без cron и очередей

Если просто написать агенту «разберись с этим вечером» и закрыть чат, ничего не произойдёт. Сессия живёт, пока открыт контекст и идёт диалог. Для фоновой работы OpenClaw использует встроенный cron‑планировщик Gateway: он хранит задания, будит агента в нужное время и может отправить результат обратно в чат.

Второй кирпич — очередь задач. Одна из ключевых мыслей опытных пользователей: отложенные одноразовые задачи должны жить в очереди (Notion / SQLite / текстовый файл) в паре с cron, который эту очередь регулярно проверяет. Без этого агент либо забывает задачи, либо начинает «перераздувать» память сессии.​

Дальше — пошаговый разбор: как использовать cron, как устроить очередь, как подружить всё это с Notion и собрать 2–3 реальных автономных сценария.

Cron в OpenClaw: как работает встроенный планировщик

Официальная документация описывает cron как scheduler самого Gateway: он хранит задания, будит нужного агента в нужной сессии и при желании доставляет вывод обратно в чат.

Базовая команда для добавления cron‑задачи:

bashopenclaw cron add \
  --name "Morning briefing" \
  --cron "0 8 * * *" \
  --session main \
  --message "Prepare a morning briefing for the next 24 hours and send it here." \
  --model "haiku"

Что здесь важно:

• --name — человекочитаемое имя задания.
• --cron — стандартное crontab‑выражение (минуты, часы, дни и т.д.).
• --session — сессия, в которую будет «подключён» агент.
• --message — промпт, который Gateway отправит агенту во время запуска.
• --model — модель для конкретной задачи (может отличаться от модели по умолчанию).

Полезные команды управления:

bash# Посмотреть все задания
openclaw cron list

# Запустить задание вручную (без ожидания времени)
openclaw cron run <jobId>

# Запустить только если «должно быть выполнено по расписанию»
openclaw cron run <jobId> --due

# Изменить параметры задания
openclaw cron edit <jobId> --message "Новый промпт" --model "sonnet"

# Привязать задание к конкретному агенту (в многоагентной схеме)
openclaw cron edit <jobId> --agent ops

# Удалить
openclaw cron delete <jobId>

Документация подчёркивает: cron — часть Gateway, а не отдельный системный crond. Он знает про ваши агенты, сессии и интеграции и может использовать это знание при будке агента.

Зачем нужна очередь задач (Notion, SQLite или просто файл)

Практика показывает: пользователю регулярно нужны одноразовые отложенные задачи — «через три дня напомни…», «вечером обработай вот этот список», «когда освободишься, разошли отчёты» и т.д..​

Reddit‑разборы по OpenClaw прямо говорят: такие задачи должны жить в отдельной очереди, иначе:

• они растворяются в чат‑истории,
• или вы начинаете упаковывать их в MEMORY.md и превращаете память в захламлённый лог.

Минимальная модель выглядит так:​

• Очередь (Notion / SQLite / текстовый файл) — хранит задачи с полями: id, type, payload, status, scheduled_for.
• Cron‑агент — каждые N минут проверяет очередь, выбирает задачи «на сейчас» и выполняет их.
• Агент‑исполнитель — обрабатывает задачу и меняет статус в очереди.

Реализация может быть разной — от тупого JSONL‑файла до полноценных таблиц в Notion.

Вариант 1: простая очередь в текстовом файле

Самый быстрый способ начать — обойтись без внешних сервисов.

Пример: ~/.openclaw/workspace/state/tasks_queue.jsonl:

json{"id": "2026-02-22T10:01:00_email_digest", "type": "email_digest", "run_at": "2026-02-22T19:00:00+03:00", "status": "pending"}
{"id": "2026-02-22T10:05:00_report", "type": "weekly_report", "run_at": "2026-02-23T09:00:00+03:00", "status": "pending"}

Cron‑задача:

bashopenclaw cron add \
  --name "Process local queue" \
  --cron "*/10 * * * *" \
  --session main \
  --message "Check state/tasks_queue.jsonl for pending tasks due now, execute them, and update their status."

Дальше в SKILL.md можно описать поведение:

text---
name: "Queue Processor"
triggers:
  - "process-queue"
---

# Behavior

1. Read `state/tasks_queue.jsonl`.
2. Parse each line as JSON.
3. Select tasks with `status == "pending"` and `run_at <= now`.
4. For each task:
   - Decide what to do based on `type`.
   - Execute the appropriate workflow.
   - Mark task as `status: done` and append a log entry.
5. Save updated queue back to file.

Это не самый надёжный и не масштабируемый вариант, но он иллюстрирует базовый паттерн из «7 things I wish I knew before using OpenClaw»: одной крон‑задачи, читающей очередь, достаточно для кучки одноразовых отложенных задач.​

Вариант 2: очередь в Notion — «таск‑менеджер для агента»

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

Шаг 1. Создаём интеграцию в Notion

Гайд по Notion‑интеграции рекомендует:

1. Зайти на notion.so/my-integrations.
2. Создать новую интеграцию: Name: «OpenClaw», выбрать workspace.
3. Скопировать Internal Integration Token (начинается с ntn_).
4. Поделиться нужными страницами/базами с интеграцией — по умолчанию доступ = 0.

Шаг 2. Настраиваем Notion‑skill в OpenClaw

Пример конфига из официального гайда:​

textnotion:
  enabled: true
  apiKey: "secret_xxxxxxxxxxxxxxxxxxxxx"
  defaultInbox: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"  # ID базы задач
  databases:
    tasks:    "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    notes:    "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    meetings: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    projects: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  defaults:
    tasks:
      status: "Not Started"
      priority: "Medium"
    notes:
      type: "Quick Note"

Шаг 3. Дизайн базы «Очередь задач»

Создаём в Notion базу, например «OpenClaw Queue» с полями:

• Title — краткое описание задачи.
• Type — тип (email_digest, lead_research, report, …).
• Run at — дата/время запуска.
• Status — pending, in_progress, done, error.
• Payload — дополнительные данные (ссылки, параметры).

Шаг 4. Cron‑агент, который читает и выполняет задачи

Для Notion‑очереди паттерн тот же, что и для файловой, только вместо jsonl — запрос к Notion API:

bashopenclaw cron add \
  --name "Notion queue processor" \
  --cron "*/15 * * * *" \
  --session main \
  --message "Query Notion tasks database for items with Status = 'pending' and Run at <= now, execute them, and update their Status."
  --model "haiku"

Внутри скилла:

1. Вызвать Notion API: POST /databases/DATABASE_ID/query с фильтром Status != Done, Run at <= today.​
2. Для каждой задачи:
   • Определить сценарий из поля Type.
   • Выполнить нужный workflow (написать письмо, собрать отчёт, сделать ресёрч).
   • Обновить строку в Notion: Status = Done, добавить комментарий.

Такой подход даёт приятный бонус: вы видите очередь и историю в привычном интерфейсе Notion, а агент просто «подчищает» её по расписанию.

Реальный сценарий №1: утренний брифинг + задачи из Notion

Комбинируем всё вместе:

1. Notion — база «Tasks» с задачами и статусами.
2. HEARTBEAT.md — описание, что брифинг должен включать погоду, календарь, задачи.
3. Cron — один job в 8:00, который инициирует брифинг:

bashopenclaw cron add \
  --name "Morning briefing" \
  --cron "0 8 * * *" \
  --session main \
  --message "Prepare a morning briefing: weather, next 24h events, and top 5 overdue Notion tasks with suggestions." \
  --model "haiku"

4. Notion‑skill — умеет дергать базу задач и формировать список «overdue».

Такой сценарий описан и в официальных материалах как типичный use case: Notion‑база задач + OpenClaw‑агент, который по расписанию вытаскивает просрочки и помогает приоритизировать.

Реальный сценарий №2: мониторинг конкурентов и уведомления

В примерах реальных воркфлоу для OpenClaw есть кейс мониторинга цен конкурентов. Паттерн:​

1. Вы задаёте: «Следи за страницами competitor1.com/pricing, competitor2.com/plans и competitor3.com/pricing каждые 4 часа. Пиши в Slack, если цена меняется больше чем на 5%.».​
2. OpenClaw с помощью браузерных инструментов по cron открывает страницы, снимает текущую цену, сравнивает с предыдущими значениями и шлёт уведомление только при значимых изменениях.​

Аналогичный принцип можно использовать для любого e‑commerce‑кейса:

• Конкурентные цены на маркетплейсах.
• Наличие SKU у конкурентов.
• Скидки/акции на конкретные категории.

Cron здесь отвечает за частоту, а state — за хранение предыдущих значений, с которыми сравниваем.

Реальный сценарий №3: автоотчёты и скриншоты дашбордов

Ещё один показательный кейс из обзора воркфлоу: еженедельные отчёты с дашбордов.​

Паттерн:

1. Раз в неделю cron‑задача будит агента.
2. Агент:
   • Логинится на аналитический дашборд (через browser automation).
   • Делает скриншоты ключевых экранов (weekly overview, traffic, funnel).​
   • Формирует краткое текстовое резюме.
   • Шлёт всё в Slack/Telegram — вам или команде.​

Это уже «тяжёлый» workflow по часам агента, но со стороны разработчика это просто один cron + хороший SKILL.md.

Реальный сценарий №4: «умный» дом и контекстные действия

Блоги и статьи по OpenClaw описывают кейсы, где агент:

• Настраивает отопление с учётом погоды и расписания.​
• Управляет светом и устройствами по времени суток и активности.​
• Реагирует на события (камера, датчики) и триггерит действия.​​

Типичный паттерн:

1. Home Assistant даёт API для состояния устройств.
2. OpenClaw через cron и/или webhooks проверяет состояние (температура, присутствие, прогноз).​
3. При определённых правилах (холодно, никого нет, скоро выезд) — принимает решения.

Эксперты по безопасности подчёркивают: ограничивайте список entities для агентов и не давайте весь дом сразу. Лучше несколько специализированных агентов с узким доступом.​

Многоагентные сценарии: когда один агент дирижирует другими

В обзорах использования OpenClaw всё чаще всплывает паттерн «dream team» — несколько специализированных агентов, которыми управляет оркестратор.​

Видео‑демо описывает схему:​

• Оркестратор принимает задачу (например: «нужен механизм ретраев для сервиса»).
• «Builder» генерирует реализацию.
• «Reviewer» делает ревью, проверяет тесты.
• «Deployer» отвечает за деплой.
• Оркестратор координирует и присылает вам результат.

С точки зрения cron и очередей:

• Очередь задач — список больших задач (features, интеграции).
• Cron оркестратора — периодически поднимает следующее задание в работу.
• Субагенты — выполняют свою роль и отчитываются.

Этот паттерн — следующий шаг после простых cron‑тасков и утренних брифингов. Документы по cron прямо показывают, как задания можно «привязывать» к отдельным агентам (--agent ops) в multi‑agent‑сетапах.

Частые грабли при построении автономных воркфлоу

Суммируя практику комьюнити и официальные рекомендации:

• Грабли №1: «Слишком много cron»
  Каждый новый workflow = отдельный cron. Через неделю никто не помнит, что за что отвечает. Лучше меньше заданий + умные heartbeat‑проверки и очередь.
• Грабли №2: Нет очереди
  Отложенные задачи живут в голове пользователя и кусках переписки. Результат — забытые задачи и хаос в памяти агента. Очередь (даже текстовый файл) решает это.
• Грабли №3: Всё на одной модели
  Утренняя сводка и тяжёлый ресёрч гонятся через один и тот же Opus/GPT‑5. Счёт растёт, а задачи, для которых хватило бы дешёвой модели, «переплачены» в разы.​
• Грабли №4: Агент с полным доступом к дому и продам
  Без ограничений по Home Assistant и прод‑инфраструктуре агент может случайно сделать «очень много лишнего». Документация и кейсы по безопасности советуют жёстко ограничивать доступные сущности.