2026 DeepSeek Harness: песочница E2B или постоянная среда?

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

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

Платформенным руководителям — если требуется заранее разделить состояние, секреты, стоимость, аудит и ответственность за сбой между двумя исполнительными контурами.

E2B — это изолированная среда исполнения для кода, данных и инструментов Agent-систем. В официальной документации она описывается как Linux-виртуальная машина, создаваемая по запросу, а не как удалённый Mac. Поэтому E2B нельзя считать заменой macOS-узлу. Официальное описание E2B

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

В DeepSeek Harness необходимо разделять как минимум четыре уровня:

1. Состояние диалога или сессии. История запросов, идентификатор задания и результаты вызовов инструментов относятся к Harness-контролю.
2. Состояние исполнительной среды. Файлы, установленные пакеты, фоновые процессы и локальные базы находятся внутри конкретного окружения.
3. Секреты и полномочия. Ключ API, токены репозитория, доступ к тестовым сервисам и право выполнять внешние записи должны управляться отдельно.
4. Артефакты. Логи, патчи, отчёты, сборки и изображения должны быть переданы в место, которое не зависит от жизни песочницы.

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

Предупреждение. Приостановленная песочница и удалённая песочница — не одно и то же. В E2B режим pause сохраняет состояние, а kill удаляет среду без возможности дальнейшего восстановления. Это должно быть отражено в обработчике завершения задачи, а не оставлено на усмотрение агента.

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

Если ответ положительный, E2B подходит для следующих операций:

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

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

Постоянная среда будет прямее, если разработчик:

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

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

Проверка перед первым запуском

Отметьте пункты:

• [ ] проект собирается из чистого клона;
• [ ] зависимости описаны в lock-файле или аналогичном манифесте;
• [ ] результат можно получить как архив, патч, журнал или другой отдельный артефакт;
• [ ] нет необходимости хранить процесс между заданиями;
• [ ] задача не требует Xcode, Keychain, Safari или подписи iOS;
• [ ] входные данные не должны автоматически попадать в производственную систему;
• [ ] после уничтожения среды можно повторить запуск без ручного восстановления.

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

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

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

Разделите зависимости на три списка.

Восстанавливаемые:

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

Сохраняемые:

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

Запрещённые для автоматической передачи:

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

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

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

1. определить идентификатор задачи;
2. записать путь к рабочему каталогу;
3. собрать изменённые файлы;
4. сохранить стандартный вывод, поток ошибок и код завершения;
5. передать артефакты в контролируемое хранилище;
6. только после подтверждения передачи завершить песочницу.

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

Команда macOS: исполнительная поверхность должна оставаться настоящей

Если Agent-задача зависит от macOS, переносить её в обычную E2B-песочницу нельзя. Речь идёт не о предпочтении интерфейса, а о наличии конкретных системных возможностей:

• Xcode и его локальные компоненты;
• сборка и подпись приложений для iOS;
• Keychain и сертификаты;
• Safari и поведение WebKit;
• системные разрешения macOS;
• физические или виртуальные устройства Apple;
• проверка сценариев, которые зависят от окон, меню и системных диалогов.

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

Такой порядок снижает риск, но не доказывает совместимость автоматически. Команда должна отдельно протестировать:

• версию macOS;
• версию Xcode;
• наличие сертификатов;
• доступ Harness к нужному рабочему каталогу;
• ручное подтверждение системных диалогов;
• возврат сборки и логов обратно в контрольный слой.

Для долгих задач, где Mac нужен постоянно, рациональнее заранее выбрать подходящую постоянную среду Mac для DeepSeek Harness, а E2B оставить промежуточным фильтром для файлов и команд, которым нельзя сразу давать доступ к рабочему Mac.

Платформенная команда: контрольный слой и исполнительный слой

Платформа должна разделять не только машины, но и ответственность.

Постоянная среда отвечает за:

• конфигурацию DeepSeek Harness;
• идентификатор задания;
• состояние рабочего процесса;
• правила маршрутизации;
• аудит действий;
• ручное согласование опасных операций;
• принятие и хранение результатов.

E2B отвечает за:

• запуск кода в изолированном Linux-контуре;
• временную файловую систему;
• выполнение проверок;
• установку одноразовых зависимостей;
• обработку недоверенного ввода;
• возврат ограниченного набора артефактов.

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

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

Безопасность: высокорисковые задания отдельно

Безопасной считается не сама среда, а ограниченный маршрут выполнения.

Для опасного входа задайте следующие границы:

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

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

Опыт из runbook. Если результат нельзя проверить без возврата в постоянную среду, не разрешайте песочнице выполнять финальное действие. Она должна подготовить патч, отчёт или пакет доказательств, а не самостоятельно менять производственное состояние.

Технический лимит времени у E2B нельзя путать с гарантией долгосрочного рабочего места: официальная документация указывает максимальный непрерывный срок работы песочницы до 24 часов для одного из тарифных режимов и до 1 часа для другого, при этом более длинные сценарии предполагают pause и resume. Эти значения могут зависеть от актуального плана и должны проверяться перед внедрением. Актуальные ограничения timeoutMs

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

Перед завершением задания мы рекомендуем формировать пакет:

• task_id;
• версию шаблона среды;
• commit или идентификатор исходного состояния;
• список выполненных команд;
• код завершения;
• журнал;
• изменённые файлы или патч;
• список созданных артефактов;
• причину завершения;
• решение о повторном запуске.

