Что такое CubeSandbox для ИИ-агентов?

Я провёл несколько вечеров на прошлой неделе, изучая репозиторий CubeSandbox. Не в продакшне — проект стал публичным только 21 апреля, а суждения, которые я обычно выношу об инструменте, требуют больше времени в работе. Но архитектурные решения достаточно интересны, чтобы зафиксировать, что они сигнализируют об инфраструктуре для агентов, пока новостной цикл не захватил повестку.

Если вы строите агентов, выполняющих ненадёжный код — всё, что касается интерпретации кода, браузерной автоматизации, обучения с подкреплением или любого цикла «мышление → выполнение → обратная связь», где модель решает, что запускать, — инфраструктура песочницы не является второстепенным вопросом. Это то, что ломается первым под нагрузкой. CubeSandbox — один из ответов. Эта статья о том, что он собой представляет, почему важны принятые архитектурные решения и какие команды должны его оценить. Не о том, стоит ли вам переходить на него.

Что такое CubeSandbox и что Tencent открыла в open source

Основная архитектура и позиционирование

CubeSandbox — это open-source сервис песочницы для ИИ-агентов, выпущенный Tencent Cloud 21 апреля 2026 года под лицензией Apache 2.0. Репозиторий на GitHub поставляется с полным стеком: API-шлюз, оркестратор, агенты на каждый узел, сетевой уровень, гипервизор. Не SDK, не обёртка вокруг хостируемого сервиса. Вы разворачиваете его самостоятельно.

Технические заявления, взятые прямо из README:

• Холодный старт менее 60 мс для полностью готовой к работе песочницы.
• Накладные расходы по памяти на экземпляр менее 5 МБ.
• ~2 000 одновременных песочниц на сервере с 96 ядрами.
• Изоляция на аппаратном уровне через RustVMM + KVM, каждая песочница получает собственное гостевое ядро.
• Совместимость с протоколом E2B SDK — смена одной переменной среды для миграции.

Кодовая база примерно наполовину написана на Rust, поддерживающие слои — на Go и C. Документ с обзором архитектуры разбивает её на CubeAPI (REST-шлюз, совместимый с E2B), CubeMaster (оркестратор кластера), CubeProxy (маршрутизатор запросов), Cubelet (менеджер жизненного цикла на узел), CubeVS (сетевая изоляция на основе eBPF) и CubeHypervisor + CubeShim (уровень виртуализации; CubeShim реализует Shim v2 containerd). В README упоминаются upstream-проекты: Cloud Hypervisor, Kata Containers, virtiofsd и containerd-shim-rs — ничего неожиданного для специалистов в этой области.

На практике: это microVM-песочница из той же архитектурной семьи, что и Firecracker, но с отдельной реализацией VMM. Держится ли качество реализации за пределами Tencent-овского тестового стенда с bare-metal — открытый вопрос. Из README это не узнать.

Почему важна совместимость с E2B

Самое интересное архитектурное решение в CubeSandbox — не холодный старт в 60 мс. Это намеренная совместимость с E2B SDK.

E2B стал почти стандартом для выполнения кода в агентах. Manus использует его. Длинный хвост LLM-приложений, которым нужно запускать сгенерированный моделью код, тянется к нему первым делом. Его SDK-протокол — from e2b_code_interpreter import Sandbox, указать URL, запустить код — это ближайшее к де-факто интерфейсу в этой категории.

Зеркалируя этот протокол, CubeSandbox обходит проблему, с которой сталкивается большинство «альтернатив»: необходимость учить разработчиков новому SDK. Путь миграции — одна переменная среды. Существующий код агентов не меняется. Если вы уже строили поверх E2B, стоимость тестирования CubeSandbox — примерно один вечер, не квартал.

Я задержался на этом месте при чтении репозитория. Совместимость нацелена не на то, чтобы доказать, что CubeSandbox «лучше». Она нацелена на то, чтобы сделать эксперимент дешёвым. Это более умная ставка.

Почему песочницы важны в инфраструктуре агентов

Изоляция, время запуска и параллелизм

