如果你最近在 Kimi K2.6 的 Agent 模式里尝试搭建一个读书笔记网站，你会发现它不再仅仅是给出 Python 代码或静态 Demo，而是一个包含前端、后端、独立数据库和用户账号体系的真实可访问 URL。这意味着 Kimi 实际上接管了从开发到托管，再到数据库运维的全生命周期。然而，这种体验背后隐藏着巨大的工程挑战：如果有 100 万个用户同时发出指令，后台必须瞬间承载 100 万个独立的生产级数据库，这在传统数据库架构下几乎是无法实现的。
AI 建站场景对数据库有三个极端要求。首先是极细的实例粒度，必须做到“每终端用户一个数据库”，但在传统云数据库定价模型下，百万级实例的成本是天文数字。其次是 Schema（数据库模式）由 LLM 现场生成且频繁变动，Agent 随时可能根据用户需求增加字段，这对数据一致性和查询稳定性提出了极高要求。最后是“零-峰两极”的负载分布，大多数站点长期闲置，但一旦走红则面临百倍并发跳增，数据库必须具备极强的弹性且能实现租户隔离。
针对这些挑战，Kimi 最终选择了 TiDB Cloud，并做出了三个核心技术决策。决策一：利用 Serverless Cluster 的多租户能力实现极致低成本。TiDB Cloud 引入了“虚拟数据库界面”层，长尾租户不分配真实实例，仅在请求瞬间由 Gateway 维持连接并弹性分配资源，从而让百万级建站的单位经济模型跑通。相比 Supabase 等为每个租户分配真实 PostgreSQL 实例的方案，TiDB 的多租户架构在成本控制上更具优势。
决策二：通过统一技术栈（Vector + SQL + JSON）降低 Agent 生成代码的难度。在 Kimi 的场景中，Agent 需要在一条 SQL 中同时处理用户过滤、JSON 字段筛选和向量相似度排序。TiDB 的全能型栈避免了 LLM 需要协调多个客户端和处理复杂事务合并的问题，显著提升了代码生成的准确率。决策三：利用 Warm Pool 和 Scale-to-zero 技术，让 Agent 能在 1 秒内获取准备就绪的数据库实例。通过预热池分配实例而非走完整的 Provisioning 链路，确保了 AI 生成应用时的丝滑体验。
这不仅仅是 Kimi 的孤立选择。数据显示，目前 TiDB Cloud 上超过 90% 的新集群是由 AI Agent 直接创建的，而非人类工程师。这一趋势表明，在 AI Agent 时代，数据库正在从一种笨重的底层设施演变为一种随调随用的弹性资源。
