資料來源：火山引擎-開發(fā)者社區(qū)

本文為火山引擎技術(shù)專家陳碩，在AICon全球人工智能與機(jī)器學(xué)習(xí)技術(shù)大會上的演講分享。本文圍繞以下五部分展開：

• Data Agent整體介紹

• 智能分析Agent產(chǎn)品演進(jìn)

• 智能分析Agent技術(shù)架構(gòu)演進(jìn)

• 智能分析Agent落地新進(jìn)展

• Data Agent未來架構(gòu)展望

大家好，很榮幸能參加這次分享，跟大家聊一聊我們在火山引擎Data Agent-智能分析Agent方向的一些落地實踐和踩坑經(jīng)驗。讓我們直接進(jìn)入主題。

我想從一個“四象限”框架開始談起。

自ChatGPT支持上傳Excel文件以來，許多數(shù)據(jù)從業(yè)者就開始思考：能否利用Agent或大模型來替代傳統(tǒng)的數(shù)據(jù)分析工作？這個四象限劃分了不同的技術(shù)路徑：第一象限是純大模型（Bare Metal），直接調(diào)用API生成文本；第四象限代表傳統(tǒng)數(shù)據(jù)產(chǎn)品，如BI工具和歸因分析系統(tǒng)；第二象限則是通用Agent，例如Deep Research這類能撰寫報告、進(jìn)行調(diào)研的產(chǎn)品。

然而，通用Agent在處理數(shù)據(jù)分析任務(wù)時往往力不從心。一個典型的例子是SQL代碼生成：如果沒有經(jīng)過精心設(shè)計，其生成正確代碼的成功率可能像“抽卡”一樣隨機(jī)，十次嘗試中或許只有兩三次能寫對。更關(guān)鍵的問題在于企業(yè)知識的融合——公司的指標(biāo)平臺是一個復(fù)雜的系統(tǒng)工程，通用Agent難以理解和接入這種專業(yè)的數(shù)據(jù)知識體系。

正因如此，Data Agent的價值得以凸顯。它需要既能無縫對接企業(yè)的知識基座，又能在數(shù)據(jù)領(lǐng)域通過精細(xì)化的流程設(shè)計和工具鏈優(yōu)化，切實提升業(yè)務(wù)適用性和數(shù)據(jù)結(jié)果的準(zhǔn)確性。

那么，什么是數(shù)據(jù)分析Agent？

簡而言之，數(shù)據(jù)分析Agent第一代可以理解為“Chat BI”，即聊天式的商業(yè)智能交互；第二代則更接近通用Agent在數(shù)據(jù)領(lǐng)域的深度應(yīng)用，能夠執(zhí)行端到端的自動化分析任務(wù)。在火山引擎，我們構(gòu)建了完整的產(chǎn)品體系來支持這些能力，包括Chat BI數(shù)據(jù)洞察報告、開放的數(shù)據(jù)分析Agent接口，以及自動生成儀表盤等功能。

這套產(chǎn)品的能力是分層構(gòu)建的。

最底層負(fù)責(zé)適配各種模型底座，如火山引擎內(nèi)部系統(tǒng)或兼容OpenAI協(xié)議的外部模型；向上是數(shù)據(jù)能力底座，解決企業(yè)最核心的數(shù)據(jù)連接、權(quán)限管控等基礎(chǔ)問題；再上一層是配置管理層，致力于將散亂的數(shù)據(jù)命名和描述進(jìn)行語義化處理，并結(jié)合業(yè)務(wù)知識庫和知識圖譜，使模型能夠真正理解企業(yè)的數(shù)據(jù)內(nèi)涵；最頂層則是面向用戶的數(shù)據(jù)消費(fèi)產(chǎn)品，例如支持多輪追問的Chat BI界面，以及今年新推出的深度研究模式。

這些能力不僅可以通過原生的用戶界面使用，也能通過開放的API集成到企業(yè)的OA系統(tǒng)或工作流平臺中。

談到產(chǎn)品演進(jìn)，一個關(guān)鍵概念是“Product Model Fit”——產(chǎn)品形態(tài)必須與模型能力相匹配。在Pre-LM（前大模型）時代，人們嘗試用BERT等小模型做Text-to-SQL，效果如同玩具，難以實際落地；進(jìn)入前大模型時代后，BI產(chǎn)品開始加入歸因預(yù)測等增強(qiáng)分析功能，但對用戶要求過高，普通人難以駕馭。直到2023年底ChatGPT 3.5的出現(xiàn)，催生了一批Chat BI產(chǎn)品，但其應(yīng)用場景仍顯局限，靈活性不足。

真正的轉(zhuǎn)折點(diǎn)出現(xiàn)在2024年。O3推理模型的出現(xiàn)，讓Deep Research這類產(chǎn)品展現(xiàn)出令人驚艷的能力，它讓我第一次感受到AI在數(shù)據(jù)分析領(lǐng)域接近L3/L4級自動駕駛的智能水平。今年之所以被稱為“Agent元年”，正是因為模型能力終于能夠支撐開放式的Agent設(shè)計理念。

我們的第一代產(chǎn)品“智能問數(shù)”就是在ChatGPT 3.5時期誕生的。在設(shè)計時，我們特別關(guān)注了數(shù)據(jù)分析師的實際工作流程：他們使用儀表盤等工具時，并非直接創(chuàng)建儀表盤，而是先靈活地查詢數(shù)據(jù)、尋找洞察，再將有價值的結(jié)論固化為報表。因此，我們的產(chǎn)品讓用戶先通過主動提問進(jìn)行靈活分析，接著系統(tǒng)自動進(jìn)行歸因和下鉆以發(fā)現(xiàn)關(guān)鍵維度，最后用戶可以將有價值的問題收藏并自動生成日報或周報。這看似是一個簡單的聊天機(jī)器人（Chatbot），實則完整還原了從臨時性洞察到例行化監(jiān)控的業(yè)務(wù)閉環(huán)。

當(dāng)然，任何產(chǎn)品都有其局限性。Chat BI能否真正發(fā)揮作用？關(guān)鍵在于找到合適的應(yīng)用場景。它可能無法完全替代專業(yè)分析師的全套工具鏈，但對于一線業(yè)務(wù)人員來說卻非常適用。例如，我們?yōu)槎兑舻赝茍F(tuán)隊部署后，八千多名成員可以隨時在移動端查詢數(shù)據(jù)，其靈活性遠(yuǎn)超傳統(tǒng)BI工具。這引出了一個核心矛盾：產(chǎn)品開發(fā)不能一味追求技術(shù)先進(jìn)性，更要解決“Product Market Fit”（產(chǎn)品市場契合度）——即明確誰需要這個產(chǎn)品，在什么場景下使用？這才是決定產(chǎn)品能否成功落地的關(guān)鍵。

引入新產(chǎn)品后，關(guān)鍵在于找準(zhǔn)它能替代哪些現(xiàn)有場景。例如，Chat BI能否替代傳統(tǒng)BI系統(tǒng)？對于熟練的數(shù)據(jù)分析師而言可能不行，他們已精通現(xiàn)有工具。但在我們火山引擎落地的案例中，像抖音地推團(tuán)隊這樣的一線人員，規(guī)模達(dá)八千人且常年在戶外奔波，傳統(tǒng)BI根本無法在移動端靈活支持他們實時查詢數(shù)據(jù)、服務(wù)客戶。恰恰是這種移動端、臨時性的查詢場景，成為了Chat BI大放異彩的舞臺。

這涉及到三種替代邏輯：產(chǎn)品替代要看目標(biāo)用戶，場景替代要看任務(wù)復(fù)雜度。例如，分析師需要同時計算同環(huán)比、占比并進(jìn)行歸因分析，當(dāng)前Chat BI的架構(gòu)尚難以支撐如此復(fù)雜的任務(wù)；技能替代則要看用戶角色，決策層和一線員工可能是最合適的受益者。歸根結(jié)底，Chat BI并非萬能鑰匙，無法通吃所有場景，找準(zhǔn)其“Product Market Fit”（PMF）的突破口至關(guān)重要。

因此，我們在2025年推出了“深度分析模式”，它更接近通用Agent的形態(tài)：用戶只需提出一個開放性問題，系統(tǒng)便能自動生成分析計劃、拆解子任務(wù)、執(zhí)行到底，最終輸出Markdown報告或網(wǎng)頁。

雖然看起來能處理更開放的問題，但也帶來了新的挑戰(zhàn)，其中“領(lǐng)域知識”是首要障礙。人類語言本身存在局限性，例如廣告行業(yè)的“消耗”一詞，外行人可能完全不解其意。為此，我們構(gòu)建了結(jié)構(gòu)化知識庫來解決專業(yè)術(shù)語問題。

此外，分析框架也需要專門沉淀，因為在拆解開放性問題時，模型的理解可能與企業(yè)慣用的分析邏輯存在偏差；還有領(lǐng)域常識，例如電商行業(yè)的“黑話”往往散落在飛書文檔中，我們通過對接企業(yè)知識庫，挖掘出這些“冰山下的知識”。

數(shù)據(jù)準(zhǔn)確性更是硬性要求。Chat BI偶爾算錯一個數(shù)字或許尚可容忍，但當(dāng)深度分析報告涉及二十個數(shù)據(jù)點(diǎn)時，即使每個點(diǎn)有99%的準(zhǔn)確率，其整體準(zhǔn)確率經(jīng)過連乘也會驟降至82%。更不用說用戶提問本身可能模糊不清，結(jié)果也難以校驗。

我們引入了反問澄清機(jī)制和自動化校驗手段，如同給Agent配備了一位“質(zhì)檢員”，逐步將準(zhǔn)確度打磨提升。帶著這些思考，接下來我們探討技術(shù)架構(gòu)如何支撐這些需求。

