Агент в песочнице или песочница как инструмент? Выбираем архитектуру подключения для deepagents

Критический выбор, который определит вашу архитектуру на годы вперед

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

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

Паттерн 1: Агент внутри песочницы (Agent IN Sandbox)

Представьте клетку. Внутри — агент со всеми своими нейронными сетями, памятью и логикой. Снаружи — мир, к которому он обращается через строго ограниченные каналы. Это классический подход, который многие выбирают по умолчанию. Звучит безопасно? Не всегда.

Как это работает в deepagents

В deepagents этот паттерн реализуется через контейнеризацию всего агентского рантайма. Вы разворачиваете Docker-контейнер (или более изолированную среду типа gVisor, Firecracker), внутри которого живет и ваш агент, и его LLM (если она локальная), и все необходимые инструменты.

# Конфигурация deepagents для паттерна Agent IN Sandbox
sandbox:
  type: "docker"  # или "firecracker", "gvisor"
  image: "deepagents/runtime:2026.2"
  resources:
    cpu: 2
    memory: "4Gi"
    gpu: false

agent:
  runtime_inside_sandbox: true
  llm_provider: "local"  # модель загружается внутрь контейнера
  tools:
    - file_system: "/workspace"
    - code_executor: "python3"
    - network_access: "restricted"

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

Плюсы, которые кажутся очевидными

• Максимальная изоляция. Агент физически не может выйти за пределы контейнера. Даже если он скомпрометирован, ущерб ограничен песочницей.
• Простота оркестрации. Запустил контейнер — получил агента. Остановил — убил все следы его деятельности.
• Полный контроль над средой. Вы точно знаете, какие библиотеки, версии Python, системные пакеты доступны агенту. Никаких «а у меня на машине работает».

Минусы, о которых молчат на старте

• Расточительство ресурсов. Каждый агент тащит за собой полную копию рантайма, библиотек, иногда даже LLM. Память умножается на количество параллельных агентов.
• Холодный старт убивает latency. Запуск нового контейнера — это секунды, а то и десятки секунд. Для интерактивных сценариев неприемлемо.
• Сложность отладки. Залезть внутрь работающего контейнера, посмотреть логи в реальном времени, прикрепить дебаггер — это отдельная боль.
• Проблема с состоянием. Как передавать состояние между сессиями? Сохранять том? Реплицировать базу данных внутрь? Каждая задача превращается в квест.

Главный подводный камень: вы думаете, что повышаете безопасность, но на деле создаете монолитного франкенштейна, которого потом невозможно масштабировать. Как в той истории про три агента вместо одного — начинаете с простого, а заканчиваете ночными дежурствами.

Паттерн 2: Песочница как инструмент (Sandbox as Tool)

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

Это принципиально другой подход. Агент живет в основной среде (или в своей собственной, но не в песочнице). Песочница — это просто один из многих инструментов в его арсенале, наряду с доступом к API, базам данных, браузеру.

Реализация в deepagents через инструменты

Deepagents поддерживает этот паттерн через механизм инструментов (Tools) и расширений. Вы регистрируете песочницу как отдельный сервис, который агент может вызывать по мере необходимости.

# Конфигурация для паттерна Sandbox as Tool
agent:
  runtime_inside_sandbox: false
  llm_provider: "openai"  # модель где-то в облаке
  tools:
    - name: "execute_in_sandbox"
      type: "sandbox_tool"
      endpoint: "http://sandbox-manager:8080/api/execute"
      sandbox_type: "ephemeral"  # временная песочница
      timeout: 30s
    - name: "browse_web"
      type: "browser_tool"
    - name: "query_database"
      type: "sql_tool"

sandbox_manager:
  pool_size: 10  # пул готовых песочниц
  reuse_sandboxes: true  # переиспользование между вызовами
  cleanup_policy: "after_each_call"

Агент получает задачу «напиши и протестируй этот код». Он разбивает ее: 1) Использую инструмент «песочница» для выполнения кода. 2) Проанализирую результат. 3) Если нужно — повторю в новой песочнице. Песочница создается на лету, используется для конкретной операции, уничтожается.

Преимущества, которые меняют всё

• Экономия ресурсов. Один пул песочниц обслуживает десятки агентов. Нет дублирования рантаймов, библиотек, моделей.
• Горячий старт. Песочницы из пула уже запущены и готовы к работе. Задержка — миллисекунды, а не секунды.
• Гибкая политика безопасности. Разным инструментам — разные уровни доступа. Песочнице для тестирования кода — одни разрешения. Песочнице для работы с продовой базой — другие.
• Простота отладки агента. Агент живет в основной среде, его логи, метрики, состояние — все под рукой. Не нужно пробиваться через слои контейнеризации.

Сложности, которые нужно учитывать

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

Гибридные подходы: когда одного паттерна мало

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

