Kimi K2.6背后的Agent Database：Agent-native 时代的数据Infra竞争，跟过去30年有何不同¶

📊 Level ⭐⭐⭐ | 11.9KB

背景¶

黄东旭前几篇文章（如何做 AI Agent 喜欢的基础软件、当我们在谈论 Agent Infra 时我们在谈论什么）提出了一些猜想，本文是这些理论的大规模落地验证——TiDB Cloud 正式成为 Kimi K2.6 的供应商，为 Kimi Agent 建站服务提供动态大规模的 Agent Database 支持。

Kimi K2.6 Agent 建站场景¶

最典型的 End-to-End 在线应用构建场景：Agent 帮助人类生成代码，形成真实可用的在线服务，用户无需任何技术背景。与 Loveable 等其他 AI 建站应用的区别：Kimi K2.6 从前端到后端完全接管/托管。核心挑战：不在于代码生成，而在于 hosting 的成本。

为什么 hosting 成本是关键¶

受众变大（无技术门槛）→ 用户量激增
大多数 AI 模板服务按月订阅，重度 Token 消耗用户的算力成本往往超过订阅费
但网站托管/一次性生成代码并持续在线服务的场景：算力消耗集中在创建那几下，服务运行后按月收费，基础设施成本（Web 服务器、带宽、数据库）利润空间更大主要挑战：一周内可能上千万个站点被创建出来，按传统云服务或数据库定价，为每个网站提供一个真实 Postgres/RDS 实例 → 成本爆炸。

为什么选 TiDB 而不是 NeonDB/Supabase¶

Supabase 模式问题：每个 Agent 配一个 Supabase PostgreSQL，上百万个实例 → 成本直接爆炸。 PostgreSQL 多 Schema 隔离问题：单个实例在万级规模时扛不住，更不用说流控、故障半径控制和数据隔离。核心原因：成本。Agent-native 场景需要完全不同的架构思路。

Agent-native 时代的数据 Infra 竞争逻辑¶

过去 30 年：比单点性能（谁的 TPS 高、谁的延迟低、谁支持更大的单库容量）。现在比的是当以下四件事同时发生时，谁能提供最顺畅的体验： 1. 海量长尾租户：尽管请求量不大，但全都要求在线 2. LLM 即席改 Schema：必须支持分支和多版本 3. 无法预测的突发流量 4. AI 在秒级别随时动态创建/销毁，以及动态生成访问的 SQL 这是完全不一样的赛道。

三个核心战略决策¶

1. 最小化 Agent 使用 Infra 工具时的摩擦¶

每个任务和站点独立隔离，由 Agent 创建和使用，用的时候能秒级创建。 TiDB Cloud 的 Warm Pool + Scale-To-Zero，让 Agent 在 1 秒内拿到 fully prepared 的数据库实例。如果数据库 provisioning 占去几分钟，Agent 就得在自己代码里写 retry/poll/wait → 这个负担不该由 Agent 来扛。

2. 对 Agent 生成服务所使用的技术栈尽可能统一¶

人类工程师觉得方便，对 LLM 来说直接关系到生成代码的成功率。少跨一个系统就少一类 bug，多用 Skill 中写好的技术栈和最佳实践，而不是每次靠思考和抽卡，大大提升了生成代码变成服务的稳定性。

3. 极致的低成本¶

放弃 Supabase 和 Neon 那样的真实数据库实例分配和管理，TiDB 引入了一层虚拟数据库界面。大量请求是长尾的——没有请求时，不需要真实分配数据库实例，只需让 Agent/终端用户"假装"后端是一个独立数据库。最极端情况下，整个平台只需要一个常驻的 DB Session Gateway 服务维持数据库连接，其他所有资源都可以变成弹性的。物理层面：数据由底层封装了对象存储的分布式 KV 数据库提供存储服务，逻辑层面自动处理数据可见性隔离和冷热分离。 Agent 层面不会有实例被回收、休眠或连接中断等不好的体验。效果：整个数据库平台的弹性能力提升一个台阶，数据使用成本数量级规模下降。

传统 Serverless vs TiDB Cloud 架构对比¶

传统 Serverless 数据库（面对 Agent 场景）：

每个 Sandbox 分配一个真实数据库实例
冷却时被回收，难保证 7×24 永远在线
数量大了成本难控制（想象几千万个 Supabase 实例） TiDB Cloud 架构： See also Agent Harness Architecture
无真实数据库实例，一切都是虚拟的
对 Sandbox 中的 Agent 来说，仍然拥有一个个完整的独立数据库
底层大型分布式 KV 数据库逻辑层面自动处理隔离和冷热分离
Agent 体验：无回收、无休眠、无连接中断

