openclaw worker

openclaw worker — це обмежена точка входу середовища виконання, призначена для запуску оркестратором хмарних робочих процесів у підготовленому робочому середовищі. Це не команда загального призначення для реєстрації робочих процесів вручну.

Gateway установлює відповідний пакет OpenClaw і відкриває зворотний SSH-тунель із фіксацією ключа хоста. Засіб запуску робочого процесу запускає цю команду з підготовленим призначенням. Команда підключається через локальний сокет, перенаправлений тунелем, і допускається зі спеціальною роллю worker.

Контракт запуску

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

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

Межа середовища виконання

Процес виконує звичайний вбудований цикл агента з обмеженим бекендом:

• Інструменти програмування read, write, edit, apply_patch, exec і process виконуються локально в робочому просторі робочого процесу.
• Виклики моделі використовують проксі висновування Gateway. Локальний профіль автентифікації моделі не завантажується.
• Записи транскрипту використовують RPC фіксації транскрипту Gateway.
• Оновлення потокового передавання та життєвого циклу інструментів використовують RPC подій у реальному часі Gateway.
• Приймаються лише призначені сеанс і хід.

Режим робочого процесу не запускає канали, HTTP-поверхні Gateway або автоматичний запуск плагінів поза набором інструментів призначеного сеансу. Він використовує одноразовий каталог стану й не має постійних облікових даних провайдера або forge.

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

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

Відхилення транскрипту stale-base-leaf аварійно зупиняє поточний запуск. Режим робочого процесу не повторює відхилену послідовність для іншого листа, тому дубльованої фіксації не створюється; будь-який ще не зафіксований хвіст цього запуску, що зберігається в пам’яті, втрачається. Повторний запуск належить власнику розміщення етапу 3, який має створити нове призначення на основі авторитетного транскрипту Gateway та реєстру фіксацій. Так само перезапуск процесу Gateway завершує очікуваний хід висновування з помилкою провайдера; повторно приєднатися до активного потоку висновування того самого процесу можна лише після повторного підключення тунелю або WebSocket робочого процесу.

Опис закритої RPC-поверхні робочого процесу див. у розділі Протокол Gateway, а архітектуру та модель безпеки — у розділі План хмарних робочих процесів.