Skip to main content

​
Статус

Предложение, редакция 3. Не реализовано. Направление согласовано в 2026-07; редакция 2 учитывала результаты анализа с позиции потенциального злоумышленника (выделенный протокол воркера, автоматы состояний размещения и среды, входящая синхронизация с учётом Git, односторонняя передача управления в v1, формулировки безопасности для контролируемого исходящего трафика). Редакция 3 окончательно определяет модель владения синхронизацией (воркер создаёт коммиты, Gateway принимает и публикует их), добавляет простой режим синхронизации без Git, исправляет выполнение команд воркером на полное в пределах изолированной машины, переносит политику доступа в интернет на этап подготовки и возвращает диспетчеризацию агентом в этап 3.

​
Проблема

Сеансы агентов OpenClaw выполняют свой цикл, инструменты и инференс внутри процесса Gateway на одной машине. Вычислительные ресурсы ограничены возможностями этой машины, длительные задачи занимают её, а параллельные задания конкурируют за её ресурсы. Облачные продукты (облачные агенты Cursor, Claude Code в веб-интерфейсе, облачный Codex) решают эту проблему с помощью временных облачных песочниц для каждой задачи, но для этого требуются инфраструктура поставщика и доверие к нему. Операторы, у которых уже есть свободные машины (или возможность недорого их арендовать), не могут указать: выполнить этот сеанс на другой машине, показывать его на моей боковой панели как любой другой сеанс, а затем удалить машину.

​
Цели

  • Выполнять полный сеанс агента (цикл + инструменты) на временной удалённой машине («облачном воркере»), при этом сеанс должен отображаться и транслироваться в Control UI точно так же, как локальный сеанс.
  • На воркере не должно быть постоянных учётных данных (ни данных аутентификации провайдера, ни токенов Git-платформы) и прямого исходящего сетевого доступа; машине нужен только доступный sshd.
  • Подготовка, синхронизация, запуск, сбор результатов, уничтожение — полностью автоматически и с возможностью подключения разных провайдеров (первый провайдер: CLI аренды в стиле Crabbox).
  • Передавать выполняющуюся работу с Gateway на воркер на границе хода без потери расшифровки диалога, идентификатора сеанса или (если байты запроса остаются эквивалентными) привязки к кешу провайдера; безопасно получать результаты обратно.
  • Передавать работу облачному воркеру могут как пользователи (через UI), так и агенты (через инструмент).
  • Поддерживать сеансы длительностью в несколько дней; срок жизни определяется политикой, а не жёстко заданным ограничением.

​
Не входит в задачи (v1)

  • На воркерах не будет внешних средств программирования (Claude Code, Codex CLI). Сеансы воркеров выполняют только встроенный исполнитель OpenClaw. Поддержка таких средств будет включаемой возможностью v2, поскольку они самостоятельно выполняют инференс со своими учётными данными.
  • Не будет выбора лучшего из N вариантов и параллельного запуска нескольких попыток.
  • Не будет зависимости от VPN или tailnet. Транспорт — только SSH.
  • Не будет новой среды выполнения песочницы. Границей изоляции служит машина воркера; позднее поверх неё можно будет добавить внутримашинную изоляцию средствами ОС.
  • В v1 не будет симметричной оперативной миграции: передача выполняется с локальной машины → на воркер; возврат с воркера → на локальную машину требует остановленного сеанса и завершённого согласования рабочей области. Оперативная двусторонняя передача управления позднее будет построена на тех же механизмах барьера.
  • На Gateway не будет дополнительного состояния в JSON; состояние среды, размещения, курсора и разрешений хранится в SQLite.

