当 Agent 成为数据库的主要用户，数据底座该如何重写？——从阿里云ApsaraLakebase的产品定位，看 “Data Gravity” 虹吸效应

进入2026年，围绕AI Agent部署的工作负载，正上演一幕耐人寻味的“反差”！

一方面，大模型仍在快速迭代，推理成本不断下降，头部模型之间的能力差距在逐渐收窄；另一方面，数据资产的定价逻辑正在被重估——无论是Databricks的估值飙升，还是Snowflake的战略转身，都在说明数据湖仓厂商的估值与战略重心变化；以及阿里云CTO 李飞飞在多个公开场合强调“Data Gravity”这一概念，指出数据平面能力是“护城河”。所有的这些，都在指向同一个判断：当模型能力趋于同质，数据的组织方式与流动效率，才是定义AI后半赛道话语权的“终极筹码”，才决定谁能把 AI 真正用起来。

恰在此时，阿里云传来一个标志性事件：在《IDC MarketScape：中国 Data Agent 2026 年厂商评估》中，阿里云位居领导者象限最领先位置（TOP1）——18 家参评厂商中仅 4 家进入领导者，支撑这一结果的重要产品之一便是阿里云数据库团队的AIDBSData Agent产品。阿里云CTO 李飞飞表示：“AI 进入智能体大爆发的阶段，有一个关键词一定会成为主流——Data Gravity。AI 要做复杂的工作，更要在企业的实际工作中产生最大价值。”而“Data Gravity”在产品层面的具体形态，正指向数据被持续调用后形成的虹吸效应。

承接这一趋势的不止AIDBS（AI 原生数据库服务）。如果说AIDBS 回答的是“业务用户怎么用上数据”，那么另一条线索指向数据层本身——ApsaraLakebase。它在今年上半年公开亮相、又在8月阿里云数据库团队举办的Agentic DB Day上被进一步推至台前。阿里云给它的定位很克制但也很明确：AI时代的数据底座，而非又一款数据库产品！

那么问题来了：阿里云为什么选择在这个时间节点推出ApsaraLakebase？Agent的爆发，究竟给底层基础设施带来怎样的范式冲击？而即将到来的云栖大会，阿里云又会有哪些重磅发布和叙事，进一步深入数据引力的故事？

线索其实已经露在公开信息里。阿里云数据库团队此前提到，也在多个公开渠道透出，今年即将到来的云栖大会上，他们要一站式讲清一件事——Agent需要的到底是怎样的数据库，其中数据层的部分，正是 ApsaraLakebase 的故事。

带着这些问题和信息，笔者在阿里云谷园区，见到了阿里云数据库产品事业部产品管理与技术架构部负责人王远（花名：惊玄），那天恰好是他在阿里的八周年纪念日！

阿里云数据库产品事业部

产品管理与技术架构部负责人 王远

当Agent敲响了新数据底座的“门”

“Agent直接管理数据库的比例，或者说增速，远超我们想象。” 采访一开始，王远首先抛出了一个正在发生的事实！

王远认为：ApsaraLakebase是新时代的产物，是承载Agent工作负载的最强大底座，这个进程不是缓慢地演进，而是在快速接管。

他关注的不只是数据本身。

Agent正在把信息技术从专属的行业圈层推向更广阔的公众视野，但这种"出圈"也给底层基础软件从业者带来了全新挑战，是另一重压力：操作系统、数据库、编译器始终是整个信息系统的核心底座，AI和Agent的运行一刻也离不开这些Infra的支撑。可如今，大众的注意力都在AI 应用层，底层基础软件反而被"隐身"，被包裹在AI的光环之下。在这样背景下，阿里云数据库团队开始深度思考：产品设计该如何与新型AI应用结合？到底做出什么样的迭代，才能保持核心生命力？

第一个要明确的是，这个新的能力底座到底要服务谁。阿里云数据库团队内部原本设定了一个目标：到2026年9月30日，25%的数据库实例由Agent直接管理。结果是什么？远超预期，采访时这一比例已经突破50%了，如果只看新增的数据库实例，这个比例更高，达到80%。也就是说，今天新开出的数据库实例里，Agent占了大头，纯由人开通的反倒是少数。这说明：Agent已经成了数据库的“主力用户”，它已经从过去的“能聊天”走到“能做事”，可以像一个7×24的数字员工一样，自己规划、执行，并且交付结果。

