封面为生成式场景底图与确定性文字排版的组合，不是任何厂商的产品架构图。
一个编码 Agent 想试新的表结构，需要能随时创建、隔离和回收的数据库环境。另一个 Agent 接到“调查慢查询”的任务，需要读取监控、分析执行计划，并在授权范围内提出或执行调整。两项工作都与数据库有关，目标却不同。
前者需要数据库提供数据与实验环境，后者让 Agent 参与数据库自身的维护。数据库分支、长期记忆和自动运维会被放在同一个概念下讨论，正是因为这个名字覆盖了不同的任务。
Agentic Database 可以理解为：围绕 Agent 的工作方式重新设计的数据库及数据服务，以及由 Agent 参与管理的数据库系统。 这是对当前产品路线的归纳，不是已经统一的行业定义。它首先描述数据库与智能体关系的变化，不意味着出现了一种取代关系型数据库的新数据模型。
两条路线，分别服务应用任务与数据库运维
图 1：两条路线可以出现在同一平台中，但有其中一条，不代表另一条也已经具备。以下分类用于理解产品，不是统一标准。
两条路线的区别在于任务最终要完成什么。预约会议时，Agent 查询日历、确认空闲并写入预约，完成标准是会议安排正确；调查数据库变慢时，Agent 读取监控、分析执行计划并检查锁等待，完成标准是找到原因并验证处理效果。前者把数据库作为完成应用任务的基础设施，后者把数据库本身作为诊断和维护的对象。
本文所说的 Agent，也不只是能够回答问题的聊天机器人。它可以围绕一个目标选择工具、连续执行多个步骤，并根据执行结果改变下一步行动。它与预设工作流的主要区别，是行动路径会随着环境反馈发生变化。
第一条，数据库平台支撑业务与开发任务。 一个编码 Agent 不只需要生成建表 SQL，还可能需要创建测试库、修改表结构、跑测试，最后把应用部署起来。一个业务 Agent 则需要读取实时业务数据，记住用户偏好，保存尚未完成的任务。数据库平台通过工具接口、分支、Serverless 和记忆服务，为这些任务提供所需的数据和环境。
第二条，Agent 承担数据库运维任务。 用户提出“调查这批慢查询”，Agent 读取指标和执行计划，寻找原因，提出调整方案，必要时在批准后执行。它交付的是诊断依据、调整方案和验证结果，目标是改善数据库自身的性能与运行状态。
两条路线会共享查询、建库甚至修改索引等操作，所以不能只靠某个工具调用来区分。为新功能建立测试分支，服务于应用开发；为排查慢查询建立实验分支，服务于数据库运维。任务目标和验收结果，才是更清楚的判断依据。同一平台也可以同时提供两类能力。
模型可以参与决定查什么、何时调整配置，但存储、事务和查询执行仍需要数据库引擎负责。Agentic 不等于让大模型替代数据库处理每一条读写。
相邻技术不能代替 Agentic Database
这些概念有交集，但回答的问题并不一样。
| 概念 | 主要解决什么 | 与 Agentic Database 的关系 |
|---|---|---|
| 向量检索 | 从数据中找到语义相近的内容 | 可以提供上下文，但不负责完整任务 |
| Text-to-SQL | 把自然语言转成数据库查询 | 是交互能力，不等于多步自主行动 |
| MCP 接入 | 向 Agent 暴露可调用的工具和资源 | 是连接方式，不是数据库新内核 |
| Serverless 数据库 | 按工作负载供给、调整计算资源 | 适合部分 Agent 负载，但早于这一轮热潮 |
| 传统自动化运维 | 按规则备份、切换、扩容、告警 | 与 Agent 可以协作，不因有自动化就变成 Agentic |
| Agentic Database | 支撑 Agent 的应用任务，或让 Agent 参与数据库运维 | 可能组合以上能力，没有统一的必选清单 |
“查一下上个月销售额”可以只需要一次查询；“调查销售额下降的原因”可能需要先比较地区，再检查渠道与退货数据，最后决定是否继续调查。两者都能使用数据库，但后者更接近目标驱动的多步任务。
所以，只是在控制台加一个对话框，不足以说明产品发生了多大变化。要看它是否真正接上了任务需要的数据、工具和执行流程。
公开产品可以归纳为四种形态
图 2：按任务和交付内容归纳产品形态，同一产品可以覆盖多个方向。
面向 Agent 的即时数据库环境
这类产品首先解决环境供给问题：让 Agent 通过接口创建数据库、取得连接、建立隔离分支，任务结束后再回收资源。
数据库分支可以理解为从某个数据起点创建独立实验环境。编码 Agent 要试两种表结构设计，不必直接改生产库，而是分别测试，再交由正常发布流程推进。分支不是自动合并任意业务数据的承诺。
这类短时环境可以结合弹性计算减少空闲资源，但 Serverless 只是供给方式，不是 Agentic Database 的定义条件。
记忆与上下文服务
| 同一任务所需的数据 | 示例：预约会议 | 更新依据 |
|---|---|---|
| 业务事实 | 会议室当前是否空闲 | 日历系统的实时结果 |
| 执行状态 | 已查空闲，尚未发邀请 | 工具调用结果与流程记录 |
| 长期记忆 | 用户偏好下午开会 | 有来源、可修正的历史偏好 |
以上是教学场景，三类数据共同服务一次行动，但不能相互替代。
模型知道通用知识，不代表知道当前库存、用户上周的选择，或者一项任务已经执行到哪里。
这催生了两类需求：从业务数据中取得当前依据，以及跨会话保存、组织和召回信息。记忆服务可以分开保存原始对话、提炼后的信息和用户偏好，避免把所有历史都当成同一种可直接行动的事实。
业务数据、任务状态与长期记忆还可以由不同系统承接，再由应用组织成一次行动所需的上下文。选择一体化平台还是组合现有存储，取决于数据更新、权限和运维边界。
记忆服务可以帮助 Agent 记住事情，但用户偏好、任务进度和已经确认的业务记录，仍然是不同性质的数据。
靠近数据的 AI 工作流
如果每次都要把业务数据导出，再在应用侧拼接检索、模型调用和结果存储，开发者需要维护许多连接环节。另一种思路，是让数据库平台直接提供这些能力。
数据库平台可以把向量化、检索增强生成（RAG）和模型连接组织为一套数据处理流程。开发者仍要决定哪些数据可以进入模型、结果如何保存和校验，以及流程失败时如何恢复。这种能力帮助构建 AI 应用，与让 Agent 维护数据库是两项不同的工作。
“靠近数据”也不意味着大模型一定在数据库内核进程中运行。模型可以在外部，平台负责连接、组织数据和编排流程。真正改变的是，开发者在哪里组装这些能力。
数据库运维 Agent
这类产品不要求业务应用先变成 Agent。即便仍然运行普通的网站或交易系统，数据库团队也可以使用它调查异常、分析慢查询和辅助配置。
运维任务可以从选型与配置延伸到监控、异常调查和调整。慢查询诊断尤其适合作为具体起点：Agent 可以同时对照查询计划、负载变化和锁等待，而不必在证据不足时直接改动生产参数。
数据库运维 Agent 的价值不是多生成一份诊断报告，而是缩短从发现问题到采取合适行动的路径。不过，“可以建议”与“可以自动执行”仍然是不同的产品边界。
共同成因是软件开始连续行动
图 3：因果关系是本文的分析，不是厂商市场份额或性能统计。旧技术并未突然诞生，而是被新的工作方式重新组合。
它们看起来分散，实际对应着同一场变化：越来越多软件工作，不再由人逐步点按钮完成，而是由人给出目标，软件连续执行。
这首先改变了资源供给。一个开发者按天维护的测试环境，可能变成多个编码 Agent 按任务创建的临时环境。快速分支与弹性计算因此有了新的使用场景。
其次改变了数据需求。问答可以只取一段相关文本，持续工作的 Agent 却需要把业务事实、历史信息和任务进度一起用起来。单独增加向量检索，很难包办这些事情。
最后改变了管理压力。当创建应用、修改配置变得更容易，数据库数量和变更数量也可能增加。运维 Agent 因而与面向 Agent 的数据库同时出现：一边让软件更容易使用资源，另一边帮助团队管理这些资源。
这也解释了为什么 PostgreSQL 经常出现。它已有关系数据、事务和成熟工具链，还可以通过 pgvector 等扩展补上向量检索。在已有生态上组合新能力，开发者不必为每类 Agent 任务重新学习一套数据系统。
其他关系型和非关系型数据库也能承担其中的任务。PostgreSQL 是重要的承载生态，并不是 Agentic Database 的定义条件。
厂商正从不同入口争夺 Agent 工作流
图 4：各路线争夺的是工作流入口，不是同一张功能清单；产品列举用于说明切入点，不代表排名。
| 切入点 | 代表性实践 | 主要解决什么 |
|---|---|---|
| 数据库环境 | PolarDB、Neon | 分支、弹性计算与环境回收 |
| 应用后端 | Supabase、Neon Backend | 认证、API、文件与函数 |
| 状态与上下文 | 腾讯云 Agent Memory、AWS | 记忆、执行状态与业务数据 |
| 近数据 AI | EDB AIDB | 检索、模型连接与数据流程 |
| 数据库运维 | EDB、Google Cloud、DatabaseClaw | 诊断、批准与受控执行 |
这些产品共享 Agentic 的叙事，却不是同一种“新数据库”。比较时只需抓住三件事：它接住了工作流的哪一段、Agent 使用谁的权限，以及操作完成后如何验收。
公测、功能发布和生产可靠运行也不能画等号。能创建环境，不代表可以绕过发布流程；能执行调整，也不代表数据库已经能够无人值守。
需求正在趋同，产品边界仍在分化
从公开能力看，需求正在趋同，产品边界仍在分化。有的系统先解决临时环境的创建和回收，有的把记忆与检索服务接到现有数据上，还有的从数据库诊断与运维切入。它们回应了同一种工作方式，却未必会汇成一种产品。
| 逐渐趋同的方向 | 能看到的公开信号 | 还不能推导出什么 |
|---|---|---|
| 数据库要更容易被 Agent 调用 | 工具接口让 Agent 创建资源、查询和试验 | 工具接入已统一授权与操作安全 |
| Agent 需要持续的数据依据 | 业务数据、任务状态和记忆被分别组织 | 已有统一的记忆格式或可靠性标准 |
| 编码 Agent 需要隔离的实验环境 | 数据分支与弹性计算适配短时任务 | 每种数据库都必须采用同一种存算架构 |
| 自动执行需要权限边界 | 诊断、建议、批准与执行被拆成不同步骤 | DBA 可以被无条件替代 |
这些是从公开能力中归纳出的需求变化，不能仅凭功能公告判断实际使用范围。
分歧首先出现在 Agent 所处的位置。应用层更容易跨系统组织任务，数据库平台则更接近数据与运行状态；两种路径各有优势，目前没有统一答案。
第二处分歧是数据能力如何组合。把记忆、检索和业务数据集成到一个系统，可以减少连接工作；拆成多个专用服务，则保留了独立优化空间。不同负载很可能继续采用不同架构。
第三处分歧是产品最终以什么形式交付。数据库、后端平台和运维能力都在吸收 Agent，但共享一个技术趋势，不代表它们会收敛成同一种商业形态。
所以，“行业共识”更适合落在需求层：软件需要更方便地取用数据、延续任务和操作环境。至于这些能力由谁提供、放在哪里，还在竞争。
下一阶段可能沿三条路线演进
图 5：左侧是已公开的能力，右侧是本文推测的演进方向；三条路线可能并行发展。
基于当前产品动作，可以看到三条可能的演进路线。它们是本文的判断，不是厂商共同承诺的路线图。
第一，交付单位可能从“一个数据库实例”扩大到“一套任务环境”。 数据库已经有分支，如果文件、认证和函数仍然各走各的，Agent 还是要处理环境不一致的问题。下一步值得观察的，不只是建库速度，而是整个环境能否一起建立、隔离和回收。
第二，数据服务可能从“找出相似内容”走向“组织可用上下文”。Agent 不只需要找到一句话，还要理解它属于谁、什么时候有效、与当前业务状态是否一致。记忆服务和数据附近的 AI 工作流提供了起点，但跨服务的语义、权限与更新机制仍有大量工作。
第三，自主管理更可能先从有边界的任务成熟。慢查询调查、配置建议、限定范围的调整，有较明确的输入和结果；跨系统故障与高影响变更则需要更复杂的判断。先验证建议，再逐步扩大获准执行的范围，是更容易检验的演进路径。
这三条路线最终可能交汇：Agent 创建应用环境，在运行中使用持续更新的上下文，再由运维 Agent 帮助管理底层系统。但它们也可能长期由不同产品协作完成，而不是合成一个超级数据库。
理解 Agentic Database，最重要的不是记住一个新的产品缩写，而是看清数据库角色的变化：它既在成为 Agent 可调用的开发与运行基础设施，也在成为 Agent 可以协助管理的系统。
判断一个 Agentic Database 产品，可以抓住三个维度：服务于什么任务、以什么结果验收、哪些能力已经交付而哪些还只是愿景。 这三个维度比产品名称更能说明它真正提供了什么。
原有产品资料核验截至 2026 年 9 月 26 日；Serverless 补充核验于 9 月 27 日。产品描述来自官方公开资料，未进行性能或生产实测；四种形态、需求归纳和未来判断为本文分析，不代表正式行业标准。
系列下一篇将讨论：Supabase 与 Neon 如何接住 Agent 生成应用之后的后端工作。
参考资料
- Anthropic：Building effective agents
- 阿里云：PolarDB PostgreSQL Agentic Database 公测公告
- 阿里云：PolarDB MySQL Agentic Database
- 阿里云：RDS PostgreSQL Serverless 实例
- 腾讯云：数据库 AI 服务基本概念
- 腾讯云：Agent Memory
- 腾讯云：DatabaseClaw
- AWS：Agentic AI with AWS Databases
- Neon：The Neon backend is GA
- Supabase：Architecture
- Supabase：MCP Server
- EDB：Agentic Database
- EDB：Agentic AI / AIDB
- Google Cloud：Database Operations Agents
- pgvector：项目文档