從 AI 取數到智能分析：企業級數據 Agent 的多階段演進與工程化落地

作者 | 王新波，Shopee 技術專家

審核 | Kitty

策劃 | QCon 全球軟件開發大會

在大模型技術蓬勃發展的背景下，企業數據消費正從傳統的 BI 報表和自助式分析，邁向 AI 原生的 Agent 時代。然而，將學術界看似成熟的 Text-to-SQL 技術落地到復雜的 OLAP 場景中，其準確率可能從紙面上的 90% 驟降至 10%。

本文整理自 Shopee 技術專家王新波在 QCon 全球軟件開發大會 2026 北京站的分享《從 AI 取數到智能分析：企業級數據 Agent 的多階段演進與工程化落地》。王新波詳細復盤了過去兩年其所在團隊在打造企業級 Data Agent 過程中的實踐與反思。他系統性地揭示了從解決找表不準、語義錯誤到引入 Multi-Agent、語義模型與 Skill 機制的完整技術演進路徑，并分享了如何通過工程底座與運營閉環，將一個簡單的取數工具逐步雕琢為支持個性化與場景化智能分析的可靠生產力工具。

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

1 背景與挑戰：從 BI 演進到 AI 原生數據消費

數據消費的發展通常被劃分為四個階段。1.0 時代是傳統 BI 時代，以 SAP 等系統為代表，報表交付高度依賴 IT 團隊通過編寫 SQL 來實現。2.0 時代邁入了自助式 BI，Dashboard 成為主流。以我所在公司的數據平臺為例，Dashboard 的月活大約有兩萬多，但在這兩萬多用戶中，只有不到百分之十是數據的生產者，也就是報表的編輯者。這說明絕大部分人的數據消費，依然要指望著少數的 BI 同學進行手工操作。到了 3.0 的增強分析時代，開始引入 AI 作為輔助，但主要的分析流程依然由人驅動。而現在，我們正大踏步跨入 4.0 ——AI 原生 Agent 時代。在這個階段，數據消費者終于可以直接通過自然語言提交需求，Agent 則能夠自主完成從取數到智能分析的全過程。

我們團隊對 AI 取數的探索始于 2024 年。起初，我們對 Text-to-SQL 這條路信心滿滿，因為學術界當時的 Benchmark 數據非常亮眼。在 Spider 這類榜單上，一些 State-of-the-art 的解決方案準確率可以達到 85% 到 91%，這甚至已經接近了人類標注員的水平?；谶@份信息，我們設計了一個初代 Text-to-SQL 的 Demo 架構，不到一周就完成了搭建。當時的技術方案采用了典型的 RAG 鏈路：我們把平臺上近三十天內有訪問記錄的大約一百萬張表做了 Embedding 索引，用戶提問后，系統通過向量近似檢索召回相關的表，然后利用這些表的元數據構造 Prompt，交給大模型一步生成 SQL。

然而，這套方案上線后的效果非常差。我們構造了一個內部評測集來摸底，甚至還是簡化版本的評測集。但就在這個評測集上，找表的平均倒數排名僅能達到 56% 左右，而 Text-to-SQL 的執行準確率更是不到 40%。更令人沮喪的是，就連最基本的語法準確率也徘徊在百分之五六十。差不多同一時間，Spider 發布了 2.0 版本的 Benchmark，這個新版本號稱是基于企業真實 OLAP 場景構造的評測集。當時比較先進的商業化模型 GPT-4o，其裸模型在 Spider 2.0 上能達到的準確率只有百分之十左右。結合 Spider 2.0 的這個數據和我們的初版實踐，我們得出了一個殘酷的結論：企業級 OLAP 場景下的 Text-to-SQL，是一件極其困難的事情。

2 Text2SQL 技術演進之路

面對前期的技術難點，我們對初代 Demo 和種子用戶的負反饋進行了深入分析，歸納出了五大核心問題。第一是找表不準。數倉有著嚴格的分層，每一層之間和內部都存在大量結構相似、只有細微區別的表。對于 Embedding 模型來說，通過語義相似性檢索去區分這種微弱的差異是非常困難的，結果往往會召回看起來相關但實際上完全錯誤的表。第二是 SQL 語義錯誤。第一版架構僅僅使用了表元數據，嚴重缺失了業務規則和數據口徑，導致生成的 SQL 雖然能跑出結果，但計算邏輯和數據結論完全不對。第三是 SQL 語法錯誤。大模型經常會混用 MySQL、PostgreSQL 等專有語法，而我們的底層引擎是 Presto 或 StarRocks，這些不兼容的語法會導致 SQL 直接報錯。同時，模型幻覺也頻繁出現，比如編造出表中根本不存在的數據列，甚至引用其他表的列。第四是交互體驗差。系統里的找數、取數等功能入口各自獨立，用戶需要在不同模塊間來回切換，體驗感很差，系統響應時間也慢。第五是評測缺失。我們當初只構造了一個僅包含五十多條數據的極簡評測集，完全脫離了生產環境，即便把 Agent 調校到很高的分數，也不敢放心交給業務使用。