Сценарий 1: Мультиагентные системы с разными уровнями доверия

Представьте систему из трех агентов, как в статье про архитектуру subagents:

• Оркестратор (главный агент) — работает вне песочниц, имеет доступ ко всем инструментам, управляет workflow.
• Специалист по коду (subagent) — работает ВНУТРИ песочницы, потому что выполняет потенциально опасный код.
• Аналитик результатов (subagent) — работает ВНЕ песочницы, но использует ее как инструмент для проверки гипотез.

Каждый агент получает архитектуру, соответствующую его роли и уровню риска.

Сценарий 2: Эскалация привилегий

Агент начинает работу в ограниченной песочнице (паттерн 1). Если ему нужно выполнить операцию, требующую больше прав или доступа к специфическим инструментам, он запрашивает «эскалацию» — временный доступ к более мощной песочнице-инструменту (паттерн 2). После выполнения операции доступ отзывается.

# Псевдокод workflow с эскалацией привилегий
def handle_user_request(task):
    # Шаг 1: Агент в базовой песочнице анализирует запрос
    with BasicSandbox() as sandbox:
        analysis = agent.analyze(task, sandbox)
        
        if analysis.requires_dangerous_ops:
            # Шаг 2: Запрос эскалированной песочницы-инструмента
            escalated_sandbox = sandbox_tool.request_escalated(
                reason=analysis.reason,
                timeout="5m"
            )
            result = escalated_sandbox.execute(analysis.plan)
            # Шаг 3: Автоматическая очистка и возврат к базовой среде
            escalated_sandbox.cleanup()
            return result
        else:
            return sandbox.execute_safely(analysis.plan)

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

Практическое руководство: выбираем паттерн для вашего случая

1Определите уровень угрозы агента

Задайте себе три вопроса:

• Агент будет выполнять произвольный код от пользователей?
• Есть ли доступ к чувствительным данным (ключи, пароли, персональные данные)?
• Может ли агент нанести материальный ущерб (остановить продакшен, удалить данные)?

Если на два из трех вопросов ответ «да» — начинайте с паттерна «Агент внутри песочницы». Безопасность важнее производительности.

2Оцените требования к latency

Измерьте, сколько времени занимает холодный старт песочницы в вашем окружении. Docker-контейнер с минимальным рантаймом — 2-5 секунд. Firecracker VM — 100-300 мс. Если ваши пользователи ожидают ответа быстрее секунды, паттерн «Агент внутри песочницы» не подойдет для интерактивных сценариев.

3Спроектируйте границы доверия

Разделите систему на домены с разным уровнем доверия. Как в мультиагентных системах на Bedrock:

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

Четкие границы упрощают аудит безопасности и снижают риски при компрометации одного компонента.

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

Не верьте теоретическим сравнениям. Разверните прототипы:

# Тест паттерна 1: Agent IN Sandbox
python benchmark.py --pattern=in_sandbox --agents=10 --duration=5m

# Тест паттерна 2: Sandbox as Tool  
python benchmark.py --pattern=as_tool --agents=10 --sandbox_pool=5 --duration=5m

# Сравните метрики:
# - Среднее время отклика
# - Пиковое потребление памяти
# - Время восстановления после сбоя песочницы
# - Стоимость инфраструктуры в час

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

Распространенные ошибки и как их избежать

Решение: Используйте принцип наименьших привиледий. Если агенту нужны данные из БД — вынесите этот доступ в отдельный инструмент с четкими ACL, как в системе Agent Skills.

Решение: Регулярно обновляйте инструменты песочницы, используйте изоляцию на уровне процесса (seccomp, AppArmor), мониторьте аномальную активность. Как показано в исследовании CAR-bench, агенты творчески ищут пути обхода ограничений.

Решение: В deepagents используйте политики очистки (cleanup policies): after_each_call, after_each_agent, periodic. Всегда очищайте временные файлы, переменные окружения, историю команд.

Что будет дальше? Эволюция паттернов к 2027 году

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

• Адаптивная изоляция. Система автоматически определяет уровень угрозы агента (на основе его поведения, источника, типа задач) и динамически выбирает паттерн изоляции.
• Песочницы с разной гранулярностью. Не просто «контейнер», а изоляция отдельных системных вызовов, сетевых доступов, областей памяти. Агент получает именно тот уровень изоляции, который нужен для конкретной операции.
• Совместное использование изолированных ресурсов. Несколько агентов работают в одной песочнице, но с разными пространствами имен (namespaces) и контрольными группами (cgroups). Экономия ресурсов без компромиссов безопасности.
• Интеграция с аппаратной изоляцией. Использование Intel SGX, AMD SEV для создания доверенных сред выполнения (TEE) прямо в песочницах. Код агента выполняется в зашифрованном виде, даже администратор хоста не может его проанализировать.

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

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

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