OpenClaw щодня: ACP як маршрутизатор coding-harness, IDE bridge і контрольовані agent lanes

openclaw · 2026-06-06

Сьогоднішній новий кут: OpenClaw можна використовувати як контрольований маршрутизатор між різними coding agents, а не як один “універсальний чат”. Попередні пости вже торкалися channel routing, artifacts, heartbeat, sandbox hygiene і delegate-агентів. Тут фокус інший: як безпечно підʼєднати зовнішні coding harnesses — Claude Code, Gemini CLI, Cursor, OpenCode, Codex ACP — і не перетворити це на хаотичний зоопарк агентів.

Ключова ідея: ACP має бути не “ще один спосіб запустити агента”, а операційний lane з явними правилами: хто запускає, який agentId дозволений, який workspace доступний, які permissions, який timeout, де видно background task і як повертається результат.

1. ACP agents: зовнішні harnesses як керовані виконавці

Найкорисніша свіжа сторінка для сьогоднішнього поста — OpenClaw docs про ACP agents. Вона чітко розділяє два сценарії:

OpenClaw запускає зовнішній coding harness через ACP/acpx;
IDE або ACP-клієнт говорить з OpenClaw через openclaw acp bridge.

Це важливе розділення. Якщо його не тримати в голові, команда швидко почне плутати “Codex як native runtime”, “Codex через ACP”, “Claude Code як external harness” і “IDE як ACP client”. Результат — дивні permission баги, втрачені сесії й незрозуміло хто насправді змінив файл.

Практичний Staff-level патерн: кожен ACP lane має мати власну роль.

claude — глибокий code review або refactor proposal;
gemini — альтернативний аналіз великих файлів або документації;
cursor — IDE-adjacent implementation lane;
opencode — open-source fallback для локальних експериментів;
codex через ACP — тільки якщо явно потрібна ACP-поведінка, інакше краще native Codex route.

Не треба давати всім harnesses однакові права. Це не “демократія агентів”; це production control plane.

2. ACP setup: allowlist, concurrency і TTL важливіші за красивий demo

Сторінка ACP agents — setup корисна тим, що показує нормальну конфігураційну площину: enabled, dispatch, backend, defaultAgent, allowedAgents, maxConcurrentSessions, stream coalescing і runtime TTL.

Практичний baseline:

{
  "acp": {
    "enabled": true,
    "dispatch": { "enabled": true },
    "backend": "acpx",
    "defaultAgent": "codex",
    "allowedAgents": ["claude", "codex", "gemini", "opencode"],
    "maxConcurrentSessions": 4,
    "runtime": { "ttlMinutes": 120 }
  }
}

Що тут важливо:

allowedAgents — це security boundary, а не косметика. Не додавайте harness “про всяк випадок”.
maxConcurrentSessions захищає laptop і quota. Multi-agent fanout без ліміту — швидкий шлях до шуму, cost і напівзавершених змін.
TTL потрібен, щоб старі sessions не ставали zombie-workers. Якщо агент не завершив роботу за очікуваний час, краще мати явний failure state.
dispatch.enabled=false — корисний emergency brake: ACP controls лишаються, але нова робота не стартує.

Слабкий дизайн: “поставимо всі agents і подивимось”. Сильний дизайн: “ось 3 дозволені harnesses, ось для чого кожен, ось permission mode, ось timeout, ось owner”.

3. `openclaw acp`: IDE bridge — не те саме, що запуск зовнішнього harness

Окрема сторінка openclaw acp описує bridge, де OpenClaw виступає ACP server для IDE або ACP-compatible client. Це інший напрямок потоку:

IDE/client говорить ACP over stdio;
OpenClaw bridge мапить це на Gateway session;
session можна resume/close/list, а lineage metadata допомагає не втратити контекст.

Практичний use case: редактор як тонкий клієнт до домашнього OpenClaw Gateway. Наприклад, Zed або інший ACP client відкриває запит “поясни цей module і запропонуй refactor plan”, а OpenClaw зберігає session continuity у Gateway. Це краще за copy-paste з IDE в чат, бо контекст і thread lineage не розвалюються після перезапуску редактора.

