Agent，正在拿走数据库的行动权。
这并不是一场突然发生的变化。五十年前，数据库就经历过一次类似的权力转移。
1974 年，密歇根州安娜堡，一场著名争论决定了数据库此后的方向。查尔斯·巴赫曼主张，程序员应像航海家一样，亲自规划复杂数据结构中的取数路径；埃德加·科德则认为，人只需声明“要什么”，系统自己决定“怎么做”。
关系模型最终胜出，也完成了第一次权力转移：人类交出执行路径的规划权，由查询优化器代劳。某种意义上，优化器是数据库历史上第一个“代理”。
但那次转移有一条清晰边界：做什么，始终由人预先定义。数据库收到的，仍是结构明确的指令，而不是需要自行理解和拆解的业务目标。
今天，这条边界正在被越过。
一名财务人员只需说一句“检查本季度异常支出，处理高风险项目”，Agent 就会理解目标、拆解任务、检索数据、匹配规则，并根据中间结果决定下一步。人类开始把“为了实现目标，应该执行哪些指令”这一层决策，整体让渡出去。
风险也随之改变。Agent 只负责回答问题时，错误停留在信息层面；一旦它能写入数据、触发付款、冻结账户、调整库存，错误就会直接变成现实后果。
一个会推理、会探索、也会出错的系统，是否应该拥有直接操作数据库的权力？如果答案是肯定的，数据库的架构、产品形态和安全边界又该如何重构？
围绕这些问题，我们邀请了两位深度参与这场变革的实践者：阿里云智能集团数据库产品事业部负责人杨辛军（Jimmy），以及该事业部产品管理与技术架构部负责人王远。
一、数据库的第一用户换人：证据藏在实例创建记录里
数据库用户的变化，最先出现在实例创建记录里。
先看两组数字。2025 年，Databricks 以约 10 亿美元收购 PostgreSQL 厂商 Neon，后者披露约 80% 的数据库实例由 Agent 创建。杨辛军也提到，近几个月，由 Agent 创建的阿里云 PostgreSQL 数据库实例数，已达到过去 5 年累计实例的 3 倍。
“Agent 正在用户不易察觉的地方，持续创建和使用数据库。”他说。
这并不意外，因为这些数字集中出现在 PostgreSQL 上。大模型语料里，Postgres 的文档、问答和代码最丰富，模型也就最“懂”它，Agent 建库时自然更容易默认选它。生态优势，第一次通过模型语料完成了自我强化。
但机器访问数据库本身并不新鲜。电商、银行、ERP 早就都是程序在执行 SQL。区别在于，传统应用的访问路径在开发阶段就写死了：用户点击“提交订单”后，后端查哪些表、执行什么语句，早已写进代码并通过测试。
Agent 则不同。它接收的是目标，不是步骤。运行时，它会先观察环境、理解 Schema、制定计划，再根据结果不断调整：字段找不到就继续探索，结果矛盾就切换路径，方案失败就生成多个候选继续试。
王远把这种变化概括为：原本相对固定的系统逻辑，正在变成“秒级甚至亚秒级变化的执行方式”。
杨辛军 进一步区分了这次变化和过去历次数据库演进：“过去的变化，更多是针对数据类型和业务场景调整数据库能力；这一次的根本区别，是数据库的使用者变了——从人变成了 Agent。”
过去，一个应用要用上数据库，得先经过一整条链路：产品经理提需求，开发者设计 Schema、写接口和 SQL，DBA 建实例、配权限，前端再包装成产品。数据库在后台，真正操作它的是开发者、数据工程师和 DBA。
但当数据库的直接操作者变成 Agent，这条链路就会被大幅缩短。
一个编程 Agent 接到“做个客户管理工具”，就可以自己申请数据库、设计表结构、生成迁移脚本、写入数据、接上前端；上线后，它还会继续分析查询、修改 Schema、调整索引。整个过程里，用户未必打开过控制台，也未必知道数据库在哪里。
这也会重新定义最终用户。数据库的能力开始直接触达非开发者群体。用户只要表达需求，由 Agent 负责完成具体操作。
在「C 位面对面」访谈中提到的一家保险公司，业务人员已经可以用自然语言提出理赔要求、上传材料，后续流程全部由 Agent 完成——他们没有数据库账号，也不写 SQL，却实实在在成了数据库服务的用户。
这也意味着，数据库能力正在绕过传统开发流程，直接进入业务场景。管理者可以即时追问数据变化，业务人员也不必再等待系统开发。
“开发者的定义也在发生变化。”杨辛军 指出，通过 Agent 构建应用、组织数据、完成业务流程的人，即使不具备传统编程能力，也已经在参与软件与数据系统的建设。
不过，这场迁移还没完成。阿里云数据库团队在访谈里给了一个参考标尺：当超过一半的数据库实例由 Agent 创建和管理时，Agent 才算成为主力用户。
一旦主体换成 Agent，数据库围绕传统开发者建立的产品假设就会失效：Agent 不需要图形控制台，不读文档，它需要的是可发现的能力、可组合的接口，以及支持快速试错和恢复的环境。
所以，数据库要被重新做一遍。
二、数据库要被重新做一遍
“理想状态是去掉文档、去掉控制台。”王远这样描述未来的数据库形态：用户打开浏览器，在对话框里表达需求，就能获得过去只有专业人员才能调用的数据服务。
杨辛军 补充说，Agent 并不需要图形界面，API、命令行、CLI 就够了。一个强调入口变轻，一个强调入口拆掉，指向的是同一件事：厚重的控制台不再是数据库的主界面。
这也是 Agentic Database 和“数据库加 AI”的分界线。
过去行业主要沿两条路径引入 AI：一条是 DB for AI，为 AI 应用提供向量检索、多模态处理；另一条是 AI for DB，用 AI 诊断慢 SQL、辅助运维。两条线都没有改变数据库的基本位置——它仍是后台系统，AI 只是服务对象或附加功能。
杨辛军 对第三条路径的概括很清楚：“过去是把 AI 放进数据库，现在还要解决如何把数据库能力交给 Agent 和用户使用。”
从访谈内容看，这场变化至少发生在四个层面。
首先，是交互方式重构。输入从结构化查询扩展到文字、图片、音视频，输出从表格变成结论、内容和可继续调用的结果。
SQL 不会消失，但它的位置变了——从用户必须掌握的入口，退到 Agent 与数据库之间的执行层。王远把它概括成一句话：从 “SQL in、Table out” 走向 “Token in、Token out”。
其次，是能力开始 Agent 化。数据库过去只管数据和查询，监测、治理、分析、开发分散在不同工具和团队里。
现在，这些能力正在被收拢成 Agent，运行在现有引擎之上，比如负责变更、恢复、运维的 DAS Agent，负责资产盘点和数据理解的 Meta Agent、Analytics Agent，以及基于 BaaS 能力生长出的应用开发 Agent。
其中，Meta Agent 瞄准的是企业数据库最老的问题之一：技术债。自然语言转 SQL 的瓶颈，从来不只是语法，而是语义。模型会写 SQL，但不知道企业里表名、字段、指标背后的真实业务口径。
Meta Agent 的作用，就是持续理解字段、补充业务语义并沉淀下来，让后续查询越来越准。数据库因此不只保存业务数据，也开始保存“对数据的理解”和“使用数据的经验”。
然后，是为新负载重做内核。Agent 的负载模式和传统应用完全不同：7×24 运行、速度远超人类、围绕一个目标并行探索、反复试错。快速分支、快速备份恢复、操作追踪、错误修正、更强弹性，以及权限和负载隔离，都是内核需要补齐的能力。
其中最关键的是分支：基于写时复制，可以秒级拉起一个与生产同构的环境，让 Agent 为同一任务开出多个分支，分别测试 Schema、索引和数据方案，完成后再销毁。备份恢复也不再只是灾难后的手段，而是试错中的常规动作。
新负载也带来了新的成本结构。用户一句话，可能衍生出多个 Agent、几十次查询和多个临时数据库。
阿里云的探索方向是多租户共享，让多个项目共用底层资源，同时保证权限和负载隔离。核心矛盾很清楚：既要鼓励 Agent 大量试验，又不能让资源无限膨胀；既要靠共享摊薄成本，又要确保任务之间互不干扰。
最后，是保留一个确定性的执行底座。
杨辛军 强调，Agent 可以探索，但企业数据库不能把所有判断交给概率模型。交易、销量、对账等业务关键数据，必须实时精确；图片、视频等多模态数据，部分环节可以容忍近似。
数据库因此必须“一专多能”——守住事务和一致性的基本盘，再扩展多模态、模型调用和 Agent 协作能力。这样形成了一个双层系统：上层 Agent 负责理解需求、生成方案、组织任务；下层由事务、权限、约束、隔离和资源控制决定一个动作能否真正发生。
四层变化叠加后，AI 原生数据库服务的能力如何？茶饮品牌古茗给出了一个样本：过去以天、周计的自助分析需求，现在 2 到 4 小时就能上线。运维 Agent 会根据各门店流量和客群变化持续优化，Meta Agent 也会自动理解门店新增的数据资产和个性化字段。
王远把这个变化比作数据库从副驾驶变成自动驾驶司机：人只说目的地，剩下交给系统。但自动驾驶不等于拆掉方向盘和刹车，人仍然保留设定目标、限定范围和随时接管的权力。
有趣的问题也就来了：原来握方向盘的人，将会去哪里？
三、Agent 接管操作之后，DBA 要成为“组织者”
“焦虑是正常的，我自己也会焦虑。”谈及 AI 对 DBA 的冲击，王远没有回避。
变化已经发生。随着 Agent 进入数据库运维体系，一个 7×24 小时在线的“高水平运维体”正在成形：它不会疲劳，能够同时处理海量指标、执行计划与历史事件，在发现异常后自动完成诊断、生成方案，并在满足条件时直接执行。
最先被替代的，是那些规则清晰、频率高、结果可验证的工作——包括监控、慢查询分析、统计信息收集、执行计划检查，以及标准化变更与恢复。过去依赖流程与审批的操作，正在被 DAS Agent 逐步接管。
这也在改变 DBA 的价值结构。
长期以来，DBA 的一部分优势来自“信息差”：更懂事务与锁机制，更熟悉执行计划，也更了解企业内部数据库的历史与架构。而 Agent 正在快速缩小这种差距——它可以在秒级完成文档检索、复盘历史故障，并将专家经验转化为标准化执行步骤。
但信息的普及，并未削弱判断的重要性。
杨辛军指出，交易、销量、对账等关键业务数据必须“实时且准确”，无法依赖模型提供的近似结果。数据库仍然需要在事务、一致性与安全上提供严格保障。
现实中，Agent 可以提出技术上可行的索引优化方案，却未必理解写入延迟对结算系统的影响；可以建议调整参数，却无法判断企业是否愿意为性能提升增加成本；可以生成恢复流程，但无法承担数据丢失或业务中断的责任。
这意味着，DBA 的角色正在发生转移——从“执行操作的人”，转向“决定哪些操作应该发生，以及机器可以做到什么边界”。
在王远看来，这种转型早已开始，只是 Agent 显著加速了进程。未来 DBA 的能力，将集中体现在三个方向。
首先，是与 Agent 协作的能力。重点不在提示词，而在流程重构：由 Agent 持续采集哪些信息、优先诊断哪些问题、在哪些场景下自动执行、何时必须上升为人工决策。
这也改变了工作入口。DBA 面对的，不再是零散告警，而是由 Agent 整理后的任务包——包括异常来源、候选方案、影响评估以及回滚条件。人的精力将更多用于证据判断与高风险决策。
其次，是对行业与业务的理解能力。
随着 SQL 编写、文档检索和常规调优逐渐被 Agent 接管，真正难以标准化的部分，转向“业务语义”。同样一次数据库延迟，在茶饮门店系统中可能只是报表延后，而在金融交易或保险理赔系统中，则可能意味着资金风险与合规问题。
Agent 能够识别“技术异常”，但只有人能够判断“业务含义”。
第三，是组织与驾驭多 Agent 系统的能力。
王远强调，未来不只是“用一个 Agent”，而是让一组 Agent 参与架构设计与任务执行。DBA 需要定义它们之间的职责与边界：谁负责监控，谁负责诊断，谁负责执行；哪些数据可以访问，何时必须中断自动化。
这也在放大个体能力。“一人公司”和“超级个体”的讨论背后，正是大模型与 Agent 对生产力的放大。一名 DBA 可以管理更多数据库，同时调度更多 Agent 协同工作。
但风险同样被放大。在传统模式下，一条错误命令通常影响单一实例；而在 Agent 体系中，一条错误策略可能被批量执行，演变为系统性事故。
因此，评价 DBA 的标准也在变化。
从“解决了多少故障、优化了多少 SQL”，转向“自动化覆盖率有多高、建议准确率如何、高风险操作被限制在多小范围，以及系统恢复能力有多强”。
所以，DBA 不会被 Agent 简单替代，而是出现分化。过去，优秀 DBA 意味着能够快速救火；未来，更重要的是让大多数问题在扩散之前就被处理掉。
四、能被调用只是入场券，能被托付才是壁垒
“这个窗口变化非常快，因此必须提前布局。”谈到 Agentic 时代留给数据库厂商多少时间时，杨辛军的判断并不保守。
在他看来，中国数据库产业将有机会从 Follower 走向 Leader。但这也意味着没有现成答案可抄，必须同时试多个方向。“其中 90% 可能失败，但只要抓住那 10%，就可能建立真正的领先优势。”
这也说明，今天的竞争还远没定局。产品定义、技术路径和市场边界，都还在形成中。
2025 年，Databricks 以约 10 亿美元收购 Neon，Snowflake 收购 Crunchy Data；数据平台开始补交易型数据库，Serverless 数据库主打分支和弹性，Agent 平台则向下延伸，开始管理数据和执行权限。大家都在往同一个位置挤：Agent 时代的数据底座。
这个位置为什么重要？杨辛军的判断很直接：数据具有重力（Data Gravity）。AI 越发展，数据越重要，数据库也越重要。
Agent 不但没有削弱数据库，反而放大了它的价值：一个 Agent 可能在几秒内生成大量查询、创建多个任务，还会持续沉淀中间结果和记忆；而企业核心数据，也不会因为交互方式变成自然语言，就离开事务、权限和审计体系。
所以，数据库同时卡住了两个关键点：Agent 最需要的数据，以及 Agent 行动真正落地的执行层。围绕这两个点，竞争开始分成两层。
第一层是能被调用。自然语言查询、向量和多模态检索、Agent 记忆、数据库分支、BaaS、工具接口，都是这一层的能力。阿里云数据库也在沿这条线布局，包括 PolarDB 云原生数据库在探索的 Agentic Memory、数据库分支、一体化 BaaS，以及通过阿里云 AI 原生数据库服务 (AIDBS) 把数据库包装成一个 Multi-Agent 系统。杨辛军 的意思是，把 Database Service 进一步做成 Agentic Service。
但这一层很难形成长期壁垒。向量检索各家都能补，MCP 这类连接协议天然就是标准化方向，分支和自然语言查询也会逐渐从差异化功能变成默认配置。支持 Agent 调用，最终会像当年支持 JDBC 和 HTTP 一样，只是入场券。
第二层才是真正的分水岭：企业敢不敢让 Agent 动手。
允许 Agent 查报表，和允许它修改客户状态、执行数据恢复，是完全不同的信任等级。企业不会因为演示里足够聪明，就把生产库交出去。厂商必须证明：即使 Agent 判断错了，系统也能锁住它的权限、成本和影响范围。
王远把企业级要求概括为几个词：可理解、可追溯、准确、安全，再加上权限隔离和负载隔离。
采购标准也会随之变化。未来企业选数据库，不只看 QPS，还会看一次 Agent 任务用了多少工具、扫了多少数据、最坏会消耗多少资源。成本单位也会从实例和查询，扩展到任务、模型和 Token。
杨辛军把 Token 比作未来的水、电和石油。重点不在价格预测，而在属性判断：当 Agent 成为大规模生产资源，它的消耗就必须像水电一样可预算、可限额。
商业模式也会跟着改。王远以古茗为例指出，单次使用成本下降，并不意味着收入会缩水。门槛一旦降低，使用者和调用量都会扩大，业务人员、管理者和外部 Agent 也会一起成为数据服务消费者。数据库厂商将有机会直接触达业务部门，收费逻辑也可能从卖资源，转向按任务、按结果卖能力。
如果回到 1974 年，第一次权力转移用了十多年才真正完成——优化器靠确定性证明赢得信任，它给出的执行计划可以被验证为更快、更对。这一次不同，受让方是一个概率系统，信任无法一次性证明，只能靠权限、审计和反馈一点点建立。
所以，能被调用，决定数据库能否进入 Agent 生态；能被托付，决定它能否进入企业生产核心。第二次权力转移真正完成的那一刻，不会出现在发布会上，而会出现在一家企业第一次放心让 Agent 在无人值守时完成生产变更的时刻。
这场转移已然开始。阿里云 AI 原生数据库服务（AIDBS） 让阿里云数据库在无需架构改造的前提下具备面向 Agent 的智能能力，成为 Agent-ready 的数据基础设施，也标志着阿里云瑶池数据库率先完成面向 Agentic 架构的系统性重构。也欢迎更多企业共同探索，从“能被调用”走向“能被托付”的体验。
