嘉賓 | 王騰飛

編輯 | 李忠良

過去兩年，整個行業對大模型、Agent 的討論從未降溫。從基礎模型能力的快速迭代，到 Agent 框架的百花齊放，似乎每一個技術熱點都在告訴我們：AI 的規模化落地就在眼前。

但當企業真正開始推進 AI 項目時，很多人很快發現了一個尷尬的現實：Demo 永遠驚艷，生產總是難產。這不是模型的問題，也不是 Prompt 的問題——真正決定一個 AI 項目能不能從"跑通"走向"跑穩"的，是背后那套看不見的基礎設施：它能否接住多模態數據的爆炸式增長？能否支撐從訓練到推理再到反饋的完整閉環？能否讓 Agent 真正找到并用好企業沉淀的數據資產？

傳統大數據平臺為什么開始顯得不夠用了？面向 Agent 時代，新一代 AI 基礎設施到底需要重建哪些能力？在火山引擎 FORCE 大會上，火山引擎數智平臺產品總監 王彥輝給出了他的判斷：“企業級 Agent 的落地，正在推動數據平臺迎來一場深刻的變革——服務對象，正在從人變成 Agent。”他在會上系統闡述了 Agent DataLake 方案，試圖回答一個核心問題：如何讓企業數據真正流向智能體，從而轉化為可感知的業務價值。帶著同樣的問題，我們與王彥輝及火山引擎數智平臺技術總監丁遠普展開了一次深度對話，從數據形態、計算范式到產品化路徑，試圖把答案挖得更深、看得更遠。

值得一提的是，王彥輝將在 6 月 26 日至 27 日的 AICon 全球人工智能開發與應用大會上，出品了《AI 原生數據工程》專題論壇，圍繞"數據如何定義模型能力"這一核心命題，系統拆解從訓練到推理、從生產到反饋的全鏈路數據閉環。如果你對本文話題有更深的興趣，那場論壇值得關注。

從輕質油到重油：AI 時代的數據底座正在經歷一場結構性變革

InfoQ：如果把視角從 Agent 稍微拉開，放到更廣義的 AI 落地上看，您接觸的真實客戶里，最常見的基礎設施短板是什么？哪些問題表面上看是模型效果問題，背后其實是數據底座、數據治理或工程體系的問題？

丁遠普：總體來看，主要存在兩類問題。

第一類是數據夠不著的問題。很多企業的內部數據散落在各個系統中，在用 AI 或 Agent 接入時難以整合。數據不完整，整體效果自然會大打折扣。這本質上是數據打通與治理的問題，而非模型本身的局限。

第二類是模型用不好的問題。基礎模型本身能力很強、迭代也很快，但它是高度泛化的模型，可以類比為 CPU、GPU 這樣的通用計算能力——模型提供的 Token，可以視為第三種算力。

舉兩個典型例子：

• PDF 處理場景：如果業務人員直接用通用模型處理 PDF，效果大概率不佳。通用模型不會針對 PDF 進行專項優化和適配，而 PDF 版面復雜、多欄、圖文混排，缺乏專項處理效果自然差。此外，PDF 處理本身是一條很長的鏈路，前后都需要專業的數據處理環節。綜合來看，直接用通用模型做 PDF 解析，效果會相當有限。
  

• 視頻剪輯場景：基礎模型直接用同樣困難。視頻有幀結構、動畫、多鏡頭銜接等復雜特性，僅憑一段提示詞，模型很難精準理解意圖并完成視頻處理需求。和 PDF 類似，視頻處理也需要完整的前置和后置鏈路，才能達到理想效果。

綜合來說，AI 落地并非簡單選一個模型進行一次調用就能完成，而是一個數據 + 算法 + 工程的系統性問題。模型可以視為發動機或大腦，其他的則是底盤、變速箱、油路，綜合起來構成一套完整的數據底座體系。

