面向智能体的文件系统

面向智能体的文件系统

人工智能与机器学习

面向智能体的文件系统Sarah Catanzaro分享2026年5月27日

如果你今年在X平台上花过时间（在等待Claude Code或Codex生成你的API集成时），你可能会认为AI智能体再过几周就会取代你的工作。快速起飞是有可能的，但今天，智能体还相当温驯。相对较少的智能体访问相对较少的文件，进行增量更新。智能体确实在规模化运作，但那只是人类的规模，而非智能体的规模。因此，这些智能体的基础设施需求是可控的。它们可以使用为凡人构建的系统来凑合。

但如果专家们是对的，这种情况很快就会改变。将会有大量的智能体，同时处理大量文件，并进行大量更新。随着智能体能力越来越强，它们如何读取、写入和更新数据的问题也变得越来越复杂。近几个月来，我被X平台上的意见领袖们说服了：我现在相信，对于智能体来说，文件系统比数据库或对象存储更合适。但我并不那么确信今天的文件系统已经为AI的未来做好了准备。

为什么是文件系统？

当我第一次看到文件系统在X平台上成为热门话题时，我以为这不过是AI工程师们探索的又一个兔子洞，就像图RAG或SAEs一样。作为一名数据科学家，在被Pandas折磨多年后，我终于发现了SQL数据库，并很快确信我们只需要它。所有其他的数据管理系统都是蛇油（Foundation DB除外，也许Kafka也算，当然还有WarpStream）。

但互联网上的人偶尔确实知道一些事情，所以我决定深入探究。我们已经看到，当基础设施决策在一个技术范式的早期做出时，它们往往会固化。我们现在关于智能体如何与数据交互所做的选择，将塑造未来几年什么是可能的、可行的以及痛苦的。所以我们最好确保文件系统是正确的选择。否则就有可能成为技术债务界的Bruno Mars。

所以我做了我一直做的事。我和比我聪明得多的人（以及智能体）进行了交谈。而那些构建数据基础设施超过十年的人们让我相信，文件系统确实是正确的道路。原因如下：

训练语料库包含大量文件系统操作并捕获上下文

来自公共互联网的大量代码（基础模型正是在此之上训练的）代表了与文件系统交互的应用程序。读取文件、写入文件、导航目录结构以及操作路径的代码是软件工程的通用语言。打开任何一个GitHub仓库，你都会发现文件I/O操作遍布其中，例如配置解析、日志写入、资源加载和数据序列化。

数据库代码在训练语料库中也有很好的体现，但它通常依赖于代码本身未能完全捕获的上下文，例如模式、约束和特定于生产环境的访问模式。在实践中，许多数据库交互与模型在生成时看不到的外部状态紧密耦合。

这造成了一种不对称。文件系统操作具有极其简单的语义；它们通常是自包含的，可以在本地上下文中执行。相比之下，数据库操作更依赖于上下文，对正确性也更敏感；它们丰富的语义可能在不同系统之间微妙地不同。因此，当智能体处理类似文件的抽象时（其中必要的状态是显式且本地可访问的），它们往往更可靠；而当与依赖隐式或外部结构的系统交互时，可靠性则较低。

文件系统能满足智能体处理数据的需求

在生成式AI热潮之前，有两种常见的数据交互模式：OLTP和OLAP。应用程序会使用事务并发地读取、写入和更新数据库中的多个条目。事务必须快速且可靠。虽然许多OLAP系统支持读取事务内的快照隔离，但它们是为不同的工作负载设计的，在这种工作负载中，分析师通过BI和其他报告应用程序临时或重复地运行查询。分析工作负载侧重于聚合和探索大量结构化数据以生成洞察。

相比之下，智能体具有特殊的数据访问模式。考虑几个例子：
一个编码智能体必须检索包含源代码的文件，理解其结构，修改特定函数，并将更新后的文件写回。
一个法律智能体可能从存储中提取多份合同，从每份合同中提取相关条款，交叉引用它们，并综合出一个答案。