帶著這五大核心問題，我們開啟了 Text-to-SQL 的技術演進之路。這段路可以總結為五次關鍵的躍遷，每一次都由真實的生產痛點所驅動。第一次躍遷是從單鏈路 RAG 轉變為 Multi-Agent 加元數據漸進式披露的解決方案，主要解決找數和體驗割裂的問題。第二次躍遷引入了用戶畫像和持久化記憶，實現了從“千人一面”到個性化響應的跨越。第三次躍遷引入了語義建模，利用語義模型和輔助建模 Agent 來突破純大模型生成 SQL 的準確率天花板。第四次躍遷則是設計了一套包含文件系統上下文和 Sandbox 等工具的復雜 Agent 工程底座，用以支撐復雜分析和長時間穩定運行。第五次躍遷我們引入了 Skill 機制，使用戶能夠自定義多步驟的流程化分析主題，最終實現了從取數到場景化分析的轉變。

先來看第一次躍遷，其核心設計在于 Multi-Agent 架構。系統被分為兩層。上層是 Supervisor Agent，負責背景知識加載、意圖識別以及任務的拆解與編排，然后把具體任務交接給下層的專業子 Agent。下層是專業 Agent 層，包含了三個關鍵角色：Data Scope Clarity Agent 負責確認用戶問題歸屬的數據域；Data Discovery Agent 負責在已確認的數據域內精準找到相關的表；而生成 SQL 的 Agent 則基于已確認的表元數據和業務知識，完成最終的 SQL 生成。在這個過程中，我們加入了兩層 Human-in-loop 機制。在 Data Scope Clarity Agent 找到業務域后，會引入用戶確認環節；在 Data Discovery Agent 找到相似表后，同樣會引入用戶確認。只有用戶確認通過，Agent 才會進入下一步。這種兩層確認體系能夠確保 Agent 的推理過程不走偏。

另一個重點設計是元數據的漸進式披露。傳統的 RAG 系統習慣于一次性通過相似性檢索召回所有候選信息，但假設召回了十幾張表，每張表又有上百個字段，如果把這些表描述、Schema 和列描述全部塞進上下文，真正有價值的信息可能只占其中一到三張表，這會造成極大的上下文浪費和嚴重的上下文腐化問題。

針對這點，我們引入了三層元數據披露邏輯。第一層是業務域定位，基于意圖識別和公司已有的業務域基礎元數據，直接在百萬級表中定位出用戶問題所命中的數據域，將范圍從百萬級縮小到域內的數百張表。第二層是域內表發現，基于語義檢索、熱度排名，結合表的語義規則，從數百張表中進一步挑選出候選表并交由用戶確認。只有當用戶確認后，我們才會來到第三層：深度知識展開，即加載這些候選表的完整 Schema、字段和關聯業務規則。比如，當用戶提問“東南亞地區昨天的 GMV 是多少”，系統會在 L1 階段定位到“Marketplace Order”業務域，接著在表發現階段鎖定訂單明細表和每日 GMV 增量表等一到三張表，用戶確認后，這些表的完整信息才被加載。這一機制讓上下文窗口既可控又精準。

找到了正確的表之后，流程進入 SQL 生成階段。整個生成 Workflow 被我們拆分為四個步驟。當系統拿到用戶問題和候選表上下文后，第一步會引入歧義和缺失檢測。例如，如果候選表中包含多個與 GMV 相關的指標，系統會通過 Human-in-loop 方式讓用戶確認具體的計算口徑，消除歧義后再進入下一步。第二步是多路并行生成候選 SQL。我們會同時啟動三條生成路徑：第一條是自校正模式，模型生成后會進行反思并自我修正，然后交出候選 SQL；第二條是任務分治模式，將問題拆解成子任務，分別生成結果后再合成為候選 SQL；第三條是簡單直接生成模式。這三條路徑產生的候選 SQL 會進入第三步選優環節，由 Agent 從中挑選出最優的一個，然后進入第四步驗證和修復。在這一步，我們會先用 SQL 編譯器驗證語法錯誤，如果發現錯誤，則開啟一個修復與再驗證的閉環，由大模型結合我們植入的專用語法知識來提升修復效果，最終交出可執行的 SQL。

