Agent 时代的数据库长什么样——DTCC 2026 给了我们一张新底座

Agent 时代的数据库长什么样——DTCC 2026 给了我们一张新底座

2026 年 8 月 27 日，DTCC（中国数据库大会）现场，腾讯云副总裁王义成说了一句让台下数据库圈沉默的话：Agent 时代的数据库，不是给人用的。

紧接着他抛出第二个判断：模型决定了 Agent 的下限，数据决定了它的上限。

两句话放在一起，意味着数据库厂商已经默认了一个前提——Agent 真正进生产的瓶颈，不在模型，在数据。

这也是腾讯云当天发布的 TDSQL Nexa 想回答的核心问题：当数据库的服务对象从"坐在工位上的人"变成"自己生成 SQL 的 Agent"，整套数据架构必须重做。

一、Agent 时代的数据库，正在从档案柜变成工位

过去三十年，数据库的设计目标很清晰：接住人写的 SQL，稳定、快速、不丢数据。工程师写一条 SELECT，业务人员打开报表，App 沿着固定路径完成增删改查——数据库只负责"记事实"。

Agent 来了以后，这套假设开始崩。

调用什么时候发生、访问哪些数据、需要多少资源，Agent 自己决定。确定性请求变成了概率性请求，传统数据库那种"假设输入路径可枚举"的优化思路，碰到了天花板。

王义成在 DTCC 现场把生产级 Agent 碰到的数据问题归纳为三类：

• 失忆：每次新会话都要重读全部历史，速度慢、成本高，模型被旧信息干扰；
• 资源窒息：Agent 高并发发起查询，OLTP 数据库瞬间被打满；
• 自我进化困难：Agent 试错成本高，改坏一行生产数据，可能就是企业级事故。

三个问题，对应的不是单点优化，是整套数据库架构要重写。Nexa 的整套产品（Nexa 核心 + TDSQL Boundless + TDSQL-C + Agent Memory + DatabaseClaw）就是按这三个病开的药方。

二、Nexa 的解法：一张多模表，把四套引擎藏到背后

假设一个业务问题：

上季度，华东区哪些商品的复购率下降了？原因是什么？

Agent 要答这个问题，至少要去三个地方——MySQL 取订单、数仓计算复购率、知识库查商品资料和用户反馈。三套系统的接口、权限、更新频率各不相同，团队每接一类新数据，运维成本就涨一截。

Nexa 给出的答案是多模统一表。

对 Agent 来说，入口只有一张表和一套 SQL。具体查询该走事务、搜索、AI 计算还是分析引擎，由 Nexa 核心引擎在内部路由。对外是一个统一的"工位"，对内是四个分工明确的"工种"。

腾讯云公布的对比测试是这么说的：用 Nexa 替代 PostgreSQL（在线）+ ClickHouse（可观测）+ Redis（缓存）+ S3（多模态）这套 Langfuse 默认架构，Agent Trace 场景性能提升 10 倍以上；面向中等规模应用的 SQL 人工零介入；更广的业务场景下，Agent 业务性能平均提升 50%（数据来源：腾讯云 DTCC 2026 现场公布）。

这一刀切的是 Agent 工程化最大的隐性成本：数据接入复杂度。

但光有统一表还不够。Nexa 真正区别于传统数据库的地方，在于它把"业务语义"也接管了过去。

传统数据库里，Agent 看到的是 order_id、order_status 这些字段名。字段名只告诉它"这是什么"，不会自动告诉它"销量应该按已支付算、复购率按用户算、退款订单要扣除"。这些业务口径往往藏在资深员工脑子里，写在零散的 Wiki 里。

Nexa Knowledge 做的就是这件事——扫描纳管的数据资产，做数据建模，把隐藏在字段背后的业务规则挖出来，喂给 Agent。结果就是：Agent 生成的 SQL 不再只是语法正确，而是口径正确。