當數據走向理解，如何重構一個企業級 AI 數據平台？

本文整理自作者於 10 月 20 日鏡舟 MIP 產品發布會上的演講。10 月 20 日，鏡舟科技舉辦 MIP 產品發布會，宣布產品戰略從即時分析走向統一的數據分析與智能平台，並正式發布極速統一的企業級 AI 數據平台 MIP。MIP 以 StarRocks 為技術基礎，將統一數據底座、企業級語義層和可信 Data Agent 連接起來，由貫穿全平台的治理能力支撐，幫助企業讓 AI 按業務口徑使用數據，結果可核對、可追溯。

作者|董穎婷，鏡舟科技產品負責人

出品|產業家

企業落地AI Agent的三個問題

Agent進入企業的真實業務之後，會繞不開數據、口徑和知識的問題。結合我們自己的實踐，我們總結了三個比較普遍的問題，並在每個問題後面寫出我們的思路。

問題一：數據多模態且分散。

一個Agent處理任務時，可能同時訪問二維業務表、非結構化文檔、圖片和向量數據。這些數據往往存在不同的存儲介質和系統裡，取回之後還要進一步關聯分析。這給AI Agent系統的搭建帶來了難題。

我們的思路是：多類數據要能在SQL中關聯。業務表上的數據、湖上的數據、對象存儲上的非結構化數據，都能統一檢索和查詢，查詢出來的結果還能繼續分析。數據存在不同的地方是常態，但搬遷的代價高，所以讓計算去找數據，分散的問題就可以在查詢層得到解決。

問題二：口徑需要反復解釋。

以數據分析為例，"銷售額怎麼算""哪些訂單參與計算"，都要先定義清楚。但這些知識往往散落在歷史SQL、文檔，甚至分析師的個人經驗裡。於是同一個問題容易出現不同的答案。

我們的思路是：把業務口徑定義在數據庫裡。這樣的定義可以直接轉換成可執行的計算。我們通過Semantic View把指標對應到明確的表達式，查詢結果可以追溯到對應的公式、統計範圍和最終執行的SQL，方便統一解釋口徑。

問題三：搭建過程大量重複。

搭建多個Agent時，會面臨不同的數據接入，需要重新整理相關的知識和上下文。有修正時，不同Agent之間也難以同步，這導致Agent建設過程中產生很多重複工作。

我們的思路是：以數據庫承載可重用企業上下文的管理能力，由MirrorMind統一組織知識及其關聯、版本和訪問權限，供多個Agent按需使用；會話與任務運行狀態由MirrorPilot管理。

三個問題指向同一根源：數據、口徑和上下文，缺少統一的載體。

10月20日，鏡舟科技產品發布會上，我們正式推出了MIP------極速統一的企業級AI數據平台。以數據庫為核心，它的架構設計沿著兩個方向展開，向下：為數據庫加入AI能力，升級數據底座；向上：數據庫for AI，讓企業的知識和AI Agent能力，服務更多的業務。

數據在哪裡，理解與計算就應該在哪裡。把數據、口徑和上下文放進數據庫，是因為這三件事缺的能力，恰好都要從數據庫裡長出來。

三層架構：MIP把數據與知識組織成共享能力

MIP把企業的數據與知識組織成三層，形成一套共享能力。

底層是MirrorData，一個以開源StarRocks為核心的企業級數據查詢引擎，提供極速查詢檢索和多模態分析能力。

中間層是MirrorMind，以Semantic View為核心，把相關領域的業務知識和分析師的個人經驗關聯起來，供Agent按需使用。

上層是MirrorPilot，業務Agent的運行環境。

三層之上，是各類業務應用。企業經營中常用的經營分析、售後診斷、商品選型，都可以用這套統一的底座來搭建。

後面的章節會逐層展開這三層，展示整套底座的使用方式。

• 用"售後圖片"展示MirrorData多模態檢索與業務關聯

• 用"活動預算對照"說明MirrorMind中語義定義的作用

• 以"零售經營分析"串起配置、查詢、分析與報告的完整使用流程。

MirrorData：統一的數據底座

標準SQL接入，一套計算能力服務所有應用

MirrorData是MIP的數據底座，核心是一個查詢引擎。

上層的BI報表、互動式分析、數據應用和Agent，都可以通過標準SQL接入。同一套計算能力服務不同的應用，MirrorData作為統一的查詢入口。

查詢引擎延續了StarRocks的高性能查詢能力。在此基礎上，我們做了企業級增強：權限管理、資源管控和資源隔離。

支持統一訪問內表、湖表與多模態內容

數據側的接入有三種方式。

**1.傳統內表。**內表承載業務字段、JSON、文本和向量等可查詢數據；對於圖片、文檔等內容，可通過文件引用和業務對象ID，與其派生表示及業務記錄建立關聯。

**2.湖上數據。**很多客戶的數據已經沉澱在數據湖上。MirrorData通過外部Catalog統一接入，支持Paimon、Iceberg、Hive等主流湖表格式，提供高效的湖表訪問能力。

**3.未利用的歷史文件。**企業已有的圖片、文檔和音視頻，往往難以直接參與業務分析。原始文件可以保留在對象存儲中，按任務需要完成解析和向量生成後，將文件引用、提取的文本及向量寫入表，與業務字段關聯。MirrorData統一組合檢索、過濾、關聯與聚合。

一條SQL，完成混合檢索

在極速分析和數據湖查詢的基礎上，MirrorData進一步擴展多模態檢索與關聯分析。同一個業務對象可以同時具有結構化字段、JSON屬性、文本、Embedding和文件引用，通過業務對象ID連接內容與業務事實，使檢索結果能夠繼續參與分析。

底層是三類查詢能力：

• 結構化數據：結合分區裁剪和列式掃描，完成極速分析。

• 全文檢索：基於倒排索引進行詞項匹配，例如通過MATCH_ANY匹配描述中包含"開箱"或"拆箱"的記錄。

• 向量檢索：按相似度或距離，查找相關內容。

一條SQL可以把三者串聯起來，具體的訪問路徑，取決於查詢方式和索引方式。

演示：售後訂單查詢

為了直觀展示SQL與查詢結果，我們製作了一個售後檢索操作頁。用戶上傳一張屏幕破損照片，尋找近期破損形態相似的售後記錄，再關聯訂單、批次、承運商和退款信息，為後續分析提供依據。

先將參考照片轉換為查詢向量，作為參數供檢索SQL使用。隨後在SQL中計算圖片相似度，通過售後單和訂單明細的關聯關係補充批次、承運商與退款信息，並加入時間、品類以及"開箱／拆箱"全文條件。

這些條件最終組成一條完整的SQL。也就是說，一條SQL就能完成結構化和非結構化數據的統一檢索。

訂單圖片檢索

MirrorMind：讓Agent用對口徑

數據能查到之後，下一步：Agent得理解企業的業務定義和背景知識。MirrorMind以Semantic View為核心，解決的就是這個問題。

如需詳細了解，可進一步閱讀Semantic View系列文章

•Semantic View技術解析（一）

•Semantic View技術解析（二）

• Semantic View技術解析（三）

Semantic View裡定義什麼

Semantic View記錄Agent理解業務所需的結構化定義，包括：

• 表和關聯：定義數據表的範圍，以及表之間的關聯關係。

• 維度：指標可以按哪些維度上卷、下鑽。比如活動預算按渠道、活動類型拆，或按日期匯總。

• 指標：每個指標的計算表達式和說明。除了原子指標，也可以定義衍生指標，以及窗口函數這類複雜的計算邏輯。

• 同義詞：為指標維護業務名稱、別名和說明，例如"市場總預算""促銷補貼總額"。Agent可以結合這些定義識別用戶所指的指標，減少不同表達習慣帶來的理解偏差。

Agent拿到一個問題，先在Semantic View裡找到適用的定義，再按這個口徑轉成執行語句，交給數據庫執行。

對比：有沒有Semantic View

用同一個問題做對比："公司的活動預算是多少？"

沒有Semantic View時，Agent直接查詢底表。表裡有四個金額字段，Agent不理解哪一個才是活動預算，於是把所有金額字段加總，得到約29,161,800元。這個結果是錯的，不相關的字段也被算了進去。

在演示使用的campaign_analytics中，"活動總預算"對應total_bbbb_amount，計算表達式為SUM(bbbb_amount)。Agent讀取這份定義後，選擇對應字段求和，得到1,980,000元；沒有把其他金額字段一並加入。錄像中最終執行的仍然是底表SQL，Semantic View提供了選擇和計算指標的業務依據。

Semantic View把業務名稱、指標公式和分析維度組織成可重用的定義，讓不同Agent使用共同的計算依據，減少各自解釋字段和拼接口徑帶來的偏差。查詢結果可以結合指標定義與執行SQL進行核查。

示例：零售客戶的訂單域

以一個零售客戶的訂單分析為例。在訂單域裡，需要先區分訂單和訂單明細。一筆訂單可能包含多條明細商品，兩者的統計粒度並不相同。Semantic View按訂單與商品明細建立業務主題：

• 訂單主題定義"訂單數"和"取消率"，按門店、月份分析；

• 銷售明細主題定義"折後實收金額"，按渠道、品類、商品分析。

兩個主題的統計邊界也在定義裡寫清楚：銷售額統計已支付訂單，用銷售明細主題的折後實收金額；取消率則是取消訂單數除以全部訂單數。

Semantic View定義指標怎樣計算、可以按哪些維度分析；業務規則補充統計邊界和例外；業務資料提供政策、事件與原文依據；分析方法規定拆解與核查步驟；任務記憶保留已確認的條件與結論。這些內容可獨立維護，由MirrorMind統一管理關聯、來源、版本和訪問權限，再由Agent按任務組合使用。這樣能夠說明Context不只有Semantic View，也能支撐業務上持續的知識迭代。

像管理代碼一樣管理知識

Agent需要的上下文，不止涉及一個Semantic View。比如分析一次指標異動，往往還要關聯業務知識和標準的分析流程。我們把它統稱為企業上下文。MirrorMind把這些上下文統一管理：內容的關聯、來源與版本、訪問權限。

管理方式和代碼很像，我們借鑒了Git的思路：知識可以創建分支，每個分支上有不同的版本；可以按版本回溯，查看任意版本在某個時間的快照；經過業務確認後，正確的版本再上線。業務在迭代，知識也在迭代，但每個Agent拿到的，都是經業務確認、已上線的版本。用戶的反饋會留下完整的trace記錄，成為下一輪知識迭代的輸入。

多個任務重用經確認的業務定義與背景知識，減少口徑漂移；知識更新經過驗證後採納，並保留版本與修訂依據，供後續任務重用和回溯。

MirrorPilot：Agent的運行與交付環境

數據能查到，口徑可信，最後一步是把它們組織成Agent，交付給業務。這是MirrorPilot的職責。它是企業的Agent運行和交付環境，向下串聯MirrorData和MirrorMind，對外交付結果。

四步完成一次任務

用戶側有兩條使用路徑下達任務。一條是直接對話，通過產品工作台完成分析；另一條是通過API接入原有的業務系統，重用Agent的能力。

一次任務的執行分為四步。先理解目標；再結合上下文和現有Skill，組織執行方案；然後調用工具，比如查詢Semantic View裡的具體定義；最後處理結果。簡單任務到這裡就直接交付，複雜任務會重複檢索、多步執行，再把最終結果返回給業務。

MirrorMind按任務的需要提供上下文，MirrorData負責結果的查詢和佐證。圍繞運行本身的還有一整套周邊管理：會話管理、任務狀態、資源範圍、預算、超時和運行記錄，都內置在MirrorPilot裡。

交付的不只是答案

MirrorPilot的交付物，可以是一段回答，也可以是報表和API。執行過程會嚴格留痕：這次計算用的是哪條SQL、口徑規則是什麼，都清晰可查。用戶可以繼續追問，也可以對整個任務溯源。

開放接入，能力沉澱

接入是開放的。MirrorPilot提供Agent API，企業可以從已有BI、經營門戶或業務系統發起任務，經服務端鑑權後獲取任務結果或會話鏈接，並按現有應用的交互方式完成集成。自定義Skill用於擴展分析步驟，MCP用於接入外部工具。

能力是會沉澱的。已有分析邏輯可以沉澱為SQL模板，同類問題按時間、維度等參數重用查詢邏輯，執行後返回結果，減少重複生成查詢的工作。業務知識、SQL模板和Skill都能持續重用與迭代，也支持自定義Skill的接入和管理。

因此，MirrorPilot既可以獨立運行，也可以接入企業原有的應用，逐步擴展分析能力。

MirrorControl：配套的管理控制後台

與MirrorPilot配套的，是MirrorControl管理控制後台。

配置Agent時，在這裡選擇數據範圍、知識庫，以及要用到的Semantic View和Skill。它還提供知識檢索能力，比如"取消率在企業內部是如何定義的"，輸入問題就能得到定義和提示。

示例：一個零售客戶的經營分析Agent

最後用一個脫敏案例，把三層串起來：某客戶用MIP配置了自己的經營分析Agent。

配置：先圈定範圍

配置Agent的第一步，是定義業務範圍：Agent所需的數據範圍是什麼，業務域相關的Semantic View是哪些，相關知識庫在哪裡。圈定範圍的目的，是縮小Agent的檢索範圍，避免知識混淆，造成錯誤的答案。

然後是角色、回答規則和Skill的配置。比如追問和下鑽時走什麼標準流程，輸出報告用什麼樣式，都在這裡定義。查詢和檢索工具內置在Agent裡，可以直接檢索企業內部知識和Semantic View。

演示：從一個問題到一份報告

配置完成後，看一次完整的使用過程。

進入平台，先選擇Agent，它的分析範圍在配置時已經圈定。直接用自然語言提問，比如讓Agent按渠道拆分銷售額。Agent會給出每個渠道的分析結果，附帶圖表和原始SQL。

涉及數據查詢的回答，用戶可以查看相關查詢語句、指標與時間範圍，並結合計算口徑核查結果。保留查詢和知識來源，使分析過程更容易追溯。

接著追問："這個指標正常嗎？按部門拆解合理嗎？"Agent會調用企業上下文裡的標準流程和SOP，比如對訂單取消率做異常識別。異常判定規則與分析方法由MirrorMind作為企業上下文統一管理，MirrorPilot在任務中讀取相關知識、組織步驟，並調用MirrorData執行查詢。

若再追問一句："為什麼會飆升？" Agent按分析方法繼續檢查品類、品牌和商品，並檢索倉儲事件及庫存記錄。它把這些信息與門店取消率變化結合起來，提出可能原因、相關證據和建議動作，供業務人員進一步核查。

分析完成後，用戶可以繼續通過對話要求生成管理層報告。Agent將當前任務中的數據、圖表、業務資料與分析結論整理成可打開、可下載的HTML報告，供業務部門討論和核查。

演示視頻

回到開頭的三個問題

MirrorData讓檢索結果能夠繼續參與SQL關聯與分析；MirrorMind集中維護業務口徑與企業知識，讓多個Agent重用共同的定義和依據；MirrorPilot將數據、Context與分析方法組織成業務任務，交付可核查、可追溯的答案與報告。

三個問題落在同一個底座上，這個底座就是MIP.

本內容僅供參考，不構成任何金融、投資、法律或稅務建議。文中提及的任何活動、獎勵、線上活動或相關資訊，不應被視為對購買、出售或交易任何加密資產的推薦、招攬或邀請。加密資產具有高波動性，存在價值損失風險。WEEX服務、產品及相關活動的可用性可能因地區而異。用戶在參與前有責任確保符合當地適用法律法規。