• 一个研究智能体可能遍历一组论文，提取关键发现，并编写一份文献综述。

这些工作流具有共同的特征。它们的特点是相对高吞吐量、低延迟的操作，针对从较大语料库中检索到的特定、通常较小、非结构化的文件。有时，智能体必须访问一系列文档，检索相互依赖的文件（例如，读取文件A，使用其内容确定要修改文件B的哪个部分，并将结果写入文件C）。

为什么不是____

为什么不是OLTP数据库？关系型数据库非常适合具有清晰关系结构的数据——可以表示为带有模式、链接实体的外键以及消除冗余的规范化形式的表格的数据集。当可靠性至关重要时，当你需要严格的一致性、原子性的多行更新和回滚保证时，它们尤其有用。

大多数智能体工作负载不符合这种模式。

当一个编码智能体处理一个代码仓库时，“数据”是源代码——具有丰富、不规则结构的文本文件，这些结构因语言、框架和项目约定而异。当一个法律智能体处理合同时，“数据”是自然语言——具有隐式结构、难以用清晰的表格形式表示的文档。在这两种情况下，底层数据都是非结构化或松散结构化的。

这可能在模式层面造成摩擦。关系型数据库通常需要预先定义模式，但智能体并不总是事先知道它们将存储或处理什么。它们的数据模型会随着任务、工具和上下文的变化而演变。在表格中建模这可能导致频繁的模式更改或通用表示，从而将结构和验证卸载到应用程序层。

这种不匹配也可能延伸到访问模式。智能体通常不会操作小的、范围明确的记录行。相反，它们读取和写入大的、连续的数据块，例如整个文件、完整文档或完整历史记录。它们经常请求“最后N步”或需要将整个对话或代码库加载到上下文中。这些工作负载本质上是顺序的和面向历史的。文件自然地映射到这个模型，而OLTP系统倾向于将数据视为无序的行集合，使得有序的历史记录和追加式工作流难以自然表达，尤其是在涉及大型blob或嵌套结构时。

你可以通过将非结构化数据存储为blob或JSON，并使用关系型数据库作为元数据索引来解决这个问题。许多系统正是这样做的。但在这一点上，数据库不再用于其预期目的。你实际上是在事务引擎之上构建了一个文件系统抽象，同时仍然为一个针对非常不同工作负载优化的系统支付运营和性能成本……为什么不直接使用合适的工具来完成工作呢？

显然，我不认为关系型数据库不好；我怀疑它们将在智能体和LLM驱动应用程序的开发中发挥关键作用。然而，许多智能体系统操作于不断演变的文档、日志和工件集合，将这些干净地映射到模式优先、面向行的接口上可能会引入额外的复杂性。

为什么不是对象存储？对象存储（S3、GCS、Azure Blob Storage）针对完全不同的工作负载进行了优化。它专为大型对象（如媒体文件、数据湖归档、备份快照或以TB或PB计量的ML训练数据集）的高吞吐量而构建。它主要也是为持久性而设计的，具有复制和持久性保证，使其成为长期存储的理想选择。

智能体工作负载常常颠覆这些假设。智能体频繁检索小文件，经常更新它们，并在紧密循环中操作，读取上下文、写入中间状态、读回并迭代。对象存储对于这种模式来说太慢了。S3风格的系统针对吞吐量和持久性进行了优化，而不是低每操作延迟，这使得重复的小型读写效率低下，即使使用像S3 Express One Zone这样的新层级，它虽然降低了延迟，但引入了更高的成本和单AZ持久性的权衡。

对象存储也不太适合智能体如何修改数据。对象是不可变的blob：你无法有效地追加或部分更新一个文件，只能重写整个对象。相比之下，智能体经常追加日志、更新小块状态或逐步优化输出。结果，简单的操作变成了重复的完全重写，既低效又笨拙。

