Как добавить интерпретатор кода в AI-приложение с помощью песочницы

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

Что интерпретатор кода добавляет AI-приложению

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

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

Функции интерпретатора кода особенно полезны для:

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

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

Эталонная архитектура

Практическая архитектура интерпретатора кода состоит из пяти частей:

Уровень	Ответственность	Типичный выбор дизайна
Пользовательский интерфейс	Загружать файлы, показывать прогресс, отображать артефакты, запрашивать одобрение	Хранить загруженные файлы в рамках текущего разговора или проекта
Сервер приложения	Аутентифицировать пользователей, обеспечивать политику, создавать сессии песочницы, хранить журналы	Никогда не раскрывать сырые учетные данные песочницы браузеру
Оркестрация модели	Решать, когда вызывать инструменты кода, и обобщать результаты	Использовать структурированные вызовы инструментов вместо разбора свободного текста
Среда выполнения песочницы	Выполнять Python, хранить временные файлы, устанавливать разрешенные пакеты	Запускать с контролем ресурсов, тайм-аута и очистки
Хранилище артефактов	Сохранять одобренные выходы, такие как диаграммы, CSV, отчеты и журналы	Хранить только выходы, которые приложение или пользователь приняли

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

Такое разделение сохраняет полезность модели, не делая ее границей безопасности.

Поток реализации

Надежный поток реализации начинается до выполнения любого кода.

1. Принять задачу пользователя и файлы

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

Например, пользователь может попросить:

«Проанализируйте этот CSV, найдите основные драйверы дохода и верните диаграмму с кратким объяснением».

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

2. Позволить модели запросить вызов инструмента

Определите узкую поверхность инструментов. Типичная первая версия требует лишь нескольких инструментов:

{
  "name": "run_python",
  "arguments": {
    "code": "import pandas as pd\n...",
    "input_files": ["sales.csv"],
    "expected_outputs": ["summary.json", "revenue_chart.png"],
    "timeout_seconds": 30
  }
}

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

3. Создать или повторно использовать сессию песочницы

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

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

4. Выполнить Python и захватить результаты

Запустите код через API выполнения песочницы или собственного рабочего внутри песочницы. Захватите структурированный вывод выполнения:

{
  "status": "success",
  "stdout": "Loaded 12,448 rows\n",
  "stderr": "",
  "artifacts": [
    {
      "path": "revenue_chart.png",
      "type": "image/png",
      "size_bytes": 84231
    },
    {
      "path": "summary.json",
      "type": "application/json",
      "size_bytes": 1260
    }
  ],
  "duration_ms": 1840
}

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

5. Вернуть результаты пользователю

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

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

Обработка файлов, выходов и сгенерированных артефактов

Обработка файлов — это то, где многие проекты интерпретаторов кода становятся запутанными. Относитесь к входам и выходам как к отдельным объектам.

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

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

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

Полезная политика артефактов выглядит так:

Тип артефакта	Обработка по умолчанию
Диаграммы .png, .jpg, .webp, .svg	Предварительный просмотр в интерфейсе после проверки размера и типа
Выходы данных .csv, .json, .xlsx	Предложение загрузки и обобщение изменений
Отчеты .txt, .md, .pdf	Предварительный просмотр или загрузка в зависимости от размера
.py, .sh, бинарники, архивы	Не запускать и не открывать автоматически; требовать явной проверки

Если ваше приложение поддерживает постоянные проекты, храните принятые артефакты вне песочницы. Песочница должна оставаться одноразовой.

Установка политики пакетов и сети

Большинство рабочих процессов интерпретатора кода требуют пакетов, таких как pandas, NumPy, matplotlib, seaborn, scikit-learn или openpyxl. Вопрос в том, предустановлены ли пакеты, устанавливаются по запросу или встроены в пользовательские шаблоны песочницы.

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

Установите политику пакетов до запуска:

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

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

Применение ограничений, журналов, очистки и проверки

Интерпретатор кода — это производственная функция, а не демонстрационный запускатель ячеек. Установите ограничения вокруг него с самого начала.

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

• максимальное время выполнения на ячейку или вызов инструмента
• максимальный размер вывода для stdout и stderr
• максимальный размер артефакта и количество файлов
• ограничения ЦП и памяти, соответствующие задаче
• разрешенные расширения файлов для предварительного просмотра и загрузки
• ограничения параллелизма на пользователя и рабочую область
• правила очистки временных сессий и файлов

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

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

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

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

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

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

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

Контрольный список оценки

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

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

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

Заключение

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

Часто задаваемые вопросы

Какой самый безопасный способ добавить интерпретатор кода?

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

Должна ли модель контролировать установку пакетов?

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

Нужен ли всем задачам интерпретатора кода доступ к сети?

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

Что должен видеть пользователь после выполнения?

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

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

• Создание MCP-сервера удаленного выполнения кода с помощью Novita Sandbox и библиотеки mcp-use
• Как использовать Novita AI с Goose: более 200 моделей LLM
• Агент против рабочего процесса: ключевые различия и практические компромиссы