OpenClaw: мульти-агентная оркестрация в 2026

Зачем нужна мульти-агентная оркестрация

Один долгоживущий контекст агента накапливает шум: дампы исследований, неудачные попытки и логи инструментов раздувают окно, пока качество не падает. OpenClaw рассматривает оркестрацию как задачу первого класса — родительский агент планирует и маршрутизирует; воркеры получают узкие промпты и изолированные workspace.

Команды переходят на мульти-агентный OpenClaw, когда:

• Генерация CI/CD должна затрагивать несколько репозиториев или сервисов параллельно (данные бенчмарка показывают ~3,2× более быструю параллельную генерацию кода по сравнению с одноагентным Claude Code на сопоставимых задачах)
• Code review выигрывает от независимых «линз» (безопасность, стиль, покрытие) без того, чтобы одна модель играла все роли
• Длинные документы не должны заставлять одного агента держать research, outline, draft и audit в одном потоке

Режим сбоя тоже архитектурный: пять «агентов», которые пишут в одни и те же ключи памяти без изоляции, создают race condition — слой оркестрации должен владеть логикой merge и таймаутами.

Модель оркестрации OpenClaw

В runtime OpenClaw сводится к gateway-демону плюс именованным agent identity в конфигурации. Мульти-агентные потоки используют:

Правило глубины: два уровня (orchestrator → workers) покрывают ~95% нагрузок. Три уровня (orchestrator → team lead → leaf) помогают только когда подкоманды действительно независимы — стоимость отладки резко растёт.

Внешняя ссылка: OpenClaw GitHub и community-заметки об архитектуре maxSpawnDepth / cascade stop behavior.

Три паттерна оркестрации

Паттерн 1 — Параллельный fan-out

Когда: подзадачи не зависят от выходов друг друга.

Форма: оркестратор инициирует несколько spawn в одном turn; wall-clock ≈ самый медленный воркер, а не сумма воркеров.

Примеры:

• Lint трёх пакетов одновременно
• Research трёх URL конкурентов
• Генерация unit-тестов для трёх сервисов

Антипаттерн: fan-out pipeline (research + draft) — drafter стартует с пустым входом, пока research ещё выполняется.

Orchestrator
 ├── spawn worker-a (scope: package-frontend)
 ├── spawn worker-b (scope: package-api)
 └── spawn worker-c (scope: package-worker)
      → merge summaries → single PR plan

Паттерн 2 — Последовательный pipeline

Когда: этап B нуждается в артефакте этапа A.

Форма: research → outline → implement → audit → publish. Каждый воркер получает чистый контекст только с deliverable предыдущего этапа.

Почему выигрывает: drafter не тащит 3 000 строк raw research tokens; auditor не видит pre-audit draft history.

Цена: wall-clock аддитивен — используйте только при реальных зависимостях.

Паттерн 3 — Fan-out с валидацией

Когда: точность важнее скорости (compliance-текст, infra diff, pricing tables).

Форма: один и тот же промпт 2–3 воркерам; оркестратор или monitor agent сравнивает выходы; расхождения запускают retry или эскалацию к человеку.

Цена: ~2–3× расход token по сравнению с одним воркером — оправдано только для high-stakes merge.

Runbook настройки

Предполагается, что OpenClaw уже установлен — если нет, сначала пройдите руководство по установке.

Шаг 1 — Определите roster агентов в openclaw.json

Типичный путь: ~/.openclaw/openclaw.json (проверьте для вашего релиза).

{
  "agents": {
    "list": [
      {
        "id": "orchestrator",
        "default": true,
        "workspace": "~/.openclaw/workspace-orchestrator",
        "sandbox": { "mode": "off" }
      },
      {
        "id": "coder",
        "workspace": "~/.openclaw/workspace-coder",
        "sandbox": { "mode": "all", "scope": "agent" },
        "skills": ["git", "nodejs", "testing"]
      },
      {
        "id": "researcher",
        "workspace": "~/.openclaw/workspace-research",
        "sandbox": { "mode": "all", "scope": "agent" },
        "skills": ["web", "docs"]
      }
    ]
  },
  "tools": {
    "agentToAgent": {
      "enabled": true,
      "allow": ["orchestrator", "coder", "researcher"]
    }
  }
}