Песочница делает три вещи одновременно для агентной системы, и нельзя пожертвовать одной из них, не навредив остальным.

Изоляция. Когда модель генерирует код, вы не знаете, что он делает, пока не запустите его. Контейнера, разделяющего ядро хоста, недостаточно. Один эксплойт повышения привилегий в гостевом ядре или один побег из Docker — и агент получил доступ к файловой системе хоста, учётным данным хоста, сети хоста. MicroVMs решают это, давая каждой песочнице собственное гостевое ядро — аппаратно-виртуализованную границу вместо границы пространства имён. Это тот же аргумент, который AWS приводила при открытии Firecracker для Lambda: контейнеры слишком тонкая стена для многопользовательского выполнения кода.

Время запуска. Агент, решающий «запущу этот Python-скрипт, чтобы проверить результат», принимает это решение за миллисекунды реального времени. Если песочница поднимается две секунды, цикл обратной связи уже сломан. Продукт выглядит медленным, даже когда модель быстрая. Firecracker достиг времени загрузки ~125 мс и сделал microVMs пригодными для serverless. Хостируемый сервис E2B сообщает о примерно 150–200 мс с предварительно прогретыми пулами. CubeSandbox заявляет менее 60 мс благодаря предварительно подготовленным пулам ресурсов и клонированию снимков. Это число, если оно выдержит проверку, меняет то, какие виды агентных циклов становятся практичными. Я бы проверил это на собственном железе перед тем, как цитировать.

Параллелизм. Одна песочница на пользователя — простой случай. Одна песочница на шаг агента, на пользователя, с тысячами агентов в полёте — сложный. Ограничение смещается от «насколько быстро стартует одна» к «сколько можно запустить на одной машине». Цифра в 5 МБ на экземпляр в паре с 2 000+ на 96-ядерной машине — это аргумент плотности. Выдержит ли это реальные нагрузки — песочницы, которые реально загружают интерпретаторы Python, браузеры, зависимости — снова открытый вопрос.

Эти три фактора тянут в разные стороны. Более строгая изоляция обычно означает более тяжёлые VM, более медленный запуск, меньшую плотность. Интересные microVM-системы отказываются от этого компромисса.

Почему это превращается в продуктовое узкое место при масштабировании

Для прототипа с одним пользователем ничего из этого не имеет значения. Поставьте Docker-контейнер за агентом, примите технический долг по безопасности, выпускайте. Цена невидима, пока не станет видна.

Она становится видна в трёх точках, все из которых я наблюдал:

Задержка на шаг. Агент, вызывающий песочницу 20 раз в одном reasoning-трейсе, наследует холодный старт 20 раз. При 200 мс каждый раз — это 4 секунды чистой инфраструктурной задержки, добавленной к воспринимаемому пользователем времени ответа. Модель не стала медленнее. Инфраструктура стала.

Многопользовательский параллелизм. Как только платящие пользователи запускают агентов одновременно, «одна VM на пользователя» перестаёт масштабироваться линейно. Счёт за хостинг растёт быстрее, чем выручка. Либо вы делите ядра и принимаете риск изоляции, либо принимаете худшую маржу. Третьего варианта нет, кроме смены базового примитива.

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

CubeSandbox делает ставку на то, что аппаратная изоляция, низкие накладные расходы по памяти и старт менее 60 мс достижимы одновременно, и что продуктовые команды обратят на это внимание, когда упрутся в эти три стены. Окупится ли это — функция от исполнения и принятия. И то, и другое пока открыто.

Кому стоит оценить CubeSandbox, а кому — нет

Стоит внимательно изучить:

• Командам, уже работающим на E2B и упирающимся в ограничения по стоимости или параллелизму, которые в любом случае рассматривают self-hosting. Миграция — буквально однострочное изменение.
• Инфраструктурным командам, строящим внутренние агентные платформы с требованиями по комплаенсу или размещению данных, исключающими сторонние облака. Apache 2.0 + self-hosted — это предпосылка.
• Всем, кто запускает циклы обучения с подкреплением с высокой частотой создания песочниц, где стоимость холодного старта живёт во внутреннем цикле обучения. Улучшение на 100 мс, умноженное на миллионы эпизодов — реальные деньги.
• Командам, чья текущая установка — «Docker-контейнер с флагами усиления», и чья модель угроз тихо переросла это. Честный момент для переключения — до инцидента, не после.

