Если AI-агент напрямую вызывает write или rm в прод-репозитории, одной галлюцинации достаточно для потери данных, утечки секретов или «полузаписанных» конфигов. Virtual File System (VFS) держит агента в одноразовом, проверяемом, откатываемом представлении; реальный диск обновляется только после ревью или CI.
1. Почему нельзя писать напрямую
Кодинг-агенты уверенно выполняют массовые операции. Типичные риски: выход за путь, rm -rf, частичная запись, отсутствие аудита.
2. VFS: три слоя
- Base (только чтение)
- Overlay (запись)
- Publish (слияние)
3. Четыре паттерна
Git worktree, OverlayFS/контейнер, удалённый sandbox, IDE-слой. Долгоживущим агентам нужен выделенный хост.
4. Права
- Запись только в
$WORKSPACE/** .env*,secrets/запрещены по умолчанию- Двойной контроль: file API + shell
5. Атомарная запись
Staging в overlay → unified diff → атомарный rename → run_id для отката.
6. Секреты
Плейсхолдеры в runtime, маскирование логов/diff, ограничение egress.
7. Пример
def safe_resolve(path: str) -> Path:
p = (SANDBOX / path).resolve()
if not str(p).startswith(str(SANDBOX)):
raise PermissionError("path escape")
return p
8. Чеклист
- ☐ Нет неограниченного shell
- ☐ Allowlist на запись
- ☐ Откат на каждый run
- ☐ Выделенный хост для постоянных агентов
9. FAQ
VFS замедляет агента?
Overhead overlay — мс–с, меньше одного LLM round-trip.
Минимум для маленькой команды?
Ветка + PR, без push в main.
Конфликт с Docker?
Код read-only, изменения в writable layer.
Параллельные multi-agent?
Worktree на агента, integrator сливает.
Cursor — это VFS?
Контролируемые tools + правила workspace — та же абстракция.
Облачный Mac?
APFS-снимки и выделенная ФС для долгих агентов.
Выделенные agent runner со снимками
Nuvcloud Mac mini M4—тарифы.