当AI Agent变成数据库新用户，传统架构还扛得住吗？

数据库这个行业，过去几十年的目标一直很纯粹：把数据存稳、查快，业务高峰时扛住压力。但AI正在把这道题改写得面目全非。

向量、图、多模态这些新数据对象开始进入生产链路，GPU、RDMA这类异构硬件成了系统设计必须考虑的变量。更关键的是，AI Agent正在变成一位"7×24小时在线的新用户"——它会检索、推理、调用工具，还会把任务进度、记忆和上下文不断写回系统。相比一次SQL查询，这是一条更长、更动态、也更难预测的任务链路。

在腾讯云数据库DBTalk"顶会三连击：2026国际顶会论文权威解读"上，中国人民大学张峰教授、浙江大学李环研究员、华东师范大学杨程程研究员，分别从系统演进、云原生数据基础设施、测试与测评三个方向给出了最新观察。三个议题最终汇成同一个问题：当负载被AI改写，数据库该如何重新设计？

优化不再盯着单个算子，而是整条数据路径

数据库的基本能力没有变。存储、索引、查询、事务与并发控制，仍然是系统的地基。但向量检索、RAG、模型状态这些新对象，已经很难再被视为外围能力——它们正在进入数据库内核，反过来影响数据表示、存储格式、优化器与执行引擎的设计。

张峰把视角放在数据库内核的协同演进上。过去，系统优化往往聚焦于某个算法或算子；现在，研究开始沿着完整的数据路径展开：数据如何表示、如何布局、如何移动、在哪里执行，以及在负载变化时如何保持稳定。

数据格式就是一个典型例子。以L3为例，在GPU时代，压缩率高并不等于算得快。如果沿用CPU侧编码、CPU与GPU之间搬运、执行时再解码的传统路径，压缩带来的收益很容易被数据转换和搬运成本抵消。L3因此重新设计了GPU原生的数据格式，让学习型压缩从CPU侧的离线处理，转变为能够直接参与GPU分析计算的可执行数据格式。

类似的变化也发生在向量和图数据系统中。向量数据库需要同时考虑检索、分区、负载倾斜与跨机通信；压缩图直接更新则通过前台完成轻量级局部修改、后台持续整理压缩规则，在保持压缩效果的同时兼顾在线更新与查询性能。

当数据类型不断增加、访问路径持续延长，数据库优化的目标也随之变化：不再只追求单个模块的局部最优，而是围绕真实工作负载，推动数据表示、执行引擎与异构硬件的跨层协同。

资源能拆开，弹性却不会自动发生

如果说数据库内核需要适应新的数据对象和访问方式，那么云原生数据基础设施面对的则是另一项挑战：资源边界已经逐步打开，但资源池并不会自动产生弹性。李环关注的是数据库运行方式的变化。

近几年，云原生数据库沿着存算解耦、资源池化和Serverless数据服务持续演进。持久数据与计算节点不再被严格绑定，内存、缓存以及压缩等后台任务也开始拥有更独立的资源边界。容量规划、扩缩容、查询准入和资源配置，随之从DBA的离线操作逐步转变为系统持续执行的在线决策。

不过，资源能拆开，不代表弹性问题已经消失。远程访问会带来网络开销；新节点加入后，需要完成状态恢复和拓扑收敛；缓存扩缩还会影响命中率与一致性。真正的弹性不能等负载爆发后再补救，而要在观测、预测、决策、执行和反馈之间形成闭环。

李环将这一目标概括为"快、稳、省"：

• "快"——资源能否及时到位，运行中的查询能否利用新增算力；
• "稳"——多租户、多并发场景下的准入、过载保护与服务等级目标；
• "省"——资源能否按查询需求被细粒度分配和复用。

三者并不能同时无限优化，系统需要在响应速度、稳定余量和资源利用率之间寻找合适的控制点。

Agent的出现让这道题更复杂。计算资源可以回收，但任务进度、长期记忆、执行分支和权限上下文不能随之丢失。未来的数据基础设施，需要管理的不只是CPU、内存和存储，还包括跨越多次查询和工具调用的任务状态、数据生命周期、访问关系等。

长链路任务，不能只靠单点指标证明可靠

新架构、新负载进入生产，最终都要回答一个更朴素的问题：系统究竟可靠不可靠？杨程程从测试与测评角度提出，AI时代的Benchmark需要重新定义评测对象。

传统Benchmark往往以查询或事务为基本单元。但一次Agent任务，可能同时包含向量检索、结构化查询、记忆读取、数据更新和多轮工具调用。这意味着，面向AI负载的测评至少需要覆盖5个方向：

• 评测单元从算子升级为工作流——Benchmark不应只测单个算子有多快，更要评价这些操作组合后的端到端性能，以及不同数据访问路径之间是否产生资源竞争；
• 多模数据需要协同访问——AI任务常同时涉及关系数据、向量、文档甚至图数据，Benchmark应评价混合查询下的吞吐、延迟和资源开销，而非将每种能力割裂测试；
• 负载与状态会持续演化——Agent的记忆持续增长，访问模式随任务阶段不断变化，Benchmark应设计从冷启动、稳定运行到数据增长、突发并发的多阶段负载；
• 多租户隔离必须经受真实压力——真实平台同时服务大量Agent，负载差异巨大，Benchmark应评价租户间的干扰程度，以及系统在有限资源下能否维持稳定的服务质量；
• 异常必须能够拆解——当系统表现异常时，Benchmark应能帮助定位问题发生在哪个环节，是检索慢了、生成超时了，还是工具调用卡住了，而不是只给出一个总分。

这种模块化的拆解与追溯能力，是系统从"可用"走向"可信"的关键。

数据库的下一站，是跨层重构

圆桌讨论将话题落回到研究与工程之间的关系。企业带来真实场景、复杂边界和持续的工程反馈；高校则从中抽象出可验证的问题，探索更具通用性的解法。两者之间的往复，决定了许多系统研究能否真正走进生产环境。

对研究者和工程师而言，AI与数据库的交叉会不断带来新问题，但系统基本功仍然不可替代。理解数据表示、执行引擎、并发控制和软硬件协同，才能在新工具不断出现时，判断瓶颈究竟在哪里。

数据库的下一站，不是功能清单的继续增长，而是一场跨层重构：数据表示要适应新对象，资源管理要感知新负载，测试与测评要覆盖新边界。当数据库既能管理数据，也能更好地管理状态、记忆与任务生命周期，它才可能成为AI时代更可靠的数据底座。