Песочницы

Исследование быстрорастущего рынка песочниц для AI-агентов: типы рабочих нагрузок, ключевые игроки и будущее этого сегмента инфраструктуры.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Песочницы

Sandboxes Автор: Crystal Tang Оригинальный текст:

Бросьте дротик в карту Сан-Франциско — и вы попадёте в кого-то, кто строит песочницу. По крайней мере, так кажется.

Песочницы начинались как безопасные среды для выполнения ненадёжного кода. По мере того как агентные (agentic) рабочие нагрузки становятся всё сложнее, песочницы превращаются в операционные среды, внутри которых агенты реально работают.

Что делает этот рынок интересным — единого типа рабочей нагрузки для песочниц больше не существует. Каждый крупный провайдер оптимизирует под свой сценарий использования и неявно делает ставку на своё видение агентного будущего.

Рабочие нагрузки

Рабочие нагрузки песочниц обычно различаются по двум осям: продолжительность выполнения и объём требуемого состояния. На практике это сводится к трём доминирующим сценариям:

Простое выполнение кода

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

Среды с сохранением состояния

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

Ресурсоёмкие нагрузки

Они выглядят как традиционная инфраструктура. Обучение небольших моделей, инференс (inference), пакетные задачи и CI-подобные рабочие нагрузки. Они часто привязаны к GPU, параллелизуемы и затратны.

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

Пространство проектирования

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

Примитив изоляции

Различные рабочие нагрузки требуют различных гарантий изоляции. Контейнеры легковесны и быстры. MicroVM оптимизированы для более строгих границ изоляции и в целом считаются «правильным» примитивом по умолчанию. gVisor находится где-то посередине.

Производительность

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

Для простых рабочих нагрузок с выполнением кода важнее всего время холодного старта. Если вызов инструмента занимает несколько секунд до начала выполнения, весь опыт будет ощущаться как медленный.

Для долгоживущих рабочих нагрузок время возобновления часто важнее. Когда пользователь приостанавливает и позже возобновляет сессию, он ожидает, что она появится мгновенно. Это подталкивает провайдеров к созданию снимков, пулам «тёплых» экземпляров и постоянным средам выполнения.

В масштабе провайдеры также начинают оптимизировать вокруг совершенно иного набора ограничений: параллельная оркестрация песочниц, производительность CPU, производительность дисков и плотность рабочих нагрузок.

Сохранение состояния

Агентные рабочие нагрузки становятся всё более stateful.

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

Это фундаментально меняет то, чем должна быть песочница. Среда выполнения больше не одноразовая; она начинает вести себя как постоянное рабочее пространство. Это означает создание и восстановление снимков сред между сессиями, ветвление и форки состояний выполнения, подключение внешних систем хранения (S3, blob-хранилища, базы данных) и сохранение долгоживущего состояния между рабочими процессами.

Переносимость и взаимозаменяемость

Песочницы должны быть совместимы с любым harness (оркестратором агента).

Claude Managed Agents от Anthropic и Agents SDK от OpenAI уже рассматривают песочницы как полностью взаимозаменяемые.

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

Где живёт harness

Один из наиболее интересных архитектурных вопросов — где именно должен жить сам harness.

Если harness находится за пределами песочницы, оркестрация может быть всегда активной, в то время как среды запускаются только тогда, когда требуется выполнение. Это улучшает отзывчивость, но создаёт более сложные границы доверия между инфраструктурой и ненадёжным выполнением. Именно в этом направлении движутся Claude Managed Agents и Agents SDK от OpenAI.

Альтернативно, если harness живёт внутри песочницы, изоляция становится значительно проще, но задержка (latency) при запуске становится критичной. Компромисс — меньшая гибкость оркестрации.

Сегодняшние независимые игроки

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

Modal

Modal — ближайший аналог масштабного инкумбента. Он начинался как бессерверная вычислительная платформа и рассматривает песочницы как ещё одну рабочую нагрузку поверх более широкого вычислительного слоя. Поддерживает CPU, GPU и бессерверные задачи.

