Rigs та ізольовані середовища

Rig — це одноразова машина, якою агент керує в реальному часі: браузер, робочий стіл Linux, емулятор Android, симулятор iOS або машина за ізольованим терміналом. Більшість rig — це ВМ; керовані хостом мобільні симулятори — явний виняток. Ця сторінка пояснює кожну межу і те, чому все влаштовано саме так. Щоб відкрити середовище, див. Дати агенту машину для тестів; точні дії, порти та типові значення — у довідці з rigs.

Чому ВМ, а не пісочниця

Нативна пісочниця загортає процес в ізоляцію просторів імен — справжню, але вона ділить із вами ядро й обмежує процес, а не комп’ютер. Щойно агенту треба поклацати в застосунку для робочого столу, відрендерити сторінку в справжньому браузері або провести експерименти з rm -rf, про які ви воліли б не думати, чесна межа — це машина: власне ядро, власний диск, власний мережевий стек.

Ізольовані поверхні використовують два бекенди ВМ:

• мікроВМ для термінала й браузера — запуск гіпервізора менш ніж за секунду з контейнерних образів, закріплених за дайджестом.
• QEMU для повноцінного робочого столу Linux, якому потрібен пристрій відображення, якого мікроВМ не має.

Мобільні поверхні керуються хостом і прямо заявляють про слабшу межу:

• Android керує емулятором Google через ADB.
• iOS створює й володіє пристроєм CoreSimulator на хості Mac і керує ним через WebDriverAgent. Пристрій та його дані видаляються, коли rig закривається, але його мережа використовує мережу хоста Mac.

Ізольовані rig пишуть в одноразовий оверлей поверх базового образу лише для читання, тож один rig не може змінити те, з чого стартує наступний. Rig iOS володіє одноразовим пристроєм CoreSimulator, який видаляється, коли rig закривається. Android приєднується до емулятора на хості, що переживає сесію.

Вихід: за замовчуванням заборонено

Мережа rig починається з нічого. Хости допускаються для кожного rig окремо через шлюз, який гість не може обійти: єдині шляхи назовні — ті, що створила конфігурація запуску. Ізольований термінал отримує базовий набір розробника (реєстри пакетів, хостинги коду, дзеркала apt); браузерний rig допускає сайт продукту (usectrl.dev) і стартує з локальної сторінки file://, якій не потрібен вихід; усе інше відхиляється під час з’єднання.

Android та iOS цим шлюзом не охоплені. Їхній емулятор і симулятор на хості використовують мережу хост-сервера, тож інтерфейс і звіт про можливості зазначають, що вихід тут не обмежується, і ніколи не пропонують оманливого елемента керування «перезапустити без обмежень».

Вихід і облікові дані — це одна політика, побачена з двох боків: брокер облікових даних (нижче) не випустить токен для хоста, до якого гість не може дістатися.

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

Введення йде через гіпервізор, захоплення — через гостя

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

Два канали відображення

У людини, яка спостерігає, і в моделі, яка керує, потреби протилежні, тож rig обслуговує два незалежні потоки:

• Людський канал — повна роздільність під розмір вашої панелі, яка переузгоджується під час зміни розміру; сервер передає її як непрозорі байти. Сервер ніколи не декодує кадр, бо відеодекодер на шляху запиту — саме те, що заважає йому відповідати на RPC.
• Канал агента — це зменшені нерухомі знімки, обмежені зручним для моделі розміром, по одному зображенню на результат інструмента; старіші кадри відкидаються під час компакції, а їхні текстові описи залишаються.

Жоден канал не поступається заради іншого: ви отримуєте плинну картинку, модель — дешеву.

Перехоплення керування — це вузьке місце, а не прохання

Ексклюзивне керування забезпечується примусово в єдиній точці, через яку проходить кожна дія, — а не проханням до моделі поводитися як слід. Поки його утримує людина, сервер відхиляє змінювальні дії агента. Агент зберігає свої дії спостереження (знімки екрана, видобування), щоб описувати те, що ви робите, і про перехоплення йому повідомляють через канал коригування, а не лишають виявляти його через відхилені клацання. Клацання й уведення тексту на полотні працюють, коли цей замок не тримає ніхто інший — або коли його тримаєте ви; статусний ярлик показує Керування у вас. Кожна подія введення — ваша й агента — потрапляє до журналу аудиту цього rig із зазначенням суб’єкта й монотонної послідовності, тож питання «хто це клацнув» залишається з’ясовним і після зникнення машини.

Вміст перетинає межу; машини залишаються окремими

Копіювання й вставлення працюють в обидва боки, як і перетягування файлів усередину й назовні, — але rig — це інший комп’ютер, і задум цього не приховує.

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

Перетинання контролюється окремо для кожного користувача й кожного напрямку, незалежно. Вставлення в rig дозволене за замовчуванням; копіювання з rig спершу запитує підтвердження (дозвіл на десять хвилин або Завжди дозволяти в Налаштування → Сервер → Rigs → Доступ до буфера обміну). Це ніколи не налаштування робочого простору: один учасник не може дати згоду за буфер обміну іншого учасника.

У macOS сполучення для перетинання — ⌘C/⌘V, і воно однозначне: ⌃C і далі доходить до оболонки гостя як переривання, яким воно й є. У Windows і Linux обидва сполучення — це те саме натискання, тож гість отримує його незміненим, а ваш буфер обміну перезаписується лише тоді, коли вміст гостя справді змінився. Переривання залишається перериванням.