為了支撐高質量生成，我們將相關的上下文信息分為四層。第一層是最基礎的 Hive 表元數據，包括表名、表描述、字段名、字段描述等信息。第二層是業務域知識文檔，我們內部稱之為 Mart，這里包含了倉庫建模介紹、數據使用幫助文檔及 FAQ 等，我們對其做了語義壓縮和結構化提取。第三層是 Topic 運營知識，這允許 BI 同學補充業務口徑、業務術語，并將其與少量的專有表或語義模型綁定，從而在根源上規避找表階段的不確定性。第四層是技術類元數據，包含三類信息：一是高質量 SQL 硬樣例，這是我們從線上日志中基于打分機制篩選出來的；二是表的一些 Sample Data；三是表的統計數據，這部分主要來源于 Metastore 中的 Hive Statistics 數據，比如行數和列分布情況，以及我們通過枚舉值挖掘鏈路識別出的離散列可能取值，這些知識在生成 SQL 時能有效幫助大模型寫對查詢條件。

引入 Multi-Agent 后，效果和體驗的割裂問題有了很大改觀，但我們很快遇到了新的痛點：AI 的回答千篇一律。比如，同樣是問“GMV 為什么下跌”，新加坡運營的同學關心的是他負責的特定市場訂單表，而全球財務的同學則關注全局財務匯總的 GMV 數據。為了解決這個問題，我們進入了第二次躍遷，引入了雙層個性化體系。

第一層是用戶畫像，我們從權限平臺等系統拉取用戶的組織架構、角色、所屬區域、數據權限等靜態數據，在對話開始前就將其加載到上下文中，這樣 Agent 在開口前就已經“認識”了用戶。如果線上詢問的是新加坡的運營同學，Agent 就會傾向于推薦新加坡市場相關的數據表，并在生成 SQL 的查詢條件里自動加上 region = ‘SG’。第二層是用戶記憶，我們實現了跨 Session 的持久化偏好記憶。用戶在平臺上的交互行為，比如點贊、點踩、經常搜索的表、曾經做過的口徑確認、配置的數據映射等，都會被持久化存儲。在用戶發起新一輪對話時，系統會基于相似性規則，將相關的歷史記憶加載到上下文中，實現 Agent“越用越懂你”的效果。

有了個性化能力和多路生成的 SQL 框架，我們依然發現，純靠大模型生成 SQL 的準確率很難突破預期的天花板。我們分析總結了三重挑戰。第一重是業務語義理解，比如要生成正確的 SQL，系統需要推斷出 GMV 的口徑、活躍用戶的定義，但在缺失業務規則的文本上下文里，這種多步加工過程中的幻覺會不斷累加，導致語義類錯誤頻發。第二重是表關聯推理，OLAP 場景下的數據加工往往需要復雜的多表 Join，其關聯鏈路又因數倉層級的復雜性而極難推導。第三重是 SQL 的物理實現，比如分區的選擇、數據表查詢分區范圍的確定，以及各種函數語法的混用，這些直接導致了很高的語法錯誤率。這三層復雜度的疊加，是純大模型方案難以提升的核心原因。

對此，我們的第三次躍遷是引入語義模型，作為一個數據抽象層，它充當大模型與底層物理數據之間的橋梁。我們做了三件事：一是將業務數據映射到物理表字段和計算邏輯上；二是預定義好標準指標、維度和過濾條件，使得大模型不再需要從零開始推理業務邏輯；三是讓語義模型封裝技術的復雜性，對外呈現得像一張統一的寬表或 Cube，封裝了底層的 Join 關系和過濾條件。大模型看到的將是業務概念而非原始的物理表，這顯著降低了其生成任務的難度，直接帶動了整體準確率的提升。例如，計算“昨天新加坡區域的 GMV”，在純 Text-to-SQL 模式下，系統需要推斷統計口徑、定位物理表和字段、綁定過濾條件、確定聚合維度，任何一步出錯結果就不對。而基于語義模型，系統只需要生成一個極其簡單的 DSL，描述清楚統計指標、時間范圍和區域，剩下的 DSL 到 SQL 映射就不再依賴大模型生成，而是由語義引擎以工程化的、確定性的方式翻譯為可執行的 SQL。

