Kimi 和 Kimi Work能根据用户的一段自然语言需求，自动完成前端、后端编码与数据库 Schema 设计，交付持续在线的应用。随着 Agent 从生成代码走向交付和运行完整应用，Kimi 面临两类状态管理问题：Website 场景需要为数千万 Agent 生成站点提供秒级就绪、空闲零成本的隔离数据库；Coding Agent 场景需要让代码、Git 状态和任务进度不随 Sandbox 销毁而丢失。Kimi 引入 TiDB Cloud Starter 和 TiDB Cloud Filesystem 等技术方案应对这两个问题，背后是同一逻辑：让执行环境保持弹性与临时性，让数据与工作状态可靠持久。

用户说一句话，Agent 交付一个在线应用——然后呢？

一个用户打开 Kimi 网站或 Kimi Work 桌面客户端，输入"做一个博客系统"。几分钟后，一个包含前端页面、后端逻辑和数据库的完整应用部署上线，可以访问、可以运行。用户不写一行代码，也不需要了解任何技术细节。

这是 Kimi Agent 能力的典型交付流程。代码生成分钟能完成，但代码生成只是起点。应用上线之后，它的数据由谁承接？如果用户下次回来让 Agent 修改代码，上一次的工作状态还在不在？

这两个问题分别指向 Kimi Agent 的两个场景，也指向同一个基础设施命题——当 Agent 从"生成代码"走向"持续交付和运行应用"，它需要怎样的数据与状态基础设施。

关键成果

数据库 provisioning 在 1 秒内完成，不再是 Agent 交付链路中的可见步骤。

空闲站点不产生数据库计算成本，改变数千万租户规模下的单位经济模型。

单一 TiDB 集群支撑数千万并发租户站点，单实例多 Schema 方案在万级规模即被排除。

前端、后端和数据库基础设施统一在同一技术栈上，Agent 代码生成成功率得到提升。

Coding Agent 的工作状态可跨 Sandbox、Session 持续存在，Sandbox 保持弹性可替换。

客户与业务背景

月之暗面 Kimi 是是中国领先的大语言模型公司之一，Kimi 也是其 AI 助手产品和大模型的名字。Kimi 网页版和 Kimi Work桌面客户端支持端到端的方式构建应用：从一个自然语言请求出发，Agent 生成、部署并托管一个完整的在线 Web 应用，前端和后端全部接管。

用户不需要技术背景，这意味着潜在用户群远大于面向开发者的工具。这也意味着平台需要支撑远大于开发者工具的站点规模——每个站点创建后持续在线，用户随时可能回来访问。

Kimi 的 Agent 产品中，目前有两个场景使用了 TiDB 相关产品：Website 场景使用 TiDB Cloud Starter 为 Agent 生成的应用提供数据库能力；Coding Agent 场景使用 TiDB Cloud Filesystem 管理代码生成过程中的状态数据。

挑战：Agent 规模化交付背后的两类状态问题

为每个站点分配独立数据库实例，在千万级规模下成本不可承受

Kimi Agent 接管应用的完整交付链路：用户表达需求，Agent 生成代码、调用数据库、写入数据、启动应用。整个过程在几分钟内完成。基础设施的挑战不在代码生成这一步，而在随之而来的托管成本。

平台需要支撑数千万个 Agent 生成的站点。每个站点都需要独立的数据库，大部分站点的访问频率很低——但用户回来时，站点必须立即响应。为每个站点分配一个独立的数据库实例，无论是 Postgres 还是托管服务，在数千万规模下成本无法承受：空闲站点持续产生计算费用，订阅收入无法覆盖。

Kimi 也评估了在单个大型 PostgreSQL 实例上通过多 Schema 进行租户隔离。这个方案在万级规模就遇到了瓶颈——流控、故障半径管理和数据隔离问题无法解决，没有通往生产级别的路径。

数据库准备时间不能占据 Agent 的交付窗口

Kimi 在几分钟内交付一个在线应用。如果数据库 provisioning 占去其中可观的时间，Agent 就得在生成代码中编写 retry、poll、wait 逻辑。这个负担应该由基础设施层承担，而不是由 Agent 生成的应用代码承担。数据库准备必须快到对 Agent 不可见。

长尾站点需要始终在线，但不能产生始终在线的成本

大部分 Agent 创建的站点是长尾的：访问不频繁，但用户回访时期望立即响应。回收空闲实例的 Serverless 架构引入 cold-start 延迟和可用性间隙。为数百万空闲站点维持常驻真实实例则产生订阅模式无法吸收的成本。

