文件系统是AI代理的新原语

2000 年，我在华盛顿特区的一家开发工作室开始编写 Web 软件，那时一切都建立在关系数据库和精心设计的模式之上。这就是工作的全部。客户提出需求，我脑中立刻浮现：“好，我们需要哪些表？需要构建什么样的自定义界面？”时至今日，我每次看到 Web 应用，仍会不由自主地思考其底层数据模型。但软件正在改变。界面正在变成一个个方框，问着“我能为你做什么？”驱动这些新体验的是智能体。紧随其后，涌出了一堆框架和工具，它们希望成为智能体领域的下一个 React。 **为智能体构建记忆** 退一步看，让我们讨论一下一个好的智能体读写记忆系统应该是什么样子。它需要做到几件事： 1. 跨会话保留事实 2. 有选择性地检索事实，因为“把一切塞进上下文窗口”很快就会失效 3. 随着时间推移自我更新和修正，这排除了许多只读方法 4. 保持人类可检查性，因为 LLM 是非确定性的，而一个黑盒记忆系统会带来调试噩梦 如果我们为智能体设计记忆系统，很自然会想到 SQL、ORM 或 API 这些你已经熟知的东西。我曾经大量采用这种方式构建软件。 **教会智能体新技能** 智能体可以使用 SQL 和数据 API，有时也应该使用。但这些接口是为那些已经明确知道自己要什么的程序设计的。Web 应用调用 `GET /tasks/123` 或运行参数化查询，是因为开发人员已经将用户意图转化为精确的操作。而智能体则处于流程中更早的一层。它们仍在解读模糊的目标、不完整的上下文、含糊的名称、变化的假设和人类的修正。要求它们直接在标准化表或范围狭窄的端点上操作，往往是强迫它们使用为确定性软件（而非探索性推理）优化的接口。 这种错位会带来大量隐藏工作。你必须教会智能体模式、业务规则、对象之间的关系、安全的变更操作、边缘情况以及相似字段之间的区别。然后，随着系统变化，你还得让这些指令保持更新。智能体也许能够调用 API，但它会消耗宝贵的上下文和推理预算，去重建人类开发人员在设计 API 时已经拥有的心智模型。如果存在一个智能体已经接受过训练（高达数万亿个 token）的 API 呢？ **LLM 已经知道如何使用文件系统** 我是说，真的知道如何使用。`ls`、`cat`、`grep`、`cd`、`mkdir`。每个工程师都能立刻认出这些命令，因为这是我们学习操作计算机的方式。而且每个 LLM 都在超过 50 年的 Unix/Linux 手册页、GitHub 仓库以及数百万份解释这些命令是什么、如何运作以及如何组合使用的文档上训练过。想想就让人惊叹：基础 LLM 的训练数据中有数万亿个 token 与文件系统相关。 文件系统几乎满足了智能体长期记忆的所有条件。一旦你看到这一点，你就会开始到处看到文件的身影。 文件系统并非完整的记忆架构，我也不打算假装它是。但它对于智能体最挣扎的那部分记忆——持久的、可检查的、可修正的工作上下文——来说，是一个异常优秀的基座。文件系统提供了模型已经知道如何推理的名称、路径、层次结构、时间戳、权限、差异和约定。一旦你注意到这一点，你就会开始到处看到文件的身影。`CLAUDE.md` 就是一个 Markdown 文件。智能体技能通常是一个包含 `SKILL.md` 和一些支持文件的目录。编程智能体通过读取、编辑、搜索和测试仓库来工作。智能体平台不断暴露类似文件的工作区、挂载存储和文档集合，作为模型执行工作的地方。这并非巧合。 我构建了一个小样本来说服自己：一个基于 Box 中两个 Markdown 文件的团队管理智能体。一个文件按团队成员组织： # 团队 ## 梅 - [ ] 草拟入职清单 - [x] 审阅 Q3 指标 ## 路易斯 - [ ] 更新客户推出计划 另一个文件按任务状态组织： # 任务 ## 待办 - 草拟入职清单 — 梅 - 更新客户推出计划 — 路易斯 ## 已完成 - 审阅 Q3 指标 — 梅 相同的数据，在两个文件中进行了反规范化。一位人类在 UI 中将某个任务标记为完成。智能体注意到团队成员文件的时间戳更新，将其与状态文件对比，同步了两个文件中的任务，并留下审计记录，说明人类修改了什么以及智能体修改了什么。没有定制的任务 API，没有自定义查询语言，没有复杂的工具契约，只有文件系统语义：读取文件、比较时间戳、更新过时副本、写入日志。这几乎过于简单，而这正是它有趣的原因。 **人类参与其中** 目前许多智能体工程工作都在教导模型理解我们的抽象。比如：这是端点。这是模式。这是允许的状态转换。这是 assignee\_id、owner\_id 和 user\_id 的区别。这是重试行为、分页模型，以及当对象被归档时这个 API 的奇怪行为。有时这些复杂性是必要的。但往往是偶然的。 我反复思考的问题是：我们能否让更多系统通过智能体已经理解的接口暴露给智能体？这并不意味着抛弃数据库——那会很愚蠢。数据库、API 和向量搜索都有自己的价值。当你需要高吞吐量事务、复杂连接、严格一致性、任意分析查询或精心维护的不变性时，文件系统是一个糟糕的答案。Markdown 文件不是数据库，假装它是只会让你最终得到一个带额外步骤的非常昂贵的共享文档。 但智能体通常并不直接需要数据库。它们需要的是一个工作集：计划、笔记、任务列表、策略、草稿、摘要、日志、修正、决策等。对于这一层，一个形状类似文件系统的接口往往对模型和监管它的人类都更易读。这种共享的可读性才是真正重要的部分。如果一个智能体将一行数据写入数据库，人类通常需要产品界面、管理工具、SQL 查询或日志管道才能弄清楚发生了什么。但如果一个智能体编辑了一个 Markdown 文件，人类可以直接打开它、阅读差异、评论、回退或直接修复。这改变了调试循环。你可以检查智能体的记忆，发现过时的假设，删除错误的状态，对变更进行版本控制，在拉取请求中审阅它们，并使用已有的系统附加权限、保留策略、审计日志和合规管理。 云文件系统让这一切变得更加有趣。一个共享驱动器不仅仅是存储；它也是协作、访问控制、版本历史、搜索、预览、评论、法律保留、保留和可审计性——正是那些演示中经常被忽略、直到成为生产问题时才重视的枯燥企业需求。 **利用模型的先验知识** 每当你发现自己在花费推理时间教智能体一个自定义抽象时，停下来问问：是否已经存在一个模型深刻理解的范式？答案不总是“文件系统”。有时是电子邮件、电子表格、Git、日历或问题追踪器。更广泛的观点是，模型并非白板，它们带着从我们已经构建的数字世界中学到的操作先验知识而来，良好的智能体设计应该利用这些知识。 五十年前，Ken Thompson 和 Dennis Ritchie 在设计 Unix 时做出了一个强有力的赌注：当设备、流、程序和状态共享一个类似文件的接口时，它们更容易组合。这个想法扩展得惊人地远。它塑造了我们今天使用的系统，包括你读这篇文章的设备以及我们用来构建它的工具。