对谈 TiDB 一号员工：AI 应用被重写，数据库被重新定义

本文整理自播客 Day1Global 生而全球 对 平凯星辰 一号员工、TiDB Chief AI Officer 唐刘的访谈。主持人为 Star，Day1Global 主理人。原节目围绕 AI Agent、数据库演化、AI 应用护城河与基础设施机会展开。

过去一年，AI 对软件行业的冲击越来越具体。

一方面，AI Agent 带来了巨大的计算和存储需求，算力、存储芯片、云基础设施成为资本市场的热门方向；另一方面，随着 Claude Code、Codex、Kimi 等 Agent 产品快速进化，很多传统软件公司的价值也开始被重新评估。

如果 Agent 可以写代码、搭网站、生成业务系统，那么原本需要采购的 SaaS，会不会被 Agent 快速替代？如果用户不再通过人手点击软件，而是让 Agent 自主调用工具和系统，那么软件的护城河又在哪里？

在 Day1Global 的这期访谈里，主持人 Star 抛出了一个很有代表性的问题：

都说 AI Agent 增加了数据的存储和使用，为什么半导体公司一年可以涨很多倍，但一些数据库公司的估值却承压？AI 的数据到底存在哪里？Agent 时代还需要什么样的数据库？

唐刘的回答很明确：AI 不会削弱数据库，反而会让数据库变得更重要。

但这里的“数据库”，已经不再只是过去那个用于增删查改业务表的数据库。它正在从“存业务数据”的系统，演化成 Agent 背后的统一存储层：保存状态、上下文、记忆、文件、权限、工作空间和审计记录。

真正的变化是：数据库的用户，正在从人和应用，变成 Agent 本身。

一、十年前，数据库解决的是分库分表；今天，Agent 带来了新的复杂度

TiDB 的故事开始于 2015 年 4 月 1 日。

那一天，Max 找到唐刘，说想做一个开源分布式数据库。唐刘第一反应是：这是愚人节玩笑吗？

当时国内做数据库内核的人很少，做开源基础软件的人也很少。要从零开始做一个分布式数据库，在当时听起来几乎是不可能完成的事。

但这个“不现实”的想法背后，是一个非常现实的问题：中国互联网公司的业务增长太快了。

早期大量互联网公司使用 LAMP 架构：Linux、Apache、PHP、MySQL。业务规模小时，单机 MySQL 足够好用。但随着电商、社交、移动互联网、短视频等业务爆发，数据量和访问量迅速超过单机数据库承载能力。

于是公司不得不分库分表。

唐刘在访谈中用了一个很直观的比喻：可以把数据库想象成一个电商平台的账本。用户信息、订单、商品、支付交易都记在这个账本里。业务小时，一本账本够用；业务大了，一本账本既写不下，也扛不住很多人同时查询，就只能拆成很多本账本。

这就是分库分表。

问题在于，账本拆开以后，复杂度并不会消失，而是转嫁给开发者和运维人员。跨库查询、分片逻辑、事务处理、数据迁移、扩容缩容，都变成业务团队的负担。

TiDB 最初要解决的，就是这个问题：把不该由应用开发者承担的复杂度，下沉到基础设施。

这个逻辑在 AI Agent 时代再次出现。只不过这一次，复杂度不再只是数据量和并发，而是 Agent 的状态、上下文、记忆、文件和工作空间。

二、AI 压缩了软件层，却放大了数据层

过去 SaaS 的价值，来自标准化软件服务。

企业不想自己开发报销系统、人力资源系统、CRM、代码管理平台，于是购买 SaaS。因为自己开发和维护的成本，远高于直接购买服务的成本。

但 AI Agent 正在改变这个成本结构。

当 Claude Code、Codex 等工具足够强时，很多业务系统的应用逻辑可以被 Agent 低成本生成。过去需要一个 SaaS 产品解决的问题，未来可能通过一个 Agent 加上一些数据和工具就能完成。

这也是为什么“AI 会不会吞掉 SaaS”成为一个高频讨论。

但应用逻辑被压缩后，还有一层东西不会消失：数据。

企业用 Agent 实现业务逻辑时，仍然需要保存客户数据、业务状态、上下文、文件、记忆、权限和历史记录。这些才是企业真正沉淀下来的资产。

所以，数据库在 Agent 时代不但不会消失，反而会变成更核心的 source of truth。

不过，这里的数据库已经不只是传统意义上的 CRUD 工具。Agent 需要的不只是增删查改，而是一个可以统一管理 memory、state、context、workspace、file、permission 和 audit log 的存储系统。

如果一个产品只是承载业务逻辑，它可能被模型压缩；但如果一个产品承载了数据、状态、上下文和工作流，它更可能成为模型变强后的受益方。

三、数据库的用户，正在从人变成 Agent

