当 Agent 成为数据库新用户，腾讯云如何解决“未知”的难题？

如果说 2025 年是 Agent 元年，那么今年，无疑就是 Agent 的“爆发年”。

从写代码、做研究报告到处理日常业务，Agent 正在接手越来越多具体的工作。同时发生变化的，还有它与数据的关系。过去，数据库主要服务于人和业务系统，查询什么、如何调用，一般由开发者提前设计好。现在，Agent 也开始直接参与其中，成为数据使用者。但让 Agent 连上数据库，只是第一步。怎么让 Agent 快速找到需要的数据，并且知道这些数据该怎么用？背后还有不少问题需要解决。

这些变化，也让数据库厂商开始重新审视原有的数据架构。数据存储、检索、计算以及业务语义管理，都需要适应新的使用方式。

腾讯云今年 8 月推出的 AI 原生多模数据库 TDSQL Nexa Lakebase，就是在尝试将这些能力整合到一套统一的数据体系中。在 10 月 30 日举行的 2026 腾讯全球数字生态大会 AI 原生数据库专场上，腾讯云数据库进一步介绍了 TDSQL Nexa Lakebase 的技术架构与应用实践。

它试图回答的，是两个企业普遍关心的问题：企业数据攒了不少，却散在不同系统里，Agent 很难直接把它们组织起来用；就算找到了需要的数据，也未必读得懂它在业务上是什么意思。

第一个问题，是不少企业长期存在的老问题。只是到了 Agent 时代，随着 Agent 开始频繁调用不同来源的数据，原有的数据孤岛和系统协同问题变得更加突出。

在 Agent 出现以前，企业的业务数据就已经分散在不同系统中。比如，订单、交易记录等结构化数据通常存储在不同的关系型数据库中，文档、图片等非结构化数据可能保存在对象存储或文件系统里。每套系统都有自己的数据结构和处理方式，主要依靠接口和同步链路完成协作。

Agent 加入后，一个任务可能同时涉及结构化数据和非结构化数据，也可能需要在多个系统之间反复查询。如果继续沿用原来的架构，企业就需要处理更多数据同步、索引更新和结果整合工作。链路越多，暴露出来的问题也就越多。更麻烦的是，数据分散在不同系统中，Agent 首先得知道去哪里找。不同系统各有一套查询方式，检索结果还需要进一步关联和筛选。

即便找到了这些数据，Agent 也未必能真的用对。数据库中的表名、字段名和数据类型，只能描述数据的基本结构，很难完整表达企业内部的业务规则。比如，数据库中可能同时存在多个与“收入”相关的字段，但它们对应的业务口径可能不同。仅凭字段名称，Agent 很难判断应该使用哪一个。

这些隐藏在数据背后的字段含义、指标口径和业务规则，就是企业语义。Gartner 在今年发布的一项分析中指出，企业语义是影响 Agent 准确性的重要因素。Agent 需要理解企业数据之间的关系和规则，才能更准确地完成任务。

对企业来说，这两类问题往往交织在一起。Agent 要完成一次数据查询，既要找到正确的数据，也要弄清楚应该遵循什么业务口径。任务链条越长，跨系统调用越频繁，对底层数据组织和业务知识管理的要求也就越高。

要让 Agent 准确高效地使用企业数据，数据库需要处理的不只是数据存储和查询，还包括多种数据形态的加工、检索，以及不同计算能力之间的协同。

腾讯云 TDSQL Nexa Lakebase 的思路，是把这些能力放进一套统一架构：融合宽表、搜索、分析和 AI 计算等引擎，减少数据在多个系统之间来回搬运；同时把表字段、业务术语、指标口径和专家经验整理成业务上下文，帮 Agent 理解数据背后的含义。

据腾讯云数据库副总经理、国产数据库中心负责人梁辰介绍，TDSQL Nexa 以对象存储 COS 作为数据底座，采用 Iceberg、Lance 等开放表格式承载海量原始数据和加工产物，并通过 GooseFS 提供分布式缓存加速，改善湖上数据的访问效率。

计算层采用可插拔的多引擎架构。宽表引擎负责海量特征、标签和业务数据的存储与查询；搜索引擎支持向量检索、全文检索和多条件过滤；分析引擎采用 MPP 分布式计算框架和向量化执行模式，处理大规模分析任务；AI 计算引擎则负责多模态数据加工，提供相应的 CPU、GPU 计算资源。

