Ubuntu Workshop: правильная песочница для запуска ИИ-агентов

В мае 2026 года Canonical выпустила Workshop — инструмент для запуска изолированных окружений разработки на базе LXD-контейнеров. Момент выбран неслучайно: агентные ИИ-инструменты — кодирующие агенты, локальные языковые модели, автономные ассистенты — получили уровень доступа к машине разработчика, для которого стандартные контейнерные решения не проектировались. Workshop предлагает другую архитектуру изоляции, ориентированную именно на этот класс задач.

Что такое Workshop и зачем он нужен

Workshop устанавливается как Snap-пакет и требует LXD версии 6.8 или новее. Среда разработки описывается в YAML-файле: в нём задаётся набор SDK, список разрешённых ресурсов хоста и конфигурация окружения. Одна команда создаёт, обновляет или удаляет среду по этому описанию. YAML-файл можно хранить в git, ревьюить в pull request и воспроизводить на другой машине без дополнительной настройки.

Workshop — не менеджер пакетов и не обёртка над виртуальным окружением. Это полноценный слой изоляции рабочей нагрузки, построенный поверх зрелого контейнерного рантайма. По уровню изоляции он ближе к лёгкой виртуальной машине, чем к Docker-контейнеру — и это принципиальное различие.

В чём отличие от Docker: граница проходит по ядру

Docker-контейнеры используют ядро хоста совместно. Изоляция обеспечивается через Linux namespaces и cgroups — это надёжно для большинства сценариев, но оставляет общую поверхность атаки через ядро. Уязвимость ядра, найденная изнутри контейнера, присутствует и на хосте.

Workshop использует системные контейнеры LXD: каждое окружение запускает собственный экземпляр ядра, не разделяя его с хостом. Граница изоляции реальная, а не только пространство имён. При этом контейнеры по умолчанию непривилегированные: процесс root внутри Workshop-окружения отображается на непривилегированного пользователя на хосте. Docker поддерживает аналогичный механизм через user namespace remapping, но на практике он почти никогда не включён по умолчанию — в Workshop это исходная точка, а не опция.

Почему агентный ИИ — это другой класс задач для изоляции

Кодирующий агент вроде Claude Code работает с правами локального пользователя: читает файловую систему, редактирует код, выполняет команды в терминале, имеет доступ к SSH-ключам, токенам облачных провайдеров и переменным окружения. Под контролем человека это управляемо. В полуавтономном режиме — особенно при экспериментах с незнакомыми моделями или сторонними агентными инструментами — те же возможности становятся существенным риском.

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

Workshop формулирует это прямо: «вы контролируете, к чему имеют доступ ИИ-агенты». Этот контроль структурный — он не зависит от того, правильно ли ведёт себя агент.

Система интерфейсов: явные разрешения вместо неявного доступа

Система интерфейсов Workshop, построенная по образцу snapd, управляет доступом окружения к ресурсам хоста. GPU, SSH-агент, сетевые интерфейсы — ничего из этого нет в Workshop-окружении по умолчанию. Каждый ресурс должен быть явно объявлен в YAML-конфигурации и предоставлен через систему интерфейсов.

Это даёт важное архитектурное свойство: набор ресурсов хоста, доступных агенту, виден в конфигурационном файле, а не спрятан в рантайм-флагах. Если кодирующему агенту внутри Workshop нужен SSH-доступ для push’а кода — SSH-агент-интерфейс должен быть включён, и это решение отражается в YAML рядом со всей остальной конфигурацией окружения.

Для команд, запускающих локальные LLM через Ollama, GPU-интерфейс предоставляется именно этой нагрузке. Другие окружения на той же машине не получают доступ к GPU по умолчанию — разрешение ограничено конкретным контекстом, а не открыто всем.

YAML-конфигурация как декларация прав доступа

YAML-файл, описывающий Workshop-окружение, по сути является декларацией прав доступа для рабочей нагрузки. Он фиксирует, какие SDK загружены, какие интерфейсы хоста подключены и что окружение предполагает делать — до запуска, а не по результатам инцидента. Этот файл хранится в git, проходит код-ревью и изменяется через тот же процесс, что и любой другой конфигурационный код.

Такой подход разделяет два вопроса, которые часто путают: что может делать агент и что агент делает. YAML отвечает на первый вопрос явно. Поведение агента в рантайме разворачивается внутри заданной границы. Когда граница должна измениться — агенту нужна новая возможность — это изменение видно и обсуждаемо, как любая другая правка конфигурации.

Для команд с несколькими агентами на разных уровнях доверия — экспериментальная модель и продуктовый ассистент — разные YAML-конфигурации задают разные наборы возможностей на одной машине.

SDK Store: готовые среды для ИИ-задач

В Workshop есть магазин SDK, который уже включает Ollama, OpenCode, NVIDIA CUDA, AMD ROCm, Intel OpenVINO и ROS 2. SDK можно подключать из стабильного или edge-канала; кастомные SDK создаются и распространяются внутри команды.

Для ИИ-разработки это означает, что инфраструктурный рантайм нагрузки — часть описания окружения, а не отдельный шаг установки на хосте. Окружение с локальной LLM через Ollama и ускорением NVIDIA CUDA полностью задаётся в YAML и воспроизводится на другой машине без ручной установки GPU-драйверов или модельных раннеров.

Присутствие ROS 2 в списке SDK говорит о том, что Workshop позиционируется и для робототехники — области, где агентные системы управления имеют физические последствия. Это, пожалуй, наиболее критичный случай для осмысленных границ изоляции.

Что Workshop пока не решает

Workshop появился в мае 2026 года, и экосистема SDK только формируется. Текущая документация не описывает гранулярную сетевую изоляцию внутри окружения — например, ограничение агента конкретными API-эндпоинтами при блокировке остального исходящего трафика. Для команд, обеспокоенных возможностью утечки данных или неожиданными внешними запросами агента, сетевые ограничения придётся настраивать отдельно.

Workshop работает в экосистеме Ubuntu и Snap. Разработчики на macOS, Windows или не-Ubuntu Linux потребуют слой виртуализации, что снижает практическую привлекательность для кросс-платформенных команд. Инструмент явно позиционируется как Ubuntu-first продукт.

Дисциплина, которую задаёт Workshop

Workshop не делает ИИ-агентов безопасными — ни один sandbox этого не гарантирует. Workshop делает периметр безопасности явным и аудируемым. YAML-файл, система интерфейсов, непривилегированные контейнеры по умолчанию — каждый из этих механизмов требует ответить на вопрос «что этой нагрузке действительно нужно?» до её запуска, а не после инцидента.

Для команд, экспериментирующих с кодирующими агентами и локальными LLM, дисциплина, которую задаёт Workshop — описать окружение, объявить доступ, запустить в изоляции — разумный базовый уровень для работы с системами, которые действуют автономно от имени разработчика. Альтернатива — надеяться, что агент не доберётся до того, до чего не должен. Workshop делает эту надежду излишней.