一致性和协调同样受限。对象存储通常缺乏事务语义、原子性多对象更新以及跨对象的强协调原语。即使改进了一致性模型，它们也不是为紧密耦合的读后写循环或跨相关工件的协调更新而设计的。智能体通常需要可预测的状态排序和跨多个文件的安全更新，这需要在其上添加协调层。

还存在语义上的不匹配。对象存储暴露了一个带有键值语义的扁平命名空间，即使可以通过前缀模拟层次结构。而文件系统则提供了真正的层次化组织，包含目录、相对路径和导航原语。智能体在操作文件系统的代码上训练，自然地以路径和目录的方式进行推理，这使得在对象存储中管理大量小文件变得笨拙。

最后，对象存储除了键前缀之外，缺乏原生的查询或索引能力。智能体通常需要搜索先前的工件、检索相关上下文或按元数据过滤，这通常需要添加一个单独的索引层、向量数据库或元数据存储。在这一点上，对象存储变成了大型blob和检查点的持久化后端存储，而不是智能体直接交互的系统。

为什么是文件系统？与其他选项相比，文件系统在智能体工作负载方面占据了一个实用的最佳平衡点。在接口层面，它们提供了一个简单、稳定的抽象：一个按照类似POSIX层次结构组织的自包含文件集合。这直接映射到智能体处理的数据类型。代码库、文档、数据集、配置和日志已经组织为文件和目录，关系编码在路径中，结构由布局暗示。它们天生不是表格化的或单一的blob，因此智能体可以以其原生形式操作数据，而不是将其转换为其他形式。文件系统也避免了强制过早的结构化。没有需要预先定义的模式，也没有格式演变时的迁移过程。文件可以是文本、JSON、代码或任何其他形式，并且可以随着时间的推移无摩擦地改变形状。结构在有用的地方出现，而不是被全局强加。

文件系统也自然地适合智能体访问和修改数据的方式。许多智能体工作负载本质上是有序的，其中操作的顺序很重要，工件最好被理解为随时间推移的进展。智能体通过追加日志、编辑函数和调整提示来重复就地修改小文件，从而创建一个具有强局部性的紧密工作集。这些工作负载更像有序流而不是无序的行集合，文件系统通过低延迟访问、缓存和高效的就地更新来自然地处理它们。

一致性同样务实。在本地文件系统上，操作通常是即时且可预测的，简化了智能体的推理。分布式或网络化变体可能会削弱这些保证，并在可见性和排序方面引入边缘情况，但该模型仍然比需要跨许多独立记录协调事务的系统更容易使用。

结果是一个最小、可组合且已经非常适合智能体和开发人员工作方式的抽象。你可以在其下分层索引、检索、版本控制或持久性，同步到对象存储，附加向量索引，或在其他地方维护元数据。但核心接口保持稳定：智能体读取和写入文件，其他一切都是实现细节。

文件系统的现状

那么，如果文件系统是正确的抽象，现有的实现是否满足智能体开发者的需求？今天，答案是有条件的肯定，但这可能很快改变。

今天构建智能体的大多数开发者依赖于本地或单节点文件系统，通常通过标准的POSIX接口访问。工作负载是适度的：中小型文件、有限的并发性以及延迟比吞吐量更重要的紧密反馈循环。在这些条件下，一台配备SSD存储的机器就足够了。许多智能体框架隐式地假设了这种模型。它们直接读写文件，在本地缓存中间输出，并将文件系统视为一个简单的持久化层；它们不需要跨多台机器进行协调。

最近，开发者开始抽象文件系统本身。智能体不再直接与磁盘交互，而是可以操作虚拟化文件系统，包括用于工具执行和安全的沙盒化或限定范围的文件系统，或隔离执行环境的容器化文件系统。这些抽象保留了熟悉的文件接口，同时将存储与特定磁盘解耦，从而更容易重置状态、强制执行边界和管理执行。

