对于创业者来说，更值得关注的可能是水面之下的事情：模型能力进化之后，Kimi Code 和 Kimi Work 这样的 agent 产品，在完成从聊天到交付工作的跃迁后，背后的 infra 基建设施，是怎么做的。
毕竟，agent 和 harness 已经是行业共识了，每个创业团队都要面对 agent 带来的新基础设施的难题。
做了十多年分布式数据库的 TiDB，如今成为了 Kimi、Dify 这些产品背后的基建服务商，最近甚至开始做 Memory、Filesystem 和 Lake 等。TiDB 自己的人说，其实他们的产品路线并没有提前规划好。Kimi、Dify 等 AI 团队陆续提出了一批听起来有些反常的需求，最终把这些产品拼成了一套 Agent Stack。
对于 Agent 时代的 infra 基建，他们有一些「暴论」判断：
Agent 时代的计算单位，不是用户，不是会话，是 Agent 本身。每个用户身边会有 10 个、100 个 Agent 在跑，每个都需要自己的状态、记忆和数据。
每个真正干活的 Agent，最后都会变成 full-stack agent。需要数据库、文件、记忆、执行环境，一样都躲不掉。
状态在哪？记忆在哪？文件在哪？在哪执行？谁有权访问？谁批准的？每个 Agent 团队迟早要回答这六个问题，区别只是主动回答还是被事故逼着回答。
执行环境可以临时，数据与状态必须持久。这是 Agent 从 Demo 走向生产的分水岭。
AI 不会消除基础设施，AI 会让基础设施再次显现。
以下内容整理自 TiDB 团队近两年服务 AI 团队的实践，Founder Park 略作调整。
作者介绍：唐刘，TiDB 一号员工，CAIO / APAC GM。2015 年写下 TiDB 第一行代码，过去两年服务了包括 Kimi、Dify 在内的一批 AI 团队的数据基础设施。
01
Kimi Agent 能规模化，先解决了这两个基建难题
先从 Kimi 和 Kimi 的 Agent 能力说起。
在 Kimi K3 的建站场景里，用户输入一句「帮我搭个读书笔记网站」，几分钟后就能得到一个包含前端、后端和独立数据库的应用。代码生成完成之后，这个站点还要继续存在。按照 TiDB 团队提供的数据，平台需要承载上千万个站点，大多数站点平时没有流量，但用户又可能在几个月后突然回来。
给每个站点配置常驻数据库，空闲资源会持续产生费用。把大量站点放进一个 PostgreSQL 实例，通过多个 Schema 隔离，规模扩大后又会遇到连接、隔离和运维压力，Kimi 团队实测过，到万级规模就扛不住了。
TiDB 团队给出的方案，是在 Agent 与物理存储之间增加一层虚拟数据库。没有请求时释放计算资源，整个平台最极端情况下计算资源只需要一个常驻的连接网关；Agent 要新数据库时，从预热池里 1 秒就可以拿到一个完全就绪的实例。没有流量的站点，不会产生数据库成本，对于建站产品来说，峰值性能只是账单的一部分。大量低频站点的空闲成本，会更早影响订阅业务能否成立。
Kimi Code 面对的是另一笔账。
Agent 进入代码仓库后，会修改文件、运行测试、生成 patch。简单任务可能几分钟结束，复杂任务会横跨多个 session。承担执行工作的 Sandbox 可以随时拉起和销毁，代码仓库、尚未提交的修改、Git 对象和任务进度却要留下来。假如 Sandbox 没了，改到一半的代码、没 commit 的 Git 状态、跑了一半的任务进度怎么办？
Kimi 在这个场景使用 TiDB Cloud Filesystem，一个面向 Agent 的持久文件系统，把「执行」和「状态」拆开，Sandbox 负责干活，Workspace 负责记住。新的 Sandbox 挂载同一工作区后，可以从最近的存档点继续任务。
建站和 Coding Agent 看起来是两类产品，对应着 Agent 应用最早需要算清成本的两件事：大量资源的空闲成本，以及执行环境消失后的任务恢复。
但要解决的其实是一件事：Agent 的执行环境是临时的，但它产生的东西必须活下来，而且要在千万级规模下算得过账。
Kimi 不是第一个遇到这个问题的团队，早在 K3 之前，TiDB 团队就已经在解决类似的问题了。
02
AI 产品最早的数据库难题：先扛住用户增长
两年前，最早找上 TiDB 的 AI 公司，提出的仍然是数据库团队熟悉的老问题。
一家头部 LLM 公司，C 端用户从十万增长到亿级，用户、会话、历史记录、任务和账单一起变多。原有的分库分表方案需要投入大量运维精力。如果去掉 LLM 的能力，AI 应用首先是互联网应用，首先要解决的，还是用户增长后带来的容量问题。这也是数据库公司最熟悉的领域。
Dify 来找 TiDB 团队的时候，需求开始出现一些变化。
这家 LLMOps 公司过去给每个租户分配独立数据库容器。随着租户的增加，数据库容器和运维工作一起增长，运维就崩了。数据显示，在将大量容器收敛进 TiDB Cloud 后，基础设施成本下降 80%，运维负担下降 90%。
更关键的变化发生在数据库的使用方式上。Dify 希望一个工作空间对应一个独立的数据空间。用户创建工作空间时，程序同时完成数据库的创建和配置；工作空间不再使用时，相关资源也跟着释放。数据库生命周期由此进入产品逻辑，不再完全依赖 DBA 手工处理。
随后，一家头部通用 Agent 平台提出一个更夸张的需求：「我们需要至少 100 万个数据库。」每个 Agent 任务都可能创建自己的数据库，设计 Schema、写入数据，再在任务结束后释放资源。整个过程由程序完成。今天 TiDB Cloud 上新建的集群，超过 90% 是 AI Agent 直接创建的，不是人类工程师。
这几次的需求变化连在一起，能看到一条清晰的变化路径。
最初，数据库服务于快速增长的 AI 应用；随后，工作空间可以直接申请数据库；再往后，Agent 开始自行创建和释放资源。
过去，一个用户或租户通常对应相对稳定的数据空间。进入 Agent 产品后，一个用户可以启动多个 Agent，每个 Agent 又会产生多个任务、工作区和数据库。资源数量与用户数量逐渐失去简单对应。
数据库要服务的对象，已经悄悄换了。
Agent 和任务由此成为资源分配与隔离的新粒度。Kimi 建站需要承载的上千万个站点，也是这条路径发展到今天的结果。
03
数据库之外，Agent 还需要保留自己的工作现场
数据库解决了应用数据的问题。随着 Agent 能够执行更长时间的任务，客户开始问 TiDB 要数据库之外的东西。
一家做 AI Workforce 平台的公司发现，上下文压缩后，重要状态会丢失；session 一换，之前积累的信息很难继续使用；多个 Agent 协作时，记忆也无法自然共享。它需要一层跨 session 持久、可检索的记忆，让 Agent 在下一次任务中找回与当前工作有关的信息。这个需求推动 TiDB 团队开发了 TiDB Cloud Memory：给每个 Agent 一层持久的、跨 session 可检索的记忆。数据库存的是数据，记忆存的是「这个 Agent 是谁」。
一家 AI 硬件公司遇到的问题则又完全不同，「我们曾经以为文件系统是一个 solved problem。」音频、转录、纪要和笔记存放在不同位置，内容、元数据、向量、权限、版本和关系又各有一套系统。人可以借助产品界面理解这些边界，Agent 需要逐个处理接口、身份和错误。系统每增加一层，任务链路就多一个可能中断的地方。
解决办法是把它们收回来：一个文件、一个对象、一个系统。
到了 Kimi 的 Coding Agent，问题合在了一起。代码仓库是一组文件，也是一份不断变化的任务状态。当前分支、未提交修改、Git 对象和 checkpoint 都属于工作现场。Sandbox 可以更换，工作现场需要被下一个执行环境完整接住。最关键的是：Git 不仅仅是文件，它是状态。
TiDB 团队也由此形成了一条更明确的产品边界：执行环境保持临时和弹性，任务状态进入独立的持久层。这里的状态包括应用数据、记忆、文件、Git 工作区、checkpoint 和操作记录。
随着状态类型越来越多，一个 Agent 也开始具备完整软件系统的特征。它要使用数据、记忆和文件，也要进入执行环境完成任务。真正干活的 Agent 逐渐成为 full-stack agent，执行与状态也需要分开管理。
04
Agent 进入真实业务后，要可追溯、可解释
任务变长之后，Agent 还会开始接触业务代码、企业数据和真实交易。基础设施需要回答的问题，开始从「能不能完成」延伸到「出了问题能不能解释」。
Clink 是一个典型的案例。作为面向 Agent 场景的支付基础设施，Clink 让 Agent 能够在明确的授权和风控规则下完成充值、消费、订阅等操作，同时记录身份、授权、资金流向和执行结果。
按照 Clink 提供的数据，团队将分析收敛到 TiDB Cloud Lake 后，复杂分析可以使用物化视图实时 Join 13 张业务表，核心指标体系约一周上线。这次改造当前先解决分析口径和开发链路，后续则将从支付分析进一步延伸到 Agent Analytics，让 Agent 的授权、决策和交易行为都能被追踪和解释。
但 Agent 管钱之前，账本要先是数据可信的。
人看到两个版本的 GMV，会停下来判断哪个可信。Agent 一旦直接读取指标并参与决策，错误口径可能被自动带入下一次操作。Agent 能接触的任务越重要，数据来源、权限范围和行为记录就越需要提前设计。
所有这些客户需求放在一起，一个准备进入真实业务的 Agent 产品，至少要回答六个问题：
任务状态存在哪里，中断后如何恢复？
记忆如何跨 session 保留，又如何更新和遗忘？
文件与工作区怎样持久化，版本如何管理？
代码和工作流在哪里执行，环境如何隔离？
Agent 能访问哪些数据，又能执行哪些动作？
操作如何记录，出错后怎样审计和回滚？
Web 时代的计算单位是用户，一个产品承接住几亿人。移动时代是会话，一个 App 可能要面临几亿并发。Agent 时代的计算单位是 Agent 自己——而 Agent 和人有一个本质区别：人类用户是无状态地访问你的服务，Agent 是带着任务、记忆、文件和权限在你的平台上「生活」。
每个真正开始干活的 Agent，无论做的是编码、运维、客服还是交易，最后都会变成 full-stack agent，都会面临这些问题：前四个问题影响任务能不能做完，后两个问题决定企业愿意交给 Agent 多大权限。
05
Agent 基建，每个 Founder 都需要这三个判断
对于正在做 Agent 的创业团队，TiDB 团队提供了三个可以提前落进架构的判断。
第一，先算空闲成本，再谈规模
Agent 业务经常面对长尾负载。大量租户、任务和工作区处于空闲状态，少数任务会在短时间内集中使用资源。如果每个 Agent 或工作区都要占用常驻实例，用户增长之后，闲置资源会持续推高账单，用户涨十倍，账单估计就是百倍了。能规模化的 Agent 业务，第一性原理是：不干活的时候，成本趋近于零；要干活的时候，秒级就绪。
做容量规划时，除了峰值并发，还要计算空闲资源、唤醒时间、连接管理和状态恢复。Kimi 建站面对上千万个低频站点，这笔账直接关系到订阅业务的单位经济。
第二，从第一天就拆开执行和状态
Sandbox 的价值来自临时、弹性和隔离。让执行环境长期存在，只为保存用户任务，会让成本和安全边界变得复杂。
团队需要尽早定义哪些内容可以重建，哪些内容必须进入持久层。数据库、记忆、文件、工作区、checkpoint 和审计记录都要有明确去处。执行中断以后，用户能否继续工作，是 Agent 从 Demo 进入生产环境时一道很实际的门槛。执行环境可以临时，数据与状态必须持久。
第三，让 Agent 少跨几次系统边界
每增加一个外部系统，Agent 都要多处理一套接口、身份、数据格式和错误方式。结构化数据、向量、文件与权限可以由不同组件承担，团队需要有能力管理其中的一致性和可观测性。
减少边界也不等于把所有能力塞进一个系统。更实用的判断标准是：Agent 能否看到稳定的数据语义，权限能否贯通，失败以后能不能找到原因并恢复。系统数量只是表面，跨系统协调的复杂度才会持续影响交付。
这三个判断来自不同客户在真实业务里付过的成本。它们也是 TiDB 随后整理产品边界的依据。
06
AI 不会消除基础设施，AI 会催生新基建
回头看 TiDB 过去两年的产品变化，会发现每一部分都能对应到上面的一类客户问题。
当 Agent 开始直接创建大量数据库，TiDB Cloud Starter 负责承接应用数据。它提供秒级就绪、scale-to-zero，以及 SQL、向量和 JSON 的统一查询能力。
当任务跨越 sandbox 和 session，TiDB Cloud Memory 保存可检索的长期记忆。TiDB Cloud Filesystem 保存文件、Git 工作区和 checkpoint，让新的执行环境可以回到之前的工作现场。
当 Agent 需要消费企业指标，TiDB Cloud Lake 将交易与分析放进同一套数据语义中。权限和审计贯穿这些能力，可观测性与工作流等部分仍在继续补齐。
我们把这套组合称为 TiDB Agent Stack。它的定位是「Unified Storage Layer for Agents」，即 Agent 的统一状态底座。模型负责理解和规划，Sandbox 提供临时执行环境，Stack 保存任务持续运行所需的数据、记忆、文件和操作记录。
这套产品组合能否成为 Agent 团队普遍采用的架构，还要看成熟度、迁移成本和真实使用结果。可以确定的是，这张图并非来自一次闭门规划。它沿着用户增长、数据库自动创建、跨 session 记忆、Git 工作区和可信分析的需求逐步展开。
过去三年，行业的聚焦点一直在模型，以至于有一种错觉：模型足够强，其他问题都会自动消失。
K3 这样的模型确实在把 Agent 的能力边界迅速往外推。但有意思的是，模型越强，暴露出来的基建缺口反而越大。
Kimi 的 Agent 产品则把另一件事摆到了台前：模型开始真正干活以后，基础设施问题会变得更具体，也更接近商业化。
两年前，「我们需要至少 100 万个数据库」听起来像一个离谱需求。今天，一个用户已经可能同时拥有多个 Agent，每个 Agent 都会创建任务、工作区，并直接申请基础设施资源。
互联网时代花了二十年，才沉淀出今天人人默认的那套基建：云、CDN、数据库、消息队列。Agent 时代的对应物正在被压缩到两三年内成型，而且没有任何一家公司有规划——它是被 Kimi 们、Dify 们、以及无数个还没出名的团队，用一个一个「奇怪需求」逼出来的。
所以如果你正在做 Agent，手里正好有一个奇怪的问题，别觉得它奇怪，它可能就是下一块基建的入口。
AI 不会消除基础设施。AI 会让基础设施再次显现。
如果你正在构建 Agent 时代的产品，TiDB AI Startup Program 为早期团队提供云资源额度与架构支持——如果你在构建未来，来和我们一起构建它。
