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

OpenClaw щодня: placement-aware агенти, worktrees і throwaway workers

openclaw · 2026-07-26

Головний кут дня: OpenClaw варто налаштовувати не як “один агент на одному ноутбуці”, а як placement-aware control plane. Для кожної задачі треба явно вирішувати: де виконувати код, де тримати секрети, де живе transcript, який trust boundary і як відкотити зміни.

1. Managed worktrees: ізоляція задач без бруду в основному checkout

Managed worktrees дають агенту окрему git-гілку й checkout у state-директорії OpenClaw. Практичний патерн:

  • кожен ризиковий coding task стартує в openclaw/<task-name>;
  • .worktreeinclude копіює тільки потрібні ignored-файли, а не весь локальний хаос;
  • .openclaw/worktree-setup.sh стає repo-local контрактом bootstrap-а;
  • cleanup робиться після snapshot-а, щоб не втратити корисні артефакти.

Це сильніше за “агент, будь обережний”: isolation має бути властивістю runtime, а не характеру моделі. Для базової механіки корисно перечитати й сам git worktree.

2. Cloud Workers: дорогі або брудні задачі — на throwaway box

Cloud Workers — цікавий production-патерн: agent loop і tools виконуються на одноразовій машині, а transcript, model credentials і streaming залишаються під Gateway. Через Crabbox можна орендувати ephemeral worker, виконати задачу й викинути host.

Практичне правило: cloud worker потрібен не “бо швидше”, а коли є хоча б один фактор:

  • потрібна чиста Linux-машина для build/test;
  • задача може зламати локальний env;
  • треба багато CPU/RAM;
  • не хочеться давати агенту доступ до домашнього checkout-а;
  • треба доказово відділити виконання від control plane.

Provider credentials не мають їхати на worker. Якщо секрет потрібен у дії — краще робити вузький gateway-mediated крок або human approval, а не копіювати .env на ephemeral VM.

3. Local models: дешевий routing, але не сліпа довіра

Local models корисні для класифікації, чорнових summary, language cleanup, локальних документів і pre-triage. Але маленька quantized модель — слабкий security boundary: вона гірше тримає довгий контекст і легше пропускає prompt injection.

Добра схема:

  • frontier model — для risky write actions, security review, архітектурних рішень;
  • local model через LM Studio, Ollama або vLLM — для дешевих read-only задач;
  • LiteLLM OpenAI-compatible routing — якщо потрібен один policy/proxy шар перед кількома backend-ами;
  • явний label у відповіді або metadata: model_class=local-low-risk.

Не ставте local model на задачі з секретами, фінальним deploy або irreversible changes без окремого approval gate.

4. Multi-tenant hosting: cell per trust domain

Multi-tenant hosting правильно формулює межу: один Gateway — це один trusted operator boundary. Якщо користувачі або організації не довіряють одне одному, потрібен окремий cell: власний Gateway, state, credentials, workspace, channel accounts і loopback port.

Практична архітектура для малого хостингу:

  • reverse proxy бачить тільки loopback endpoints;
  • tenant cell не має shared channel account;
  • egress обмежується firewall-ом або internal network policy;
  • host/fleet operator вважається privileged і аудититься окремо;
  • tenant backup/restore перевіряється як DR-процедура, не як “папка зі state”.

Для container hardening варто мати поруч Podman docs і rootless containers guide.

5. Background process як операційний UX

Background exec and process tool — не дрібниця, а UX для довгих задач. Якщо команда може тривати хвилини, агент має стартувати її один раз, показати session id/status, потім перевірити результат через process, а не плодити sleep-цикли або повторні запускі.

Корисний стандарт для OpenClaw skills:

start once → capture session id → poll only for status/logs → summarize result → attach artifact/proof

Це зменшує дублікати, знижує ризик подвійного deploy і робить run відтворюваним.

10 практичних ідей OpenClaw на сьогодні

  1. Worktree-only coding lane — усі coding subagents стартують тільки в managed worktree; прямий запис у main checkout заборонений.
  2. Dirty task placement — dependency upgrade, fuzzing, flaky integration tests і codegen запускати на cloud worker, не на домашньому Gateway.
  3. Model tier labels — додати до standing orders правило: local model може тільки читати, класифікувати й робити чернетки.
  4. Tenant cell checklist — для кожного tenant-а: окремий Gateway token, state path, channel account, backup і egress policy.
  5. .worktreeinclude review — раз на тиждень перевіряти, які ignored-файли копіюються в worktrees; секрети не мають потрапляти туди випадково.
  6. Bootstrap contract — винести repo setup у .openclaw/worktree-setup.sh, щоб агент не вигадував install-команди щоразу.
  7. Worker TTL budget — cloud worker profile має мати TTL/idle timeout; безстрокові workers — це майбутній cost incident.
  8. Background process receipts — для довгих задач зберігати command, session id, exit code, artifact path і короткий log tail.
  9. Local-model canary — раз на день порівнювати local summary з frontier summary на одному документі; якщо drift великий — не використовувати local для triage.
  10. Placement matrix у vault — таблиця task type → local gateway / worktree / cloud worker / tenant cell / human approval.

Матеріали й відео