​
Предшествующие решения (что мы заимствуем, а что инвертируем)

  • Облачные агенты Cursor: цикл агента выполняется в их облаке; виртуальная машина служит целевой средой для выполнения инструментов; хранилище диалога только для добавления транслируется всем клиентам; быстрый старт после установки из снимка; самостоятельно размещаемые воркеры представляют собой процессы только с исходящими подключениями. Мы заимствуем модель, в которой «источник истины для диалога остаётся у оркестратора», и модель потоковой передачи; размещение цикла мы инвертируем (см. решение ниже).
  • Облачный Codex: двухфазная среда выполнения — этап настройки с доступом к сети, затем автономный этап агента с удалёнными секретами; кеш состояния контейнера для быстрого продолжения работы. Мы заимствуем разделение на этапы как основу нашей модели исходящего трафика, а идею кеша — для тёплых образов в v2.
  • Claude Code в веб-интерфейсе: отдельная виртуальная машина для каждого сеанса; Git-прокси, изолирующий учётные данные (настоящие токены никогда не попадают в песочницу, отправка ограничена веткой сеанса); снимок файловой системы после настройки; передача управления = отправленная ветка + воспроизведённая история. Мы заимствуем изоляцию учётных данных и модель передачи управления, но исходящая синхронизация выполняется через rsync с Gateway, поэтому поддерживаются рабочие деревья с незакоммиченными изменениями, а токен Git-платформы отсутствует где-либо поблизости от машины.
  • Агент программирования Copilot: исходящий трафик по умолчанию запрещён, кроме разрешённого списка реестров пакетов. Наше стандартное состояние при обычной работе строже (прямой исходящий трафик полностью отсутствует), поскольку инференс и веб-поиск поступают через SSH-туннель, — однако в разделе «Безопасность» объясняется, почему это «контролируемый исходящий трафик», а не «нулевой исходящий трафик».

​
Архитектурное решение: цикл на воркере, инференс через Gateway

Рассматривались три варианта размещения:
  1. Цикл остаётся на Gateway, воркер выполняет инструменты (модель Cursor). Это наиболее безопасная область отказа (расшифровка диалога, инференс, подтверждения и восстановление после перезапуска остаются локальными) и предпочтительный для рецензента первый этап. Этот вариант отклонён как архитектура продукта: инструменты OpenClaw, не связанные с выполнением команд, представляют собой внутрипроцессные операции с файловой системой, поэтому каждое чтение, изменение или сканирование файла превращается в сетевой обмен либо требует масштабного преобразования поверхности инструментов в укрупнённые RPC рабочей области; взаимодействие со средой выполнения интенсивно и ограничивается задержкой. Мы следуем духу этой модели там, где она уже реализована (перенос выполнения команд на Node), но не создаём уровень удалённого выполнения инструментов.
  2. И цикл, и инференс выполняются на воркере. Это наиболее простая область отказа, но учётные данные моделей (включая профили OAuth) придётся передавать на временные машины, Gateway утратит контроль над политиками, маршрутизацией и аудитом, а миграция изменит идентификатор, от имени которого вызывается провайдер, что сделает кеши провайдера недействительными.
  3. Цикл + инструменты выполняются на воркере, а вызовы модели проксируются через Gateway. Выбранный вариант. Один сетевой обмен на ход модели вместо одного обмена на каждый вызов инструмента; инструменты выполняются рядом с кодом; Gateway остаётся единственным владельцем профилей аутентификации, маршрутизации провайдеров и политик; воркер не хранит секретов.
Цена варианта 3 — синхронная зависимость от Gateway во время каждого хода модели, поэтому правила обеспечения устойчивости являются частью решения, а не запоздалым дополнением:
  • Потеря Gateway в середине хода приводит к сбою активного вызова провайдера. Ход помечается как неудачный и после повторного подключения выполняется заново как новый ход; прозрачного повторного воспроизведения выполняющейся потоковой передачи провайдера нет из-за риска двойного списания средств или двойного вызова инструмента.
  • Каждая операция между воркером и Gateway содержит устойчивый идентификатор (см. раздел «Протокол воркера»), поэтому после повторного подключения выполнение продолжается либо извлекаются кешированные конечные результаты, а операции не остаются в подвешенном состоянии.
  • Gateway является компонентом с управляемой нагрузкой: ограничения количества одновременно работающих воркеров, управление потоком и сброс нагрузки входят в объём v1 (см. раздел «Производительность»).
Поскольку Gateway одновременно хранит расшифровку диалога и инициирует весь трафик к провайдеру, сеанс не зависит от местоположения: перемещение цикла между Gateway и воркером ничего не меняет ни на стороне провайдера, ни в пути данных UI. Именно это делает передачу работы и возврат результатов недорогими.

​
Компоненты

​
1. Автомат состояний среды + контракт провайдера

