AI Agent 场景下的数据库架构挑战：应对海量短命实例的实战方案

在过去一年的 TiDB Cloud 服务观察中，我们发现了一个趋势性的数字变化：每天新创建的数据库集群里，超过 90% 并非由人类发起，而是由 AI Agent 自动创建的。

这并非个别现象，它正在成为新常态。从创建集群、生成表结构、编写并执行 SQL 到最终销毁数据库，整个流程可能不需要 DBA 介入，甚至无需人类知晓。这个现象迫使我们重新审视一个根本问题：当数据库的主要使用者从人类转变为 AI Agent 时，过去二十年围绕“人类使用数据库”建立的所有假设——容量规划、Schema 设计、运维流程乃至定价模型——是否依然成立？

本文无意做产品推介，而是希望分享我们在过去一年中，服务数家 AI 公司时遇到的真实挑战、做出的架构决策以及踩过的坑。这些来自一线的实践经验，或许能为正在构建 AI Agent 应用的团队提供有价值的参考。

Agent 工作负载的四个特征：传统数据库为何被“打穿”

在深入具体案例之前，我们先归纳从真实生产环境中观察到的 AI Agent 工作负载特征。

特征一：海量短命实例

传统应用的数据库通常是“一个产品一个库”或“一个租户一个 Schema”。但在 Agent 场景下，粒度变成了“一个 Agent”或“一个 Session”对应一个逻辑数据库。我们曾见过一个客户在三个月内创建了近百万个数据库租户，其中约 99% 是一次性使用的。如果沿用传统云数据库按最小实例（月费十几到二十美元）计价的模型，百万实例意味着天文数字的账单，其成本足以让商业模式本身难以成立。

特征二：数据库成为 Agent 的“工作台”而非“仓库”

Agent 对数据库的使用不止于“存入即走”。以一个数据分析任务为例：Agent 可能先从网络抓取原始资料，将其结构化后存入数据库，接着用 SQL 进行数据清洗、统计、聚类分析，最终生成报告。将数据沉淀在数据库中，使得后续处理可以依赖确定性的 SQL 和可审计的代码，分析过程才真正实现工程化。更激进的场景如建站，Agent 为用户搭建一个需持续运营的网站，这意味着其创建的数据库本身就是一个生产系统，且 Schema 由 AI 动态生成。此时，“一个 Agent 一个库”不仅是隔离需求，更是控制爆炸半径的关键——单个 Agent 的错误操作不会波及其他租户。

特征三：上下文即数据，且体量剧增

为了实现任务的可恢复、可审计和跨 Session 检索，Agent 的关键上下文需要被持久化。虽然载体可以是文件或日志，但当需要对上下文进行结构化查询和跨任务关联分析时，数据库的优势便凸显出来。更值得注意的是，上下文的长度在不断增加。我们有客户的单条上下文（Context）达到 30MB-50MB，包含文本和音频数据，这已远超传统 OLTP 数据库的舒适区。

特征四：流量“脉冲式”爆发，成本必须可控

Agent 的工作模式不像人类遵循固定作息。它们可能在凌晨三点发起一波密集查询，也可能连续数小时完全静默。如果为了应对这种“间歇性活跃”而长期维持整套计算资源，对服务方和客户而言都是巨大的成本浪费。

案例一：数据库成本决定产品能否上线

第一个案例来自某全球知名的 AI Agent 平台。该平台在发布 Waitlist 后迅速积累了超过两百万等待用户，但从开放名单到正式上线，却间隔了近两个月。卡住他们的并非产品核心逻辑，而是数据库方案。

问题本质：从 Demo 到规模化之间的鸿沟

该产品的形态决定了每个会话（Session）就是一个独立的 Agent。跨 Session 通常意味着业务目标不同，需要一个全新的独立环境。因此，他们的核心需求不是“一个产品一个库”，而是“一百万个 Agent 需要一百万个逻辑数据库”。他们早期评估的方案中，最小实例的月成本约十几美元，单看不贵，但乘以百万量级后，商业模式直接崩盘。数据库方案在此并非性能优化项，而是决定业务能否上线的先决条件。

