Agent 的下一场战争不在模型，在数据库

过去一年，Agent 的发布会一场接一场。演示视频里，它能查资料、写代码、订机票、做报表，像一个不知疲倦的数字员工。

可一旦把它放进生产环境，故事常常变成另一个版本：任务一多，数据库连接先被打满；十几个 Agent 同时跑，测试数据互相污染；想回滚某个中间步骤，发现只能整库恢复；为了一个临时实验，DBA 要新建一套实例，审批走完，活动已经结束了。

问题不在模型。模型决定 Agent 能做什么，数据库决定 Agent 能不能上线。

传统数据库是按“人”的节奏设计的：建库要审批，扩容按天算，测试环境共用一套，回滚靠备份。Agent 的节奏是秒级、批量、可丢弃。两种节奏撞在一起，数据库就成了 Agent 落地时最硬的那块天花板。

10月29日腾讯数字生态大会 AI 产品发布台，腾讯云数据库带来TDSQL-C PostgreSQL产品的全新升级，定位很直接：让 Agent 拥有生产级数据库后端服务。这句话听起来像口号，但把它拆开，会发现它其实在回答一个更具体的问题——当数据库的“用户”从人变成 Agent，数据库本身该怎么改？

先看负载。传统业务数据库追求稳定：白天高峰、夜间低谷，容量按峰值预留。Agent 的负载却像心电图——可能一整天没人用，也可能因为一条提示词突然拉起上百个并发任务。为峰值买断资源是浪费，按传统规格扩容又太慢。

再看环境。一个 Agent 任务要经历开发、测试、灰度、生产四个阶段。传统做法是共用一套测试库，或为每个项目建一套实例。到了“一人百 Agent”的时代，环境数量指数级上升，建库速度直接决定迭代速度。

数据形态也变了。Agent 面对的不只是表格，还有文档、日志、知识片段、向量、图关系。它既要跑事务，又要做检索，还要在库内分析。过去这些能力分散在关系库、向量库、搜索引擎和数仓里，靠 ETL 和胶水代码连接；现在，Agent 要求它们在同一份数据上完成。

最后是生命周期。传统数据库只关心“存”，开发、测试、灰度、回滚由外围工具拼装。Agent 的工作流却是连续的：实验失败要能回到任意节点，灰度出问题要能秒级切走，任务结束要能自动回收。数据库如果只负责存储，Agent 的“可逆性”就无从谈起。

四件事叠加，说明问题不是加一个向量字段就能解决。Agent 需要的不是一款更大的数据库，而是一套能跟着它快速试错、快速回收的运行环境。

二、四层架构：不是功能堆叠，是重画边界

TDSQL-C PostgreSQL 给出的答案，是一套四层架构。从上往下看，分别是 AI 应用全场景层、多协议接入层、云原生双引擎计算层和 AI Native Storage 存储底座。

图：TDSQL-C 的四层架构，把应用接入、协议、计算、存储收进同一套底座

最上面是场景层，覆盖 Supabase、AI Agent 开发者和主流工具链；第二层是协议层，MCP、REST、SQL通道并列，Agent 可以用自己熟悉的方式接进来；第三层是计算层，PostgreSQL 与 MySQL 双引擎，加上 Serverless 和 Branch；最下面，是负责可靠性、成本和多模存储的 AI Native Storage。

这四层不是四套产品拼在一起。它真正做的事情，是把 Agent 工作流的边界收进了数据库：上面接应用和协议，中间管计算和分支，下面管存储和冷热。传统数据库的边界停在“存储”二字，TDSQL-C 把它往前推到了“环境”。

为什么是 PostgreSQL？因为它的扩展能力天生适合承接这种变化。自定义类型、索引方法、扩展机制，让它能长出向量、时序、图等能力；Supabase、PostgREST 这些生态，又让它天然靠近“数据库即后端”的开发方式。PostgreSQL 不是一款固定的数据库，更像一个可以不断扩展的框架。对 Agent 来说，这种可塑性比单纯的 TPS 更重要。

