AgentBox: зачем AI-агенту своя Linux-среда

Мы запустили AgentBox — облачные песочницы с полноценной Linux-средой для AI-агентов. К этому привела работа над собственными агентами: вместе с доступом к командной строке появились вопросы об изоляции, пакетах, Docker, параллельных сессиях и тестах. Каждый из них довольно быстро становится частью продукта.

После запуска агента начинается работа со средой

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

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

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

Изоляция нужна на уровне каждой сессии

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

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

В анонсе AgentBox мы указали, что песочницы построены на Firecracker. Это выбранная основа изоляции. При подключении агента всё равно нужно настроить сеть, работу с секретами и права на внешние сервисы. Например, отдельная Linux-среда не ограничивает права API-ключа: если ключ позволяет изменить данные в CRM, агент получает эту возможность вместе с ним.

Linux-среда должна позволять решить задачу

Слишком бедное окружение быстро ограничивает агента. Для поиска по репозиторию полезен rg, для работы с JSON — jq. В зависимости от задачи понадобятся другие пакеты. У нас были случаи, когда требовался браузер. Всё это должно либо присутствовать в образе заранее, либо устанавливаться в процессе работы.

У разработки есть и более тяжёлые требования. Чтобы проверить изменение, агенту может понадобиться поднять Docker-окружение проекта. Это требует соответствующих системных привилегий. Если несколько сессий запускают контейнеры на общей машине, их окружения могут мешать друг другу. Следовательно, возможность выполнить команду нужно рассматривать вместе с изоляцией её последствий.

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

Что вошло в первый публичный анонс AgentBox

На момент сентябрьского анонса мы описали следующий набор возможностей:

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

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

Масштабирование и тесты возникают довольно рано

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

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

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

Собственные продукты стали первым применением

На момент запуска на AgentBox уже работали Orpheus и AI-помощник в RetailCRM. Так мы обкатывали платформу на рабочих сценариях. Для нового проекта всё равно нужно проверить его собственную нагрузку: сколько сессий работает одновременно, сколько ресурсов занимает запуск и какие зависимости нужны агенту.

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

AgentBox появился из потребности организовать эту часть работы для нескольких агентских продуктов. Наше решение на сентябрь 2026 года — отдельные Linux-песочницы, подготовленные или собственные образы и SDK для подключения. Перед переносом своего агента полезно прогнать в такой среде конкретный рабочий сценарий: от старта сессии до запуска команд и получения результата.