План хмарних воркерів

Статус

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

Проблема

Сеанси агентів OpenClaw виконують свій цикл, інструменти та інференс усередині процесу Gateway на одній машині. Обчислювальні ресурси обмежені можливостями цієї машини, тривалі завдання займають її, а паралельні завдання конкурують за її ресурси. Хмарні продукти (хмарні агенти Cursor, Claude Code у вебверсії, хмарний Codex) розв'язують це за допомогою тимчасових хмарних пісочниць для кожного завдання, але потребують інфраструктури постачальника та довіри до нього.

Оператори, які вже мають резервні машини (або можуть дешево їх орендувати), не мають змоги вказати: виконай цей сеанс там, покажи його на моїй бічній панелі як будь-який інший сеанс, а потім утилізуй машину.

Цілі

• Виконувати повний сеанс агента (цикл + інструменти) на тимчасовій віддаленій машині («хмарному робочому вузлі»), водночас сеанс має відображатися й передавати дані потоково в інтерфейсі керування точно так само, як локальний сеанс.
• Жодних постійних облікових даних на робочому вузлі (автентифікації постачальника чи токенів forge) і жодного прямого вихідного мережевого трафіку; машині потрібен лише доступний sshd.
• Підготувати, синхронізувати, запустити, зібрати результати, знищити — повністю автоматизовано, зі змінними постачальниками (перший постачальник: CLI оренди в стилі Crabbox).
• Передавати поточне завдання з Gateway на робочий вузол на межі ходу без втрати транскрипту, ідентичності сеансу або (коли байти запиту залишаються еквівалентними) прив'язки до кешу постачальника; безпечно повертати результати.
• І люди (через інтерфейс), і агенти (через інструмент) можуть передавати роботу хмарному робочому вузлу.
• Підтримувати сеанси тривалістю в кілька днів; час існування визначається політикою, а не жорстко заданим обмеженням.

Нецiлi (v1)

• Жодних зовнішніх середовищ програмування (Claude Code, Codex CLI) на робочих вузлах. Сеанси робочого вузла виконують лише вбудований виконавець OpenClaw. Підтримка зовнішніх середовищ є добровільною функцією v2, оскільки вони самостійно виконують інференс із власними обліковими даними.
• Жодного розгалуження на найкращу з N / паралельні спроби.
• Жодної залежності від VPN/tailnet. Транспорт — лише SSH.
• Жодного нового середовища виконання пісочниці. Межа ізоляції — машина робочого вузла; ізоляцію засобами ОС усередині машини можна додати пізніше.
• У v1 немає симетричної живої міграції: передавання відбувається з локальної машини на робочий вузол; повернення з робочого вузла на локальну машину потребує зупиненого сеансу та завершеного узгодження робочого простору. Живе двостороннє передавання керування пізніше спиратиметься на той самий механізм бар'єрів.
• Жодного побічного стану у форматі JSON на Gateway; стан середовища, розміщення, курсорів і дозволів зберігається в SQLite.

Попередні рішення (що ми копіюємо, а що змінюємо на протилежне)

• Хмарні агенти Cursor: цикл агента виконується в їхній хмарі; VM є цільовим середовищем виконання інструментів; сховище розмови лише з дописуванням потоково передається всім клієнтам; знімок після встановлення забезпечує швидкий теплий запуск; самостійно розгорнуті робочі вузли є процесами лише з вихідними з'єднаннями. Ми копіюємо модель потокового передавання та принцип «джерело істини для розмови залишається в оркестраторі»; розміщення циклу змінюємо на протилежне (див. рішення нижче).
• Хмарний Codex: двофазне середовище виконання — етап налаштування з доступом до мережі, а потім автономний етап агента з вилученими секретами; кеш стану контейнера для швидких наступних запусків. Ми копіюємо поділ на етапи як модель вихідного трафіку та ідею кешу для теплих образів у v2.
• Claude Code у вебверсії: окрема VM для кожного сеансу; git-проксі з ізоляцією облікових даних (справжні токени ніколи не потрапляють до пісочниці, а push обмежений гілкою сеансу); знімок файлової системи після налаштування; передавання через teleport = надіслана гілка + відтворена історія. Ми копіюємо ізоляцію облікових даних і модель передавання керування, але вихідна синхронізація виконується через rsync із Gateway, тож підтримуються робочі дерева з незбереженими в комітах змінами, а токен forge не існує навіть поблизу машини.
• Агент програмування Copilot: вихідний трафік типово заборонено, крім реєстрів пакетів із дозволеного списку. Наш типовий режим стабільної роботи суворіший (прямий вихідний трафік повністю відсутній), оскільки інференс і вебпошук надходять через тунель SSH, — але пояснення, чому це «контрольований вихідний трафік», а не «нульовий вихідний трафік», див. у розділі «Безпека».

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