三、四个能力，拆开看技术含金量

1. Serverless：1 秒冷启动，难的不是“快”

TDSQL-C 给出的数字是：Scale-to-0 冷启动不超过 1 秒，闲时不访问不计费，批量任务峰量翻百倍仍能毫秒级弹起。

图：Serverless 的 Scale-to-0 曲线

难的是从 0 到 1 的那一下，而不是从 1 到 100

1 秒听起来只是一个速度指标，但在数据库里，它意味着一条很长的链路要在瞬间跑完：计算资源调度、存储挂载、日志恢复、Buffer Pool 预热、扩展加载、连接建立。少一环，冷启动就会变成“冷等待”。

大家盯着“弹起速度”，却容易忽略弹起之后数据是不是对的、事务是不是一致的、连接池会不会瞬间打爆。快只是入场券，一致才是底线。

对 Agent 来说，这解决的是成本结构：开发、测试、临时任务这些长尾场景，不用时归零，用时再弹起。试错越多，弹性越值钱。

2. Branch：零拷贝，给 Agent 一颗“后悔药”

Branch 是这套架构里最像“为 AI 而生”的能力。官方说法是：PB 级数据零拷贝克隆，毫秒级拉起独立实验环境，分支数量支持 100+。

图：开发、测试、灰度、生产，每个阶段都可以用 Branch 或 Serverless 切开

零拷贝的核心是 Copy-on-Write。克隆的一瞬间，新分支并不复制全量数据，而是和主库共享同一份存储快照；只有写入发生时，才把被修改的数据页复制出来。所以分支可以做到“秒级创建、按需计费”，写多少算多少。

这件事对 Agent 开发的意义，比“省存储”大得多。它把“环境”变成了一个可以随手创建、随手丢弃的东西：每个 Agent 任务一个分支，测试数据不会污染主库；每次长任务跑到一半，可以存档，失败了回到任意节点。

但 Branch 不是备份。它共享底层数据页，适合做环境隔离和实验，不适合替代独立的备份与容灾。分支开得越多、活得越久、写得越重，存储放大和回收治理就越重要。

3. 多协议：让 Agent 用自己熟悉的语言说话

MCP 是 Anthropic 提出的模型上下文协议，专为 Agent 设计，可以直连 Cursor、Dify、LangChain 等工具；REST 基于 PostgREST，把数据库表直接映射成 HTTP API；SQL 负责复杂事务和分析；AI Toolkit 则把向量检索、库内分析、大模型调用封装进内核。

这四条通道，对应的是四种现实。Agent 技术栈各异，没人愿意为了一套协议重写后端。只提供 SQL，接入成本就转嫁给了开发者；只提供 REST，复杂事务又容易失控。多协议的价值，不是“什么都能接”，而是“让合适的场景走合适的通道”。

AI Toolkit 里的几个组件值得单独说：DiskANN 负责磁盘型向量检索，突破内存限制，官方召回率 99%+；列式执行把实时分析放进库内；AI 优化器按查询特征规划执行路径；tencentdb_ai 让 SQL 直接调用大模型。它们指向同一个方向：AI 能力不该是数据库外面的旁路，而应该是库内的一等公民。

4. AI Native Storage：把“贵”和“抖”一起解决

Agent 的数据底座，最后都要落到存储上。TDSQL-C 的存储层做了几件事：重构日志系统、支持多数据写入协议、行列混存、构建地域级全对象存储架构。

图：三 AZ 全对等写、行列混存、对象存储冷热分层，构成 AI Native Storage 的底座

可靠性上，默认 3AZ 部署，三副本全对等写，任意 2/3 副本确认即返回，IO 小于 50ms；SLA 99.995%，RPO=0，RTO≤60 秒。坏盘、网络抖动对业务无感；真出事，数据不丢，分钟级恢复。

成本上，支持实例、库、表级压缩，叠加双级压缩，压缩率 50%~70%；再通过库表到数据级的智能落冷，把冷数据下沉到对象存储 COS。官方口径是单位 QoS 成本较同类产品下降 200%+。按绝对值理解，成本量级大约是对标产品的三分之一，具体仍要看账单。

