Перейти до основного вмісту

Work: ізольовані робочі області

Work — вбудований інтерфейс агентів програмування Libre WebUI. Кожне завдання поєднує довговічну розмову, явний маршрут постачальника й окрему файлову систему /workspace. Модель може переглядати й змінювати файли, виконувати команди в контейнері Docker або Pod Kubernetes завдання та запускати попередній перегляд.

Work реалізовано безпосередньо, без Libre Claw або демона.

Лише довірені користувачі

Усі API потребують автентифікованого облікового запису з доступом. За замовчуванням доступ мають лише адміністратори; його можна відкрити всім активним користувачам на вкладці Керування користувачами в Налаштуваннях (папки хоста завжди залишаються доступними лише адміністраторам, оскільки підключають шляхи сервера). Work навмисно дозволяє виконувати довільні команди оболонки в пісочниці. Завдання використовують вихідний трафік, якщо вибрана іменована політика його не вимикає. Вважайте кожного допущеного користувача довіреним оператором середовища виконання, а не просто користувачем чату.

Основні можливості випуску​

  • Окремі режими Work і Chat із видимим перемикачем режиму.
  • Завдання в основному бічному списку, стабільні позиції й безпосереднє видалення.
  • Окрема ідентичність пісочниці та постійний том Docker або PVC Kubernetes для кожного завдання; середовище можна зупинити або створити заново без втрати файлів.
  • Розмова, стан запуску, активність інструментів, вибір моделі та власник завдання зберігаються в базі Libre WebUI.
  • Поточний автентифікований потік тексту асистента, розкритих постачальником міркувань, викликів і результатів інструментів, використання, навичок та змін стану.
  • Належні серверу навички робочого процесу навчають модель перевіряти, редагувати, тестувати й запускати попередній перегляд, не створюючи керівних файлів у проєкті.
  • Локальні моделі Ollama з інструментами, Ollama Cloud і налаштовані плагіни постачальників.
  • Адаптивний поділ «Розмова/Робоча область», розмір якого можна змінювати мишею й клавіатурою на настільному екрані, і перемикач на невеликих екранах.
  • Вбудовані подання «Файли», «Активність», Git, «Термінал», «Попередній перегляд» і «Екран»; «Екран» представляє робочий стіл Work Computer.
  • Підсвічування синтаксису у світлому й темному режимах, форматування у браузері, виявлення конфліктів збереження й тимчасові чернетки.
  • Закриване розкриття інформації для кожного користувача під час вибору віддаленого постачальника.
  • Повний переклад Work 25 мовами, зокрема рідна арабська розкладка справа наліво зі збереженням напрямку коду, шляхів, ID моделей і виводу зліва направо.

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

Архітектура​

Libre WebUI, а не модель чи браузер, вибирає імена пісочниці та робочої області, образ, підключення тому, користувача, обмеження, режим мережі й порт попереднього перегляду. Модель отримує лише такі інструменти:

  • list_files
  • read_file
  • write_file
  • delete_file
  • move_file
  • search_files
  • run_command
  • start_preview
  • stop_preview

delete_file і move_file не дозволяють вийти з робочої області, не переходять за символічними посиланнями, потребують явного рекурсивного прапорця для каталогу й не перезаписують місце призначення. Оскільки вони використовують файловий помічник, інструменти працюють і під час попереднього перегляду, коли run_command заблоковано.

Запити до моделі виконує серверна частина, а не контейнер Work, тому вони не залежать від мережевої політики контейнера.

Вимоги​

  • Для Docker потрібні встановлений досяжний демон і дозвіл серверному процесу викликати docker або програму з WORK_DOCKER_COMMAND.
  • Для Kubernetes потрібні облікові дані API, обмежені простором імен Role і RoleBinding, простір імен пісочниці й NetworkPolicies, які створює Helm за work.enabled=true.

Також:

  • Модель із підтримкою інструментів через справний Ollama чи Ollama Cloud або активний плагін доповнень чи чату з точною моделлю й обліковими даними адміністратора.
  • Достатньо пам’яті для образу середовища, проєктів і локальних залежностей.
  • Автентифікований обліковий запис із доступом до Work; за замовчуванням доступ мають лише адміністратори, але його можна відкрити всім активним користувачам.

Libre перевіряє оголошені можливості Ollama й відхиляє модель без tools. Модель плагіна має підтримувати протокол виклику інструментів свого постачальника. Відмова завершує запуск без непомітного перемикання.

Локальний запуск​

Найпростіший варіант на одному комп’ютері:

docker info
npx libre-webui@latest

Відкрийте http://localhost:8080, увійдіть як адміністратор, виберіть Work, сумісну модель та опишіть завдання.

Якщо Docker відсутній або недоступний, Work показує Середовище виконання недоступне із причиною та вимикає запуск. Команди ніколи не виконуються безпосередньо на хості.

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

Інтерфейс Work​

Створення й повторне відкриття​

Виберіть Work, введіть інструкцію, виберіть модель і натисніть Запустити. Перше повідомлення створює завдання, перший запуск, маршрут постачальника й постійну робочу область.

Завдання залишається на головній бічній панелі. Повторне відкриття відновлює нещодавню розмову, вкладку «Файли», поточних постачальника й модель, а також робочу область. Старі повідомлення завантажуються сторінками. Завдання можна перейменувати за заголовком і видалити з меню або бічної панелі.

Для завдання може бути активним лише один запуск; наступна інструкція використовує ту саму розмову й файлову систему.

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

Наймання агента​

За наявності персон доступна дія Найняти як агента: завдання стає постійним іменованим агентом. Персона зберігається між запусками — її ім’я й системний промпт передують промпту Work, але контракт пісочниці завжди має пріоритет. Бічна панель розміщує агентів у групі Агенти над одноразовими завданнями, показуючи аватар, активність і стан. Коли бічна панель стиснута, у рейці залишаються лише ці закріплені аватари агентів; одноразові завдання Work повертаються, щойно панель розгорнуто.

Рядок стану має два рівні. Для найнятого агента після запуску виконується недорогий запит до моделі без інструментів, який просить статус приблизно з 8 слів («Вхідних немає. Готові 2 відповіді.»); відповідь обмежено одним рядком із 90 символів, а в разі помилки або тайм-ауту використовується перший рядок завершальної відповіді асистента. Одноразові завдання й невдалі запуски використовують лише цей детермінований варіант; WORK_STATUS_BLURB_MODEL=0 повністю вимикає запит. Відкриття завдання просуває монотонну позначку перегляду, синхронізовану між пристроями, а крапка показує пізніший кінцевий запуск.

Агенти повідомляють про роботу через сповіщення: work-run-finished, work-run-attention і work-takeover. Екранний банер видно лише на відкритій вкладці, тому push-сповіщення досягає користувача в іншому місці. Кожне посилання веде безпосередньо до агента.

Можна використовувати власну або спільну персону; спільний перегляд не розкриває спогадів власника. Після видалення персони агент продовжує працювати без неї й записує попередження. API приймає personaId і isAgent; завдання з персоною автоматично стає агентом.

Вкладка Agent​

Перша додаткова вкладка Agent:

  • Ідентичність: аватар, ім’я, індикатор активності й останній рядок стану.
  • Екран: за наявності Work Computer — компактна жива мініатюра лише для перегляду. Вона є повноцінним підключенням і враховується в обмеженні; клацання відкриває повний екран із перехопленням, навчанням і звуком.
  • Процедури: автоматизації, пов’язані із завданням. Кожне спрацювання виконується в тій самій робочій області й розмові з моделлю та середовищем агента, а не як нове завдання, тому ранковий звіт накопичується в одному місці. Рядки показують розклад і перемикач призупинення; форма + Процедура вже прив’язана до агента. Спрацювання для зайнятого агента коректно завершується work-task-busy, не потрапляючи до черги.
  • Автоперевірка: перемикач схвалень для цього агента й зібрані ним правила «дозволяти завжди» (видалення правила знову звужує його дію). Якщо політика завдання вимагає перегляду, перемикач заблоковано в увімкненому стані.
  • Навчені навички: продемонстровані процедури з перемикачем увімкнення.