不同引擎负责各自擅长的任务，NTS 则负责连接这些引擎，让数据能够在不同处理环节之间流转。具体来说，NTS 既负责外部数据接入，将 MySQL、PostgreSQL、MongoDB 等数据源中的数据同步到 TDSQL Nexa。也负责内部引擎之间的数据同步，例如，宽表引擎中的数据可以通过 NTS 同步到搜索和分析引擎，供后续的向量检索、全文检索和数据分析使用。这样，同一份业务数据就能支持不同类型的查询，不必由应用层反复拼接结果。

如果企业暂时不希望迁移原有数据，也可以通过 ShortCut 联邦访问外部数据源，直接查询原系统中的数据。企业可以根据数据实时性、性能和管理需求，选择原地访问或同步纳管。目前，TDSQL Nexa 支持接入 MySQL、PostgreSQL、MongoDB、COS/S3 等多类数据源。

在不同引擎已经接通的基础上，TDSQL Nexa 还需要解决一个问题：开发者和 Agent 如何使用这些能力？

TDSQL Nexa 在上层设计了统一的智能编排路由引擎，通过声明式 DDL 定义逻辑表、字段类型和索引类型。查询发生时，系统会根据查询需求和代价模型，判断调用哪个引擎、使用哪种索引完成查询。用户不必分别了解底层各个引擎的数据组织方式。对外，TDSQL Nexa 提供 SQL、REST、MCP 等访问方式，计算侧兼容 MySQL、PostgreSQL、OpenSearch 等协议生态，降低现有系统和开发工具的接入改造成本。

为 TDSQL Nexa 提供多模数据底座的，是腾讯云数据库 TDSQL Boundless。它在原有分布式事务与可扩展存储的能力上，扩展了自动冷热分离的功能来降低系统使用成本，同时构建了宽表、全文、向量和列存能力。

对于 AI 应用产生的大量数据，Boundless 可以结合数据访问情况进行冷热分层：热数据保留在本地 CBS，冷数据自动下沉到 COS。针对占用空间较大的字段，例如 Agent 对话内容和图片等，也可以将其放到对象存储中，其他元数据继续保留在本地，以兼顾访问性能和存储成本。

多模态数据进入系统后，还需要经过解析、抽帧、打标和向量化等处理，才能用于后续检索和训练。在传统架构中，这些工作往往由不同的计算任务和系统分别承担，加工完成后还需要将结果同步到数据库或搜索引擎。

TDSQL Nexa 将 AI 计算引擎 纳入整体架构，统一纳管 CPU、GPU 异构算力，并提供数据处理、分布式计算和作业编排能力。图片、视频等原始数据经过解析、质量过滤、推理打标和 Embedding 生成后，产生的向量、标签和元数据可以进一步与宽表、搜索等引擎衔接，供后续检索和分析使用。

以训练数据准备为例，算法团队需要从大量原始数据中筛选有价值的样本，再进行特征提取和数据加工。AI 计算引擎可以承接其中的处理任务，并将加工结果接入后续的数据存储与检索链路，减少不同系统之间的数据搬运和重复加工。

正如前文所说，Agent 即使找到了正确的数据，也可能因为不了解企业内部的业务规则而得出错误结果。数据库的表结构和字段信息，并不能完整表达这些知识。为此，TDSQL Nexa 还在数据引擎之上增加了 Knowledge 能力，用来构建和维护企业语义。

Nexa Knowledge 先从已有数据库中提取表、字段和关联关系，建立基础的数据语义；企业还可以补充指标定义、业务术语、业务规则、文档和专家经验。 系统对这些材料进行解析和整理，将有价值的信息沉淀为 Skill、术语、澄清规则、已验证问答和世界事实五类知识资产。

Agent 接到查询任务时，可以检索相关知识，了解应该使用哪些数据、遵循什么指标口径，以及采用怎样的查询方法。这些信息可以作为 SQL 生成和数据分析的依据，减少模型仅凭字段名称推测查询逻辑的情况。

这套语义体系还会随着业务使用持续更新。新的文档、字段变化，以及查询过程中发现并确认的语义偏差，都可以重新沉淀到对应的知识资产中，供后续任务复用。对企业来说，原本散落在数据结构、业务文档和专家经验中的知识，终于可以逐步形成一套能够被 Agent 检索和调用的语义体系。

