在Kimi K3以2.8万亿参数规模创下开源模型纪录之后，支撑其Agent产品运行的底层基础设施正在成为行业关注焦点。分布式数据库厂商TiDB披露的实践数据显示，其云平台上新建集群中超过90％由AI Agent直接创建，而非人类工程师操作。这一比例标志着Agent正在成为数据库资源分配与隔离的新粒度。
据TiDB团队介绍，Kimi建站场景需要承载上千万个站点。多数站点平时没有流量，但用户可能在数月后重新访问。若为每个站点配置常驻数据库，空闲资源将持续产生费用；而将大量站点放入单一PostgreSQL实例并通过多Schema隔离，在万级规模时便遭遇连接与运维瓶颈。TiDB给出的方案是在Agent与物理存储之间增加虚拟数据库层，无请求时释放计算资源，Agent申请新数据库时可从预热池中1秒获取就绪实例，无流量站点不产生数据库成本。
在Kimi Code场景中，Agent进入代码仓库后会修改文件、运行测试并生成patch，复杂任务可能横跨多个session。执行任务的Sandbox可随时拉起销毁，但代码仓库、未提交修改、Git对象和任务进度需要持久保留。TiDB Cloud Filesystem将执行与状态分离，新Sandbox挂载同一工作区后可从最近存档点继续任务。TiDB方面认为，这对应Agent应用最早需要算清的两件事：大量资源的空闲成本，以及执行环境消失后的任务恢复。
TiDB团队回顾了AI客户需求的变化路径。两年前，头部LLM公司提出的仍是数据库团队熟悉的容量问题，C端用户从十万增长至亿级，用户、会话、历史记录与账单同步膨胀。随后，LLMOps公司Dify提出按工作空间动态创建和释放数据库的需求，将大量容器收敛进TiDB Cloud后，基础设施成本下降80％，运维负担下降90％。再往后，一家头部通用Agent平台直接提出需要至少100万个数据库，每个Agent任务自行设计Schema、写入数据并在结束后释放资源。
TiDB一号员工、CAIO兼APAC GM唐刘表示，Agent时代的计算单位不是用户，不是会话，而是Agent本身。每个用户身边会有10个、100个Agent在跑，每个都需要自己的状态、记忆和数据。每个真正干活的Agent最终都会变成full-stack agent，需要数据库、文件、记忆和执行环境。状态在哪、记忆在哪、文件在哪、在哪执行、谁有权访问、谁批准，这六个问题每个Agent团队迟早要回答，区别只是主动回答还是被事故逼着回答。
从服务Kimi、Dify等AI团队的实践来看，Agent基建的产品路线并非提前规划，而是由AI团队陆续提出的反常需求逐步拼装而成。执行环境可以临时，数据与状态必须持久，正在成为Agent从Demo走向生产的分水岭。
该文观点仅代表作者本人，企服科学平台仅提供信息存储空间服务。