我们的三层解法

1. 逻辑多租户，共享物理集群：核心是让海量逻辑租户共享同一套基础设施，通过逻辑隔离实现成本分摊。其前提是元数据层必须足够强悍。得益于我们之前服务插件生态客户时，将元数据规模优化至千万级别并支持两千万张表以上的经验，应对百万级 Agent 的场景才成为可能。
2. 存算分离，极致弹性：底层使用对象存储作为全量数据的持久化层，上层计算节点处理热数据并可弹性调度。在 Agent 间歇性活跃的特性下，计算层可以近乎实现 “Scale-to-zero”，将闲置成本降至极低。
3. 接受合理的权衡：弹性不是零代价的，计算节点冷启动会带来约百毫秒的延迟。但在 Agent 场景中，这通常是可接受的，因为大模型推理本身就是秒级，LLM 生成的查询也非高度优化的毫秒级 SQL。用微乎其微的启动延迟换取数量级的成本下降，是合理的交易。

此外，资源隔离同样关键。海量租户共享资源池时，必须通过严格的 Resource Control 为每个 Agent 设定清晰的资源消耗边界，防止单一 Agent 的异常行为拖垮整个集群。

关键教训：用真实负载测试，而非基准测试

客户从 MySQL 迁移到 TiDB 的过程，因协议兼容而代码改动极少，两周内即完成。但上线切换时，仍花费了约三小时进行查询计划调优。原因是标准的 TPCC 基准测试无法反映其 Agent 实际生成的、用于复杂上下文重建的查询模式，这需要不同于常规事务的索引策略。务必记住：AI Agent 生成的 SQL 和人类编写的 SQL 是两个物种，标准基准跑得再好，也不代表生产没问题。

案例二：30MB 的上下文，究竟该存于何处？

第二个案例来自 AI 硬件公司 Plaud，其产品是 AI 笔记硬件，拥有全球超 150 万用户。如果说案例一聚焦“数量与成本”，Plaud 则揭示了“长上下文与多媒体数据的存储架构”问题。

问题本质：存储链路过于迂回

Plaud 的上下文很长，最长约 30MB-50MB，多为文本和音频。传统做法是将此类大对象存入对象存储（如 S3），数据库仅存其元数据。但这种分离架构立刻引入一系列工程难题：一致性（需自行保证 S3 与数据库间的数据同步）、性能（S3 高延迟迫使业务增加缓存层，且随着文件增多，枚举查询的长尾延迟难以控制）。最终得到的是一套“对象存储 + 元数据库 + 缓存层 + 一致性补偿”的复杂且脆弱的链路。

范式转变：将长上下文收回数据库

我们提供的方案是改变范式：将长上下文直接存入数据库字段。在实际生产中，TiDB 的单字段可支持 100MB 量级的数据。这意味着用户的整段交互上下文（包括音频转写文本）可直接落地于数据库中，同时完整保留事务性、一致性及 SQL 查询能力，从而大幅简化原有复杂链路。关键点在于：不仅是“能存长”，更是“在存长的同时，依然保有 SQL 与事务能力”。

一个被低估的传统能力：在线 DDL

Plaud 的实践还验证了在线 Schema 变更（Online DDL）在 AI 时代的价值。AI 原生应用的数据结构更不稳定，Schema 变更频率远高于传统业务。无需锁表的在线 DDL 能力，允许业务发布与 Schema 变更同步推进，这对于追求快速迭代的 AI 产品至关重要。

案例三：分库分表扩张至二十个分片之后

第三个案例来自一家国内头部大模型公司。其产品形态更接近传统高频对话场景，但规模上去后，传统方案同样遭遇瓶颈。

问题：维护复杂度先于性能崩溃

该公司基于 PostgreSQL 进行了大量分库分表，最终达到近二十个分片。理论上继续增加分片还能提升性能，但团队首先在维护复杂度上不堪重负：跨分片查询日益复杂、Schema 变更需逐片执行、监控告警配置成倍增加、新人学习成本陡升。这是一个重要判断：AI 应用的流量压力，可能首先体现为数据层架构复杂度的失控，而非模型成本。

