几个月前，Eli Mernit 发布了一个开源的 Agent 文件系统，发了一条 viral 帖子，拿了一些 discovery calls，转化了几个付费客户。复盘之后，他的结论是：Agent 文件系统不会是一个独立产品。
关于 Agent 文件系统，现有认知基本是对的
- Agents 偏好文件系统做上下文，大多数基于代码模型训练，没人想把 MCP 粘在一起来拉 Salesforce 或 Gmail 的数据
- 文件系统是比数据库更好的接口，Agent 运行
find -name "yourfile"比执行 SQL 更安全更简单 - 最好的上下文层是文件系统接口，背后是物化视图
- 给 Agent 越多上下文，它越有用
- 给 Agent 大量上下文是一个非平凡的存储问题
每个点基本都对。他犯的错误是：假设一个 Agent 文件系统会是一个独立产品。
两个明显的切入点都走不通
"AI Agents 的 Kafka"——流媒体和存储层。对大公司来说这是真实问题。但问题是：Agent 文件系统层是否根本上不同于现有的流媒体基础设施？是否有足够多的公司以足够大的规模摄入上下文，值得一个专业提供商来管理？
"AI Agents 的 Plaid"——集成层。用单一接口让你认证并访问来自不同服务的数据。这很有用，但这个产品的价值在集成本身，不在文件系统。
真实的四类用户
第一类：摄入数据的公司，想要共享文件系统层。 他们不需要新的文件系统，他们需要的是挂载到沙箱的 volume。每个沙箱提供商都已经包含了这个功能。告诉他们用 volumes，给他们链接文档，问题就解决了。
第二类：想要 Obsidian sync 替代品的独立创业者。 有人用 Obsidian，想摄入数据。但这个人群相当 niche，付费意愿低。
第三类：想要消除 MCP 麻烦的开发者。 带适配器的文件系统可以间接解决这个问题，但 Pipedream 等已经做得很好了。价值在集成，不在下面的存储层。
第四类：所有人。 这是最大的桶，也是他一直在回味的。
这类人看懂了演示，把 Gmail、Slack、Linear 接进来，看着邮件填充到本地机器的文件夹里，说了某种版本的："好吧这很 awesome，但然后呢？"
上下文层覆盖你数字生活的想法，抽象地看非常有吸引力。然而一旦它真正存在，你面对的是一个装满文件的文件夹和闪烁的光标。人们真正想要的是有人看他们的数据并在上面构建有用的东西：每日摘要、邮件草稿回复、在工作流里做特定工作的 Agent。他们不想要存储，他们想要一个应用。
结构性问题
基础设施只有在上层应用足够成熟、能吸引买家时才有销路。 现在人们还在搞清楚应用层长什么样，所以底层存储层没有什么可以依附的东西。
文件系统是 Agent 的正确架构组件。人们同意这一点，也想要它。但它嵌入的那个东西的形态还没有被决定。
Agent 文件系统会成为更高级平台的一部分。赢的公司不会卖"AI Agents 的文件系统"。它们会发一个沙箱或 harness，把文件系统作为附加组件放在下面。文件系统层会成为现代 AI 云平台的一个组件，但不会作为一个独立产品。
每个人都知道文件系统是真相，但它只是谜题的一块。