План облачных воркеров

Статус

Предложение, редакция 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, поскольку они самостоятельно выполняют инференс с собственными учётными данными.
• Нет веерного запуска нескольких параллельных попыток с выбором лучшей.
• Нет зависимости от VPN или tailnet. Передача данных осуществляется только по SSH.
• Нет новой среды выполнения песочницы. Границей изоляции служит машина рабочего узла; позднее поверх неё можно добавить песочницу на уровне ОС.
• В v1 нет симметричной динамической миграции: передача выполняется с локальной машины на рабочий узел; возврат с рабочего узла на локальную машину требует остановленного сеанса и завершённого согласования рабочего пространства. Динамическая двусторонняя передача впоследствии будет построена на том же механизме барьеров.
• На Gateway нет побочного состояния в JSON; состояние среды, размещения, курсоров и разрешений хранится в SQLite.

Аналоги (что мы заимствуем, а что меняем на противоположное)

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

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

Рассматривались три варианта размещения:

1. Цикл остаётся на Gateway, рабочий узел выполняет инструменты (модель Cursor). Самая безопасная область отказа (история диалога, инференс, подтверждения и восстановление после перезапуска остаются локальными) и предпочтительный для рецензента первый этап. Отклонено как архитектура продукта: инструменты OpenClaw, не связанные с выполнением команд, представляют собой внутрипроцессные операции с файловой системой, поэтому каждое чтение, редактирование или выполнение grep требует сетевого обмена либо крупной переработки поверхности инструментов в укрупнённые 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, а не дополнительными мерами усиления надёжности.

Контракт провайдера (реализуется Plugin; в ядре нет имён провайдеров или политик):

type WorkerProvider = {  id: string;  provision(profile: WorkerProfile, opId: string): Promise&lt;WorkerLease&gt;; // → ssh host/port/user/key material  inspect(lease: { leaseId: string; profile: WorkerProfile }): Promise&lt;LeaseStatus&gt;; // adopt/health/orphan sweep  renew?(leaseId: string): Promise<void>; // long-lived sessions vs provider TTLs  destroy(lease: { leaseId: string; profile: WorkerProfile }): Promise<void>; // idempotent, returns only on proof of teardown};

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: никаких каналов, никакого автоматического запуска Plugin сверх набора инструментов сеанса, временный каталог состояния, никаких локальных профилей аутентификации.

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

Gateway управляет подключением; рабочему узлу не требуется ничего, кроме sshd:

• Gateway открывает SSH-соединение с рабочим узлом (учётные данные из аренды провайдера, ключ хоста закрепляется из результата подготовки — без StrictHostKeyChecking=no) и создаёт обратный туннель, перенаправляющий локальный сокет рабочего узла на конечную точку WS Gateway.
• Трафик управления и моделей и передача рабочего пространства используют отдельные SSH-соединения с одними и теми же закреплёнными доверенными данными, чтобы rsync не блокировал потоки токенов в начале очереди.
• Жизненным циклом туннеля (keepalive, повторное подключение с задержкой) управляет среда выполнения окружения на 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; устранение дубликатов детерминировано. Гарантии однократной доставки нет.
• Явные кадры для отмены, закрытия, возобновления и конечных результатов; управление потоком на основе кредитов и окон.
• Согласование возможностей протокола не зависит от версии общего протокола Node.

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

Два отдельных контракта — текущая кодовая база отделяет долговечные изменения журнала диалога (принадлежащие диспетчеру сеансов, дерево JSONL с состоянием родительских и конечных узлов) от локальных для процесса событий реального времени (потоковые приращения, жизненный цикл инструментов, подтверждения), и протокол исполнителя должен сохранять это разделение:

• Долговечная фиксация журнала диалога: исполнитель отправляет семантические пакеты добавлений с runEpoch и операцией compare-and-swap относительно базового конечного узла; диспетчер сеансов Gateway генерирует идентификаторы записей и родительских записей. Исполнитель никогда не может предоставлять доверенные строки журнала диалога, идентификаторы записей, идентификаторы родительских записей или идентификаторы чужих сеансов.
• Воспроизводимые события реального времени: типизированное объединение событий с порядковыми номерами исполнителя, подтверждениями ACK от Gateway, ограниченным хранением и отсечением запоздалых событий, передаваемое в существующую рассылку событий агента, чтобы представление чата, строки инструментов и логика непрочитанного/состояния работали так же, как для локальных сеансов.

Прокси инференса: повторно использовать словарь событий существующего клиента потока прокси среды выполнения (src/agents/runtime/proxy.ts), но перенести границу доверия. Исполнитель отправляет только идентификаторы сеанса и запуска, одобренную ссылку на модель, контекст и ограниченные параметры генерации; Gateway самостоятельно определяет поставщика, конечную точку, аутентификацию, заголовки, маршрутизацию и политику стоимости по собственному каталогу. Предоставленный исполнителем объект модели (например, контролируемый злоумышленником baseUrl) отклоняется. Применяются ограничения размера запроса, отмена, аудит и повторное воспроизведение конечного результата. Инструменты, размещённые на Gateway (websearch), выполняются на 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 инструменты являются контролируемыми каналами исходящего трафика (исполнитель, подвергшийся атаке через внедрение в запрос, всё ещё может поместить байты рабочего пространства в контекст модели или запросы websearch). Соответственно:

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

Радиус поражения скомпрометированного сеанса исполнителя: синхронизированная копия рабочего пространства и данные, разрешённые проходящими аудит прокси-каналами — без учётных данных, прямого сетевого доступа и доступа к каким-либо поверхностям Gateway за пределами списка разрешённых операций.

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

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

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

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

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

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

Этапы

Реализация поставляется небольшими PR, которые можно сливать независимо; каждый этап ниже представляет собой серию PR, а не одно изменение.

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

Позднее: среды ACP на исполнителях с явно включаемым наполнением учётными данными для каждой среды; быстрый запуск из снимка/тёплого образа; веерная рассылка (N аренд, один запрос); изоляция ОС внутри машины; более полный сбор артефактов через схему артефактов.

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

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