第二个要弄清的是人和Agent的差异，而这种差异非常具体。人朝九晚五，Agent可以全年无休；人操作数据库小心翼翼，Agent会瞬间拉起成百上千个实例去试错；人改完一条数据，再登录另一个系统做分析，中间有分钟级的延迟，而Agent改完就要求毫秒级的分析响应。

更棘手的是“数量”带来的成本。一个企业级应用背后，可能有几十个Agent在同时工作。如果每个Agent独占一个数据库实例，成本会像“火箭”一样蹿升，成倍上翻。所以这种情况下，Serverless和多租户形态不再是可选项，而是必须全力跟进的能力项。毫无疑问，人与Agent访问数据库的最本质区别，除了行为模式，就是成本结构。

数据库因此必须变。怎么变？王远和他的团队对ApsaraLakebase做的，是架构层面的重新思考！

ApsaraLakebase是什么？一次架构层面的重构

最初的路线是渐进式的。阿里云数据库团队选择在成熟的PolarDB产品之上，迭代ApsaraLakebase相关特性，走渐进式适配Agent场景的改良路线。但过去大半年的落地实践给出了另一个答案，让他们清晰地看到：仅在现有数据库产品上叠加适配能力，无法完全释放出Agent场景的全部潜力，必须为Agent量身定制一款原生适配其工作负载的全新数据底座。

转向的动因是成本。传统数据库在Agent 场景下，存储与运维开销会随实例数量快速抬升。ApsaraLakebase 的应对是基于云原生共享底座构建，支持海量 Agent 租户的隔离挂载，把 Agent 数量增长带来的开销控制在可预期的范围内——用王远的话说，是“数据不搬家，一次入湖，处处可用”。

过去，结构化数据进数据库，图片、视频、文档等非结构化数据进对象存储。不同系统各管各的，Agent要用就得来回倒腾。ApsaraLakebase 换了一个思路：所有数据，不管什么结构，统一放在对象存储里，只存一份，再在其上叠加缓存、引擎、语义与接口能力等。

ApsaraLakebase具体分层如下：

第一层：存储层——基于对象存储构建。成本低、可承载海量数据，实现“一份数据、多索引适配”，满足多样化数据访问需求，并提供多模态数据处理、统一数据管理与元数据管理能力。在云与AI深度融合的时代，对象存储已经成为企业级数据底座的通用选择，也是当前业界性价比最高的存储基础设施。任何数据类平台和产品，如果不能充分释放对象存储的核心优势，在云与AI驱动的产业环境中，就很难长期保持核心竞争力。这一判断决定了产品从规划之初就将对象存储能力深度整合进来，把对象存储作为核心存储底座。

第二层：缓存加速层——补足在线业务访问的性能短板，让上层的在线业务和智能体应用都能获得流畅稳定的访问体验。

第三层：开放引擎层——把阿里云现有的数据库引擎全部接进来，包括：PolarDB、AnalyticDB（ADB）、Lindorm、RDS、Tair、MongoDB等。ApsaraLakebase虽然是一个新型能力底座，但在这一层的用意并不是要推翻企业已有的数据资产，而是通过开放引擎层，让企业的全域数据资产，所有存量数据库、历史数据资产都能平滑接入，最大程度降低企业的迁移和改造成本。

第四层：Agentic Schema抽象层，是整个架构的核心创新层。传统数据库沿用实体关系模型定义Schema，这套逻辑适配人类开发者的习惯，但和Agent的行为模式天然存在认知鸿沟：Agent需要一套完整的机制来完成知识组织、上下文串联、长期记忆管理。Agentic Schema层就是为了打通这道鸿沟，定义了从多模态原始数据，到企业级标准数据Schema，再到Agent的上下文、记忆库、知识库的全链路转化与管理规则，目的是让Agent能真正“读懂”数据。

