# 你是大模型的受益方，还是被吞掉方？AI应用的护城河与机会 ft. TiDB 唐刘
**作者**: Star@Day1Global Podcast
**日期**: 2026-07-13T01:25:15.000Z
**来源**: [https://x.com/starzq/status/2076478556734206365](https://x.com/starzq/status/2076478556734206365)
---
当 Agent 可以写代码、搭网站、生成业务系统，软件的价值正在被重新评估：原本需要采购的 SaaS，可能被 Agent 快速生成；原本由人操作的系统，也开始由 Agent 自主调用。
数据库会因此变得不再重要吗？现实可能恰恰相反。
一家 M 开头的头部 AI Agent 平台曾向 TiDB 提出一个听起来很疯狂的需求：能不能低成本提供 100 万个数据库？数据库的问题解决后，对方又问，能不能再提供 100 万个云盘？
这不只是数据量变大，而是数据库的“用户”变了。过去，数据库服务人和预先写好的业务系统；现在，Agent 会自主创建、访问和销毁数据库，还要管理上下文、状态、权限、文件与运行环境。数据库不再只是存放业务数据的后台组件，而可能成为 Agent 最核心的 Source of Truth。
这一期，Day1Global 邀请到 PingCAP 一号员工、TiDB Chief AI Officer 唐刘。从 11 年前解决 MySQL 分库分表的运维噩梦，到今天探索 Agent 的统一存储层，我们聊了 TiDB 的六次产品演化、FDE 为什么在 AI 时代重新走红、AI 基础设施和应用层还有哪些机会，以及一个创业者必须回答的问题：你做的产品，是大模型进步的受益方，还是六个月后会被模型吞掉的一层？
> 本文为 Day1Global 播客精编文字稿，基于最终录音稿整理。为便于阅读，内容在不改变原意的基础上做了口语顺滑、结构重组和术语统一，非逐字稿。
欢迎收看/收听完整播客
视频
> **Star@Day1Global Podcast@starzq**: [原文链接](https://x.com/starzq/status/2076478025877909675)
>
> E81. 你是大模型的受益方，还是被吞掉方？AI应用的护城河与基础设施机会 ft. TiDB @siddontang
> 什么样的公司会受益于 AI 大模型，什么样的公司会被模型吞掉？
> 都说 Agent 增加了数据的存储和使用，为什么半导体公司一年可以涨 10-20 倍，但 MongoDB 这样的数据库公司股价一度腰斩？
> 本期节目 ,
音频
https://www.xiaoyuzhoufm.com/episode/6a53331f4adef2b365629cb3
## 本文目录
一、11 年前的愚人节：为什么要再做一个数据库
二、从分库分表到 Agent-first：基础设施不断接管复杂度
三、AI 不会削弱数据库，反而会让它更重要
四、Agent 和人使用数据库，有什么根本不同
五、六次产品演化：从存数据到“把 Agent 自己存进去”
六、FDE 为什么成为 AI 公司的关键角色
七、TiDB 的新定位：Agent 背后的统一存储层
八、Memory、Sandbox、权限与评测：基础设施还有哪些机会
九、你是模型的受益方，还是被吞掉方
十、回答问题与完成任务之间，隔着一整套系统
十一、AI 变化越快，越要关注不变的东西
## 一、11 年前的愚人节：为什么要再做一个数据库
Star：11 年前的 4 月 1 日，Max 邀请你一起做一个开源分布式数据库。你的第一反应是什么？
唐刘：第一反应就是：Are you kidding me？
那是愚人节，而且我们当时从来没有在线下见过，只在网上聊过。更重要的是，那时国内做数据库内核和开源基础软件的人很少，我们之前也没有完整做过数据库。现在回头看，这件事能走到今天，反而很有意思。
但决定做 TiDB 的原因其实很朴素：我们遇到了一个真实而且非常痛的问题。
十几年前，中国互联网公司普遍使用 LAMP 架构，也就是 Linux、Apache、PHP 和 MySQL。业务小的时候，一台 MySQL 足够；但互联网业务增长太快，数据越来越多、访问并发越来越高，一台机器很快就扛不住了。
这时大家只能做分库分表。你可以把数据库想成一本账本：订单、用户、商品、支付记录都写在里面。一本账本装不下，就拆成很多本；访问压力太大，也分散到不同账本上。
问题是，账本拆开之后，复杂度没有消失，而是被转移给了业务开发和运维团队。跨库查询、数据路由、扩容和故障处理，都会变成工程师的噩梦。
我们当时的想法就是：能不能把这些不该由应用开发者承担的复杂度，下沉到基础设施？让开发者只关注业务，而不是天天处理分库分表。
某种程度上，中国互联网的发展史，也是一部“悲催的 MySQL 运维史”。TiDB 最初要解决的，就是这个问题。
## 二、从分库分表到 Agent-first：基础设施不断接管复杂度
Star：TiDB 的 11 年，好像也对应了数据库和互联网基础设施的演化。
唐刘：是的。TiDB 的发展史，本质上是一部不断把复杂度下沉的历史。
最初，我们解决的是 MySQL 分库分表。后来企业把系统搬到云上，数据库从本地自运维走向 Cloud Native 和托管服务；再往后，Serverless 出现，用户希望按需使用、按量付费，不再长期预留固定资源。
到了 Agent 时代，变化更大。数据库的使用者不再只是人和固定业务系统，而开始变成 Agent。它需要存的不只是结构化业务数据，还包括 Memory、State、文件、Workspace 和工具调用记录。
所以数据库正在从“存数据的系统”，演化成 Agent 的统一存储空间。TiDB 的历史，也可以看作互联网和 AI 基础设施迭代的一条缩影。
## 三、AI 不会削弱数据库，反而会让它更重要
Star：一方面，AI 产生了更多数据；另一方面，市场又担心 AI 会替代软件，数据库公司也受到冲击。AI 到底还需不需要数据库？
唐刘：我的判断是：AI 不会削弱数据库，反而会让数据库变得更重要。
AI 的确会压缩很多业务系统。过去企业购买 SaaS，是因为自己开发一套报销、人力或 CRM 系统太贵。现在，Agent 写代码和构建应用的能力越来越强，一些中间层业务软件可能被快速生成，成本也会下降。
但业务系统被压缩之后，企业的数据不会消失。客户信息、订单、权限、流程状态和历史上下文，仍然是公司的核心资产，必须有地方可靠地保存。
因此，数据库会成为 Agent 的状态、上下文和业务事实最核心的 Source of Truth。
不过，传统数据库只提供 CRUD，也就是增删查改，已经不够了。Agent 还需要 Memory、State、文件系统、Workspace、权限、审计和恢复能力。未来有竞争力的数据库，不只是“一个库”，而是可扩展、面向多种数据形态，并且把 Agent 当作一等公民的统一存储引擎。
## 四、Agent 和人使用数据库，有什么根本不同
Star：当数据库的用户从人变成 Agent，使用方式会发生什么变化？
唐刘：至少有四个明显区别。
第一，Agent 的访问更高频、更动态，也更不可预测。人会按照界面和固定流程操作，工程师也会给业务系统制定数据库最佳实践。但你只会告诉 Agent 一个目标，至于它查多少次、怎么组合查询、什么时候写入，往往无法预先确定。
第二，Agent 需要更完整的上下文。人脑会记住大量背景信息，但 Agent 要完成下一步任务，必须重新读取历史、状态、环境和相关数据。它需要保存和召回的内容，通常比人多得多。
第三，生命周期更短。人创建的数据库往往长期运行；Agent 可能为一个任务临时创建数据库，任务结束后立即销毁。大量数据库会进入“用后即焚”的状态。
第四，Agent 不只需要知道“数据在哪里”，还要知道当前状态是什么、自己拥有什么权限、下一步可以做什么，以及之前发生过什么。因此，可追溯、可审计、可监控和可恢复会变得非常重要。
也就是说，Agent 对数据库的要求不是更低，而是更高，而且与过去完全不同。
## 五、六次产品演化：从存数据到“把 Agent 自己存进去”
Star：这些变化并不是凭空想象出来的。你们服务 AI 客户时，经历了哪些具体需求？
唐刘：我们大致经历了六个阶段，而且几乎每一步都是客户推着我们往前走。
第一个阶段，是存储 AI 应用产生的海量数据。一家头部大模型公司在用户快速增长后，发现原来的 PostgreSQL 很难承载大量对话和应用元信息，分库分表又拖慢研发，于是迁移到 TiDB。这时我们以为，AI 公司使用数据库和互联网公司没有本质区别，核心仍然是可扩展性。
第二个阶段，是“一位用户一个数据库”。Dify 提出，他们不希望把所有 SaaS 租户放在同一张表或同一个数据库里，而是希望每个用户拥有独立数据库。这样可以更好地隔离故障和数据，避免一个租户影响其他租户，也更容易独立计费。对 TiDB 来说，挑战从“把一个数据库做大”，变成了“同时管理几十万甚至上百万个数据库”。
第三个阶段，是让 Agent 自主管理数据库。一家头部 AI Agent 平台希望为海量用户生成彼此完全不同的网站和业务系统。每个应用都有独立的数据模型，数据库的创建、表结构设计、查询代码和生命周期，都由 Agent 自主完成。
这一刻，我们意识到：数据库已经不是给人设计的，而是要给 Agent 设计的。Agent 必须成为数据库的一等公民。
第四个阶段，是把文件也放进来。一家智能录音硬件公司原本把音视频放在对象存储，把摘要、标签和逐字稿等元信息放在数据库。但两套系统之间容易出现一致性问题，元信息会遇到扩展瓶颈，文件读取还需要额外的缓存和热点治理。
客户问我们：能不能把文件和元信息放进同一个体系？这推动 TiDB 从传统数据库进一步走向文件系统和统一存储。
第五个阶段，是云盘和 Workspace。Coding Agent 通常运行在无状态 Sandbox 中，一旦沙箱中断，任务环境和中间状态就可能丢失。因此客户需要一个可以挂载到沙箱的持久化云盘，还要针对 Git、代码克隆、提交和大量临时文件进行优化。
这时，TiDB 不再只是保存数据和文件，而开始成为 Agent 的运行时 Workspace。
第六个阶段，是 Agent Stack。头部 AI 公司有能力自己搭建模型调用、Sandbox、Memory、存储、监控、计费和审计系统，但大量中小企业没有这样的研发能力。它们希望获得一套按需使用的基础设施，只需要关注自己的 Agent 业务逻辑。
因此，我们开始与生态伙伴一起整合数据库、文件系统、Sandbox、Agent Core 和其他开源组件，为开发者提供更完整的 Agent Infra 入口。
Star：所以一开始是存海量数据，后来是几百万个数据库，再后来是存文件、存运行环境。到最后，已经不只是“存数据”了，有点像把 Agent 自己存进去。
唐刘：对，这个比喻很准确：把 Agent 自己存进去了。
## 六、FDE 为什么成为 AI 公司的关键角色
Star：这些需求都来自客户。为什么 FDE，也就是前向部署工程师，在 AI 时代又变得重要？
唐刘：我甚至会说，如果一家 AI 公司没有 FDE，很难把产品真正交付给企业客户。
AI 产品太新，客户往往不知道自己究竟需要什么，厂商也无法提前定义完整答案。传统企业的链条是：产品经理收集需求，研发开发，市场包装，解决方案团队培训，再由销售交付。这个流程在成熟行业可以运转，但在 AI 时代太慢了。
客户可能早上提出需求，晚上就希望看到结果。FDE 的价值，就是让有工程背景的人直接进入客户现场，理解业务、调整方案，甚至现场修改产品，再把反馈快速带回研发。
TiDB 在 AI 业务线上，很多销售就是资深研发转过去的。因为客户本身高度技术导向，技术人员和技术人员直接交流，更容易建立信任，也更容易识别客户没有说清楚的真实问题。
AI 时代最重要的是 Speed matters。跑得快不代表永远不犯错，但反馈足够快，就有更大的调整空间。
对程序员来说，这也是一个变化：单纯写代码的价值会下降，但理解业务、发现问题，再借助 AI 快速交付的价值会提高。有工程背景的销售和 FDE，会越来越重要。
## 七、TiDB 的新定位：Agent 背后的统一存储层
Star：在 AI 生态里，TiDB 怎么定位自己？
唐刘：我们的本质没有变，仍然是帮助用户保存、查询和管理数据。但数据库的用户已经从人转向 Agent，所以产品边界也要变化。
我们希望 TiDB 成为 Agent 和 AI 应用背后的 unified storage layer，也就是统一存储层。
Agent 产生的 Memory、State、Workspace、文件、权限信息和工具调用记录，都应该能够被保存、查询、恢复和治理。开发者不需要分别搭建很多套系统，也不需要自己处理复杂的状态和上下文管理，只要专注于 Agent 的业务逻辑。
11 年前，我们希望消除程序员分库分表的噩梦；未来十年，我们希望消除 AI 开发者管理状态、上下文和记忆的噩梦。
## 八、Memory、Sandbox、权限与评测：基础设施还有哪些机会
Star：除了存储，你还看好哪些 AI 基础设施方向？
唐刘：第一是 Memory。真正有价值的记忆系统不只是抽取事实和做摘要，而要和 Agent 的推理、工作流以及客户业务深度结合。它很难做，但一旦进入核心业务，粘性也很高。
第二是安全的 Sandbox。Agent 要执行代码，就需要隔离的运行环境。如果能在保证安全的前提下，提高单机调度密度、降低成本，商业价值会很明显。
第三是企业级能力，包括身份认证、权限、可观测性、数据治理和审计。很多早期 Agent 更像玩具，但进入严肃业务后，企业一定会要求安全、合规和可控，而这些往往也是客户最愿意付费的部分。
第四是评测。一个 Agent 到底做得更好了还是更坏了？一个任务是否真正完成？很多时候，不运行就无法判断；但直接在线上运行，又可能造成损失。如何建立可靠的评测和验证系统，是一个长期机会。
## 九、你是模型的受益方，还是被吞掉方
Star：面对客户提出的各种需求，你们怎么判断一个方向值不值得做？
唐刘：AI 领域有一个必须回答的问题：你到底是模型进步的受益方，还是会被模型吞掉的一层？
大模型迭代太快。你今天解决的问题，六个月后可能直接变成模型的原生能力。很多过去需要复杂编排和 Prompt Engineering 的任务，现在只要把目标说清楚，Agent 就能自动完成。
所以做 AI 产品时，要判断模型越强，你的价值是越大，还是越小。
我认为真正的护城河可能来自几件事：第一，别人没有的私有数据和上下文；第二，深度融入企业工作流，成为日常运营的一部分；第三，形成完整的产品生态和解决方案；第四，拥有持续触达客户的渠道，以及快速反馈、快速交付的执行力。
但最核心的判断仍然非常直接：有没有人愿意为你解决的问题付钱？如果没有，作为公司就很难长期成立。
应用层已经出现不少真实价值，包括应用生成平台、企业 AI Workforce、Coding Agent、Agent Payment、AI 搜索、智能硬件和情感陪伴。但这些领域最终能留下多少公司，取决于它们能否建立模型能力之外的壁垒。
## 十、回答问题与完成任务之间，隔着一整套系统
Star：过去一年，你对 AI 最大的一次认知变化是什么？
唐刘：以前我们更关注模型能不能回答问题、Prompt 怎么写。后来我越来越觉得，真正困难的事情不是让 AI 想明白，而是让它把事情做完。
回答一个问题和完成一个任务，中间差得非常远。
完成任务需要上下文、工具、权限、状态和运行环境，还要有失败恢复、审计和人机协作。模型只是其中一部分。模型越强，围绕它的系统能力反而越重要。
这也是为什么我现在更关注 Agent 的运行环境，而不是只关注模型本身。只有当这些环节被补齐，Agent 才能从“会回答”走向“能交付”。
## 十一、AI 变化越快，越要关注不变的东西
Star：未来十年，有哪些东西不会变？
唐刘：第一，商业本质不会变。你做的东西，最终要有人愿意付钱。即使未来主要用户变成 Agent，也要有 Agent 或其背后的组织愿意为价值买单。
第二，数据的价值不会变。AI 生成的数据会越来越多，单条数据的密度可能下降，但真实业务数据、历史上下文和高频访问的数据会更加重要。
第三，对简单性的追求不会变。无论用户是人、开发者还是 Agent，系统越简单，越容易被正确使用。
第四，可靠性和可信任性不会变。用户不会因为产品由 AI 构建，就接受丢数据、权限泄露或任务乱执行。
Star：你最后推荐了《系统之美》。它为什么对你影响很大？
唐刘：这本书让我不再只看单点问题，而是把问题放进完整系统里，看反馈回路、延迟和杠杆点。
做数据库和基础设施时，一个看起来很小的设计，可能同时影响可靠性、性能、可运维性、开发者体验，甚至公司最终会长成什么样。AI 也是如此。一个 Agent 很快做出功能，并不代表系统已经完整；状态如何保存、权限如何管理、过程能否审计、失败能否恢复，都会影响最终结果。
真正重要的不是优化某个局部，而是看清系统如何运转，以及改变系统的杠杆点在哪里。
AI 的变化会让人焦虑。新的模型、框架和各种“Engineering”概念不断出现，可能几个月后又被替代。缓解焦虑的一种方式，是少追逐短期名词，多关注长期不变的价值链：理解客户、解决真实问题、可靠交付，并持续创造有人愿意付费的价值。
写代码可能不再是程序员唯一的核心竞争力，但在需求、产品、交付和运维构成的完整系统里，人仍然可以创造很大价值。
免责声明：本文仅为播客内容整理，不构成投资、技术选型或商业决策建议。
## 相关链接
- [Star@Day1Global Podcast](https://x.com/starzq)
- [@starzq](https://x.com/starzq)
- [3.7K](https://x.com/starzq/status/2076478556734206365/analytics)
- [@siddontang](https://x.com/siddontang)
- [1.7K](https://x.com/starzq/status/2076478025877909675/analytics)
- [https://www.xiaoyuzhoufm.com/episode/6a53331f4adef2b365629cb3](https://www.xiaoyuzhoufm.com/episode/6a53331f4adef2b365629cb3)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:27 AM · Jul 13, 2026](https://x.com/starzq/status/2076478556734206365)
- [3,707 Views](https://x.com/starzq/status/2076478556734206365/analytics)
- [View quotes](https://x.com/starzq/status/2076478556734206365/quotes)
---
*导出时间: 2026/7/13 14:21:48*