environments.* в протоколе Gateway сейчас представляет собой проекцию только состояния. Устойчивым ядром служат принадлежащая SQLite запись среды и автомат состояний, спроектированные до определения форм RPC: requested → provisioning → bootstrapping → ready → (attached|idle) → draining → destroying → destroyed | failed | orphaned
  • Подготовка устойчива к сбоям: запись о намерении сохраняется до вызова провайдера вместе с детерминированным идентификатором операции, поэтому после перезапуска Gateway может принять выполняющуюся аренду вместо повторного выделения или создания бесхозной оплачиваемой машины.
  • Согласование после перезапуска и сборщик бесхозных ресурсов (провайдер inspect в сравнении с локальными записями) являются требованиями v1, а не дополнительными мерами повышения надёжности.
Контракт провайдера (реализуется плагином; в ядре нет названий провайдеров или политик):
RPC: environments.create, environments.destroy, расширенный environments.list/status (провайдер, идентификатор аренды, состояние, возраст, время простоя, подключённые сеансы). Первые провайдеры: оболочка CLI аренды в стиле Crabbox (основной путь продукта) и провайдер статического SSH-хоста с пометкой «только для разработки» — воркер на общем хосте может читать посторонние данные хоста, поэтому статические хосты предназначены для разработки функции, а не являются стандартной моделью эксплуатации.

​
2. Начальная загрузка воркера: установка OpenClaw на машину

Без отдельного артефакта воркера и без зависимости от доступности npm:
  • Канонический способ установки для всех режимов: сформированный Gateway пакет воркера с хешем содержимого (собственные выходные данные сборки Gateway, упакованные в tar-архив), передаваемый по SSH и устанавливаемый на машине. По определению это охватывает сборки для разработки и ещё не выпущенные коммиты.
  • npm i -g openclaw@<exact gateway version> является оптимизацией, когда Gateway выполняет выпущенную версию; никогда latest.
  • Начальная загрузка идемпотентна; при совпадении хеша пакета установка на тёплой арендованной машине пропускается. Для чистых машин может потребоваться этап установки инструментальной среды с доступом к сети (среда выполнения Node) — это часть этапа настройки, после которого доступ закрывается.
  • Рукопожатие проверяет хеш сборки воркера, набор возможностей протокола и совместимость среды выполнения. Существующих проверок версии и протокола Gateway для этого недостаточно (Node, подключённые через SSH-туннель, освобождены от отклонения при несовпадении точной версии), поэтому при допуске воркера выполняется отдельная проверка точного соответствия сборки.
Режим воркера (openclaw worker) — это точка входа, а не ответвление: обработка подключений вместе со встроенным исполнителем агента, при этом хранение сеанса и вызовы моделей обеспечиваются RPC Gateway. Он не должен запускать поверхности Gateway: никаких каналов, никакого автоматического запуска плагинов за пределами набора инструментов сеанса, временный каталог состояния, никаких локальных профилей аутентификации.

​
3. Транспорт: всё через SSH

Подключением управляет Gateway; воркеру не требуется ничего, кроме sshd:
  • Gateway открывает SSH-подключение к воркеру (учётные данные из аренды провайдера, ключ хоста закреплён из результата подготовки — без StrictHostKeyChecking=no) и создаёт обратный туннель, перенаправляющий локальный сокет воркера на конечную точку WS Gateway.
  • Управляющий трафик и трафик моделей, а также передача рабочей области используют отдельные SSH-подключения с одним и тем же закреплённым доверенным материалом, чтобы rsync не блокировал потоки токенов в начале очереди.
  • Жизненным циклом туннеля (проверка активности, повторное подключение с задержкой) управляет среда выполнения окружения на Gateway. Кратковременный разрыв туннеля незаметен на уровне сеанса: устойчивое состояние протокола (ниже) позволяет воркеру повторно подключиться и продолжить работу.

​
4. Протокол воркера (выделенный; не протокол Node)

