过去两年企业数据分析产品几乎都接入了大模型。最常见的实现方式是在原有 BI 系统上增加一个自然语言入口用户输入问题大模型识别意图生成 SQL查询数据库再把结果转换成图表或文字结论。这类产品降低了取数门槛但严格来说它更接近 ChatBI 或 NL2SQL而不是完整的 Data Agent。真正的 Data Agent不只是把自然语言翻译成 SQL也不是在报表系统外面套一层聊天界面。它需要理解业务问题识别分析对象选择数据资产规划分析步骤执行查询和计算验证中间结果并将最终结论组织成用户可以理解和继续追问的分析内容。从架构上看这不是依靠一个大模型就能完成的。大模型擅长语言理解、任务规划和结果解释但不擅长直接记住企业内部所有数据定义也不适合承担精确计算、权限判断和大规模数据处理。RAG 可以补充企业知识却不能替代结构化的数据语义。语义层能够统一指标和维度但不会主动完成分析。工具调用能够执行任务却缺乏对业务目标的理解。因此一个可用的 Data Agent本质上是一个由大模型、RAG、语义层、工具系统和执行环境共同组成的分析系统。这几个模块并不是简单串联而是在一次完整的分析过程中反复协同。在真正拆解 Data Agent 的技术架构之前如果你也在关注大模型究竟如何进入企业真实业务场景而不是停留在概念和 Demo 阶段我整理了一份帆软的《“AI”场景落地实战白皮书》。白皮书更适合想进一步了解AI 如何与企业数据、业务场景和实际应用结合的读者可以配合本文一起看从“AI 能做什么”进一步看到“AI 怎么真正落地”。需要自取https://s.fanruan.com/hti40复制到浏览器一、先定义 Data Agent 的技术边界在拆解架构之前需要先回答一个问题Data Agent 到底负责什么从用户视角看Data Agent 接收到的通常不是一个明确的技术指令而是一个业务问题。例如为什么华东区域上个月销售额下降了这句话没有告诉系统应该查询哪张表销售额采用什么统计口径“上个月”按自然月还是最近30天计算华东区域包含哪些省份应该从客户、产品、渠道还是销售人员角度分析下降是同比下降、环比下降还是低于预算什么程度的变化才值得解释。传统 BI 要求用户提前选择指标、维度和筛选条件。NL2SQL 通常假设用户的问题已经足够明确再把问题转换为查询语句。但真实业务分析并不是一次查询而是一个逐步缩小问题范围的过程。分析人员通常会经历以下步骤明确问题和指标口径找到相关数据判断整体变化是否真实按不同维度拆解识别主要贡献因素验证异常是否由数据问题造成形成结论和行动建议。Data Agent 的技术边界应当覆盖这条完整链路。因此它至少需要具备四类能力理解能力理解用户意图、业务语义和分析上下文。规划能力把模糊问题拆解成可以执行的分析步骤。执行能力调用数据库、代码环境、算法模型和可视化工具。验证能力检查数据、逻辑和结论是否一致。从这个角度看大模型只是 Data Agent 的认知核心而不是全部系统。二、Data Agent 的整体技术架构一个企业级 Data Agent可以抽象为五层结构第一层交互与任务入口负责接收自然语言问题、文件、图表、报表上下文以及用户反馈。第二层认知与规划层以大模型为核心完成意图理解、任务拆解、分析规划、工具选择和结果解释。第三层知识与语义层包含 RAG、业务知识库、指标体系、元数据、数据目录、数据血缘和语义模型。第四层工具与执行层包含 SQL 查询、Python 计算、数据可视化、机器学习、报表生成和外部系统接口。第五层数据与治理层负责连接数据仓库、数据湖、业务数据库、文件和实时数据同时提供权限、安全、审计和资源控制。这五层并不是传统软件架构中的简单上下游关系。在一次分析过程中大模型可能先查询语义层再通过 RAG 获取业务规则随后生成执行计划调用 SQL 工具获取数据发现结果异常后再回到元数据层检查字段含义最后调用 Python 完成进一步计算并通过验证机制检查结论。整个过程更接近一个循环理解问题 → 获取上下文 → 制定计划 → 调用工具 → 检查结果 → 调整计划 → 生成结论这也是 Data Agent 与普通问答系统最大的架构差异。三、大模型负责理解和规划而不是直接计算很多 Data Agent 产品把大模型放在系统中心这是合理的。因为企业分析任务首先是一个语义问题。用户不会说请查询订单明细表按照区域分组计算本月含税销售金额并与上月进行对比。用户更可能说最近华东卖得怎么样大模型需要从这句话中推断“最近”对应什么时间范围“华东”对应什么区域定义“卖得怎么样”可能涉及销售额、销量、订单数、毛利和目标完成率用户真正关心的是现状、变化还是原因。这种能力很难通过固定规则实现。大模型在 Data Agent 中主要承担四项工作。意图识别判断用户是在查数据、看趋势、找原因、做预测还是生成报告。同一个问题可能对应完全不同的分析深度。“本月销售额是多少”主要是描述性分析。“本月销售额为什么下降”需要诊断性分析。“下个月销售额可能是多少”需要预测性分析。“应该调整哪些产品和渠道”则进一步涉及规范性分析。任务规划复杂分析不能通过一条 SQL 完成。大模型需要把问题拆成多个步骤例如确认销售额口径计算本月和上月销售额判断变化幅度分区域、产品、渠道拆解计算各维度对下降的贡献度检查是否存在订单缺失或退款异常汇总主要原因。任务规划的价值是把用户的自然语言目标转换成可执行分析路径。工具选择Data Agent 可能同时具备 SQL、Python、搜索、预测模型、可视化和文档生成等工具。大模型需要判断什么时候使用什么工具。简单汇总可以使用 SQL。复杂统计分析可以使用 Python。业务制度查询可以使用 RAG。趋势预测可能需要时间序列模型。最终报告则可能需要调用图表和文档生成工具。结果解释执行引擎返回的是数据、表格、统计量和图表大模型需要把这些结果转换成业务语言。例如系统不应只告诉用户华东区销售额环比下降12.7%。还应进一步说明本月华东区销售额环比下降12.7%其中江苏区域贡献了约63%的下降额。主要原因不是订单量减少而是高客单价产品销量下降同时退款金额有所增加。不过大模型不应该直接承担精确计算。大模型本质上基于 Token 概率生成内容。即使模型具备较强的数学和推理能力也不能把语言推理等同于数据库计算。因此在 Data Agent 中大模型更适合作为分析任务的规划者和解释者而不是数据结果的直接生产者。四、RAG让 Data Agent 知道企业是如何经营的大模型可以理解通用的销售、财务、库存和供应链概念但它并不知道某一家企业内部的具体规则。例如“有效客户”在不同企业中可能有完全不同的定义最近30天产生过订单的客户最近90天有付费行为的客户累计消费超过一定金额的客户当前合同仍然有效的客户。类似的问题还包括销售额是否包含税费退款订单是否计入收入毛利是否扣除物流费用新客户按首次下单还是首次付款计算区域归属按客户地址还是销售组织划分。这些内容通常分散在指标文档、业务制度、数据字典、会议纪要和分析报告中。RAG 的作用就是在分析过程中为大模型补充这些企业内部知识。一个典型的 RAG 流程包括将企业文档切分和向量化根据用户问题召回相关内容对召回结果进行重排将高相关内容放入模型上下文让模型基于企业知识理解和回答问题。但在 Data Agent 中RAG 不能只做文档问答。它至少需要支持三类知识。业务知识包括行业术语、业务流程、部门规则和管理制度。例如什么是有效商机什么情况下订单被判定为取消不同客户等级如何划分某个促销政策适用于哪些产品。分析知识包括分析方法、计算逻辑、诊断框架和历史经验。例如销售额下降通常从价格、销量和产品结构拆解库存异常需要检查入库、出库、调拨和盘点毛利下降可以从价格、成本和产品组合分析。历史分析知识包括过去的分析过程、结论和业务反馈。例如上一次销售下降是由于渠道促销结束某类异常订单需要排除测试账号某个指标在月初通常存在数据延迟。这类历史内容可以帮助 Data Agent 避免重复分析也可以使结论更符合企业实际情况。不过RAG 也有明显局限。文档中的定义可能过期不同文档之间可能存在冲突召回结果也不一定完整。如果 Data Agent 直接把检索到的内容当成绝对事实反而可能引入新的错误。因此企业级 RAG 还需要解决文档版本管理知识有效期来源可信度权限过滤冲突检测引用追溯。RAG 提供的是企业知识上下文而不是最终的数据计算逻辑。五、语义层让业务语言能够稳定映射到数据如果说 RAG 解决的是“企业如何理解业务”那么语义层解决的是这些业务概念在数据系统中具体对应什么。这是Data Agent 架构中最容易被低估的一层。很多 NL2SQL 系统直接让大模型读取数据库表结构再根据字段名称生成查询。在数据表较少、字段命名规范、业务逻辑简单时这种方法可能有效。但进入真实企业环境后数据库中通常存在大量历史表、中间表、重复字段和技术字段。同一个“销售额”可能同时出现在订单明细表支付流水表财务收入表销售日报表经销商结算表。不同表中的数值甚至可能都正确只是口径不同。如果缺少语义层大模型即使生成了语法正确的 SQL也不代表拿到了业务上正确的结果。语义层通常需要管理以下内容。指标定义明确指标名称、计算公式、时间口径、过滤条件和适用范围。例如净销售额 已支付订单金额 - 退款金额 - 取消订单金额维度定义明确区域、产品、客户、渠道、组织等分析维度及其层级关系。例如华东区域 → 江苏、浙江、安徽、福建、江西、山东、上海实体关系定义订单、客户、商品、门店和员工等业务实体之间如何关联。数据映射将业务指标和维度映射到底层库、表、字段和计算逻辑。权限规则规定不同用户能够访问哪些指标、维度和明细数据。语义层的价值是在自然语言和物理数据之间建立一个稳定的中间表示。用户说“销售额”Data Agent 不需要每次重新猜测应该使用哪个字段而是先解析为一个明确的语义对象再由语义层生成对应查询。可以把这个过程理解为自然语言 → 业务语义 → 数据逻辑 → 执行语句而不是直接从自然语言 → SQL这种中间层设计会增加前期建设成本但它能够显著提高结果的一致性、可解释性和可维护性。尤其在企业环境中Data Agent 最危险的问题不是无法回答而是不同时间、不同用户问同一个问题系统给出不同口径的答案。语义层的核心价值就是提供确定性。六、工具调用把分析计划转化为真实行动大模型完成任务规划之后需要通过工具与外部环境交互。Data Agent 常见的工具包括SQL 查询工具Python 计算工具数据可视化工具机器学习模型搜索与知识检索工具报表生成工具企业 API消息和工作流系统。工具调用让大模型不再只是生成文字而是能够真正执行分析任务。但工具并不是越多越好。当系统同时向大模型暴露几十个甚至上百个工具时模型需要在大量相似描述中完成选择很容易出现选错工具参数填写错误工具调用顺序混乱中间状态丢失重复执行陷入调用循环。因此Data Agent 的工具设计需要保持克制。一种更稳妥的方式是将底层能力收敛为少数几个高层工具。例如数据查询工具统一连接数据仓库、数据库和语义查询引擎。代码执行工具允许模型运行 Python、SQL 或其他分析代码。知识检索工具统一检索业务文档、指标定义和历史分析内容。可视化与报告工具将分析结果转换为图表、看板或报告。大模型不需要理解每个数据库、每个算法库和每个报表接口的具体细节而是通过稳定的协议调用这些高层能力。其中代码执行环境尤其重要。复杂分析往往需要多轮计算查询原始数据清洗异常值计算派生指标按不同维度聚合绘制图表检验假设保存中间结果。如果每一步都依赖一次独立的工具调用中间状态很容易丢失。一个具备持久上下文的代码执行环境可以保留变量、数据表、函数和计算结果使 Data Agent像分析师使用 Notebook 一样连续工作。这种模式还能够提升分析过程的可复现性。因为最终结论不再只是模型生成的一段文字而是能够追溯到使用了哪些数据执行了哪些代码采用了什么计算方法生成了哪些中间结果。七、四个模块如何在一次分析中协同以“为什么上个月华东区域销售额下降”为例可以更直观地理解整个架构。第一步大模型理解问题模型识别出这是一个诊断性分析任务需要先确认销售额口径华东区域范围对比周期用户可能关心的分析维度。第二步查询语义层语义层返回销售额的标准指标定义华东区域对应的组织范围可用于拆解的产品、渠道、客户等维度指标对应的数据表和字段。第三步调用 RAGRAG 补充相关业务知识上个月是否有促销政策变化某些区域是否调整过渠道销售额分析通常采用什么诊断框架该指标是否存在数据延迟。第四步生成分析计划大模型制定步骤计算华东区域上月和前月销售额判断下降幅度按省份拆解按产品和渠道拆解分析价格、销量和产品结构检查退款和取消订单识别主要贡献因素。第五步调用工具执行SQL 工具获取数据。Python 工具计算贡献度和结构变化。可视化工具生成趋势图、瀑布图和维度对比图。第六步验证结果系统检查各维度汇总是否与总销售额一致时间范围是否正确是否存在重复订单下降贡献是否超过总下降额结论是否能够被数据支持。第七步生成结论大模型将计算结果转化为业务语言并给出下一步建议。这时最终答案并不是大模型“猜”出来的而是多个模块协同完成的结果。八、真正困难的不是连接而是治理协同从技术演示来看把大模型、向量数据库、指标平台和 SQL 工具连接起来并不困难。真正进入企业生产环境后问题通常出现在模块之间。例如RAG 中的指标定义与语义层中的指标口径不一致应该以谁为准用户在对话中临时修改口径这个口径是否应该被保存大模型生成的分析计划超出了用户的数据权限应该在哪一层拦截SQL 查询结果与历史报表不同系统应该继续分析还是先提示差异工具执行失败后是自动重试、修改参数还是要求人工介入这些问题已经不只是模型能力问题而是系统治理问题。一个企业级 Data Agent需要明确不同模块的责任边界。通常来说大模型负责理解、规划和解释RAG 负责提供非结构化知识语义层负责提供结构化业务定义工具负责执行真实任务验证模块负责检查结果权限系统负责控制数据访问审计系统负责记录整个过程。模块之间需要有明确的优先级和冲突处理机制。例如在指标口径问题上经过审核发布的语义层定义应当高于普通文档中的描述用户临时指定的分析口径可以在当前会话中生效但不应直接覆盖企业标准指标。只有建立这些规则Data Agent 才能从“能运行”走向“可控制”。九、企业级 Data Agent 最终要解决三个问题从架构角度看大模型、RAG、语义层和工具调用分别解决了不同问题。大模型解决的是灵活性。RAG 解决的是企业知识。语义层解决的是指标确定性。工具调用解决的是实际执行。但企业真正关心的最终仍然可以归纳为三个问题。第一结果是否可靠数据来源是否明确指标口径是否一致计算过程是否可以验证。第二过程是否可控权限是否有效工具是否安全模型是否会越权错误是否能够被发现。第三能力是否可复用一次分析能否沉淀为指标、模板、流程、报告或新的分析知识。如果 Data Agent 每次都从零开始理解问题、寻找数据和生成逻辑即使单次结果不错也很难形成企业级生产能力。真正有价值的 Data Agent应当在持续使用中沉淀用户偏好指标口径分析方法业务知识任务流程历史结论验证规则。随着这些资产不断积累Data Agent 才可能从一个通用模型逐渐变成理解企业数据和业务逻辑的分析系统。结语Data Agent 并不是大模型取代 BI也不是 RAG、语义层和工具调用的简单组合。它更像是对企业数据分析链路的一次重新组织。大模型负责理解复杂需求和规划分析过程RAG 提供企业内部的业务知识语义层保证指标和数据口径的确定性工具系统负责执行查询、计算、建模和可视化验证机制则负责控制结果风险。这几个模块缺少任何一个系统都可能出现明显短板。只有大模型没有语义层系统容易生成口径错误但表达流畅的答案。只有语义层没有大模型系统仍然需要用户按照预定义方式操作。只有 RAG没有执行工具系统只能解释知识无法真正分析数据。只有工具调用没有规划和验证系统可能执行大量操作却无法保证分析方向正确。所以企业级 Data Agent 的关键并不是选择一个参数更大的模型而是建立一套能够让模型、知识、语义和工具相互约束、相互补充的技术架构。从这个意义上看Data Agent 的竞争最终不会只发生在模型层。真正决定产品能否进入企业生产环境的是它能否把大模型的不确定性转化为数据分析过程中的确定性。