智能体记忆架构：文件接口与数据库存储解耦

观察顶级工程团队如何构建智能体记忆系统，你会发现一个清晰的模式：智能体看到的是文件系统接口，而实际持久化存储的是数据库。这场争论从来不是“文件系统还是数据库”，而始终是两者在合适的层级协同工作。

文件系统作为智能体接口并非新概念。Dust.tt 在 2025 年中就将公司数据投影到合成文件系统。Letta 的记忆基准测试显示文件系统工具优于其他方案。LangChain 的上下文工程研究为此奠定了基础。

2026 年 1 月，讨论热度骤升。Vercel 发布了评估报告。Harrison Chase 分享了LangSmith Agent Builder 如何实现记忆。Jerry Liu 宣称“文件即一切所需”，相关文章登上 Hacker News。Anthropic 的 Skills 功能——将智能体能力打包为 Markdown 文件文件夹——也悄然强化了这一模式。

“争论从来不是‘文件系统还是数据库’，而始终是两者在合适的层级协同工作。”

为何重新受到关注？Cursor、Claude Code、Windsurf 等编码智能体证明，文件系统接口效果显著——至少在代码领域如此。问题在于这种成功能否推广。

吸引力显而易见。一个能干的智能体可能需要与 REST API、SQL 数据库、向量存储、云控制台、文件系统、网页浏览器和人类用户交互——每种都有不同的协议和惯例。要处理的接口太多了。

但看看这些团队实际如何构建系统，你会发现另一幅图景：他们底层使用数据库，并且非常坦率地解释了原因。

文件系统接口与文件系统存储有何区别？

Harrison Chase 在 X 上坦承了 LangSmith Agent Builder 的架构：智能体看到文件系统接口，但实际存储是数据库。他在技术深度解析中解释：

“大语言模型擅长处理文件系统，但从基础设施角度看，使用数据库更简单高效。”

这并不矛盾，而是深思熟虑的架构选择：

• 接口 = 智能体看到并交互的内容
• 存储 = 数据实际持久化的位置

争论不是“文件系统还是数据库”，而是认识到接口和存储是独立决策。

一旦理解这一区别，问题就从“文件系统还是数据库？”转变为“针对何种智能体类型选择何种接口，基于何种需求选择何种存储？”

文件系统接口为 AI 智能体提供了什么？

在MCP和文件系统抽象出现前，连接智能体与外部数据意味着为每个数据源定义自定义工具模式。每个端点都需要文档，每个模式都需要示例。Arize 的 Tony Powell指出：“等大语言模型学会使用特定 API，你已经消耗了大量上下文窗口……花了几千个 token 在教育上，而不是推理上。”

文件系统接口提供了不同思路：一小套通用操作，大语言模型已从训练数据中理解。这是 1970 年代 Unix“万物皆文件”哲学在新规模下的重现。正如 Unix 将多样设备接口压缩为文件操作，DevOps 将基础设施压缩为代码制品，智能体 AI 正将多样数据源压缩为文件系统操作。

核心操作：

• 列出 — 显示位置内容（如 ls）
• 读取 — 获取文件内容（如 cat）
• 写入 — 创建或更新文件
• 搜索 — 按名称或内容查找文件（如 find 和 grep）

实际好处是 token 效率：教育已在预训练阶段完成。Turso 的 Pekka Enberg 在AgentFS 文章中指出：“给智能体 grep、sed、awk、cat 和 git 访问权限，它会变得异常能干高效，无需自定义工具。”

Dust.tt 通过创建“合成文件系统”扩展了这一思路——将 API 和数据库投影为类文件系统层级。Slack 频道变为目录，Notion 工作区变为文件夹。底层数据存在于 API 和数据库中，但智能体看到的是连贯的文件树。

智能体到数据接口如何从自定义工具演进为标准文件系统操作。

文件系统接口在哪些场景对 AI 智能体效果好？

文件系统模式在编码智能体中已证明明确价值。

这并不意外。代码本就以目录中的文件形式组织。开发者以文件系统术语思考。操作自然映射：读取文件、编辑文件、搜索代码库。Cursor、Claude Code、Windsurf 等工具都采用此模式。

Letta 团队在基准分析中提供了重要背景：“当今智能体使用文件系统工具极为有效，主要归功于针对智能体编码任务的后训练优化。”关键短语是“智能体编码任务”——这正是训练数据存在的领域。

