2026 OpenClaw Playwright skill-browser на headless Mac VPS: Chromium под одним пользователем, лимит параллелизма и runbook ошибок (матрица решений и FAQ)

1. Боли: отсутствие Chromium, OOM и модальные блокировки

skill-browser расширяет поверхность отказов браузерными подпроцессами: шлюз может быть online, а первый navigate всё равно падает. На headless Mac VPS доминируют четыре паттерна в post-mortem.

1. Chromium не установлен под тем же пользователем: CLI и launchd работают под разными UID; кэши расходятся, логи сообщают об отсутствии executable или пустых profile.
2. Exit 137: слишком много параллельных browser context; OOM killer завершает Chromium, а шлюз видит только tool timeout без PID браузера.
3. Расщепление HOME: интерактивный SSH smoke проходит, сессии launchd — нет; config-каталоги не writable или lock profile на неверной UID.
4. Модальная блокировка: без blockedByDialog evaluate зависает на cookie banner или SSO; snapshot пустой при navigate HTTP 200.

Фиксируйте эти кластеры рано в runbook: отсутствующий бинарник Chromium — почти всегда проблема учётной записи, а не баг Playwright. Exit 137 после пика нагрузки указывает на параллелизм, а не сеть. Пустые snapshot на доступном URL — модали или anti-bot; оба требуют явной policy в конфиге Skill.

В incident review на Mac cloud команды часто подозревают сеть или LLM Provider, хотя JSONL уже показывает ENOENT на пути Chromium или SIGKILL без stacktrace. Держите одну toolCallId во время разбора и не меняйте параллельно auth шлюза, config Skill и install browser. Перед prod зафиксируйте разрешённые URL и исключённые домены — это снижает риск и лишний параллелизм от retry-циклов.

Пятый, реже документируемый паттерн: устаревший кэш Playwright или Chromium после minor upgrade. Симптом — sporadic navigate с protocol errors при зелёном doctor. Часто помогает точечная очистка browser cache под HOME launchd и переinstall — всегда тот же user, никогда через sudo из интерактивной root shell.

2. Матрица решений: headless Mac VPS vs локальный Mac vs browser Docker

Локальные Mac удобны для отладки селекторов; для 7×24 с шлюзом на порту 18789 на той же машине выигрывает headless Mac cloud. Контейнерные browser stack описаны в runbook Compose 7×24.

Команды, уже держащие IM-каналы на Mac VPS, не должны выносить browser skill на отдельный Linux-хост, пока login session и profile Chromium должны принадлежать пользователю шлюза. Матрица сформулирована operations-first, чтобы архитектурные ревью не уходили в споры о tooling.

Для коротких batch — ночные price snapshot без интерактивной IM-петли — Docker на том же Mac VPS может подойти, если healthchecks Compose и лимиты ресурсов стандартизированы. Как только агент должен live navigate во время Telegram-диалога, co-location со шлюзом выигрывает: каждый лишний hop увеличивает tail latency и усложняет корреляцию sessionId, toolCallId и channel events в JSONL. Локальные Mac незаменимы для визуальной отладки селекторов, но не как production single point: sleep, VPN и ручные клики по модалям не масштабируются в аудируемый 7×24.

3. Preflight Mac VPS: Node 22, 18789 и HOME одного пользователя

Перед установкой skill-browser слой шлюза должен быть стабилен. Полуустановленные инстансы OpenClaw дают ложные успехи в browser smoke.

• Runtime: Node.js 22+; openclaw doctor и openclaw --version без предупреждений полуinstall.
• Шлюз: lsof -i :18789 или openclaw gateway status показывает listener; иначе следуйте runbook install шлюза.
• Выравнивание учётки: зафиксируйте UserName и HOME из plist launchd; install Chromium и config Skill под тем же пользователем.
• Ресурсы и аудит: рекомендуется ≥8 GB RAM и 20 GB свободного диска; перед pull ClawHub завершите аудит безопасности Skill.

Зафиксируйте echo $HOME в интерактивной SSH shell и в симулированной сессии launchctl asuser. Расхождение здесь чаще всего объясняет «локально зелёный, prod красный» для browser skill.

Заложите минимум двадцать процентов свободной RAM поверх ожидаемого footprint Chromium. На shared Mac cloud browser skill, шлюз и локальные embedding-модели конкурируют за один memory pool. Если параллельно Ollama или другие providers, явно документируйте, что каждый открытый browser context реалистично стоит четыреста–шестьсот MB. Disk IOPS — второй bottleneck: медленный volume удлиняет cold start и повышает timeout flakiness на тяжёлых SPA.

Перед первым openclaw skills install skill-browser завершите аудит ClawHub. Third-party skills с shell или file access расширяют attack surface на хосте с gateway tokens и IM secrets. Зеркалируйте exec gating из статьи аудита Skill и относитесь к browser skill как к любому production extension: version, review, rollback-ready.

4. Таблица параметров skill-browser: headless, параллель, timeout

skill-browser основан на Playwright headless Chromium. Таблица — каркас для review; после каждого апгрейда сверяйте с live config через openclaw doctor.

Параллелизм — главный рычаг стабильности: одного context хватает для большинства IM-триггеров. Повышайте parallel contexts только если RSS остаётся ниже 60 % доступной RAM и доля успешных snapshot стабильно выше 95 %.

Для blockedByDialog две production-стратегии: dismiss для marketing cookie banner, которые не должны блокировать flow, и fail-fast для SSO или payment modal, где зависший agent хуже явной ошибки пользователю. Зафиксируйте выбор по целевому домену в runbook. Для timeout-ms — двухуровневая модель: низкие defaults для internal tools со stable DOM, высокие для external pages с тяжёлым JS — но не настолько, чтобы tool queue горела под нагрузкой.