Перетягнуті всередину файли копіюються в теку машини для перекинутих файлів, а потім пропонуються їй. Що саме означає «пропонуються», залежить від того, що можна зробити чесно: сторінка браузера отримує справжню подію перетягування в тій точці, де ви відпускаєте файл, тож зона завантаження поводиться точно так, як поводилася б із локальним файлом; робочий стіл отримує файли в ~/Drops, а їхні шляхи — у своєму буфері обміну, бо жоден хост не може синтезувати перетягування в довільний інструментарій Linux, не запустивши привілейований демон усередині гостя, — а саме цього цей задум не допускає. Результат каже, що саме сталося, тож CSV, перекинутий на зону завантаження, ніколи не повідомляється як завантажений, коли він лише файл у теці. Перекидання на ізольований термінал копіює файл усередину й набирає його шлях у гості біля запрошення — те, що оболонка справді може використати.

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

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

Облікові дані ніколи не живуть у гості

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

Що може цей токен, визначається, коли rig відкривається. Термінальний rig, який відкриває людина, отримує токен із правом запису, обмежений власним доступом цього учасника до хостингу коду. Rig, який відкрив агент, отримує токен лише для читання: помічник облікових даних git не відрізняє push від fetch, тож усередині гостя не можна запитувати правило push для кожного push так, як це робить шлюз запусків агентів на хості.

Worktree в rig — це супутник

Коли rig несе ваш репозиторій, авторитетним залишається worktree на хості. Копія синхронізується всередину під час завантаження (секрети на кшталт файлів .env виключено), а коміти повертаються лише коли ви просите — вони зчитуються в refs/rigs/<id>/*, ніколи не надсилаються й ніколи не витягуються у робочу копію. Ніщо всередині ВМ не може пересунути вашу гілку чи торкнутися вашого робочого дерева; злиття того, що створив rig, — завжди рішення людини, ухвалене на хості.

Порти без дір у захисті

Dev-сервер, запущений усередині термінальної ВМ, стає доступним — на вашій машині, у Browser (VM), за бажанням у вашій локальній мережі, за бажанням під dev-доменом із HTTPS — і при цьому машина ніколи не відкривається назовні. Карта портів гіпервізора фіксується під час завантаження, тож усе подальше переадресування йде двома вузькими каналами, які контролює хост: одним заздалегідь створеним вхідним мультиплексором, який відмовляється з’єднуватися з чимось, що гість насправді не слухає, і зворотними тунелями, які хост тримає відкритими для з’єднань, ініційованих гостем. HTTPS для dev-домену завершується на сервері з використанням локально випущеного центру сертифікації, чиї ключі ніколи не потрапляють до жодного гостя. Механіку описано в Пробросити порти з термінала.

Машини обмежені за своєю будовою

Rig не може стати улюбленцем:

• жорсткий TTL, який гість не може продовжити;
• драбина простою — припаркувати (vCPU зупинено, RAM залишається резидентною) після вікна простою й закрити після подвійного вікна; відкритий термінал або глядач, що спостерігає, вважаються «використанням»;
• бюджет пам’яті, який рахують у резидентних мегабайтах, а не в сесіях, бо припаркована ВМ звільняє CPU, але тримає кожен байт RAM; першою витісняється машина, яку використовували найдавніше, і ніколи — та, якою керує або за якою спостерігає людина;
• знищення під час завершення роботи сервера, а також прибирання осиротілих машин із міткою власника при наступному запуску, тож сервер, що впав, ніколи не лишає по собі гіпервізора, який нікому не підкоряється.

Перші завантаження підтягують закріплений образ машини; потім сервер у фоні кешує вже розпаковану копію, тож кожна наступна машина такого типу завантажується за секунди, а ізольований термінал стартує з уже встановленим базовим набором CLI, як у ранера, розміщеного на GitHub, — компілятори, Python, jq, архівні утиліти, — а не з мовним toolcache чи Docker. Образ «Комп’ютер» вбудовує той самий базовий набір CLI під час збірки, поруч із XFCE і браузерами.

Три браузери, а не один

«У мене працює» — це твердження про один рушій відображення. Тож браузерний rig — не «браузер», а Chromium, Firefox або WebKit, вибраний тоді, коли ви його відкриваєте, і rig виконує той, з яким його відкрили, протягом усього свого життя. Одна розмова може містити по одному з кожного: відкривши Firefox (VM) поруч із Chromium (VM), ви отримаєте дві машини, і навести обидві на ту саму сторінку — це і є порівняння. WebKit — найближче до Safari з усього, що працює на Linux: та сама лінія рушіїв, тож він виявляє прогалини, на які натрапляють користувачі Safari.

Дії однакові для всіх трьох; протоколи під ними — ні, і про відмінності говорять прямо, а не згладжують їх. Chromium розмовляє DevTools Protocol і надсилає кадри, тож його живий перегляд нічого не коштує, поки сторінка нерухома. Firefox розмовляє WebDriver BiDi, а WebKit — класичним WebDriver, і жоден із них не має скринкасту, тож їхні живі перегляди опитують — кілька кадрів за секунду, що годиться для спостереження за сторінкою, але не за анімацією. Там, де рушій справді чогось не може (Firefox не має перезавантаження з обходом кешу; WebKit не бачить виводу консолі, залогованого до завершення завантаження сторінки), відповідь каже про це, а не робить тихо щось інше.

Де rig живуть у продукті

Rig навмисно не є глобальним пунктом призначення. Живий перегляд — це вкладка в просторі або PR, де відбувається робота, прив’язана до тієї розмови, тож ваша вкладка й виклики browser_use агента адресують одну машину (по одній на рушій на браузерній поверхні). Те, чи rig можуть узагалі завантажуватися, — властивість хоста, тож можливості, образи, власні образи для робочого простору та список працюючих машин живуть у Налаштування → Сервер → Rigs. Керування ізольованим середовищем — це окремий клас дій обмежень, тож робочий простір, агент або простір можуть його дозволити, вимагати схвалення або заборонити зовсім; режими лише для читання забороняють його цілком.