Розглядалися три варіанти розміщення:

1. Цикл залишається на Gateway, робочий вузол виконує інструменти (модель Cursor). Найбезпечніша область відмови (транскрипт, інференс, схвалення та відновлення після перезапуску залишаються локальними) і бажаний для рецензента перший етап. Відхилено як архітектуру продукту: інструменти OpenClaw, що не виконують команди, є внутрішньопроцесними операціями файлової системи, тому кожне читання, редагування чи пошук через grep у файлах перетворюється на мережевий обмін або потребує значного рефакторингу поверхні інструментів у грубі RPC робочого простору; поведінка середовища виконання передбачає багато обмінів і залежить від затримки. Ми повторно використовуємо дух цієї моделі там, де її вже реалізовано (винесення виконання команд на Node), але не створюємо рівень віддаленого виклику інструментів.
2. І цикл, і інференс виконуються на робочому вузлі. Найпростіша область відмови, але облікові дані моделей (зокрема профілі OAuth) доведеться передавати на тимчасові машини, Gateway втрачає контроль над політиками, маршрутизацією та аудитом, а міграція змінює ідентичність, від якої викликається постачальник, що робить кеші постачальника недійсними.
3. Цикл + інструменти виконуються на робочому вузлі, виклики моделі проксіюються через Gateway. Обрано. Один мережевий обмін на хід моделі замість обміну для кожного виклику інструмента; інструменти працюють поруч із кодом; Gateway залишається єдиним власником профілів автентифікації, маршрутизації постачальників і політик; робочий вузол не зберігає секретів.

Ціною варіанта 3 є синхронна залежність від Gateway під час кожного ходу моделі, тому правила її надійності є частиною рішення, а не пізнішим доповненням:

• Втрата Gateway посеред ходу спричиняє збій активного виклику постачальника. Хід позначається як невдалий і після повторного підключення виконується як новий; прозорого повторного відтворення поточного потоку постачальника немає через ризик подвійної оплати або подвійного виклику інструмента.
• Кожна операція між робочим вузлом і Gateway містить стійкі ідентифікаційні дані (див. «Протокол робочого вузла»), тому після повторного підключення операції відновлюються або отримують кешовані кінцеві результати, а не зависають.
• Gateway є компонентом із керованою місткістю: обмеження кількості одночасних робочих вузлів, керування потоком і скидання навантаження входять до обсягу v1 (див. «Місткість»).

Оскільки Gateway одночасно зберігає транскрипт та ініціює весь трафік до постачальника, сеанс не залежить від розташування: переміщення циклу між Gateway і робочим вузлом нічого не змінює на боці постачальника та в каналі даних інтерфейсу. Саме це робить передавання й повернення недорогими.

Компоненти

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 та операцією порівняння й заміни відносно базового листового вузла; менеджер сеансів Gateway генерує ідентифікатори записів і батьківських записів. Воркер ніколи не може надавати довірені рядки транскрипту, ідентифікатори записів, батьківські ідентифікатори чи ідентифікатори сторонніх сеансів.
• Відтворювані події в реальному часі: типізоване об’єднання подій із порядковими номерами воркера, підтвердженнями ACK від Gateway, обмеженим зберіганням і відсіканням запізнілих подій, яке передає дані до наявного розгалуження подій агента, щоб подання чату, рядки інструментів і логіка непрочитаного вмісту та станів працювали так само, як для локальних сеансів.

Проксі висновування: повторно використати словник подій наявного клієнта проксі-потоку середовища виконання (src/agents/runtime/proxy.ts), але перенести межу довіри. Воркер надсилає лише ідентичність сеансу й запуску, схвалене посилання на модель, контекст та обмежені параметри генерації; Gateway визначає постачальника, кінцеву точку, автентифікацію, заголовки, маршрутизацію та політику витрат із власного каталогу. Об’єкт моделі, наданий воркером (наприклад, контрольований зловмисником baseUrl), відхиляється. Застосовуються обмеження розміру запиту, скасування, аудит і повторне відтворення кінцевого результату. Інструменти, що працюють на Gateway (вебпошук), виконуються на Gateway і повертають результати через той самий канал.

6. Синхронізація робочого простору

Точкою прив’язки синхронізації є локальний для Gateway робочий простір з ексклюзивним володінням розміщенням: для робочих просторів git — окреме кероване робоче дерево (основою є наявні метадані керованого робочого дерева — гілка, база, володіння знімком); для робочих просторів без git — цільовий каталог, що належить Gateway. Ніколи не використовується активна робоча копія користувача. Ексклюзивне володіння під час віддаленого розміщення сеансу конструктивно усуває конфлікти вхідної синхронізації.

Розподіл відповідальності — фіксація проти публікації:

• Агент на боці воркера звичайним чином створює коміти у своїй копії (git commit є локальною операцією без облікових даних; ідентичність автора проєктується з конфігурації Gateway). Ці коміти залишаються неактивними об’єктами, доки Gateway їх не прийме.
• Gateway виконує все, що потребує довіри: перевіряє, що вхідні коміти побудовано на записаній базі, перемотує локальне робоче дерево вперед, виконує push, створює 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 і вузлом. Потрібен налаштований профіль постачальника; до налаштування функція невидима.
• Делегування агентом: інструмент сеансу дає агенту змогу передати роботу хмарному воркеру так само, як це робить людина (підсеанс на основі воркера, у стилі підагента). Постачається в тому самому етапі, що й делегування людиною, та обмежується тією самою добровільно ввімкненою конфігурацією постачальника. Рекурсія структурно обмежена (у v1 сеанси воркерів не можуть самі делегувати роботу іншим воркерам); контроль витрат реалізовано як облік і аудит для кожного середовища, а не як механізм квот.

Делегування та передавання керування

v1 навмисно асиметрична:

• Локально → воркер (делегування): пройти описаний нижче бар’єр міграції, підготувати або повторно використати воркер, синхронізувати, перемкнути розміщення; наступний хід виконується віддалено.
• Воркер → локально (повернення): зупинити сеанс (дочекатися завершення роботи воркера відповідно до того самого бар’єра), завершити вхідне узгодження, перемкнути розміщення на локальне. Це не міграція наживо.
• Симетричне передавання наживо (переміщення активно працюючого сеансу в обох напрямках без зупинки) повторно використовує той самий бар’єр і механізм узгодження та постачається після того, як тести з ін’єкцією збоїв підтвердять роботу бар’єра.

Бар’єр міграції (самої лише «межі ходу» недостатньо — схвалення, фонові процеси та злиття транскрипту після звільнення блокування можуть її перетинати):

1. Зупинити допуск нових ходів (резервування розміщення).
2. Скасувати активні запуски або дочекатися їх завершення.
3. Відкликати схвалення виконання та дозволи на виконання, що очікують.
4. Дочекатися завершення побічних записів транскрипту та ACK подій у реальному часі.
5. Завершити дочірні процеси воркера.
6. Відсікти старого власника, збільшивши епоху власника.
7. Узгодити робочий простір (вхідна синхронізація з урахуванням конфліктів).
8. Активувати нового власника.

Спорідненість кешу: оскільки запити до постачальника в обох варіантах розміщення надходять із Gateway, спорідненість кешу зберігається, коли серіалізований запит до постачальника залишається еквівалентним — той самий порядок інструментів, системні інструкції, обгортки постачальника та метадані кешу (які залишаються на боці Gateway). Це властивість, яку можна перевірити, а не припущення: тести побайтової еквівалентності між локальним розміщенням і розміщенням на воркері для кожного підтримуваного транспорту постачальника входять до етапу, що запроваджує цикл воркера.