在技術(shù)架構(gòu)層面，Data Agent的整體框架與我們之前提到的產(chǎn)品能力矩陣是匹配的：最底層處理模型集成、數(shù)據(jù)接入、智能配置等基礎(chǔ)工作；向上則通過Open API、MCP（模型控制平面）甚至谷歌的A to A協(xié)議，使企業(yè)能夠靈活地將Agent能力嵌入其自有系統(tǒng)中。

這里需要重點(diǎn)介紹“智能問數(shù)”架構(gòu)的演進(jìn)。1.0版本大家可能比較熟悉：用戶提問后，系統(tǒng)首先進(jìn)行Schema Linking（理解問題并定位相關(guān)數(shù)據(jù)），接著通過語義粗排和精排選擇數(shù)據(jù)集，再結(jié)合知識庫和Prompt生成代碼，最后將代碼轉(zhuǎn)換成不同引擎可執(zhí)行的語句并可視化結(jié)果。這套流程在學(xué)術(shù)論文中常見，但在實際應(yīng)用中發(fā)現(xiàn)泛化能力不足。事實證明，在模型能力提升之后，過于清晰的流程反而會顯得僵化。

因此我們升級到2.0版本：將原先固定的模塊拆解為工具包，例如數(shù)據(jù)集選擇工具、圖表洞察工具、SQL/Python沙箱等。用戶問題輸入后，系統(tǒng)動態(tài)規(guī)劃執(zhí)行流程，像搭積木一樣按需調(diào)用工具。這更接近真正的Agent理念，模型能夠理解上下文，并能采用類似React架構(gòu)的思路進(jìn)行自我優(yōu)化，提升輸出質(zhì)量。簡而言之，架構(gòu)從“流水線”進(jìn)化為了“智能調(diào)度站”。

深度分析模式的架構(gòu)在短短半年內(nèi)就迭代了三次。今年5月在北京分享的版本是“Plan-and-Execute”模式：先由Coordinator生成計劃，再分派給Worker工具執(zhí)行。聽起來合理，但實際運(yùn)行中暴露了問題：第一個工具生成的SQL篩選條件，在傳遞給第二個工具時可能丟失。上下文傳遞如同掉入黑洞，第一步設(shè)定的全局規(guī)則在后續(xù)執(zhí)行中可能被忽略。這種架構(gòu)在需要動態(tài)調(diào)整時尤其吃力，一旦計劃生成便難以中途優(yōu)化。

另一個棘手的問題是動態(tài)調(diào)整能力。之前的架構(gòu)一旦生成計劃就僵化執(zhí)行，中途優(yōu)化困難重重。因此，我們從“Plan-and-Execute”升級到“One Agent”模式。但在落地時發(fā)現(xiàn)，用戶需求存在顯著差異：開放性問題需要啟發(fā)式思路，而日報周報等模板化任務(wù)更看重穩(wěn)定性。新架構(gòu)對這兩類需求進(jìn)行了分流處理，同時優(yōu)化了工具設(shè)計，確保模型在編寫SQL等操作時能記住上下文規(guī)則，即使經(jīng)過二十步操作也不會丟失關(guān)鍵信息。

架構(gòu)升級后，數(shù)據(jù)準(zhǔn)確性確實得到了提升，但客戶的需求不止于此，他們希望報告能提供有價值的業(yè)務(wù)洞察。我們發(fā)現(xiàn)“One Agent”在“舉一反三”、結(jié)合業(yè)務(wù)場景提出建議方面仍有不足。

于是我們更進(jìn)一步：拆分出專門負(fù)責(zé)數(shù)據(jù)探查的Agent和專注于數(shù)據(jù)洞察的Agent，各司其職；配備了上下文引擎來管理記憶；并重新設(shè)計了Agent Workspace，本質(zhì)上是為模型打造一個更趁手的“工作臺”，讓它能夠以更自然的方式調(diào)用工具。這就是我們當(dāng)前3.0架構(gòu)的核心思想。

談到落地效果，在電商場景中，一線運(yùn)營人員使用Chat BI進(jìn)行數(shù)據(jù)查詢和歸因分析，能夠?qū)⒏哳l問題沉淀為自動化報告；另一個智能投顧案例中，Agent生成的營銷活動報告直接提升了投資顧問的工作效率。

最后，分享兩點(diǎn)核心思考：

首先，錯誤會指數(shù)級放大。單步99%的準(zhǔn)確率，在二十步操作后可能驟降至82%。架構(gòu)設(shè)計必須直面這一數(shù)學(xué)規(guī)律，通過冗余校驗、多重驗證等手段與之對抗。

其次，團(tuán)隊需要并行實驗。過去半年我們架構(gòu)迭代三次，正是依靠多線并行的驗證策略。如果死磕單一方案，一旦模型能力升級，原有方案很容易掉隊。搞Data Agent開發(fā)，敏捷比完美更重要。

我的分享就到這里，謝謝大家！