Під’єднані інструменти (сервери MCP і OpenAPI)​

Агенти Work можуть викликати ті самі сервери інструментів, що налаштовані для Chat — MCP або OpenAPI, зареєстровані адміністратором у Налаштування → Інструменти. Агент бачить їх під просторовими іменами (server__tool), а виклики виконує бекенд Libre WebUI через захищений шлюз інструментів (вихідний трафік із захистом від SSRF, облікові дані окремого користувача, обмеження розміру й часу) — ніколи не з пісочниці.

Перелік чесно показує, що саме доступне автономному запуску:

  • Офлайнове завдання не отримує жодного: навіть якщо трафік іде з бекенда, завдання без мережі лишається офлайновим — та сама причина, що й для web_search.
  • Сервер, який потребує особистих облікових даних, не збережених користувачем, вилучається ще на етапі пропозиції, бо автономний запуск не може зупинитися й попросити їх. Додайте дані в Налаштування → Інструменти, і наступний запуск запропонує сервер.
  • Режим доступу до інструментів (лише адміністратори або всі користувачі) і видимість окремих серверів діють так само, як у Chat, а прив’язки серверів у персони звужують перелік для найнятого агента.
  • Коли діють схвалення, під’єднані інструменти, які сервер позначає як побічні, зупиняються на ваше рішення, як і будь-яка інша керована дія; інструменти лише для читання виконуються без запиту.

Делегування між агентами (@-згадки)​

Найняті агенти можуть передавати роботу один одному. Введіть @ у полі введення Work, щоб згадати іншого свого агента; поточний агент бачить у своїх інструкціях перелік колег (імена та рядки стану) і делегує відповідні запити інструментом message_agent. Делегування — це координація повідомленнями, свідомо не через спільні комп’ютери: кожен агент має власну ізольовану робочу область і пісочницю, а адресат не бачить розмови, з якої надійшов запит, — тому запит має нести власний контекст.

Делегування асинхронне. Інструмент повертає керування одразу, агент-адресат працює у власному завданні (у його розмові запит позначено Делеговано від відправника), а коли він завершує — успішно, з потребою даних, з помилкою чи скасуванням — його підсумкова відповідь надходить у розмову агента-делегувальника як повідомлення з позначкою Звіт від цього агента. Якщо делегувальник ще працює, звіт дістанеться моделі в наступному раунді; якщо він бездіяльний, звіт просто чекає в розмові — звіт ніколи не запускає новий запуск, тож два агенти не можуть безкінечно перекидатися повідомленнями. Делеговані запуски не можуть делегувати далі, зайнятий адресат чесно відхиляє спробу замість черги, а коли діють схвалення, message_agent зупиняється на перегляд, як і будь-яка інша дія з побічним ефектом (правило «дозволяти завжди» діє лише для того одного агента-адресата).

Схвалення дій (Автоперевірка)​

Дії з побічними ефектами можуть зупинятися на ваше рішення перед виконанням. Коли для завдання діють схвалення — політика Work має Вимагати схвалення для дій із побічними ефектами або ввімкнено перемикач агента Автоперевірка — запуск спиняється перед виконанням run_command, computer_act, delete_file, move_file чи message_agent і показує в розмові картку рішення: Дозволити один раз, Дозволяти завжди або Відхилити.

  • Дозволити один раз виконує саме цей виклик і запитає знову наступного разу.
  • Дозволяти завжди виконує виклик і зберігає правило для завдання: для файлових і комп’ютерних дій — на весь інструмент, для run_command — лише для програми команди (її першого слова), тож схвалення npm run build наперед дозволяє майбутні команди npm, а не всю оболонку, а для message_agent — лише для того одного агента-адресата. Правила перелічено в розділі Автоперевірка вкладки Agent, там же їх можна видалити.
  • Відхилити відмовляє у виклику. Моделі повідомляють, що користувач заборонив дію й повторювати її в тому самому вигляді не можна; запуск триває з цією відповіддю.

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

Схвалення обмежують дії, а не видимість: write_file й інструменти лише для читання лишаються без обмежень, а кожне рішення потрапляє до журналу аудиту безпеки.

Стан завдання​

ІнтерфейсСтан сервераКолір
Бездіяльністьidlergb(255, 255, 255)
Обробкаpreparing або runningrgb(48, 121, 255)
Готовоcompletedrgb(76, 212, 117)
Потрібні даніneeds_input або cancelledrgb(255, 204, 0)
Помилкаfailedrgb(255, 61, 129)

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

Активний запуск не блокує розмову: надіслане повідомлення приєднується одразу й досягає моделі в наступному раунді, даючи змогу спрямовувати, виправляти й додавати контекст без зупинки; кнопка зупинки залишається поруч із надсиланням.

Зміна розміру​

На настільній ширині xl розмову й робочу область розділено межею, яку можна перетягувати:

  • Ширина розмови за замовчуванням — 45%.
  • Бажаний діапазон — 30%–70% з урахуванням мінімальної ширини вмісту.
  • Збережена пропорція стосується користувача, який увійшов у цьому браузері.
  • Стрілки переміщують межу на 2%, а з Shift — на 10%.
  • Home і End вибирають доступний мінімум і максимум.
  • Enter або подвійне клацання скидають поділ.

Елементи керування відповідають напрямку письма. В арабській мові розмова міститься праворуч, робоча область — ліворуч, а вказівник і стрілки працюють в очікуваному візуальному напрямку.

На невеликих екранах використовуйте перемикач у заголовку завдання.

Файли​

Вкладка «Файли» переглядає безпосередній вміст /workspace, відкриває лише коректні текстові файли UTF-8 і зберігає зміни до тому завдання. Недопустимі послідовності байтів відхиляються, а не замінюються із втратою даних.

Редактор надає:

  • підсвічування синтаксису у світлому й темному режимах для поширених мов;
  • збереження через Cmd/Ctrl+S;
  • форматування через Shift+Alt+F;
  • оптимістичне виявлення конфліктів збереження;
  • чернетки для конкретного завдання й шляху в пам’яті сеансу; та
  • попередження під час переходу з незбереженими змінами.

Живе підсвічування призупиняється понад 8,000 символів або 400 рядків. Форматування доступне до 100,000 символів і 4,000 рядків для JavaScript/JSX, TypeScript/TSX, варіантів JSON, CSS/SCSS/Less, HTML, Markdown/MDX і YAML.

Коли модель змінює відкритий файл, вкладка показує червоно-зелене порівняння від початку ходу, згортаючи довгі незмінені ділянки. Перемикач змінює порівняння й редактор, а лічильники +added −removed дають стислий підсумок. За основу береться вміст, який браузер бачив до ходу; файл, уперше відкритий після нього, не показує відмінностей.

Чернетка слугує для зручності, а не як резервна копія; вона очищається після збереження, видалення завдання або завершення сеансу.

Активність​

Вкладка показує виклики й результати інструментів, операції з файлами, вивід команд і помилки. Метадані можна розгорнути. Вивід відображається зліва направо навіть в інтерфейсі справа наліво.

Активний запуск відкриває автентифікований потік SSE з такими подіями:

  • snapshot, run_state;
  • reasoning_delta, якщо постачальник розкриває міркування;
  • assistant_delta;
  • tool_call, tool_result;
  • usage;
  • skill_loaded; і
  • error, done.

