AI Agent 的文件系统：工作区用完即弃，历史却永久共享
多 Agent 并行开发已经成了 AI coding 场景里一个真实的瓶颈。当一个任务被拆给五个 Agent 同时做，每个 Agent 都去 git checkout 一份完整的仓库副本，内存、磁盘和版本冲突的成本很快就会盖过模型本身的收益。LayerFS 在 2026 年 10 月底发布了 v1.1.0，它想做的事情很明确：让每个 Agent 拿到一份可以独立读写的「临时工作区」，工作区用完即弃，但所有 Agent 的提交都沉淀到同一份共享历史里。
这篇东西值得看一眼的原因也在这里——文件系统不是新概念，但「为 AI Agent 设计的文件系统」这个定位很少见。更少见的是，官方在发布说明里把这次没跑过 Linux 测试这件事直接写了出来。
多 Agent 并行之后，冲突不在模型，在文件系统
单个 AI coding agent 在一个 Git 仓库里改代码，问题还不太明显。一旦变成多个 Agent 同时协作，至少会遇到三类问题：每个 Agent 都需要一份完整的工作副本，项目大了之后复制成本很高；Agent 的中间产物——失败尝试、临时文件、未完成的改动——会污染共享工作区；多个 Agent 同时操作同一个工作区时，文件状态互相覆盖，排错极其痛苦。
LayerFS 给出的核心概念是「Ephemeral Workspaces」（临时工作区）。每个 Agent mount 一个基于共享历史的、完整可写的 Workspace，在这个 Workspace 里做任何它想做的事，最后把有意义的变更 commit 成 checkpoint。据 LayerFS 官网 的说明，这些被 commit 的变更会以去重后的 checkpoint 形式保存——也就是说，多个 Agent 的重复内容只存一份。工作区本身是临时的，Agent 结束任务后直接消失。
这套模式的最大卖点是「不用复制 base」。传统做法里，每个 Agent 都要从一个基础镜像或一个 Git commit 开始复制一整套项目文件。LayerFS 的写法是：每个 Agent 在自己的 Workspace 里写数据，读的时候看到的是「基础历史 + 自己写进去的改动」合成出来的结果，底层并不真的给每个 Agent 复制一份完整项目。这也是 GitHub 仓库主页 里一句很关键的话所描述的能力：without copying the base。
Ephemeral Workspace 和 durable history 怎么共存
「临时工作区、持久化历史」这个组合听起来有点矛盾，但它恰好是 LayerFS 的设计核心。官方给出的三个关键词是三个层次：Ephemeral Workspaces（临时工作区）、Durable Results（持久化结果）、Massive Parallelism（大规模并行）。我的理解是：Workspace 层的临时性让 Agent 随便折腾，而 Checkpoint 层的持久性负责把有用的结果留下来。
具体到 v1.1.0，官方明确列出了三个新增能力。第一，JavaScript SDK 从原来的 @layerfs/sdk 拆成了三个包：@layerfs/agent 负责 Projects、Branches、文件、Sandboxes、Workspaces、Exec 和 Commit 这些 Agent 侧的调用；@layerfs/backend 负责 Store 和 daemon 读取，给 UI 和工具用；@layerfs/runtime 负责 Init、移除、worker、Sandbox 和 volume 的生命周期管理。这个拆分让 Agent 开发者不再需要把后端维护逻辑一起引进来。
第二，新增了 layerfs 命令行工具。按官方发布说明，这个命令是给「只拥有 Bash 环境」的 Agent 用的，每个命令对应一次 @layerfs/agent 调用，返回 JSON 结果。官方列出的命令包括 layerfs sandbox create、layerfs workspace mount 1 main、layerfs workspace exec … "npm test" --stream。对很多只通过 shell 操作环境、不直接写 JS 的 Agent 来说，CLI 比 SDK 的门槛低得多。
# LayerFS v1.1.0 官方 release note 里列出的 layerfs 命令
layerfs sandbox create
layerfs workspace mount 1 main
layerfs workspace exec … "npm test" --stream第三是显式 Sandboxes。v1.1.0 里 sandbox.create() 会启动一个 Sandbox，而 workspace.mount(sandbox, branch) 把 Workspace 挂进指定的那个 Sandbox，不再有自动分配逻辑。这虽然让调用代码多一行，但避免了之前版本里 Agent 不知道自己被分配到了哪个环境的问题。
v1.1.0 把 SDK 拆成了三块，代价是版本号有点拧巴
v1.1.0 是一次有意为之的 breaking change。官方在 发布说明 里写得很直接：这一版会 break 掉 1.0.0 的 SDK 代码。1.0.0 的客户端代码需要改包名、用 LayerFS.open(name) 替代 new LayerFS、先 sandbox.create() 再 workspace.mount(sandbox, branch)，以及把原来的 operator 和 workspace.status 换成 @layerfs/backend 对应接口。
有意思的是版本号的处理。发布说明里写道：1.0.0 曾承诺「不兼容的 SDK 变更需要发布新的 major 版本」，但这一次 owner 选择了 1.1.0 而不是 2.0.0，并且明确说这个承诺只对本次发布豁免一次。对使用者来说，这不是什么致命问题，但它意味着「1.x」的版本号在这个项目里并不严格代表兼容性语义。如果你在 1.0.0 上写了集成代码，升级之前要把发布说明里的「what breaks」清单过一遍。
Store 的存储格式倒是没变。官方说 1.0.0 的 Store 能通过 open check，这个结论标注为「read from source, not tested」——从源码读出来的，不是实际测试出来的。v0.1.7 及更早的 Store 会被拒绝。另外，目前只有 Disposable profile 在运行，官方明确表示这一版没有崩溃或断电级别的 durability 保证。也就是说，Agent 写进去的东西在进程正常结束前是安全的，但一旦断电或进程崩溃，不能指望它像数据库一样恢复。
发布说明里最值得看的，是它没跑什么
对于任何做文件系统或者做基础设施的项目，看发布说明时我最关心的不是新增了什么，而是「什么没有跑到」。LayerFS v1.1.0 的发布说明把这个信息写得异常清楚，让我第一次读的时候停顿了片刻。
先说好消息。据官方发布说明，Windows 上 10 个 live scenarios 全部通过，其中 5 个走 SDK、5 个走 layerfs 命令；macOS 上是 9/10 通过，唯一失败的 Depot 场景停在第一条命令，原因是那个 Sandbox 镜像里没有 cargo。重建镜像后一次 rerun 通过。这个测试数据本身是有说服力的——它覆盖了 SDK 和 CLI 两条路径，而且测试对象是真实的 Agent loop（官方的 scripted agent 走完整的 dsh Agent 循环，不需要真实语言模型和 API key）。
问题出在 Linux。发布说明的原话是 No Linux host ran this release，即没有 Linux 主机跑过这次发布。Linux FUSE mount 测试和 real-Store JavaScript 测试都没有运行，owner 对这些测试做了豁免。这句话对 LayerFS 而言的分量，比对一个普通前端项目重得多：LayerFS 这个产品要发挥作用，底层依赖的就是文件系统挂载，而 Linux 是 FUSE mount 最主要的战场。一个「面向 AI coding agents 的文件系统」在发布版本时 Linux mount 测试没有跑过，这个 gap 不是质量问题，而是覆盖问题。
关于性能数据，同样需要留意。官方发布说明明确写了一句：This release makes no new performance claim，意思是 v1.1.0 没有做出新的性能声明，之前 layerfs.ai 页面上放出的 1.0.0 性能数字是在 1.0.0 的源码上测出来的。所以任何想用 1.0.0 的数字去推 1.1.0 的结论，在官方口径下都不成立。到目前（v1.1.0 发布时点）为止，官方没有公开过 1.1.0 的 benchmark。
什么时候可以试，什么时候应当再等等
适合现在上手的是那些在 macOS 或 Windows 上做多 Agent 协作的团队，尤其是 Agent 走 Bash 路线、希望用上显式 Sandbox 和 CLI 的场景。官方发布的 scripted model 测试机制是个加分项：10 个场景可以在没有 API key 的情况下跑完，Mac 和 Windows 用户本地验证起来门槛很低。
该再等等的是 Linux 主机的场景。发布说明说得很明白，Linux 上的 FUSE mount 测试没跑。对大多数生产环境部署在 Linux 容器里的团队来说，这意味着官方没有在这一版交付 Linux 侧可验证的东西。另外，如果你的工作流依赖崩溃恢复或断电后的数据完整性，那么「只有 Disposable profile」的现状也是一个限制条件。还有一点，这次发布是 source-only 的——没有 npm 包、没有预编译二进制、也没有公共镜像，意味着要用就必须自己从源码构建，这本身会筛掉一批只有集成需求的轻量用户。
从发布节奏来看，LayerFS 的项目方在版本发布上不算掩饰，测试矩阵和豁免项都写在了发布说明里。这种透明度在开源项目里并不常见，也让读者能在一个明确的边界内判断这个 v1.1.0 当前能在哪里跑、不能在哪里跑。这也是我读完发布说明后最确定的一条判断：LayerFS v1.1.0 更多是一个「SDK 边界重建」和「工具链补齐」的版本，而不是一个「Linux 生产可用」的版本。
参考来源
评论区
登录后可评论。