如果你最近在Kimi K2.6的Agent模式里敲下“帮我搭个读书笔记网站，带登录和搜索，能导出的那种”，5分钟后你拿到的不是一个Demo，而是一个真实可访问的URL。前端、后端、独立数据库、用户账号体系全套齐备。你可以直接把链接甩给朋友，他注册后存入的数据，会稳稳地停留在你这套系统的独立数据库里。比起v0或Lovable这些AI建站工具，Kimi实际上接管了用户从开发到托管、再到数据库运维的全生命周期。

但这种体验背后的工程挑战才刚刚开始：如果有100万个用户随口说了这句话，后台就要瞬间承载100万个独立的生产级数据库，每个都被真实用户长期读写。传统数据库的产品形态几乎无法承接这种负载。Kimi工程团队拆解出了三条刺眼的约束：第一，数据库实例的粒度是“每终端用户一个”，十万用户就是十万个数据库，按传统云数据库每月十几到二十美元的价格，百万用户的账单是天文数字；第二，数据库的schema是LLM现场生成的，用户随时可能要求“加个收藏功能”，Agent又要动一次表结构，而数据库里已有真实数据，schema改错可能导致数据不可恢复；第三，负载分布是“零-峰两极”，大多数站建完就闲置，但只要一个站被社交媒体推荐，瞬间并发可以跳到百倍以上，爆量租户不能拖垮其他租户。

传统方案都走不通：路径A是单实例加schema隔离，几百个租户还行，几万个直接打爆查询规划器，爆款站会连累所有邻居；路径B是一个用户一个RDS实例，百万级租户时单是实例存在的基础月费就已不可接受。Kimi后端最终落在了TiDB Cloud上，做了三个关键决策。首先，用Serverless Cluster的多租户能力承接“每个用户一个独立数据库”，引入一层“虚拟数据库界面”，长尾的、绝大多数时间没请求的租户并不真实分配数据库实例，只在Agent或终端用户实际发起请求的瞬间，由一个常驻的DB Session Gateway维持数据库连接，其他资源全部走弹性供给。这使得“百万用户的建站后端”在单位经济上跑得通。

其次，Kimi统一了技术栈，用vector加SQL加JSON把Agent的“写代码”难度压下来。LLM写出的典型查询经常在一条SQL里同时做多件事，比如按用户过滤、按标签筛选JSON字段，这种混合查询在传统数据库里需要复杂的join和索引优化，而在TiDB Cloud里可以原生支持。最后，针对零-峰两极的负载，TiDB Cloud的弹性扩容机制确保爆量租户不会拖垮其他租户，每个租户的资源隔离在虚拟数据库层面完成。这套架构让Kimi K2.6在AI建站这个场景里，实现了“人手一个数据库”的奢侈配置。对于AI从业者来说，这不仅是技术选型的案例，更意味着AI基建正在从算力层向数据层进化，未来的Agent应用将需要更灵活、更经济的数据库基础设施来支撑海量个性化需求。