Анализ текущих интерфейсов Node с позиции потенциального злоумышленника исключил их прямое повторное использование: ожидающие вызовы Node представлены локальными для процесса промисами, которые исчезают вместе с подключением, ключи идемпотентности Node разбираются, но не используются для устранения дубликатов, и, что имеет решающее значение, подключённый Node может отправлять обычные события Node (включая запросы на запуск агента), поэтому «тип Node + ограничение возможностей» не является границей безопасности входящего трафика. Поэтому воркеры получают аутентифицированную роль worker с закрытым версионируемым разрешённым списком RPC и событий; подключения воркеров не могут обращаться ни к одному устаревшему обработчику событий Node. Идентификация и учётные данные: при подготовке создаются краткосрочные учётные данные воркера, привязанные к идентификатору среды, ключу воркера, хешу пакета, единственному разрешённому сеансу, разрешённому набору RPC и сроку действия. Сопряжение с проверкой через SSH по-прежнему применяется (мы подготовили машину и владеем ключом), но авторизация определяется созданными учётными данными, а не заявленной поверхностью Node. Семантика устойчивых операций (форма заимствована у существующей среды выполнения ACP и её журнала событий — стабильные дескрипторы, последовательное выполнение для каждого сеанса, устойчивое повторное воспроизведение (session, seq)):
  • Каждая операция ограничена областью действия (sessionId, lifecycleRevision, runId, ownerEpoch, streamKind, seq).
  • Эпохи владения отсекают устаревшие рабочие процессы: заменяющий рабочий процесс увеличивает эпоху; запоздалые результаты из старой эпохи детерминированно отклоняются.
  • Доставка как минимум один раз с сохранёнными курсорами ACK и кэшированными терминальными результатами в SQLite; дедупликация детерминирована. Гарантии доставки ровно один раз отсутствуют.
  • Явные кадры для отмены, закрытия, возобновления и терминальных результатов; управление потоком на основе кредитов/окон в потоках.
  • Согласование возможностей протокола не зависит от общей версии протокола узлов.

​
5. RPC серверной части сеансов

Два отдельных контракта — текущая кодовая база разделяет устойчивые изменения транскрипта (под управлением менеджера сеансов, дерево JSONL с состоянием родителя/листа) и локальные для процесса события в реальном времени (потоковые дельты, жизненный цикл инструментов, подтверждения), и протокол рабочего процесса должен сохранять это разделение:
  • Устойчивые фиксации транскрипта: рабочий процесс отправляет семантические пакеты добавлений с runEpoch + сравнением и заменой базового листа; менеджер сеансов Gateway генерирует идентификаторы записей и родительские идентификаторы. Рабочий процесс никогда не может предоставлять доверенные строки транскрипта, идентификаторы записей, родительские идентификаторы или идентификаторы чужих сеансов.
  • Воспроизводимые события в реальном времени: типизированное объединение событий с порядковыми номерами рабочего процесса, ACK от Gateway, ограниченным хранением и отсечением запоздалых событий, передаваемое в существующую рассылку событий агента, чтобы представление чата, строки инструментов и логика непрочитанных сообщений/статуса работали так же, как для локальных сеансов.
Прокси вывода: повторно использовать словарь событий существующего клиента потока прокси среды выполнения (src/agents/runtime/proxy.ts), но перенести границу доверия. Рабочий процесс отправляет только идентификаторы сеанса/запуска, одобренную ссылку на модель, контекст и ограниченные параметры генерации; Gateway определяет поставщика, конечную точку, аутентификацию, заголовки, маршрутизацию и политику расходов по собственному каталогу. Предоставленный рабочим процессом объект модели (например, контролируемый злоумышленником baseUrl) отклоняется. Применяются ограничения размера запроса, отмена, аудит и повторное воспроизведение терминального результата. Инструменты, размещённые на Gateway (веб-поиск), выполняются на Gateway и возвращают результаты по тому же каналу.

​
6. Синхронизация рабочего пространства

Опорной точкой синхронизации служит локальное для Gateway рабочее пространство с исключительным владением размещением: для рабочих пространств git — отдельное управляемое рабочее дерево (основой служат существующие метаданные управляемого рабочего дерева — ветвь, база, владение снимком); для рабочих пространств без git — целевой каталог, принадлежащий Gateway. Никогда не используется рабочая копия пользователя. Исключительное владение во время удалённого размещения сеанса конструктивно исключает конфликты входящей синхронизации. Разделение владения — фиксация и публикация:
  • Агент на стороне рабочего процесса обычным образом создаёт коммиты в своей копии (git commit — локальная операция без учётных данных; данные автора проецируются из конфигурации Gateway). Эти коммиты остаются неактивными объектами, пока Gateway их не примет.
  • Gateway выполняет всё, что требует доверия: проверяет, что входящие коммиты основаны на записанной базе, перематывает локальное рабочее дерево вперёд, выполняет отправку, создаёт PR и при необходимости подписывает или переподписывает — всё с локальными учётными данными Gateway. Рабочий процесс никогда не получает учётные данные git или платформы размещения репозитория и никогда не обращается к удалённому репозиторию.