Доступність міркувань залежить від моделі й постачальника; Libre показує лише вміст, повернутий API, і не може відновити прихований ланцюжок міркувань. Деякі моделі взагалі його не передають. Текст і дії інструментів можуть передаватися незалежно.

Вивід навмисно обмежено; обрізаний результат не доводить відсутності продовження. Попросіть модель перевірити вужчий результат.

Git​

Вкладка Git виконує локальні операції в /workspace:

  • ініціалізує репозиторій із гілкою main;
  • показує стан porcelain, відставання й випередження, а також до 20 комітів;
  • показує обмежене порівняння;
  • додає до індексу до 200 шляхів;
  • створює коміт з іменем і поштою адміністратора або локальною адресою no-reply;
  • створює гілку після першого коміту; та
  • перемикає наявну гілку за чистого робочого дерева.

Поверхня лише локальна: без clone, fetch, pull, push, керування віддаленими репозиторіями, довільних команд, токенів, SSH-ключів і pull request. Для цього потрібен окремий довірений посередник облікових даних, бажано GitHub App або еквівалентний інсталяційний токен, обмежений одним репозиторієм та операцією. Не зберігайте довгострокові облікові дані в робочій області, середовищі контейнера або конфігурації репозиторію.

Читання Git доступне для неактивного й активного завдання. Запис відхиляється, доки контейнером володіє запуск моделі, термінал або попередній перегляд; для перемикання гілки потрібне чисте дерево. Це запобігає перегонам.

Команди інтерфейсу використовують фіксовані масиви аргументів і виконуються як 1000:1000; введення не оцінюється оболонкою. Середовище вимикає системну й глобальну конфігурацію, підказки, хуки, помічники облікових даних, підпис, підмодулі, зовнішні порівняння, textconv і мережеві протоколи. Репозиторій відхиляється, якщо робоче дерево не дорівнює /workspace або каталог Git виходить за його межі. Запис також блокується за наявності виконуваного фільтра clean, smudge або process.

Це захищає Git API Libre WebUI. Адміністратор через термінал і модель через run_command усе одно можуть запускати звичайні команди Git, тому довільні команди обмежуються пісочницею й межею розгортання.

Вбудовані навички робочого процесу​

Кожен запуск отримує належний серверу довідник про постійну межу /workspace, кореневу систему лише для читання, тимчасові процеси й /tmp, мережу, обмеження та життєвий цикл попереднього перегляду. Навички приписують:

  • вивчити інструкції, маніфести, lock-файли, скрипти й стан репозиторію до редагування;
  • зберігати непов’язану роботу й об’єднувати незалежні читання;
  • продовжувати реалізацію, а не зупинятися на плані;
  • виконати цільову перевірку перед ширшою;
  • діагностувати помилку, а не сліпо повторювати; та
  • перевірити застосунок перед запуском попереднього перегляду як останнього довгого процесу.

Довідник існує лише в контексті моделі. Libre не створює AGENTS.md, каталог навичок або інший керівний файл. Інструкції проєкту не можуть перевизначити межу безпеки.

Термінал​

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

Вона використовує ту саму політику: непривілейований 1000:1000, каталог /workspace і захищений контейнер без можливостей. Термінал не надає більше прав, ніж run_command, а лише дає людині інтерфейс до тієї самої межі.

  • Автентифікація — звичайний заголовок Authorization обмінюється через HTTP на короткостроковий одноразовий квиток, пов’язаний із протоколом і точним завданням. У /ws/work-terminal присутні лише квиток і ID завдання. Перед кожним введенням повторно перевіряються обліковий запис, доступ, завдання й власник; відкликання закриває сеанс і звільняє оренду.
  • Перевірка походження — за CORS_ORIGIN або BASE_URL походження браузера має збігатися. Для віддаленого розгортання налаштуйте принаймні одне з них. Клієнти Electron і клієнти без браузера можуть не передавати Origin, але потребують того самого квитка й перевірки; керуйте ними через TLS, брандмауер і проксі.
  • Допуск — термінал отримує оренду середовища й враховується в WORK_MAX_ACTIVE_RUNTIMES_*.
  • Строк життя контейнера — підключений термінал утримує контейнер і не дає зупинити його як неактивний.
  • Паралельність — WORK_TERMINAL_MAX_SESSIONS_PER_TASK за замовчуванням дорівнює 2.
  • Тайм-аут бездіяльності — WORK_TERMINAL_IDLE_TIMEOUT_MS за замовчуванням дорівнює 15 хвилинам.
  • Активний запуск — термінал чекає завершення ходу моделі.

Термінал звертається безпосередньо до Docker Engine API, оскільки TTY потребує перехопленого двонапрямного потоку. Використовується WORK_DOCKER_SOCKET, потім DOCKER_HOST — сокет unix:// або звичайний HTTP tcp:// через проксі з тунелем Connection: Upgrade — і нарешті /var/run/docker.sock. Непідтримувані ssh:// або tcp:// з DOCKER_TLS_VERIFY роблять термінал недоступним із поясненням, не впливаючи на решту Work. Kubernetes використовує TTY WebSocket підресурсу exec API, зокрема зміну розміру, без Docker.

Інтерактивні сеанси не записуються, а команди не з’являються в «Активності».

Попередній перегляд​

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

  • скрипт dev у кореневому package.json із потрібними хостом і портом;
  • кореневий index.html, який обслуговує вбудований статичний сервер; або
  • єдиний застосунок у вкладеному каталозі.

Кореневий застосунок має пріоритет. Кілька рівноцінних вкладених застосунків або відсутність точки входу спричиняють зрозумілу помилку, а не випадкову команду npm. Для іншого проєкту вкажіть команду перед Запустити попередній перегляд; вона починається в /workspace, наприклад cd apps/web && npm run dev -- --host 0.0.0.0 --port 4173. Процес має слухати 0.0.0.0 і WORK_PREVIEW_PORT та стати готовим за 15 секунд.

Модель може використовувати start_preview — єдиний підтримуваний спосіб залишити довгий процес. run_command очищає фонові дочірні процеси після завершення.

Екран (Work Computer)​

Спостерігайте, як агент Work Libre WebUI шукає зображення й будує інтерактивну космічну галерею

Повна демонстрація: справжній невідредагований запуск (30x, потім у реальному часі), де агент самостійно переглядає NASA, вибирає фотографії, будує й тестує галерею Three.js з одного промпту.

Політика Work Computer додає вкладку «Екран»: живе вікно віртуального робочого стола в тій самій пісочниці — диспетчер вікон, панель і Chromium із роздільністю 1280×800. Можна спостерігати за агентом, перехоплювати мишу й клавіатуру, слухати звук комп’ютера та навчати діям показом. Відкриття вкладки запускає графічний сеанс на вимогу (до появи спостерігача нічого не працює) й підключає перегляд VNC через WebSocket.

Адміністратор вмикає функцію одним натисканням Увімкнути: Libre створює вбудований графічний образ на Docker-демоні розгортання (уперше це триває кілька хвилин) і готову політику без ручного docker build. За фільтрувальним проксі кінцеву точку складання навмисно закрито; натомість завантажте образ на хості (ghcr.io/libre-webui/libre-work-computer, тег libre-work-computer:latest) або зберіть його з deploy/work-computer/, після чого кнопка створить лише політику. Завданням потрібна мережа, оскільки екран доступний через опублікований на loopback порт, як і попередній перегляд.

Сервер VNC усередині контейнера слухає localhost і використовує два паролі на сеанс: пароль лише для перегляду отримує кожен дозволений спостерігач, а повний — лише поточний власник оренди керування. Тому сервер сам ігнорує введення решти. Міст WebSocket — єдина досяжна поверхня, опублікована лише на loopback хоста. Кожен спостерігач проходить автентифікацію одноразовим квитком сеансу й завдання, як у терміналі; доступ Work перевіряється під час кожного підключення, а відкликання негайно розриває екран. Одночасно допускається до чотирьох спостерігачів, а перегляд вважається активністю завдання.

