"Agent 正在用户不易察觉的地方，持续创建和使用数据库。" 阿里云智能集团数据库产品事业部负责人杨辛军（Jimmy）的这一观察，揭开了一场静默的权力转移。数据库的 " 第一用户 " 正在换人，而且有具体的数字佐证。2025 年，Databricks 以约 10 亿美元收购 PostgreSQL 厂商 Neon，被收购方披露的一个关键数据是：约 80% 的数据库实例由 Agent 创建。杨辛军也透露，近几个月，由 Agent 创建的阿里云 PostgreSQL 数据库实例数，已达到过去 5 年累计实例的 3 倍。

这场权力转移并非突然发生。五十年前，数据库领域就曾有过一次类似的路线之争。1974 年，查尔斯 · 巴赫曼主张程序员应像航海家一样亲自规划取数路径；而埃德加 · 科德则认为，人只需声明 " 要什么 "，系统自己决定 " 怎么做 "。关系模型的最终胜出，完成了第一次权力转移：人类交出了执行路径的规划权，由查询优化器代劳。某种意义上，优化器是数据库历史上第一个 " 代理 "。但那次转移有一条清晰边界：做什么，始终由人预先定义。数据库收到的，仍是结构明确的指令，而非需要自行理解和拆解的业务目标。

如今，这条边界正在被越过。一名财务人员只需说一句 " 检查本季度异常支出，处理高风险项目 "，Agent 就会理解目标、拆解任务、检索数据、匹配规则，并根据中间结果决定下一步。人类开始把 " 为了实现目标，应该执行哪些指令 " 这一层决策，整体让渡出去。该事业部产品管理与技术架构部负责人王远把这种变化概括为：原本相对固定的系统逻辑，正在变成 " 秒级甚至亚秒级变化的执行方式 "。杨辛军进一步区分了这次变化和过去历次数据库演进：" 过去的变化，更多是针对数据类型和业务场景调整数据库能力；这一次的根本区别，是数据库的使用者变了——从人变成了 Agent。"

过去，一个应用要用上数据库，得先经过一整条链路：产品经理提需求，开发者设计 Schema、写接口和 SQL，DBA 建实例、配权限，前端再包装成产品。真正操作数据库的是开发者、数据工程师和 DBA。但当数据库的直接操作者变成 Agent，这条链路就会被大幅缩短。一个编程 Agent 接到 " 做个客户管理工具 "，就可以自己申请数据库、设计表结构、生成迁移脚本、写入数据、接上前端；上线后，它还会继续分析查询、修改 Schema、调整索引。整个过程里，用户未必打开过控制台，也未必知道数据库在哪里。阿里云数据库团队在访谈里给出了一个参考标尺：当超过一半的数据库实例由 Agent 创建和管理时，Agent 才算成为主力用户。

这也会重新定义最终用户。数据库的能力开始直接触达非开发者群体。用户只要表达需求，由 Agent 负责完成具体操作。访谈中提到的一家保险公司，业务人员已经可以用自然语言提出理赔要求、上传材料，后续流程全部由 Agent 完成——他们没有数据库账号，也不写 SQL，却实实在在成了数据库服务的用户。杨辛军指出，通过 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 对数据库的访问模式发生了根本变化，不再是单次明确查询的集合，而是一个带有试探性的、持续交互的对话过程。它需要快速地获取 Schema，迭代式地探索数据，并频繁地进行小规模写入。这就对数据库在连接管理、资源调度、以及元数据的实时响应上，提出了与处理传统应用负载截然不同的要求。数据库内核需要为这种 " 探索型 " 负载进行深度优化。

第四，是安全边界与服务形态的重构。当 Agent 不仅能读，还能执行写入、触发付款、冻结账户、调整库存时，错误的代价就从信息层面直接变成了现实后果。一个会推理、会探索、也会出错的系统，是否应该拥有直接操作数据库的权力？答案如果是肯定的，那么数据库的架构、产品形态和安全边界就必须重构。这要求在授权、操作可逆性、以及行为监测上建立全新的防护机制，不能让一个错误的推理步骤轻易演变成不可逆的业务事故。

风险也随之改变。Agent 只负责回答问题时，错误停留在信息层面；一旦它能写入数据、触发付款、冻结账户、调整库存，错误就会直接变成现实后果。这也意味着，数据库服务商的产品形态将发生深层变化。未来的数据库不再只是一个需要被精心运维的独立系统，它将越来越像一种内嵌在开发流程中的基础能力，以 API 和 SDK 的形态被各种 Agent 按需调用。生态优势，也第一次通过模型语料完成了自我强化，正如 PostgreSQL 凭借其在大模型语料中的丰富程度，自然成为了 AI 时代的首选数据库。