当业界围绕 Agent 记忆存储展开激烈讨论时，一股来自实践者的声音正在挑战主流范式：与其在文件系统之上修修补补，不如直接承认一个基本事实 —— 文件系统本身就是一种粗制滥造的数据库。这一观点并非激进的技术偏见，而是对 Agent 存储真实需求的系统性反思。多代理协作、跨会话持久化、企业级治理 —— 这些场景正在迫使我们重新审视存储抽象的选择。

文件系统抽象的结构性困境

传统文件系统诞生于单机、单用户的桌面时代，其设计假设与当今 Agent 系统的运行需求存在根本性错配。首先是并发控制的缺失：文件系统对文件的读写依赖操作系统层级的锁机制，这种粗粒度的冲突处理在单 Agent 场景尚可勉强支撑，但当多个 Agent 并行访问同一记忆空间时，文件锁的竞争会迅速成为性能瓶颈，甚至导致状态损坏。其次是元数据管理的薄弱 —— 文件系统仅提供有限的元数据能力，时间戳和权限之外的语义信息必须自行维护，这对需要精细化记忆索引的 Agent 系统而言是致命缺陷。再者是检索能力的根本不足，尽管 grep 和 ls 等命令行工具在简单场景下表现出人意料的性能，但面对百万级记忆片段的语义检索需求，文件系统的线性扫描模式便显得力不从心。

更深层的问题在于数据完整性和事务语义。Agent 的记忆操作往往包含多个原子性步骤 —— 写入记忆片段、更新索引、记录时间戳、关联上下文。文件系统对这些复合操作毫无概念，任何一步的失败都可能导致状态不一致。相比之下，数据库的事务机制天然支持这种原子性保证。更糟糕的是，文件系统对多模态数据的处理能力极为有限，当 Agent 需要存储结构化知识、向量嵌入、图像描述乃至音频记录时，平面文件的组织方式很快变得无法维护。

「最糟糕的数据库」：重新定义问题域

OpenCode 的 Dax 一针见血地指出「文件系统就是最糟糕的数据库」。这一定义的本质在于揭示一个被忽视的真相：当我们为 Agent 构建记忆系统时，我们实际上是在重新发明数据库的核心功能 —— 索引、事务、并发控制、查询优化。区别在于，我们在文件系统的脆弱基础上用应用层代码重新实现这些机制，最终得到的是一个性能更差、可靠性更低、维护成本更高的替代品。

这一认知转变带来的启示是根本性的。如果存储需求本质上就是数据库需求，那么直接选用成熟的数据库架构难道不是更理性的选择吗？swyx 和来自数据库领域的从业者进一步补充了这一定位的含义：避免重复造轮子意味着不要在应用层重新实现搜索索引（现有解决方案已经过数十年的优化）、不要自行编写事务日志（数据库内置的 WAL 机制更为可靠）、不要自己实现锁机制（数据库的并发控制经过严格验证）。每一个「创新」的存储层实现，都是对成熟技术的背离。

数据库优先设计的工程优势

将数据库置于 Agent 存储架构的核心位置，能够带来多维度的工程收益。在并发处理层面，数据库的细粒度锁机制和 MVCC 支持允许多个 Agent 安全地同时读写记忆，而无需担心状态损坏或丢失更新。这种能力对于多 Agent 协作场景至关重要 —— 当多个 Agent 需要共享上下文、协同推理时，只有数据库能提供可靠的状态隔离与一致性保证。在查询能力方面，结构化存储使得复杂的条件检索、聚合分析、时间范围查询成为原生能力，而非需要额外拼接的半成品功能。结合向量索引，Agent 既能进行精确的结构化查询，又能实现语义近似搜索，两种能力在同一存储层内无缝协作。

数据治理是企业级 Agent 系统的核心关切，而数据库在权限控制、审计追踪、加密保护等方面提供了文件系统无法比拟的原生支持。行级权限控制、列级敏感数据掩码、操作审计日志 —— 这些能力对于需要满足合规要求的 Agent 应用而言是基础设施级别的保障，而非事后追加的安全加固。Schema 约束则进一步确保了记忆数据的一致性，避免因数据格式错误导致的 Agent 行为异常。

面向生产的存储参数与实现清单

转向数据库优先的 Agent 存储设计并不意味着简单替换存储后端，而是需要系统性地重新思考数据模型与访问模式。在数据模型层面，建议将记忆分解为结构化的事实表（记忆片段、创建时间、来源 Agent、置信度）与向量索引表（记忆 ID、嵌入向量、元数据）的组合，支持精确查询与语义检索的混合模式。典型实现中，事实表使用 PostgreSQL 的 JSONB 列存储灵活的属性数据，向量索引借助 pgvector 扩展实现语义相似度搜索。

在并发控制方面，多 Agent 场景下推荐采用乐观锁策略配合重试机制。具体的锁等待超时建议设置为 5 至 15 秒，取决于 Agent 任务的延迟敏感程度；重试次数一般设置 3 至 5 次，指数退避间隔从 100 毫秒开始。对于需要强一致性的场景（如记忆写入后的即时读取），显式事务包裹是必要的，事务超时建议控制在 30 秒以内。

持久化策略上，记忆数据的写入模式应采用 Write-Ahead Logging 兼容的数据库机制。关键记忆的写入确认级别建议设置为「同步提交」（synchronous_commit = on），以确保崩溃恢复后的数据完整性；对于非关键的中间推理结果，可适度降低持久化要求以换取延迟优化，异步写入配合定期检查点即可满足需求。备份策略建议采用增量备份结合 Point-in-Time Recovery 能力，目标恢复时间窗口（RTO）应小于 15 分钟，恢复点目标（RPO）不超过 1 分钟。

监控指标应覆盖查询延迟（P95 延迟目标建议低于 50 毫秒）、并发冲突率（锁等待超过 1 秒的事件占比应控制在 1% 以下）、向量索引召回率（定期抽检语义检索结果的相关性，维持 95% 以上召回）。当冲突率超标时，应考虑进一步拆分记忆表或引入分片策略；当查询延迟上升时，需评估是否需要为高频查询列添加专用索引。

范式转移的深层启示

数据库优先的 Agent 存储设计并非对文件系统的全面否定。文件系统在本地临时工作区、产物输出、调试日志等场景仍有不可替代的价值 —— 其简单性和模型已有的操作能力使其成为理想的短期缓存层。真正的范式转移在于明确分层边界：将文件系统视为 Agent 的「工作台」和「输出设备」，而将数据库视为「记忆库」和「知识引擎」。这种分层既保留了文件系统接口的灵活性，又获得了数据库架构的可靠性。

当 Agent 系统从实验走向生产时，这一分层将变得不可避免。多 Agent 的并发需求、跨会话的持久化需求、企业级的治理需求 —— 这些力量共同推动着存储设计向数据库优先的方向演进。尽早接受这一现实，意味着在系统规模扩张时减少重构成本，在合规审计时少走弯路，在多 Agent 协作时避免状态同步的梦魇。文件系统抽象的优雅谎言终将被生产环境的严酷现实戳破，而数据库优先的设计则为 Agent 系统的持久演化提供了稳固的地基。

参考资料

  • Leonie Monigatti, "Agent Memory: Filesystem vs Database"（文件系统与数据库在 Agent 记忆场景的对比分析）
  • Dax (OpenCode), "Filesystem is just the worst kind of database"（关于文件系统局限性的核心论点）