Sandbox 适合执行，但不适合成为长期状态的唯一载体

Coding Agent 的任务不只是生成一段代码。一个真实的任务会经历完整研发循环：进入代码仓库，理解项目结构，搜索相关代码，读取上下文，修改文件，运行 build 和 test，保存 Git 状态，生成 patch 或报告，必要时把任务交给另一个 Agent 或人类继续。

Sandbox 可以快速拉起、随时销毁，适合承担隔离和弹性的执行任务。但如果源码、Git 状态、构建结果、用户上传材料和 Agent 生成物只存在 Sandbox 内，每次销毁都带来状态丢失、任务中断和重复计算。多个 Agent 或人机之间交接任务时，下一个 Agent 需要知道当前工作状态、Git dirty state、谁有权访问哪些文件——普通共享目录无法表达这些语义。

两类场景的共同要求

两个场景看似不同，底层要求一致：执行环境保持弹性和临时性，数据与工作状态可靠持久、可恢复、可隔离、成本可控。

解决方案一：TiDB Cloud Starter 支撑 Agent 生成应用的运行数据

Kimi 在 Website 场景使用 TiDB Cloud Starter。方案的核心是三个架构决策。

把数据库准备时间从 Agent 关键路径上移除

TiDB 的 Warm Pool 维护一个预初始化的 Starter 实例池。Agent 任务启动时，在 1 秒内获得一个 fully prepared 的数据库实例。Scale-to-Zero 在空闲时收缩集群，在负载到来时自动扩展，无需手动容量管理。Agent 不需要等待数据库，也不需要在生成代码中处理数据库可用性的 retry 逻辑。

统一 Agent 生成应用的整个技术栈

Agent 每多跨一个系统边界，就多引入一类潜在故障。通过统一数据库接口和框架脚手架，Agent 在每次生成任务中复用已有最佳实践，而不是每次从零推理基础设施选择。TiDB 的 MySQL 兼容性使 Kimi 的应用层无需改写查询语句。分布式 SQL 的 ACID 事务保证确保 Agent 状态转换在多个并发实例同时写入时保持一致。

用虚拟数据库层替代真实实例

TiDB 不为每个站点分配真实的数据库实例，而是在 Agent 和底层物理存储之间放置一层虚拟数据库接口。物理层由基于对象存储的分布式 KV 存储承载数据持久化。这一层提供租户级逻辑隔离，自动管理冷热数据分层。Agent 在 Sandbox 中看到的是一个完整、独立的数据库。它不会遇到实例被回收、休眠或连接中断。

在资源使用的最极端状态下，整个平台只需一个常驻的 DB Session Gateway 服务维持数据库连接，其他所有资源按实际需求弹性伸缩。没有流量的站点不产生计算成本。

与传统 Serverless 数据库的对比是直接的：传统方案为每个 Sandbox 分配真实实例，空闲时回收，在数千万租户规模下无法维持可用性保证。TiDB 的虚拟层移除了"实例"这个概念。

解决方案二：TiDB Cloud Filesystem 承接 Coding Agent 的持久工作状态

Kimi 在 Coding Agent 场景使用 TiDB Cloud Filesystem 管理 Kimi Code 状态数据。TiDB Cloud Filesystem 是面向 AI Agent 的持久文件系统（persistent filesystem for AI agents），设计目标是让文件跨 Session、工具和机器持续存在。

核心思路是把"执行"和"持久状态"分离：Sandbox 负责执行，Workspace 负责持久状态。

Sandbox 继续保持轻量、弹性、可替换，Agent 的工作目录、上下文文件、Git 状态和生成物由 TiDB Cloud Filesystem 承接。以一次 Coding Agent 任务的生命周期来看 TiDB Cloud Filesystem 的对应能力：

Agent 进入代码仓库时，不需要一次性下载全部文件。TiDB Cloud Filesystem 的 metadata-first 和按需加载机制使 Agent 先看到目录结构和文件元数据，只在实际访问时才加载内容。Agent 在开始思考之前不会被文件下载阻塞。

Agent 搜索代码时，TiDB Cloud Filesystem 通过批量 stat 减少目录扫描的往返开销，小文件可通过元数据缓存加速读取，同时支持全文检索和向量检索帮助 Agent 按语义定位文件，并通过 ignore 策略过滤 node_modules、dist 等噪声目录。

Agent 修改代码时，TiDB Cloud Filesystem 的 FUSE 写入路径采用本地优先策略——写入先进入本地缓存，工具链获得接近本地文件系统的响应速度，后台再异步提交到远端。Journal/WAL 记录未提交变更，支持崩溃恢复。