第五层：面向Agent的访问接口层，回应的是另一个现实：传统数据库以SQL作为核心访问语言，但SQL作为结构化查询语言，早已跟不上数据库承载全类型、多模态数据的演进节奏，如今主流数据库都在兼容KV、Document等多元接口。沿着这个趋势，ApsaraLakebase提出了Agentic Query Language，将构建以自然语言为核心、遵循标准化交互范式的Agent专属查询接口，同时配套一系列预置Skills与工具，打通数据库周边的完整生态，把Agent访问数据的门槛降到尽可能低。

第六层：直接面向终端用户的应用层。数据库不再只作为底层基础设施被开发者二次封装，而是直接长出面向终端用户的Data Agent能力。未来绝大多数应用都会以智能体的形态存在，终端用户只会感知到“能帮自己完成任务的Agent”，不会感知到底层数据库的存在。

沿着这六层能力和技术判断，ApsaraLakebase规划原生搭载一系列数据类Agent：运维管理Agent，通过对话窗口或者极简CLI，就能让Agent完成全部运维管理操作；资产盘点与数据分析Agent，自动梳理全量数据资产梳并执行自定义数据分析，无需人工编写复杂查询语句；数据应用开发Agent，用自然语言提出需求，Agent会自动盘点存量数据、生成适配业务的Schema，主动确认业务峰值TPS、QPS等核心指标，并联动代码生成，覆盖从需求梳理、研发测试到上线部署的全流程。

“三层”战略：从应用层到基础设施的重构

ApsaraLakebase的能力边界，明显已超越传统数据库的范畴：它让已有的数据库长出了Agent，拓宽了原有的数据库边界。但这也带来了一个容易混淆的问题：ApsaraLakebase和阿里云的另一款产品AIDBS（AI 原生数据库服务），有啥区别，究竟有什么关系？

“AIDBS和ApsaraLakebase，是两款产品，但它们不是左右互搏，而是‘双向奔赴’。” 王远这样解释两者的定位。

AIDBS的定位是“以数据库为底座的数据Agent平台”。它交付的是Agent形态的能力，比如：数据安全Agent、运维Agent、分析Agent、数据处理Agent；它不交付数据库实例，用户不需要关心底层一共用了多少个数据库。它的用户是业务人员，是那些不熟悉SQL和索引，但懂业务、懂数据价值的人。

而ApsaraLakebase的路径正好相反。它从数据库原有的生态出发，在已有的数据库之上生长出Agent能力，它的用户是开发者、是技术人，是那些懂数据但不一定负责业务语义的人。

因此，两者是阿里云面向Agent 场景的两个不同切入点。也就是说，AIDBS和ApsaraLakebase是阿里云面向Agent场景打造的两个重要“抓手”。AIDBS是面向更广阔的业务侧人员，而ApsaraLakebase面向的是相对专业的数据技术从业者。用王远的类比，这就像“大航海时代”的两条航线：一条沿现有海图推进，逐步扩大版图；另一条登船远航，去寻找新大陆。终点相同——让数据不再需要「翻译」，让 Agent 和业务人员都能直接使用数据。

沿着ApsaraLakebase 这条线索，阿里云数据库在即将到来的云栖大会上开设了三场分论坛，共用同一条主线——Agent-Native 数据库：重新思考面向企业级Agent 服务负载的数据处理平台系统设计，把数据库打造成Agentic AI 时代的一体化多模数据底座。三个分论坛自上而下逐层展开：为Agent 重塑Data Agent生态（Data Agent as Service）、为Agent 重构数据库（Agentic Database）、为Agent 重做数据层（ApsaraLakebase & 多模态数据管理）。 这里先来个提前剧透：

第一层，叫Data Agent as Service——数据库Agent化，即把数据库的所有能力全部Agent化。阿里云现在的控制台已经上了Copilot助手。未来演进到极致形态，控制台可能就没了，取而代之的是一个CLI，或者干脆就是一个对话框。所有数据库的运维、管理、配置能力，全用自然语言搞定。

第二层，叫Agentic Database——智能体化的数据库。这一层指向数据库内核本身，Agent带来的工作负载与人不同： 7×24小时运行，会短时间内拉起大量实例做探索和试错，这些操作未必都对，其中相当一部分操作可能需要回滚、要订正、要快速备份恢复。这些冲击，都要由内核直接来承接，内核得扛住。

