AI 資料庫是什麼？湖庫一體、多模表與 Agent 工作負載完整解析

重點摘要

• 2026 年 7 月 1 日，OceanBase CTO 楊傳輝在量子位撰文指出，AI 正同時改變資料庫的三個維度：使用者從應用程式擴到自主 Agent、資料從結構化擴到多模態、工作負載從事務/分析擴到搜尋與上下文工程。
• Databricks、Snowflake 從湖倉補 OLTP 能力，OceanBase、Oracle 從交易庫補 OLAP，MongoDB、Milvus、Elasticsearch 從專用庫補通用能力，路線不同，終點看起來趨向同一個統一底座。
• 湖庫一體要進入企業生產環境，最難的不是功能整合，而是治理邊界：向量檢索若繞過結構化資料的行級權限控制，整個架構就無法通過安全審查。（本文含 OceanBase CTO 署名觀點，屬廠商框架，具體效能未經第三方驗證。）

2026 年 7 月 1 日，OceanBase CTO 楊傳輝在量子位發表長文，正式宣布推出「湖庫一體」AI 資料庫架構（Lakebase）。他在文中提出一個具體問題：當成千上萬個 Agent 同時讀寫、搜尋、試錯、回滾並生成上下文，傳統的資料庫架構還撐得住嗎？他的答案是否定的。這個問題本身不是新的，但楊傳輝的工程分析，和整個業界正在發生的架構收斂，都值得技術背景的工程師認真研究一遍。

為什麼 Agent 時代讓現有資料庫架構撐不住？

資料庫架構長期是圍繞人類應用、確定性交易和結構化資料分析設計的。這不是說它設計得不好，而是它回答的是另一個時代的問題。

Agent 把三件事同時改了。使用者從應用程式擴到大量自主運行的 Agent，每個 Agent 都可能在任意時刻發起讀寫、搜尋、試錯或回滾。人的行為有高峰和低谷，Agent 的工作節奏近乎隨機，楊傳輝稱之為「每天都可能有一個小型的雙十一」，彈性伸縮因此從可選配置變成基礎假設。

資料形態從結構化擴到多模態。資料庫不只管 Int、Float、Varchar，還要管向量、全文索引、JSON 半結構化、影像音訊的 LOB（Large Object，大型物件）。這些資料型別若散在不同系統，Agent 每次跨系統存取就是一次延遲、一次一致性問題。工作負載則從事務與分析，擴到搜尋、上下文工程（context engineering）與 AI 應用。上下文工程是大型語言模型（LLM，Large Language Model）應用特有的工作模式：Agent 要即時組裝出連貫的上下文視窗，對混合搜尋的延遲要求嚴格，結果也必須可信、可追溯。

三件事如果只改一件，現有架構打補丁或許能應付。三件同時改，「多套系統互相導資料」的做法就難以為繼：資料搬運帶來延遲，延遲讓上下文工程失去實時性，實時性降低的 Agent 輸出品質會系統性下降。這正是楊傳輝說「AI 資料庫不是傳統資料庫增加幾個 AI 函式，也不是向量資料庫補上 SQL 能力」的工程依據。

湖庫一體怎麼運作？三條邊界與兩個核心結構

楊傳輝在文中點出，湖庫一體要進入生產系統，至少要合併三條邊界。這個框架本身跟廠商無關，可以當成評估任何 AI 資料庫架構的基本清單。

資料形態要統一：結構化、半結構化、非結構化資料和向量，要在同一套表語義下管理。應用層（包括 Agent）不需要知道「這欄在關係型資料庫、那欄在向量資料庫」，只需要操作一張表。計算路徑要統一：SQL 查詢、實時分析、混合搜尋、Spark ETL、Ray 上的 AI 計算，要在同一份資料上協作，而不是靠不斷匯出轉換來協作。治理邊界要統一：元資料、權限、行級控制、審計、版本、生命週期，必須對所有資料型別一致生效。楊輝的說法是：結構化欄位有權限控制、向量檢索卻繞過了權限，這樣的系統進不了企業生產環境。這個邏輯帶有廠商立場，但從架構設計角度來看確實成立。

OceanBase Lakebase 的實作分三層。底層是存算分離（compute-storage separation）：資料放在對象儲存，計算層獨立運行，理論上可以做到負載上來瞬間擴容、空閒時縮到零，不需要常態預留高峰機器。中間層是多模表：同一張表裡混合關係型欄位、多模態欄位和 AI 欄位。AI 欄位是其中設計最有意思的部分，它是即時計算欄位，資料寫入後自動觸發 Embedding 或打標等模型計算，把結果寫回表裡，並保持事務一致性語義：要麼全部成功、要麼全部失敗，不允許部分 Embedding 完成的中間狀態。上層是開放計算，支援 Spark 處理 ETL、Daft on Ray 處理 AI 加工，多種計算引擎都在同一份資料上工作。

LOB 的儲存依大小分三條路徑：小型 LOB 直接在行內儲存，節省 IO；較大的 LOB 切片後存入對象儲存，行內只保留每個切片的位置資訊；特別大的 LOB 則引用外部對象儲存的既有檔案，資料庫只存元資料。三條路徑對應用層透明，Agent 存取多模態資料時不需要自行處理多個儲存位址的路由邏輯。

「實時性靠消除搬運」是楊傳輝強調的設計原則，值得單獨說清楚。傳統做法是離線計算跑完後把結果複製回在線資料庫，中間有 T+1 甚至更長的延遲視窗。湖庫一體把離線計算（Spark ETL、Ray AI 加工）和在線查詢（SQL、混合搜尋）統一在同一份資料上，Spark ETL 寫完的資料 SQL 引擎立即能查，模型推理生成的向量混合搜尋立即可用，不需要額外同步步驟。實時性不是靠把管道加寬，而是靠把管道省掉。

各路廠商為什麼都在往同一個底座靠攏？

楊傳輝在文中描述的業界收斂趨勢，比 OceanBase 自己的產品更值得技術工程師關注。

Databricks 和 Snowflake 從湖倉和資料倉儲出發，持續補充 OLTP 事務能力。OceanBase 和 Oracle 從交易資料庫出發，持續提升 OLAP 和大數據能力。MongoDB、Milvus、Elasticsearch 從專用資料庫出發，連續強化通用資料庫能力。起點不同，方向都指向一個能同時處理交易、分析、搜尋、向量和 AI 計算的統一底座。驅動力很清楚：只要 Agent 的工作流程跨越多個資料系統，就有資料搬運、延遲和一致性問題。每個廠商都有理由告訴客戶「用一套就夠了」，客戶工程師也有充分動機減少維護多套系統的複雜度，供需都往同方向拉。

OceanBase 自己的演進路徑是：分散式 OLTP → 實時 OLAP（消除 TP 到 AP 的資料搬運）→ 多模一體（向量、全文、JSON、GIS 進同一個引擎）→ 湖庫一體（庫內事務能力與湖上開放儲存/計算統一在同一底座）。這是一條從事務出發、往上堆疊的路徑，和 Databricks 從湖/倉往下補事務的路徑，在終點上看起來有機會相遇。但各家補齊能力的方式不同：有機地長出來的能力和後期整合進來的能力，在架構上往往有本質差異。從外部要評估深度是否真的夠，目前缺乏足夠的第三方基準測試，工程師需要自行測試，不能只靠看功能清單。

進生產前，治理邊界與廠商鎖定怎麼評估？

楊傳輝的治理邊界論點，說到了一個許多工程師在 PoC 階段忽略、到生產階段才被擋住的問題。行級安全（Row-Level Security，RLS）、審計日誌，若只作用在關係型資料，而 Agent 能通過向量相似度查詢繞過去取得不應看到的記錄，這個系統就有嚴重的資料治理漏洞。這不是假設性風險，而是 AI 應用在企業落地時會真實碰到的問題。楊傳輝指的是 OceanBase 原生就把向量索引和結構化資料統一在同一套訪問控制邏輯之下，但這個說法是否在具體業務情境中成立，需要自行驗證，不能只看架構說明。

廠商鎖定是另一個需要明確評估的風險。湖庫一體的架構在概念上強調開放計算，支援 Spark、Ray 等多種計算引擎，底層用對象儲存而非私有格式，這些設計理論上有助於降低遷移成本。但 AI 欄位的 Embedding 觸發邏輯、多模表的 schema 設計、事務一致性的 API，都是廠商自定義的。一旦把 Agent 的讀寫邏輯深度整合進這套 API，換資料庫的成本並不低。工程師引入任何「統一底座」前，應該問清楚：哪些是標準介面（如 SQL），哪些是廠商私有的？做好邊界，比到時候想換廠商再來解耦容易得多。

AI 欄位的計算成本與可預測性同樣值得在上生產前仔細評估。每次資料寫入都觸發 Embedding 或打標計算，這些計算呼叫外部模型的費用如何計量、失敗時如何重試、整個事務的 SLA 如何保證，目前從公開資訊來看並不完整。高頻寫入場景下的行為，是必須自行測試才能掌握的部分。

現在最值得關注的，不是哪個廠商率先宣布「統一底座」，而是這個統一在治理層有多深：向量索引的權限路徑和關係型資料的權限路徑，究竟是共享同一套引擎，還是外掛整合後的 API 相容層？這個問題的答案，決定了一個 AI 資料庫能不能真正進入企業生產，而不只是停在 demo 環境。

常見問題

AI-native 資料庫和傳統關係型資料庫加向量外掛，實際差在哪？
關鍵差異是事務一致性和治理統一性。傳統加向量外掛的方案，向量索引通常在關係型資料的訪問控制路徑之外，無法保證兩邊資料在同一事務邊界內保持一致。AI-native 資料庫的目標是讓向量、全文、結構化資料共享同一套事務引擎和權限體系，這對有合規要求的企業生產環境來說是根本性的架構差別，而不只是功能多寡的問題。

湖庫一體說「實時性靠消除搬運」，具體指什麼？
傳統做法是離線計算（如 Spark ETL）跑完後，把結果複製回在線資料庫，中間有 T+1 甚至更長的延遲視窗。湖庫一體把離線計算和在線查詢統一在同一份資料上，Spark ETL 寫完的資料 SQL 引擎立即能查，不需要額外同步步驟。實時性不是靠加速資料搬運，而是靠省掉搬運這個步驟本身。

選擇這類「統一底座」架構，主要的鎖定風險在哪裡？
表面上強調開放（支援 Spark、Ray，底層用對象儲存），但 AI 欄位的 Embedding 觸發邏輯、多模表的 schema API、事務一致性的具體語義都是廠商自定義的。深度整合後要遷移，重寫這些部分的成本可觀。降低風險的做法是盡量把 Agent 的核心業務邏輯寫在標準 SQL 和標準介面上，把廠商特定功能封裝在薄薄的存取層，維持可替換性。