Data Agent整体介绍
智能分析Agent产品演进
智能分析Agent技术架构演进
智能分析Agent落地新进展
Data Agent未来架构展望
我想从一个“四象限”框架开始谈起。
自ChatGPT支持上传Excel文件以来，许多数据从业者就开始思考：能否利用Agent或大模型来替代传统的数据分析工作？这个四象限划分了不同的技术路径：第一象限是纯大模型（Bare Metal），直接调用API生成文本；第四象限代表传统数据产品，如BI工具和归因分析系统；第二象限则是通用Agent，例如Deep Research这类能撰写报告、进行调研的产品。
然而，通用Agent在处理数据分析任务时往往力不从心。一个典型的例子是SQL代码生成：如果没有经过精心设计，其生成正确代码的成功率可能像“抽卡”一样随机，十次尝试中或许只有两三次能写对。更关键的问题在于企业知识的融合——公司的指标平台是一个复杂的系统工程，通用Agent难以理解和接入这种专业的数据知识体系。
正因如此，Data Agent的价值得以凸显。它需要既能无缝对接企业的知识基座，又能在数据领域通过精细化的流程设计和工具链优化，切实提升业务适用性和数据结果的准确性。
那么，什么是数据分析Agent？
简而言之，数据分析Agent第一代可以理解为“Chat BI”，即聊天式的商业智能交互；第二代则更接近通用Agent在数据领域的深度应用，能够执行端到端的自动化分析任务。在火山引擎，我们构建了完整的产品体系来支持这些能力，包括Chat BI数据洞察报告、开放的数据分析Agent接口，以及自动生成仪表盘等功能。
这套产品的能力是分层构建的。
最底层负责适配各种模型底座，如火山引擎内部系统或兼容OpenAI协议的外部模型；向上是数据能力底座，解决企业最核心的数据连接、权限管控等基础问题；再上一层是配置管理层，致力于将散乱的数据命名和描述进行语义化处理，并结合业务知识库和知识图谱，使模型能够真正理解企业的数据内涵；最顶层则是面向用户的数据消费产品，例如支持多轮追问的Chat BI界面，以及今年新推出的深度研究模式。
这些能力不仅可以通过原生的用户界面使用，也能通过开放的API集成到企业的OA系统或工作流平台中。
谈到产品演进，一个关键概念是“Product Model Fit”——产品形态必须与模型能力相匹配。在Pre-LM（前大模型）时代，人们尝试用BERT等小模型做Text-to-SQL，效果如同玩具，难以实际落地；进入前大模型时代后，BI产品开始加入归因预测等增强分析功能，但对用户要求过高，普通人难以驾驭。直到2023年底ChatGPT 3.5的出现，催生了一批Chat BI产品，但其应用场景仍显局限，灵活性不足。
真正的转折点出现在2024年。O3推理模型的出现，让Deep Research这类产品展现出令人惊艳的能力，它让我第一次感受到AI在数据分析领域接近L3/L4级自动驾驶的智能水平。今年之所以被称为“Agent元年”，正是因为模型能力终于能够支撑开放式的Agent设计理念。
我们的第一代产品“智能问数”就是在ChatGPT 3.5时期诞生的。在设计时，我们特别关注了数据分析师的实际工作流程：他们使用仪表盘等工具时，并非直接创建仪表盘，而是先灵活地查询数据、寻找洞察，再将有价值的结论固化为报表。因此，我们的产品让用户先通过主动提问进行灵活分析，接着系统自动进行归因和下钻以发现关键维度，最后用户可以将有价值的问题收藏并自动生成日报或周报。这看似是一个简单的聊天机器人（Chatbot），实则完整还原了从临时性洞察到例行化监控的业务闭环。
当然，任何产品都有其局限性。Chat BI能否真正发挥作用？关键在于找到合适的应用场景。它可能无法完全替代专业分析师的全套工具链，但对于一线业务人员来说却非常适用。例如，我们为抖音地推团队部署后，八千多名成员可以随时在移动端查询数据，其灵活性远超传统BI工具。这引出了一个核心矛盾：产品开发不能一味追求技术先进性，更要解决“Product Market Fit”（产品市场契合度）——即明确谁需要这个产品，在什么场景下使用？这才是决定产品能否成功落地的关键。
引入新产品后，关键在于找准它能替代哪些现有场景。例如，Chat BI能否替代传统BI系统？对于熟练的数据分析师而言可能不行，他们已精通现有工具。但在我们火山引擎落地的案例中，像抖音地推团队这样的一线人员，规模达八千人且常年在户外奔波，传统BI根本无法在移动端灵活支持他们实时查询数据、服务客户。恰恰是这种移动端、临时性的查询场景，成为了Chat BI大放异彩的舞台。
这涉及到三种替代逻辑：产品替代要看目标用户，场景替代要看任务复杂度。例如，分析师需要同时计算同环比、占比并进行归因分析，当前Chat BI的架构尚难以支撑如此复杂的任务；技能替代则要看用户角色，决策层和一线员工可能是最合适的受益者。归根结底，Chat BI并非万能钥匙，无法通吃所有场景，找准其“Product Market Fit”（PMF）的突破口至关重要。
因此，我们在2025年推出了“深度分析模式”，它更接近通用Agent的形态：用户只需提出一个开放性问题，系统便能自动生成分析计划、拆解子任务、执行到底，最终输出Markdown报告或网页。
虽然看起来能处理更开放的问题，但也带来了新的挑战，其中“领域知识”是首要障碍。人类语言本身存在局限性，例如广告行业的“消耗”一词，外行人可能完全不解其意。为此，我们构建了结构化知识库来解决专业术语问题。
此外，分析框架也需要专门沉淀，因为在拆解开放性问题时，模型的理解可能与企业惯用的分析逻辑存在偏差；还有领域常识，例如电商行业的“黑话”往往散落在飞书文档中，我们通过对接企业知识库，挖掘出这些“冰山下的知识”。
数据准确性更是硬性要求。Chat BI偶尔算错一个数字或许尚可容忍，但当深度分析报告涉及二十个数据点时，即使每个点有99%的准确率，其整体准确率经过连乘也会骤降至82%。更不用说用户提问本身可能模糊不清，结果也难以校验。
我们引入了反问澄清机制和自动化校验手段，如同给Agent配备了一位“质检员”，逐步将准确度打磨提升。带着这些思考，接下来我们探讨技术架构如何支撑这些需求。
在技术架构层面，Data Agent的整体框架与我们之前提到的产品能力矩阵是匹配的：最底层处理模型集成、数据接入、智能配置等基础工作；向上则通过Open API、MCP（模型控制平面）甚至谷歌的A to A协议，使企业能够灵活地将Agent能力嵌入其自有系统中。
这里需要重点介绍“智能问数”架构的演进。1.0版本大家可能比较熟悉：用户提问后，系统首先进行Schema Linking（理解问题并定位相关数据），接着通过语义粗排和精排选择数据集，再结合知识库和Prompt生成代码，最后将代码转换成不同引擎可执行的语句并可视化结果。这套流程在学术论文中常见，但在实际应用中发现泛化能力不足。事实证明，在模型能力提升之后，过于清晰的流程反而会显得僵化。
因此我们升级到2.0版本：将原先固定的模块拆解为工具包，例如数据集选择工具、图表洞察工具、SQL/Python沙箱等。用户问题输入后，系统动态规划执行流程，像搭积木一样按需调用工具。这更接近真正的Agent理念，模型能够理解上下文，并能采用类似React架构的思路进行自我优化，提升输出质量。简而言之，架构从“流水线”进化为了“智能调度站”。
深度分析模式的架构在短短半年内就迭代了三次。今年5月在北京分享的版本是“Plan-and-Execute”模式：先由Coordinator生成计划，再分派给Worker工具执行。听起来合理，但实际运行中暴露了问题：第一个工具生成的SQL筛选条件，在传递给第二个工具时可能丢失。上下文传递如同掉入黑洞，第一步设定的全局规则在后续执行中可能被忽略。这种架构在需要动态调整时尤其吃力，一旦计划生成便难以中途优化。
另一个棘手的问题是动态调整能力。之前的架构一旦生成计划就僵化执行，中途优化困难重重。因此，我们从“Plan-and-Execute”升级到“One Agent”模式。但在落地时发现，用户需求存在显著差异：开放性问题需要启发式思路，而日报周报等模板化任务更看重稳定性。新架构对这两类需求进行了分流处理，同时优化了工具设计，确保模型在编写SQL等操作时能记住上下文规则，即使经过二十步操作也不会丢失关键信息。
架构升级后，数据准确性确实得到了提升，但客户的需求不止于此，他们希望报告能提供有价值的业务洞察。我们发现“One Agent”在“举一反三”、结合业务场景提出建议方面仍有不足。
于是我们更进一步：拆分出专门负责数据探查的Agent和专注于数据洞察的Agent，各司其职；配备了上下文引擎来管理记忆；并重新设计了Agent Workspace，本质上是为模型打造一个更趁手的“工作台”，让它能够以更自然的方式调用工具。这就是我们当前3.0架构的核心思想。
谈到落地效果，在电商场景中，一线运营人员使用Chat BI进行数据查询和归因分析，能够将高频问题沉淀为自动化报告；另一个智能投顾案例中，Agent生成的营销活动报告直接提升了投资顾问的工作效率。
首先，错误会指数级放大。单步99%的准确率，在二十步操作后可能骤降至82%。架构设计必须直面这一数学规律，通过冗余校验、多重验证等手段与之对抗。
其次，团队需要并行实验。过去半年我们架构迭代三次，正是依靠多线并行的验证策略。如果死磕单一方案，一旦模型能力升级，原有方案很容易掉队。搞Data Agent开发，敏捷比完美更重要。