Agent时代的数据库，怎么跑通商业化？
AI快讯网 |
当AI Agent开始直接为终端用户创建应用，数据库的消费模式正在发生根本性变革。传统云数据库按实例计费，每个最小实例月费十几美元，百万用户就是千万美元账单——这显然不是可持续的商业模型。Kimi K2.6的“读书笔记网站”看似简单，背后却是对数据库架构的极致考验。
“帮我搭个读书笔记网站，带登录和搜索，能导出的那种。”
用户在Kimi K2.6里随口说出这句话，得到的不是一个原型截图或代码片段，而是一个真实可访问的URL。
比起v0或Lovable这些AI建站工具，Kimi实际上接管了用户从开发到托管、再到数据库运维的全生命周期。
但这种体验背后，真正的工程算力挑战才刚刚开始：如果有100万个用户随口说了这句话，就意味着后台要瞬间承载100万个独立的生产级数据库——被真实用户长期读写。
在传统数据库的产品形态下，这种工作负载量几乎无法被承接。那么Kimi究竟是如何在成本、规模与性能的“不可能三角”中，实现这种“人手一个数据库”的奢侈配置？
三条刺眼的技术约束
AI建站这一类场景，对模型厂商来说有一个基本的经济结构：算力消耗集中在Agent生成代码的那几下，服务上线后是按月收订阅费。一旦运行起来，托管的基础设施成本（Web服务器、带宽、数据库）相对算力成本要低得多，厂商的利润空间主要靠这一部分。但这套商业模式有一个前提：基础设施成本必须能压得下来。
把Kimi K2.6这个场景的工程约束拆解开，有三条特别刺眼的要求。
第一条：数据库实例的粒度是“每终端用户一个”。十万用户就是十万个数据库，一百万个用户就是一百万个。而且绝大多数实例会长期处于极低活跃，用户建完一个站之后可能很久不再打开。按传统云数据库的定价模型，一个最小实例大约每月十几到二十美元，乘以百万，账单天文数字。问题不是数据库贵，而是商业模型无法规模化。
第二条：数据库的Schema是LLM现场生成的。过去二十年，Schema设计是一个需要DBA、需要review、需要版本管理的慢决策流程。在Kimi K2.6这里，Schema是LLM对用户一句自然语言的翻译——例如“读书笔记需要什么字段？”“评分存整数还是文本？”瞬间就能决定。更棘手的问题是，用户会继续对话。下一次用户说“帮我加一个收藏功能”，Agent又要动一次表结构。这时候数据库里已经有了真实用户数据。Schema一旦改错，轻则查询失败、用户报错，重则写入紊乱、数据不可恢复。
第三条：负载分布是“零-峰两极”。大多数站建完就闲置，但只要有一个站被小红书推荐、被X平台热转，瞬间并发可以跳到百倍以上。所以数据库必须同时扛住“绝大多数近乎零、少数瞬间爆量”的极端曲线，而且要做到爆量租户不能拖垮其他所有租户。
这三条合在一起，在传统数据库的产品形态下几乎是做不出来的：
- 路径A：单实例+Schema隔离。几百个租户行，几万个直接打爆查询规划器。爆款站还会连累所有邻居。Kimi工程团队实际测过这条路：用一个大型PostgreSQL实例做多Schema隔离，单实例在万级规模时就开始扛不住，更不用说复杂的流控、故障半径控制、数据隔离这些更深一层的问题。
- 路径B：一个用户一个RDS实例。不管是RDS还是Neon/Supabase这种Serverless PG包装，本质都是为每个用户分配一个真实的PostgreSQL实例。到百万级租户，单是实例存在的基础月费就已不可接受。
TiDB Cloud的解法：三个关键决策
Kimi后端最终落在了TiDB Cloud上。工程团队做了三个关键决策，每一个都对应解决上面三条约束中的一条。
决策一：极致低成本——用Serverless Cluster的多租户能力，承接“每个用户一个独立数据库”。既然问题出在“每用户一个真实实例”，TiDB Cloud在这层走了另一条路：引入一层“虚拟数据库界面”。长尾的、绝大多数时间没请求的租户，平台并不真实分配数据库实例；只在Agent/终端用户实际发起请求的瞬间，由一个常驻的DB Session Gateway维持数据库连接，其他资源全部走弹性供给。落到Kimi K2.6的场景里，这意味着“百万用户的建站后端”在单位经济上跑得通。
为了更直观地呈现这种技术代差，我们将这一架构与以Supabase为代表的典型Serverless数据库进行了对比：传统方案中每个租户对应一个独立PostgreSQL实例，资源固定且成本线性增长；而TiDB的多租户方案中，所有虚拟数据库共享计算池，仅在请求时分配资源，空闲时scale-to-zero。实际测试表明，在同等100万租户规模下，TiDB Cloud的基础设施成本仅为传统Serverless方案的10%左右。
下面是TiDB Cloud的多租户架构示意图：
决策二：统一技术栈——Vector+SQL+JSON把Agent的“写代码”难度压下来。Kimi K2.6建站Agent里，LLM写出来的典型查询经常在一条SQL里同时做多件事——按用户过滤、按标签筛选（JSON字段）、按向量相似度排序、按时间倒序。在分离的栈里，同样的需求要LLM协调三个客户端、自己做事务、自己做结果合并……这在LLM写代码的场景下，错误率会指数级叠加。而在TiDB里，这是一条SQL。统一栈在这里的价值不是“性能更好”，而是让Agent有机会把代码写对的前提条件。
决策三：最小化摩擦——Warm Pool+Scale-to-Zero让Agent在1秒内拿到完全准备好的数据库实例。Agent生成应用时，数据库的创建不能是一个需要等待几分钟的provisioning流程。TiDB Cloud通过Warm Pool预先维护一批已经完成底层准备的Starter实例。Kimi需要新实例时，不再走完整创建链路，而是直接从预热池中分配；再叠加Starter的Scale-to-Zero能力，闲置实例的计算成本可以压到很低。这让一用户一实例不仅在隔离和成本上成立，也在体验上成立——Agent可以在1秒内拿到fully prepared instance，继续生成Schema、写入数据、启动应用，而不需要把等待、轮询、失败重试写进自己的代码。
行业曲线的聚合信号
Kimi K2.6的这次选型，如果是孤立事件，只是一则产品新闻。但放在更大的坐标系里看，它是一条正在形成的行业曲线上的一个点。一个平台侧的数据可以先交代：今天在TiDB Cloud上新建的集群里，超过90%是由AI Agent直接创建的，而不是由人类工程师创建的。这个比例一年前还远没有这么高。
数字背后是一批AI Agent团队在各自做完基建选型后，不约而同地走向了同一类架构。几个关键数据点值得放在一起看：
- 去年，某全球知名AI Agent平台选择TiDB作为其核心数据层，并在其技术博客和开发者社区公开了架构细节，当时讲的是“Agent用数据库作为工作台”。
- 更早，Dify这家做LLMOps的低代码平台公司，过去为每个开发者租户分配独立数据库容器，规模做到一定程度后扛不住运维，最终把所有租户合并到一套TiDB Cloud上：基础设施成本降80%、运维负担降90%。
△来自Dify官网- 今年，Kimi K2.6把TiDB用到了更复杂的场景——Agent直接向终端用户交付数据库驱动的完整应用。
几个团队各自做完工程评估，得到的答案差不多。这种聚合本身就是一种行业信号，通常意味着底层工程约束已经稳定到一定程度。
从“用户”到“Agent”：计算单位的代际跃迁
把视角再拉远一层，每一代AI基础设施其实对应着一种新的“计算单位”。Web时代是用户，一个产品要扛几亿人同时来。移动时代是会话，一个App要扛几亿个并发会话。Agent时代是Agent自己，每个真实用户身边可能有10个、100个独立运行的Agent实例，每个都要有自己的状态、记忆、数据。
△图片由AI生成Agent在跑起来时需要的不仅仅是数据库，还需要一个独立的sandbox来执行代码、一份独立的storage来存它的工作产物。One agent, one sandbox; one storage, one database，这套“每个Agent一份独立运行环境”的架构，正在成为Agent原生应用唯一可行的假设。Kimi、Dify、Plaud以及全球各地不断涌现的Agent团队，都不约而同地做出了相同的判断。
地基之战刚刚开始
新的默认标准正在形成。过去一年，TiDB的产品演进，正是在将这些共识逐一落实到具体产品中。Kimi等团队的选型，正是这一趋势的独立验证。当然，TiDB团队的目标远不止数据库这一层。
△图片由AI生成Agent作为新一代应用的核心计算单位，它需要的不只是一个数据库，还需要持久化工作产物的Storage、维持跨session上下文的Memory层，未来还会有更多组件。TiDB正在沿着这条线，为Agent这一代应用补齐一整套通用的运行时基础设施：
- mem9：是这条线上已经落地的第一个组件。Agent每次重启不应该从零开始，mem9为Agent提供持久、跨session可检索的Memory层。
- drive9：是第二个组件，Agent的sandbox可以随时创建和销毁，但工作成果不能跟着消失。drive9为Agent Sandbox提供持久、共享、可挂载的workspace。
后续还会有更多组件落地。Agent-native应用的标准运行时，正在一块一块成型。
AI应用的上半场比模型，下半场比地基。当Agent进入“为终端用户交付应用”的阶段，模型能力本身已经不是决定胜负的唯一变量。能不能选对一套数据底座，让交付出去的东西在真实用户面前稳定跑起来，正在变成模型厂商的核心运营能力。
从Web到移动再到Agent，计算单位的变化驱动着基础设施的演进。谁能率先构建起适配Agent原生应用的运行时底座，谁就能在下半场的竞争中占据先机。TiDB正在沿着这条路径布局，但挑战依然存在——如何在极致弹性与数据一致性之间取得平衡，如何让Agent安全地操作数据库Schema，这些都是需要持续攻克的难题。但至少，Kimi的实践已经证明了这条技术路线在商业上的可行性。