Перегляд не конкурує з виконанням: відкриття під час запуску підключається до тієї самої пісочниці, спостережуваний екран не блокує наступного запуску, а сеанс переживає завершення — навіть у командному розгортанні із зовнішнім робочим процесом. Профіль браузера зберігається в /workspace/.browser-profile, тому входи переживають перезапуск контейнера.

Для керування агент використовує два інструменти. computer_observe повертає повний знімок екрана, положення вказівника, активне вікно, поточний URL браузера, зазначення фокуса сторінки або інтерфейсу браузера, стислий опис елемента у фокусі й хеш знімка. Семантичні сигнали надходять із DevTools на loopback контейнера й відсутні у старих образах. computer_act виконує пакет до 24 дій миші й клавіатури — переміщення, клацання, подвійне або праве клацання, введення, сполучення клавіш, прокручування й очікування — і повертає знімок після стабілізації.

Захист працює у трьох місцях: дії type і key можуть оголосити очікуваний focus та безпечно завершитися помилкою, якщо поле не має фокуса, щоб текст не потрапив до адресного рядка; пакет припиняється в разі появи вікна, зміни заголовка або фокуса, оскільки решта координат застаріла; пакет може оголосити очікуваний заголовок, URL або зміну області, яку середовище перевіряє з адаптивним строком — стан очікування не вважається успіхом.

Після пакета екран опитується до стабілізації замість фіксованої затримки. Результати містять підтвердження: клацання повідомляє про зміну сусідніх пікселів, scroll_until прокручує до тексту або краю й повідомляє про видимість, а кожне спостереження порівнюється з попереднім і явно вказує на відсутність змін. Однорядковий subgoal зберігається як контрольна точка й повторюється під час відновлення. Три однакові дії на незміненому екрані спричиняють попередження, а повтор завершує запуск із запитом даних; послідовні непідтверджені очікування потребують нового спостереження. Телеметрія раундів, затримок, знімків, захистів і вердиктів записується разом з інструментами й підсумком.

Знімки передаються як справжні зображення всіма маршрутами — Ollama, Anthropic, Gemini і сумісними з OpenAI Chat та Responses — тому для керування краще вибирати модель комп’ютерного зору. Якщо постачальник відхиляє зображення, запуск не завершується помилкою: знімки виключаються до кінця запуску, модель переходить на текстові спостереження, а в журналі з’являється пояснення. Така перевірка помітно слабша. У поточному контексті залишаються лише останні знімки, а постійний журнал зберігає лише текст, ніколи не байти зображень.

У браузер вбудовано блокування вмісту: uBlock Origin Lite для реклами й трекерів (версію закріплено й перевірено контрольною сумою під час складання, а режим фільтрування задано керованою політикою) та автоматичне закриття банерів згоди на файли cookie. Це не дає рекламі витрачати знімки, токени й клацання. Відомі рекламні скрипти замінюються безпечними локальними заглушками, щоб сторінки продовжували працювати. Агенту заборонено вводити облікові дані й проходити CAPTCHA або 2FA; він повідомляє про перешкоду. Для недовірених завдань поєднуйте графічну політику з фільтрувальним DNS: настільний браузер підвищує важливість контролю вихідного трафіку.

Звук за замовчуванням вимкнено, оскільки браузер потребує клацання. Кнопка динаміка передає звук комп’ютера в реальному часі. PulseAudio відтворює його в порожній приймач, а монітор передає необроблений PCM через другий автентифікований WebSocket на loopback із тими самими квитками, повторною перевіркою доступу й обмеженням спостерігачів. Потрібен актуальний образ із deploy/work-computer/.

Кнопка Перехопити керування надає мишу й клавіатуру для входу, CAPTCHA або кроку, який агент не має виконувати; Готово повертає екран. Один сеанс VNC використовує згенеровані паролі повного доступу й доступу для спостереження, які ніколи не потрапляють до журналу; повний пароль надається лише власнику оренди. Вона спливає за дві хвилини, подовжується відкритим інтерфейсом і не може бути відібрана в іншого користувача.

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

Режим навчання Навчити завдання записує демонстрацію: людина керує екраном із видимим індикатором, а дії зберігаються в координатах. Кожне клацання також прив’язується до знайдених лише для читання тегу, ID, видимого підпису й поточного URL, тому крок називає ціль, наприклад «Натисніть "button#submit (Place order)"», а координати залишаються підказкою.

Збереження створює сценарій детерміновано, без моделі: натискання об’єднуються в рядки, клацання відрізняється від перетягування порогом 8 пікселів, паузи стають очікуванням, а текст із секретною лексикою або формою облікових даних (8+ символів із трьох класів) редагується й замінюється request_takeover. Процедура природною мовою спочатку використовує прив’язані цілі, потім координати й повторно інтерпретується через computer_observe; вона містить умови застосування, вхідні дані, кроки, перевірку, дозволену область із фактично відвіданих хостів (перед виходом потрібно зупинитися й запитати), межі схвалення та зупинку в разі помилки.

Сценарій зберігається як звичайна навичка з префіксом taught- і підтримує версії, редагування й спільний доступ. Запуски Work Computer завантажують увімкнені навчені навички власника та показують їх у списку; відтворення є звичайним запуском за відповідною процедурою. Після запуску мітки дають змогу одним натисканням додати до Track record датовану оцінку успіху або помилки (нові зверху, кількість обмежено, кожен запис — звичайна версія). Не вводьте справжні паролі під час запису: покажіть процес до входу, збережіть і використовуйте request_takeover під час відтворення.

Постачальники, маршрутизація й розкриття даних​

Підтримувані маршрути​

МаршрутПеревірка й поведінка
Локальний OllamaOllama справний, точна модель оголошує підтримку інструментів.
Ollama CloudЯвно маршрутизується через Ollama; хмарний суфікс показує розкриття даних.
Плагін доповнень або чатуАктивний, містить точну модель й облікові дані поточного адміністратора.
Плагін AnthropicВикористовує адаптер повідомлень та інструментів Anthropic для Work.
Плагін GeminiВикористовує адаптер вмісту й викликів функцій Gemini для Work.
Інший суміснийВикористовує форму OpenAI для повідомлень, інструментів і їх вибору.

Тип постачальника й ID плагіна зберігаються в завданні та кожному запуску. Саме ім’я моделі не вибирає маршрут, а однойменний плагін не перехоплює наявне завдання.

Що отримує постачальник​

  • системний промпт Work;
  • навички робочого процесу й поточні обмеження середовища;
  • до 30 останніх повідомлень користувача й асистента, максимум 256 KB;
  • визначення інструментів;
  • історію викликів інструментів; та
  • результати, зокрема списки, вміст файлів, пошук, вивід і помилки.

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

Облікові дані залишаються в серверній частині й ніколи не підключаються до контейнера Work.

Шифрування облікових даних застосунком не означає шифрування всього завдання. Розмови, результати, вивід і метадані є звичайним вмістом бази, а файли — звичайними файлами тому або PVC. Застосовуйте контроль хоста й шифрування диска відповідно до моделі загроз.

Розкриття віддаленого постачальника​

Моделі плагінів та імена Ollama з :cloud або -cloud вважаються віддаленими. Під час вибору показується закриване сповіщення про потік даних і кілька оплачуваних викликів; уподобання зберігається для користувача.

Усі маршрути використовують WORK_MAX_AGENT_ROUNDS, за замовчуванням 48 раундів; окремого обмеження у 12 раундів для плагінів немає. Бюджет інструментів дорівнює max(128, configured rounds × 8) викликів. Після його вичерпання Libre запитує завершальну передачу без інструментів із виконаною роботою, перевірками, перешкодами й залишком, а потім записує стан Потрібні дані, а не виняток або хибне завершення. Продовження використовує ту саму робочу область. Один запуск усе одно може виконати багато оплачуваних запитів.