王彥輝：補充一點：業務聯系不夠緊。當前模型與客戶實際業務落地之間的結合點還相對較遠。企業在將 AI 與業務結合時，不同業務場景的優先級、重要性各有差異。

目前存在一個關鍵問題：客戶現有的數據基建是圍繞"給人使用"來構建的，而面向 AI Agent 的數據基建與此差異較大。這導致各個層面的口徑不一致，真正落地到業務時，往往會出現較大的效果偏差。

InfoQ：從技術底層看，AI 時代的基礎設施與傳統大數據基礎設施，最大的 gap 到底在哪里？如果企業還沿用過去的架構思路，到了多模態數據、模型訓練/推理、實時反饋這些場景，最容易在哪些地方暴露出根本性不適配？

丁遠普：傳統大數據技術更多是圍繞結構化數據構建的，雖然也涉及半結構化、非結構化數據，但占比很少，企業真正落地的仍以結構化數據為主。

進入 AI 時代，最大的變化體現在以下三個方面：

第一，數據形態變了。結構化數據的特點是 schema 明確、行列清晰。而在 AI 時代，圖片、音頻、音視頻、長文本、3D 模型等多模態非結構化數據大量涌現，沒有明確的 schema，且在企業中占比極高。傳統加工方式面對非結構化數據，基本面臨三大困境：看不見、管不了、算不動。例如，很難將一個視頻存入 Hive 表（即使通過 URL 方式存儲，也極為生硬），也無法通過 SQL 進行語義查詢，比如查詢視頻畫面中的內容。

第二，計算模式變了。傳統大數據的算力以 CPU 為主，現在已演進為 CPU + GPU + Token 的混合算力模式，且 Token 算力的占比越來越大。尤其是多模態數據的處理，如音視頻的理解與生成，都依賴大模型的 Token 算力。沿用傳統架構，實際上無法有效處理這些多模態數據，或者效率極為低下。

第三，數據管理的維度大幅擴展。以前的數據管理相對簡單，無非是庫表、字段、分區，能夠抽象出一套清晰的元數據管理范式。但現在由于數據形態的變化，整個數據管理的復雜度大幅提升：多模態數據如何管理？數據來源是什么？當前狀態如何？質量評分怎么衡量？對應的模型版本是什么？數據血緣關系怎么追蹤？這些維度的復雜程度遠超傳統大數據時代。

綜上，傳統基礎設施已難以承載 AI 場景的需求，整體架構升級勢在必行。

王彥輝：這里用一個形象的類比來補充。過去我們常把數據比作石油，對比一下過去和現在的使用方式，差異就很直觀了。

以前的應用形態，如面向人的 BI 報表和推薦系統，更像是需要輕質油——汽油、柴油這類。過去的數據基礎設施正是圍繞這些處理方式和應用對接需求構建的。

而現在，我們需要大量處理非結構化數據，它的價值密度較低，更像是重油。重油的提純方式、處理方式以及面向應用的對接方式，都發生了很大變化。這也正是丁遠普提到的幾點變化：數據形態改變了，計算模式從 CPU 轉向 GPU，再到現在通過模型處理 Token，由此產生了多模態數據湖的算子能力。

在數據管理層面也有新的演進：以前管理的重點，一是建立清晰的口徑，二是做好成本治理。現在進入了第三個階段——讓 Agent 能夠發揮自身價值，與業務深度結合，并能主動找到合適的數據。

總體來看，原來是一條以輕質油為核心的生產、消費、加工產業鏈，現在既需要輕質油，也需要重油，整個產業鏈發生了根本性的變革。

InfoQ：如果從"服務模型"和"服務 Agent / 應用"兩個視角分別來看，企業對 AI 基礎設施的訴求有哪些共性，又有哪些差異？（追問：多模態數據湖為什么被視為適合 AI 時代的數據底座？）

丁遠普：共性方面，兩個視角共同需要三點：多模態數據的統一存儲與管理、異構的彈性算力（尤其是 Token 算力，我們認為 CPU 和 GPU 已屬于上一代算力形態），以及多模態的數據質量保障。

