9 月 22 日，阿里云数据库在云栖大会上推出 Agent Context、ApsaraLakebase 两大重磅新品，并对 AI 原生数据库服务（AIDBS）进行全新升级。
主论坛上，阿里云智能集团研发副总裁、数据库产品事业部负责人杨辛军（Jimmy）公布了这样一组数据：
过去 1 年阿里云 RDS PostgreSQL 的新增实例数量，已同比增长超过 400%+。其中，约 80% 新增实例由 Agent 所创建，Agent 访问流量占比正在快速接近 50% 的目标。这意味着，越来越多的数据库不再由人类创建，而是由智能体自主完成。
一边是半个世纪以来"人类设计、人类使用、人类维护"的数据库范式；另一边是一个正在快速生成的新世界：Agent设计、Agent使用、Agent维护，人类退到后面，变成规则的制定者和边界的守护者。
当数据库的主要用户从人变成 Agent，数据底座应该如何重写？阿里云为什么要在Agent 时代重新定义数据底座？数据库的形态、交互方式与运维模式又将发生怎样的变化？
会后，CSDN 与杨辛军（Jimmy）进行了深入交流，试图找到这些问题的答案。
不只是用户变了
理解阿里云数据库的选择，要先理解一个前提：为什么为人类设计的数据库，难以适应Agent 时代的负载？ 作为职业生涯亲历了数据库从传统软件走向云原生服务、如今又迈向 Agent Native 时代的技术领袖，Jimmy 对这一变化有着切身的体会。
"我最早在 Oracle 做 MySQL，那是传统商业数据库的时代，数据库是一个高大上的、需要呵护的、需要专门有 DBA 来管理的系统软件。" Jimmy 回忆道。
然后是云原生时代，存算分离、Serverless、弹性伸缩成为关键词。到了云原生时代，大部分人，包括传统的软件工程师，都可以直接开始使用数据库了。
而现在是 Agent 时代。以后随着 AI 的演进，可能连 SQL 都不需要写了，直接用自然语言来问，后面有 AI 自动帮你转成 SQL 。
Jimmy 认为，这不仅仅是交互方式的改变，更是数据库角色定位的根本性转变。人类用数据库，讲究精确、严谨，需要理解 schema、约束条件、事务边界；而 Agent 用数据库，讲究意图理解、自主决策与容错能力。它可能不会像人一样精心设计查询，而是直接以自然语言提出模糊需求，甚至会在一次任务中连续发起数十次查询。
"数据库会变得更普遍、更简单、更自动化。从复杂的系统软件，变成像水电煤一样的基础设施。"那么，Agent 用数据库，和人用数据库，到底有什么不同？
"机器访问数据库不是一件新鲜事。"从程序通过 JDBC 连接数据库的那天起，机器就在访问数据库了。但 Jimmy 说，Agent 和传统程序操作数据库有本质区别。
他用一个具体场景说明。阿里秒悟（Meoo）是一个 AI 创建网站的工具，客户只需要说一句"帮我创建一个售货网站"，它就自动生成一个数据库，在后端帮用户计数、梳理货品价值。还有 Meta 最新发布的 Muse，它可以自主帮你处理购物和代人打电话等，还可自动跨平台跨网站做比价。
Agent 也会 spawn Agent，一下子可能开 10 个 Agent，每个 Agent 后面都有个数据库跟着。不仅创建快，销毁也快，Agent 使用时间通常很短，试了发现不成功就会扔掉。就像做 coding 一样，做几个方案出来，不好就扔了，数据库也释放了。传统程序是"人写好逻辑，程序按逻辑执行"，不会自己决定要不要建数据库、不会同时开 10 个实例试错。而 Agent 会。Jimmy 提到，"一般人或 DBA 管理的数据库，要做长时间的设计和计划，一旦做好了就会一直延续下去。而现在是多方试错，快速生产，快速销毁。"
还有一个场景是"休眠-唤醒"。阿里云数据库所服务的模型公司，通常有 10 万到 100 多万个 Agent，但当中只有约 10% 是活跃的。如果所有 Agent 的沙箱都有数据库挂载，成本过高。阿里云的做法是：一个 Agent 在一定时间内不活跃，就进入休眠，释放计算节点和沙箱，数据存到对象存储；用户再次使用时，快速拉起数据库，把数据拉回来。
这背后是 3 个根本变化：
使用者从人变成 Agent ，任务的复杂度、数量和频率都会改变；
工作模式从固定的建模查询变成探索性的试错与回滚；
数据库的边界也在扩展，Agent 的运行不能仅靠数据存取，还需要语义理解、记忆组织和上下文管理。
当数据库在接口层面向的不再是开发者，这个核心判断，直接决定了阿里云数据库接下来的技术路线。
从 AIDBS 到三层架构：一个完整答案的拼图
理解了范式转移的本质，下一个问题是：重做，从哪里开始？行业里有两种思路。
一种是自上而下：在现有数据库之上加一层 Agent 工具生态链，做个自然语言查询接口，封装几个 MCP 工具，加一个 AI 运维助手，就宣称自己是 AI 原生数据库。这是很多厂商的选择，因为它快、成本低、容易出 Demo 。
另一种是自下而上：从数据库内核、数据层、甚至底层硬件开始，为 Agent 的负载特征重新设计。
这是阿里云数据库的选择，因为它认为工具生态链层只能解决如何调用的问题，解决不了被放心托付的问题。
时间倒回今年 5 月 20 日的阿里云峰会，阿里云正式首发 AIDBS（AI 原生数据库服务）。这款定位为企业级 Data-Centric Agent 一站式开发与服务平台的产品，让Agent 能够自主构建数据应用，从数据发现、数据管道到分析与机器学习，可覆盖企业数据全生命周期。
据 Jimmy 介绍，AIDBS 是这三层架构中的第一层：工具生态链层。
"AIDBS 是数据库的 Agent，我们叫它 Data Agent， Agent for Database，可以用来管理数据库，方便取数。"Jimmy 解释道，但往下还有一个方向，就是 Database for Agent ——我们要如何改变数据库本身，从而更好地帮 Agent 管理数据。
这是理解阿里云数据库架构的关键。Agent for Database 解决的是 "Agent 如何使用数据库"，让 Agent 通过自然语言、MCP 协议等方式调用数据库能力。Database for Agent 解决的则是"数据库如何为 Agent 而重构"，当 Agent 的访问模式、数据类型、负载特征与人类完全不同时，数据库的内核、数据层、甚至底层硬件都需要重新设计。
“为什么 Agent-native 不能只做上层工具，而必须重构到数据底层？” 我们把这个问题抛给 Jimmy。
答案是 Data is Context。
"现在 Agent 有三个核心要素：大模型、Agent 本身（Harness）、Context 。大模型有主流的几款，大家都可以选。然而真正决定 Agent 深度和广度的是 Context 。" Jimmy 说，"不同企业可能部署同一个模型的 Agent ，但回答的问题完全不一样。企业的自有数据就是它最大的保障，核心竞争力不在于模型，也不是 Agent ，而在于它的数据。数据才是一家公司的核心资产。"
当数据成为 Context，数据库就不再只是存储和查询的工具，而是 Context 的管理系统。而 Context 包含的数据类型极其丰富，不光是结构化数据，还有非结构化的文档、图片、音视频，以及向量索引、图关系、上下文记忆等等。这些数据要统一进行管理，才能更好地产生 Context 。
本届云栖大会上，随着 Agent Context 和 ApsaraLakebase 的发布，阿里云数据库的三层架构终于完整。记者梳理其架构层次如下：
第一层：Data Agent 生态链 —— AIDBS，解决" Agent 如何使用数据库"的问题。Agent 不懂 SQL、不懂索引优化，但它需要数据。AIDBS 作为 Data Agent ，让 Agent通过自然语言、MCP 协议等方式自主完成数据开发、分析和运维。
第二层：数据引擎内核层 Agentic DB / Agent Context，解决"数据库如何从可被调用走向可被托付"的问题。Agent 不只是要查询数据，它还要积累记忆、管理上下文、处理多模数据、做安全审计。记忆需要事务一致性，上下文需要安全权限控制，多模数据需要统一的查询引擎——这些必须进入数据库内核。
第三层：数据存储服务层 ApsaraLakebase ，解决"百万级 Agent 如何共享一份数据"的问题。如果每个 Agent 独占一个数据库实例，大规模 Agent 的成本将难以承受。ApsaraLakebase 以对象存储为单一事实数据源，数据只存一份，通过 Copy-on-Write数据分支让每个 Agent 拥有独立视图，底层共享存储避免成本随 Agent 数量线性膨胀。同时支持 Lance、Iceberg、Paimon 等开放格式，让结构化、非结构化、向量、图数据在同一套体系内流转。
可被托付：阿里云 Data+Agent 理念的设计哲学
"能被调用只是入场券，能被托付才是壁垒。"这是 Jimmy 提出的判断。
可被调用很好理解：Agent 通过 API 或 MCP 协议调用数据库的能力。但可被托付是指什么？Jimmy 表示，它有非常具体的工程内涵。
第一层内涵：记忆和上下文必须进入数据库内核。
现在 Agent 的上下文有很多种存储方式，包括文件系统，比如 LangChain 框架通常就会把它们放在 SQLite 里面。但随着数据量的增长，文件系统和 SQLite 都不能承载了。更重要的是，企业级 Agent 需要跟企业的各种数据打通——规章制度、安全管理、Permission 管理。
比如我在整个组织里能看什么文件，跟另外一个人能看什么文件，是企业里专门的数据库在管理的，这本身就是 Agent 的上下文。文件系统对很多安全管理没有办法管理，没有数据库做得这么好。
Agent Context 的核心机制是 Context Growth Loop：记录—组织—召回与组合—执行沉淀—评估演进的持续自进化闭环。每次任务完成后，处理结果写入 Agent Context ，个人经验先沉淀为私有记忆，经审核晋升为团队共享知识。
第二层内涵：Agentic DB内核原生支持多模数据融合。
英伟达黄仁勋在今年的 GTC 上表示：结构化数据是 Ground Truth of AI，非结构化数据是 Context of AI，Jimmy 引用道。Agent 在回答同一个问题时需要融合多种数据源——结构化数据不能出错，一旦看到不该看的信息，会导致泄密；同时也需要调取很多非结构化数据，比如视频、图片等。
以前数据库分成多类：关系型数据库管理结构化数据，数据仓库/NoSQL数据库则负责管理非结构化数据。而 Agentic DB 的一大特性，就是可同时管理结构化数据和非结构化数据。
第三层内涵：Coding Agent 的原生支持。
Jimmy 表示，企业更希望看到的是多部门协同、不同工种员工之间的协同。他举了个例子：一个新员工，在 AI coding 能力的加持下，他的编程能力也许能直追 5 年的老员工？
"这当中还是有区别的。5 年的员工可能知道碰到一个问题去问谁，做一些事情跟哪个人打交道更好。这就是隐形的 Context ——你在公司待的时间长，你自然会沉淀很多业务上下文和相关数据。但新员工刚进来时缺乏业务背景与上下文，推进事项很容易遇到困难。"
"企业的一个共性，就是希望把这些员工的知识都蒸馏出来，共享出去，不断沉淀。"
所以，可被托付的工程内涵是具体的、可验证的：记忆和上下文进入数据库内核，多模数据在同一引擎中融合，Coding Agent 获得企业级的知识沉淀和协同能力。
当数据库能够做到这些，Agent 就不只是在调用一个工具，而是在托付它的记忆、知识和决策过程。
同样都叫 Lakebase，阿里云数据库的不同之处是什么？
在数据领域，Lakebase 已成为行业热词。2025 年，Databricks 以约 10 亿美元收购了Neon，并将其改造为 Lakebase 正式 GA。6 月的 Data+AI Summit 上，Databricks 又提出 LTAP 概念，主张让 OLTP、OLAP、AI 应用和 Agent 都建立在湖中同一份受治理的数据之上。Snowflake 则把战略升级为 Agentic Enterprise ，推出 Agent Identity体系。
当被问及阿里云数据库旗下的 ApsaraLakebase 与这些路线最本质的架构差异时，Jimmy 表示有以下几点不同。
湖库一体架构
" Databricks 的 Lakebase 路线，本质上是将 Serverless PostgreSQL 与对象存储进行接口拼接的架构。两个系统通过外置接口组合，数据需要在湖和库之间搬运。" Jimmy 介绍说，"阿里云数据库的 ApasaraLakebase 是统一引擎的湖库一体，数据只存一份，事务和分析在同一份数据上运行。”
协议层开放 vs 表格式开放
Databricks 的开放策略主打表格式开放，Delta Lake 作为开放的表格式，任何人都可以读写。阿里云数据库的开放策略则更侧重于协议层——通过 MCP Server 开源、Agent Context 兼容 Mem0 协议等方式，让数据库能力以标准化协议开放给 Agent 框架调用。
表格式开放解决数据能不能被不同系统读写的问题，协议层开放解决 Agent 能不能以标准化方式调用数据库能力的问题。在 Agent-native 时代，后者更关键。
更开放的背后，是阿里云数据库对开源战略的重新思考。"我们数据库同时有开源版本，也有非开源版本。接口跟协议交出去是一方面，但是不是要把内核交出去，是另外一个方面。"
在 Jimmy 看来，开源和闭源不是非此即彼的选择——"我们的战略是双轨并行：一方面通过闭源筑牢竞争壁垒，另一方面通过开源联合大家做大生态。"
作为老牌的传统基础软件，为 Agent 重做数据库可谓是个系统工程。为何阿里云数据库能在这个时间点快速完成转身？
这要从阿里云数据库打破世界纪录开始说起。据 Jimmy 介绍，阿里云 PolarDB 凭借「三层解耦」的创新架构，以 20.55 亿的每分钟事务数（tpmC）和 0.8 元每事务成本（Price/tpmC）打破了 TPC-C 基准测试的性能和性价比双纪录。这个成绩虽不能与 Agent 场景直接画等号，但它说明，阿里云数据库面向新负载的架构演进，并非从零起步。大规模事务处理、资源解耦和成本优化的长期积累，构成了其继续向 Agent Native 迈进的技术基础。
“Agent 负载具有突发性和高弹性，可能在短时间内创建大量数据库实例，而计算、内存与存储需求往往并不同步。通过计算、内存和存储三层解耦，系统可以按需独立扩展各类资源，更好地适配此类负载。此外，日志复制等技术使数据库能够基于对象存储运行；CXL 内存池化则支持多台服务器共享内存资源，进一步提升资源利用率，降低大规模 Agent 数据库服务的成本。”
除了这些积累，阿里云数据库还有一个难以复制的资源优势，即：全栈协同。
在集团层面，阿里云数据库支撑着阿里内部几乎所有 Agent 产品的后端数据和记忆管理。"我们在支持集团的很多产品，包括秒悟、Qoder 等等。既为这些产品提供数据库相关能力，也在持续推进软硬件协同。针对内存成本上升，我们也在持续探索 DDR4 资源的再利用，进一步提升硬件资源利用率。"。
古茗、小红书、昆仑万维等客户，正在替 Agent 投票
这些架构不是停留在发布会 PPT 上的概念，在阿里云的构想里，它有着清晰的落地路径，每一层都有客户在生产环境中验证。
工具生态链层，最典型的样本是古茗。这家头部茶饮品牌接入 AIDBS 后，自助分析需求的上线周期从天级缩短到 2 到 4 小时。运维 Agent 会根据各门店流量和客群变化持续优化，Meta Agent 还会自动理解门店新增的数据资产和个性化字段，过去以天、周计的分析需求，现在几个小时就能上线。
上汽则将 Data Agent 能力引入汽车研发和制造的核心业务流程；奇瑞汽车 NEXTAI 研究院基于自研汽车行业基模构建智能应用体系，同步引入 AIDBS Data Agent，已有 5000 余名员工使用，核心业务语义 100% 覆盖，数据需求响应从天级缩短至分钟级。
数据层方面，小红书以 Agent Context 为数据管理智能体搭建统一上下文底座，支撑 DBA、开发、算法等 3000 + 员工的子 Agent 协同作业。区别于传统 "各自为战、反复喂料" 的 Agent 部署，整个 Agent 集群在同一业务知识域下共享同一套 Context，业务规则一次更新，所有具备权限的 Agent 在后续调用中即可获取最新上下文，无需再逐个喂料。
在客户案例之外，阿里云还有一组量化标尺，用于观察其在 Agent 方向演进的进展。
‘双 50%’ 是阿里云数据库今年提出的目标：未来 50%的数据库实例由 Agent 创建和维护，50% 的数据库交互流量来自 Agent。在提出时，该目标被不少业内人士视为长期愿景。但在专访中，Jimmy 给出了一个超出预期的答案。
"按照目前节奏来看，我们已领先于‘双 50%’ 的目标。" Jimmy 表示。具体而言：第一个 50%（数据库实例由 Agent 创建）已经超额完成。比如超过 80% 的 RDS 新增实例由 Agent 创建，阿里云数据库整体则差不多 60% 。第二个 50% （50%数据库交互流量由 Agent 发起和消耗）也非常接近了。
以上提及的 Agent 创建实例，指的是通过 API、MCP 协议或 AIDBS 等 Agent 通道创建的数据库实例；Agent 维护管理，指的是日常运维操作中由 Agent 自主决策并执行的比例，包括性能调优、故障自愈、安全管理等。
双 50% 的实现，意味着数据库半个世纪以来的一个基本假设——数据库由人创建、由人维护——正在被推翻。当超过一半的数据库实例由 Agent 创建和维护时，数据库的设计前提、运维模式、安全模型，都需要重新思考。
数据重回舞台中央
如果把「为 Agent 重做数据库」看作长期的技术选择，阿里云现在押注的关键判断是什么？
"最关键的判断， 数据是重中之重。在 Agent 时代，数据将重新成为决定成败的胜负手。" Jimmy 表示，企业将愈发重视数据资产和数据能力，防止自有数据外流。公司自己持有的、通过数据训练的垂直模型也会越来越普遍。阿里云针对这一趋势对数据库进行系统性升级，以助力企业更好地建设自有的模型、管理数据资产。
谈及最大的技术风险， Jimmy 认为："风险不是技术路线选错了，而是技术演进的速度跟不上 Agent 应用爆发的速度。Agent 的发展太快了，今天还是 Coding Agent ，明天可能就是 Agent hosting Agent 。数据库的重构需要时间，而 Agent 的需求不会等你。"
"模型决定 AI 多聪明，数据库决定 AI 能跑多远。"Jimmy 在云栖大会主论坛上说的这句话，或许可以作为这场专访最好的注脚。
模型会趋同，框架会开源，Agent 会商品化，但数据——每一个企业在长期经营中积累的结构化数据、非结构化知识、业务规则、组织记忆——是不可替代的。而数据库，作为数据的最终承载者，将在 Agent 时代重新回到技术舞台的中央。