行业收敛：one agent, one sandbox, one storage, one database¶

过去 12 个月陪跑国内外很多 AI Agent 团队基建选型后发现：

以前模式：一个产品扛亿级用户，一个 app 扛亿级会话
现在模式：一个用户身边可能有 10 个甚至 100 个 Agent 在跑，每个都需要自己的状态和数据包括 Kimi 在内的 AI Agent 商业化团队采用的架构都收敛到同一个范式：

one agent, one sandbox，one storage，one database

上半场 vs 下半场¶

上半场：谁的模型更聪明、谁的 Agent 推理更长。 下半场：竞争的核心是——Agent 交付出来的结果，在真实用户面前能不能稳定跑起来、持续交付。 Kimi 和 TiDB 的合作是模型厂商通过好的基础设施服务、快速高效提供更多价值的绝佳例子。

深度分析¶

黄东旭这篇文章揭示了 Agent-native 时代基础设施竞争的根本逻辑转变：从"单点性能竞争"到"海量长尾租户的服务连续性竞争"。 核心洞察一：hosting 成本是 Agent 建站场景的决定性瓶颈。Kimi K2.6 的建站场景与传统 SaaS 完全不同——用户无技术背景、创建频率极高（周级千万站点）、每个站点都需要独立的数据库实例但运行时长不确定。传统云数据库的"一个站点一个实例"模式在成本模型上完全不可行。 核心洞察二：虚拟数据库界面是架构关键创新。TiDB 没有试图优化单实例性能或增强多租户隔离，而是在逻辑层面引入"虚拟数据库"抽象，让 Agent 以为自己在用一个独立数据库，实际上底层是共享的分布式 KV 存储。这本质上是一个软件定义的数据层，通过逻辑隔离代替物理隔离，实现了成本数量级的下降。 核心洞察三："one agent, one sandbox, one storage, one database"正在成为行业标准范式。这与传统的"一个产品服务亿级用户"模式形成鲜明对比——Agent 时代的计算单元从"产品/应用"变成了"Agent + 配套的数据空间"。这意味着基础设施提供商需要重新思考他们的多租户模型、资源调度和计费模式。 核心洞察四：上半场（模型能力）和下半场（Infra 稳定性）的竞争维度不同。模型能力可以用 Scaling Laws 预测，但 Agent 交付结果的稳定性取决于 Infra——这篇文章实际上在说：下半场的基础设施竞争，才刚刚开始，而传统的数据库厂商（PingCAP）反而可能比纯云厂商更有优势，因为他们的分布式架构更容易演进到 Agent-native 场景。

实践启示¶

Agent-native 场景需要重新设计数据 Infra：如果你正在构建 Agent 应用或平台，需要从一开始就假设每个 Agent（或每个用户- Agent 组合）需要独立的存储空间，而不是共享数据库。传统的多租户方案在租户规模上达不到 Agent 场景的要求。
关注"虚拟化"而非"物理隔离"：成本问题的解决思路是让 Agent 获得独立数据库的体验，而不必真正为每个 Agent 分配独立实例。软件定义的存储抽象（虚拟数据库界面）是关键技术。
技术栈统一对 LLM 生成代码成功率有直接影响：在 Agent 应用中，尽量减少技术栈的多样性。使用的技术栈越标准、越少，LLM 生成代码的错误率越低，工具调用的一致性越高。
1 秒级资源准备是 Agent 体验的关键：如果 Agent 需要等待几分钟才能获得数据库实例，它就不得不在自己的代码里实现复杂的 retry/poll/wait 逻辑——这本质上是在让 Agent 做 Infra 应该做的事情。好的 Agent-native Infra 应该让 Agent "拿到资源就像已经准备好了一样"。
基础设施竞争正在从"性能"转向"弹性"：在评估 Agent 场景的 Infra 方案时，不要只看 TPS 和延迟，要看：当百万级长尾租户同时在线、LLM 随时改 Schema、流量完全不可预测、Agent 秒级创建销毁时，系统还能不能保持稳定服务。这才是 Agent-native 时代的核心竞争维度。

来源：InfoQ 黄东旭（PingCAP/TiDB） https://mp.weixin.qq.com/s/XLYWhkjFHxrH2-jb5O1qCQ

关联¶

相关概念: Harness Engineering
相关: Agent 架构