Два режима синхронизации, выбираемые в зависимости от того, является ли рабочее пространство репозиторием git:
  • Режим git. Исходящая синхронизация: синхронизация рабочего дерева через rsync (включая незакоммиченные и допустимые неотслеживаемые файлы; правила включения/исключения в стиле crabbox, с учётом .worktreeinclude) через SSH-идентификатор туннеля с записью неизменяемого базового манифеста (хэши содержимого + базовый коммит). Входящая синхронизация: новые коммиты возвращаются в виде пакета git или временной ссылки относительно записанной базы; неотслеживаемые артефакты возвращаются через явный манифест с проверками размера, типа и удержания символических ссылок в допустимых границах. При принятии проверяется происхождение от базы, а при расхождении процесс останавливается — ни одна из сторон не перезаписывается без уведомления. Удаления, переименования, подмодули и выходы символических ссылок за допустимые границы обрабатываются правилами манифеста, а не эвристиками rsync.
  • Обычный режим (без git — например, при создании проекта с нуля на машине). Исходящая синхронизация использует те же rsync и базовый манифест. Входящая синхронизация представляет собой зеркалирование по разнице манифестов обратно в целевой каталог, принадлежащий Gateway, с распространением удалений. Безопасность обеспечивается по той же причине, что и в режиме git: исключительное владение означает отсутствие параллельных локальных изменений, способных вызвать конфликт; базовый манифест по-прежнему обнаруживает неожиданный локальный дрейф и останавливает процесс вместо перезаписи.
Контрольные точки защищают многодневные сеансы от потери аренды: периодические входящие контрольные точки (коммиты ветви сеанса в режиме git, снимки манифеста в обычном режиме); периодичность задаётся политикой профиля (по умолчанию — по ходам).

​
7. Конечный автомат размещения, сеансы и пользовательский интерфейс

Размещение среды выполнения — это управляемый SQLite конечный автомат, привязанный к сеансу, а не пара несвязанных полей строки: local → requested → provisioning → syncing → starting → active(worker) → draining → reconciling → local | reclaimed | failed Он сохраняет идентификатор среды, поколение перехода, эпоху активного владельца, базовый манифест рабочего пространства, хэш пакета рабочего процесса и последние курсоры ACK. Допуск хода атомарно захватывает размещение до того, как любой из циклов начнёт ход, поэтому локальное сообщение, допущенное на основе устаревшего снимка, никогда не может конкурировать с ходом рабочего процесса — в каждый момент времени сеансом владеет ровно один цикл. Пользовательский интерфейс:
  • Сеанс рабочего процесса — это обычная строка сеанса с метаданными размещения. Он хранится в обычном хранилище, выводится через sessions.list, передаётся потоково через существующие подписки — боковой панели и чату не нужен новый путь данных, только визуальное представление: значок рабочего процесса и статус размещения/среды (provisioning / syncing / running / idle / reconciling / reclaimed).
  • Интерфейс создания: на панели цели сеанса (обновлённая боковая панель сеансов) рядом с Gateway и Node появляется облачный рабочий процесс. Требуется настроенный профиль поставщика; до настройки функция скрыта.
  • Передача агентом: инструмент сеанса позволяет агенту передавать работу облачному рабочему процессу так же, как это делает человек (дочерний сеанс на рабочем процессе, в стиле субагента). Выпускается на том же этапе, что и передача человеком, и управляется той же добровольно включаемой конфигурацией поставщика. Рекурсия ограничена структурно (в v1 сеансы рабочих процессов не могут сами передавать работу другим рабочим процессам); контроль расходов реализуется через учёт и аудит по каждой среде, а не через механизм квот.

​
Передача и смена владельца

