LayerFS 1.0: open source файловая система для параллельных ИИ-агентов

LayerFS 1.0 вышла 21 октября и решает проблему, которую большинство команд пока обходит вручную: несколько агентов работают с одним проектом и мешают друг другу. Разработчик из Ephemeral AI Lab предлагает не блокировки и не копирование каталогов, а файловую систему, где каждый агент получает полный рабочий каталог поверх общей истории.

Проект написан на Rust, распространяется по лицензии MIT и за неделю собрал больше двух тысяч звёзд на GitHub. Ниже — что именно он делает, где цифры выглядят убедительно и в каких местах доверять ему пока рано.

Что такое LayerFS и какую проблему она решает

Обычный сценарий выглядит так. Вы запускаете трёх агентов на одном репозитории. Первый правит конфиг, второй ставит зависимости, третий пересобирает проект. Через десять минут у вас три разных состояния рабочего каталога, и никто не знает, какое из них правильное.

Костыли известны: копировать каталог на каждого агента (дорого по месту и медленно на старте), давать каждому отдельный контейнер (дорого по времени), или запускать по очереди (медленно всегда).

LayerFS предлагает третий вариант. Агент монтирует полный записываемый Workspace поверх уже зафиксированной истории, работает в нём, коммитит изменения и уходит. База при этом не копируется: монтирование связывает готовое дерево целиком. По сути это open source workspace для агентов, где каталог выдаётся на время работы и исчезает после коммита.

Формулировка из документации звучит сухо, но по смыслу это git для файловой системы агента. Только вместо текстовых диффов там чанки файлов, а вместо ветки — Branch, который можно смонтировать и посмотреть глазами.

Как устроена файловая система для агентов

Внутри три сущности, и понимать их стоит по отдельности.

Store. Один файл SQLite, в котором лежат все ветки, коммиты и объекты содержимого. Никакого сервера базы данных нет: каждый демон и каждый процесс SDK открывает файл напрямую. Именно поэтому систему можно поднять на одной машине и не думать про инфраструктуру.

Workspace. Монтирование, которое привязывает всё зафиксированное дерево без копирования. Записи идут в собственный overlay рабочей области и остаются там, пока вы не сделаете Commit. Размонтирование удаляет overlay, но не историю.

Branch и Commit. Ветка — это записываемая линия коммитов. Публикация ветки в main добавляет слой. Контент режется на чанки и хранится один раз, поэтому вторая копия того же файла не занимает места.

Схема работы выглядит так: вызов инструмента агентом идёт либо через SDK внутри процесса, либо через Bash, который монтирует Workspace, выполняет команду, коммитит и размонтирует. Снаружи это выглядит как обычная файловая система, и агенту не нужно знать, что под ним слои.

Что даёт checkpoint агентов на практике

Главная практическая ценность — не экономия места, а возможность откатиться. Каждый шаг агента становится точкой возврата, и это меняет то, как вы отлаживаете его поведение.

Три сценария, где это работает сразу.

Первый: агент сломал конфиг и ушёл дальше. Вы не восстанавливаете файл руками, а откатываете ветку к предыдущему checkpoint и смотрите, что он сделал.

Второй: два агента правят один файл. Система отказывает второму коммиту с конфликтом. Если файл заведомо конфликтный по природе (например, лог), вы помечаете его правилом .lww, и тогда побеждает последняя правка.

Третий: нужен эксперимент. Вы форкаете коммит на любой глубине, гоняете альтернативную стратегию в изолированной ветке и либо мержите результат, либо выбрасываете ветку целиком. Основная линия при этом не страдает.

Есть и неочевидный плюс: история не перезаписывается. Объекты только добавляются, Store растёт, но не переписывается. Для аудита поведения агента это удобнее, чем логи: вы видите не «агент вызвал edit», а фактическое состояние файлов после каждого шага.

Цифры: насколько это быстрее и компактнее

Замеры опубликованы вместе с релизом, и они честнее обычного: разработчики сами показывают, где система проигрывает.

Последняя строка важна. На случайных смешанных нагрузках система быстрее в 1,49–2,23 раза, а вот последовательная запись проседает втрое, а последовательное чтение теряет примерно 20%. Для рабочего каталога агента это терпимо: агенты редко пишут гигабайты подряд. Для хранилища бэкапов такая система не подходит.

Отдельно про сжатие: 157 снимков реального проекта заняли 100 МБ вместо почти 2 ГБ у Btrfs с zstd. Это и есть главный аргумент: держать историю каждого шага агента становится дешево.

Как запустить LayerFS 1.0

Проект ставится из исходников, готовых бинарников в релизе нет. Официально описанный путь — через плагин dsh-layerfs для DeepSeek Harness, там же есть живой интерфейс с вкладками Work и History.

1. Проверьте, что у вас Linux с поддержкой FUSE: на этой основе работает монтирование.
2. Соберите проект из исходников или подключите плагин для DSH.
3. Смонтируйте Workspace на нужный каталог проекта.
4. Запустите агента, дайте ему поработать и сделайте Commit.
5. Размонтируйте Workspace: overlay удалится, история останется в Store.

Для Windows в текущей ветке main появилась поддержка через WSL2 и собственный Linux Docker Engine, но это добавлено уже после релиза 1.0.0, отдельным адаптером.

Где ограничения и о чём молчат бенчмарки

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

Второе: конфликты решаются отказом. Если два коммита меняют один файл и правила .lww нет, второй не пройдёт. В командной работе это правильно, в одноагентной — иногда раздражает.

Третье: последовательная запись медленная, и на задачах вроде сборки большого бинарника вы это почувствуете. Профиль нагрузки стоит прикинуть до внедрения, а не после.

Четвёртое: экосистема маленькая. Проект живёт неделю в статусе 1.0, у него 95 форков и открытые задачи в трекере, а совместимость с инструментами вне DSH пока проверена слабо. Ставить его в продакшен прямо сейчас — риск, который надо осознавать.

Зачем это тому, кто работает с агентами с телефона

LayerFS не приложение для Android: это серверная файловая система, и на телефоне она не запустится. Но косвенно она касается всех, кто гоняет агентов на удалённой машине, а с телефона только проверяет результат.

Практический сценарий: агент работает на сервере, вы смотрите историю через веб-интерфейс DSH или через SSH-клиент и откатываете неудачный шаг, не перезапуская всю задачу. Раньше для этого нужен был доступ к терминалу и понимание, что именно сломалось. Теперь достаточно выбрать checkpoint.

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

Итог: стоит ли смотреть в сторону LayerFS

Если у вас один агент и один проект, выигрыш будет скромным: история шагов приятна, но не критична. Если агентов несколько и они работают параллельно, идея с общим Store и отдельными Workspace закрывает реальную боль, которую сейчас лечат копированием каталогов.

Скачать LayerFS 1.0 можно с GitHub: проект открытый, лицензия MIT, сборка из исходников. Перед тем как переносить на него рабочую историю, проверьте две вещи: поддержку FUSE на вашей системе и то, что у вас есть независимая копия данных, которые нельзя потерять. Остальное — вопрос привычки к новой схеме веток и пары вечеров на разбор документации.