Когда ИИ-агенту предоставляется доступ к изолированной среде (Sandbox), возникает фундаментальный вопрос о том, как организовать файлы, с которыми он будет работать. Платформа Docker Sandbox (именуемая как sbx) предоставляет три основные модели управления исходным кодом, каждая из которых оказывает непосредственное влияние на рабочий процесс разработчика и его взаимодействие с агентом.
1. Прямое монтирование (Shared Mounts)
Этот вариант позволяет напрямую делить текущий рабочий путь с хост-машины с изолированной средой. При запуске sbx run из папки проекта папка монтируется по тому же абсолютному пути внутри среды. Эта модель идеально подходит для тесного сотрудничества над одной задачей, так как разработчик может видеть изменения в своем локальном редакторе по мере их возникновения, а локальные серверы разработки могут подхватывать правки с помощью функции быстрой перезагрузки (Hot Reload).
Предупреждение: Следует опасаться конфликтов зависимостей (Dependencies); пакеты, содержащие нативные бинарные файлы (Native Binaries), могут работать в изолированной среде Linux и завершаться сбоем в macOS или Windows, поэтому рекомендуется унифицировать среду выполнения или разделить установку зависимостей.
2. Использование рабочих деревьев Git (Git Worktrees)
Этот вариант подходит для одновременного выполнения нескольких задач. Он предоставляет каждой задаче собственную папку и ветку (Branch), что позволяет привязать каждое рабочее дерево к отдельной изолированной среде. Преимущество здесь заключается в полной изоляции задач, однако сохраняется одно техническое ограничение: файл .git указывает на метаданные вне диапазона монтирования, а это означает, что такие операции, как проверка статуса (git status) или переключение между ветками, должны выполняться с хост-машины.
3. Режим клонирования (Clone Mode)
В этом режиме инструмент sbx создает независимую копию кода внутри изолированной среды, при этом код хоста монтируется только для чтения. Это дает агенту полный доступ к Git внутри среды, что делает его полностью независимым в управлении ветками и коммитами (Commits). После завершения работы разработчик может забрать изменения через удаленный репозиторий Git (Remote).
Что это меняет в рабочем процессе разработчика?
Выбор подходящего метода зависит от характера задачи и степени вашего желания вмешиваться напрямую:
- Тесное сотрудничество: используйте прямое монтирование, если вы хотите следить за работой агента в режиме реального времени.
- Независимость: используйте режим клонирования или полностью изолированные среды (Mountless), если вы хотите предоставить агенту пространство для управления задачами без ущерба для вашей локальной рабочей среды.
- Управление несколькими проектами: инструменты управления рабочими областями (Workspace Managers) можно использовать для объединения нескольких репозиториев в одну среду, что упрощает работу агента со связанными проектами (например, фронтендом и бэкендом).
Помните, что изолированные среды, которые не полагаются на монтирование файлов хоста (Mountless), требуют ручного управления портами (Ports) для доступа к серверам разработки из вашего локального браузера — практика, которая повышает безопасность изоляции, но добавляет несколько дополнительных шагов настройки.