Компромисс в том, что он не оптимизирован под агентную семантику. Если вам нужен детальный контроль над тем, где запускаются ваши нагрузки (в VPC или on-premise), стандартная модель Modal может стать ограничивающей.

Modal фактически делает ставку на то, что доминирующая модель выполнения для агентов будет выглядеть как традиционные инфраструктурные рабочие нагрузки.

e2b

e2b возвращается к базовому сценарию использования песочниц — безопасному выполнению произвольного кода. Использует микровиртуальные машины Firecracker для изоляции и особенно силён в выполнении кода.

Компромисс — операционная сложность. Командам теперь нужно управлять образами, сетями и интеграциями с Kubernetes. Вы больше не просто вызываете API.

e2b делает ставку на то, что большинство агентного выполнения останется stateless.

Daytona

Daytona делает более категоричную ставку на то, что песочницы должны ощущаться как настоящие среды. Продукт ведёт себя больше как облачный devbox: постоянные файловые системы, долгоживущие сессии и быстрое время запуска. Для этого они используют контейнерный примитив.

Компромисс в том, что эта модель тяжелее, чем то, что нужно большинству рабочих нагрузок прямо сейчас. Если вы выполняете быстрый вызов инструмента, это избыточно.

Daytona фактически делает ставку на то, что будущее агентов — это постоянные операционные среды с файловыми системами, памятью и долгоживущим состоянием.

Помимо этих трёх, существует растущий длинный хвост специализированных игроков.

Строить или покупать

При достаточном масштабе компании перестают покупать песочницы и начинают строить их самостоятельно.

Я пообщалась с AI-native поисковой компанией, которая изначально использовала e2b. Их ранние нагрузки были связаны с выполнением ненадёжного кода. Со временем их продукты стали более агентно-ориентированными. Они выпустили свой флагманский продукт, который требовал поддержки долгоживущих сессий, постоянных сред и сложной оркестрации. То, что им было нужно, начинало выглядеть как операционная среда для их агентов.

В итоге они заменили e2b на свою собственную платформу песочниц, гипероптимизированную под их конкретные рабочие нагрузки и паттерны трафика.

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

Куда движется рынок

Динамика рынка

Во-первых, базовый продукт коммодитизируется. Запустить песочницу больше не сложно. Время холодного старта у провайдеров сближается, а примитивы изоляции широко доступны. Для среднестатистической рабочей нагрузки песочницы будут в значительной степени взаимозаменяемыми.

Во-вторых, реальная конкуренция — не другие стартапы в сфере песочниц. Гиперскейлеры уже начинают выходить на этот рынок. AWS уже предоставляет большинство примитивов, необходимых для построения кастомной песочницы, через Lambda, ECS и Firecracker. Они уже владеют окружающей инфраструктурой и могут предложить гораздо больше кастомизации, чем любой независимый провайдер.

В-третьих, BYOS (bring your own sandbox — «принеси свою песочницу») становится интерфейсом по умолчанию. Недавнее обновление Agents SDK от OpenAI поддерживает несколько провайдеров песочниц, и Claude Managed Agents тоже. Стоимость переключения будет стремиться к нулю.

Сама абстракция выполнения также продолжает эволюционировать вместе с агентами, что делает долгосрочную дифференциацию сложнее для прогнозирования.

Что это значит

Учитывая эту динамику, рынок песочниц, вероятно, разделится: коммодитизация для среднего случая и специализация для нишевых.

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

Более интересные рабочие нагрузки — те, которые становятся постоянными и stateful. Долгоживущие агенты ещё находятся на ранней стадии, но именно туда явно движется рынок. Именно здесь изоляция, персистентность и оркестрация действительно важны. Эти нагрузки требуют гораздо более продуманной инфраструктуры.

В результате число значимых независимых провайдеров сократится. Горстка специализированных игроков продолжит обслуживать нишевые сценарии. Гиперскейлеры поглотят недифференцированный длинный хвост рабочих нагрузок песочниц. А для тех случаев, где песочница тесно связана с основным продуктом, компании будут строить собственные решения.

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

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

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot