當 Agent 成為數據庫新用户，騰訊雲如何解決「未知」的難題？

作者 | 凌敏

如果説 2025 年是 Agent 元年，那麼今年，無疑就是 Agent 的「爆發年」。

從寫代碼、做研究報告到處理日常業務，Agent 正在接手越來越多具體的工作。同時發生變化的，還有它與數據的關係。過去，數據庫主要服務於人和業務系統，查詢什麼、如何調用，一般由開發者提前設計好。現在，Agent 也開始直接參與其中，成為數據使用者。但讓 Agent 連上數據庫，只是第一步。怎麼讓 Agent 快速找到需要的數據，並且知道這些數據該怎麼用？背后還有不少問題需要解決。

這些變化，也讓數據庫廠商開始重新審視原有的數據架構。數據存儲、檢索、計算以及業務語義管理，都需要適應新的使用方式。

騰訊雲今年 8 月推出的 AI 原生多模數據庫 TDSQL Nexa Lakebase，就是在嘗試將這些能力整合到一套統一的數據體系中。在 10 月 30 日舉行的 2026 騰訊全球數字生態大會 AI 原生數據庫專場上，騰訊雲數據庫進一步介紹了 TDSQL Nexa Lakebase 的技術架構與應用實踐。

它試圖回答的，是兩個企業普遍關心的問題：企業數據攢了不少，卻散在不同系統里，Agent 很難直接把它們組織起來用；就算找到了需要的數據，也未必讀得懂它在業務上是什麼意思。

1

 Agent 能找到數據，就能真的用對嗎？

第一個問題，是不少企業長期存在的老問題。只是到了 Agent 時代，隨着 Agent 開始頻繁調用不同來源的數據，原有的數據孤島和系統協同問題變得更加突出。

在 Agent 出現以前，企業的業務數據就已經分散在不同系統中。比如，訂單、交易記錄等結構化數據通常存儲在不同的關係型數據庫中，文檔、圖片等非結構化數據可能保存在對象存儲或文件系統里。每套系統都有自己的數據結構和處理方式，主要依靠接口和同步鏈路完成協作。

Agent 加入后，一個任務可能同時涉及結構化數據和非結構化數據，也可能需要在多個系統之間反覆查詢。如果繼續沿用原來的架構，企業就需要處理更多數據同步、索引更新和結果整合工作。鏈路越多，暴露出來的問題也就越多。更麻煩的是，數據分散在不同系統中，Agent 首先得知道去哪里找。不同系統各有一套查詢方式，檢索結果還需要進一步關聯和篩選。

即便找到了這些數據，Agent 也未必能真的用對。數據庫中的表名、字段名和數據類型，只能描述數據的基本結構，很難完整表達企業內部的業務規則。比如，數據庫中可能同時存在多個與「收入」相關的字段，但它們對應的業務口徑可能不同。僅憑字段名稱，Agent 很難判斷應該使用哪一個。

這些隱藏在數據背后的字段含義、指標口徑和業務規則，就是企業語義。Gartner 在今年發佈的一項分析中指出，企業語義是影響 Agent 準確性的重要因素。Agent 需要理解企業數據之間的關係和規則，才能更準確地完成任務。

對企業來説，這兩類問題往往交織在一起。Agent 要完成一次數據查詢，既要找到正確的數據，也要弄清楚應該遵循什麼業務口徑。任務鏈條越長，跨系統調用越頻繁，對底層數據組織和業務知識管理的要求也就越高。

2

 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 計算引擎可以承接其中的處理任務，並將加工結果接入后續的數據存儲與檢索鏈路，減少不同系統之間的數據搬運和重複加工。

Nexa Knowledge：讓 Agent 理解企業自己的業務語言

把不同數據放進一套架構，讓 Agent 能夠統一查詢，只解決了問題的一部分。

正如前文所説，Agent 即使找到了正確的數據，也可能因為不瞭解企業內部的業務規則而得出錯誤結果。數據庫的表結構和字段信息，並不能完整表達這些知識。為此，TDSQL Nexa 還在數據引擎之上增加了 Knowledge 能力，用來構建和維護企業語義。

Nexa Knowledge 先從已有數據庫中提取表、字段和關聯關係，建立基礎的數據語義；企業還可以補充指標定義、業務術語、業務規則、文檔和專家經驗。 系統對這些材料進行解析和整理，將有價值的信息沉澱為 Skill、術語、澄清規則、已驗證問答和世界事實五類知識資產。

Agent 接到查詢任務時，可以檢索相關知識，瞭解應該使用哪些數據、遵循什麼指標口徑，以及採用怎樣的查詢方法。這些信息可以作為 SQL 生成和數據分析的依據，減少模型僅憑字段名稱推測查詢邏輯的情況。

這套語義體系還會隨着業務使用持續更新。新的文檔、字段變化，以及查詢過程中發現並確認的語義偏差，都可以重新沉澱到對應的知識資產中，供后續任務複用。對企業來説，原本散落在數據結構、業務文檔和專家經驗中的知識，終於可以逐步形成一套能夠被 Agent 檢索和調用的語義體系。

從多引擎協同到 AI 計算引擎，再到 Nexa Knowledge，TDSQL Nexa 試圖把數據存儲、處理和業務語義管理連接起來。數據可以在不同引擎之間流轉，企業積累的業務知識也有了統一沉澱和持續更新的地方。最終，讓 Agent 更準確地找到、理解和使用企業數據。

3

 從智能駕駛到企業 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% 以上。

4

 數據庫的邊界正在延伸

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 原生數據庫接下來需要回答的問題。