编者按： 当大语言模型的上下文窗口不断扩张，AI 智能体是否必须依赖成百上千的专用工具、复杂的云端编排与封闭的插件生态，才能真正具备"长期记忆"与"跨平台协作"的能力？
本文首先剖析了"上下文窗口不等于记忆"的架构痛点，指出传统白板式的上下文管理机制极易丢失关键信息，而文件系统通过 CLAUDE.md、技能描述文件等持久化载体，为智能体提供了可读写、可迁移的长期上下文。其次，作者深入论证了"文件格式即 API"的开放协作范式，强调通用文本格式（如 Markdown）足以绕开厂商壁垒与繁琐的标准谈判，实现智能体能力的无缝组合与跨工具流转。同时，文章客观援引了苏黎世联邦理工学院的实证研究，警示低质量或过度冗余的上下文文件反而会推高推理成本、干扰智能体决策，从而点明"精简约束与标准化"才是上下文工程的关键。最后，作者提出"文件作交互接口、数据库作底层基座"的融合架构，并呼吁在 AI 代理时代回归数据自主、协议开放的个人计算本质。
作者 | Daniel Phiri
编译 | 岳扬
🌱 - 本文是一些萌芽中的想法集合。
我曾经在一家向量数据库公司工作。我的全部工作就是帮助人们理解为什么他们需要专为 AI 打造的数据库 ------ 嵌入向量、语义搜索，等等。所以此刻写下这些文字，多少有些荒诞。但眼见 AI 生态系统里的所有人突然重新发现了朴实无华的文件系统，我觉得他们可能察觉到了比大多数人了解的更重要的东西。
文件系统不是比数据库更伟大，而是与数据库截然不同的存在。我必须事先声明，因为定会有人读到此处，以为我要鼓吹"文件优而数据库劣"。绝非如此。请继续看下去。
01 人人都在谈论文件系统
如果你在过去几个月里稍微关注过 AI 智能体领域，你一定注意到了一些奇怪的现象。LlamaIndex[1] 发表了《Files Are All You Need》。LangChain[2] 撰文讨论智能体如何利用文件系统进行上下文工程。Oracle[3]，没错就是 Oracle（他们最近很活跃），发布了一篇文章比较文件系统与数据库作为智能体记忆的优劣。Dan Abramov[4] 写了一个基于 AT Protocol 构建的社交文件系统。Archil[5] 正在构建云存储服务（cloud volumes），原因无他 ------ 智能体需要 POSIX 文件系统。
来自 LlamaIndex 的 Jerry Liu 说得很直白：我们正从一个"智能体需掌握数百种工具"的模式，转向一个"智能体可以访问文件系统以及大概 5-10 种工具"的世界，仅此而已。 文件系统、代码解释器、网络访问权限，这样的配置即便不比拥有百余种 MCP 工具的智能体更通用，至少也不相上下。
Karpathy[6] 提出了一个相关的观察，令我印象深刻。他指出，Claude Code 之所以有效，是因为它运行在你的电脑上，使用你的操作环境、你的数据、你的上下文。它不是一个需要你访问的网站，而是居住在你机器上的一个小精灵。他认为，OpenAI 搞错了方向，专注于把智能体放在 ChatGPT 编排的容器中云部署，而不是简单地运行在 localhost 上。
而让这一切具备商业价值的关键在于：当前 AI 实际应用场景中，编程类智能体占据主导地位。Anthropic 据传即将实现盈利，其中巨大贡献来自 Claude Code 这个命令行工具。不是聊天机器人，而是能读写文件系统中数据的工具。
02 上下文窗口不等于记忆
我认为多数讨论都忽略了更深层的问题。
记忆，在人类心理学意义上，是我们运作的基石。我们不会在每次做决定时都重读一遍自己的人生经历。我们拥有长期存储、选择性回忆的能力，可以遗忘无关紧要的事，也能调取关键的信息。而大语言模型的上下文窗口完全不是这么回事。它更像一块不断被人擦掉重写的白板。
如果你曾用 Claude Code 做过正经项目，你一定体会过那种盯着"距离自动压缩还剩余的上下文数量"的提示越来越近时的恐惧。整个对话、智能体对你的代码库积累的所有理解、你的偏好、你曾做过的决定，都将被压缩或丢失。
文件系统用一种最朴素、最直接的方式解决了这个问题：把东西写下来，放进文件里，需要的时候再读回来。Claude 的 CLAUDE.md 文件为智能体提供了关于你项目的持久化上下文。Cursor** 将过往的聊天记录存储为可搜索的文件。大家开始编写 aboutme.md 文件，来充当可移植的身份描述 ------ 你的偏好、你的技能、你的工作风格，全都放在一个文件里，这个文件可以在不同应用间流转，无需任何人去对接 API。
然而！事情可能没那么简单。
苏黎世联邦理工学院（ETH Zürich）最近的一篇论文[7]评估了这类仓库级上下文文件是否真的能帮助编程智能体完成任务。研究结果与直觉相悖：在测试的多种智能体和模型上，上下文文件往往降低了任务的成功率，同时使推理成本增加了 20% 以上。 拿到上下文文件的智能体会进行更广泛的探索，运行更多测试，遍历更多文件 ------ 但这种"严谨细致"反而耽误了它们去找到真正需要修复的代码。这些文件像一份待办清单，而智能体把它过于认真对待了。
这听起来像是在推翻我们前面的所有假设。但我认为它恰恰让这个观点更加犀利。论文的结论不是"不要使用上下文文件"，而是说：不必要的需求会让任务变得更难，上下文文件只应描述最核心的必要条件。 问题不在于作为持久化层的文件系统，而在于人们把 CLAUDE.md 写成了一份长达 2000 字的入职文档，而不是一套精简的约束说明。这就引出了关于标准的问题。
03 文件格式即是 API（但究竟是哪个文件？）
眼下我们有 CLAUDE.md、AGENTS.md、copilot-instructions.md、.cursorrules，等你读到本文时，大概又多了五个。所有人都认同智能体需要基于文件系统的持久化上下文，但没人能对文件该叫什么、里面该放什么达成一致。我注意到有人在尝试统一，这是好事。
Dan Abramov 那篇关于社交文件系统[8]的文章，把某个重要的点讲透了。他描述了 AT Protocol 如何将用户数据视为个人仓库中的文件 ------ 结构化的、归用户所有、任何能读懂该格式的应用都可读取。关键的设计选择在于，不同的应用不需要就什么是"帖子"达成共识。 它们只需要对各自的格式进行命名空间隔离（使用域名，就像 Java packages 那样），避免冲突即可。应用会对文件的变化做出响应。应用数据库里的内容不是"源头"，而是从用户文件夹里"算出来"的衍生数据 ------ 也就是所有用户文件夹的一份完成缓存的物化视图**。
同样的问题也存在于智能体上下文文件领域。我们不需要把 CLAUDE.md、AGENTS.md、copilot-instructions.md 合并成一个文件。我们需要的是它们互不冲突地共存。 平心而论，统一的工作已经在进行了。Anthropic 发布了 Agent Skills[9] 这个开放标准，即 SKILL.md 格式，微软、OpenAI、Atlassian、GitHub 和 Cursor 都已采用。你为 Claude Code 编写的一个技能，可以在 Codex 里用，也可以在 Copilot 里用。文件格式就是 API。
NanoClaw[10] 是一个轻量级的个人 AI 助手框架，它把这一理念推向了合乎逻辑的终点。它没有去构建一个不断膨胀的功能集，而是采用了"技能优先于功能"的模式。想要支持 Telegram？没有 Telegram 模块。只有一个 /add-telegram 技能，本质上是一个 markdown 文件，教 Claude Code 如何重写你的安装程序以添加该集成。技能就是文件。它们可移植、可审计、可组合。不需要 MCP 服务器，不需要去浏览插件市场。只需要一个包含 SKILL.md 的文件夹。
不用开会、不用签约，光靠文件格式就能让不同应用互相协作。我想把这句话的意思说得更具体些，因为它是一个比较绝对的论断。在技术领域，让两个竞争产品协同工作，通常要么需要一个花费数年才能批准的正式标准，要么需要一个强制兼容的主导平台。文件系统则绕过了这两者。如果两个应用都能读取 markdown，它们就能共享上下文。如果它们都理解 SKILL.md 格式，它们就能共享能力。没有人需要签署合作协议，也没有人需要去参加标准机构的会议。做协调工作的是文件格式本身。
04 瓶颈已经转移
基础设施领域有一个很有用的类比。传统的数据架构是围绕着"存储是瓶颈"这个假设来设计的。CPU 等待来自内存或磁盘的数据，计算本质上是对存储所提供的内容作出被动响应。但随着处理能力的提升超过了存储 I/O 的发展，范式就发生了转变[11]。业界转向了存储与计算解耦[12]，让两者各自独立扩展，于是我们有了像 S3 加临时计算集群这样的架构。瓶颈转移了，一切围绕新的约束进行了重组。
类似的事情也正在 AI 智能体身上发生。瓶颈不是模型能力或算力，而是上下文。模型已经足够聪明，只是太健忘了。 而文件系统，尽管看似简单，却是一种极其高效的方式，用于在 AI 智能体运行的确切位置管理持久化上下文 ------ 就在开发者的机器上，在他们的环境中，数据早已就位。
05 你以为自己在用文件，其实底层就是在遍历图
现在，如果我不承认这里面的问题，那我就是在自欺欺人。有人在 Twitter 上调侃[13]道："你们这些人一边用着文件系统，一边说智能体不需要图，不过只是在否认自己正在用图罢了。" 而这话......还真没毛病。文件系统就是一个树形结构。目录、子目录、文件 ------ 也就是有向无环图。当你的智能体执行 ls、grep、读取文件、顺着引用找到另一个文件时，它就是在遍历一张图。
Richmond 在甲骨文（Oracle）的那篇文章里给出了我所见过的最一针见血的区分：文件系统赢在其交互界面，数据库赢在其可以作为底层基座。一旦你需要并发访问、大规模的语义搜索、去重、或者按时效性给内容加权 ------ 你最终都会自己去建索引。说白了，那其实就是个数据库。
在 Weaviate 工作过的经历告诉我，这不是一个非此即彼的选择题。文件接口之所以强大，是因为它通用，且 LLM 天生就能理解它。数据库基座之所以强大，是因为它在事情变得复杂的时候能提供你所需的保障。未来真正有趣的方向不是文件与数据库的对抗，而是将文件作为人类和 Agent 交互的接口，底层由适合该场景的任意基座提供支撑。
06 这其实是在探讨个人计算的本质
这是我对整件事的真实看法 ------ 我觉得大家都在绕着弯子说，却没人直接点破。
文件系统有能力重新定义 AI 时代里"个人计算"的含义。
这不是那种"所有东西都在本地运行"的意思（但也许也沾点边？）。而是说：你的数据、你的上下文、你的偏好、你的技能、你的记忆 ------ 以一种你拥有的格式存在着，任何智能体都能读取，不会被锁死在某个特定的应用里。你的 aboutme.md 既适用于你今天用的某个 OpenClaw/NanoClaw 变体，也适用于将来出现的任何东西。你的技能文件是可移植的。你的项目上下文可以在不同工具之间持续留存。
这正是个人计算本该有的样子 ------ 在它们全都涌入围墙花园式的 SaaS 应用和专有数据库之前。文件就是最初的开放协议。因为 AI 智能体（Agent）正在变成我们操作电脑的主要方式，所以"文件"变得非常重要，它成了连接不同软件的桥梁，让我们拥有了对自己数据的完全控制权，我们可以无需任何人许可，就能自由切换工具、编排工作流、并在不同应用间保持连续性。
我承认这有点理想主义。开放格式的历史上，到处都是纸上获胜、实践中落败的标准。各大公司有强烈的动机让自己的上下文文件保持那么一点点差异，好让用户的切换成本居高不下。我们现在已经看到了 CLAUDE.md、AGENTS.md、.cursorrules 等多种格式并存，而不是一个通用格式 ------ 这本身就证明了分裂是常态，而不是例外。 而苏黎世联邦理工学院的那篇论文也提醒我们：即便文件格式存在，写出好的上下文文件也比听起来的要难。大多数人会写出糟糕的上下文文件，而糟糕的上下文文件显然还不如没有。
但我总会回到 Dan Abramov 写过的一句话：我们的记忆、我们的思想、我们的设计，应当比我们用来创造它们的软件活得更久。这不是一个技术层面的论断，而是一个价值观层面的论断。而文件系统，尽管古老且简单，却恰好处于独一无二的位置来实现这一点。不是因为它是最好的技术。而是因为它是唯一一项已经属于你的技术。
END
本期互动内容 🍻
❓论文提到「糟糕的上下文文件不如没有」。你写过/见过哪些「本想帮忙、实则添乱」的配置文件或系统提示词？
文中链接
1\][www.llamaindex.ai/blog/files-...](https://link.juejin.cn?target=https%3A%2F%2Fwww.llamaindex.ai%2Fblog%2Ffiles-are-all-you-need "https://www.llamaindex.ai/blog/files-are-all-you-need") \[2\][blog.langchain.com/how-agents-...](https://link.juejin.cn?target=https%3A%2F%2Fblog.langchain.com%2Fhow-agents-can-use-filesystems-for-context-engineering%2F "https://blog.langchain.com/how-agents-can-use-filesystems-for-context-engineering/") \[3\][blogs.oracle.com/developers/...](https://link.juejin.cn?target=https%3A%2F%2Fblogs.oracle.com%2Fdevelopers%2Fcomparing-file-systems-and-databases-for-effective-ai-agent-memory-management "https://blogs.oracle.com/developers/comparing-file-systems-and-databases-for-effective-ai-agent-memory-management") \[4\][overreacted.io/a-social-fi...](https://link.juejin.cn?target=https%3A%2F%2Foverreacted.io%2Fa-social-filesystem%2F "https://overreacted.io/a-social-filesystem/") \[5\][archil.com/post/why-fi...](https://link.juejin.cn?target=https%3A%2F%2Farchil.com%2Fpost%2Fwhy-file-systems-are-here-to-stay "https://archil.com/post/why-file-systems-are-here-to-stay") \[6\][karpathy.bearblog.dev/year-in-rev...](https://link.juejin.cn?target=https%3A%2F%2Fkarpathy.bearblog.dev%2Fyear-in-review-2025%2F "https://karpathy.bearblog.dev/year-in-review-2025/") \[7\][arxiv.org/abs/2602.11...](https://link.juejin.cn?target=https%3A%2F%2Farxiv.org%2Fabs%2F2602.11988 "https://arxiv.org/abs/2602.11988") \[8\][overreacted.io/a-social-fi...](https://link.juejin.cn?target=https%3A%2F%2Foverreacted.io%2Fa-social-filesystem%2F "https://overreacted.io/a-social-filesystem/") \[9\][agentskills.io/](https://link.juejin.cn?target=https%3A%2F%2Fagentskills.io%2F "https://agentskills.io/") \[10\][github.com/qwibitai/na...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fqwibitai%2Fnanoclaw "https://github.com/qwibitai/nanoclaw") \[11\][www.moonfire.com/stories/the...](https://link.juejin.cn?target=https%3A%2F%2Fwww.moonfire.com%2Fstories%2Fthe-lakehouse-era%2F "https://www.moonfire.com/stories/the-lakehouse-era/") \[12\][www.pracdata.io/p/zero-disk...](https://link.juejin.cn?target=https%3A%2F%2Fwww.pracdata.io%2Fp%2Fzero-disk-architecture-the-future%3Fhide_intro_popup%3Dtrue "https://www.pracdata.io/p/zero-disk-architecture-the-future?hide_intro_popup=true") \[13\][x.com/nayshins/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fnayshins%2Fstatus%2F2009366290692231328 "https://x.com/nayshins/status/2009366290692231328") **本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。** **原文链接：** [madalitso.me/notes/why-e...](https://link.juejin.cn?target=https%3A%2F%2Fmadalitso.me%2Fnotes%2Fwhy-everyone-is-talking-about-filesystems%2F "https://madalitso.me/notes/why-everyone-is-talking-about-filesystems/")