Модель безпеки

Точне формулювання: воркер не має прямого вихідного мережевого доступу та постійних облікових даних постачальника або платформи розміщення репозиторіїв. Це не «нульовий вихідний доступ» — висновування та інструменти, що виконуються на Gateway, є контрольованими вихідними каналами (воркер, у який впроваджено шкідливу інструкцію, усе одно може помістити байти робочого простору в контекст моделі або запити вебпошуку). Відповідно:

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

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

Місткість

Gateway ретранслює кожну підказку та потік токенів для N воркерів, тому v1 визначає модель місткості замість того, щоб виявляти її обмеження у виробничому середовищі: ліміти одночасних воркерів для кожного Gateway, вікна кредитів для кожного потоку (поточна черга потоку подій необмежена, а граничний розмір буфера сокета вузла примусово від’єднує повільних споживачів — обидва варіанти непридатні без змін), обмежене буферування сплесків на диску та скидання навантаження з видимими в інтерфейсі станами зворотного тиску. Передавання робочого простору залишається в окремому SSH-каналі.

Життєвий цикл

• Автоматична зупинка в разі бездіяльності та TTL є політикою профілю постачальника, а не фіксованими константами. Типові значення щедрі, з явним підтриманням активності; багатоденна робота є повноцінним сценарієм (для серверних частин на основі оренди постачальник має renew); сеанс із незавершеним ходом або нещодавньою активністю ніколи не вилучається.
• У разі відмови або вилучення воркера: розміщення переходить у стан reclaimed, рядок сеансу зберігається, наступне повідомлення готує новий воркер і повторно синхронізує його з останньої контрольної точки. Розмова ніколи не втрачається (сховище на боці Gateway); зміни робочого простору після останньої контрольної точки втрачаються, і інтерфейс повідомляє про це.
• Повторне використання прогрітої оренди підтримується з першого дня (для постачальників, які це підтримують); знімок образу після початкового налаштування є шляхом швидкого запуску у v2.

Поверхня конфігурації

Мінімальна та добровільно ввімкнена: блок профілю постачальника (ідентифікатор постачальника, облікові дані або посилання CLI, правила синхронізації, політика тривалості, бюджети, необов’язковий етап налаштування) та вибір розміщення для кожного сеансу. Без нових змінних середовища. У неналаштованих інсталяціях нічого не відображається.

Етапи

Реалізація надходить як невеликі PR, які можна зливати незалежно; кожен наведений нижче етап є серією PR, а не однією зміною.

1. Основи: автомат станів середовища + контракт постачальника + постачальник у формі crabbox (static-SSH як середовище розробницьких випробувань), початкове налаштування пакета воркера + рукостискання допуску, SSH-тунель + закріплення ключа хоста, знімок керованого робочого дерева + вихідна синхронізація (режими git і простий). Очищення покинутих ресурсів + відновлення після перезапуску.
2. Протокол воркера + цикл воркера: автентифікована роль воркера, довговічні операції/епохи/курсори ACK, контракти фіксації транскрипту й подій у реальному часі, проксі висновування з моделями, визначеними Gateway, керування потоком. Один постачальник, лише делегування нових сеансів людиною, без передавання керування. Для завершення етапу обов’язкові тести з ін’єкцією збоїв (розрив тунелю, перезапуск Gateway, відмова воркера).
3. Делегування + повернення + делегування агентом: бар’єр міграції, автомат станів розміщення, під’єднаний до панелі цільового розташування інтерфейсу, вхідне узгодження + контрольні точки, аудит для кожного середовища, обмеження місткості, інструмент делегування агентом (сеанси воркерів не можуть створювати рекурсію). Тести побайтової еквівалентності кешу підказок.
4. Симетричне передавання керування наживо після підтвердження тестами з ін’єкцією збоїв на етапі 3.

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

Відкриті питання

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