上周，我帮一个创业团队看他们的数据架构。他们的业务系统跑在Agent之上，每天自动做数据分析、用户画像、异常检测。我打开监控面板，看到数据库的连接数曲线像锯齿一样密集，每秒几百个请求不间断。

负责人跟我说，系统上线第一周就出事了。Agent发了一个复杂查询，查完之后根据结果自动触发了十个子查询。十个子查询又各自触发新的查询，指数级放大。5分钟之内，CPU被打满了。当时的直观感受是：数据库面对的不再是一个人在问问题，而是一群Agent在互相追问。

这件事引出一个需要认真思考的问题：当向数据库提问的主力从人变成Agent，数据库本身会发生什么变化？

查询行为：从“人问”到“Agent追问”

人查数据和程序查数据，本质上是两种不同的行为模式。

人查数据有天然的刹车机制。打开工具，想清楚要什么，写SQL，跑一下看结果。发现不对，停下来想一想，改一改再跑。每一步都有人在判断，整个过程慢但可控。

Agent没有刹车。它拿到查询结果后，会在极短时间内自动决定下一步动作。可能是继续查，可能是做推理，也可能是根据结果触发新的查询。一个Agent发出去的不是一条独立的查询，而是一串连锁反应。当这种连锁反应同时发生在几百个Agent身上，数据库承受的压力和以前完全不在一个量级。这就逼着数据库自己做判断。

传统优化器：依赖离线统计信息

以前的查询优化器靠的是统计信息。表有多少行、索引基数多少、数据分布怎么样，优化器拿这些统计信息算成本，选一条看起来最便宜的执行计划。问题是统计信息是离线的快照。数据在变，统计信息不跟着变。一张表从一万行涨到一千万行，优化器还是按一万行的统计信息选计划，结果就是全表扫描走了哈希连接。一条本来该几秒跑完的查询要几分钟。

传统做法是DBA发现慢了，手动加hint纠正，或者手动更新统计信息。

AI优化器：建立反馈回路，动态调整

AI优化器的做法是建一个反馈回路。每条查询执行完后，优化器会把实际执行时间和预估时间做对比。如果实际耗时远超预估，就把这个偏差记下来，更新自己的成本模型。下次遇到类似的查询模式，优化器不会再用旧的统计信息算成本，而是用修正后的成本模型重新选计划。它学的不是“这条SQL该走哪个索引”，而是“这类数据分布下，哪种Join策略更划算”。

生产环境跑下来，复杂查询的加速效果肉眼可见。有测试场景里，多表关联的查询时间能缩短一个数量级。数据库不再只是被动执行命令，它开始根据实际运行情况调整自己的策略了。

数据碎片化：Agent拿不到完整上下文

另一个让人感触很深的变化是数据形态。

以前做项目，业务数据基本都是结构化的，订单、账户、流水，字段清晰，类型固定，丢进关系型数据库就行。现在的情况是，文本、图片、音视频、向量嵌入这些非结构化数据在核心系统里的体量早就超过了结构化数据。问题在于，Agent要理解一个业务的完整上下文，需要同时拿到好几类数据。关系型数据库存业务数据，对象存储管文件，向量数据库管embedding，数据分散在好几套系统里。

Agent要拿到完整信息，就得跨系统查询、在应用层拼装数据。这导致延迟高，一致性差，运维还得盯好几套集群。不少团队都被这个问题折腾过。一个业务场景要同时查关系表、做向量检索、调大模型API，光是跨系统的数据同步链路就写了十几个定时任务，出了问题排查起来要翻三四个系统的日志。

解决方案：多模融合

所以多模融合这个方向最近很热。核心思路是在同一个存储引擎、同一个事务框架下让多种数据类型共存。关系型、文档型、向量型、空间型、时序型放在一张表里定义，共享同一套事务日志。一条SQL就能同时做精确匹配和语义相似度搜索，数据不用在不同系统之间搬来搬去。

实测过KingbaseES，它在关系型数据库基础上融合了JSON文档、向量、GIS空间、时序这几类处理能力。多种数据类型在同一张表里定义，事务和备份走同一套链路。做跨模查询的时候，一条SQL同时涉及关系数据和向量检索，不用跨库协调，优化器自己会选执行路径。

Agent要拿到完整的业务上下文，数据如果分散在五套系统里，拿到的上下文就是碎的。这是多模融合要解决的根本问题。