Папки хоста (необов’язково)​

Docker зазвичай використовує іменований том, тому модель не бачить справжніх файлів. Завдання можна прив’язати до реального каталогу хоста. Kubernetes відхиляє такі каталоги й використовує PVC.

WORK_HOST_WORKSPACES_ENABLED=true
WORK_HOST_WORKSPACE_ROOTS=/Users/you/Projects

WORK_HOST_WORKSPACE_ROOTS — список коренів, розділених :, за замовчуванням домашній каталог користувача сервера. Поле Папка робочої області необов’язкове; порожнє значення зберігає ізоляцію.

Шлях має бути абсолютним наявним каталогом і після розв’язання символічних посилань залишатися всередині кореня. .ssh, .gnupg, .aws, .config, .kube, .docker, .claude, .libre-webui і node_modules завжди відхиляються. Дозволений шлях зберігається й відображається.

Пісочниця стає вужчою

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

Постійність і життєвий цикл​

СтанСховищеСтрок життя
Власник, заголовок, постачальник, станБаза LibreДо видалення завдання/користувача
Запуски, помилки, повідомлення, активністьБаза LibreДо видалення завдання
ФайлиТом Docker або PVC K8sПереживають скасування, зупинку попереднього перегляду й перезапуски
Коренева система й тимчасові файлиКонтейнер або PodОдноразові, можуть бути зупинені або створені заново
Процес попереднього переглядуРобоча пісочницяТимчасовий, зберігається лише за підтвердженої справності
Незбережена чернеткаСеанс браузераТимчасова зручність

UUID завдання створюється сервером, а імена ресурсів визначає лише серверна частина. Перед повторним використанням або видаленням перевіряються мітки керування й власника; ресурс іншого завдання відхиляється.

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

Адміністратори задають іменовані політики середовища виконання: образ, обмеження пам’яті, CPU й PID, розмір Kubernetes, тайм-аут бездіяльності, мережу та перемикачі Work Computer (GUI + браузер) і Дозволити перехоплення екрана (також визначає навчання). Завдання працює за вибраною політикою; порожні поля успадковують глобальні значення, а видалення повертає їх під час наступного повторного створення. Політика змінює лише ресурси й функції та не може послабити непривілейований режим, корінь лише для читання, відкинуті можливості або мережеву ізоляцію.

WORK_RUNTIME_IDLE_TIMEOUT_MS зупиняє пісочницю після відсутності команд, термінала або запитів підписаного попереднього перегляду й звільняє слот. Робоча область зберігається, а попередній перегляд запускається знову. Значення 0 за замовчуванням утримує її до явної зупинки.

Під час запуску сервера активні виконання позначаються невдалими, а стан попереднього перегляду очищається. Драйвер одним запитом отримує керовані контейнери або Pod. Робочі середовища відомих завдань зупиняються, уже зупинені не змінюються, а осиротілі видаляються. Власник визначається міткою, а не іменем. На простір імен або демон має припадати один екземпляр Libre. Якщо очищення неможливо довести, Work безпечно закривається, повторює спробу кожні 10 секунд і блокує операції, що вносять зміни.

Мережа​

Перевірте політику

Без іменованої політики мережу ввімкнено. Адміністратор може створити політику з мережею, вимкненою за замовчуванням, а автор вибирає її під час створення. Окремого перемикача завдання немає; зміна політики потребує повторного створення середовища.

Docker підключає мережеві завдання до керованого мосту (libre-webui-work, WORK_NETWORK_NAME) з com.docker.network.bridge.enable_icc=false:

  • пісочниці не можуть з’єднуватися одна з одною; та
  • не досягають контейнерів розгортання на спільному мосту за замовчуванням, зокрема неопублікованих бази даних або Ollama.

Мережа з таким самим іменем, але без мітки керування, відхиляється.

У Kubernetes Pod отримує мережеву мітку. Helm установлює заборону за замовчуванням, вхід лише для попереднього перегляду та доступ до інтернету для дозволених Pod із винятком work.networkPolicy.blockedEgressCidrs. Це ефективно лише за підтримки CNI; див. Kubernetes.

Вихідний трафік дозволено для пакетів, Git і API. Це не вихідний брандмауер. Код може досягати:

  • служб хоста Docker;
  • локальної мережі хоста;
  • інтернету; та
  • кінцевих точок метаданих інфраструктури.

Засоби політики вихідного трафіку​

  • WORK_RUNTIME_DNS (Docker) — розділені комами адреси IPv4/IPv6, примусово задані через --dns; фільтрувальний резолвер надає списки імен. Неправильні адреси відхиляються й журналюються, тому впровадити прапорці неможливо.
  • Брандмауер хоста або мережі вищого рівня у стабільній підмережі керованого мосту.
  • WORK_NETWORK_NAME для заздалегідь створеної мережі з власними параметрами, міткою керування й вимкненим ICC.

DNS не обмежує прямі IP-адреси; для гарантії потрібен брандмауер.

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

Мережа не додає облікових даних: до завдання не підключаються SSH-ключі, хмарні дані, профілі браузера, домашній каталог хоста або сокет Docker. Код усе одно може передати секрет, записаний у /workspace.

Трафік пісочниці відокремлено від запитів моделі; Ollama й плагіни завжди викликаються серверною частиною за явним маршрутом.

Межа безпеки пісочниці​

Docker-контейнер:

  • працює без root як 1000:1000;
  • використовує /workspace як робочий каталог;
  • підключає лише том вибраного завдання;
  • має корінь лише для читання й обмежений /tmp;
  • позбавлений усіх можливостей Linux;
  • no-new-privileges;
  • не є привілейованим і використовує init-процес;
  • застосовує обмеження CPU, пам’яті, процесів, часу й виводу;
  • фіксує swap (--memory-swap = --memory);
  • підключається до керованої мережі без ICC або залишається без мережі; та
  • публікує лише порт попереднього перегляду на призначений loopback.

Усі властивості повторно перевіряються через docker inspect і хешуються в ai.libre-webui.policy. Контейнер зі старою політикою після оновлення знищується й створюється заново.

Kubernetes застосовує еквівалент: непривілейований користувач, корінь лише для читання, seccomp RuntimeDefault, відсутність підвищення прав, відкинуті можливості, обмежені тимчасові ресурси, відсутність токена ServiceAccount і PVC у /workspace; мітки й відбиток перевіряються.

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

Ці заходи зменшують випадкове розкриття хоста, але не перетворюють Work на віртуальну машину або безпечне середовище аналізу шкідливого ПЗ. Контейнери спільно використовують ядро хоста; уразливість Docker, Kubernetes, середовища, образу, залежності або ядра може перетнути межу.

Томи Docker не мають незалежної квоти. Проєкт може вичерпати сховище; відстежуйте зростання й застосовуйте обмеження хоста. Забезпечення розміру PVC Kubernetes залежить від постачальника сховища.

Контрольний список захисту Docker​

У Kubernetes також перевіряйте RBAC простору імен, безпеку Pod, клас сховища й виконання NetworkPolicy CNI за посібником.

Застосунок задає прапорці контейнера, перевіряє шляхи й захищає API, але не може забезпечити брандмауер хоста, квоти сховища або рівень прав демона. Це обов’язок оператора.

1. Ізоляція керування Docker​

Основному контейнеру потрібне керування демоном; сокет є обліковими даними площини керування, тому компрометація застосунку може призвести до компрометації хоста.

