模型决定AI有多聪明，数据库决定AI能跑多远。阿里云数据库产品事业部RDS开发总负责人陈宗志（花名：暴跳）在DTCC大会上把这个判断讲得很直白。他正在带团队做一件事：让数据库自己长出Agent的能力，而不是把AI塞进数据库里当插件。
向量检索等核心能力已经在AliSQL上开源。这背后是一条更硬的逻辑线——数据库的用户正在被替换，产出端和消费端都交给了Agent。
从后勤到关键变量：数据库角色的两次位移
AI和数据库的关系，走过了两个阶段。
上半场，模型是主角。大家盯参数、盯推理效果，数据库干的是清洗和整理调参数据的活，属于托底的后勤。应用形态以对话为主，数据库加个向量能力，补一补Transformer的短板就够了。
下半场，Agent大量涌现，情况反转。模型决定单次任务做得多好，数据库决定这些任务的经验能不能沉淀下来。没有数据库的Agent，每次启动都是新手；有历史执行记录、中间结果和决策痕迹托底，Agent才敢接更复杂的活。
这里有个容易被忽略的坑：很多人以为Agent-Native就是给数据库加几个AI函数。陈宗志多次强调，这是架构上的彻底重构，不是功能叠加。
人的访问逻辑，和Agent完全不是一回事
人写代码时，系统默认用户清楚表结构。DDL和DML的访问比例，大概是10000:1。没人会在查某个字段前先去看一遍表结构。
Agent反过来。它是研究式的，先查表结构，再找数据。DDL信息的访问频率，被拉高到和现实数据访问差不多的量级。
试错也是天然的。它会在事务里嵌套小事务，失败就回溯重试。多模态数据散落在各处，它实时检索，不做提前预处理。多步推理带来不可预测的并发，过去清晰的冷热表界限被打乱了。
人对世界有预设认知，Agent没有。不适配这种访问特性，AI跑得越快，传统数据库设计逻辑暴露的问题就越大。
这也是阿里云瑶池数据库给自己定下两个50%目标的原因：数据服务方面，50%访问数据库的流量来自Agent；数据管控方面，50%的数据库实例由Agent创建与维护。
三大不可预测性，逼着数据库换骨架
陈宗志把Agent用数据库的方式拆成三个不可预测。
数据类型不可预测。一次推理可能同时碰到结构化表、向量召回、JSON文档、关联图和全文检索。以前多模访问会提前把内容检索出来放进文本，现在Agent不做预处理，全是实时访问。
访问量不可预测。多步推理瞬间把并发拉满，闲时静默，忙时几十倍尖峰。一个Agent有多步推理流程，同类型Agent还会部署很多个。
访问方式不可预测。研究式查询先看表结构再找数据。哪些是热表、哪些是冷表，人类用户提前有判断，Agent要实际查看内容才能决定。
这三个不可预测叠加起来，传统数据库的容量规划和索引策略基本失效。
模型吞不掉数据库的三个理由
业内有一种声音：模型越来越强，数据库会不会退回存储层？OpenAI做Memory，Anthropic做MCP体系，上下文窗口越拉越长，看起来像是模型在往下卷。
陈宗志的判断是互补，不是冲突。三个原因。
成本。百万Token窗口的推理费用远高于数据检索。不是每次访问内容都需要过Transformer，内部检索有结果就直接用。
企业级数据管控。持久化、授权隔离、审计追溯，这些模型层做不了。
多Agent协作。Transformer做的是面向单个Agent、单个会话的记忆。数据库厂商做的是提取、整理知识，不同场景用不同记忆。这些Agent记忆是企业最重要的知识财富，不应该留给Transformer厂商，应该作为自己的核心资产保留。
阿里云数据库推出Agent Context，目的就是让企业以更低开销、更高安全性做内部知识检索与管理。跨Agent协作时，数据库沉淀的知识比每次调用Transformer更高效。
按触发计费，把Serverless推到极致
Agent普及之后，数据库的商业模式也在变。
陈宗志的判断：技术、信任与商业模式是推动Agent渗透率从10%向50%迈进的三大要素，企业信任是当前最大堵点。
信任问题怎么解？阿里云数据库提供沙箱、分支管理（Fork、Merge）等能力，让Agent在探索式访问中随时回滚，并提供全链路审计。
商业模式上，头部模型公司已经有实现案例：亿级Sandbox、Scale-to-Zero成本降70%。但这里有个行业悖论——Agent把触发量推高10倍，客户却期待账单更便宜。
传统数据库不管有没有波峰波谷，都收固定费用。云原生数据库的Serverless模式按需弹性、按流量付费，Agent时代把这一波浪潮推到极致。头部模型公司会瞬时创建亿级Sandbox，单次触发量极大，存活时间不长，但亿级生命周期同时存活，费用非常可观。
谁能把伸缩做到极致，谁就能赢得市场。阿里云头部C端应用“秒悟”支持一句话生成企业级生产应用。过去一年，受此类AI Agent场景驱动，RDS PostgreSQL实例的触发量激增了5倍。
Vibe Coding和AI Agent创建应用，今年只是起步，爆发趋势已经明确。
Agentic DB的四根柱子
阿里云瑶池数据库正在向Agentic DB形态进化。PolarDB、RDS、AnalyticDB、Lindorm、Tair等一系列云数据库，都在围绕Agent重构，目标是新一代Agent友好型数据库。
陈宗志说得很清楚：Agentic DB不是一款全新产品，而是所有数据库在Agent时代必须拥有的能力增强。从AI Ready到AI Native，再到Agentic-Native，概念在变，方向一致——变成用户友好的数据库。
四大关键特质：
-
多模数据处理。一个引擎支撑文本、向量、图等好几类模态，避免数据孤岛。
-
极致Serverless伸缩。秒级冷启动与Scale to Zero，适应短生命周期作业。
-
数据库分支能力。像Git管理代码一样管理数据，零拷贝的Fork与Merge，适应Agent的探索式工作流。
-
自然语言接口。MCP等协议让Agent通过自然语言直接运维数据库。
阿里云还发布了AI原生数据库支撑（AIDBS），定位是企业级Data-Centric Agent的一站式开发与服务平台，让数据可以被Agent理解、调度、流动与监管。
一个部署层面的现实问题
Agent高频短连接访问数据库时，连接池配置是个容易踩的坑。传统业务按峰值QPS配连接池，Agent场景下连接创建和销毁的频率远高于查询本身。
以PostgreSQL为例，默认max_connections通常为100，在亿级Sandbox场景下远远不够。但盲目调大又会撞上系统文件描述符和内存上限。更稳的做法是上连接池中间件（如PgBouncer），把后端连接数控制在合理范围，前端接受高频短连接。
验证方法：观察pg_stat_activity中idle连接占比，如果长期超过70%，说明连接池配置偏保守。
这个查询能快速看到当前连接状态分布。idle_in_transaction状态的连接如果持续偏高，说明Agent的事务嵌套重试逻辑可能有问题，需要结合审计日志排查。
标准之争，答案在Agent手里
过去一年，几乎所有数据库厂商都在围绕Agent重构数据基础。谁才是标准？
陈宗志的回答很直接：谁对Agent更友好，谁能满足Agent的诉求，谁就是这个时代的标准。
这个判断背后有一个工程现实：Agent的访问模式还在快速演化，今天的最优解可能半年后就被推翻。数据库厂商能做的，是把伸缩、分支、多模、自然语言接口这些底层能力做扎实，让上层适配层去追Agent的变化。
对测试和运维工程师来说，这意味着接下来要关注的不是某个具体功能，而是数据库在极端并发、短生命周期、多模混合访问下的稳定性边界。压测模型要改，监控指标要加，容量规划的逻辑也要跟着换。