差異方面，兩個視角各有側重。服務模型（如基礎模型預訓練）的場景，數據量極大，且以批次形式到來，可能每半個月或一個月到達一次。每次數據到達后時間窗口很緊，需要在短時間內完成大量數據的清洗、處理和標注，為模型訓練做好準備。服務 Agent 的場景則不同，對數據量級的要求相對較低，基礎設施的訴求更偏向輕量化和靈活性，關注的是如何以更少的資源、內存和計算開銷來運行，而非承接大規模數據處理型的工作流。

從客戶需求來看，兩者同樣有明顯區別。服務模型的基建主要面向 AI 團隊或算法團隊，核心任務是數據準備；而服務 Agent 的基建，通常面向業務團隊。業務團隊不關心底層基建細節，更希望 Agent 好用、易用、可靠——不要頻繁出問題、不要產生幻覺、不要丟失上下文記憶。

關于多模態數據湖為什么是 AI 時代的數據底座，以 LAS 為核心的多模態數據湖產品體現在三個核心能力上。

第一，提供多模態數據的存儲與管理能力。我們在產品中引入了 Lance 數據格式，在國內這一方向上積累深厚。Lance 格式能為 AI 場景提供良好的大 Blob 數據存儲，支持零成本動態加列和高性能隨機訪問——這對 AI 場景非常友好，因為業務方隨時可能需要新增字段，而無需預先定義。

第二，提供以 Token 為新型算力的算子能力，涵蓋 PDF 解析、視頻編輯、爆款剪輯等多種模態數據的處理能力。

第三，在算子之上構建了面向業務的應用層。算子本身是較為通用和原子化的能力，但實際面向客戶時，很多業務人員并不擅長調用 API，因此我們在算子之上封裝了面向行業和垂直領域的應用層，如電商場景的視頻編輯、傳媒與文娛領域的多種應用，業務人員可以直接使用，無需具備技術背景。這三個層次，構成了我們認為適配 AI 時代的數據底座。

王彥輝：從服務模型和服務 Agent 這兩個維度來補充，我認為這代表了兩個不同階段：一個是面向訓練環節，從模型側來看；另一個是面向推理環節——推理早期是純對話模式，現在進入 Agent 時代，Agent 需要調用各種工具，包括數據類工具和 Sandbox。

我們認為在 Agent 時代，Harness 非常關鍵。Harness 的核心構成包括 Sandbox 以及數據——數據是定制化的源頭，是個性化能力發揮的重要起點。用戶的對話、session 和記憶，是模型后續不斷迭代、提煉個人價值與用戶畫像的重要基礎。此外，多模態數據湖涵蓋湖管理、湖計算、湖存儲、湖分析和湖檢索幾個方向，共同構成了 AI 大時代下數據基礎的完整體系。

別堆樂高，也別照搬大廠——底座升級有一個度的把握

InfoQ：假設一家企業已經意識到原有平臺能力不夠用了，準備升級底座。從技術架構角度看，一套面向 AI 時代的基礎設施至少要滿足哪些硬性條件？這些條件里，哪一條最難補，為什么？

丁遠普：硬性條件的思路與前面提到的一脈相承，核心涵蓋三塊：多模態數據的統一存儲與管理能力、異構彈性算力（尤其是 Token 算力），以及多模態數據質量保障。其中最難補的是中間這一條，也就是以 Token 為新型算力的算子能力。原因在于，這不是簡單采購硬件或搭建存儲就能解決的問題，需要對模型有很深的理解，還要結合具體業務場景進行封裝和優化，是一項系統性工程。

王彥輝：除了遠普剛才提到的資源和管控能力之外，上面的平臺能力和生態能力建設要是非常重要的，尤其生態鏈接的能力。平臺能力包括幾個方面：

• 第一，能統一管理結構化、非結構化、實時流、日志、文檔等多模態數據的數據資產管理能力

