人手一个数据库！Kimi K2.6 背后 TiDB Cloud 如何打破成本、规模与性能的“不可能三角”

导语：Kimi K2.6 让用户一句话生成完整网站，背后是百万独立数据库的挑战。TiDB Cloud 的架构选择如何实现低成本、高扩展和实时体验？

一句话建站，数据库全员独立

“帮我搭个读书笔记网站，带登录和搜索，能导出的那种。”如果你最近在 Kimi K2.6 的 Agent 模式下敲下这句话，5 分钟后你得到的将不再是需要自行调试的 Python 代码，也不是一个只能看不能用的静态 Demo，而是一个真实可访问的 URL。前端、后端、独立数据库、用户账号体系……全套齐备。你可以直接把链接分享给朋友，他注册后存入的数据，会稳稳地停留在你这套系统的独立数据库里。

然而，这种丝滑体验背后藏着真正的工程算力挑战：如果有 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 实例；到百万级租户，单是实例存在的基础月费就已不可接受。

Kimi 的选择，以及为什么是这个选择

Kimi 后端最终落在了 TiDB Cloud 上。工程团队做了三个关键决策，每一个都对应解决上面三条约束中的一条。

决策一：极致低成本——用 Serverless Cluster 的多租户能力承接“每个用户一个独立数据库”

既然问题出在“每用户一个真实实例”，TiDB Cloud 在这层走了另一条路：引入一层“虚拟数据库界面”。长尾的、绝大多数时间没请求的租户，平台并不真实分配数据库实例；只在 Agent/终端用户实际发起请求的瞬间，由一个常驻的 DB Session Gateway 维持数据库连接，其他资源全部走弹性供给。落到 Kimi K2.6 的场景里，这意味着“百万用户的建站后端”在单位经济上跑得通。

（上图为 TiDB Cloud 多租户架构示意）

决策二：统一技术栈——vector+SQL+JSON 把 Agent 的“写代码”难度压下来

Kimi K2.6 建站 Agent 里，LLM 写出来的典型查询经常在一条 SQL 里同时做多件事——按用户过滤、按标签筛选（JSON 字段）、按向量相似度排序、按时间倒序。在分离的技术栈里，同样的需求要 LLM 协调三个 client、自己做事务、自己做结果合并……这在 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 一家的选择

Kimi K2.6 的这次选型，如果是孤立事件，只是一则产品新闻。但放在更大的坐标系里看，它是一条正在形成的行业曲线上的一个点。一个平台侧的数据可以先交代：今天在 TiDB Cloud 上新建的集群里，超过 90% 是由 AI Agent 直接创建的，而不是由人类工程师创建。这个比例一年前还远没有这么高。数字背后是一批 AI Agent 团队在各自做完基建选型后，不约而同地走向了同一类架构。

去年，某全球知名 AI Agent 平台选择 TiDB 作为其核心数据层，并在其技术博客和开发者社区公开了架构细节，当时讲的是“Agent 用数据库作为工作台”。更早，Dify 这家做 LLMOps 的低代码平台公司，过去为每个开发者租户分配独立数据库容器，规模做到一定程度后扛不住运维，最终把所有租户合并到一套 TiDB Cloud 上：基础设施成本降 80%、运维负担降 90%。

今年，Kimi K2.6 把 TiDB 用到了更复杂的场景——Agent 直接向终端用户交付数据库驱动的完整应用。几个团队各自做完工程评估，得到的答案差不多。这种聚合本身就是一种行业信号，通常意味着底层工程约束已经稳定到一定程度。

把视角再拉远一层，每一代 AI 基础设施其实对应着一种新的“计算单位”。Web 时代是用户，一个产品要扛几亿人同时来；移动时代是会话，一个 App 要扛几亿个并发会话；Agent 时代是 Agent 自己，每个真实用户身边可能有 10 个、100 个独立运行的 Agent 实例，每个都要有自己的状态、记忆、数据。Agent 在跑起来时需要的不仅仅是数据库，还需要一个独立的 sandbox 来执行代码、一份独立的 storage 来存它的工作产物。One agent, one sandbox; one storage, one database，这套“每个 Agent 一份独立运行环境”的架构，正在成为 Agent 原生应用唯一可行的假设。Kimi、Dify、Plaud 以及全球各地不断涌现的 Agent 团队，都不约而同地做出了相同的判断。新的默认标准正在形成。过去一年，TiDB 的产品演进，正是在将这些共识逐一落实到具体产品中。

TiDB 团队的目标，远不止数据库这一层。Agent 作为新一代应用的核心计算单位，它需要的不只是一个数据库，还需要持久化工作产物的 storage、维持跨 session 上下文的 memory 层，未来还会有更多组件。TiDB 正在沿着这条线，为 Agent 这一代应用补齐一整套通用的运行时基础设施。