← 文章 / 数据与数据库
InfoQ 4小时前 · 2026-09-09 19:10:52 · 5 阅读

当 Agent 开始写应用,数据库也得换一套打法

今天借助 AI 生成一个 Demo,已经越来越快。真正难的,不是先把页面和功能跑起来。进入生产之后,权限如何控制、环境如何交付、试错之后如何回退、多个 Agent 协作时状态如何共享,才是更难回答的问题。这些问题一旦进入生产环境,就很难再靠“先跑起来再说”解决。

9 月 5 日,DBTalk 数据库 AI 技术沙龙北京站讨论的,正是这一层。围绕“面向 Agent 开发的数据库新范式”,腾讯云数据库 PostgreSQL 团队把视角从模型能力继续下探。讨论的重点,也落到了 Agent 应用真正落地时最容易卡住的底座问题上。当应用生成速度越来越快,数据库能不能同步完成从存储组件到生产底座的角色转换,成为现场反复讨论的核心。

从 Demo 到生产,应用后端要先补齐

黄辉首先抛出了一个现实判断:AI 缩短的是代码生成时间,不是生产工程的责任清单。今天生成一个 Demo 可能只要一分多钟,但真正上线时,身份认证、权限隔离、弹性伸缩、成本控制和数据安全,一个都不能少。真正的门槛,已经不再只是“能不能写出来”,而是“能不能稳定跑起来”。

图片

围绕这一点,腾讯云最新推出的 云开发 CloudBase for Supabase 版 给出的思路,是把 Schema 当成应用后端的契约。Schema 不只是表结构,也是 API、鉴权和权限控制的起点。平台基于 Schema 直接映射出 REST API 和 RPC 接口。再结合 JWT、表级授权和行级安全策略,把原本分散在应用层的后端能力尽量下沉到数据库侧完成。对开发者来说,这意味着很多过去需要额外补齐的服务端能力,可以在数据库这一层得到更直接的承接。

AI 场景也在倒逼数据库重写自己的交付逻辑。传统云数据库建库通常仍是分钟级,而资源池化之后,数据库资源返回时间可以压到 3 秒以内。计费侧则按 CU 结算,1 核 2G 每小时记为 1 CU,更适合 AI 应用高波动、低活跃率的运行方式。对应到生产场景,这套模式解决的不是“数据库够不够用”,而是“数据库能不能跟上 AI 应用的生成和试验节奏”。

Agent 一多,真正难的是记忆和边界

施博文把问题进一步推到了多 Agent 协作。现场提到两组数据:Neon 判断未来 AI 驱动的数据库请求占比可达 80%。Gartner 预计到 2027 年,企业级 Agent 采用率将达到 33%。协作形态正从 agent to agent 走向 agent team to agent team。数据库也不再只是存数据的地方,而开始承担协作状态管理的角色。

图片

他把多 Agent 场景下最容易出问题的地方归成三类:长期记忆不可靠、隔离边界不清晰、中间状态难以回退。现场还提到一个很典型的现象:早期很多 Agent 的“记忆”只是文本文件,内容一多,不仅难以复用,也很难真正隔离。说到底,需要的是一个能把状态存住、隔开、也能回退的数据底座。

腾讯云 PostgreSQL 在这里形成了较完整的组合能力。事实记忆可以落在关系表里,语义记忆可以通过 pgvector 处理向量检索,关系记忆则可以交给 Apache AGE 做图计算。执行层用 Cube Sandbox 做 microVM 级隔离,数据层再通过多租户和行级安全策略划清访问边界。再加上 PG 18 的 branch 能力,数据库第一次真正像代码一样,拥有了“先分支试,再按点回”的实验方式。实验测试数据显示,3.8GB 数据库传统克隆需要 1200 多毫秒,而采用 clone 能力后只需 56.8 毫秒,提速约 22 倍。这些能力放在一起,解决的已经不是单点效率问题,而是多 Agent 协作能否真正进入可治理状态的问题。

海量环境背后,数据库也得换一套资源模型

李晓慧把视角进一步拉向云原生 PostgreSQL 产品形态。她提到,进入 2026 年后,企业内部对 AI 和 Agent 的使用需求明显增长。问题已经不再是“要不要用”,而是“怎么支撑海量环境同时运行”。传统 DBA 审核式开库、固定资源模型和单一数据形态,正在越来越难匹配这种变化。

图片

围绕 Agent 场景,即将发布的 云原生数据库 TDSQL-C PostgreSQL 版重点强调了几项能力。首先是 Serverless:闲时计算节点缩到 0,需要时 1 秒内弹起。“闲时归零”不仅是弹性能力,也是成本模型成立的前提。其次是 branch 分支能力。基于底层存储的 Copy-on-Write,PB 级数据可以在 1 秒内完成克隆,且分支数量不受限制,对主库零干扰。与此同时,云原生数据库 PostgreSQL 也在继续补齐多协议接入能力。SQL、REST、MCP 等不同接入方式,都在往同一个数据库底座上收拢。

从这个角度看,数据库资源模型的变化,并不只是扩容速度更快、计费方式更细。它开始真正适应 Agent 场景下高频试验、快速复制和即时回退的运行节奏。这也是数据库从“AI 就绪”继续走向“AI 原生”时,产品形态必须回答的问题。

从本次活动的内容分享可以看到,面向 Agent 的数据库演进,腾讯云数据库正在沿两条线同时推进:一条继续深入数据库内核本身,围绕分支、隔离、回退和云原生资源模型,把底座能力做得更稳;另一条继续贴近 AI 应用工程方案,围绕隔离、REST、MCP、记忆与多 Agent 协作,把生产链路补得更完整。未来,DBTalk 数据库 AI 技术沙龙将继续围绕这些方向展开,持续关注技术演进与场景实践,推动数据库能力与 AI 应用的深度结合。

原始来源: InfoQ

评论 (0)