• 第二，業務語義的定義，業務是為人服務的，所以要有清晰的語義層和元數據體系，讓模型理解數據含義、指標口徑、質量和權限邊界

• 第三，要支持實時數據處理和反饋閉環，讓 AI 不只是回答問題，而能持續優化決策，也就是 AI 可觀測和評測能力的建設

• 第四，要具備安全、合規、審計和權限控制能力，確保 AI 在企業環境中可控使用

AI 生態，特別是數據生態差異比較大，但值得重點關注的是要結合企業數據平臺建設的階段和沉淀以及業務發展階段因地制宜的考慮。

InfoQ：今天我們已經看到很多和 AI 相關的場景，不只是"讀知識"，而是多模態數據的寫入和檢索同時發生。比如訓練數據持續沉淀、線上反饋實時回流、圖文音視頻混合處理。在這種 case 下，存儲引擎和數據系統會遇到哪些新挑戰？業界目前有哪些典型解法？

丁遠普：坦率地說，我們在實際客戶場景中遇到寫入和檢索同時高并發發生的情況相對較少，但可以從我們的技術實踐角度談一些相關思考。

在檢索與寫入層面，以 LAS 為核心的存儲格式能夠對多模態數據進行統一處理——無論是標量數據的寫入、向量的存儲，還是全文檢索，都可以在同一套體系中支撐。LAS 之所以被稱為"多模態"，也正體現于此：除了能夠存儲大字段，還可以將音視頻、圖片乃至點云數據向量化后存入 LAS 格式，從而支持混合檢索。

在檢索與寫入層面，以 Lance 為核心的存儲格式能夠對多模態數據進行統一處理——Lance 格式不僅能夠存儲標量數據，還可直接存儲音視頻、圖片乃至點云等多模態非結構化數據，支持將這些數據向量化后與原始數據一同存入；同時它具備成熟的全文檢索能力，可實現向量、全文與標量的混合檢索。

我們觀察到較多的實際需求，是如何在一套極簡的數據架構下，同時承載多種查詢檢索的工作負載。例如，將標量數據和向量數據統一存入 Lance，查詢時既可以通過 Lance 自身提供的查詢模式訪問，也可以通過 ByteHouse 這樣的分層數據庫來查詢，同時支持標量查詢、向量查詢和全文檢索。

InfoQ：從企業決策者視角看，當大家意識到底座要升級時，最容易走偏的路徑是什么？是繼續用開源組件拼裝，還是直接追求一體化方案？您觀察到的典型誤判，更多發生在技術選型、建設節奏，還是對業務目標的理解上？

丁遠普：最容易走偏的典型路徑，是"堆樂高"式的思維——簡單羅列和拼湊技術棧。比如原本用傳統格式存儲數據、用 Hive 做數據處理，需要向量能力時再引入一個向量數據庫，越堆越多。底層技術架構越復雜，所需消耗的運維人力也就越多。這種簡單疊加的思路，很容易偏離正確方向。我們更期望的是，能夠站在當前 AI 的實際訴求上，重新審視底層架構應該如何變革，而不是進行簡單的技術拼接。

另一個容易走偏的點是盲目對標：很多企業看到外部頭部公司搭建了大型數據平臺，便照搬規劃一套同等體量的平臺，但這類方案在實際落地中往往很難推進。

王彥輝：第一，要結合自身實際情況，因地制宜。不同企業在數據化能力、基礎設施積累上差距懸殊，不能簡單套用別人的路徑。我們整體的思路是以消除數據孤島為目標。很多客戶在過去就積累了大量數據技術債，進入 AI 時代同樣面臨這一問題——非結構化數據散落各處，缺乏統一的流轉和處理加工機制，治理工具也不完善。在這種情況下，應當結合自身的 AI 戰略來制定數據策略，明確在哪些方向重點發力，在哪些方向做中長期布局，并確定優先級順序。