5. Runbook семь шагов: учётка → install → Chromium → зонд → smoke → launchd

1. Выровнять учётку и HOME: проверить UserName plist launchd; SSH под тем же пользователем; echo $HOME должен совпадать с plist.
2. Pin версии и doctor: backup openclaw.json, выполнить openclaw doctor; апгрейды по runbook release train мая.
3. Установить skill-browser: после аудита openclaw skills install skill-browser.
4. Установить Chromium: тот же пользователь npx puppeteer browsers install chromium; путь в логах.
5. Записать параметры: headless, parallel contexts, timeout-ms, blockedByDialog в config Skill.
6. Зонд и smoke: подтвердить порт 18789; фиксированный URL для snapshot; сохранить toolCallId в JSONL.
7. Приемка launchd: загрузить plist, симулировать reboot, повторить smoke — результат должен совпадать.

Архивируйте выход snapshot и связанные строки JSONL в change ticket. Так responders увидят регрессии после апгрейда в diff, не переразбирая весь stack.

Шаг два — pin версии — особенно важен на ветке 2026.5: Skill loading и exec gating ужесточились. После upgrade прогоните минимальный E2E: IM message → agent вызывает browser tool → snapshot back. Сравните defaults headless и blockedByDialog с pre-upgrade; drift здесь объясняет многие «случайные» evaluate hangs. Шаг семь — приемка launchd — не опционален: smoke только в interactive SSH не доказывает uptime после reboot или plist reload.

6. Три сигнала: cold start, RSS, доля успешных snapshot

• Cold start Chromium: первый launch на Mac cloud — меньше восьми секунд; стабильно больше пятнадцати — узкое место диска или нет warmup policy.
• Память: после single-context smoke шлюз плюс Chromium вместе ниже 60 % доступной RAM.
• Доля snapshot: двадцать повторов одного URL — ≥95 % успеха; ниже 90 % сначала меняйте policy модалей, не параллелизм.

Привяжите эти KPI к paging: регрессия cold start после deploy — нет Chromium или неверный cache path; пики RSS — parallel contexts; drift snapshot — anti-bot или смена SSO на целевой странице.

Добавьте простой dashboard: hourly snapshot success rate, p95 cold start и gateway RSS после browser tool. Пороги дословно в runbook — «ниже 90 % snapshot за 15 минут» pager-worthy; «одиночный timeout» часто нет. Несколько target URL — baseline на URL, anti-bot policy сильно различается по доменам.

7. Таблица ошибок и послойный triage

«Browser tool failed»: Chromium на месте → HOME одного пользователя → headless/параллель → модали/timeouts. Каждый слой — к JSONL toolCallId.

Не меняйте параллельно auth шлюза, config Skill и install Chromium во время инцидента. Стабильная цепочка toolCallId ускоряет post-mortem лучше скриншотов из интерактивной shell.

Слой один — Chromium на месте — проверяйте под тем же user, что launchd: which chromium недостаточно, если puppeteer установил в user-specific cache. Слой два — HOME — сравните plist, interactive shell и simulated launchd env. Слой три — параметры — headless true на headless host и parallel contexts vs RAM budget. Слой четыре — модали и сеть — blockedByDialog, timeout и смена URL. DOM и anti-bot цели разбирайте только когда слои один–три зелёные.

8. Бизнес-кейсы: формы, мониторинг и IM

Автоматизация формы поддержки: агент получает тикеты через Telegram, открывает внутреннюю форму skill-browser, заполняет поля и возвращает скриншот; SSO-модали — fail-fast, чтобы агент не зацикливался.

Мониторинг конкурентов: cron запускает snapshot фиксированных селекторов в JSONL; parallel contexts остаётся 1 против OOM; drift DOM ловится сравнением snapshot.

Сначала browse, потом ответ: пользователи спрашивают @bot про доку; агент сначала navigate к live doc, затем резюмирует — подходит для страниц с login или client-side render, где чистая LLM без URL даст неверный ответ.

Compliance screenshots: регуляторные или internal audit требуют периодических доказательств, что public status page содержит нужный текст. Cron flow с фиксированным selector и archived snapshot в JSONL даёт повторяемую evidence — если parallel contexts консервативен и target URL в allowlist. Не смешивайте такие jobs с interactive IM peak load на том же узле без RAM reserve.

9. FAQ

Вопрос: skill-browser рядом с Ollama или несколькими providers? Да; browser subprocess отделён. Задайте лимит concurrency в tools.profile и смотрите RSS в gateway status --deep.

Вопрос: Повторная приемка после апгрейда v2026.5.x? doctor, переinstall Chromium тем же user, минимальный smoke snapshot — см. runbook release train.

Вопрос: Mac cloud vs VPS Linux или Docker? 7×24 co-located шлюз: Mac cloud; короткие batch: Docker возможен, но triage OOM и прав длиннее.

10. Заключение

Критерий успеха: skill-browser → Chromium одного пользователя → воспроизводимый snapshot через порт 18789. Ноутбук и WSL2 редко держат 7×24; browser Docker на Linux VPS борется с /dev/shm и headless detection. Чтобы browser skill работал параллельно IM-каналам постоянно, надёжнее арендовать узел Mac cloud Apple Silicon VPSMAC и собрать шлюз, кэш Chromium и launchd в одном runbook. Docker остаётся для коротких batch, но не заменяет production headless Mac stack. Далее: Docker 7×24 и аудит Skill.