文件系统接口适用场景：

• 编码智能体（代码已在文件中）
• 文档处理（文档映射为文件）
• DevOps 和基础设施（配置即文件）
• 知识库导航（层级结构有效）

文件系统接口在哪些场景对 AI 智能体失效？

文件系统模式并非万能。多个场景暴露其局限性，实践者尝试后也坦承失败。

结构化数据查询

你无法用 grep 处理“查找 Q3 订购了产品 X 但未订购产品 Y 的所有客户”。涉及连接、聚合或图遍历的查询，文件系统操作显得笨拙。

Vercel 的基准测试清晰说明了这一点。当他们测试文件系统操作与数据库查询处理结构化数据时：

结论：对于具有清晰模式的结构化数据，专用查询语言——无论是 SQL、MongoDB 查询 API 还是其他数据库接口——始终优于文件系统操作。

大规模性能

文件系统抽象隐藏了一个关键问题：每个文件操作都可能变成 API 调用。Hacker News 上一位实践者描述完全放弃此方法：“如果通过 fuse 使用 grep，最终会打开大量文件，导致向某些 API 发起获取请求，速度会很慢……我们甚至用 Rust 实现此想法进行测试，最终放弃，因为效果不佳。”

LlamaIndex 的 Jerry Liu 在“文件即一切所需”中提出类似观察：“编码智能体已使用 CLI 工具作为文件搜索主要手段，但我们注意到此方法无法扩展到海量文档集合（1k-1m+）。”

问题本质在于：文件系统缺乏使数据库查询快速的索引机制。

无服务器和云原生环境

文件系统隐喻假设存在文件系统，但许多生产环境——如无服务器函数、基于浏览器的智能体和边缘计算——没有持久本地存储。

非编码智能体类型

客户服务智能体需要结构化客户数据。分析智能体需要数据库查询。使文件系统接口对编码智能体强大的训练数据优势，可能无法转移到这些领域。

为何领先团队使用数据库存储智能体记忆？

无论选择何种接口模式，领先团队底层都收敛于数据库存储：

原因一致：

• 多智能体协调需要事务。多个智能体共享状态时，需要 ACID 保证。
• 扩展要求索引。Grep 适用于小集合；生产系统需要数据库级查询优化。
• 治理需要审计追踪。企业部署需要可追溯性：谁在何时访问了什么，原因何在。
• 混合检索是基本要求。生产系统需要向量搜索、全文搜索和结构化查询协同工作。

集成向量搜索的文档数据库特别适合此处。结合灵活文档存储、向量嵌入和全文搜索的平台，无需拼接多个系统。

开发者如何选择智能体记忆的接口和存储？

文件系统接口并非唯一选项。对某些智能体类型，它也不是最佳选择。

像 MongoDB Atlas 这样的文档数据库将数据存储为 JSON 文档，结构上已“类文件”。具备原生向量搜索、全文搜索和聚合管道，智能体可通过MCP 工具或 API 直接查询——无需文件系统转换层。对于分析智能体、客户服务智能体或任何涉及结构化数据查询的工作流，这种直接路径可能优于文件系统接口。

文件系统接口在智能体训练数据使 ls 和 grep 比自定义工具更可靠时表现突出，主要是编码智能体。但这种训练数据优势并非适用于所有领域。

[DIAGRAM 3: 解耦架构]

新兴架构解耦了接口和存储选择，允许团队独立优化每层。

真正要问的问题：

• 何种智能体类型？ 编码、文档、分析、客户服务？
• 何种接口适合该类型？ 编码智能体用文件系统，结构化数据用 MCP/直接查询。
• 何种存储需求？ 扩展性、多智能体协调、治理、检索模式？
• 需要转换层吗？ 还是智能体可直接查询数据库？

架构正在收敛，这对开发者意味着什么

“文件系统 vs. 数据库”的框架掩盖的比揭示的更多。构建生产智能体系统的团队已超越这场争论。他们将接口与存储分离，无论向智能体暴露何种接口，底层都使用数据库。

“结构化数据、非编码工作流和无服务器环境需要不同方法。”

文件系统接口对编码智能体和文档导航效果良好，那里存在训练数据且隐喻合适。但它并非普适。结构化数据、非编码工作流和无服务器环境需要不同方法。

问题从来不是“文件系统还是数据库？”而是始终两者兼有——在合适的层级。

TRENDING STORIES

Group Created with Sketch.