Agent 运行 build/test 时，TiDB Cloud Filesystem 用分层管理区分可重建文件（node_modules、dist 等，留在本地 overlay）和需要持久化的文件（源码、测试结果、patch、构建日志，进入远端持久层），避免 build 产物拖垮远端同步。

Agent 保存 Git 状态时，TiDB Cloud Filesystem 用专门的模型表达工作现场：clean tree 表示基准，dirty overlay 表示 Agent 的修改，object pack 保存新产生的 Git 对象。下一个 Agent 恢复时面对的是一个可继续工作的 Git Workspace，不是一个丢失了历史的目录。

Agent 需要存档点时，TiDB Cloud Filesystem 的 layer FS checkpoint 机制可以在关键节点创建存档，失败时 restore 或 rollback。长任务不再完全依赖聊天上下文恢复历史。

多个 Agent 协作交接时，TiDB Cloud Filesystem 通过 Workspace 隔离不同任务上下文，Token/Scope 控制文件访问边界，Vault Grant 支持 Secret 的 TTL 授权传递，Audit Trail 记录访问和修改历史。交接的是一个可恢复、可授权、可审计的工作状态。

统一价值：从一次性生成代码到持续交付应用

TiDB Cloud Starter 和 TiDB Cloud Filesystem 分别承接 Kimi Agent 的两类状态，背后的逻辑一致：解耦临时执行环境与持久状态。

Website 场景中，Sandbox 里的 Agent 生成应用并启动服务，应用的运行数据由 TiDB Cloud Starter 承接。Sandbox 可以销毁，应用数据持续存在，站点保持在线。Coding Agent 场景中，Sandbox 里的 Agent 编写和调试代码，开发工作状态由 TiDB Cloud Filesystem 承接。Sandbox 可以销毁，代码、Git 状态和任务进度持续存在，下一个 Agent 从断点继续。

两者共同使 Kimi 的 Agent 执行环境保持弹性和临时性——快速拉起、随时销毁、按需扩展——同时保证应用数据和开发状态不因执行环境的消失而丢失。

成果与商业价值

秒级数据库就绪。 TiDB 的 Warm Pool 在 Agent 请求后 1 秒内交付一个 fully prepared 的数据库实例。provisioning 不再是交付链路中的可见步骤。Agent 生成应用代码时无需处理数据库可用性的 retry 逻辑。

空闲成本消除。 虚拟数据库架构移除了低流量时段的计算开销。不活跃站点不产生空闲数据库成本。在数千万 Agent 创建租户的规模下，这是单位经济模型的实质性改变。

持续可用。 站点无论流量高低始终保持在线。用户回访低频站点时不会遇到 cold-start 延迟。平台在不承担常驻实例成本的前提下交付 always-on 可用性。

统一交付栈。 前端、后端和数据库基础设施通过同一技术栈解决。Agent 在每次生成中应用一致的脚手架和最佳实践，而非推理新的系统组合。统一栈提升了代码生成成功率。

可扩展的租户隔离。 逻辑隔离在所有租户间保持有效，无论规模如何。平台避免了单实例多 Schema 方案在万级租户以上出现的故障半径风险、流控复杂度和数据隔离失败。

在 Coding Agent 场景，TiDB Cloud Filesystem 的方案设计价值体现在：Sandbox 不再承载长期文件状态，降低了平台的状态管理复杂度；Agent 的代码仓库可以按需加载而非全量下载，减少启动等待；长任务可以通过 checkpoint 存档和恢复，减少因中断导致的重复计算；多 Agent 协作交接的是完整工作状态而非零散文件。

从商业角度看，Website 场景的核心意义是让数千万站点的托管在成本上成立——算力消耗集中在应用创建阶段，运行期数据库成本趋近于零，订阅制模式具备可持续的利润空间。Coding Agent 场景的核心意义是让长周期、多角色协作的 Agent 编码任务具备连续性——任务不因环境销毁而中断，Agent 的开发成果可以持续积累。

结语

Kimi 引入 TiDB 等方案后形成的架构，收敛于一个正在 Agent-Native 商业产品中出现的模式：一个 Agent，一个 Sandbox，一个数据库，支撑数千万租户。Agent 时代的基础设施竞争不是单点性能的竞争，而是当隔离、即时 provisioning 和成本弹性三件事同时被要求时，哪个系统能同时交付。

Website 场景的回答是虚拟数据库层。Coding Agent 场景的回答是 Agent-Native 文件系统。两者合在一起，构成 Agent 从 Demo 走向生产所需要的状态基础设施：执行环境可以临时，数据与状态必须持久。