docker-compose.socket-proxy.yml не передає сокет застосунку. Проксі пропускає лише containers, images, volumes, networks, exec та info, блокуючи swarm, secrets, configs, build, commit і system. Libre використовує DOCKER_HOST=tcp://docker-socket-proxy:2375 без підключення сокета або групи; CLI, термінал і діагностика використовують цю адресу. Поверхня API менша, але радіус наслідків залишається: створення контейнерів дає змогу підключати шляхи хоста.

Сильніша межа — окрема віртуальна машина без сторонніх навантажень; ще сильніша — виділений rootless-демон або окремий хост середовища. До впровадження перевірте володіння файлами, маршрутизацію, очищення й термінал. Підключення звичайного сокета лише для читання не робить API доступним лише для читання.

2. Блокування керування хостом із пісочниці​

Вимкнення ICC не блокує служби хоста. Перевірте фактичний міст і підмережу:

docker network inspect libre-webui-work \
  --format 'id={{.Id}} subnets={{range .IPAM.Config}}{{.Subnet}} {{end}}'
ss -lntup

Постійний брандмауер має забороняти трафік мосту до SSH, Docker API, баз даних і адміністративних портів. Перевірте правило одноразовим контейнером і дозволеними завантаженнями, а потім збережіть його. DOCKER-USER керує пересланим трафіком; доступ до самого хоста може потребувати правила INPUT.

3. Обмеження вихідних цілей​

Блокуйте метадані хмари, приватну інфраструктуру й LAN клієнта, якщо вони не потрібні. Поєднуйте DNS і брандмауер. Прямий IP обходить DNS, а HTTP-проксі недостатній за прямих з’єднань. Забезпечуйте політику поза контейнером.

Створюйте окремі політики без мережі, лише для реєстрів і з відкритим вихідним доступом. Політика визначає підключення мережі, а зовнішні правила — допустимі цілі.

4. Справжні квоти зберігання​

Обмеження CPU, пам’яті й PID не обмежують том. Використовуйте проєктні квоти XFS, логічні томи з квотами або драйвер тому/PVC із розміром. Docker local на ext4 не отримує надійної квоти лише з оголошеного розміру.

Відстежуйте кожен том ai.libre-webui.managed=true і корінь даних Docker, попереджайте до заповнення та перевіряйте поведінку в разі помилки. Інтерфейс або du лише попереджають і не забезпечують обмеження між перевірками.

5. Перевірка політики​

Після зміни створіть одноразове завдання й перевірте через docker inspect: UID, корінь лише для читання, можливості, no-new-privileges, пам’ять, swap, CPU, PID, єдиний том завдання та мережу. Головний контейнер має мати лише очікувані підключення, а загальнодоступний вхід має проходити через автентифікований проксі або тунель, а не порт Docker чи попереднього перегляду.

Безпека й доступність попереднього перегляду​

Docker динамічно публікує попередній перегляд на loopback серверної частини; Kubernetes використовує IP Pod. Модель і браузер не вибирають довільне джерело. Libre підписує URL для точного завдання й кінцевої точки, під час кожного запиту перевіряє процес і проксіює HTTP/WebSocket через /api/work/previews. Зупинка або перезапуск відкликають URL.

Відповіді видаляють облікові дані Libre й файли cookie сервера вищого рівня. HTML обмежено iframe-пісочницею та CSP, що дозволяє скрипти, форми, модальні вікна й завантаження без same-origin; це захищає й окрему вкладку. Створений код залишається недовіреним і може надсилати дані робочої області або браузера. URL є короткостроковим секретом.

Браузер завантажує те саме загальнодоступне джерело, тому віддалений HTTPS працює без відкриття портів, IP Pod і змішаного вмісту. Зворотний проксі має зберігати WebSocket для /api/work/previews/; наданий Nginx це робить.

Основний застосунок дозволяє у фреймах лише власне джерело й Turnstile. Попередній перегляд обходить загальну політику Helmet, щоб передавати тіла й застосовувати вужчу пісочницю. Політику cross-origin embedder вимкнено, оскільки сервери розробки рідко мають потрібні заголовки.

Матриця розгортання​

РозгортанняЗапуски/файлиПерегляд
Локальний npx libre-webuiПідтримується за встановленого й доступного Docker.Підписаний проксі на джерелі застосунку.
Локальний запуск із вихідного кодуТі самі вимоги.Джерело API розробки на порту 3001.
ElectronУмовно: використовує зовнішню серверну частину без окремого середовища Work.Підписаний проксі цієї серверної частини.
Віддалений bare metal або VMПрацює за наявності Docker на хості.Зворотний проксі HTTP і WebSocket.
Стандартний ComposeПідтримується за замовчуванням на Docker Desktop: образ містить CLI, Compose підключає сокет хоста, а порти Work проходять через host.docker.internal. Нативний Docker Engine додатково потребує досяжного непублічного WORK_PREVIEW_BIND.Те саме загальнодоступне джерело.
Kubernetes/Helm--set work.enabled=true: Pod/PVC для запусків, файлів, команд, Git, термінала, екрана й звуку Work Computer за IP Pod, Role простору імен і default-deny NetworkPolicies — без сокета. Див. Kubernetes.Проксі всередині кластера до IP Pod.

Work всередині Docker Libre WebUI​

Усі файли Compose репозиторію містять Work: образ містить CLI й підключає /var/run/docker.sock. На Docker Desktop достатньо вбудованих типових значень маршрутизації. Нативному Docker Engine додатково потрібен WORK_PREVIEW_BIND, заданий на непублічний інтерфейс хоста, досяжний із сусідніх контейнерів, як описано нижче.

Контейнери завдань є сусідніми з контейнером Libre WebUI, видимі в docker ps і керуються тим самим життєвим циклом.

Сокет надає керування хостом на рівні root. Work без нього не працює, тому наслідок сформульовано прямо: кожен адміністратор Libre WebUI фактично є адміністратором Docker-хоста. Оператор відповідає за безпеку, мережу, життєвий цикл, копії й доступ. Видаліть рядок сокета, щоб вимкнути Work; інші функції від нього не залежать.

Альтернатива — docker-compose.socket-proxy.yml через DOCKER_HOST; див. ізоляцію керування.

Потрібно виконати три умови:

  1. CLI Docker існує. Офіційний образ містить його; користувацькому образу потрібні docker-cli або WORK_DOCKER_COMMAND. Інакше: The "docker" CLI is not installed….
  2. Сокет підключено. Інакше: No Docker daemon is reachable….
  3. Користувач входить до групи сокета. Образ працює як nodejs з uid 1001, сокет зазвичай належить root або docker, тому Compose використовує group_add: ['${DOCKER_GID:-0}']. Значення за замовчуванням підходить для Docker Desktop, а Linux потребує власного ID. Інакше: The Docker socket is mounted but the Libre WebUI user cannot open it….
# Read the socket's group as seen INSIDE a container. A macOS host reports a
# different value, because Docker Desktop proxies the socket through a VM.
echo "DOCKER_GID=$(docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  alpine stat -c '%g' /var/run/docker.sock)" >> .env
docker compose up -d --force-recreate

Порти попереднього перегляду залишаються на loopback хоста й доступні через підписаний проксі того самого джерела для HTTP і WebSocket. Це працює з HTTPS і тунелями, застосовує пісочницю та відкликає старий URL.

У Docker адреси публікації й підключення можуть відрізнятися. Залиште WORK_PREVIEW_BIND=127.0.0.1, а WORK_DOCKER_PUBLISHED_HOST задайте як досяжну адресу хоста (host.docker.internal у Docker Desktop). Вбудовані профілі Compose задають обидва значення й відображають це ім’я хоста. Нативні розгортання Linux мають перевизначити WORK_PREVIEW_BIND шлюзом мосту Docker (або іншим явно досяжним непублічним інтерфейсом хоста); саме лише зіставлення host.docker.internal не робить слухача на loopback доступним. Ніколи не прив’язуйте ці сирі тимчасові порти до 0.0.0.0.