第三层，软硬融合的数据底座。从整个数据基础设施的技术栈来看，越往下，越依赖一体化融合能力——硬件成本持续上升，单靠软件层优化已不足以覆盖。阿里云数据库团队还在探索CXL高速互联、远程内存访问、一体机等方向，努力把硬件的每一分潜力都榨出来，提升硬件资源的实际使用率。

正是这三层：数据应用层、数据内核层、数据Infra层，共同构成了阿里云数据库在AI时代的战略框架，最终指向一个核心愿景：打破数据库长期以来只服务专业开发者的边界，让数据库真正触达更广泛的终端用户，完成基础软件在AI时代的彻底“蝶变”。

都在推湖库一体，阿里云有啥不一样？

Lakebase这个概念并不是阿里云的独创，Databricks最早提出，此后多家厂商陆续跟进。那么，阿里云的差异化基础是什么？

“数据库不是设计出来的，是用出来的。如果要作为行业的领导者、标准的制定者，你首先规模得在行业里领先。规模不够，定义标准就是纸上谈兵。”王远亮出的“王牌”是“用出来的规模”。

这个规模有两层含义。

一是存储侧，不可否认，阿里云数据库的工程化能力，在业界处于引领者地位。作为云厂商，对象存储本身承载了大量用户，规模摊薄了单位存储成本。

二是引擎侧，阿里云数据库产品家族的广度以及市场覆盖能力很广。阿里云数据库在亚太地区连续多年市场份额第一，PolarDB、ADB、Lindorm、MongoDB、RDS、Tair等产品构成的完整的引擎矩阵，可以整体接入ApsaraLakebase。覆盖的场景类型和积累的工程问题数量，构成了产品迭代的输入。

也就是说，ApsaraLakebase也不是从零起步，不是凭空长出来的，是底层能力多年沉淀的结果。底层的PolarStore、PolarLakeCache等能力，都来自PolarDB多年的积累；而在存储层和缓存层的攻坚上，工程实践和长期打磨比技术本身更重要。数据底座的许多能力过去跑在RDMA上，现在跑在CXL上——硬件在变，能力在复用。

落到使用者身上，ApsaraLakebase的这套设计给出了两种体验：

对于开发者来说，ApsaraLakebase提供数据汇聚、元信息统一、语义抽象统一的一站式接口，SQL 与自然语言并行支持，减少为使用数据而附加的技能成本。我们不需要学那么多数据处理技能，可以把更多精力放在业务上。

对于不具备技术背景的用户，ApsaraLakebase会提供一系列Agent，覆盖数据安全、运维、数据分析、治理——让懂技术的人去写代码，而不懂技术的人，可以通过自然语言使用数据，创造价值。

采访结束时，王远呼吁大家：云栖大会期间一定要去阿里云数据库的展台、论坛去看看。他提到一个细节：今年数据库的展区、论坛等，和往年不一样，不再按产品分类，不再按传统的TP、AP、NoSQL等产品域划分，而是按“用户视角”组织，重点呈现AI应用如何切入、数据如何流转、底层基础设施如何构建。这一细节变化背后，正是开篇提到的“Data Gravity”数据引力的鲜活注脚。

从某种角度来看，阿里云数据库产品分类在云栖大会的展台和论坛上的消失，不只是陈展方式的调整。她对应的是数据底座定位的迁移，是数据底座下一个十年演进的风向标：数据库不再把自己限定为存放数据的容器，而是让自己成为数据引力的“增强器”——让数据更容易被汇聚、被理解、被Agent访问、被业务使用。数据越容易被调用，它的价值就越高，围绕它运转的应用、智能体与场景就越多，这正是开篇所说的Data Gravity 在产品层面的具体形态。这，也许就是Data Gravity 的“虹吸效应”。

沿着这个方向看，“数据库”中的这个“库”字会逐渐退到背景里，它会以最夯实的底座形式，让数据成为真正的引力源，它不再臣服于任何技术门类的划分，而是反过来吸引一切能力向它聚拢。