有了語義模型之后，我們就面臨了一個工程決策：后續所有查詢生成是否都要交給 Text-to-DSL 來處理？我們最終選擇了混合 Workflow 的方式。用戶問題提交后，會先經過一個意圖識別與復雜度評估環節。這個環節分為兩個維度：我們可以讓大模型自主評估，用戶也可以配置策略進行自路由，例如將個人的 Topic 數據域設置為一直走語義模型或一直走 Text-to-SQL。如果交給 Agent 評估，Agent 會基于問題的復雜度來做路由選擇。如果問題簡單且偏探索性，就走傳統的 Text-to-SQL 鏈路；如果問題涉及復雜的計算邏輯且有可用的語義模型，就走 Text-to-DSL 鏈路。兩條鏈路最終都會生成物理可執行 SQL，交付給后續的取數、可視化和分析。

語義模型雖然能提升準確率，但其構建過程本身非常復雜。傳統方式是由數據專家人工構建，周期長且費力。為了縮短這個工作量，我們設計了輔助語義建模 Agent，目前還處于 Beta 階段。它的輸入包含三類元數據：第一類是表結構、字段描述和數倉層級等基礎元數據；第二類是已經在線上運行的 SQL，以供 Agent 學習查詢模式、字段常見的計算邏輯、指標與過濾條件的綁定關系等；第三類是公司現有報表平臺上已配置的數據集和看板，從這些定義中學習維度與指標配置，從數據集中學習指標的計算口徑。拿到這些信息后，語義建模 Agent 基于用戶的建模意圖執行四項操作：指標推薦、維度識別、關鍵路徑發現、數據關系識別與映射填充。它生成的結果是一份語義模型的草案，這份草案并不會直接上線，而是需要交由啟動建模的數據專家進行審核、修改和確認，確保沒有質量問題后才會上線，用以支撐 Text-to-DSL 鏈路。這個思路的核心是，通過輔助工具降低復雜度，但最終的數據質量交由專家把關。

語義模型上線也并不意味著終點。我們在生產環境中認識到，打造一個完美的 Agent 或語義模型從來不是一蹴而就的，它更像一個需要不斷帶教、輔助優化的實習員工。為此，我們建立了一個“四步循環”來持續優化語義模型。第一步是 AI 輔助建模，快速產出草稿。第二步是語義驅動查詢，模型上線，執行 Text-to-DSL 查詢，但會打上 Beta 版本的標簽。第三步，線上用戶對 Agent 輸出結果的反饋信息，會被回流給數據專家，由專家進行 Review 和審核，從中發現語義模型的缺陷并進行優化。第四步，優化后的語義模型重新上線。這樣就形成了一個“建模、查詢、驗證、優化”的反饋閉環，保證語義模型在線上能夠持續正向迭代。

3 Data Agent 工程體系

AI 取數的準確性問題得到階段性解決后，另外一個核心挑戰浮現了出來：如何保證 Agent 在線上能夠 24 小時穩定運行，并擁有完整的評測和運營閉環？我們的工程體系全貌可以被劃分為技術體系、評測體系和運營體系三大部分。技術體系內部又細分為六大塊：知識管理、文件系統上下文、隔離環境、Agent 工具箱、Agent Skill 以及個性化能力。我挑選其中兩個最關鍵的技術點展開。

第一個是文件系統上下文。在 Data Agent 場景下，模型上下文比一般的聊天 Agent 要復雜得多，它涉及表的基礎元數據、Schema、語義規則、個性化數據、語義建模知識等。如果一股腦地把所有信息都塞進上下文窗口，不僅很容易撐爆窗口，還會觸發嚴重的上下文腐化問題。我們的做法是引入一個虛擬的文件系統，其后端存儲可以是 MySQL 或分布式文件系統。我們把各類知識按層級結構組織起來，這和元數據的漸進式披露相輔相成。在對話開始時，只加載最上層的元數據，如用戶畫像；在確定數據域時，加載 L1 層的業務域知識；只有當用戶確認了具體的表之后，我們才展開最詳細的信息和語義規則。而那些在當前階段不再需要的信息，則會被擇機從上下文窗口中卸載下來。此外，文件系統上下文另一個重要作用是緩存多步分析產生的中間結果。比如在一個歸因分析任務中，第一步取出的數據集，后續的每一步分析都依賴于它。如果把這個龐大的數據集一直放在模型上下文里，窗口會被嚴重占用。我們的做法是將取到的數據以標準化 DataFrame 的方式存儲到文件系統中，模型上下文中只保留一個 Reference 或數據路徑。當后續步驟需要使用工具時，直接傳遞這個 Reference 即可，而不必在上下文里流轉一個超大的數據集。

第二個重點是隔離環境，也就是 Sandbox。我們給每個 Session 中運行的 Agent 都提供了一個權限隔離和資源隔離的沙箱環境，以此保證運行的安全與可控。我們提供的一些關鍵工具，比如批處理執行和 Python 代碼執行，全都在這個沙箱環境中完成，從而有效防止惡意 Prompt 利用工具進行破壞性操作。

接下來的評測體系同樣至關重要。它包含評測集建設、評估執行、結果評分三部分。在評測集建設上，我們踩了不少坑。最早一版的評測集由 QA 團隊幫忙生成，只有五六十條數據，嚴重脫離真實的業務場景，我們根本無法依據它得出的數據去優化一個面向生產的 Agent。后來我們轉變思路，決定基于線上真實使用的 SQL 來構造評測集。我們面向特定的分析主題或重點優化領域進行表的選擇，搜索線上被執行成功且執行頻繁的 SQL，以及源自成熟穩定報表平臺的 SQL，然后讓大模型依據這些 SQL“反向生成”出對應的自然語言問題。生成的問題全部交由人工 Review，審核通過后才積攢到評測集中。最終，我們積累了一個包含數千條數據的評測集，它面向不同的分析主題和難度級別，成為我們的離線評測基準。

在結果比較方面，我們也做了很多探索。我們最先嘗試了通過 AST 抽象語法樹來比較兩個 SQL 是否一致，但很快發現，相同的語義邏輯可以有多種多樣的表達方式，它們對應著完全不同的語法樹，這種比較方法效果很差。然后我們選擇了基于大模型的準確性比較，這在簡單場景下效果不錯，但在復雜場景中，由于存在多種等價的寫法，大模型評估的分數并不理想。我們通過人工比較和模型評估的交叉驗證，確認了這個現象。最終，我們決定以執行準確性比較作為主要的評估手段。為了解決執行結果比較中的一些問題，比如 AI 生成的 SQL 可能帶有臨時別名，或者時間列的格式靈活多變，我們對時間字段做了歸一化處理，并基于類似編輯距離的算法來計算列名的一致性；針對浮點數或經過類型轉換的數據，我們設計了基于殘差和容差的數據比較策略。我們把這一整套結果比較邏輯做成了一個工具，集成在評估 Pipeline 中?，F在，平臺上的知識庫、Agent、模型的任何改動，都可以方便地觸發離線評估鏈路，來對比改動前后的效果變化。

在介紹運營體系之前，我想插入一段關于元數據治理的實踐，因為它對整體效果的影響非常關鍵。我們在開始做 Text-to-SQL 的時候就發現，平臺上有大量的 Hive 表完全沒有表描述和列描述。大模型在只有干巴巴的表名的情況下，幾乎不可能找到符合用戶需求或語義正確的表。所以我們同步啟動了一個元數據治理流程。平臺上有百萬級別張表，靠人工去治理是不可想象的，因此我們設計了一個 AI 與人工協同的四步治理流程。

第一步，我們按照業務過程和數倉的層級，對一些表進行分組。例如，將相同業務語義的表，或是按 Region 拆分的表，都放到同一組內。這些同組的表共享相似的業務語義。第二步，以表組為基本單位，交給 AI 生成描述。它依賴的信息不僅是平臺上的名字、字段，更大量地依賴了業務域建模的相關知識、用戶幫助文檔和 FAQ，從而生成候選的表描述和列描述。第三步，這些候選描述不能直接上線，而是必須交給業務方的負責人或表的 Owner 進行逐條的人工 Review。他們可以選擇采納、修改或補充描述，只有經過人工審核的描述，才能正式生效。第四步是血緣擴散，我們把已經治理好的核心表，通過血緣關系將其描述和計算邏輯自動擴散到它的下游表，自動為下游也生成描述。當然，擴散出來的描述同樣也需要業務方 Review、修改和確認。

治理前后的效果改善非常顯著：AI 生成的語義描述直接被業務方采納、無需任何修改的比例高達 70%，這證明了方案有明顯的正向收益；對于中等規模的 OLAP 表，治理時間從原來的三十分鐘縮小到了十分鐘左右，節省了 67% 的時間；我們通過人工方式只治理了兩千張核心表，但通過血緣機制，描述的擴散與治理最終覆蓋了十五萬張以上的表；在找表階段，準確度在治理前后最高提升了 15 個百分點。這充分說明，元數據的質量和豐富程度，對找表階段的 Agent 幫助巨大。做 Data Agent 不能只盯著模型和工程架構，數據質量這塊臟活、累活，也必須下苦功夫去做。

接下來就是我們的運營閉環。我們很早就發現了一個事實：線下的評測效果，絕不等于線上實際運行的效果。線下評測集即使基于線上數據構建，但隨著 Agent 的迭代，分數總會越來越高，而線上用戶問題千變萬化，評測集的概括性會越來越跟不上。

我們的運營閉環做了三步。第一步，基于線上反饋采集和人工標注，構建線上準確率的評估系統。線上反饋采集既包含用戶拷貝執行生成的 SQL、追問、糾正等隱式反饋，也包含點贊、點踩等顯式反饋，還有數據團隊同學在后臺對結果的人工標注。這三者結合，提升了線上準確率計算的效率并收口了其準確性。第二步，是知識管理和 Topic 運營。Topic 相當于一個私域的業務域概念。BI 同學或者有數據分析需求的同學，可以把自己經常使用的表放到一個獨立的 Topic 里，形成一個面向自己的私域數據組，完全繞開繁瑣的找表過程。同時，通過語義建模構建的模型也可以綁定到 Topic 上，讓該 Topic 下的所有數據查詢都走語義模型，避免 Text-to-SQL 帶來的隨機性干擾。第三步，是效果驗證和數據回流。我們做了后臺工具和 Test Session 功能，運營同學可以快速驗證他們在 Topic 中補充的業務知識或規則效果如何，效果好了就上線。所有的上線效果都有看板和監控。最后，所有的標注數據和用戶記憶，都會被回流到算法平臺，算法同學正在利用這些數據幫我們訓練一個基于自有數據的自有模型。

4 基于 Skill 的場景化分析支持

前面的工作解決了“運行穩不穩”和“取數準不準”的問題，而接下來要探討的第四部分，是如何基于 Skill 能力，讓 Data Agent 支持可定制的場景化分析。這是我們將其從一個取數工具，進化為能夠支持復雜分析場景的關鍵一步。我們最早嘗試的是讓 Agent 做自由歸因或自由探索分析，但結果暴露了很大的問題。Agent 經常會繞過關鍵維度的下鉆和交叉分析，直接給出一個結論。在某些情況下這個結論可能正確，但在更多情況下，它是不對的。我們去咨詢了專業的 BI 同學，得到的反饋是：無論結論對錯，他們都“不敢用”。因為分析過程是個黑箱，他們不知道數據是怎么一步步得來的，結論完全無法驗證。這讓分析的商業價值大打折扣。為了保證分析過程的可信與可靠，我們引入了 Skill 機制，在模型的自主分析和可定制的流程化分析之間尋找一個平衡點。這里的 Skill 實現，遵從的是 Anthropic 的 Agent Skill 規范。但在我們的 Data Agent 語境下，Skill 指的是由數據分析師定義的、多步驟的、復雜的數據分析流程。

以歸因分析為例，一個典型的歸因 Skill 可以包含一個五步流程。第一步是指標下鉆，通過 SQL 拉取時間序列數據，觀察指標趨勢。第二步是按國家、品類、渠道等可用維度進行拆解。第三步是依據維度拆解，進行計算和分析貢獻度排名，并執行一些交叉分析邏輯。第四步是找到根因，按影響因子排序定位出根本原因。第五步是生成結構化的分析報告。