Паралельність обмежена: WORK_MAX_ACTIVE_RUNTIMES_PER_USER дорівнює 2, WORK_MAX_ACTIVE_RUNTIMES_GLOBAL — 3. Відповідь можливостей повідомляє зайнятість. Підвищуйте значення лише за достатніх ресурсів.

Для Kubernetes використовуйте work.enabled=true; чарт створює RBAC, простір імен, політики й Pod/PVC за посібником.

Конфігурація середовища виконання​

ЗміннаТиповоПризначення
WORK_RUNTIME_BACKENDdockerСервер пісочниці: docker або kubernetes
WORK_RUNTIME_IMAGEnode:22.22-bookworm@sha256:2d178f2785b96dfbf62a416ca2e40f50e30150b4ff3320d706f0d96e90600eb3Образ пісочниці завдання
WORK_DOCKER_COMMANDdockerВиконуваний файл CLI Docker
WORK_COMMAND_TIMEOUT_MS120000Типовий тайм-аут команди
WORK_MAX_OUTPUT_CHARS50000Максимальний захоплений вивід
WORK_MAX_AGENT_ROUNDS48Раунди моделі й інструментів на запуск
WORK_MEMORY_LIMIT2gЛіміт пам’яті контейнера
WORK_CPU_LIMIT2Ліміт CPU контейнера
WORK_PIDS_LIMIT256Ліміт процесів контейнера
WORK_PREVIEW_PORT4173Порт застосунку в контейнері
WORK_PREVIEW_BIND127.0.0.1Інтерфейс публікації на хості
WORK_DOCKER_PUBLISHED_HOSTяк WORK_PREVIEW_BINDХост або IP опублікованих Docker-портів Work
WORK_COMPUTER_SCREEN_PORT6080Порт WebSocket мосту екрана
WORK_COMPUTER_AUDIO_PORT6081Порт WebSocket мосту аудіо
WORK_RUN_LEASE_WAIT_MS60000Очікування тимчасового власника оренди середовища
WORK_MAX_ACTIVE_RUNTIMES_GLOBAL3Паралельні контейнерні завдання всієї інстанції
WORK_MAX_ACTIVE_RUNTIMES_PER_USER2Паралельні контейнерні завдання адміністратора
WORK_MAX_TASKS_GLOBAL500Максимум постійних завдань інстанції
WORK_MAX_TASKS_PER_USER100Максимум постійних завдань адміністратора
WORK_NETWORK_NAMElibre-webui-workКерований міст пісочниць із мережею
WORK_RUNTIME_DNSне заданоIP резолверів через кому для мережевих завдань
WORK_DOCKER_SOCKETDOCKER_HOST, якщо unix:// або tcp://, інакше /var/run/docker.sockКінцева точка Docker Engine для терміналів і діагностики
WORK_TERMINAL_MAX_SESSIONS_PER_TASK2Одночасні браузерні термінали завдання
WORK_TERMINAL_IDLE_TIMEOUT_MS900000Тайм-аут бездіяльності термінала
WORK_RUNTIME_IDLE_TIMEOUT_MS0 (вимкнено)Зупинка пісочниці після бездіяльності, включно з переглядом
WORK_K8S_NAMESPACElibre-webui-workПростір імен Pod і PVC пісочниць Kubernetes
WORK_K8S_STORAGE_CLASSтипове значення кластераStorageClass для PVC робочих областей
WORK_K8S_WORKSPACE_SIZE5GiРозмір PVC робочої області на завдання
WORK_K8S_POD_READY_TIMEOUT_MS900000Очікування стану Running Pod пісочниці
WORK_K8S_POD_GONE_TIMEOUT_MS60000Очікування зникнення видаленого Pod

У промисловому середовищі використовуйте фіксовану перевірену версію або digest образу. Змінний тег може змінити інструменти командного рядка й межу безпеки без зміни Libre WebUI.

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

Фіксовані ліміти протоколу й інтерфейсу​

ЕлементЛіміт
Нове повідомлення завдання або запуску65,536 символів і байтів UTF-8
ID моделі під час створення або зміни500 символів і байтів UTF-8
ID провайдера плагіна200 символів
Активні запуски на завдання1
Текст команди20,000 символів
Тайм-аут команди від інструментавід 1 до 600 секунд
Готовність перегляду15 секунд
Читання або запис файлу2,000,000 байтів тексту UTF-8
Безпосередній список каталогуПерші 1,000 елементів
Сторінка повідомленьДо 200 повідомлень і 1,000,000 байтів
Окреме збережене повідомлення100 KB
Контекст розмови для моделіОстанні 30 повідомлень, до 256 KB
Збережений вивід інструментаБлизько 20,000 вихідних символів і маркер обрізання
Поточне підсвічування редактора8,000 символів і 400 рядків
Форматування в браузері100,000 символів і 4,000 рядків
Вивід стану Git2,000,000 захоплених символів
Вивід diff Git600,000 захоплених символів
Історія Git20 локальних commit
Шляхи в одному запиті stage200
Повідомлення commit4,000 символів
Цикл агента для кожного провайдераТипово 48 раундів через WORK_MAX_AGENT_ROUNDS
Бюджет викликів інструментівmax(128, configured rounds × 8) викликів

API файлів працює з текстом UTF-8. Вбудований редактор не редагує двійкові файли, а файл більший за 2 MB не можна відкрити через Work API.

Огляд API​

Усі кінцеві точки містяться під /api/work і потребують автентифікації та поточного доступу Work із бази даних. Типово Work доступний адміністраторам; звичайні операції можна відкрити активним користувачам. Вибір папок хоста й адміністративні кінцеві точки політик та доступу залишаються лише для адміністраторів.

МетодШляхПризначення
GET/capabilitiesДоступність і ліміти середовища та провайдера
GET/tasksПерелік завдань поточного адміністратора
POST/tasksСтворити завдання й перший асинхронний запуск
GET/tasks/:idЗавантажити стан і останні повідомлення
GET/tasks/:id/messagesЗавантажити старіші повідомлення
PATCH/tasks/:idПерейменувати або змінити точний маршрут моделі
DELETE/tasks/:idВидалити завдання й постійну робочу область
POST/tasks/:id/runsПочати наступний запуск
POST/tasks/:id/messagesНадіслати повідомлення агенту під час запуску
GET/tasks/:taskId/runs/:runId/eventsПередавати автентифіковані події SSE
POST/tasks/:id/cancelСкасувати активний запуск
GET/tasks/:id/approvalsОчікувані схвалення й стан Автоперевірки для завдання
PUT/tasks/:id/approvalsПеремкнути схвалення для завдання
POST/tasks/:id/approvals/:approvalIdВирішити очікуване схвалення (один раз, завжди, відхилити)
DELETE/tasks/:id/approval-rules/:ruleIdВидалити правило «дозволяти завжди»
GET/computer/setupСтан налаштування Work Computer для адміністратора
POST/computer/setupСтворити GUI-образ і політику
POST/tasks/:id/computer/startПочати сеанс Work Computer
GET/tasks/:id/computer/controlПоточний керівник і запит агента на перехоплення
POST/tasks/:id/computer/controlПерехопити або продовжити керування
DELETE/tasks/:id/computer/controlПовернути керування агенту
POST/tasks/:id/computer/teachЗберегти записану демонстрацію як навичку
POST/tasks/:id/computer/anchorВизначити елемент під записаним клацанням
POST/computer/skills/:slug/traceДодати успішний або невдалий результат до навички
GET/tasks/:id/filesПерелічити каталог робочої області
GET/tasks/:id/fileПрочитати текстовий файл
PUT/tasks/:id/fileЗберегти текстовий файл
GET/tasks/:id/gitПрочитати захищений стан та історію Git
GET/tasks/:id/git/diffПрочитати обмежений локальний diff
POST/tasks/:id/git/initІніціалізувати локальний Git
POST/tasks/:id/git/stageДодати явні шляхи до stage
POST/tasks/:id/git/commitСтворити commit із підготовлених змін
POST/tasks/:id/git/branchesСтворити локальну гілку
POST/tasks/:id/git/switchПеремкнутися на наявну чисту гілку
POST/tasks/:id/preview/startПочати керований перегляд
POST/tasks/:id/preview/stopЗупинити керований перегляд

