“AI 原生数据库”正在分裂成两条路线：向量是标配，Agent 才是分水岭

“支持向量检索”在 2026 年已经不再是一个有区分度的能力。DB-Engines 2026 年 10 月的流行度排名显示，前四的关系型和多模型引擎——Oracle、MySQL、SQL Server、PostgreSQL——都已经原生或通过 pgvector 等扩展加入了向量类型或向量搜索。向量检索正在变成数据库的标配功能，就像 2010 年代的 JSON 支持一样，从“卖点”变成“基线”。

真正的分化发生在下一个层次：数据库是继续做“被应用调用的存储”，还是把自己变成“Agent 可以直接操作的数据底座”。

阿里云 PolarDB-X v2.5.0 在 2026 年 10 月开源的路径代表了第一条路线的深化：在 DN 层新增原生 VECTOR 数据类型和基于 HNSW 的向量索引，同时加入 AI Function，允许在同一条 SQL 里完成关系过滤、语义检索和文本推理，不需要外挂向量库，也不需要引入 AI SDK 或自建推理服务。它的核心叙事仍然是“一体化”：把向量检索和关系查询放进同一个执行引擎，让开发者用 SQL 表达混合负载。华为云在同期的数据库升级中给出了另一组数字：GaussDB 的混合搜索延迟从 10 秒降到 50 毫秒，向量容量从 10 亿扩展到 100 亿以上；TaurusDB 的自研向量引擎在向量-标量混合搜索上比开源方案快 2 倍。这些进展是真实的，但它们解决的是“检索效率”问题。

华为云同期提出的“Agent-Native 数据库”叙事指向了一个不同的方向。它的核心判断是：Agent 时代正在把架构从“以应用为中心”推向“以数据为中心”，数据库需要为高频 Agent 访问、分支管理、语义访问这些新的访问模式重新设计。PolarDB-X 的 AI Function 虽然形式上是一条 SQL 函数，但它隐含的范式是：数据库不再只是被动的查询执行者，它可以主动调用模型完成推理、分类、抽取、摘要，把一部分原本属于应用层的逻辑吸收到数据层。

这两条路线不是互斥的。向量索引是共同的基础设施，AI Function 和 Agent-Native 是站在这个基础设施之上的不同抽象层。但它们在工程含义上有一个关键差异：如果数据库只是“更快地做向量检索”，应用仍然需要自己编排 Agent、管理记忆、处理工具调用；如果数据库真的走向 Agent-Native，它就要承担多租户隔离、数据分叉、会话状态这些原本属于应用层或中间件的职责。

一个务实的判断是：向量能力在 2026 年不应该再作为选型的首要区分点，因为主流引擎都有或者很快会有。真正的选型问题是：你的 Agent 工作负载需要数据库承担多少“主动”职责。如果只是需要在一个查询里混合关系过滤和语义相似度，PolarDB-X 和 GaussDB 的能力已经够用；如果 Agent 需要频繁地读写状态、试错、回滚、在多个分支上并行探索，那么“数据库能不能被当作 Agent 的状态底座”就会变成架构设计的核心问题，而不是一个功能清单上的勾选项。