第二，我們觀察到，很多客戶在推進時傾向于自下而上地推進，優先從存儲開始。理由是：數據先存下來，當未來真正需要使用時，隨著計算能力和治理能力的成熟，數據資產的價值才能逐步被開發出來。因此，存儲是相對最關鍵的起點。

總結起來就是這個思路：因地制宜、通盤規劃、從底層往上走。當然，通盤規劃并非意味著做大而全的頂層設計，而是要在不只解決單點問題的前提下，把握好節奏與顆粒度，這中間有一個度的把握。

InfoQ：如果把 AI 時代的數據處理放到基礎設施層面來看，GPU 參與數據處理和傳統 CPU 主導的數據處理，最大的差異是什么？它帶來的好處、代價，以及對平臺架構提出的新要求分別有哪些？

丁遠普：我更想回答的其實是"用模型來處理數據"與"用 CPU、GPU 來處理數據"之間的差異，因為這個視角更為關鍵。

最大的差異在于計算方式的根本性轉變。以前用 CPU 處理數據，工作負載基本上是規則引擎驅動的，通過 Spark、MapReduce 這類分布式引擎來處理，開發者寫 SQL 或編寫處理程序來完成任務。而基于模型處理數據，整個計算方式發生了較大變化——不再是寫程序或 SQL，而是編寫提示詞。這個范式的轉變相當顯著。

當前各廠商提供的基礎模型能力已經相當強大，最輕量的使用方式就是直接調用云上的 Token 算力——這是最輕資產的模式，不再需要像以前一樣采購服務器、購買裸機 ECS。從這個角度看，以 Token 算力對比傳統 CPU 和 GPU，整個基礎設施反而會變得更簡單、更輕量，這是一個很大的轉變。

在存儲方向，AI 時代的數據處理基礎設施同樣離不開存儲，而且存儲在 AI 時代相比計算變得更加重要了。計算側，原本需要 CPU 和 GPU 以及各類計算引擎完成的大量工作，現在很大一部分被模型替代。但存儲不同，其重要性反而在提升——尤其是多模態數據大量涌現后，音視頻數據體量更大，對存儲基礎設施的承載能力要求更高。此外，單純的文件存儲或對象存儲已不夠用，還需要向量存儲能力、Agent context 存儲能力等。這也是底層基礎設施在新時代呈現出的重要差異之一。

王彥輝：從用戶使用視角來補充。過去用戶使用數據的標準范式是 SQL，復雜些的用 Python。到了模型時代，交互方式轉變為提示詞，這對用戶的模型認知要求大幅提升——需要了解模型具備哪些能力，以及如何才能更好地發揮模型的價值。

從基礎設施建設的角度看也是如此。當我們以模型作為底層算力來構建基礎設施時，需要對模型有深入理解，才能為用戶提供更簡潔的使用體驗——用戶只需輸入一句話，系統便能在后臺根據其意圖進行擴寫和改寫，從而獲得更好的效果。

從自己寫 SQL 到直接調算子：模型時代的"最后一公里"怎么解？

InfoQ：很多企業現在會直接"裸調模型"去完成抽取、清洗、分類、理解這些任務；但也有越來越多平臺開始把這些能力沉淀成標準化算子。從企業級落地角度看，這兩種方式最大的差別是什么？什么時候該追求靈活，什么時候必須走產品化、平臺化？

丁遠普：裸調模型并非不能完成任務，但對使用者的模型理解能力要求極高。以我之前舉的 PDF 解析為例，自己裸調模型實現一套完整的 PDF 解析鏈路是非常復雜的。簡單的 PDF 也許能快速處理，但企業中的數據往往相當復雜，尤其是一些傳媒企業的 PDF，版面結構類似報紙，多欄排布且各欄格式不一。在這種情況下裸調模型，從我們實際接觸的客戶來看，很難達到理想效果。

因此，越來越多的平臺開始將這些能力封裝為算子，為使用者提供更便捷的路徑。在云上提供算子服務這一方向，我們是較早進行布局的。后來很多企業看到這一路徑的價值，也逐步跟進，認為算子確實能有效提升基于模型的數據處理能力和效果。

