一个让我们重新审视数据库的数字
过去一年，我们在 TiDB Cloud 上观察到一个趋势性变化：每天新创建的数据库集群中，超过 90% 不是由人类创建的，而是由 AI Agent 自动发起的。
这不是某个极端客户的个例，而是正在成为常态。Agent 创建数据库、生成 schema、写 SQL、跑实验、销毁数据库——全程不需要 DBA 介入，甚至不需要人类知道它发生过。
这个数字迫使我们重新审视一个根本问题：当数据库的主要用户从人类变成 AI Agent 时，过去二十年我们围绕"人类使用数据库"所构建的一切假设——容量规划、schema 设计、运维流程、定价模型——还能成立吗？
这篇文章不打算做产品介绍。我想分享的是过去一年里，我们在服务几家 AI 公司时遇到的真实挑战、做出的架构决策、以及踩过的坑。这些经验或许对正在构建 AI Agent 应用的团队有参考价值。
Agent 工作负载的四个特征：为什么传统数据库会被打穿
在深入案例之前，先把我们观察到的 Agent 工作负载特征做一个归纳。这不是理论推演，而是从真实生产环境中反复出现的模式。
特征一：海量短命实例
传统应用的数据库是"一个产品一个库"或"一个租户一个 schema"。但在 Agent 场景下，粒度变成了"一个 Agent / 一个 session 一个逻辑数据库"。我们见过一个客户三个月创建了近百万个数据库租户，其中约 99% 是一次性使用的。
如果按传统云数据库的定价模型——最小实例每月十几到二十美元——百万实例意味着天文数字的月账单。问题不是数据库贵，而是贵到商业模式算不过来。
特征二：数据库成了 Agent 的工作台，不是存储仓库
Agent 不是把数据"存进去就完了"。以一个典型的数据分析任务为例：Agent 先从网上抓取原始资料，结构化存入数据库表，然后用 SQL 做清洗、统计、聚类、离散分析，最后生成报告。如果数据只停留在 Markdown 或纯文本里，后续处理只能继续依赖大模型"泛泛看一眼"，分析质量完全交给模型幻觉。落到数据库里，SQL 是确定性的、代码是可审计的，分析才真正可工程化。
更激进的是建站类场景：Agent 直接帮用户搭建一个网站，网站要持续运营、持续收费。这意味着 Agent 创建的数据库不是临时的，而是一个真正的生产系统。而且——schema 也是 AI 写的。一旦 schema 由 AI 动态生成，"一个 Agent 一个库"就不仅是隔离问题，而是控制爆炸半径：写错了只影响当前 Agent，不波及其他租户。
特征三：上下文即数据，而且越来越长
在很多复杂 Agent 系统中，为了实现可恢复、可审计和跨 session 的检索，关键上下文需要被持久化。持久化的载体可以是文件索引、日志存储或数据库——但当 Agent 需要对上下文做结构化查询、跨任务关联分析时，数据库的优势就会显现出来。我们服务的几家客户最终都走向了这个方向。
而且上下文在变长。我们有客户的单条 context 达到 30MB-50MB，内容包括文本和音频。这已经远远超出传统 OLTP 数据库的舒适区。
特征四：流量不可预测，但成本必须可控
Agent 不像人类按工作时间使用数据库。它们可能在凌晨三点突然发起一波密集查询，也可能连续几小时完全沉默。如果为这种"间歇性活跃"长期维持整套计算资源，客户和服务方都会双输。
案例一：当数据库成本决定产品能不能上线
第一个案例是某全球知名 AI Agent 平台。
作为一个通用型 AI Agent 平台，发布 waitlist 后迅速积累了两百万以上的等待用户。但从发布 waitlist 到真正开放，中间隔了将近两个月。这段时间不是产品没准备好——Agent 控制层已经是无状态的，可以随时拉起和销毁。真正卡住他们的，是数据库。
问题的本质：不是做不出 Demo，而是 Demo 无法规模化
它的产品形态里，一个 session 就是一个 Agent。同一 session 内任务连续、上下文连贯；跨 session 通常意味着业务目标不同，需要一个新的独立环境。所以他们的需求不是"一个产品一个库"，而是"一百万个 Agent 需要一百万个逻辑数据库"。
他们最早评估的方案，最小实例月成本大约十几到二十美元。单看不贵，但乘以百万，商业模式直接崩盘。
这就是这个案例最有力量的地方：数据库方案不是性能优化项，而是决定业务能不能上线的前提条件。
我们是怎么解的
解法可以概括成三层。
第一层：一个物理集群承载海量逻辑租户。 不是每个 Agent 一套独占实例，而是共享基础设施 + 逻辑隔离。多租能力本身，就是成本被打下来的基础。
但多租的前提是元数据能扛住。这里有一个背景：我们之前有一个做插件生态的客户，插件数 × 租户数的乘积把数据库元数据规模推到了千万级别。这逼着团队做了大量 meta 层优化，最终在测试中跑到了两千万张表以上的量级。正因为这个能力已经就绪，第一个案例那种百万级 Agent 的场景才是可承接的。
第二层：存算分离，做到更极致的弹性，把成本进一步压下去。底层以对象存储作为全量数据的持久化层，上层叠缓存处理热数据；计算层弹性调度，在 Agent 场景下可以接近 scale-to-zero。Agent 不是 24 小时持续高活，很多用户一天只活跃几次。如果为间歇性活跃长期维持整套计算资源，成本是没有意义的。
第三层：接受合理的 trade-off。 弹性不是零代价的。计算节点唤起时会有冷启动延迟，大约百毫秒。但在 Agent 场景里，这通常是可接受的——大模型推理本身就是秒级的，LLM 生成的查询也不是高度优化的毫秒级 SQL。省下的是数量级的成本，付出的只是用户几乎无感的一点启动延迟。
还有一个容易被忽视的点：资源隔离。 海量租户共用基础设施时，最怕的不是平均负载高，而是某一个 Agent 把资源打爆、拖垮整池。所以除了多租和弹性，还必须把 resource control 做到位，让每个 Agent 的资源消耗有清晰的边界。
一个关键教训：测试你的真实工作负载，不要测基准
客户从 MySQL 迁移到 TiDB，因为 MySQL 协议兼容，几乎没有代码改动，整个过程在两周内完成。但切换上线时，仍然花了大约三小时做查询计划调优。原因是：标准 TPCC 基准测试并不能反映 客户 Agent 实际生成的查询模式——那些查询是复杂的上下文重建，需要不同于常规事务的索引策略。
这是一个值得所有 AI 应用团队记住的经验：AI Agent 生成的 SQL 和人类写的 SQL 不一样，标准基准跑得再好，也不代表生产没问题。
案例二：30MB 的上下文到底该存在哪里
第二个案例是 Plaud，一家 AI 硬件公司，产品是 AI 笔记硬件，全球超过 150 万用户。
如果说案例一讲的是"Agent 数量与成本模型"，Plaud 讲的则是"长上下文和多媒体数据的存储架构"。
问题的本质：不是没地方存，而是存储架构太绕
Plaud 的 context 很长，最长大约 30MB 到 50MB，主要是文本和音频。按照传统做法，这类大对象不会直接进数据库，而是进对象存储（S3），数据库只存元数据。
但一旦原始数据和元数据分开，工程问题就排着队来了：
一致性问题。 数据在 S3，索引在数据库，任何修改、覆盖、删除都要自己保证两边一致。实际上，很多线上故障就死在这个环节。
性能问题。 S3 吞吐高但延迟也高，于是业务不得不再加一层缓存。但缓存并不能消灭问题，因为很多查询仍然会穿透。再加上 bucket 文件越多，枚举和查询越慢，长尾延迟会变得非常难看。
最终你得到的是一套"对象存储 + 元数据库 + 缓存层 + 一致性补偿"的复杂链路。能跑，但脆弱。
范式变化：把长上下文收回数据库
我们给 Plaud 的方案不是"继续优化这条链路"，而是改变范式：很多长 context 可以直接存在数据库字段里。
在真实生产中，TiDB 的单字段可以支撑到 100MB 量级。这意味着用户的整段交互上下文——包括音频转写文本——都可以直接落在数据库中。事务性、一致性、SQL 查询能力全部保留，那套复杂的 S3 + Meta 拼接链路就可以大幅简化。
这里需要强调一点：重要的不只是"能存长"，而是"在能存长的同时，仍保留 SQL 和事务能力"。 如果只是换成某种偏 AP 的系统，当然也能塞大对象，但事务性和查询语义就得自己补——这不是白得来的。
一个被低估的传统能力：在线 DDL
Plaud 还验证了一个传统数据库能力在 AI 时代的价值：在线 schema 变更。
AI 原生应用的数据结构比传统业务更不稳定，schema 变更频率高得多。如果每次改表都要等锁表、等停机窗口，发布节奏就会被迫堆积，研发为了赶窗口把多个变更一起上，质量反而更差。不锁表的 DDL 让业务发布和 schema 发布可以同步推进，这在 AI 产品的快速迭代中格外重要。
案例三：分库分表做到第二十个分片之后
第三个案例是某国内头部大模型公司。
他们的产品形态更接近传统的高频对话场景，和前两个案例相比并不算"极端"。但量一大，传统方案也会碰壁。
问题：维护复杂度先于性能崩溃
他们基于 PostgreSQL 做了大量分库分表，最终做到了十几到接近二十个分片。按理说分片加下去性能还能撑，但团队先扛不住了——跨分片查询越来越复杂，schema 变更要逐片执行，监控和告警要乘以分片数，新人入职的学习成本越来越高。
这是一个很重要的判断：AI 流量不一定首先死在模型成本上，也可能先死在数据层的架构复杂度上。
顺带验证的一件事
他们的单条 context 没有 Plaud 那么长，大约几 MB 级别，但原来也是放在对象存储上的。迁移到 TiDB 后，把其中一部分 context 收回了数据库，目的很简单：简化架构。
这和 Plaud 的故事互相印证了：即便不是极端长上下文，只要 context 大到让"对象存储 + 元数据 + 分片数据库"的组合开始变笨重，把更多内容收回数据库也是合理的演进方向。
从数据库到记忆层：Agent 基础设施的下一个需求
在服务这几家客户的过程中，我们还观察到一个更深层的需求正在浮现。
前面三个案例讲的，主要还是 Agent 对数据库层的需求：结构化存储、上下文持久化和多租户隔离。但当 Agent 开始跨 session、跨设备、跨任务连续工作时，问题就不再只是"把数据存下来"，而是"如何把过去的信息在合适的时候、以合适的形式重新带回模型上下文"。传统数据库当然可以保存用户偏好、历史决策和项目资料；真正缺少的是一层面向 Agent 的记忆机制，去完成记忆的沉淀、索引、检索、筛选和注入。否则，即使数据仍然在库里，Agent 在新 session 中也很难低成本地恢复到上一次的工作状态，看起来就像每次都要从零开始。
这个观察促成了 mem9 的诞生。
mem9 是一个开源的 AI Agent 持久记忆基础设施（Apache 2.0），底层用 TiDB 做持久化和向量搜索。它以一层 REST API 暴露给 Agent 框架，提供记忆的写入、混合搜索（向量 + 关键词）、跨 session 恢复等能力。Agent 框架只需对接这一层 API，不需要关心底层的存储、索引和搜索实现。
从架构上看，这是 Agent 数据基础设施的自然分层演进：
前两层是数据系统的自然延伸，第三层是一个新的独立需求。但它并不是脱离数据库的——mem9 底层仍然依赖分布式数据库的事务性、向量搜索和弹性扩展能力。这不是"数据库不够用了所以加一层"，而是"数据库的能力通过一个专门为 Agent 设计的 API 层暴露出来"。
mem9 目前已经集成了 OpenClaw 生态，代码在 GitHub 上开源：github.com/mem9-ai/mem9。
几个实践教训
最后分享几个跨案例的经验总结。
定价模型也需要为 Agent 重新设计。
如果每个 Agent 或 session 对应一个传统云数据库实例（哪怕是最小规格），会让绝大多数商业模式难以维系。我们在案例一的场景中放弃了按实例定价，改为基于实际资源消耗的聚合计费模型。这不是可选的优化——对于 Agent 密度足够高的场景，这是前提条件。
Agent 生成的 SQL 和人类写的 SQL 是两个物种。
不要用 TPCC 或 sysbench 的结果来预判 Agent 场景下的数据库表现。Agent 的查询模式是不规则的、多变的、且往往不是最优的。上线前必须用真实的 Agent 工作负载做压测，否则一定会在切换当天遇到意料之外的慢查询。
简化架构比优化架构更有价值。
在 AI 应用的快速迭代节奏下，维护一套"对象存储 + 元数据库 + 缓存层 + 分片 + 一致性补偿"的复杂链路，运维成本和心智负担会很快变成瓶颈。如果数据库本身能承载长上下文和大对象，那么减少一层组件，比优化每一层的性能更有实际意义。
记忆将成为 Agent 基础设施的标配。
今天大多数 Agent 应用还在"无状态"模式下运行——每次对话独立，没有跨 session 的连续性。但随着 Agent 开始承担更复杂、更长期的任务（比如持续运营一个网站、跟进一个客户关系），跨 session 的持久记忆就会从"nice to have"变成刚需。这是我们启动 mem9 的原因，也是我们认为 Agent 数据基础设施下一个必须补上的能力。
写在最后
过去一年的经历让我们形成了一个核心判断：AI 时代的竞争优势不在模型大小，而在数据基础设施能否支撑 Agent 的工作方式。
当数据库的主要用户从人类变成 Agent，数据库不再是一个被动的存储系统，而是 Agent 的操作底座——它们在上面创建、查询、分支、合并、销毁，像使用一个可编程的基底。
这对数据库行业是一次根本性的范式转移。而我们的经验是：不要试图用旧架构"兼容"新需求，而是从 Agent 的工作方式出发，重新思考数据库应该是什么样的。
值得一提的是， TiDB Cloud 与即将上线的“平凯数据库云服务”技术同源，平凯数据库云服务面向中国市场，通过主流云厂商适配与本地化服务，让中国客户无需试错，即可享受经全球头部客户考验、百万生产集群大规模长期验证的云数据库服务。二者体验一致，无论企业是深耕国内市场还是开拓海外业务，都能以统一技术栈，高弹性伸缩来灵活应对海量数据处理与 AI 创新需求。平凯数据库云服务将于 2026 年 4 月 1 日上线！
作者简介
黄东旭，TiDB 联合创始人兼 CTO，TiDB / TiKV 核心作者。在分布式系统和数据库架构领域有超过 10 年经验。近期关注 AI Agent 数据基础设施方向，主导了开源项目 mem9（github.com/mem9-ai/mem9）和 db9（https://db9.ai）
参考资料
TiDB X 架构设计：The Making of TiDB X — Origins, Architecture, and What's to Come
mem9 开源仓库：github.com/mem9-ai/mem9