看一個具體的 Skill 執行流程示例：當用戶提問“幫我分析上周 GMV 下跌的原因”，Agent 首先識別意圖，并將其與上下文中一個相關的 Skill 描述進行匹配。匹配成功后，該 Skill 的完整 Markdown 定義會被全部加載到上下文中，Agent 就會嚴格按照這個定義好的流程去一步步執行。每一步執行都會輸出中間結論和結果。這種機制實現了中間步驟可追溯、異?？苫貧w、流程不可跳過、結果可驗證，從而極大地提升了分析結論的可信性。這里的 Skill 機制和我們前面提到的工程底座——Sandbox 和文件系統上下文——是相輔相成的。多步分析中產生的大量中間結果數據，并不會存放在模型上下文里，而是存放在文件系統中，模型只需要記住其 Reference 或路徑即可。如果下一步需要用 Python 執行分析，就加載那個路徑的數據；如果是大模型去做下一步的推理，就按需加載一小部分采樣數據到上下文，防止整體數據流轉導致上下文撐爆。

總結來看，這種基于 Skill 的分析方式為 Data Agent 帶來了三大價值：一是可復用。一次定義，全員觸發。它能把資深分析師腦中成熟的標準分析流程，變成平臺級資產供所有人共享。二是可信賴。固定的流程保證了論證的嚴謹性，管理者或應用方可以看到一步一步的計算過程，從而驗證最終結果的準確性。三是可擴展。我們提供了 Skill Builder 和 Skill Runner，用戶可以自定義他們想要的任何分析 Skills，通過上傳文件或在平臺上直接創建，就像使用 Claude Code 的 Skill Creator 一樣。

5 總結與展望

回顧我們整個 Data Agent 從 AI 取數工具到面向分析場景的全過程，我們通過 Multi-Agent、個性化與語義模型提升了準確性，通過包含 Sandbox 和文件系統上下文的工程底座來支持多步驟、長時間穩定運行，并最終引入 Skill 機制，使分析師和 BI 團隊能夠定制和沉淀分析流程到平臺上。

放眼未來，我有幾個關于趨勢的判斷。第一是關于 Agent Harness 的演進。Harness 就像是 Agent 的操作系統。如果 Agent 等于大模型加 Harness，那么 Agent 減去大模型，剩下的所有東西都屬于 Harness。我們之前做的很多 Agent 工程工作，都屬于 Harness 的范疇。但我們需要思考，這是否是“舊瓶裝新酒”？答案既是，也不是?！笆恰钡牟糠衷谟冢覀冏龅闹T如調優 Prompt、優化工具調用邏輯等工作，隨著模型自身能力的進化，其帶來的邊際效益正在逐步降低。但“不是”的部分在于，另一些工作，比如狀態管理、上下文管理，以及從個性化到通用化的轉變，這些無論模型如何進化都必須去做。以前我們給大模型做工具是逐項添加，比如給它一個加法工具、一個減法工具放到上下文里，未來工具應該是通用化的場景。比如，給它“一臺電腦”、一個可操作和接收反饋的環境作為通用工具，它通過標準化的接口就能自由排列組合去解決任務。這一點，從 Anthropic 從 4.5 到 4.6 的新模型中已經能明顯看到這種能力的顯現。

第二是 Agent First 的理念，未來的數據平臺應該是為了 Agent 而設計的，而不是把 Agent 當作平臺上的一個附加工具。Agent 將會成為人與數據交互的新界面。

第三是從 AI 工具到 AI 員工的轉變。1.0 時代的 SQL 取數助手是一個工具；2.0 時代它變得更像一個支持分析的助手；而在 3.0 時代，就像我們看到的一些產品形態，Agent 正在向一種“數字勞動力”演進。其關鍵點是 Schedule Channel 和 Agent Skills 的自我生成與進化能力，最終讓 Agent 能夠獨立地接收任務、自我演進、自我修復和自主學習。

第四是 Agent 治理。Agent 究竟聰不聰明、效果好不好，都需要伴隨可追溯性、可控性和可持續的評估能力。這是讓我們敢在生產環境下大規模落地 Agent 的先決條件。

作者介紹

王新波，Shopee 技術專家，深耕大數據引擎及平臺領域多年。曾先后就職于阿里巴巴、快手、滴滴等公司，在 SQL 引擎開發、數據中臺建設、數據治理等方向積累了豐富的技術經驗與業務洞察。現專注于 Shopee 數據 Agent 的研發與探索，主導了智能取數、智能洞察、業務場景化分析等多個 AI 應用的設計與落地，致力于借助 Agent 技術重塑數據交互方式，讓業務人員能夠通過自然語言便捷地獲取和理解數據，降低數據使用門檻，釋放數據驅動決策的價值。

會議推薦

大會限時早鳥票享 8 折專屬優惠，現在報名立減 1160，更多詳情可掃碼或聯系票務經理 13269078023 進行咨詢。