2026 Linux cloud VPS: мультиагентные конвейеры — LangGraph vs OpenClaw Gateway, systemd и поуровневая диагностика FAQ

На прошлой неделе одна команда взяла схему Supervisor + Worker из нашей статьи про конвейер мультиагентной архитектуры и перенесла ее на Linux VPS. В рабочее время все выглядело отлично: события из Slack доходили, ответы публиковались, демо было убедительным. Но после плановой перезагрузки хоста проявилась типичная продовая проблема: потерялись точки ожидания одобрения, старые checkpoint начали переиспользоваться как новые ветки, Cron-задачи задублировались, а канал показывал "все нормально", хотя граф уже разошелся по состоянию. Корень проблемы оказался не в модели, а в неверном разделении слоев.

В продакшене важно помнить: мультиагентность — это не "запустить больше Python-процессов". Нужна строгая граница ответственности. LangGraph отвечает за топологию, переходы состояния, checkpoint, восстановление по thread_id и human interrupt. OpenClaw Gateway отвечает за ingress (IM/Webhook), расписания, границы доступа и наблюдаемость 24x7. Этот материал — практический FAQ: матрица решений, минимальная топология, контракт handoff, baseline для systemd и L0-L3 порядок диагностики. Для операционной части Gateway см. FAQ по Linux-эксплуатации OpenClaw; для бюджета и token-учета — статью о стоимости AI-агентов.

Почему на VPS нужно разделять оркестрацию и слой исполнения

На localhost можно собрать Planner -> Coder -> Reviewer в одном процессе. На Linux VPS под реальной нагрузкой это быстро ломается из-за четырех факторов:

• Разные источники входа - чат-команды, webhooks, личные сообщения, Cron.
• Долгоживущие состояния - человек может подтвердить задачу через часы, и состояние обязано переживать рестарты.
• Разделение привилегий - процесс с публичным ingress не должен иметь полный набор MCP-ключей.
• Наблюдаемость по доменам - TLS/403 и доставка событий это Gateway, циклы узлов и merge state — LangGraph.

Поэтому базовая схема такая: LangGraph запускается на внутреннем адресе, OpenClaw Gateway — отдельным сервисом. Gateway нормализует входящие события, формирует намерение (intent) и вызывает граф контролируемо. LangGraph остается единственным источником истины по состоянию workflow. Такое разделение уменьшает радиус инцидента и делает эксплуатацию предсказуемой.

Матрица топологий: три типовых формы на Linux VPS

На практике чаще всего встречаются три архитектурные формы. Выбор зависит от требований к 24x7-каналам, устойчивости interrupt и места выполнения тяжелых инструментов.

Форма A — самый быстрый старт, но и самая частая причина нестабильности при плохой персистентности checkpoint. Форма B обычно лучше для роста: VPS держит ingress и orchestration API, а тяжелые инструменты выносятся на cloud Mac. Форма C уместна для простых сценариев, но ее не стоит растягивать на задачи с ревью-ветвлением и сложными handoff.

Подход LangGraph к мультиагентным графам описан в официальной документации multi-agent. Настройка канального слоя OpenClaw — в Gateway configuration.

Минимально воспроизводимая топология (форма A)

Короткий путь внедрения, который хорошо работает в бою:

1. LangGraph API - обернуть граф в FastAPI, слушать 127.0.0.1:8123, хранить checkpoint в постоянном хранилище.
2. OpenClaw Gateway - установить по документации OpenClaw CLI, завершать TLS на Nginx/Caddy.
3. Bridge-правило - входящее событие -> нормализация -> структурированный вызов run API.
4. Раздельный systemd - langgraph-api.service и openclaw.service как независимые unit-файлы.

# /etc/systemd/system/langgraph-api.service
                [Unit]
                Description=LangGraph multi-agent API
                After=network-online.target

                [Service]
                User=deploy
                WorkingDirectory=/opt/langgraph-app
                Environment=CHECKPOINT_DIR=/var/lib/langgraph-checkpoints
                ExecStart=/opt/langgraph-app/.venv/bin/uvicorn main:app --host 127.0.0.1 --port 8123
                Restart=on-failure
                RestartSec=5

                [Install]
                WantedBy=multi-user.target

После включения сервисов проверьте ss -lntp: наружу должен смотреть только 443 у reverse proxy. Публиковать orchestration API напрямую нельзя. Это простое правило резко снижает и риск компрометации, и сложность инцидентов.

Контракт handoff: что Gateway передает в граф

Чаще всего ломается не модель, а формат передачи. Зафиксируйте versioned JSON schema:

• thread_id - стабильный ключ между каналом и цепочкой состояния графа.
• intent - явный enum: new_task, approve, cancel, status.
• payload - структурированный контекст (repo, paths, instruction), большие вложения как ссылки на object storage.
• caller_scope - данные о канале/пользователе для повторной авторизации внутри графа.

Модель memory/checkpoint в LangGraph рассчитана на долгоживущие сценарии. Gateway должен оставаться максимально stateless. Если обе стороны ведут отдельные state machine, неизбежно появляется split-brain между каналом и реальным состоянием выполнения.

Диагностика L0-L3: сначала слой, потом правка

Если жалоба звучит как "бот молчит", не меняйте сразу все. Идите по слоям.

L0: systemd и порты

Проверить systemctl status openclaw langgraph-api и сокеты. Падение LangGraph часто маскируется под "проблему канала".

L1: канальные и bridge-логи OpenClaw

Через openclaw logs проверить webhook, подписи, target URL. TLS/403/retry сначала разбираются здесь.

L2: trace LangGraph и checkpoint

По тому же thread_id определить последний стабильный узел. Ошибки прав доступа или mount'ов делают каждое сообщение "новой сессией".

L3: удаленные workers и MCP

При форме B проверяйте сеть, NO_PROXY, срок токенов и лимиты хоста. Переустановка Gateway не исправит таймаут удаленного worker.

Чеклист перед запуском (30 минут)

• LangGraph слушает только приватный интерфейс, наружу открыт только Gateway.
• checkpoint хранится в постоянном и резервируемом хранилище.
• Timeout Gateway->graph меньше окна ретраев канальной платформы.
• Явный allowlist инструментов по узлам; Reviewer без write-доступа в прод.
• Репетиция reboot: interrupt корректно возобновляется, Cron не дублируется.
• Единый trace id от ingress до логов worker.

FAQ