过去很长一段时间，数据库的目标足够明确：把数据存稳、查快，并在业务高峰时扛住压力。
但 AI 正在改写这个命题。向量、图、多模态等新数据对象进入生产链路，GPU、RDMA 等异构硬件成为系统设计变量；更关键的是，AI Agent 开始像一位持续工作的“新用户”——它会检索、推理、调用工具，也会把任务进度、记忆和上下文不断写回系统。相比一次 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 Agent 的一次任务往往包含向量检索、结构化查询、记忆读取、数据更新和多轮工具调用。Benchmark 不应只测单个算子有多快，更要评价这些操作组合后的端到端性能，以及不同数据访问路径之间是否产生资源竞争。
多模数据需要协同访问。AI 任务常同时涉及关系数据、向量、文档甚至图数据。Benchmark 应评价混合查询下的吞吐、延迟和资源开销，而非将每种能力割裂测试。
负载与状态会持续演化。Agent 的记忆持续增长，访问模式随任务阶段不断变化。Benchmark 应设计从冷启动、稳定运行到数据增长、突发并发的多阶段负载，评价系统在变化中的性能退化、恢复能力和资源弹性。
多租户隔离必须经受真实压力。真实平台同时服务大量 Agent，负载差异巨大。Benchmark 应评价租户间的干扰程度，以及系统在有限资源下能否维持稳定的服务质量。
异常必须能够拆解。当系统表现异常时，Benchmark 应能帮助定位问题发生在哪个环节——是检索慢了、生成超时了，还是工具调用卡住了，而不是只给出一个总分。这种模块化的拆解与追溯能力，是系统从“可用”走向“可信”的关键。
AI 时代，数据库要管理的不只是数据
圆桌讨论将话题落回到研究与工程之间的关系。企业带来真实场景、复杂边界和持续的工程反馈；高校则从中抽象出可验证的问题，探索更具通用性的解法。两者之间的往复，决定了许多系统研究能否真正走进生产环境。
对研究者和工程师而言，AI 与数据库的交叉会不断带来新问题，但系统基本功仍然不可替代。理解数据表示、执行引擎、并发控制和软硬件协同，才能在新工具不断出现时，判断瓶颈究竟在哪里。
数据库的下一站，不是功能清单的继续增长，而是一场跨层重构：数据表示要适应新对象，资源管理要感知新负载，测试与测评要覆盖新边界。当数据库既能管理数据，也能更好地管理状态、记忆与任务生命周期，它才可能成为 AI 时代更可靠的数据底座。