v1 намеренно асимметрична:
  • Локально → рабочий процесс (передача): пройти описанный ниже барьер миграции, подготовить или повторно использовать рабочий процесс, выполнить синхронизацию, переключить размещение; следующий ход выполняется удалённо.
  • Рабочий процесс → локально (возврат): остановить сеанс (дождавшись завершения работы рабочего процесса согласно тому же барьеру), завершить входящее согласование, переключить размещение на локальное. Это не миграция в реальном времени.
  • Симметричная смена владельца в реальном времени (перемещение активно работающего сеанса в обоих направлениях без остановки) повторно использует тот же барьер и механизмы согласования и выпускается после того, как испытания с внедрением сбоев подтвердят работу барьера.
Барьер миграции («границы хода» недостаточно — подтверждения, фоновые процессы и объединения транскрипта после освобождения блокировки могут пересекать её):
  1. Остановить допуск новых ходов (захват размещения).
  2. Отменить активные запуски или дождаться их завершения.
  3. Отозвать ожидающие подтверждения выполнения и разрешения на выполнение.
  4. Дождаться завершения побочных записей транскрипта и ACK событий в реальном времени.
  5. Завершить дочерние процессы рабочего процесса.
  6. Отсечь старого владельца, увеличив эпоху владельца.
  7. Согласовать рабочее пространство (входящая синхронизация с учётом конфликтов).
  8. Активировать нового владельца.
Привязка кэша: поскольку запросы к поставщику в обоих вариантах размещения исходят от Gateway, привязка кэша сохраняется, если сериализованный запрос к поставщику остаётся эквивалентным — тот же порядок инструментов, системные инструкции, обёртки поставщика и метаданные кэша (которые остаются на стороне Gateway). Это проверяемое свойство, а не предположение: тесты побайтовой эквивалентности локального размещения и размещения на рабочем процессе для каждого поддерживаемого транспорта поставщика входят в этап, на котором вводится цикл рабочего процесса.

​
Модель безопасности

Точная формулировка: рабочий процесс не имеет прямого исходящего сетевого доступа и постоянных учётных данных поставщика или платформы размещения репозитория. Это не «полное отсутствие исходящего трафика» — вывод и инструменты, выполняемые на Gateway, являются контролируемыми исходящими каналами (рабочий процесс, подвергшийся инъекции через запрос, всё ещё может поместить байты рабочего пространства в контекст модели или поисковые запросы). Соответственно:
  • Учёт контролируемого исходящего трафика: аудит по каждой среде и доступный оператору учёт для прокси вывода и инструментов Gateway. Ограничения скорости/объёма байтов существуют как управление потоком протокола (пропускной способностью), а не как механизм квот расходов.
  • Входящий доступ рабочего процесса к Gateway ограничен закрытым списком разрешённых операций протокола рабочего процесса; записи транскрипта структурно ограничены (идентификаторы генерируются Gateway, привязка к одному сеансу).
  • Выполнение команд рабочим процессом имеет полные разрешения в пределах машины. Машина одноразовая и не содержит учётных данных, поэтому подтверждение каждой команды добавляет трение, ничего не защищая; защищаемой границей являются входящее согласование и аудит. Выполнение команд никогда не проходит через путь подтверждения узла Gateway.
  • Политика интернета определяется поставщиком во время подготовки: профиль среды задаёт её при создании машины (брандмауэр/группа безопасности/сеть без исходящего доступа), при необходимости с сетевым этапом настройки, который поставщик закрывает перед этапом работы агента. Ядро не реализует переключатель сети во время выполнения.
  • Гигиена машины при подготовке: конечная точка облачных метаданных заблокирована либо подтверждено её отсутствие, профиль экземпляра отсутствует, SSH-агент не наследуется, сокет Docker отсутствует, окружение и домашний каталог чисты. Ключи узла SSH закрепляются по результатам подготовки.
  • Подтверждения и политики для всего, что выполняется на стороне Gateway (отправка, PR, вызовы поставщика), продолжают обрабатываться на Gateway.
Радиус поражения скомпрометированного сеанса рабочего процесса: синхронизированная копия рабочего пространства плюс возможности, разрешённые аудитируемыми прокси-каналами — без учётных данных, без прямого доступа к сети и без доступа к поверхностям Gateway за пределами списка разрешённых операций.

​
Пропускная способность

