Коротко
- Ассистент в мессенджере и оркестратор десятка агентов у OpenClaw запускаются одним и тем же процессом Gateway. Разница в настройках.
- Оркестратором его делают шесть механизмов: расписания, изолированные агенты, вложенные субагенты, реестр задач, внешние кодовые агенты и полномочия для работы без присмотра.
- Если нужен replay после сбоя, жёсткий потолок расходов или изоляция между клиентами, берите другой инструмент. Список ниже.
OpenClaw привыкли считать чат-ботом: пишешь ему в Telegram, он отвечает и что-то делает на твоём компьютере. Так его подаёт и сам проект. Слоган на главной странице документации звучит так: «Your AI assistant, on your own hardware, in every chat app you already use», то есть «ваш ИИ-ассистент, на вашем железе, в каждом мессенджере, которым вы уже пользуетесь».
Но через пару абзацев там же сказано главное: тот же Gateway работает как личный ассистент на одном ноутбуке или как общий сервер команды, и «configuration is the only difference», отличается только конфигурация. Gateway здесь означает постоянно работающий процесс OpenClaw, который держит каналы, агентов, расписания и состояние.
Наш тезис: OpenClaw — постоянно работающий рантайм для оркестрации агентов, и ассистент в нём только самая простая конфигурация. Рантайм (runtime) означает среду, в которой агенты живут и исполняются, в отличие от фреймворка, который вы импортируете в свой код. Ниже шесть механизмов, которые это доказывают, одна схема и один пайплайн. В конце честно: когда OpenClaw брать не надо.
Если слово «агент» для вас пока туманно, начните с материала «Агент — это цикл, а не магия». Про разницу между заранее заданным процессом и агентом, который сам выбирает шаги, мы писали в «Пяти схемах».
Почему это рантайм, а не фреймворк
Фреймворк устроен как библиотека: вы пишете программу, в которой агенты вызываются как функции. Рантайм запущен всегда. В нём уже есть сессии, каналы, расписания и хранилище состояния, а агенты работают внутри него.
Так устроены все постоянно работающие агентные системы. Исследование исходного кода одиннадцати кодовых агентов (arXiv 2609.00006, июль 2026, OpenClaw в выборке есть) отмечает: ни один из них не импортирует универсальный агентный фреймворк. Значит, само слово «рантайм» OpenClaw ещё не выделяет. Выделяет его то, что в этот рантайм встроено для оркестрации.
Документация проводит ту же линию. На странице про Swarm, режим параллельного запуска многих агентов, написано: «There is no graph DSL and no separate workflow format. The program is the orchestration». Отдельного языка графов и формата workflow нет, оркестрация задаётся самой программой.
Шесть механизмов
1. Расписания и события: агент работает, когда никто не пишет
Ассистент отвечает на сообщения. Оркестратор просыпается сам. Для этого в OpenClaw есть встроенный планировщик: команда openclaw automations (старое имя openclaw cron осталось алиасом). Планировщик сохраняет задания и сам будит агента в нужное время.
Виды расписаний по документации: разовое at, интервал every, cron-выражение с часовым поясом --cron … --tz, запуск после завершения другого процесса on-exit и поток строк из внешней команды stream. Есть условный наблюдатель trigger.script. Это маленький скрипт, который раз в интервал (не чаще чем раз в 30 секунд) решает, будить ли модель, и возвращает { fire, message?, state? }. Пока повода нет, модель не вызывается. Снаружи агента будят вебхуки: POST /hooks/wake и POST /hooks/agent, по умолчанию выключены.
Задание можно направить в постоянную сессию --session session:<id>, тогда каждый запуск видит историю прошлых. Для запусков без человека в документации есть отдельный контракт: ответ должен быть готовым результатом, а если делать нечего, агент возвращает NO_REPLY и в чат ничего не уходит.
Что это даёт в пайплайне: точку входа без человека. Пайплайн стартует по времени или по событию, а тихие прогоны не засоряют канал.
2. Изолированные агенты: команда в одном процессе
Один Gateway держит несколько агентов. У каждого свой рабочий каталог (workspace), свой каталог состояния agentDir и своя история сессий в SQLite. Привязки (bindings) решают, какой агент отвечает в каком канале или аккаунте. Документация подчёркивает, что они детерминированы: побеждает самое точное совпадение, модель в выборе не участвует.
Команды: openclaw agents add work --workspace … --model … --bind telegram:work, проверка через openclaw agents list --bindings. Готовый каркас команды из четырёх ролей (coordinator, researcher, writer, reviewer) создаёт openclaw agents team create. Писать друг другу агенты могут по умолчанию, это регулирует tools.agentToAgent.
Одна оговорка из документации: workspace — каталог по умолчанию, а не песочница. Изоляция здесь про контекст и память, а не про безопасность.
Что это даёт в пайплайне: роли с разной моделью, разной памятью и своим каналом, у каждого свой ограниченный контекст. Как нарезать агентов по областям, мы разбирали в статье «Один агент на одну область».
3. Вложенные субагенты с каскадной остановкой
Субагентом называют дочернего агента, которого родитель запускает на подзадачу инструментом sessions_spawn. Вызов не блокирует родителя: он сразу получает {status: "accepted", runId, childSessionKey}, а результат ребёнка приходит позже событием завершения (announce). Документация прямо советует ждать этих событий, а не опрашивать детей в цикле.
Дерево ограничено параметрами. maxSpawnDepth задаёт глубину, по умолчанию 5, это и максимум. maxChildrenPerAgent ограничивает число детей у одного родителя: по умолчанию 5, можно до 20. maxConcurrent держит общий параллелизм, по умолчанию 8. Результаты поднимаются по дереву на один уровень за раз. У листа на последнем уровне нет инструментов, чтобы запустить своих детей.
Остановка каскадная: явная отмена оркестратора гасит всё дерево его потомков, /stop в чате делает то же для того, кто его отправил. Если очередь недоставленных результатов дорастёт до 25, OpenClaw предупредит, при 50 перестанет запускать новых детей.
Что это даёт в пайплайне: веерный разбор задачи. Координатор раздаёт куски исполнителям на дешёвой модели, собирает ответы и может остановить всю ветку одной командой.
4. Реестр задач, который переживает рестарт
Каждый отсоединённый запуск (субагент, внешний агент, задание по расписанию) попадает в реестр задач. Документация называет его журналом активности, а не планировщиком. Путь задачи: в очереди, выполняется и один из пяти исходов — успех, ошибка, таймаут, отмена или потеря. Команды: openclaw tasks list, show, cancel, retry, audit.
Над задачами есть Task Flow, «durable record», долговечная запись процесса: статус, состояние в stateJson, счётчик ревизий revision. Для каждого отсоединённого субагента или ACP-запуска flow создаётся автоматически. Записи лежат в SQLite и переживают рестарт Gateway. Смотреть их можно через openclaw tasks flow list и show.
Субагенты после рестарта продолжают работу со своего транскрипта. Если ребёнок падает снова и снова, его останавливает защитная отметка (recovery tombstone), и бесконечного цикла восстановления не будет.
Что это даёт в пайплайне: видно, что сейчас крутится, что упало и что можно перезапустить. Перезагрузка сервера не обнуляет работу.
Предел этой долговечности документация называет сама, и мы вернёмся к нему в разделе про ограничения.
5. Внешние кодовые агенты в роли подчинённых
Через протокол ACP (Agent Client Protocol, общий протокол подключения кодовых агентов к внешней «обвязке») OpenClaw запускает чужих агентов как своих детей. По документации это Claude Code, Cursor, Copilot, Gemini CLI, OpenCode и другие. Вызов тот же: sessions_spawn с runtime: "acp" или /acp spawn из чата. Каждый такой запуск тоже фоновая задача в реестре. Codex по умолчанию подключается через собственный плагин, ACP для него запасной путь.
Чтобы параллельные агенты не топтались в одном каталоге, есть управляемые git-worktree, отдельные рабочие копии репозитория: openclaw worktrees create <repo> --name <name> создаёт ветку openclaw/<name>. ACP-сессии этот каталог передаётся параметром cwd.
Две оговорки. Флаг worktree: true в sessions_spawn работает только для обычных субагентов с visible: true, для ACP он не подходит. И песочница OpenClaw ACP-агента не оборачивает, так сказано в документации дословно.
Что это даёт в пайплайне: тяжёлые правки кода делает специализированный агент, а OpenClaw ставит задачу, следит за статусом и доставляет результат.
6. Полномочия для работы без присмотра
Когда человек рядом, он жмёт «разрешить». В 7 утра в понедельник рядом никого нет. Для этого в OpenClaw несколько слоёв.
Режимы разрешений Gateway: read-only, guarded (решает человек), workspace (решает LLM-ревьюер: разрешить, запретить или спросить; после трёх отказов подряд вопрос уходит человеку) и full. Если ничего не настроить и не включить песочницу, по умолчанию действует полный доступ.
Для заданий по расписанию есть постоянные разрешения (standing grants). Запросы на выполнение команд из automation получают только подключённые клиенты одобрений: Control UI (веб-панель управления Gateway) и приложения. В чат-каналы, по документации, такие запросы не приходят никогда. Если клиента нет, запрос сразу отклоняется. Кнопка «Always allow» создаёт грант, привязанный к конкретному агенту, заданию, команде и каталогу. Список и отзыв: openclaw approvals grants list и openclaw approvals grants revoke <id>.
У ACP свои настройки. По умолчанию permissionMode = approve-reads: чтение разрешено, запись и запуск команд требуют подтверждения. А nonInteractivePermissions = fail, и без интерактивного терминала сессия падает с PermissionPromptUnavailableError. Мягкий вариант deny тихо отказывает и работает дальше.
Правила поведения агента в автономном режиме пишутся прямо в AGENTS.md как постоянные распоряжения (standing orders): область, триггеры, где нужно одобрение, кому эскалировать.
Что это даёт в пайплайне: заранее решаете, что агент делает сам, а что ждёт человека. Решение живёт в конфигурации, а не в надежде, что модель спросит. Подробнее, что выносить в обвязку, а что оставлять модели, в статье «Что выносить в обвязку агента».
Схема: ассистент и оркестратор на одном Gateway
┌──────────────────── Gateway (один процесс) ────────────────────┐
│ │
Сообщение в чате ──►│ binding ──► агент main ──► ответ в чат (ассистент) │
│ │
Расписание / хук ──►│ automation ──► session:<id> координатора (оркестратор) │
│ │ │
│ ├─► субагенты (глубина до 5, стоп каскадом) │
│ ├─► ACP: Claude Code / Codex в worktree │
│ │ │
│ реестр задач + Task Flow (SQLite, переживает рестарт) │
│ полномочия: permission mode, grants, ACP permissionMode │
└────────────────────────────────────────────────────────────────┘
│ итог: --announce в канал, одобрения в Control UI| Ассистент | Оркестратор | |
|---|---|---|
| Кто запускает | Человек сообщением | Расписание, вебхук, наблюдатель |
| Сколько агентов | Один main |
Несколько через agents add и субагенты |
| Где контекст | Одна сессия в чате | Постоянная session:<id> плюс изолированные дети |
| Кто пишет код | Сам агент | ACP-агент в отдельном worktree |
| Как видно состояние | Переписка | openclaw tasks list, tasks flow show |
| Кто одобряет | Человек в чате, сразу | Заранее: режим, гранты; остальное в Control UI |
Процесс, база и каналы у обеих колонок одни и те же.
Пример: еженедельное обновление документации проекта
Задача условная: у небольшой команды есть репозиторий, раз в неделю нужно собрать, что изменилось, и обновить документацию. Команды ниже собраны по документации, адреса и имена вымышлены.
- Триггер. Задание по расписанию будит координатора в пятницу утром в его постоянной сессии:
Если за неделю ничего не изменилось, координатор отвечаетopenclaw automations add --name docs-weekly \ --cron "0 8 * * 5" --tz Europe/Moscow \ --session session:docs-weekly \ --message "Собери изменения за неделю и обнови документацию" \ --announce --channel telegram --to "<id чата>"NO_REPLYи в чат ничего не приходит. - Сбор. Координатор запускает двух-трёх субагентов через
sessions_spawn, каждого со своей частью источников и, если нужно, более дешёвой моделью (model). Ждёт событий завершения, а не опрашивает. - Правка. Координатор отдаёт сводку ACP-агенту:
sessions_spawnсruntime: "acp"иcwd, указывающим на worktree. Worktree заранее создан командойopenclaw worktrees create <repo> --name docs-weekly, правки уходят в веткуopenclaw/docs-weekly. Чтобы агент мог писать файлы без человека, для ACP сознательно выставляется подходящийpermissionMode. Иначе сессия упадёт на первой записи. - Контроль. Каждый запуск виден в
openclaw tasks list, для ACP-запуска автоматически есть flow вopenclaw tasks flow list. Если Gateway перезапустился посреди работы, субагенты продолжат со своего транскрипта. - Человек. Итог уходит в канал через
--announce. Ветку сливает человек. Если по дороге понадобится команда вне выданных грантов, запрос придёт в Control UI, а не в мессенджер.
Человек стоит в двух местах: заранее, когда выдаёт полномочия, и в конце, на слиянии.
Когда брать не OpenClaw
| Нужно | Что брать | Почему |
|---|---|---|
| Долгий процесс, который после сбоя продолжится ровно с того места | Temporal, LangGraph | Temporal восстанавливает ход выполнения повтором истории событий (replay). LangGraph сохраняет снимок состояния графа на каждом шаге (checkpointer) |
| Заранее известный граф шагов, одинаковый каждый раз | n8n, LangGraph | Граф рисуется или описывается явно. У OpenClaw графового DSL нет по замыслу |
| Жёсткий потолок расходов | Внешний лимит, например ключи LiteLLM с лимитами трат (spend limits) | token_budget у цели — ограничитель сессии, «not a billing cap» |
| Изоляция между клиентами на одном сервере | Отдельный Gateway на каждого | Один Gateway — одна граница доверия |
Теперь подробнее.
Durable execution с replay. Durable execution, долговечным выполнением, называют выполнение, которое переживает сбой без потери места. Temporal исполняет код воркфлоу «effectively once and to completion» и восстанавливает состояние повтором истории событий. У Task Flow документация сама проводит черту: долговечны записи, но не стек вызовов и не автоматическое расписание. Метаданные ожидания не регистрируют таймер, а побочные эффекты нельзя повторять вслепую. У хуков нет долговечной очереди, автоматического повтора и гарантии exactly-once. Если сбой посреди платёжной операции для вас недопустим, это работа для Temporal.
Детерминированные графы. Если процесс известен заранее и каждый раз одинаков, модель-оркестратор его только замедлит и удорожит. Для таких процессов есть LangGraph с явным графом. Для интеграций и бизнес-процессов с десятками коннекторов проще n8n.
Бюджет. В документации нет механизма, который жёстко остановит расходы на отметке в N долларов. Ограничивать нужно снаружи, на уровне ключа провайдера или прокси.
Несколько клиентов. Документация прямо пишет: один Gateway рассчитан на одну границу доверенного оператора, «not hostile multi-tenant isolation». Песочница по умолчанию выключена, команды выполняются на хосте. Для нескольких арендаторов нужен отдельный экземпляр на каждого.
Зрелость. Проект оценивает себя сам в maturity/scorecard.md. Общая оценка 68%, стадия Alpha по шкале, где Alpha — 50–70, Beta — 70–80, Stable — 80–95. Качество 65%, полнота 71%, покрытие пока не оценено. Agent Runtime и «Automation and durable work» стоят на Beta. В историческом прогоне QA от 8 сентября 2026 года (в текущую оценку не входит) фоновые задачи и хуки прошли все проверки, задания по расписанию — 12 из 22, внешние рантаймы и субагенты — 3 из 10, приём внешних событий — 0 из 15. Практический вывод: реестр задач проверен хорошо, а пайплайн на вебхуках сначала гоняйте на тестовых данных.
Куда дальше
Дальше мы будем разбирать такие пайплайны по одному: схема, механизмы, место человека, цена и где ломается. Первыми — редакция по расписанию и Claude Code с Codex в роли подчинённых. Как выглядит живая команда агентов, смотрите в «Команде из 15 агентов».