Почему всё больше AI-агентов переходят на виртуальные файловые системы

В первой половине 2026 года, если посмотреть, как строят coding-агентов, один паттерн встречается везде: модели больше не читают и не пишут файловую систему хоста напрямую. Вместо этого команды вставляют между ними виртуальную файловую систему (VFS) — от sandbox-инструментов Cursor и абстракций workspace в Claude Code до удалённых песочниц на OpenHands, E2B и Modal. Агенты общаются с диском через управляемый API-слой.

Это больше, чем другая точка монтирования. VFS одновременно выполняет четыре задачи: изоляция, бюджет токенов, снимки и аудируемые изменения. В статье — почему VFS стал стандартом в 2026 году, как он сочетается со слоем памяти, какие реализации выбирают команды и как разработчики iOS / кроссплатформенных приложений подключают VFS-песочницы к облачным Mac-средам сборки.

* По типичным экспериментам с monorepo и рекомендациям вендоров; зависит от структуры repo.

Что такое виртуальная ФС агента?

Классические IDE-плагины дают LLM вызывать read_file("/Users/...") — путь равен разрешению. Agent VFS вставляет между моделью и хранилищем контролируемый API:

• ls / tree: сводки, а не всё дерево в контексте
• grep / glob: поиск по шаблону с попаданиями на уровне строк
• read: чтение диапазонов с бюджетом токенов
• write / patch: структурированные diff
• snapshot / rollback: контрольные точки на уровне задачи

Модель по-прежнему видит дерево файлов; платформа может учитывать, ограничивать, аудировать и отклонять пути при каждом I/O. Это отличие от «склонировать repo в контейнер и запустить bash».

Почему это взлетело в 2026

Три давления совпали, и VFS из оптимизации стал архитектурой по умолчанию.

Безопасность: агент не должен владеть машиной

Когда агенты запускают shell, правят конфиги и ставят пакеты, одна prompt injection может означать RCE. После громких случаев «агент снёс repo» и «случайно отредактировал ~/.ssh» в 2025–2026 продуты по умолчанию ушли в песочницы:

• Белые списки путей: только корень проекта и подкаталоги /tmp
• Контроль сетевого egress: npm/pip через прокси; блокировать произвольный внутренний curl
• Изоляция учётных данных: API-ключи вне VFS; шлюз их подставляет

VFS — единая точка принуждения, чище, чем разбрасывать if path.startswith по каждому инструменту.

Токены: контекст — не бесплатный диск

Как мы показали в реальной месячной стоимости AI-программирования, засунуть monorepo на 100k строк в промпт может стоить доллары за вызов. VFS превращает «владеть кодом» в «получать код по запросу»:

1. grep "class FooBar" для поиска
2. read path:42-80 для функции
3. patch возвращает только diff

Это дополняет выбор между DeepSeek, Claude Code и Cursor: помещается ≠ нужно помещать. VFS — токен-экономика на уровне продукта.

Снимки: откат и воспроизводимость

После десяти правок файлов сборка ломается — пользователи хотят «вернуться на пять минут назад». Снимки VFS перед каждым write (overlay FS, git stash и т.д.) версионируют состояние задачи. Это важно для:

• Общих облачных сессий агента в команде
• CI-ботов, чинящих PR без присмотра
• Компаний, которым нужно показать compliance, что именно изменила модель

Память помнит предпочтения; снимки VFS помнят что изменилось в этом запуске — разные горизонты времени.

Кто что использует

Общее: модели никогда не держат сырые syscall open() — только вызовы инструментов со схемой. Поэтому Claude Code Skills можно безопасно поставлять пакетами возможностей: Skills объявляют разрешённые пути/инструменты; VFS их принуждает.

VFS vs слой памяти

Не путайте VFS с Mem0, Zep или TencentDB Agent Memory:

Зрелые стеки используют три слоя: VFS — «что редактируем сейчас», память — «что этот пользователь всегда хочет», реальный macOS — «компилируется и выходит в прод».

Сравнение реализаций

Если строите VFS сами, приоритет — grep <2 с на 100k файлов и атомарные patch. Многие команды кладут git worktree снизу, а VFS сверху как политику + обёртку токенов — прагматичный MVP.

Практический путь для iOS / кроссплатформы

Команды Flutter / React Native часто думают: если flutter build проходит в VFS-песочнице, можно выпускать. На практике:

1. VFS-песочница: агент правит Dart/Swift, гоняет unit-тесты, черновик PR
2. Память: UDID тестового устройства, только TestFlight, истёкший профиль в прошлый раз
3. Облачный Mac: реальный xcodebuild, архив, загрузка в App Store Connect

См. RN / Flutter: отладка на iOS-устройстве и App Store. Цепочка Apple привязана к железу и macOS. VFS решает безопасное редактирование кода; облачный Mac Zilmac — сборки, которые компилируются и выходят в среде Apple.

Рекомендуемый pipeline: завершить feature-ветку в локальной или облачной VFS-песочнице → память фиксирует ограничения сборки → webhook запускает CI на облачном Mac → сводки логов сбоев пишутся обратно в память для следующей сессии агента.

Рекомендации и антипаттерны

Рекомендуемые практики

• Политика путей deny-all по умолчанию; каталоги разрешать явно
• Вывод инструментов больше N KB — в файлы VFS; в контексте только сводка + путь
• В конце задачи синхронизировать ключевые неслитые diff в память или issue
• Сборки и подпись физически отделить от VFS, чтобы агенты не трогали provisioning profiles

Антипаттерны

• ❌ Использовать VFS как JSON-БД бизнес-данных — нужна память или настоящая БД
• ❌ Давать агентам read всего node_modules — чёрная дыра токенов
• ❌ Тонкие обёртки host-path без снимков — откат невозможен
• ❌ Ждать, что VFS заменит Xcode — подпись и отладка на устройстве всё ещё требуют macOS

FAQ

Чем agent VFS отличается от Docker mount?

Docker сохраняет реальную семантику путей. Agent VFS добавляет API агента плюс бюджеты токенов, снимки и белые списки — это абстракция, а не контейнер.

Нужен ли VFS, если есть память?

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

Может ли VFS заменить каталог проекта Xcode?

Не для подписи и сборки, но сильно повышает безопасность, когда агенты правят код. Прагматичная связка: VFS-песочница + сборки на облачном Mac.

Как выбрать VFS для своего агента?

Прототип на git worktree; в проде — по потребности в изоляции: OpenHands, E2B или свой шлюз. Бенчмарк grep, снимков и мультитенантной изоляции.