从多引擎协同到 AI 计算引擎，再到 Nexa Knowledge，TDSQL Nexa 试图把数据存储、处理和业务语义管理连接起来。数据可以在不同引擎之间流转，企业积累的业务知识也有了统一沉淀和持续更新的地方。最终，让 Agent 更准确地找到、理解和使用企业数据。

一套新的数据架构有没有价值，最终还是要看它能否解决实际业务问题。腾讯云数据库在大会上分享了两个基于 TDSQL Nexa 的客户案例，一个来自智能驾驶，另一个来自教育行业。

一辆车在行驶过程中会产生大量图像、视频、传感器信号和事件日志。算法团队需要从这些数据中找到有价值的训练样本，尤其是一些出现概率较低、但对模型能力提升非常重要的长尾场景。

以车辆紧急制动为例，车端会将事件前后一段时间的数据打包成 Lance 文件，上传到对象存储；事件和文件的元数据存放在 MongoDB，合规和地图数据则保存在 PostgreSQL。随后，基于 Spark 或 Ray 的计算管线会提取相关特征，包括天气、路况、行人和车辆的位置、速度等信息。一次事件可能产生数百列特征描述，累计特征维度达到上万。算法团队需要从历史数据中寻找相似场景，筛选样本用于模型增量训练。

原有架构中，Doris 负责存储标签数据，ES 负责存储语义向量。不同系统各自管理数据和索引，当算法团队需要同时按照语义相似度、天气、道路和车辆状态等条件筛选样本时，还需要在应用层融合不同系统的查询结果。

引入 TDSQL Nexa 后，数据处理链路得到简化：原始数据上传至对象存储，AI 计算引擎负责特征提取和加工，处理后的特征数据写入宽表引擎，再通过 NTS 同步到搜索和分析引擎，更新相应索引。算法团队筛选样本时，可以通过一条 SQL 完成全文、向量和标量条件的混合检索，不必再分别访问多个系统并在应用层拼接结果。据介绍，该车企改造后的数据闭环效率提升了约 10 倍。

第二个案例来自教育行业。这家企业希望通过 Agent 实现对话记忆、课程资料检索，以及课程和题目相关的问题解答。实际建设中，需要管理的数据包括 Agent 会话、个人信息记录、课件和课程视频等，还涉及相应的数据加工、搜索和分析系统。原有架构中，这些能力分散在不同系统，维护成本较高，Agent 回答准确率也受到影响。

基于 TDSQL Nexa，企业将数据存储、加工、检索和分析整合到统一的数据体系中。与此同时，Nexa Knowledge 对数据库中的表、字段及其关系进行梳理，并将课程文档、视频内容和业务规则纳入企业知识体系，让 Agent 能够结合数据和业务上下文回答问题。

随着新文档持续写入、数据库字段发生变化，相关语义也可以随之调整；使用过程中发现的语义偏差，则可以经过校验后重新沉淀到知识体系中。据介绍，在综合评测中，这套方案的问题回答准确性提升了 60% 以上。

Agent 对数据库的影响，已经不只是查询方式发生变化。据腾讯云披露，过去一年，Agent 创建的腾讯云数据库（TDSQL-C）实例日均超过 2 万个，增速超过 80 倍，活跃实例突破 100 万个。Agent 已经开始大量参与数据库的创建和使用，数据库需要适应的工作方式，也需要发生变化。

腾讯云副总裁王义成在此前接受采访时，曾将这种变化概括为 Agent 带来的“未知”。Agent 由模型生成，什么时候发起请求、会产生什么样的数据、给数据库带来多大的压力，都很难按照传统业务的方式提前预估。数据库需要面对的，除了新的数据形态，还有更加难以预测的访问负载和运行需求。

从腾讯云面向 Agent 的数据库产品布局来看，相关能力已经延伸到多个方向：TDSQL-C 面向 Agent 应用后端开发，具备 Branch 秒级分支、Serverless 弹性、多 Agent 运行沙箱三大特性；TencentDB Agent Memory 负责记忆与团队知识管理，自 5 月开源以后多次登上 GitHub Trending 全球第一，目前收获了超 3w Stars；TencentDB Agent 则是全新的数据库智能体，具备感知、分析、决策、执行的完整自治能力。

当 Agent 开始承担越来越多具体工作，数据库的边界将不断延伸，既要保证数据安全、稳定和可用，也要让 Agent 能够找到数据、理解数据，并在业务过程中正确使用数据。这些能力能否真正经受住生产环境的考验，才是 AI 原生数据库接下来需要回答的问题。