架构简化的验证

虽然其单条上下文长度在几 MB 级别，不及 Plaud 极端，但原本也存放在对象存储中。迁移至 TiDB 后，他们同样将部分上下文收归数据库管理，主要目的就是简化架构。这印证了从案例二得出的结论：即便不是极端长上下文，只要对象存储与数据库的组合开始显得笨重，将更多内容收回数据库就是合理的演进方向。

从数据库到记忆层：Agent 基础设施的下一个需求

在服务上述客户的过程中，我们观察到一个更深层的需求正在浮现。

前三个案例主要涉及 Agent 对数据库层的需求：结构化存储、上下文持久化和多租户隔离。但当 Agent 需要跨 Session、跨设备、跨任务连续工作时，问题就超越了“如何存”，变成了“如何把过去的信息在合适的时机、以合适的形式重新注入模型上下文”。传统数据库能保存用户偏好和历史记录，但缺少一层面向 Agent 的、专门处理记忆的沉淀、索引、检索和筛选机制。

这个观察促成了开源项目 mem9 的诞生。mem9 是一个开源的 AI Agent 持久记忆基础设施（Apache 2.0 协议），底层利用 TiDB 实现持久化与向量搜索能力，并通过一层 REST API 向 Agent 框架提供记忆的写入、混合搜索（向量+关键词）、跨 Session 恢复等功能。Agent 框架只需对接此 API，无需关心底层实现。

从架构视角看，这是 Agent 数据基础设施的自然分层演进：

前两层是传统数据系统的延伸，而第三层“长期记忆层”是一个新的独立需求，但它并非脱离数据库，而是将数据库的能力通过一个为 Agent 量身定制的 API 层暴露出来。mem9 目前已集成至 OpenClaw 生态，代码在 GitHub 开源：github.com/mem9-ai/mem9。

核心实践教训总结

1. 定价模型需为 Agent 重塑：如果每个 Agent 或 Session 都对应一个传统云数据库实例，绝大多数商业模式将难以维系。对于 Agent 密度高的场景，放弃按实例计费，转向基于实际资源消耗的聚合计费模型，不是优化选项，而是前提条件。
2. Agent SQL ≠ 人类 SQL：切勿用 TPCC 或 Sysbench 等标准基准测试的结果来预判 Agent 场景的数据库表现。Agent 生成的查询模式不规则、多变且往往非最优。上线前必须使用真实 Agent 工作负载进行压力测试。
3. 简化架构优于优化架构：在 AI 应用的快速迭代节奏下，维护一套“对象存储 + 元数据库 + 缓存层 + 分片 + 一致性补偿”的复杂链路，其运维成本和心智负担会迅速成为瓶颈。如果数据库本身能承载长上下文和大对象，那么减少一层组件，往往比优化每一层的性能更有实际意义。
4. “记忆”将成为 Agent 基础设施的标配：目前多数 Agent 应用仍在“无状态”模式下运行。但随着 Agent 开始承担更复杂、长期的任务（如持续运营网站、跟进客户关系），跨 Session 的持久记忆将从“锦上添花”变为“不可或缺”。这也是我们启动 mem9 项目的原因。

写在最后

过去一年的实践让我们形成一个核心判断：AI 时代的竞争优势或许不在于模型参数量的大小，而在于数据基础设施能否有效支撑 Agent 的全新工作方式。

当数据库的主要用户从人类变为 Agent，数据库的角色就从被动的存储系统，转变为了 Agent 的“操作底座”——Agent 在其上创建、查询、分支、合并、销毁，如同使用一个可编程的基座。这对整个数据库行业而言，是一次根本性的范式转移。我们的经验是：不要试图用旧架构去“兼容”新需求，而应从 AI Agent 的工作方式出发，重新构想数据库应有的形态。这些来自真实场景的挑战与解决方案，正是整个技术社区共同探索未来架构的宝贵财富，也欢迎大家在 云栈社区 进行更多深入的交流与讨论。