TiDB Cloud 正式成为 Kimi K2.6 的提供商，支持 Kimi Agent 网站部署服务的动态大规模数据库 provisioning。TiDB 创始人唐刘（siddontang）发文解析了这背后的工程权衡——不是 TiDB 广告，是 Agent 原生数据库的架构命题。
Agent 场景对数据库的四个全新挑战
从一个简单例子开始：用户告诉 Kimi K2.6 Agent Mode "给我建一个读书笔记网站"。几分钟后，一个包含登录、数据库、搜索和外部访问的 web 应用上线。
用户看到"cool"，数据库工程师的第一反应是：后端正在做数据库系统从未系统化处理过的事情。
挑战一：租户数量爆炸
传统 SaaS 世界，租户增长由销售驱动——每年几百个客户，增长曲线缓慢且可预测。Agent 建站场景中，一个 viral 产品可以在一周内创建数十万个独立租户。
数据库控制平面不再处理人类操作请求，而是处理来自 Agent 的 API 调用。QPS 可以跳升几个数量级。
挑战二：Schema 不可控
过去 schema 由人类设计，设计后很少变更。现在 schema 由 LLM 在对话中生成。用户多问一个问题，Agent 可能再次修改表结构。
数据库依赖了几十年的假设——稳定 schema、预计算计划、预热缓存——被悄然移除。
挑战三：Workload 分布极端
99% 的租户长期零 QPS。1% 的租户可能突然跳到极高流量。
不能按平均负载 provision，峰值会杀死你。也不能按峰值 provision，成本会杀死你。
这是系统设计中最烦人的那种「显然」：两个简单答案都是错的。
挑战四：数据库用户从人类变成 Agent
人类开发者遇到错误会读文档、查日志、debug。Agent 遇到错误经常重试、绕路或直接放弃。更糟的是，它们的错误可能被放大到数千甚至数百万终端用户。
单独看，这些问题都不是全新的。但 Kimi K2.6 这样的场景同时把它们推到了极限。
从零设计 Agent 原生数据库
抛开 TiDB，如果今天从零为 Agent 设计数据库，唐刘提出四个基本问题：
1. 多租户
不是旧意义上的「把每个租户放进一个大数据库做逻辑隔离」。一旦扩展到数万甚至数十万租户，metadata、连接、权限、生命周期管理、隔离全部成为瓶颈。
直觉是：系统应该从第一天就假设自己由 N 个轻量级逻辑实例组成。每个实例在控制平面层有独立的调度、计量和生命周期管理；在数据平面层，资源池化、按需分配。
这不是把单租户系统 patch 成多租户。如果第一天方向错了，未来大部分工作会变成打补丁。
2. Scale-to-zero
真正的 zero，不是「实例在睡觉但你还在付费」的那种假 zero。
关键架构判断：计算和存储必须完全解耦。存储常驻，数据永远在那里。计算按需启动，空闲时资源归零。
没有这种解耦，"scale-to-zero" 最多是定时关机。那不是 scale-to-zero，是批处理 job 戴了云原生的帽子。
3. 统一技术栈
这一点经常被低估。
如果让 Agent 同时操作 Pinecone + Postgres + MongoDB，它大概能生成代码。但错误率显然比单一数据库 + 单一 SQL 接口高。
对 LLM 来说逻辑简单：少一层抽象就少一类 bug。
把向量搜索、关系查询、JSON、AP 分析放在同一个 SQL 接口后面，不仅是性能问题，也是可靠性问题。Agent 最怕的不是慢一点，是系统边界太多——错误发生在边界上，难以 debug。
4. 计费
Agent 写的查询差异巨大。有的便宜到只是点查，有的是跨全表的 analytic scan。
如果计费基于「实例 × 时间」，很难把成本分配到实际产生成本的终端用户。
更合理的模型是按语句、按请求或按 RU 计量。每个 Agent 动作应该映射到一个成本。否则商业模式很容易变成：用户开心，平台流血。
为什么 Kimi 选择 TiDB
按上述要求推导，Agent 原生数据库的轮廓已经清晰。Kimi 的技术选型变成匹配问题：市场上谁能同时满足所有这些约束？
最终落在 TiDB Cloud 上，大致三个原因：
第一，多租户是原生设计，不是后期 bolt on。
每个集群是独立逻辑实例。控制平面层有生命周期管理、配额和计量。数据平面层资源池化和调度。数万集群不是系统的特殊项目，是正常运营模式。
第二，scale-to-zero 是真实的，不只是营销语言。
计算存储分离 + 对象存储架构，空闲租户计算资源可降至零，数据保持可用，存储成本足够低。冷启动可控制在用户可接受范围内——这对 Agent 场景至关重要。
第三，Agent 能快速获得 ready-to-use 数据库。
TiDB Cloud 维护预预热实例池。Kimi 需要新实例时不必走完整创建路径，可直接从池中分配准备好的实例。结合 scale-to-zero，空闲成本也可控。
这很重要，因为Agent 不应该被迫写自己的重试、轮询和等待逻辑。这个负担本来就不该推给 Agent。
加上 TiDB 的统一栈（SQL + 向量 + JSON + HTAP）和 RU-based 计费，前面的约束基本对齐。
Kimi 选择 TiDB 不是因为某个 benchmark 数字最快。是因为这个场景中没有一个约束可以失败，而 TiDB Cloud 对每个约束都有可执行的答案。
单点最优性在这里不那么重要。约束完整性更重要。
三个工程细节
细节 1：每租户集群的 metadata 压力
很多人的第一反应："数万个集群——控制平面 metadata 扛得住吗？"
答案有趣：TiDB 内部有大量处理大规模 metadata 和生命周期管理的经验，所以扩展控制平面不是全新问题。这是 dogfooding——Serverless 控制平面本身就在运行大规模、多租户、高频生命周期管理 workload。用自己的产品支持自己的产品听起来自然，实际踩了不少雷。
细节 2：向量索引和 TP workload 的隔离
Agent 场景中，向量检索和 TP 事务经常出现在同一条 SQL 语句中。
TiDB 的做法是把向量索引作为特殊列索引，与行数据共存于同一副本。查询执行时用专用 operator pipeline，避免 ANN 搜索拖慢 TP 路径。
这可能不是学术上最纯粹的设计，但实用。工程经常如此：架构纯度不如确保 Agent 能写一条 SQL 并正确运行重要。
细节 3：Agent 发起调用的可观测性
当 90% 以上的 DDL 和 DML 由 Agent 发起时，传统按人、应用或 SQL 文本审计不再足够。
Kimi 和 TiDB 建立了按 Agent session 聚合的观测视图。不问"这个人做了什么"，而是问"一次 Agent 对话中发生了哪些数据库动作、哪些成功、哪些失败、成本去了哪里"。
唐刘认为这将成为 Agent 原生数据库的标准能力。否则出问题时就只能看到一堆 SQL，看不到背后的意图链。
未解决的问题
Agent 原生数据库还有很多未解问题：
跨租户资源竞争：一个 viral 租户突然 spike，如何控制它对同区域其他租户的影响？硬配额提供安全网，但太严格伤害弹性，太宽松无法防止级联故障。
统一结构化与非结构化数据：目前主要解决结构化和半结构化（SQL、JSON、向量）。但 Agent 越来越多需要处理文档、图片、音频、视频，还需要跨结构化记录、向量和文件一起查询。统一存储和查询语义是下一个必须回答的问题。
更大的命题
许多传统数据库设计围绕「人类开发者写代码」的假设构建。现在调用者正在变成 Agent。
错误处理、权限模型、可观测性、计费、schema 演进——全部需要重新审视。
这不是 TiDB 单独需要回答的问题。数据库、Agent 框架和云平台都会被这个变化推动。
唐刘做了十多年数据库。这些年数据库的基本设计逻辑没变化太多次：OLTP、OLAP、HTAP、Cloud Native。每一波都是前一波的延伸。
但 Agent-native 感觉不同。它不是简单问「如何让数据库更快更便宜」——这些问题已经回答了很多年。
真正的问题是：当数据库的主要用户不再是人类，而是 Agent 时，旧的设计假设还成立吗？
答案不会来自用 Agent-friendly API 包装旧系统。那是止痛药，不是新架构。
需要从第一性原理重新思考。