上周，我为一个创业团队审查其数据架构，发现他们的业务系统基于Agent运行，每天自动执行数据分析、用户画像构建和异常检测。当我打开监控面板时，看到数据库的连接数曲线如锯齿般密集，每秒承载着数百个不间断的请求。

负责人告诉我，系统上线仅一周便出现了问题。Agent发起了一个复杂查询，随后根据结果自动触发了十个子查询，这些子查询又各自生成了新的查询，导致请求呈指数级放大，短短5分钟内便耗尽了CPU资源。当时的直观感受是：数据库面对的已不再是单个人的提问，而是一群Agent在相互追问。

这一事件引出了一个需要深思的问题：当数据库的主要查询者从人类转变为Agent时，数据库本身将发生哪些变化？

查询行为的根本改变

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

人类查询数据拥有天然的“刹车”机制。打开工具，理清需求，编写SQL，执行查看结果，发现错误后暂停思考，调整后再运行。每一步都有人为判断介入，整个过程虽然缓慢但可控。

Agent则没有这种“刹车”。它获取查询结果后，会在极短时间内自动决定下一步操作，可能是继续查询、进行推理，也可能根据结果触发新的查询。一个Agent发送的并非单一查询，而是一连串的连锁反应。当这种连锁反应同时发生在数百个Agent身上时，数据库承受的压力与以往完全不在一个量级，这迫使数据库自身必须做出判断。

传统的查询优化器依赖统计信息，例如表行数、索引基数、数据分布等。优化器基于这些统计信息计算成本，并选择一条看似最经济的执行计划。然而，问题在于统计信息是离线的快照。数据在不断变化，而统计信息未能同步更新。一张表从一万行增长到一千万行，优化器可能仍依据一万行时的统计信息选择计划，结果导致全表扫描，本应几秒完成的查询耗时数分钟。传统做法是DBA发现性能下降后，手动添加hint或手动更新统计信息。

AI优化器的做法是构建一个反馈循环。每条查询执行完毕后，优化器会将实际执行时间与预估时间进行对比。如果实际耗时远超预估，系统会记录这个偏差，并更新成本模型。下次遇到相似的查询模式，优化器不再使用过时的统计信息，而是基于修正后的成本模型重新选择执行计划。它学习的不是“这条SQL应该走哪个索引”，而是“在这种数据分布下，哪种Join策略更高效”。

在真实生产环境中，复杂查询的加速效果显著。在某些测试场景中，多表关联查询的时间甚至可以缩短一个数量级。数据库不再被动地执行命令，而是开始根据实际运行情况动态调整自身策略。

数据碎片化的代价

另一个深刻的变化体现在数据形态上。

过去做项目时，业务数据基本上是结构化的，如订单、账户、流水等，字段清晰，类型固定，适合存放在关系型数据库中。如今，文本、图片、音视频、向量嵌入等非结构化数据在核心系统中的体量已远超结构化数据。问题在于，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到来后，数据库的变化可总结为三个方向：使用者从人类变为程序，数据形态从单一结构化变为多模态，交互方式从编写SQL变为自然语言。这三件事叠加在一起，正在重塑数据库的架构设计。

中国数据库技术因场景丰富、格局未定，首次有机会参与定义下一代数据库的范式。能走多远，真实的业务场景会给出答案。