← 陆家贤 ← Jiaxian Lu

Agent 文件系统：从一次性沙箱到持久化工作空间 Agent File Systems: From Disposable Sandboxes to Persistent Workspaces

Chinese only

以下内容与我的工作无关，仅为个人感想与学习笔记，不代表任何公司或机构的立场。

These notes are unrelated to my work. They are personal reflections and study notes only, and do not represent the views of any company or organization.

本文是对以下内容的阅读笔记：siddontang 在 X 上的帖子《为什么我们在 TiDB Cloud 上做了一个 Agent 云盘》 These are reading notes on: a post on X by siddontang (in Chinese)

摘要

长任务 Agent 会读写文件、生成代码、运行测试、保留日志和中间状态，但执行它的沙箱往往是短命的。因此，Agent 需要的不是供人浏览的“网盘”，而是一个能跨会话、沙箱和机器延续的工作空间层。这个层需要同时提供文件语义、结构化元数据、事务一致性、检索、快照、租户隔离、权限、审计和计费。drive9 是这一思路的产品化实现，而 TiDB Cloud 是其当前宣称的底层支撑之一。

核心判断

Agent 缺的不是一个网盘，而是一个能干活、能恢复、能审计，还能被程序查询的持久化工作空间。

对人类而言，文件常常是打开、阅读和分享的文档。对 Agent 而言，文件还是：

  • 任务上下文与外部记忆；
  • 计划、中间结果与执行状态；
  • 代码、测试、日志与工具输入输出；
  • 结论的证据和审计记录；
  • 多 Agent 和多次执行之间的交接面。

为什么传统拆分架构会变麻烦

常见做法是将大文件放在对象存储，元数据放在关系数据库，再由应用维护两边的映射。这个架构本身没错，但它会把系统之间的缝隙暴露给业务层：

  1. 一致性：文件上传成功但元数据写入失败，或文件已删除但索引仍存在。
  2. 权限与缓存同步：访问策略已更新，旧缓存或签名 URL 却仍可用。
  3. 搜索与关联：文件经过 AI 处理后产生 summary、tag、embedding、实体与关系，Agent 又需要将它们与业务表做关联查询。
  4. 运维扩散：为延迟加上缓存后，又引入热点、失效、回源、扩缩容和故障转移问题。

很多复杂度不是业务想要的，它只是被架构缝隙硬塞给了业务。

Agent 持久化工作空间的设计契约

能力 要解决的问题
跨会话持久化 沙箱销毁后，新运行能继续之前的工作
熟悉的文件语义 Agent 仍然使用目录、路径、CLI、Git 和 SQLite 等现有工具
元数据与结构化查询 按任务、租户、时间、标签、状态和文件关系筛选
语义与全文检索 在文件、摘要、实体和 embedding 中找回正确上下文
事务一致性 协调文件、元数据、索引、权限与引用的状态变化
快照、恢复与 fork 试验失败后回滚，或从同一基线并行启动多个 Agent
多租户与权限 防止不同用户、项目和 Agent 之间串数据
审计、配额与计费 追踪谁读写了什么，并限制存储、查询和算力成本

如果这个层还要支撑自动评估与回归，就需要向《面向 Agent 的可验证架构：从 UI 驱动到自动回归闭环》所说的验证闭环暴露稳定的读写接口、版本状态和执行证据。

一种可行的分层架构

自上而下分为四层：

  1. Agent / Coding Agent
  2. 本地文件接口：FUSE、CLI、SDK
  3. Workspace 控制层：身份、权限、快照、配额
  4. 控制层之下并列两层，二者互相关联：
    • 元数据与索引层：SQL、全文、向量、审计
    • 文件数据层：对象存储 / 行存储

原文提出的 TiDB 思路是：小文件可直接入表，大文件进对象存储，内部表维护文件、元数据与对象位置的映射，用分布式事务保证状态协调，再将查询、索引、权限、缓存和计量下沉。

截至 2026-07-04，drive9 官方对外强调的是：

  • 文件可跨会话、工具和机器持续存在；
  • 沙箱可替换，同一文件系统继续使用；
  • 向 Agent 提供本地目录/FUSE 挂载语义；
  • 当前版本宣称支持 Git、SQLite 与可移植 overlay；
  • 传输加密、租户隔离和访问控制；
  • 持久化数据由兼容 S3 的对象存储支撑，产品页标注“Powered by TiDB Cloud”。

TiDB Cloud 官方则将自身定位为全托管、云原生的分布式 SQL 数据库，当前强调自动扩缩容、持久对象存储、全文/向量能力、可用性与安全性。

需要保留的边界

厂商视角

本文来自 TiDB/drive9 团队的产品叙事。架构问题具有普遍性，但客户采用、延迟、成本、大文件直存数据库等说法，在没有独立基准测试与完整工作负载之前，不应推广成通用结论。

  • 文件系统不等于记忆系统：存下来只解决 durability，何时写入、如何检索、哪些内容应被遗忘，仍需独立的记忆策略。
  • 存储安全不等于 Agent 安全：官方 FAQ 明确指出，数据交给 Agent 进程后，它如何使用数据由 Agent 与运行时负责。
  • 数据库不应无条件取代对象存储：文件大小、访问模式、一致性、成本和合规要求不同，应用实测决定分层。
  • 持久化会引入新治理问题：数据保留期、秘密扫描、敏感数据、删除语义、快照清理和租户导出都必须被设计。

选型时先问的六个问题

  1. 任务是否真的会跨沙箱、会话或机器延续？
  2. 需要保存的是文件，还是记忆、数据库状态与完整运行时快照？
  3. 一致性需要覆盖哪些对象：文件、元数据、索引、权限还是任务状态？
  4. Git、SQLite、大量小文件、大文件和并发 Agent 的读写模式各是什么？
  5. 谁可以读取、fork、恢复、删除和导出工作空间？
  6. 当服务不可用或延迟超标时，Agent 是停止、降级，还是切换本地副本？

来源与核对

时效性

drive9 与 TiDB Cloud 仍在快速迭代。本笔记将“Agent 需要持久化、可查询工作空间”视为稳定架构判断；具体功能与实现请以产品官网当前说明为准。