# 没人能规划 Infra 的未来：TiDB AI 演化之旅
**作者**: siddontang
**日期**: 2026-07-15T05:09:57.000Z
**来源**: [https://x.com/siddontang/status/2077259352357191752](https://x.com/siddontang/status/2077259352357191752)
---
如果只看结果，TiDB 在 AI 时代的产品形态变化很快。
从数据库，到 Serverless 数据库；从一个 agent 可以按需创建和销毁的数据库，到文件系统、云盘、coding workspace；最后逐渐变成面向 agent 的 unified storage layer。再往上，通过 agent stack solution，让用户更容易构建自己的 agent 应用，也让 TiDB 真正成为 agent infra 里重要的一环。
这听起来很像一个提前设计好的宏大战略。
但真实情况通常没那么体面。
我们不是坐在会议室里拍桌子说：“兄弟们，下一步我们要做 agent infrastructure。”
更真实的情况是：
我们是被客户一个又一个看起来有点离谱、但仔细一想又很合理的需求，一步步推到这里的。
这也是基础设施产品最有意思的地方。真正的变化，往往不是从一个漂亮概念开始，而是从客户一句：
“你们能不能顺便把这个也解决一下？”
开始的。
## 原点：把复杂度从应用开发者手里拿走
TiDB 最早要解决的问题很朴素：MySQL 分库分表太痛苦。
当年中国互联网高速增长，单机 MySQL 扛不住数据量和并发，业务团队不得不自己做分库分表。于是应用开发者不仅要写业务逻辑，还要处理路由、分片、扩容、复杂查询、运维和一致性问题。
本来是写业务的，最后活成了半个数据库内核工程师。
TiDB 的核心价值，就是把这些不该由应用开发者承担的复杂度，下沉到基础设施里。
这个原点很重要。
因为到了 AI agent 时代，问题变了，但逻辑没变。
以前我们想消除的是应用开发者的分库分表噩梦。
现在我们想消除的是 AI 开发者的状态、上下文、文件、工作区、运行环境管理噩梦。
本质上还是那句话：
应用开发者应该专注于业务，而不是每天和基础设施互相伤害。
下面这几个阶段，就是这个逻辑被客户需求不断放大的过程。
## 第一阶段：AI 公司还是“普通数据库客户”
最早的一类 AI 客户，其实没那么神秘。
他们有大量用户对话、应用元信息、模型调用记录和业务状态要存。早期用 MySQL 或 PostgreSQL 还能撑住，但业务一爆发，数据量和访问量上来，就又回到了老问题：
要不要分库分表？
这听起来很熟悉，甚至有点复古。
AI 公司再酷，数据库扩展性不够的时候，也还是会回到那个古老的问题：单机撑不住了，怎么办？
所以这些客户把 MySQL/PostgreSQL sharding 的复杂度迁到 TiDB 上，本质还是 TiDB 最熟悉的老问题：
数据规模增长太快，应用层不想再背数据库扩展性的锅。
这个阶段，我们对 AI 的理解还比较浅。看起来 AI 公司用数据库，和传统互联网公司没有本质区别：都是元数据多了、访问量大了、单机数据库撑不住了。
但很快，客户开始提出一些不太像“普通数据库需求”的要求。
## 第二阶段：一个用户一个数据库
Dify 提出了一个非常关键的需求：
能不能给每个用户一个独立数据库？
传统 SaaS 的设计通常是多租户共用一套数据库，通过 tenant_id 区分数据。这个模式成熟，也便宜，但在 AI workflow 场景里会暴露很多问题：
- 隔离性差：一个数据库出问题，可能影响大量用户。
- 安全风险高：应用逻辑一旦写错，可能出现租户之间的数据串读。
- 计费困难：用户到底用了多少数据库资源，很难单独核算。
- 变更风险大：一个租户的变更，可能影响其他租户。
所以 Dify 想要的是“一个用户一个数据库”。
这件事对 TiDB 是一个明显挑战。
以前我们更多是在解决“怎么把一个数据库做大”。现在客户问的是：
你能不能管理几十万、上百万个数据库？
这一步非常关键。
它让 TiDB 从“把单个数据库做大”，走向“把海量数据库管理起来”。
但在这个阶段，业务逻辑还是相对一致的。Dify 的每个用户都有自己的 workflow，但表结构和使用模式大体相似。
真正更激进的变化，来自下一类客户。
## 第三阶段：Agent 成为数据库的一等公民
后来，类似 Manus 这样的头部 agent 平台提出了更激进的需求。
他们也要 100 万个数据库。
但这次不是给 100 万个结构相似的 workflow 用，而是给 100 万个由 agent 生成的应用用。
用户可能让 agent 生成一个博客系统、CRM、内部工具，甚至一个小型 SaaS。每个应用都有自己的业务逻辑、schema、查询方式和生命周期。
这和 Dify 的场景完全不一样。
Dify 的挑战是规模和隔离。
Manus 这类场景的挑战是：
数据库的使用者不再是人写好的应用，而是 agent 本身。
agent 要自己创建数据库，自己生成 schema，自己写业务代码，自己生成查询逻辑，自己决定什么时候创建、什么时候修改、什么时候销毁。
这时候数据库不能再假设：
- schema 是人提前设计好的；
- 查询模式是工程师优化过的；
- 实例生命周期是长期稳定的；
- 运维操作由人类控制。
以前数据库面对的是人类工程师。
现在数据库面对的是一个会写代码、会建表、会改 schema、还可能凌晨三点突然销毁环境的 agent。
这是一种新的使用主体。
数据库必须开始把 agent 当成一等公民。
这是一次产品认知的跳变。
以前 TiDB 是给人类工程师和人类应用服务的数据库。
从这个阶段开始，TiDB 必须服务一种新的主体：会自己写代码、自己建表、自己查询、自己销毁环境的 agent。
## 第四阶段：数据库开始变成文件系统
接下来，一个做智能录音设备的客户问了一个非常反直觉的问题：
你们的数据库能不能存我们的文件？
对传统数据库工程师来说，这听起来有点像问：
“你们家冰箱能不能顺便当车库？”
数据库一般存结构化数据和元数据，音频、视频、图片这类大文件通常放在 S3 或对象存储里。
典型 AI 应用架构也是这样：
- 音视频文件放对象存储；
- summary、tag、transcript、embedding、metadata 放数据库。
这个架构看起来很合理。
但规模一大，问题就出来了：
- metadata 本身会变成扩展性瓶颈；
- 文件和 metadata 分属两个系统，一致性容易出问题；
- 对象存储延迟偏高，用户体验不够好；
- 为了解决延迟，客户又要自己做缓存；
- 缓存一大，又要处理热点、扩容、容灾和一致性。
客户最后发现：
为了让“文件 + metadata”这套系统稳定工作，他其实又在自己搭一个复杂的分布式系统。
这正好回到了 TiDB 的老命题：
应用开发者不应该为基础设施复杂度买单。
TiDB 本身是分布式数据库，底层也可以基于对象存储，同时有分布式事务、元数据管理、扩展性和热点处理能力。于是一个新的产品形态开始出现：
数据库不只是数据库，也可以成为文件系统。
这一步把 TiDB 从“结构化数据存储”推向了更大的“统一存储引擎”。
## 第五阶段：文件系统变成 Agent Runtime Workspace
文件系统之后，coding agent 场景又把需求往前推了一步。
Kimi、Verdent 等客户开始问：
既然 TiDB 能做文件系统，能不能给 agent 做一个云盘？
原因很简单：coding agent 通常跑在 sandbox 里，而 sandbox 往往是无状态的。
如果 sandbox 挂了，任务状态、代码修改、运行环境、上下文都可能丢掉。
agent 需要一个持久化的 workspace，把工作过程中的文件、状态、上下文保存下来。
但 coding workspace 不是普通网盘。
它有一个非常特殊的 workload：Git。
Git 会产生大量临时文件、对象、索引、diff、commit、clone、checkout 操作。普通云盘如果直接承载 Git 工作流，很容易遇到性能、成本和一致性问题。
所以客户真正要的不是“一个能挂载的盘”。
他们真正要的是：
一个懂 agent coding workload、懂 Git、能挂在 sandbox 上、能恢复任务状态的 workspace。
这时 TiDB 又前进了一步。
它不只是文件系统，而是 agent runtime 的 workspace。
这一步很关键，因为它把 TiDB 从“存储 agent 产生的数据”，推向了“承载 agent 的工作过程”。
## 第六阶段：Unified Storage Layer
一开始，TiDB 作为分布式 OLTP 数据库，解决的是传统 OLTP 可扩展性问题。
后来，为了帮助客户解决实时分析场景，TiDB 演化成了 HTAP 数据库。
到了 AI 时代，需求继续变了。
AI 应用不只需要存表。
它需要存状态、上下文、文件、embedding、transcript、metadata、workspace、运行过程、审计记录，甚至还要连接更复杂的数据湖和湖仓场景。
这就是 TiDB Lake 这类能力出现的背景。
AI 应用的数据形态天然是混合的：
- 有强事务的业务状态；
- 有高并发的在线查询；
- 有大规模历史数据；
- 有文件和对象；
- 有向量和语义检索；
- 有实时分析；
- 有离线训练和评估；
- 还有 agent runtime 产生的大量中间状态。
如果每一种数据都用一个系统解决，最后开发者面对的不是 infra stack，而是一场系统集成耐力赛。
所以 TiDB 在这个阶段的演化方向，是把分布式数据库、文件系统、workspace、数据湖能力结合起来，形成一个 unified storage layer。
它不是简单地说“我也支持更多数据类型”。
更准确地说，它是在回答一个问题：
AI 应用和 agent 系统能不能不要为每一种状态、文件、上下文、分析需求都单独搭一套基础设施？
这就是统一存储层的价值。
它让 agent 和 AI 应用可以在同一套基础设施上管理不同形态的数据：
- 在线状态；
- 用户数据；
- 文件内容；
- 工作区；
- 上下文；
- 审计日志；
- 分析数据；
- 长期记忆。
这一步之后，TiDB 的角色就不只是“数据库”了。
它开始成为 AI 应用背后的统一存储层。
## 扩展阶段：从统一存储层走向 Agent Stack
前面几个阶段的客户，大多是头部 AI 公司。
他们有很强的工程能力，只需要 TiDB 提供数据库、文件系统、云盘、workspace 这些底层能力。
但后来很多中小 AI 公司也找过来。
他们的问题不是：
“能不能给我一个数据库？”
而是：
“我能不能不要从零搭一套 agent 系统？”
一个真正能进 production 的 agent 系统，不只是 LLM API。
它至少包括：
- agent core：Claude Code SDK、Kimi Code、OpenAI Codex 等；
- sandbox/runtime：让 agent 安全运行任务；
- memory/state/workspace：短期记忆、长期记忆、文件、工作区；
- model/API gateway：不同模型的路由、成本和能力选择；
- observability：日志、监控、调试；
- audit/governance：权限、审计、合规；
- billing：资源计量和成本控制。
大公司可以自己搭。
中小 AI 公司很难。
尤其是硬件 AI、情感陪伴、垂直应用公司，它们的核心能力可能在产品、硬件、内容、场景和用户理解上，而不是从零搭 agent infra。
让它们自己搭一整套 production-grade agent infra，基本等于让一家咖啡店先自己造个电网。
所以这个阶段的需求变成：
你们能不能提供一套 agent stack，让我只关注自己的业务逻辑？
这时 TiDB 的定位也继续往前走。
不是做所有东西，而是以数据库、文件系统、workspace 和状态存储为核心，作为统一存储层，联合 sandbox、agent core、模型 API、观测、计费等生态组件，成为 agent infra 的入口之一。
这不是简单的平台化叙事。
更准确地说：
当 agent 真正进入 production，它需要一套统一的基础设施栈。TiDB 正在从这套栈里的统一存储层，变成开发者进入这套栈的入口之一。
## 这几个阶段背后的同一个逻辑
表面看，这几个阶段跨度很大：
- 从 MySQL/PostgreSQL sharding；
- 到百万数据库；
- 到 agent 自主建库；
- 到文件系统；
- 到 sandbox runtime 的 workspace；
- 到统一存储层；
- 到 agent stack。
但底层逻辑是一致的：
客户业务复杂度不断上升，而 TiDB 不断把这些复杂度从应用层拿走，沉到基础设施层。
十年前，复杂度是分库分表。
今天，复杂度是 agent 的状态、上下文、文件、工作区、权限、审计、运行环境和成本。
这也是为什么“AI 数据库”这个词并不够准确。
TiDB 在 AI 时代真正要做的，不是给数据库加一点 AI 能力，也不是简单做一个向量数据库，而是成为 agent 和 AI 应用背后的统一存储层：
- 状态可保存；
- 上下文可查询；
- 文件可管理；
- workspace 可恢复；
- 权限可治理；
- 操作可审计；
- 成本可计量；
- 规模可扩展。
这才是 TiDB 在 AI 时代真正值得讲的故事。
不是“数据库也会 AI 了”。
而是：
AI 应用终于把基础设施复杂度推到了一个新高度，而 TiDB 正在把这部分复杂度接住。
## 最后
基础设施产品最好的路线图，往往不是规划出来的，而是被客户逼出来的。
但前提是，你要听得懂客户真正的问题。
客户说“我要 100 万个数据库”，真正的问题可能是隔离、计费和 blast radius。
客户说“数据库能不能存文件”，真正的问题可能是 metadata、对象存储、一致性、延迟和缓存复杂度。
客户说“能不能给我一个云盘”，真正的问题可能是 sandbox 无状态、Git workload 和 agent workspace 恢复。
客户说“能不能给我一套 agent stack”，真正的问题可能是中小 AI 公司没有能力从零搭 production-grade agent infra。
所以 TiDB 的 AI 演化，并不是从数据库到 AI 概念的包装升级。
它更像是一条被客户需求拉出来的基础设施演化路径：
从存数据，到存文件，到存 workspace，到存 agent 的运行状态，最后成为 agent infrastructure 的一部分。
没人能在一开始就规划出 infra 的未来。
大多数时候，未来是客户先喊出来的。
你能做的，就是别嫌那个需求离谱，先认真听完，然后撸起袖子加油干。
## 相关链接
- [siddontang](https://x.com/siddontang)
- [@siddontang](https://x.com/siddontang)
- [2.2K](https://x.com/siddontang/status/2077259352357191752/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:09 PM · Jul 15, 2026](https://x.com/siddontang/status/2077259352357191752)
- [2,299 Views](https://x.com/siddontang/status/2077259352357191752/analytics)
- [View quotes](https://x.com/siddontang/status/2077259352357191752/quotes)
---
*导出时间: 2026/7/15 18:50:17*