Agent Infra 实践复盘：Kimi 如何搭建 Agent 背后的 Database 服务

📌 一句话摘要

PingCAP CTO 黄东旭复盘了 TiDB Cloud 为 Kimi K2.6 Agent 建站服务提供数据库支持的实践，揭示了 Agent 时代数据基础设施的核心挑战与架构选择。

📝 详细摘要

本文由 PingCAP 联合创始人兼 CTO 黄东旭撰写，复盘了 TiDB Cloud 成为 Kimi K2.6 Agent 建站服务数据库供应商的合作细节。文章首先指出 Agent 下半场的竞争核心在于稳定、持续地交付服务，而非模型能力本身。Kimi K2.6 面向大众用户，提供从代码生成到在线托管的全流程服务，其核心挑战在于海量长尾租户下的基础设施成本。文章对比了传统 Serverless 数据库（如 Supabase、Neon）与 TiDB Cloud 的架构差异：前者为每个 Agent 分配真实数据库实例，成本随规模线性增长；后者通过虚拟数据库层和底层分布式 KV 存储，实现极致的弹性与成本控制。文章总结了三个核心战略决策：最小化 Agent 使用 Infra 工具的摩擦（秒级创建）、统一技术栈以提升生成代码的成功率、以及通过架构创新实现极致的低成本。最后，作者指出「one agent， one sandbox， one storage， one database」已成为 AI Agent 团队的通用范式。

💡 主要观点

1. Agent 下半场的竞争核心是稳定、持续地交付服务，而非模型能力。 当模型能力趋同，Agent 能否将生成的结果稳定地跑起来，并持续为用户提供服务，成为决定商业成功的关键。Kimi K2.6 的案例证明了这一点。
2. 面向大众用户的 Agent 服务，核心挑战在于海量长尾租户下的基础设施成本。 Kimi K2.6 面向无技术背景用户，用户规模巨大。每个用户生成的站点都需要独立的数据库，若采用传统方案，成本将随租户数量线性增长，无法商业化。
3. TiDB Cloud 通过虚拟数据库层和底层分布式 KV 存储，实现了极致的弹性与成本控制。 与传统 Serverless 数据库为每个租户分配真实实例不同，TiDB Cloud 引入虚拟数据库界面，底层由统一的分布式 KV 存储支撑，实现了秒级创建、按需弹性、冷热分离，大幅降低成本。
4. Agent 时代的数据基础设施需要同时满足多租隔离、统一技术栈和即时弹性。 Kimi 选择 TiDB 的核心原因在于其在「per-tenant 多租隔离、统一栈、即时弹性」这三件事上同时做到位，而非追求单一指标的极致。

💬 文章金句

• Agent 下半场的竞争核心是：Agent 交付出来的东西和结果，在真实用户面前能不能稳定跑起来，持续的交付。
• Agent-native 时代的数据 Infra 竞争，跟过去 30 年都不太一样，过去比的是单点性能……但现在不是，现在比的是当……这四件事同时发生的时候，谁能提供最顺畅的体验？
• 选 TiDB 的核心原因不在某一个单点指标的极致——而在于「per-tenant 多租隔离、统一栈、即时弹性」这三件事同时做到位时，它是少数几个把每一项都'够用且顺手'的系统。
• 一个用户身边可能有 10 个甚至 100 个 Agent 在跑，每个都需要自己的状态和数据......包括 Kimi 在内的一些 AI Agent 作为商业模式的团队采用的架构都收敛到同一个范式：one agent， one sandbox， one storage， one database。

📊 文章信息

阅读完整文章