当开发者超越单台机器的限制时，他们通常会转向试图保留相同编程模型的分布式文件系统。像NFS、HDFS、Lustre、BeeGFS和CephFS这样的系统都暴露了一个可以跨多台机器挂载的共享命名空间，允许不同的进程并发地读写相同的文件，协调通常在应用程序层处理。

尽管这些系统经常被归为一类，但它们在设计上差异很大。NFS本质上是一种允许客户端访问远程服务器上文件的网络协议，因其简单性和兼容性而仍被广泛使用。HDFS是为大规模数据处理而构建的，并针对高吞吐量、顺序访问进行了优化。Lustre和BeeGFS优先考虑并行I/O和聚合带宽，使其非常适合HPC和训练工作负载。CephFS反映了更现代的架构，分布数据和元数据以提高可扩展性和容错性。

这些系统工作良好，因为它们与它们为之构建的工作负载紧密对齐：大文件、相对稳定的数据集以及读取密集型或追加密集型的访问模式。在这种模式下，性能是可预测的，抽象基本成立。

当工作负载转向大量小文件、频繁更新以及越来越多的独立进程通过共享状态交互时，问题就出现了，这给元数据系统带来了压力。除了提供数据服务，文件系统还隐式地协调进程间的行为。虽然分布式文件系统可以在一定程度上适应这种转变，但它们并非以此为主要需求而设计的。

并发性和隔离保证

当你有成百上千个智能体同时操作，读取和修改共享状态，并将其写回时，问题就变了。文件系统必须可靠地存储数据，并调解独立进程之间的交互。要做到这一点，强大的协调和一致性保证是不可或缺的。当两个智能体试图修改同一个文件时会发生什么？跨多个文件的操作中途失败意味着什么？

大多数文件系统确实以某种形式支持并发访问。多个进程可以同时读写文件。分布式系统将该模型扩展到多台机器。但保证比看起来要弱，因为协调通常被推送到应用程序层，依赖于建议性锁、单写入者模式或隐式解决（如最后写入者胜出）。虽然这些方法在冲突罕见或访问模式结构良好时有效，但在争用情况下会变得脆弱。

事实是，传统的分布式文件系统并非为高度并发、细粒度的共享状态修改而设计。它们针对吞吐量和可用性进行了优化，一致性保证因系统而异。它们通常不提供跨多个文件的事务语义或跨相关状态片段的协调更新。它们提供的保证在冲突罕见时通常足够，但当许多独立进程积极修改共享状态时，就会变得有限。

这方面有一些有趣的工作正在进行。Turso基于SQLite，正在探索专门为智能体状态管理设计的文件系统架构。在AgentFS中，整个智能体运行时（文件、状态、工具调用和执行历史）都存在于一个单一的SQLite数据库中，该数据库可以作为一个单一工件被复制、分叉、快照或跨机器移动。SQLite提供了事务保证、通过内核页面缓存实现的快速本地访问以及可查询性，所有这些都在一个可移植的文件内。该设计还强制执行写时复制隔离，允许多个智能体在沙盒环境中操作而不影响彼此的状态，尽管真正的并发多智能体写入仍然是一个活跃的开发领域。

物化和查询能力

今天，一个智能体可能检索一个文件并进行一次更新。很快，智能体将需要从多个文件中提取数据，物化中间结果，并对这些结果运行操作。不久之后，它们将做一些更接近我们曾经依赖Spark等系统所做的事情（即跨文档连接数据、聚合数据并计算新输出）。

正在改变的是，检索不再是一个一次性的步骤。RAG假设一个单次传递，其中智能体检索上下文，将其传递给模型，然后继续。但对于智能体检索，过程是不同的。智能体必须跨文件组合信息，动态地组装上下文，并在每一步持续重建其所需的工作集。

在这一点上，这看起来不再像检索，而开始像一个查询问题。

智能体正在选择、过滤、转换和组合非结构化数据。它实际上是在语料库上运行查询，只是没有任何类似真正查询引擎的东西。因此，差距变得明显。