Gateway ретранслирует каждый запрос и поток токенов для N рабочих процессов, поэтому v1 задаёт модель пропускной способности, а не обнаруживает ограничения в рабочей среде: лимиты одновременных рабочих процессов для каждого Gateway, кредитные окна для каждого потока (текущая очередь потока событий не ограничена, а предел буфера сокета узла принудительно отключает медленных потребителей — оба механизма непригодны без изменений), ограниченная буферизация всплесков на диске и сброс нагрузки с видимыми в пользовательском интерфейсе состояниями обратного давления. Передача рабочего пространства выполняется по отдельному каналу SSH.

​
Жизненный цикл

  • Автоматическая остановка при бездействии и TTL задаются политикой профиля поставщика, а не фиксированными константами. Значения по умолчанию достаточно велики и предусматривают явное поддержание активности; многодневная работа является полноценным сценарием (для серверных частей на основе аренды существует renew поставщика); сеанс с выполняющимся ходом или недавней активностью никогда не освобождается.
  • При завершении работы или освобождении рабочего процесса: размещение переходит в reclaimed, строка сеанса сохраняется, следующее сообщение подготавливает новый рабочий процесс и повторно синхронизирует его с последней контрольной точки. Разговор никогда не теряется (хранилище на стороне Gateway); изменения рабочего пространства после последней контрольной точки теряются, и пользовательский интерфейс сообщает об этом.
  • Повторное использование тёплой аренды с первого дня (для поддерживающих его поставщиков); снимок образа после начальной настройки — путь быстрого запуска в v2.

​
Поверхность конфигурации

Минимальная и добровольно включаемая: блок профиля поставщика (идентификатор поставщика, учётные данные/ссылка на CLI, правила синхронизации, политика времени жизни, бюджеты, необязательный этап настройки) плюс выбор размещения для каждого сеанса. Новые переменные среды отсутствуют. В ненастроенных установках функция не отображается.

​
Этапы

Реализация добавляется небольшими, независимо объединяемыми PR; каждый этап ниже представляет собой серию PR, а не одно изменение.
  1. Основы: конечный автомат состояния среды + контракт провайдера + провайдер в формате crabbox (статический SSH как стенд разработки), начальная загрузка пакета воркера + подтверждение допуска, SSH-туннель + закрепление ключа хоста, снимок управляемого рабочего дерева + исходящая синхронизация (режимы git + без git). Очистка потерянных ресурсов + восстановление управления после перезапуска.
  2. Протокол воркера + цикл воркера: аутентифицированная роль воркера, устойчивые операции/эпохи/курсоры ACK, фиксация стенограммы + контракты событий в реальном времени, прокси инференса с моделями, разрешёнными Gateway, управление потоком. Один провайдер, только ручная диспетчеризация новых сеансов, без передачи управления. Выход блокируется до прохождения тестов с внедрением сбоев (разрыв туннеля, перезапуск Gateway, отказ воркера).
  3. Диспетчеризация + обратное получение + диспетчеризация агентов: барьер миграции, конечный автомат размещения, подключённый к панели выбора целевой среды в UI, входящая сверка + контрольные точки, аудит для каждой среды, ограничения ёмкости, инструмент диспетчеризации агентов (сеансы воркеров не могут запускать рекурсию). Тесты побайтовой эквивалентности кэша промптов.
  4. Симметричная передача управления в реальном времени после подтверждения устойчивости к сбоям на этапе 3.
Позже: стенды ACP на воркерах с добровольным включением загрузки учётных данных для каждой среды; быстрый запуск из снимка/предварительно прогретого образа; веерный запуск (N аренд, один промпт); изоляция ОС внутри среды; более полный сбор артефактов по схеме артефактов.

​
Открытые вопросы

  • Доступность плагинов/Skills на воркерах: хранящиеся в репозитории Skills бесплатно синхронизируются с рабочей областью; для настроенных в Gateway Skills/плагинов агента требуется явное решение о синхронизации или исключении (в любом случае манифест инструмента/плагина входит в подтверждение допуска).
  • Периодичность контрольных точек по умолчанию: по ходам или по времени для очень активных сеансов.
  • Как профили среды взаимодействуют с маршрутизацией между несколькими агентами (профили по умолчанию для каждого агента или только выбор для каждого сеанса).