2026-03-27 15:21
扫码打开虎嗅APP
本文来自微信公众号： InfoQ ，作者：黄东旭，原文标题：《当数据库的主要用户不再是人类：我们在 AI Agent 场景下的架构实践与思考》
过去一年，我们在TiDB Cloud上观察到一个趋势性变化：每天新创建的数据库集群中，超过90%不是由人类创建的，而是由AI Agent自动发起的。
这不是某个极端客户的个例，而是正在成为常态。Agent创建数据库、生成schema、写SQL、跑实验、销毁数据库——全程不需要DBA介入，甚至不需要人类知道它发生过。
这个数字迫使我们重新审视一个根本问题：当数据库的主要用户从人类变成AI Agent时，过去二十年我们围绕"人类使用数据库"所构建的一切假设——容量规划、schema设计、运维流程、定价模型——还能成立吗？
这篇文章不打算做产品介绍。我想分享的是过去一年里，我们在服务几家AI公司时遇到的真实挑战、做出的架构决策、以及踩过的坑。这些经验或许对正在构建AI 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不一样，标准基准跑得再好，也不代表生产没问题。
第二个案例是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开始跨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数据基础设施下一个必须补上的能力。
8写在最后
过去一年的经历让我们形成了一个核心判断：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