算子化的價值主要體現在兩個方面：

一是能力復用。基于垂直領域封裝好一個算子（如 PDF 解析），便可在企業內部多個團隊和業務中直接復用，無需每個業務線各自開發一套。從零開發本身成本較高，而且不同團隊能力參差不齊，效果也難以保持一致。

二是穩定性保障。裸調模型時，容錯處理需要自行實現；而調用我們的接口，API 層面的抖動、限流，以及模型升級帶來的兼容性問題，都可以在算子層內部消化掉，用戶無需關注。

關于什么時候該追求靈活、什么時候必須走產品化，我們的觀點是：任何時候都應該走產品化——這也是我們一直堅持的方向。

王彥輝：我覺得這兩種方式的核心差別，不在于“是否調用大模型”，而在于企業把 AI 能力當成一次性工具，還是當成可復用、可治理、可規模化的生產能力。

“裸調模型”的優勢是靈活，適合快速驗證。比如一個新場景剛出現，任務邊界還不清楚，抽取字段經常變化，業務專家還在探索規則，這時候直接用 Prompt 加模型 API，迭代速度最快。但它的問題也很明顯：效果依賴個人經驗，輸入輸出不穩定，質量難評估，成本難控制，出了問題也很難追溯。它更像實驗室能力，而不是企業級生產能力。

標準化算子的價值，是把抽取、清洗、分類、理解這些能力產品化。每個算子都有明確的輸入輸出、參數配置、質量指標、版本管理、權限控制、日志審計和異常處理。這樣 AI 能力才能被不同團隊復用，進入數據鏈路、業務流程和平臺體系，形成穩定交付，而不是每個項目重新寫一套 Prompt。

我認為是在場景早期、需求不確定、低頻使用、結果主要輔助人工判斷的時候要追求更靈活，快速是錯。這個階段要鼓勵探索，避免過早平臺化。

當一個能力開始高頻調用、影響核心業務決策、被多個團隊重復使用，或者涉及合規、安全、成本和 SLA，就必須沉淀成算子，做平臺化的能力。因為企業級 AI 落地最終比拼的不是誰能做出一個 Demo，而是誰能把有效能力穩定、可控、低成本地嵌入業務系統。產品化的本質，算子對客戶最直接的價值，是讓模型的使用變得更簡單。基礎模型提供的是高度泛化的能力，企業如果直接使用，需要在其上做大量的工程和業務適配工作。

這個演進過程其實和大數據領域的發展脈絡很像：最早需要自己實現分布式計算邏輯；有了大數據基建之后，分布式的復雜性被屏蔽，只需寫業務處理程序；后來 SQL 出現，進一步降低了使用門檻。AI 領域的演進路徑與此類似——模型提供了類似 CPU、GPU 的底層算力，而我們的算子則站在更貼近業務和領域的角度，將能力封裝好、建設好、開放出來，用戶直接調用即可，調用成本大幅降低。

從成本維度看，綜合算上人力投入，我們認為算子能夠幫助企業實現降本；從易用性和業務上線效率來看，產品化的算子同樣帶來顯著提升。

目前企業使用較多的算子類型中，文檔類（如 PDF 解析）普適性最強，幾乎各行各業都有需求，企業要么基于開源自研，成本較高且效果不穩定，要么直接調用我們的算子，簡單高效。視頻類算子我們也做了很多布局，涵蓋剪輯、爆款素材提取、商品視頻編輯、人物編輯等場景。此外還有超分能力，例如基于 Seedance 2.0 生成低分辨率內容后，通過我們的算子進行超分，可以大幅降低用戶使用 Seedance 2.0 的成本。