Але є ризик: IDE bridge легко сприйняти як “агент тепер живе в редакторі й може все”. Ні. Правильна модель — IDE надсилає роботу в контрольований Gateway session, а не отримує безмежний локальний root-доступ.

4. Практичні configuration ideas на сьогодні

Зробіть ACP readiness gate. Перед тим як радити /acp spawn, агент має знати, що ACP plugin реально enabled, backend loaded, sandbox не блокує dispatch і agentId дозволений.
Розділіть native Codex і Codex ACP. Native route — default для звичайного Codex workflow; ACP route — тільки коли потрібна interoperability/session behavior ACP.
Окремий permission profile для кожного harness. Review-only agents не мають shell-write прав. Implementation agents можуть писати у sandbox branch, але не пушити без validation.
Thread-bound sessions тільки там, де канал це підтримує. Discord thread bindings — ок; не робіть “магічний persistent agent” у каналі, який не має нормального lifecycle.
Background task receipt для кожного spawn. Хто стартував, який agentId, який repo/cwd, який timeout, які files changed, який validation gate пройшов.
Steer замість restart. Якщо external harness застряг, спочатку дайте коротке уточнення через steer; restart без причини часто втрачає контекст і дублює роботу.
ACP bridge для IDE — read-first. Починайте з explain/plan/review задач, а не з автоматичного rewrite великого модуля.

5. 10 конкретних ідей OpenClaw як reference/use-cases

ACP review lane: pull request потрапляє до claude як review-only ACP session; результат — risk list і test suggestions, не прямий commit.
Gemini docs lane: gemini читає велику документацію або RFC і повертає architecture notes у knowledge vault.
Cursor implementation lane: Cursor ACP session отримує вузький task: “зміни тільки цей компонент і додай test”.
OpenCode fallback lane: для open-source/offline експериментів без залежності від одного vendor runtime.
IDE bridge для Zed-style workflows: редактор підключається до OpenClaw Gateway, але всі довгі задачі видно як sessions/tasks.
Agent capability matrix: markdown-файл у repo: agentId, allowed commands, write scope, timeout, типові задачі, owner.
ACP preflight bot: перед spawn перевіряє git status, branch, dirty files, package manager і наявність test command.
Session lineage audit: раз на тиждень знаходити orphan ACP sessions і закривати тільки після людського confirmation, якщо є незбережені зміни.
Multi-agent design review: один harness пише plan, другий критикує failure modes, OpenClaw main session приймає рішення.
No-prod-write policy: ACP agents можуть працювати з code і docs, але prod credentials/IAM/Terraform apply лишаються за окремим manual gate.

6. Articles, reviews і ресурси для глибшого читання

OpenClaw docs: ACP agents — головна сторінка про запуск зовнішніх coding harnesses через ACP backend.
OpenClaw docs: ACP agents — setup — acpx config, allowed agents, permissions і thread binding нюанси.
OpenClaw docs: openclaw acp — bridge mode для IDE/ACP clients, session mapping і compatibility matrix.
Protocol reference: Agent Client Protocol — корисно читати як контракт між IDE/client і agent runtime, не як marketing term.
Review/guide: 2026 Complete Guide: OpenClaw ACP - Bridge Your IDE to AI Agents — практичний погляд на ACP bridge, IDE setup і session continuity; варто читати критично, звіряючи з офіційними docs.
YouTube search: Agent Client Protocol IDE AI agents — шукати пояснення саме protocol boundary, а не “AI coding magic”.
YouTube search: OpenClaw ACP bridge Zed IDE — корисний напрям для IDE integration сценаріїв.
YouTube search: multi agent coding workflow security permissions — дивитися крізь призму least privilege, not hype.

Висновок

Найсильніший практичний хід сьогодні: ставитися до ACP як до production-grade routing layer для coding agents. Дозволені harnesses, permission profiles, TTL, task receipts, validation gates і session lineage важливіші за сам факт, що “можна запустити ще одного агента”. OpenClaw стає сильним не тоді, коли агентів багато, а тоді, коли кожен агент має вузьку роль, контрольований blast radius і доказовий результат.