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

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

Зачем агентам RL нужна песочница

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

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

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

Для RL-ориентированных агентных систем полезный вопрос не просто «безопасна ли эта песочница?». Лучший вопрос: может ли эта среда выполнения поддерживать повторяемые эксперименты, не допуская, чтобы одно испытание незаметно загрязняло следующее?

Что означает сбрасываемость для испытаний RL-агентов

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

Песочница для RL-агента может нуждаться в сбросе:

• Файлов, созданных, отредактированных, удаленных или загруженных во время испытания.
• Установленных пакетов, кешей сборки, скомпилированных артефактов и временных файлов.
• Запущенных процессов, портов, сокетов, сессий браузера и фоновых задач.
• Переменных окружения и ограниченных учетных данных.
• Фикстур базы данных, локальных сервисов, очередей или имитаций API.
• Сетевой политики, конфигурации реестра пакетов и разрешений инструментов.
• Состояния оценки, журналов наград и входных данных проверяющего.

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

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

Повторяемые окружения и снимки состояния

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

Существует три распространенных паттерна базовой линии:

Паттерн	Наилучшее применение	Остерегайтесь
Новая песочница из шаблона	Независимые эпизоды, пакетные оценки, задачи программирования, браузерные задачи	Время запуска и установки пакетов может доминировать в коротких испытаниях
Снимок и восстановление	Многошаговые задачи, которым требуется подготовленное окружение перед каждой попыткой	Дрейф снимков может скрыть изменения, если снимок не версионирован
Долгоживущая песочница с контролируемыми контрольными точками	Интерактивная отладка, задачи с учебной программой, коррекция с участием человека	Состояние может утекать между испытаниями, если контрольные точки не явны

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

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

Детерминированные и недетерминированные запуски

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

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

• Закрепите версии пакетов, образы контейнеров, наборы данных, промпты, код оценщика и конфигурацию модели.
• Записывайте случайные зерна (седы) там, где модель, окружение или оценщик их поддерживают.
• Заморозьте фикстуры бенчмарков и ожидаемые результаты.
• Направляйте установку пакетов через одобренные реестры или кеши.
• Избегайте использования живых производственных систем в качестве источников наград, если задача явно не связана с интеграцией в реальном времени.
• Фиксируйте точные команды, вызовы инструментов, файлы и сетевые адреса, использованные во время выполнения.

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

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

Ограничения ресурсов и времени для циклов испытаний

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

Установите ограничения на уровне песочницы, а не только внутри промптов агента:

Ограничение	Почему это важно для RL-агентов
Тайм-аут по часам	Предотвращает блокировку пакета зависшими эпизодами
Квота CPU и памяти	Не дает одному испытанию лишать ресурсов соседние испытания
Квота диска	Контролирует логи, кеши, установки пакетов и сгенерированные артефакты
Лимит процессов	Уменьшает количество утекших подпроцессов и сбоев фоновых задач
Сетевая политика	Предотвращает неожиданные вызовы, загрузки или внутренний доступ
Лимит размера вывода	Поддерживает полезность контекста модели и конвейеров телеметрии
Ограничение на количество одновременных песочниц	Защищает бюджет и общую инфраструктуру во время перебора гиперпараметров

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

Телеметрия для наград, оценки и отладки

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

Полезная телеметрия включает:

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

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

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

Границы файлов, сети и небезопасных действий

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

Используйте границы файловой системы, соответствующие задаче:

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

Сетевая политика требует такой же точности. Бенчмарк для программирования может не нуждаться в доступе в интернет. Задача по установке пакетов может нуждаться в белом списке реестров. Оценка браузерного агента может требовать конкретных публичных веб-сайтов и блокировки внутренних метаданных эндпоинтов. Рабочий процесс агента данных может нуждаться в узком API вместо широкого доступа к частной сети.

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

Захват артефактов и проверка человеком

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

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

Проверка человеком относится к границе, где эксперименты в песочнице иначе повлияли бы на внешние системы. Хорошие точки проверки включают:

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

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

Где подходит Novita Agent Sandbox

Novita Agent Sandbox — это облачная среда выполнения песочницы для AI-агентов, которым нужны изолированные окружения для выполнения кода, работы с файловой системой, браузерных рабочих процессов и длительных задач. Текущая документация Novita описывает возможности песочницы, такие как выполнение команд, операции с файлами, шаблоны, снимки, пауза и возобновление, фоновое выполнение и управление жизненным циклом через SDK/CLI.

Для RL-стильных агентных работ эти примитивы соответствуют основным требованиям окружения:

Требование RL-агента	Примитив песочницы для поиска
Начинать каждое испытание с известной базовой линии	Создание песочницы на основе шаблона или снимка
Выполнять действия агента без доступа к хосту	Изолированное выполнение команд и ограниченная файловая система
Сохранять только выбранные выходные данные	Операции с файлами и политика экспорта артефактов
Поддерживать длительные оценки	Фоновое выполнение, пауза/возобновление, политика тайм-аута
Отлаживать неудачные или удивительные испытания	Логи, результаты команд, различия файлов и захваченные артефакты
Отделять оценку от логики приложения	Управление жизненным циклом через SDK/CLI для каждого запуска

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

Контрольный список песочницы для RL-агента

Используйте этот контрольный список перед запуском повторяющихся RL-стилей испытаний или больших пакетов оценки:

Область	Вопросы для ответа
Базовая линия	Какой шаблон, снимок, набор данных, набор зависимостей и версия оценщика используются для каждого испытания?
Сброс	Какое состояние стирается между испытаниями, и какое состояние намеренно сохраняется?
Детерминизм	Какие зерна (сиды), версии пакетов, настройки модели и фикстуры закреплены?
Файловая система	Какие пути доступны только для чтения, для записи, скрыты или экспортируются?
Сеть	Заблокирован ли исходящий трафик, разрешен по белому списку, проксирован, регистрируется или зависит от задачи?
Ресурсы	Каковы ограничения по CPU, памяти, диску, процессам, тайм-ауту и параллелизму?
Инструменты	Какие команды, менеджеры пакетов, браузеры и API может вызывать агент?
Награды	Какие доказательства питают награду, и может ли оценка быть объяснена из захваченных артефактов?
Телеметрия	Логируются ли команды, изменения файлов, сетевые вызовы, выходные данные и результаты оценщика без хранения секретов?
Артефакты	Какие выходные данные копируются наружу, сохраняются, редактируются или отбрасываются?
Проверка человеком	Какие действия требуют одобрения перед выходом из песочницы или касаются внешних систем?

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

ЧЗВ

Что такое песочница для RL-агента?

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

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

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

Делают ли песочницы для RL-агентов автономных агентов безопасными?

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

Должно ли каждое RL-испытание начинаться с новой песочницы?

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

Что должна логировать песочница для RL-агента?

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

Рекомендуемые статьи

• MCP Servers in Isolated Sandboxes: Filesystem, Secrets, and Network Tradeoffs
• Building a Coding Agent with Novita’s Agent Sandbox
• How Agent Sandboxes Power Secure, Scalable AI Innovation