在計費方式上，不同算子有各自獨立的計費項。PDF 類按頁計費，視頻類算子多數按時長（處理時長或生成時長）計費，也有少數算子仍以 Token 方式計費。總體方向是，我們希望越來越多的算子能夠以業務單位來計費（如頁數、時長），而非將 Token 直接暴露給用戶——Token 對大多數業務人員來說不直觀，也不易理解。

王彥輝：

從產品化角度看，算子的價值絕不只是“把模型能力封裝一下”。如果只是把 Prompt 包成一個接口，那還停留在技術封裝層；真正的算子，是把不穩定、難復用、難治理的模型能力，轉化為企業可以配置、編排、觀測和規模化交付的產品能力。

它帶來的第一層價值是穩定性。企業不可能接受每個項目都靠工程師手寫 Prompt、手工調參。算子需要定義清楚輸入輸出、參數、版本、質量指標、異常處理和回退機制，讓 AI 能力進入生產鏈路。

第二層是成本控制。模型調用成本、上下文長度、并發、緩存、批處理、大小模型協同，都需要在算子層被產品化管理。否則企業越用 AI，成本越不可控。

第三層是復用效率。抽取、清洗、分類、匹配、總結、質檢這些能力，本質上會在不同業務里反復出現。算子化之后，平臺可以把最佳實踐沉淀下來，讓業務團隊通過配置和編排復用，而不是每次重新開發。

第四層是交付方式的變化。過去 AI 項目往往是定制化交付，一個場景一個方案；算子化之后，平臺可以用“標準能力 + 場景配置”的方式交付，大幅降低規模化復制的難度。

不同客戶的訴求也會不同。數據和 AI 成熟度高的大型企業，更關心算子的可治理性、可觀測性、權限、審計、SLA，以及能否納入現有數據平臺和流程體系。中型企業更關注開箱即用、成本可控、上線速度和業務效果。行業客戶，比如金融、政務、醫療，會更重視合規、安全、可解釋和過程留痕；互聯網和零售客戶則更關注高并發、實時性、A/B 測試和快速迭代。

所以算子的本質，不是模型接口，而是企業級 AI 能力的產品單元。它把模型能力從“能用”推進到“可管、可復用、可交付、可規模化”。

InfoQ：過去我們習慣把"存"和"算"拆開理解，但在 AI 場景里，數據的沉淀、更新、檢索、加工和反饋已經形成一個循環，尤其當企業希望應用持續獲得更好的上下文、知識和效果時，數據底座該如何通過架構設計，讓這套"存—算—再沉淀"的閉環真正跑起來？這里面最關鍵的設計原則是什么？

丁遠普：AI 領域都在講數據飛輪，但存和算如何形成閉環，在不同階段的答案并不相同——模型預訓練階段、后訓練階段，以及 Agent 階段，各自的機制都有所差異。

單就 Agent 階段而言，數據本身在持續產生。已有的數據可以構建成知識或記憶，注入 Agent；隨著用戶使用 Agent，又會不斷生成新的問答對，形成新的數據，這些數據會持續沉淀到 Agent 底層的數據存儲中，轉化為知識和記憶，再反饋給 Agent。這樣，在 Agent 層面也形成了一個數據閉環，持續運轉。模型的預訓練和后訓練階段，同樣存在類似的飛輪機制。

王彥輝：剛才提到數據沉淀，以前數據主要給人使用，沉淀方式是通過用戶行為形成行為日志，再輸入推薦平臺，產出推薦結果。而現在，很多數據沉淀發生在人機交互過程中——作業執行記錄、對話 session turn、Agent 執行結果等，都是重要的數據來源。

這些數據當前一個非常關鍵的應用場景是評測——這是以前所不具備的能力。過去執行 SQL 或推薦系統的結果雖然也有不確定性，但有明確的業務指標可以掛鉤驗證。現在，模型的能力表現與 Agent 的執行過程高度相關，結果具有更強的不確定性。這帶來一個新的視角：如何讓人、或讓模型、或讓整個 Agent 去理解自身的執行過程？這就需要引入評測機制。