Пожалуй, пока подождать:

• Прототипы и демо для одного пользователя. Затраты на подъём кластера microVM не оправданы при низком объёме вызовов.
• Команды без доступа к bare-metal или KVM-совместимым VM. Требование к железу реально — x86_64 Linux с KVM. Стандартные облачные VM без вложенной виртуализации не подходят из коробки, хотя путь PVM расширяет это.
• Все, чей стек глубоко завязан на SDK, отличный от E2B, где стоимость миграции перевешивает выигрыш во времени работы. Совместимость помогает; она не устраняет затраты на переключение полностью.

Это всё, что я могу подтвердить по прочтении кода и документации. Остальное требует времени в продакшне, а я его туда ещё не поставил.

Часто задаваемые вопросы

Какую проблему решает CubeSandbox?

Это среда выполнения для запуска сгенерированного ИИ кода в изоляции, с низкой задержкой, с высоким параллелизмом, без разделения ядра хоста. Проблема, на которую он нацелен, — та, с которой рано или поздно сталкивается каждая агентная платформа: контейнеры слишком «дырявы» для ненадёжного кода, традиционные VM слишком медленные и тяжёлые, существующие microVM-решения либо проприетарны, либо операционно сложны.

Чем это отличается от подходов только с контейнерами?

Подходы только с контейнерами разделяют ядро хоста. Эксплойт гостевого ядра достигает хоста. CubeSandbox даёт каждой песочнице собственное гостевое ядро через аппаратную виртуализацию на основе KVM — более крепкую границу против кода, который LLM может испустить, когда что-то идёт не так, или когда пользователь пытается это устроить. Заявленные накладные расходы по памяти (менее 5 МБ на экземпляр) также закрывают разрыв в плотности, который исторически делал VM неэкономичными по сравнению с контейнерами.

Почему важна совместимость с E2B?

Потому что стоимость опробования новой песочницы — это обычно проект миграции, а не сам пробный запуск. SDK E2B имеет достаточно широкое применение, чтобы совместимость позволяла командам тестировать CubeSandbox, изменив одну переменную среды. Это разница между «оценю в следующем квартале» и «подниму сегодня вечером». Выбор протокола делает тяжёлую работу по принятию.

Каким командам тестировать его в первую очередь?

Командам, уже работающим на E2B при нетривиальном объёме, командам с требованиями по комплаенсу, требующими self-hosting, и командам, запускающим плотные агентные циклы, где задержка холодного старта проявляется во времени ответа для пользователя. Пользователи меньшего масштаба могут подождать — ранее принятие стоит дороже, чем даёт.

Заключение

Инфраструктура под агентами превращается в реальную категорию. Большую часть 2024 года и в 2025-м изоляция в песочнице была второстепенным вопросом — решалась тем, что было под рукой. Команды, выставляющие сейчас агентов перед реальными пользователями, обнаруживают, что выбор песочницы определяет всё: от задержки на запрос до маржи на пользователя.

CubeSandbox не меняет базовую физику. MicroVMs уже были правильным архитектурным ответом; открытыми вопросами всегда были качество реализации и трение принятия. Репозиторий заявляет конкурентные цифры по первому и решает второй, нативно говоря на протоколе E2B. Выдержат ли цифры в продакшне за пределами тестового стенда Tencent — это то, что покажут ближайшие несколько месяцев.

Я планирую развернуть его на тестовом кластере и проверить заявление о холодном старте на собственной нагрузке. Подлежит проверке. Вернусь к этому, когда будут данные.

Предыдущие публикации:

• MCP в продакшне: что нужно знать разработчикам
• Паттерны и подводные камни подключения инструментов в агентных воркфлоу
• Что такое Claude Managed Agents?
• Руководство по быстрому старту с Claude Managed Agents (2026)
• GitHub Copilot против приватных помощников по программированию