После этого можно выбрать один из трёх вариантов:

1. Удалить среду. Подходит для одноразовой проверки.
2. Поставить на паузу. Подходит для короткого перерыва, если состояние действительно нужно сохранить.
3. Передать задачу в постоянную среду. Подходит, если начинается длительная отладка или требуется macOS.

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

Нет, если Xcode является обязательной частью исполнения. E2B не следует воспринимать как удалённый Mac: официальная документация описывает Linux-песочницы, команды, файлы и процессы, но не обещает macOS-инструменты или системные сервисы Apple. Описание возможностей E2B

Допустим только предварительный этап:

1. извлечь метаданные проекта;
2. проверить структуру исходников;
3. выполнить статический анализ;
4. подготовить патч;
5. проверить скрипты, не зависящие от Xcode;
6. передать результат на реальный Mac;
7. выполнить сборку, подпись и системную проверку;
8. вернуть логи и артефакты в контрольный слой.

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

Для команд, которым нужен предсказуемый macOS-узел, полезно заранее изучить варианты заказа Mac mini для удалённой разработки. Это не отменяет E2B, но помогает правильно определить границу между проверкой кода и настоящим Apple-исполнением.

Ниже — порядок, который можно выполнить без перестройки всей платформы.

Шаг 1. Введите классификатор задания

Добавьте обязательные поля:

• task_id;
• risk_level;
• requires_macos;
• requires_persistent_state;
• needs_external_write;
• artifact_policy;
• owner.

Если поле не заполнено, задача не должна автоматически попадать в E2B.

Шаг 2. Создайте минимальный шаблон E2B

В шаблон включите только:

• необходимые системные пакеты;
• команды запуска;
• проверку версии инструментов;
• каталог для входных файлов;
• каталог для результатов;
• явную команду очистки.

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

Шаг 3. Оставьте постоянную среду для состояния

На Mac или другом управляемом узле храните:

• конфигурацию Harness;
• разрешённые маршруты;
• историю задания;
• закрытые зависимости;
• ручные решения;
• промежуточные результаты;
• инструменты, которые не работают в Linux.

Не передавайте в E2B весь рабочий каталог. Передавайте только входной набор, необходимый для конкретной проверки.

Шаг 4. Введите шлюз секретов

До запуска определите:

• какие ключи нужны;
• кто их владелец;
• срок действия;
• право чтения или записи;
• допустимые домены и сервисы;
• место журналирования.

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

Шаг 5. Зафиксируйте протокол передачи

Минимальный протокол:

1. постоянная среда создаёт task_id;
2. контрольный слой формирует входной архив;
3. E2B получает только этот архив;
4. песочница выполняет проверку;
5. артефакты связываются с task_id;
6. контрольный слой проверяет код завершения и содержимое;
7. Mac выполняет разрешённую финальную операцию;
8. песочница удаляется или ставится на паузу по политике.

Шаг 6. Проведите три приёмочных теста

Тест восстановления. Уничтожьте E2B после подготовки файла. Проверьте, можно ли восстановить результат из переданного артефакта.

Тест состояния. Измените файл и установите локальную зависимость. Перезапустите задачу. Проверьте, что именно сохранилось, а что пришлось создавать заново.

Тест macOS. Выполните тот же сценарий на реальном Mac. Сравните сборку, системные разрешения, подпись и логи. Если результат зависит от Xcode или Keychain, E2B остаётся только предварительным контуром.

Шаг 7. Назначьте владельца сбоя

Для каждого этапа должен быть ответственный:

• Harness — за маршрутизацию и состояние;
• E2B — за запуск временной проверки;
• платформа — за передачу и аудит;
• владелец Mac — за macOS-инструменты и сертификаты;
• команда разработки — за принятие патча и итоговый релиз.

Без такого распределения двухконтурная схема превращается в спор после сбоя: E2B считает задачу завершённой, Mac не получил артефакт, а Harness сохранил только текст диалога.

Выбирайте только E2B, если одновременно выполняются условия:

• задача короткая;
• код или входные данные могут быть недоверенными;
• состояние можно пересоздать;
• macOS не требуется;
• результат передаётся как отдельный артефакт;
• внешняя запись не выполняется автоматически.

Выбирайте только постоянную среду, если:

• нужен Xcode, Safari, Keychain или подпись;
• рабочая сессия продолжается несколько дней;
• важны кэш, локальная база и фоновые процессы;
• требуется частое ручное вмешательство;
• задача должна возвращаться в тот же рабочий каталог.

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

Текущая схема «всё запускать на одном Mac» удобна на старте, но у неё есть реальные недостатки: недоверенный код может загрязнить рабочее пространство, ключи сложнее отделить от обычной сессии, а повторяемость проверки зависит от накопленного локального состояния. Переносить абсолютно всё в E2B тоже неправильно: исчезает macOS-инструментарий, усложняется ручная отладка и появляется отдельная ответственность за выгрузку каждого артефакта. Поэтому для временной вычислительной задачи разумно использовать песочницу, а для длительной разработки, тестов Xcode и сохранённого рабочего места — аренду управляемого Mac через MESHLAUNCH. Такой подход оставляет каждой среде только те обязанности, которые она действительно может выполнять предсказуемо.

Если в вашей команде уже отмечены задачи с постоянным состоянием или macOS-зависимостями, следующим шагом будет разбор доставки облачного Mac для DeepSeek Harness, а не безусловная миграция всех запусков в короткоживущую песочницу.