性能上，行存撑 TP，列存撑 AP，向量索引撑语义召回，全文索引撑关键词检索。一份数据，多种访问方式，减少了过去“关系库 + 向量库 + 数仓”之间的搬运，也少了一层数据不一致的风险。

零抖动也是价值：坏盘替换、网络抖动、在线变更对业务无感。Agent 最怕的不是慢，而是“时快时慢”；稳定本身就是性能。

四、专家看门道，用户看疗效

如果让一位数据库架构师来挑刺，他大概率会先问三个问题：冷启动之后，数据一致性怎么保证？分支这么多，元数据和垃圾回收怎么管？多协议接进来，权限边界画在哪里？

这三个问题，恰好对应 TDSQL-C 这套架构的真正难点。它把计算和存储拆开，换来了弹性，但也把运维复杂度从“管实例”转移到了“管平台”；它把环境变成分支，换来了速度，但也要求更精细的生命周期治理；它把数据库开放给 MCP 和 REST，换来了接入便利，但也把安全从“数据库内部”推到了“整个 Agent 链路”。

所以，这不是一次简单的产品升级，而是一次边界重画。 边界重画之后，DBA 不会消失，但工作内容会变：从建库、扩缩容、备份，转向策略、权限、成本和安全治理。

站在用户视角，标准很朴素：能不能让开发者少等、少配、少背锅。美团 NoCode 的 300% 联调效率提升，解决的是“等环境”；Supabase、Cursor、Dify、FastGPT 的接入，解决的是“少改代码”；WorkBuddy、元宝、混元、NoCode 这些负载跑在上面，解决的是“敢不敢上生产”。官方披露的数字是 50 万开发者、每天数十亿次请求、99.995% 的 SLA。

从第三方分析的视角看，数据库市场的竞争维度正在换挡。过去比 TPS、比兼容性、比价格；现在还要比“环境创建速度”“分支隔离能力”“协议覆盖度”“单位任务成本”。TDSQL-C PostgreSQL 把这几件事打包成一个底座，本质上是在抢一个新的生态位：不是做 Agent 的数据库，而是做 Agent 的操作系统。

五、冷静看：三个不能忽视的边界

第一，Serverless 不是万能药。1 秒冷启动对开发、测试、突发流量很友好，但对 p99 延迟敏感的核心交易，仍然需要预留容量。

第二，Branch 不是备份。它适合实验和环境隔离，不适合替代容灾。分支的生命周期、存储放大、权限回收，都需要一套治理规则，否则“一人百环境”很快会变成“一人百笔糊涂账”。

第三，多协议不是无门槛。MCP 和 REST 让 Agent 接得更顺，也让数据暴露面更大。提示词注入、越权访问、批量拉取，这些风险不会因为协议标准而自动消失。行级安全、最小权限、全链路审计，一个都不能少。

还有一笔账不能忽略：成本。Scale-to-0 省的是闲置计算，但分支多了、存储涨了、跨 AZ 流量大了，账单一样会上去。Serverless 不等于免费，它只是把“为峰值付费”变成了“为使用付费”。

六、结语：数据库的“Agent 时刻”

TDSQL-C PostgreSQL 真正值得讨论的，不是某一个参数，而是它把“生产级”三个字拆成了可操作的能力：秒级弹性、环境隔离、零拷贝分支、多协议接入、金融级存储、按量成本。

过去，数据库是 Agent 身后的一个资源池；现在，它开始变成 Agent 身前的运行环境。Agent 可以在这里开发、试错、灰度、回滚，也可以在这里被隔离、被审计、被回收。

模型决定 Agent 的上限，数据库决定 Agent 的下限。当 Agent 可以安全地犯错、快速地重来，它才真正从 Demo 走进生产。

这大概就是数据库的“Agent 时刻”：不是数据库变得更像 AI，而是 AI 终于需要一个像数据库一样可靠的地方，安放它的每一次尝试。