为什么我们在 TiDB Cloud 上做了一个 Agent 云盘

我们最近基于 TiDB Cloud 给 AI Agent 做了一个云盘，叫 drive9.ai。

它的目标很简单：给每一个 Agent 提供一个简单易用、便宜可靠、可查询、可治理的云盘。

第一反应大概率是：

数据库？文件系统？云盘？你们是不是把架构图画反了？

说实话，我们一开始也觉得有点离谱。

数据库好好存行列数据，突然说自己要长出一个文件系统，听起来像 MySQL 半夜偷偷装了个 NAS。

但当我们和一些 AI 公司深入交流、共创、合作，并且真的帮他们上线之后，我们发现：这不是我们拍脑袋 YY 出来的方向，而是 AI Agent 领域里非常真实、非常具体、非常工程的痛点。

文件和元数据，终于开始互相折磨了

我们聊过一家全球领先的智能录音设备公司，也聊过几家机器人公司。

这些客户除了结构化数据之外，还有大量非结构化数据：

• 音频

• 视频

• 文本

• 图片

• 传感器数据

• 模型处理后的 summary、tag、embedding

• Agent 执行过程中产生的中间文件和结果

传统架构一般是这样：

• 文件放 S3 这类对象存储

• 元数据放 MySQL、PostgreSQL、Aurora 这类数据库

• 应用层自己维护两边的一致性

这个架构看起来非常标准，标准得像面试八股文。

但一到真实生产环境，问题就开始上线值班了。

第一，文件和元数据在两个系统里，一致性很难保证。

你删了文件，元数据还在；你写了元数据，文件上传失败；你更新了权限，但文件缓存还没失效。最后大家一起写补偿任务、对账任务、修复脚本，写着写着就像在给分布式系统擦屁股。

第二，元数据规模上来以后，传统数据库要分片。

分片本身没错，但谁维护谁知道。很多时候不是业务复杂，是你先被 shard key 教做人。

第三，对象存储有长尾延迟。

AI workload 不一定像传统 OLTP 那样对延迟极致敏感，但几十毫秒、上百毫秒的抖动，在一些交互式场景里用户还是会明显感受到。Agent 卡一下，用户不会想 “这可能是对象存储 P99”，用户只会觉得：这东西怎么有点笨。

第四，为了解决对象存储延迟，大家通常会在上面加 cache。

但 cache 这个东西，刚开始是优化，后来就会长成一个系统。热点、扩缩容、failover、一致性、淘汰策略、回源风暴，最后你会发现：你本来只是想加个 cache，结果不小心又重写了一个分布式系统。

第五，AI 会让文件变得 “可理解”。

用户上传的文件不再只是一个 blob。AI 会提取 summary、tag、embedding、实体、关系、时间线。很多场景里，Agent 需要非常方便地检索这些信息，甚至和结构化数据做 join。

这时候 SQL 突然又变得很香。

总结一下，客户真正需要的东西可能不是一个普通对象存储，也不是一个普通数据库，而是：

一个盖在对象存储上的 SQL cache layer。

听起来有点怪，但越想越合理。

为什么是 TiDB？

一开始，客户和我们都不认为 TiDB 能干这个。

毕竟文件系统这件事，已经明显超出了 TiDB 作为一款数据库的传统范畴。

但我们一起往下拆之后，发现：没准 TiDB 还真能干。

原因有几个。

第一，TiDB Cloud 本身已经把数据放在对象存储上，并且在上面提供缓存层，所以读延迟更可控。

第二，TiDB 的分布式架构天然适合处理 cache 扩缩容、热点打散、调度和 failover 这些问题。换句话说，很多人为了文件系统额外搭出来的一整套分布式能力，TiDB 本来就有一大半。

第三，TiDB 是经过十几年、上千客户 workload 打磨过的系统。很多大 value、大规模、高并发、高可靠性的场景，已经在生产环境里被验证过。

第四，TiDB 天然支持 SQL 级别的 metering 和 billing。AI workload 一跑起来，账单很容易像内存泄漏一样涨。你必须知道谁用了什么、用了多少、怎么计费、怎么限流。

所以我们最后做了一个很朴素的设计：

