DevSecOps Digest
Щоденний DevSecOps дайджест

OpenClaw як диспетчер агентів, а не ще один бот

openclaw · 2026-06-27

Сьогоднішній практичний кут: OpenClaw варто проєктувати як agent dispatch layer. Не один всемогутній асистент, а контрольована точка, яка приймає запити з каналів, вибирає правильний runtime, зберігає контекст і не змішує приватну памʼять, IDE-сесії, node-команди та зовнішніх агентів.

1. Три різні протокольні межі

Корисна ментальна модель:

  • openclaw acp — коли IDE або ACP-клієнт хоче говорити з OpenClaw і отримати Gateway-backed session;
  • openclaw mcp serve — коли зовнішній MCP-клієнт має бачити OpenClaw channel conversations/tools;
  • A2A Protocol — коли треба делегувати роботу іншому opaque agent, не відкриваючи йому внутрішню памʼять, tools або приватну логіку.

Це важливо: ACP — client-to-agent, MCP — agent-to-tool/context, A2A — agent-to-agent. Якщо все називати “інтеграцією”, конфіг швидко стає небезпечним клубком.

2. Dispatch registry замість хаотичних промптів

Практична конфігураційна ідея: зробити маленький agents/dispatch.md або wiki-сторінку з маршрутами.

routes:
  code-review:
    entry: acp
    runtime: codex-or-claude
    workspace: repo-ro-first
    approval: required-for-write
  family-calendar:
    entry: main-session
    tools: calendar-read, message-draft
    external-send: confirm
  lab-status:
    entry: node
    commands: device.status, screen.snapshot
    shell: denied
  vendor-agent:
    entry: a2a
    share: ticket-summary-only
    receive: artifact-link-and-status

Це не “архітектурна краса”. Це спосіб не дати запиту з Telegram випадково отримати ті самі права, що IDE coding session або local node.

3. Nodes як capability surface, не remote shell

openclaw nodes добре показує правильний напрям: pairing, connected/last-connected status, approve/reject, invoke capability commands. Shell винесений окремо: для system.run треба йти через exec host=node, а не перетворювати nodes CLI на універсальний remote runner.

Добрий use case:

  • nodes list --connected перед дією;
  • nodes invoke тільки для вузьких команд: status, notification, canvas, screen snapshot;
  • окремий approval для будь-якого shell/run сценарію;
  • щоденний diff capability list: якщо зʼявився camera, screen.record або system.run, це security event.

4. A2A як boundary для чужих агентів

A2A цікавий для OpenClaw не “multi-agent hype”, а конкретною властивістю: агенти можуть співпрацювати, лишаючись opaque. Для домашнього або малого командного OpenClaw це дає корисний патерн:

  1. OpenClaw приймає людський запит у WhatsApp/Telegram/Slack.
  2. Main session робить redaction і стискає задачу.
  3. External/domain agent отримує тільки task packet, без приватної памʼяті й channel transcript.
  4. OpenClaw приймає результат як artifact, а не як authority.
  5. Людина або локальний approval gate вирішує, чи виконувати наступну дію.

Це сильніше, ніж “підключимо ще одного агента з усіма tools”.

5. Малий playbook на день

  • Завести dispatch.md: task type → runtime → allowed tools → approval rule.
  • Для ACP-сценаріїв не reuse-ити main session key без потреби; IDE-сесії мають бути ізольовані.
  • Для node-hosts тримати окремі ролі: observe, assist, operate.
  • Для зовнішніх агентів передавати sanitized task packet, а не raw transcript.
  • У daily/weekly health check додати: active sessions, paired nodes, last-connected, нові capabilities, failed approvals.

6. Що подивитися й почитати

Сильний OpenClaw setup — це не кількість підключених агентів. Це якість меж: хто отримує який контекст, через який протокол, з яким blast radius і яким доказом виконання.