破局與進化：火山引擎Data Agent從落地實踐到架構未來
本文為火山引擎技術專家陳碩，在AICon全球人工智能與機器學習技術大會上的演講分享。本文圍繞以下五部分展開：
- Data Agent整體介紹
- 智能分析Agent產(chǎn)品演進
- 智能分析Agent技術架構演進
- 智能分析Agent落地新進展
- Data Agent未來架構展望
大家好，很榮幸能參加這次分享，跟大家聊一聊我們在火山引擎Data Agent-智能分析Agent方向的一些落地實踐和踩坑經(jīng)驗。讓我們直接進入主題。
我想從一個“四象限”框架開始談起。
自ChatGPT支持上傳Excel文件以來，許多數(shù)據(jù)從業(yè)者就開始思考：能否利用Agent或大模型來替代傳統(tǒng)的數(shù)據(jù)分析工作？這個四象限劃分了不同的技術路徑：第一象限是純大模型（Bare Metal），直接調用API生成文本；第四象限代表傳統(tǒng)數(shù)據(jù)產(chǎn)品，如BI工具和歸因分析系統(tǒng)；第二象限則是通用Agent，例如Deep Research這類能撰寫報告、進行調研的產(chǎn)品。
然而，通用Agent在處理數(shù)據(jù)分析任務時往往力不從心。一個典型的例子是SQL代碼生成：如果沒有經(jīng)過精心設計，其生成正確代碼的成功率可能像“抽卡”一樣隨機，十次嘗試中或許只有兩三次能寫對。更關鍵的問題在于企業(yè)知識的融合——公司的指標平臺是一個復雜的系統(tǒng)工程，通用Agent難以理解和接入這種專業(yè)的數(shù)據(jù)知識體系。
正因如此，Data Agent的價值得以凸顯。它需要既能無縫對接企業(yè)的知識基座，又能在數(shù)據(jù)領域通過精細化的流程設計和工具鏈優(yōu)化，切實提升業(yè)務適用性和數(shù)據(jù)結果的準確性。
那么，什么是數(shù)據(jù)分析Agent？
簡而言之，數(shù)據(jù)分析Agent第一代可以理解為“Chat BI”，即聊天式的商業(yè)智能交互；第二代則更接近通用Agent在數(shù)據(jù)領域的深度應用，能夠執(zhí)行端到端的自動化分析任務。在火山引擎，我們構建了完整的產(chǎn)品體系來支持這些能力，包括Chat BI數(shù)據(jù)洞察報告、開放的數(shù)據(jù)分析Agent接口，以及自動生成儀表盤等功能。
這套產(chǎn)品的能力是分層構建的。
最底層負責適配各種模型底座，如火山引擎內部系統(tǒng)或兼容OpenAI協(xié)議的外部模型；向上是數(shù)據(jù)能力底座，解決企業(yè)最核心的數(shù)據(jù)連接、權限管控等基礎問題；再上一層是配置管理層，致力于將散亂的數(shù)據(jù)命名和描述進行語義化處理，并結合業(yè)務知識庫和知識圖譜，使模型能夠真正理解企業(yè)的數(shù)據(jù)內涵；最頂層則是面向用戶的數(shù)據(jù)消費產(chǎn)品，例如支持多輪追問的Chat BI界面，以及今年新推出的深度研究模式。
這些能力不僅可以通過原生的用戶界面使用，也能通過開放的API集成到企業(yè)的OA系統(tǒng)或工作流平臺中。
談到產(chǎn)品演進，一個關鍵概念是“Product Model Fit”——產(chǎn)品形態(tài)必須與模型能力相匹配。在Pre-LM（前大模型）時代，人們嘗試用BERT等小模型做Text-to-SQL，效果如同玩具，難以實際落地；進入前大模型時代后，BI產(chǎn)品開始加入歸因預測等增強分析功能，但對用戶要求過高，普通人難以駕馭。直到2023年底ChatGPT 3.5的出現(xiàn)，催生了一批Chat BI產(chǎn)品，但其應用場景仍顯局限，靈活性不足。
真正的轉折點出現(xiàn)在2024年。O3推理模型的出現(xiàn)，讓Deep Research這類產(chǎn)品展現(xiàn)出令人驚艷的能力，它讓我第一次感受到AI在數(shù)據(jù)分析領域接近L3/L4級自動駕駛的智能水平。今年之所以被稱為“Agent元年”，正是因為模型能力終于能夠支撐開放式的Agent設計理念。
我們的第一代產(chǎn)品“智能問數(shù)”就是在ChatGPT 3.5時期誕生的。在設計時，我們特別關注了數(shù)據(jù)分析師的實際工作流程：他們使用儀表盤等工具時，并非直接創(chuàng)建儀表盤，而是先靈活地查詢數(shù)據(jù)、尋找洞察，再將有價值的結論固化為報表。因此，我們的產(chǎn)品讓用戶先通過主動提問進行靈活分析，接著系統(tǒng)自動進行歸因和下鉆以發(fā)現(xiàn)關鍵維度，最后用戶可以將有價值的問題收藏并自動生成日報或周報。這看似是一個簡單的聊天機器人（Chatbot），實則完整還原了從臨時性洞察到例行化監(jiān)控的業(yè)務閉環(huán)。
當然，任何產(chǎn)品都有其局限性。Chat BI能否真正發(fā)揮作用？關鍵在于找到合適的應用場景。它可能無法完全替代專業(yè)分析師的全套工具鏈，但對于一線業(yè)務人員來說卻非常適用。例如，我們?yōu)槎兑舻赝茍F隊部署后，八千多名成員可以隨時在移動端查詢數(shù)據(jù)，其靈活性遠超傳統(tǒng)BI工具。這引出了一個核心矛盾：產(chǎn)品開發(fā)不能一味追求技術先進性，更要解決“Product Market Fit”（產(chǎn)品市場契合度）——即明確誰需要這個產(chǎn)品，在什么場景下使用？這才是決定產(chǎn)品能否成功落地的關鍵。
引入新產(chǎn)品后，關鍵在于找準它能替代哪些現(xiàn)有場景。例如，Chat BI能否替代傳統(tǒng)BI系統(tǒng)？對于熟練的數(shù)據(jù)分析師而言可能不行，他們已精通現(xiàn)有工具。但在我們火山引擎落地的案例中，像抖音地推團隊這樣的一線人員，規(guī)模達八千人且常年在戶外奔波，傳統(tǒng)BI根本無法在移動端靈活支持他們實時查詢數(shù)據(jù)、服務客戶。恰恰是這種移動端、臨時性的查詢場景，成為了Chat BI大放異彩的舞臺。
這涉及到三種替代邏輯：產(chǎn)品替代要看目標用戶，場景替代要看任務復雜度。例如，分析師需要同時計算同環(huán)比、占比并進行歸因分析，當前Chat BI的架構尚難以支撐如此復雜的任務；技能替代則要看用戶角色，決策層和一線員工可能是最合適的受益者。歸根結底，Chat BI并非萬能鑰匙，無法通吃所有場景，找準其“Product Market Fit”（PMF）的突破口至關重要。
因此，我們在2025年推出了“深度分析模式”，它更接近通用Agent的形態(tài)：用戶只需提出一個開放性問題，系統(tǒng)便能自動生成分析計劃、拆解子任務、執(zhí)行到底，最終輸出Markdown報告或網(wǎng)頁。
雖然看起來能處理更開放的問題，但也帶來了新的挑戰(zhàn)，其中“領域知識”是首要障礙。人類語言本身存在局限性，例如廣告行業(yè)的“消耗”一詞，外行人可能完全不解其意。為此，我們構建了結構化知識庫來解決專業(yè)術語問題。
此外，分析框架也需要專門沉淀，因為在拆解開放性問題時，模型的理解可能與企業(yè)慣用的分析邏輯存在偏差；還有領域常識，例如電商行業(yè)的“黑話”往往散落在飛書文檔中，我們通過對接企業(yè)知識庫，挖掘出這些“冰山下的知識”。
數(shù)據(jù)準確性更是硬性要求。Chat BI偶爾算錯一個數(shù)字或許尚可容忍，但當深度分析報告涉及二十個數(shù)據(jù)點時，即使每個點有99%的準確率，其整體準確率經(jīng)過連乘也會驟降至82%。更不用說用戶提問本身可能模糊不清，結果也難以校驗。
我們引入了反問澄清機制和自動化校驗手段，如同給Agent配備了一位“質檢員”，逐步將準確度打磨提升。帶著這些思考，接下來我們探討技術架構如何支撐這些需求。
在技術架構層面，Data Agent的整體框架與我們之前提到的產(chǎn)品能力矩陣是匹配的：最底層處理模型集成、數(shù)據(jù)接入、智能配置等基礎工作；向上則通過Open API、MCP（模型控制平面）甚至谷歌的A to A協(xié)議，使企業(yè)能夠靈活地將Agent能力嵌入其自有系統(tǒng)中。
這里需要重點介紹“智能問數(shù)”架構的演進。1.0版本大家可能比較熟悉：用戶提問后，系統(tǒng)首先進行Schema Linking（理解問題并定位相關數(shù)據(jù)），接著通過語義粗排和精排選擇數(shù)據(jù)集，再結合知識庫和Prompt生成代碼，最后將代碼轉換成不同引擎可執(zhí)行的語句并可視化結果。這套流程在學術論文中常見，但在實際應用中發(fā)現(xiàn)泛化能力不足。事實證明，在模型能力提升之后，過于清晰的流程反而會顯得僵化。
因此我們升級到2.0版本：將原先固定的模塊拆解為工具包，例如數(shù)據(jù)集選擇工具、圖表洞察工具、SQL/Python沙箱等。用戶問題輸入后，系統(tǒng)動態(tài)規(guī)劃執(zhí)行流程，像搭積木一樣按需調用工具。這更接近真正的Agent理念，模型能夠理解上下文，并能采用類似React架構的思路進行自我優(yōu)化，提升輸出質量。簡而言之，架構從“流水線”進化為了“智能調度站”。
深度分析模式的架構在短短半年內就迭代了三次。今年5月在北京分享的版本是“Plan-and-Execute”模式：先由Coordinator生成計劃，再分派給Worker工具執(zhí)行。聽起來合理，但實際運行中暴露了問題：第一個工具生成的SQL篩選條件，在傳遞給第二個工具時可能丟失。上下文傳遞如同掉入黑洞，第一步設定的全局規(guī)則在后續(xù)執(zhí)行中可能被忽略。這種架構在需要動態(tài)調整時尤其吃力，一旦計劃生成便難以中途優(yōu)化。
另一個棘手的問題是動態(tài)調整能力。之前的架構一旦生成計劃就僵化執(zhí)行，中途優(yōu)化困難重重。因此，我們從“Plan-and-Execute”升級到“One Agent”模式。但在落地時發(fā)現(xiàn)，用戶需求存在顯著差異：開放性問題需要啟發(fā)式思路，而日報周報等模板化任務更看重穩(wěn)定性。新架構對這兩類需求進行了分流處理，同時優(yōu)化了工具設計，確保模型在編寫SQL等操作時能記住上下文規(guī)則，即使經(jīng)過二十步操作也不會丟失關鍵信息。
架構升級后，數(shù)據(jù)準確性確實得到了提升，但客戶的需求不止于此，他們希望報告能提供有價值的業(yè)務洞察。我們發(fā)現(xiàn)“One Agent”在“舉一反三”、結合業(yè)務場景提出建議方面仍有不足。
于是我們更進一步：拆分出專門負責數(shù)據(jù)探查的Agent和專注于數(shù)據(jù)洞察的Agent，各司其職；配備了上下文引擎來管理記憶；并重新設計了Agent Workspace，本質上是為模型打造一個更趁手的“工作臺”，讓它能夠以更自然的方式調用工具。這就是我們當前3.0架構的核心思想。
談到落地效果，在電商場景中，一線運營人員使用Chat BI進行數(shù)據(jù)查詢和歸因分析，能夠將高頻問題沉淀為自動化報告；另一個智能投顧案例中，Agent生成的營銷活動報告直接提升了投資顧問的工作效率。
最后，分享兩點核心思考：
首先，錯誤會指數(shù)級放大。單步99%的準確率，在二十步操作后可能驟降至82%。架構設計必須直面這一數(shù)學規(guī)律，通過冗余校驗、多重驗證等手段與之對抗。
其次，團隊需要并行實驗。過去半年我們架構迭代三次，正是依靠多線并行的驗證策略。如果死磕單一方案，一旦模型能力升級，原有方案很容易掉隊。搞Data Agent開發(fā)，敏捷比完美更重要。
我的分享就到這里，謝謝大家！
浙公網(wǎng)安備 33010602011771號