当 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 也未必能真的用对。数据库中的表名、字段名和数据类型，只能描述数据的基本结构，很难完整表达企业内部的业务规则。比如，数据库中可能同时存在多个与“收入”相关的字段，但它们对应的业务口径可能不同。仅凭字段名称，Agent 很难判断应该使用哪一个。 这些隐藏在数据背后的字段含义、指标口径和业务规则，就是企业语义。Gartner 在今年发布的一项分析中指出，企业语义是影响 Agent 准确性的重要因素。Agent 需要理解企业数据之间的关系和规则，才能更准确地完成任务。 对企业来说，这两类问题往往交织在一起。Agent 要完成一次数据查询，既要找到正确的数据，也要弄清楚应该遵循什么业务口径。任务链条越长，跨系统调用越频繁，对底层数据组织和业务知识管理的要求也就越高。 TDSQL Nexa 如何重新组织多模数据与企业知识？ 要让 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 对话内容和图片等，也可以将其放到对象存储中，其他元数据继续保留在本地，以兼顾访问性能和存储成本。 AI 计算引擎：让多模态数据加工与后续使用衔接起来 多模态数据进入系统后，还需要经过解析、抽帧、打标和向量化等处理，才能用于后续检索和训练。在传统架构中，这些工作往往由不同的计算任务和系统分别承担，加工完成后还需要将结果同步到数据库或搜索引擎。 TDSQL Nexa 将 AI 计算引擎 纳入整体架构，统一纳管 CPU、GPU 异构算力，并提供数据处理、分布式计算和作业编排能力。图片、视频等原始数据经过解析、质量过滤、推理打标和 Embedding 生成后，产生的向量、标签和元数据可以进一步与宽表、搜索等引擎衔接，供后续检索和分析使用。 以训练数据准备为例，算法团队需要从大量原始数据中筛选有价值的样本，再进行特征提取和数据加工。AI 计算引擎可以承接