我们有用于结构化数据的强大系统，以及用于JSON和Parquet等半结构化格式的相当不错的系统。但智能体处理的是高度非结构化的内容：代码、文档和自然语言。不幸的是，用于大规模查询和操作这些内容的基础设施仍然不成熟。文件系统暴露了数据，但它们不提供在此级别处理数据所需的操作。

有一些团队开始探索这个领域，有些正在取得真正的进展。Archil正在为AI工作负载重新思考文件系统层。他们的系统位于对象存储之前，为智能体提供跨环境的快速、一致的数据访问，同时明确针对智能体工作负载的延迟特性进行优化。Vortex正在数据层解决这个问题。它是一种列式文件格式，专为极快读取而设计，包括随机访问、选择性读取和大批量扫描，并与现代查询引擎紧密集成。该格式特别适合读取密集型的智能体分析工作负载，在这些工作负载中，智能体跨许多步骤重复扫描、过滤和聚合大量数据集合。

访问控制

随着这些工作负载变得越来越复杂，访问控制成为执行模型的一部分。文件系统确实支持ACL，但它们通常在文件、目录、用户和组级别定义。权限是静态的，在访问时评估，并且不扩展到数据被读取后如何使用。

这种模型在智能体工作负载下会崩溃。智能体不仅仅读取一次文件。它们从许多文件中读取，组合信息，并构建跨步骤持续存在的中间结果。访问决策不仅需要在文件打开时强制执行，还需要在多步骤工作流的整个执行过程中强制执行。例如，一个智能体可能被允许独立读取两个文档，但不允许组合它们或将特定字段传播到下游输出中。

这需要更细粒度和动态的控制。策略需要在字段、片段和派生数据的级别上操作，而不仅仅是文件，并且它们需要在智能体构建状态时持续评估。这包括控制哪些数据可以被缓存，哪些中间结果可以被物化，以及哪些可以被传递到后续步骤。

这开始看起来像查询时的策略执行。权限在选择、过滤和转换期间应用，并且当数据在系统中移动时，它们需要正确组合。

文件本身的规模

今天的智能体工作负载仍然受限。它们操作于小文件、适度的上下文窗口、有限的工作内存和有边界的输出。这自然限制了它们接触的数据大小。随着模型的改进和上下文窗口的扩展，智能体将开始处理更大的工件。一个编码智能体不会逐个文件地操作，它需要理解和修改整个代码库。一个法律智能体不会审查单个合同，它需要综合数百份文档。

显然，这些不是一次性操作。智能体将重新访问相同的数据，构建中间结果，并跨步骤迭代。在这一点上，瓶颈将转移。文件系统将不再仅仅负责存储数据。它需要支持对大型文件和大型文件集合的高效访问。智能体将需要选择性扫描、缓存中间状态，并在数据之间移动，而无需重复将其加载到内存中。

随着这些工作负载的扩展，问题变成了访问和计算的问题，而不仅仅是存储。

面向智能体时代的文件系统

我现在相信文件系统是智能体的正确抽象。它们符合智能体的训练方式、思考数据的方式以及实际运作的方式。但我们今天拥有的系统并非为智能体正在成为的样子而设计。

随着智能体的扩展，工作负载也在变化。许多智能体在共享状态上并发操作。它们不仅仅读取文件，它们通过文件进行协调。它们不仅仅检索数据，它们构建工作集、物化中间结果并跨步骤迭代。

这种转变引入了新的需求。并发性需要更强的保证。检索变成了对非结构化数据的查询问题。访问控制从静态ACL转向动态的、执行感知的策略。文件系统需要支持对更大工件的高效操作。

我们开始看到早期的答案，但技术栈的形态仍在变化之中。我们现在关于智能体如何与数据交互所做的选择将很快固化，因此值得做出正确的选择。

作者 Sarah Catanzaro
编辑 Justin Gage
致谢 感谢Will Manning对早期草稿的编辑。