AI-агент с Docker-песочницей на LangGraph: готовая архитектура для безопасного исполнения кода

В открытый доступ выложен полный рабочий проект AI-агента, который самостоятельно пишет и исполняет код в изолированной Docker-песочнице. Это не концепт, а готовый репозиторий с оркестратором на LangGraph, субагентами, каталогом инструкций (skills) и жёсткими настройками безопасности контейнера. Для бизнеса это означает, что команда может взять проверенную архитектуру для безопасной автоматизации задач, связанных с кодом — от генерации отчётов до обработки данных — без риска повредить основную инфраструктуру. Решение переводит эксперименты с LLM в категорию контролируемых рабочих процессов. Владельцам и менеджерам нужно оценить, подходит ли эта модель для автоматизации внутренних процессов, требующих исполнения кода, и проверить, соответствуют ли её механизмы изоляции корпоративным стандартам безопасности.

Что представляет собой опубликованный проект

Проект llm-sandbox-agent — это практическая реализация агента, который принимает сложную задачу от пользователя, декомпозирует её, поручает подзадачи субагентам, а те, в свою очередь, пишут и запускают Python-код в изолированном Docker-контейнере. Ключевые компоненты, которые делают эту систему работоспособной:

• Оркестратор на LangGraph: Центральный «мозг», который планирует решение, используя гибридный паттерн ReAct + Plan-Execute. Он разбивает задачу, назначает подзадачи и агрегирует результаты.
• Субагенты с чистым контекстом: Для каждой подзадачи создаётся отдельная сессия с LLM. Это предотвращает переполнение контекста основного агента и позволяет выполнять задачи параллельно.
• Каталог навыков (Skills): Набор детальных инструкций для конкретных типов задач (например, создание презентаций). Инструкции хранятся в файлах и динамически подгружаются в контекст агента по мере необходимости через инструмент read_skill.
• Инструменты управления задачами и файлами: Агент работает с внутренним списком задач (create_todo_list, complete_todo, revise_todo_list) и файлами пользователя (list_input_files, read_file_content).
• Docker Sandbox с жёсткими ограничениями: Для исполнения кода создаётся временный контейнер с ключевыми флагами безопасности: --network=none, --read-only, --cap-drop=ALL, --security-opt=no-new-privileges, запуск от имени non-root пользователя, лимиты на CPU, RAM и количество процессов.

Этот набор превращает абстрактную идею «агента, который пишет код» в инженерную систему с чёткими границами ответственности и контролем безопасности.

Почему эта архитектура меняет подход к автоматизации

Традиционно автоматизация с помощью LLM упиралась в дилемму: либо агент работает только с текстом и API, что ограничивает его возможности, либо ему дают доступ к среде исполнения, что создаёт неприемлемые риски. Представленный проект предлагает третий путь — контролируемую среду исполнения как сервис внутри агентского workflow.

Этот подход переносит фокус с вопроса «можно ли доверять LLM выполнение кода?» на вопрос «как настроить границы доверия для конкретного бизнес-кейса?». Архитектура становится инженерным активом, а не экспериментальным скриптом.

В какие рабочие процессы это можно интегрировать уже сейчас

Проект не является универсальным ИИ-сотрудником. Его сила — в чётко очерченных операциях, где результат — это код, файл или структурированные данные. Типовые сценарии для внедрения:

1. Генерация и адаптация шаблонов кода: Автоматическое создание скриптов для обработки входящих данных определённого формата (CSV, JSON логов) по описанию задачи.
2. Преобразование данных и создание отчётов: Агент получает сырые данные и инструкцию (skill) по построению графика или сводной таблицы, пишет скрипт для Pandas/Matplotlib, исполняет его и возвращает готовый файл.
3. Документирование и создание презентаций: На основе технического текста и структуры данных агент генерирует скрипт, который формирует слайды (например, с помощью библиотеки python-pptx).
4. Локальное тестирование простых алгоритмов: Получение от LLM не только псевдокода, но и рабочего примера с исполнением и проверкой вывода на конкретных тестовых данных.

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

Какие риски и ограничения нельзя игнорировать

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

• Docker — не абсолютная изоляция. Как отмечено в первой части статьи автора, Docker обеспечивает изоляцию на уровне процессов ядра, но не на уровне гипервизора. Для сред с повышенными требованиями к безопасности (мультитенантные среды, работа с персональными данными высокой чувствительности) следует рассмотреть более строгие альтернативы: gVisor или микро-ВМ (например, Firecracker).
• Привязка к Python и LangGraph. Агент заточен на генерацию и исполнение Python-кода. Это разумно для большинства задач анализа данных и автоматизации, но исключает сценарии, требующие других языков. Фреймворк LangGraph задаёт определённый шаблон построения агента, что может потребовать переобучения команды.
• Зависимость от качества инструкций (skills). Эффективность агента напрямую зависит от детальности и точности инструкций в каталоге skills. Их создание и поддержка — это отдельная мета-работа, требующая экспертизы в предметной области.
• Производительность и стоимость. Каждый запуск кода подразумевает создание и уничтожение Docker-контейнера, что добавляет оверхед. При высоких нагрузках это может привести к увеличению времени отклика и затрат на вычислительные ресурсы. Лимиты CPU/RAM, установленные в песочнице, также ограничивают сложность выполняемых задач.

Эти пункты — не критика, а checklist для реалистичной оценки. Проект предлагает отличный баланс для большинства внутренних бизнес-задач, но не является волшебной таблеткой.

Практический чек-лист оценки для внедрения

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

• [ ] Определите пилотный кейс. Выберите одну повторяющуюся задачу, где результат — это файл (отчёт, график, обработанные данные), а логика может быть описана в инструкции.
• [ ] Проверьте требования к изоляции. Согласуйте с ИБ-специалистами: достаточно ли Docker с заданными флагами безопасности для ваших данных и инфраструктуры. Запланируйте тест на попытку «сбега» из контейнера.
• [ ] Проанализируйте каталог skills. Изучите репозиторий и оцените, насколько примеры skills близки к вашим процессам. Спланируйте, кто и как будет писать и поддерживать ваши собственные инструкции.
• [ ] Оцените интеграцию. Поймите, как агент будет получать входные данные (файлы, запросы из CRM) и куда передавать результаты (общее файловое хранилище, почта, API). Проверьте совместимость стека (Python, Docker) с вашим CI/CD и средой исполнения.
• [ ] Рассчитайте экономику. Прикиньте стоимость одного цикла «запрос-ответ» с учётом времени выполнения LLM, создания контейнера и потребления GPU/CPU. Сравните с текущими трудозатратами на выполнение задачи вручную или полуавтоматически.
• [ ] Запланируйте эксперимент. Выделите 2-3 недели инженерному ресурсу не на «изучение», а на развёртывание проекта и решение конкретного пилотного кейса. Критерий успеха — рабочий процесс от запроса до артефакта без ручного вмешательства в код.

Этот чек-лист смещает фокус с технического любопытства на управленческое решение. Цель — не изучить новый фреймворк, а получить работающий и безопасный инструмент автоматизации.

Какое решение можно принять на следующей неделе

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

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

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

Источники

• Habr: LLM Sandbox часть 2 (практика)
• GitHub: репозиторий агента с песочницей

Генерация изображения

• Модель: qwen-image-2.0-pro
• Провайдер: alibaba