这期访谈里最重要的判断，不是“AI 需要更多数据库”，而是：数据库的用户变了。

过去数据库主要服务人和业务系统。人使用软件时，是低频、视觉导向、相对可预测的：打开页面、点击按钮、提交表单、查询数据。

Agent 使用数据库完全不同。

1. 访问更高频，也更不可预测

人类开发者会遵守 DBA 制定的最佳实践，尽量避免危险查询。但 Agent 执行任务时，用户只会告诉它目标，具体怎么查、怎么写、怎么检索，是 Agent 自己决定的。

这意味着数据库要面对更动态、更高频、更不可控的访问模式。

2. Agent 更依赖上下文

人类使用系统时，很多上下文存在脑子里；但 Agent 要完成任务，必须依赖外部记忆。

它需要知道历史对话、当前状态、工具调用记录、权限边界、下一步能做什么、不能做什么。

3. 数据库生命周期更短

传统数据库通常是长期运行的服务，一个实例可能 7×24 小时稳定运行。但 Agent 可能为了完成某个任务临时创建数据库，任务结束后立刻销毁。

数据库从长期资源，变成了某些场景下的“用后即焚”资源。

4. Agent 不只关心“数据在哪里”

人类开发者通常知道数据存在哪里，需要时查出来即可。但 Agent 还需要知道：当前状态是什么？上下文是什么？我有什么权限？这个操作是否可审计？失败后是否可恢复？

所以，Agent 对数据库提出的要求，反而比人更高。

四、从数据库到 Agent Infra：TiDB 在 AI 客户中的六次演化

唐刘在访谈中提到，TiDB 服务 AI 客户的过程，可以概括为六个阶段。这六个阶段，也是一条 Agent 基础设施需求的演化路线。

暂时无法在飞书文档外展示此内容

阶段 1：AI 公司首先也是数据规模公司

一些大模型公司最初把对话和元信息存在 PostgreSQL 中。用户量暴涨后，PostgreSQL 扛不住，需要分库分表，最后迁移到 TiDB。

这和传统互联网业务遇到的问题类似：AI 公司首先也是数据规模公司。

阶段 2：一个用户一个数据库

Dify 这样的 AI workflow 平台，不希望像传统 SaaS 那样把所有租户数据放在同一个数据库里，而是希望每个用户有独立数据库。

这样做的原因包括：

• 隔离不同用户的数据和故障影响
• 降低数据串读风险
• 更容易按用户计费
• 避免一个用户的变更影响所有用户

这让数据库从“一个大池子”，变成了“按用户隔离的资源”。

阶段 3：一个 Agent 一个数据库

更激进的 AI 建站平台提出：不仅要大量数据库，而且每个数据库背后的业务逻辑都可能不同。

Agent 要自主创建数据库、生成 schema、写业务代码、生成查询逻辑，并管理整个数据库生命周期。

这时，数据库真正开始从“给人用”转向“给 Agent 用”。

阶段 4：数据库开始存文件

智能录音设备客户提出：能不能把音视频文件也存在数据库里？

传统架构通常是文件放对象存储，元信息放数据库。但这会带来几个问题：

• 元信息本身也会遇到扩展性瓶颈
• 文件与元信息之间可能出现一致性问题
• 对象存储访问延迟较高
• 为了优化延迟，又要搭缓存系统
• 缓存系统本身又会遇到分布式和热点问题

如果企业为了优化这些问题，又自己搭一套分布式缓存和一致性系统，就等于重新造了一套基础设施。

TiDB 基于分布式事务和对象存储架构，可以把文件和元信息统一管理，降低应用侧复杂度。

阶段 5：数据库变成 Agent 的云盘和 Workspace

Coding Agent 通常跑在 sandbox 里，而 sandbox 是无状态的。如果沙箱挂了，任务上下文和工作区就会丢失。

因此客户需要一个可挂载的云盘，把 Agent 的运行环境、状态、代码和上下文保存下来。

而 coding 场景又离不开 Git，所以这个云盘还需要针对 Git 的 workload 优化。

到这一步，TiDB 已经不只是数据库，而是在变成 Agent runtime 的 workspace。

阶段 6：面向中小企业的 Agent Stack

头部 AI 公司有能力自己搭建 Agent 系统，但大量中小 AI 公司没有这样的研发能力。

它们需要的是一整套 Agent 基础设施：

TiDB 在这个阶段的角色，不是把所有东西都自己做掉，而是联合生态组件，提供一个 Agent Infra 的入口，让开发者不用从零搭数据库、文件系统、沙箱、记忆系统和监控系统，而是直接专注自己的业务逻辑。

主持人 Star 在访谈里做了一个很形象的总结：一开始是存 AI 产生的数据，后来是给每个 Agent 分配数据库，再后来是存文件、存 workspace，最后有点像是“把 Agent 自己也存进去”。