• 小文件直接存在 TiDB 表里

• 大文件放对象存储

• 内部表维护文件、元数据、对象位置之间的映射

• TiDB 用分布式事务保证文件数据和元数据的一致性

• TiDB 提供索引、权限、查询、缓存和治理能力

传统架构里，应用层要自己维护：

• 文件到底在不在

• 元数据到底对不对

• 权限有没有串

• 索引有没有漏

• cache 有没有脏

• 对象存储有没有慢

• 账单有没有爆

现在这些东西可以下沉到 TiDB Cloud 里。

应用终于不用一边写业务，一边兼职分布式清洁工。

更有意思的是，客户真的上线了。而且在一些场景里，已经有客户把 100MB 级别的文件直接存在 TiDB 里。

这件事一开始听起来有点反直觉，但工程上跑起来之后，你会发现它不是为了炫技，而是为了减少系统之间的缝。

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

然后，就到了 drive9

如果说 TiDB Cloud 长出来的是文件系统能力，那 drive9 就是给 AI Agent 用的云盘。

drive9 也是客户提给我们的需求。

某个全球顶级 Gen AI 客户，以及某头部 LLM 客户，都在大量使用 sandbox。但在 sandbox 使用过程中，他们经常会遇到一个问题：sandbox 会挂，或者会被回收。

这对 Agent 来说很麻烦。

因为 Agent 干活不是只跑一个 prompt。它会读文件、写文件、生成代码、跑测试、保存日志、修改 workspace、记录中间状态。

如果 sandbox 挂了，所有上下文都没了，那 Agent 就像一个刚进入公司的新人，每半小时失忆一次。

所以他们需要 sandbox 能挂载一个高性能的云盘。

而且这些客户很多是 coding agent 场景。coding 和 git 有大量交互，所以这个云盘还要对 git workspace 做很多特殊优化。

他们需要的 AI Agent 文件系统，不只是 read /write。

它还要：

• 能搜索

• 能挂元数据

• 能做向量检索

• 能按租户隔离

• 能控制权限

• 能和结构化数据连起来

• 能被 SQL 查询

• 能很好支持 git workspace

• 能支持整个文件系统 snapshot

• 能恢复、fork、审计和计费

人类用云盘，通常是点开文件夹，找个 PDF，拖张照片。

Agent 用云盘，是把文件当成上下文、记忆、证据、任务状态和工具输入输出。

所以 Agent 不需要一个 “网盘 UI”。

它需要的是一个可查询、可编程、可理解、可治理的数据层。

这就是为什么 drive9 建在 TiDB Cloud 上。

听起来不浪漫，但很工程。

因为 AI 时代的文件系统，已经不只是 “文件放哪里” 的问题了。

它变成了：

• 文件如何被理解

• 文件如何被搜索

• 文件如何和结构化数据关联

• 文件如何按租户隔离

• 文件如何控制权限

• 文件如何计费

• 文件如何审计

• 文件如何在 Agent 执行过程中保持连续性

换句话说：

现在文件系统要服务 Agent。过去文件系统服务人类。

关于 drive9 是如何基于 TiDB Cloud 来构建的，以及为什么非常合适 git 场景，我后面文章会详细说明。

最后

我们做 drive9，不是因为数据库突然想跨界做网盘。

而是因为 Agent 时代，文件本身的角色变了。

文件不再只是静态附件，而是 Agent 的上下文、记忆、证据、状态和工作空间。

当文件变成 Agent 执行任务的一部分，它就必须具备数据库级别的一致性、查询能力、权限控制、审计能力和成本治理。

所以 “数据库长出文件系统” 这件事，听起来像玩笑，但背后其实是一个很严肃的判断：

而下一代文件系统，很可能需要长在数据库和云基础设施之上。AI Agent 会重新定义文件系统。

这也是 drive9.ai 想做的事情。

给 Agent 一个不是一次性、不是黑盒、不是只会存 blob 的云盘。

而是一个真正 durable、queryable、programmable、governable 的 workspace layer。

简单说：

Agent 缺的是一个能干活、能恢复、能审计、还能被 SQL 查询的文件系统。Agent 不是缺一个网盘。

我们是认真的。