独立开发者做Agent文件系统，和同行同起点走出不同方向

前天晚上，和一位做 Agent File System 项目的老师通了电话，想和大家分享一些感悟。

我们都很意外：几乎在同一个月份，我们各自启动了项目，也不约而同地选择了相似的底层设计——Agent 的文件系统应该像 Layer Stack 一样逐层堆叠，每一层都可以记录、分叉和回滚。

虽然上层组件和实现方式有不少差异，但底层的 Layer Stack 理念基本一致。聊起来有一种奇妙的默契：这套设计为什么成立、局限在哪里、搭建过程中会踩哪些坑，很多话都不用说完，对方就懂了。

我们对 AGI/RSI 的判断也很接近：massive rollout to beat smarter models。相比于只追求单个模型更聪明，我们都看重大规模并行尝试所能带来的能力提升。

但有趣的是，同样的底层出发点，因为面向的场景不同，最终走向了两条很不一样的路。

老师的项目是 Cloud Native，更贴近企业的实际业务。他们可以基于用户需求，对运行环境做一些明确的假设；在当前的成本结构里，storage is cheap，因此存储效率并不是最优先的问题。他们更关注的是：如何满足用户需求，让 Agent 稳定地跑起来。

项目上线不久，已经取得了很大的成果。他们为国内头部 AI 公司提供 Agent Hosting，支撑的沙盒规模已经超过十万台。

交流中，我也提出了对一些底层算法在极端情况下的性能与存储开销的担忧，并解释了为什么我会启动 LayerFS，专注底层文件系统的优化。

这里没有谁对谁错。我们面对的是不同的约束，也在优化不同的目标。

作为独立开发者，我从第一天就在想：怎样让 Agent 在大家自己的设备上跑起来，并且让有限的资源能够支撑尽可能多的 Agent，在我们搭建的沙盒里运行？作为local native带着一台老旧的macbook闯天下的开发者来说，我其实很难接受在云端业务中无限storage scale的理念。

第一，是存储效率。

在最初采用的 Layer Stack + Overlay 架构里，即使只改动文件的一小部分，也可能触发整文件的 copy-up 或重写。频繁修改、频繁保留历史版本时，小改动就可能带来很大的存储增量。

在云端，这笔开销可以结合业务收益、存储成本和工程复杂度来权衡。但在个人电脑上，磁盘容量和 I/O 都是直接的限制，不能简单地用增加资源来解决。

第二，是对 Agent 工作单位的理解。

他们的单位是 workspace per task。

我的单位是 workspace per tool call。

我走的路线是： Ephemeral Workspace per Tool Call， Durable Shared History。我希望每一次工具调用都能拥有一个短暂、隔离、可分叉的工作区，并将需要保留的状态变化写入共享历史。这意味着，创建工作区、Copy-on-Write、capture、commit 都会变成高频操作，对延迟和存储效率的要求也会明显提高。

在我目前接触到的项目里，还没见到过有人把agent工具调用当成文件系统记录单位。

这是我相信的agent fs发展方向：

1. Agent 的文件系统应该支持以 tool call 为粒度管理状态。

每一小步都能自动 checkpoint、回滚和 nested fork，让尝试与撤销成为低成本的基础能力。

2. Agent 的文件系统应该保存足以恢复执行的完整工作区。

除了 Git 跟踪的源码，还要考虑被 .gitignore 忽略的依赖、缓存和其他运行所需的文件。恢复一个工作区时，应该尽可能直接继续执行，减少重新安装和重建环境的等待。

3. 存储效率必须成为底层设计的一部分。

我们很难准确预测 Agent 时代会产生多少状态和历史版本。“Storage is cheap”在当前规模下成立，并不意味着它在更高的并发、更细的 checkpoint 粒度、更深的分叉历史下仍然成立。设计至少需要认真回答：这些量同时增长时，系统会怎样？

作为一个单打独斗的开发者，去探索一条大家都不看好，未被验证过的道路确实挺困难，但也挺提升人的。

你既要脑洞大开，去赌一个还没人验证的未来；又要像个神经质一样，天天推演最坏的情况：要是 Agent 抽风了狂写文件怎么办？文件系统量级是现在的100倍怎么办？

但好在我思维足够的发散，心思足够得细腻，也靠着ai的优化闯过重重难关，希望尽可能在一个月之内将性能优化好，功能完善，给agent圈的从事者带来一次革命性的大惊喜

欢迎来 点个 Star ⭐，给独立开发者一点支持，也欢迎一起交流、挑刺。