Шаг 2 — Изолируйте workspace для каждого воркера

Каждый worker ID должен соответствовать отдельному каталогу workspace. Никогда не делите writable workspace между параллельными fan-out воркерами — file race портят merge.

mkdir -p ~/.openclaw/workspace-{orchestrator,coder,researcher}

Шаг 3 — Напишите system prompt оркестратора с routing table

Промпт оркестратора должен перечислять:

1. Доступные worker ID и skills
2. Когда fan-out vs pipeline
3. Timeout на spawn (например, 120 s для research, 300 s для codegen)
4. Failure policy: retry once, then escalate

Правило sub-agent context: воркеры должны получать только AGENTS.md + TOOLS.md + task payload — не полный thread оркестратора.

Шаг 4 — Включите sandbox для недоверенных воркеров

Оставьте у оркестратора sandbox.mode: off для coordination tools; sandbox coders/researchers с mode: all, когда воркеры могут выполнять shell или network.

Шаг 5 — Задайте лимиты spawn

Настройте maxChildren / maxSpawnDepth по документации вашей версии OpenClaw. Начните с max 3 parallel children, пока не измерите RAM и API rate limits.

Шаг 6 — Проверьте через openclaw doctor

openclaw doctor
openclaw status

Устраните duplicate hooks или конфликтующие agent bindings перед fan-out под CI.

Шаг 7 — Запустите контролируемую fan-out задачу

Пример инструкции оркестратора (концептуально):

Task: Review modules auth/, billing/, notify/ in parallel.
Spawn researcher once per directory with identical rubric.
Merge into one markdown report with per-module sections.
Timeout: 180s per worker. If one worker fails, continue with partial merge and flag gaps.

Логируйте peak RSS во время теста — сравните с footprint бенчмарка.

Шаг 8 — Подключите CI trigger (опционально)

Экспонируйте gateway локально; триггер через SSH + REST из pipeline. Храните артефакты в task-scoped paths:

export TASK_ID="${GITHUB_RUN_ID}"
mkdir -p "/tmp/openclaw-runs/${TASK_ID}"

Память, состояние и дисциплина merge

Merge contract: оркестратор должен заранее определить output schema (JSON sections, required headings). Воркеры валидируют против schema перед handoff.

Железо и бюджет RAM

Измерено на хостах класса Apple Silicon M4 (см. статью бенчмарка):

Оркестрация не требует GPU — узкие места — API rate limits и disk I/O при sync workspace. Для выбора узла по региону (только API latency) см. матрицу регионов M4.

Обработка сбоев

Явно определите в промпте оркестратора:

Ночные CI-сбои часто связаны с отсутствием timeouts — default «wait forever» блокирует gateway.

Рекомендуемый путь

Если X → Y в одну строку: если промпт worker B нуждается в output worker A, — pipeline. Если нет — fan-out.

FAQ

Сколько агентов OpenClaw может запускать параллельно?

Фиксированного глобального cap нет — практические лимиты: RAM, API rate limits и merge complexity. Начните с 3 parallel workers, измерьте peak RSS через ps или «Мониторинг системы», затем масштабируйте.

Fan-out всегда ускоряет работу?

Только когда задачи независимы. Неверно применённый fan-out на зависимых этапах даёт тихий сбой (пустые черновики, дублирование). Перед выбором паттерна всегда стройте карту зависимостей.

В чём разница между agentToAgent и sub-agent spawn?

agentToAgent отправляет сообщения именованным persistent agents (sales vs support bots). Sub-agent spawn создаёт эфемерных workers для одной ветки задачи. CI orchestration обычно опирается на spawn; multi-tenant chat bots используют agentToAgent плюс bindings.

Можно ли запускать оркестрацию на Mac Mini без облачной аренды?

Да. Подойдёт любой постоянно включённый Mac с Node 22.19+, достаточным RAM и стабильной сетью. Команды используют выделенные Mac mini — локальные или хостинговые — когда ноутбуки засыпают и рвут длинные gateway sessions.

Как это связано с TradingAgents или MiroFish?

TradingAgents оркестрирует trading-firm debate (LangGraph). MiroFish оркестрирует social swarms для prediction. OpenClaw оркестрирует dev workflows (code, CI, review). Выбирайте фреймворк под домен — они дополняют друг друга, а не заменяют.