兩年前，評測主要依靠人工來完成；現在越來越多的評測由 Agent 自主完成——提出需求，Agent 自行做規劃和執行，再由 Agent 對執行結果進行自評，給出推斷性的反饋，而不再是像以前一樣輸出一個確定性的結果供人查看。SQL 執行會生成一張確定性的報表，而現在很多執行結果是不確定的，數據基礎設施也需要更多地面向這種不確定性來設計和準備。

這是 AI 時代在數據應用層面一個非常重要的變化——面向評測場景的數據應用，從數據節點的角度來看，意義尤為突出。

存儲會成為標配，模型之上一切皆變

InfoQ：未來 2-3 年，AI 基礎設施最有可能先收斂出哪些標準層？哪些能力會成為"基礎配置"，哪些仍會因行業和場景而高度分化？

丁遠普：首先，存儲會成為標準層。在 AI 時代，存儲不但沒有過時，反而愈發重要。無論是底層的文件系統還是對象存儲，都在持續擴展新能力以支撐 AI 場景的需求。從我們的觀察來看，國內外的廠商在存儲方向都在面向 Agent 做布局，典型的是多家云廠商都在跟進支持了 Lance 存儲格式；Agent 架構中首選開放存儲，一份數據支持 AI 不同的 workload。

其次，結構化分布式計算依然重要。但在面向 Agent 的企業基建中，基于 Spark、Flink 的大規模分布式計算會對 Serverless 形態會有更強的訴求，企業無需自建團隊維護分布式引擎、也會逐步減少數據開發的投入，更多的交給 Agent、交給提示詞。

另外，向量檢索能力會持續沉淀為標準能力，這一方向相對已較為成熟。

再者，算子層也呈現出明顯的標準化趨勢。越來越多的廠商開始在模型之上構建更貼近業務的能力層，解決模型到業務落地之間的"最后一公里"問題。當然，僅靠算子可能還不夠，我們在算子之上還進一步做了應用層的封裝，或者以 Skill 的方式將算子推送到 Agent 中發揮價值——不過這一層已超出嚴格意義上的基礎設施范疇。

最后，GPU 不一定會成為各家基礎設施的標配，但模型付費能力一定是。GPU 本身供貨緊缺，對大多數企業而言也是重資產——無論是采購云上 GPU 還是自建 IDC，投入都較大。從成本 ROI 來看，直接購買 Token、調用算子、配合存儲，是更輕量也更合理的路徑。這是我們認為會逐步形成標準層的幾個方向。

高度分化的部分，更多集中在偏業務的領域層。云廠商通常不會深入到用戶極少的垂直細分場景，因為需要考慮規模化復制和投入產出比。因此，醫療、金融等高度專業化的行業數據訴求，仍將長期保持分化狀態——這些領域可能更適合由專注該行業的企業來承接，對于我們這類平臺型廠商而言，這一層更多是泛化能力的體現。

王彥輝：我認為這其中最大的變量是模型的能力。模型能力之下，數據存儲是能夠形成標準的，這一點我與丁遠普的判斷一致。

但模型能力之上，變化會非常劇烈。兩三年前，Agent 能力尚不具備，圍繞推理的計算形態相對單一；模型能力提升后，Agent 能力逐步成型，從短任務 Agent 演進到能夠執行長時復雜任務的 Agent，又是一次形態躍遷。所以，模型之上如何使用模型、如何與模型交互，這一層的變化速度會非常快，難以形成穩定的標準。

這也意味著，越靠近模型之上的能力層，越需要保持敏捷和開放，而越靠近底層的存儲與數據管理，越有機會沉淀為長期穩定的基礎設施標準。

會議推薦

AICon 上海站 4 大核心看點：Keynote 前瞻洞見、Agent 工程化專題拆解、前沿技術 + 產業落地全覆蓋，Google Cloud 專家實操帶練。更多詳情可掃碼或聯系票務經理 13269078023 進行咨詢。

今日薦文

你也「在看」嗎？