交互方式：从“写SQL”到“说人话”

这个变化写代码的人感受最深。以前用数据库的流程是理解业务需求，翻译成SQL，跑查询看结果，不对就改SQL再跑。一个复杂报表折腾半小时很正常。现在有人在对话框里直接打字提问，数据库自己理解意图、生成执行计划、跑查询、返回结果。翻译成底层SQL大概是这样的：

SELECT category, SUM(amount) as total
FROM orders
WHERE region = '华北' AND user_id IN (  SELECT user_id FROM user_metrics   WHERE repurchase_rate > 0.3 AND month = '2025-11')
GROUP BY category ORDER BY total DESC LIMIT 3;

NL2SQL降低了数据库的使用门槛。以前只有DBA和资深后端能高效用数据库，现在产品经理和运营可以直接提问。但这件事背后有个很多人忽略的关键技术：语义层。语义层就是在数据库上面加一层翻译，把业务指标、计算逻辑、数据关系翻译成Agent能理解的东西。

Agent问“本季度高价值客户的留存率怎么样”，语义层得先搞清楚“高价值客户”的判断标准、“留存率”的具体口径，然后再翻译成底层查询逻辑。这层做不好，查出来的数据是错的，而且错得很合理，因为Agent确实按你说的查了，只是你说的和你想的根本不是一回事。

去年踩过这个坑。给一个客户配语义层，把“活跃用户”的定义映射成了最后登录时间，而不是实际的活跃行为。结果查出来的日活比实际多了两万多。业务部门拿着报表来找人，对着两条数据对了一下午才发现是语义层的口径写错了。

做AI加数据库的时候，花最大力气的往往不是底层引擎，而是上面那层语义理解和映射。

核心挑战：确定性与概率性的共存

一个绕不开的问题摆在面前：这些东西听着都挺好，生产环境能跑稳吗？这才是最难的地方。数据库追求的是确定性，同样的输入永远得到同样的输出，一笔交易、一个账户余额一分钱都不能差，这是数据库过去几十年一直在死磕的东西。但Agent的行为是概率性的，它生成的下一个token没法提前预知，整个系统的行为模式随时在变。

数据库要在一个概率性的环境里依然保证数据不出错、事务不丢，这对架构设计提出了全新的要求。

问题的核心在于，Agent会改变查询的语义和复杂度。同一条自然语言查询，Agent可能今天翻译成简单的等值JOIN，明天换成多表子查询。查询模式的不可预知意味着数据库不能像过去那样依赖预编译的执行计划。

应对方向

应对这个问题的方向有几个：

• 查询级别的并发控制和资源隔离：给每个Agent分配独立的连接池和内存上限，防止一个Agent的复杂查询拖垮整个集群。
• 执行计划的稳定性保护：当优化器发现某类查询模式反复出现时，可以锁定一个稳定的执行计划，避免每次都要重新选路。
• 语义校验层：在Agent的查询真正落到数据库之前，先做一次结构检查，确认它不会产生笛卡尔积或者扫描全表。

同时搞定数据库的工程确定性和AI的概率性，这件事难度很高。国内在这件事上有一个好处：场景多，场景复杂，大量真实业务需求在倒逼数据基础设施创新。而且，全球对AI数据库的探索还在早期，技术路线没有定型，大家都在试。不像传统数据库时代，海外厂商用几十年建起来的生态壁垒让人追不上。这次起跑线差不了太多。

总结：Agent驱动的数据库新范式

回到开头那个创业团队的问题。后来他们做了两件事。一是给Agent的查询加了并发限制和超时熔断，防止指数级放大。二是把原本分散在三套系统里的数据迁到了一个多模数据库上，跨模查询直接在库内完成，不用再在应用层拼装。问题暂时压住了，但负责人说，他知道这只是治标，真正的问题是：怎么让数据库在一个被Agent驱动的世界里，既快又稳。

Agent来了之后，数据库的变化可以总结成三个方向：

• 使用者：从人变成程序。
• 数据形态：从单一的结构化变成多模态。
• 交互方式：从写SQL变成自然语言。

这三件事叠加在一起，正在重塑数据库的架构设计。中国数据库技术因为场景丰富、格局未定，第一次有机会参与定义下一代数据库的范式。能走多远，真实的业务场景会给出答案。

《夸克》非常好用的免费AI浏览器

下载APP查看