ID завдання завжди перевіряється відносно автентифікованого власника. Поточний стан облікового запису, роль і політика доступу читаються з бази за кожним запитом, тому відкликання діє навіть за старих тверджень ролі в JWT.

Схема оновлення завдання зберігає серверне поле networkEnabled для внутрішньої сумісності. Воно не показується окремим засобом Work. Під час створення вибирайте іменовану політику з потрібним типовим станом мережі; не використовуйте сире поле як постійний API конфігурації.

Видалення, зміни облікових записів і резервні копії​

Видалення завдання​

Видалення навмисно руйнівне:

  1. Сервер позначає завдання як таке, що виводиться з експлуатації, і блокує нові зміни.
  2. Активний запуск скасовується, а пісочниця зупиняється.
  3. Libre WebUI перевіряє мітки власності ресурсів середовища.
  4. Контейнер або Pod та іменований том або PVC видаляються.
  5. Завдання видаляється з бази каскадно разом із запусками й повідомленнями.
  6. Після успіху очищаються чернетки браузера.

Якщо очищення середовища не вдалося, Libre WebUI зберігає запис і повертає помилку, щоб оператор відновив Docker або Kubernetes і повторив. Метадані не видаляються непомітно, залишаючи неврахований ресурс.

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

Пониження адміністратора й видалення користувача​

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

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

Повна резервна копія завдання​

Повна копія Work потребує:

  • базу Libre WebUI з власністю, іменами ресурсів Docker або Kubernetes, маршрутизацією, запусками, повідомленнями й активністю; та
  • усі томи Docker або PVC Kubernetes із міткою ai.libre-webui.managed=true, що містять файли Work.

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

Відновлюйте базу й відповідні робочі області разом. Створіть кожен том або PVC під точним записаним ім’ям і відновіть ai.libre-webui.task=<task UUID> та ai.libre-webui.managed=true. Самі файли не зберігають міток; сама база не має файлів; саме сховище втрачає власність та імена ресурсів.

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

Локалізація та арабський RTL​

Повний Work перекладено 25 мовами: англійською, арабською, бенгальською, чеською, данською, німецькою, іспанською, французькою, гінді, індонезійською, ісландською, італійською, японською, корейською, малайською, нідерландською, польською, португальською, російською, шведською, тайською, турецькою, українською, в’єтнамською та китайською.

Арабська встановлює lang="ar" і dir="rtl" до відтворення React: бічна панель і розмова переходять праворуч, робоча область ліворуч, напрямні значки дзеркальні, вкладки й зміна розміру дотримуються RTL.

Технічний вміст лишається зліва направо, де це впливає на правильність:

  • код і підсвічування;
  • шляхи файлової системи;
  • ID моделей;
  • команди й журнали перегляду;
  • вивід і метадані інструментів; та
  • вміст блоків коду.

Назви завдань, природномовні промпти, помилки, імена файлів і команди перегляду використовують автоматичний напрямок тексту.

Усунення неполадок​

Середовище недоступне з npx​

npx libre-webui запускає сервер на хості, але не встановлює Docker. Виконайте docker info від того самого користувача ОС. Установіть або запустіть Docker чи виправте права, а потім перезавантажте Work. Також перевірте справний Ollama або активний плагін із моделлю та обліковими даними поточного адміністратора.

Середовище недоступне в Docker або Kubernetes​

Compose з репозиторію не має показувати цю помилку: образ містить CLI, а файл підключає socket хоста. Панель називає причину — відсутній CLI, socket або група. Для останнього задайте DOCKER_GID і пересоздайте контейнер. Див. Work усередині Docker.

У Kubernetes увімкніть --set work.enabled=true. Libre повідомить kubernetes, перевірить API й запускатиме Pod із PVC. Не підключайте socket середовища вузла; див. Kubernetes.

Немає сумісних із Work моделей​

Для Ollama виберіть модель, що оголошує tools. Для плагіна перевірте:

  • тип completion або chat;
  • активність;
  • точну модель у карті;
  • доступний API-ключ поточного адміністратора; та
  • підтримку викликів інструментів цією моделлю.

Work ніколи не перемикається на іншого провайдера як резерв.

Не встановлюється пакет або не працює віддалений Git​

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

Запуск зупинився на ліміті агента​

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

HTTP 429 під час запуску​

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

Перегляд не стає готовим​

Команда має продовжувати роботу, прив’язуватися до 0.0.0.0 і слухати WORK_PREVIEW_PORT протягом 15 секунд. Порожнє поле знаходить dev у package.json, простий index.html або один вкладений застосунок. Якщо знайдено кілька або жодного, введіть явну команду. Вона починається в /workspace; для вкладеного застосунку використовуйте cd <app-directory> && ....

Перегляд працює на сервері, але не у віддаленому браузері​

Перевірте збірку з підписаним проксі та перезапустіть старий URL. Зворотний проксі й тунель мають дозволяти WebSocket для /api/work/previews/. Опублікований Docker-порт має лишатися на loopback і не потребує відкриття брандмауера.

Файли лишилися, але перегляд зупинився​

Це очікувано після скасування, перезапуску сервера, явної зупинки або невдалої перевірки готовності. Процес тимчасовий, том постійний. Відкрийте завдання й почніть перегляд знову.

Файл не відкривається або не зберігається​

API приймає текст UTF-8 до 2 MB. Якщо файл змінився після відкриття, перезавантажте його до збереження. Підсвічування переходить у простий текст вище 8,000 символів або 400 рядків; форматування має окремий ліміт 100,000 символів і 4,000 рядків та підтримує лише задокументовані типи.

Work повідомляє про відновлення пісочниць​

Під час запуску або завершення не вдалося довести зупинку відомих пісочниць. Work безпечно блокується й повторює спробу кожні 10 секунд. Відновіть доступ до Docker або Kubernetes API й перевірте журнал сервера. Не видаляйте рядки бази, доки мічені ресурси не узгоджено.

Не вдається видалити завдання​

Переконайтеся, що середовище досяжне. Конфліктний ресурс без очікуваної мітки ai.libre-webui.task навмисно відхиляється. Обережно виправте конфлікт і повторіть.

Підсумок безпеки​

  • Work типово доступний лише адміністраторам; відкриття всім робить кожен активний обліковий запис оператором пісочниці. Папки хоста завжди лишаються адміністративними.
  • Сервер має контролювати налаштований Docker-демон або простір імен Kubernetes.
  • Контейнери зменшують доступ до файлової системи, але не є віртуальними машинами.
  • Завдання без офлайн-політики мають вихідний трафік; обмеження цілей залишається обов’язком оператора.
  • Томи Work не мають незалежної дискової квоти.
  • Git працює лише локально; віддалені облікові дані не підключаються й не приймаються API.
  • Брандмауер, ізоляція демона, вихідні обмеження й справжні квоти забезпечує оператор.
  • Віддалені провайдери отримують запитані результати й можуть виконувати кілька оплачуваних викликів.
  • Порти перегляду лишаються на loopback і доступні лише через підписані відкличні URL.
  • Стандартний Compose надає Docker, а Kubernetes/Helm — Pod/PVC при work.enabled=true.
  • Повна резервна копія потребує базу Libre WebUI і томи Work.

Пов’язана документація​