五、FDE 为什么在 AI 时代重新重要？

这些需求并不是 TiDB 在会议室里凭空想出来的，而是被客户一步步“逼”出来的。

这也解释了为什么 FDE，也就是前向部署工程师，在 AI 时代重新变得重要。

传统企业软件的销售和产品流程很长：产品经理拜访客户，收集需求，研发开发，PMM 包装材料，售前培训销售，销售再去卖给客户。

但 AI 时代，这套流程太慢了。

客户今天提出需求，可能明天就想看到结果。更关键的是，AI 客户本身通常技术能力很强，决策链也很短。很多时候，客户自己也不完全知道自己真正需要什么，必须和供应商一起共创。

这时，FDE 的价值就出现了。

它不是单纯销售，也不是传统售前，而是带着工程能力进入客户现场，理解业务问题，快速判断技术方案，甚至当天修改、当天交付。

唐刘认为，AI 时代会越来越需要“有工程师背景的销售”。因为单纯写代码的价值正在被 Agent 放大和替代，工程师新的价值会更多体现在理解业务、靠近客户、识别真实问题，并借助 AI 快速交付。

AI 时代的组织优势，不只是模型能力，而是反馈速度。谁能更快贴近客户、更快理解问题、更快交付答案，谁就更容易找到真实需求。

六、什么样的企业更具韧性？大模型时代的四条护城河

这也是 Star 在节目标题中提出的核心问题：什么样的公司会受益于大模型，什么样的公司会被模型“吞掉”？

唐刘给出的判断，可以总结为四条护城河。

1. 是否拥有私有数据和上下文

如果一个产品拥有别人没有的数据、业务上下文和工作流，大模型无法凭空训练出来。这是最重要的护城河之一。

2. 是否深度融入企业日常运转

GitHub、Salesforce 这类产品难以替换，不只是因为功能，而是因为它们已经嵌入企业工作的方方面面。

一旦成为组织运行的一部分，可替换性就会显著降低。

3. 是否形成生态和统一解决方案

单点工具容易被模型或竞品替代，但如果一个 AI 应用和周边生态深度集成，形成完整解决方案，就更难被替换。

4. 是否有持续触达客户和快速迭代的能力

在 AI 时代，执行速度本身就是护城河。能够持续接触客户、快速反馈、快速交付的团队，更不容易被模型变化吞掉。

不过，即使是 GitHub 这样的产品，未来也会面临一个新问题：它是否真正把 Agent 当作一等公民？

如果未来每个人都有多个 Agent 分身，那么代码协作系统也需要重新设计人与 Agent 的关系。

七、变化越快，越要看不变的东西

过去一年，唐刘最大的认知反转是：AI 的关键不再只是“回答问题”，而是“完成任务”。

回答一个问题，主要依赖模型能力；完成一个任务，则需要上下文、工具、权限、状态、记忆、审计和运行环境。

这也是为什么他现在更关注 Agent 的运行环境，而不是单纯关注模型本身。

面对快速变化，他认为有几件事不会变。

• 商业本质不会变。无论用户是人还是 Agent，一个产品有没有价值，最终还是看有没有人愿意为它付钱。
• 数据价值不会变。尤其是真实业务数据和上下文数据，会在 Agent 时代变得更重要。
• 对简单性的追求不会变。无论使用者是开发者、普通用户，还是 Agent，越简单、越可靠、越容易使用的系统，价值越大。
• 可靠性和信任不会变。用户不会因为一个系统由 AI 驱动，就接受丢数据、权限泄露或任务乱执行。

他在节目最后推荐了一本书：《系统之美》。原因也和这期访谈的主线一致：真正重要的不是优化某一个局部，而是看清楚整个系统如何运转，以及哪里才是改变系统的杠杆点。

结语：Agent 可以生成应用，但仍然需要地方记住世界

十年前，TiDB 想解决的是程序员分库分表的噩梦。

下一个十年，Agent Infra 要解决的是状态、上下文、记忆和 workspace 管理的噩梦。

如果一个产品只是业务逻辑，它可能被模型压缩；如果一个产品承载了数据、状态、上下文和工作流，它更可能成为模型变强后的受益方。

AI 可以生成应用，但它仍然需要地方保存状态、记住历史、恢复现场、审计过程。

所以，Agent 时代，基础设施不会退场。相反，真正可靠、可扩展、可治理的基础设施，会变得比过去更重要。

因为 Agent 可以生成世界，但它仍然需要一个地方，记住世界。

来源说明：本文基于 Day1Global 生而全球播客节目《你是大模型的受益方，还是被吞掉方？AI 应用的护城河与基础设施机会 ft. TiDB 唐刘》整理改写。感谢主持人 Star 的提问与节目制作。